►
From YouTube: IETF113-DRIP-20220323-1200
Description
DRIP meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
C
A
D
E
Apparently,
I
want
to
run
things
good
afternoon.
Everyone.
This
is
the
itf's
drip
session,
so
anyone
who
is
not
interested
in
trip
please.
E
D
C
Daniel
you
are
good,
but
at
the
desk
that
we
can't
hear
our
on-site
delegate
here.
F
C
G
I
G
H
Okay,
so
this
is
a
not
well
unless
you
have
never
seen
it
so
take
the
time
to
read
it.
If
you
have
any
questions,
please
come
to
to
see
us
or
contact
our
ad
next
slide.
H
So
these
are
the
rules
for
how
we
handle
this
meeting,
that's
hybrid
meetings,
so
we
have
in
person
participant
and
remote
participant.
I
I
think
that
we're
not
that.
H
Numerous
and
if
you
have
a
question
I
would
say
you
can
jump
into
into
the
conversation,
we
are
more
in
a
conversation
like
a
type
of
meeting
next
slide.
H
So,
where
we
are
so,
we
have
our
first
rfc
being
published
and
now
we're
heavily
focused
on
the
derip
architecture.
H
H
And
we
we
have,
I
would
say,
one
of
the
main
document,
the
chord
document,
which
is
the
err
id
that
is
in
working
group
last
school.
H
So
milestones
where
we
have
a
few
other
documents
that
we
need
to
to
focus
on:
it's
not
the
end
of
the
road,
but
we're
pretty
good.
In
that
I
see
the
registries
we
we
target
to
be
done
by
the
end
of
the
year
for
the
next
itf.
We
think
oauth
oath
might
be
a
good
target,
pretty
confident
about
that
one.
H
H
So
this
is
the
agenda
and
I
suppose
that
schway
is
gonna
start
has
anyone
wants
to
say
something
before
we
start
the
presentation.
H
No,
so
I
suggest
that
schwei
is
presenting
the
drip
arc.
A
I
I
lost
control
here
for
a
second
sorry.
What
slide
deck
was
it
for.
J
Actually,
there
is
no,
there
is
no
slide
for
the
the
first
two
ones.
This
is
just
for
the.
I
would
say
for
the
editors
to
report
any
last
minute,
major
issues
you
have
on
the
and
for
the
read,
there's
only
one
flight
from
from
school.
So
if
there's
nothing
to
report
from
the
from
the
ark,
we
can
move
to
the
next
one.
So
for
bob
to
report
in
here
I
would
say
last
major
issue
on
his
side.
J
A
J
The
red
draft,
and
then
we
can
move
to
to
see
what,
for
the
for
the
astm
update,
got
it.
Okay,
thank
you.
B
You
want
me
to
proceed
with
this
one,
I
believe
so,
okay,
so
we
all
know
our
first
rfc
has
been
published
and
then
at
right
about
the
same
time
as
our
requirements
and
terminology
were
published.
The
astm
f-38
committee,
which
is
the
unmanned
aircraft
system
operations
committee,
entered
ballot
on
two
uas
red
documents.
One
of
them
is
the
revision
of
f
3411-19,
which
has
been
the
basis
of
most
of
our
work.
There
was
extensive.
B
B
B
The
picture
in
the
middle
is
just
an
illustration
of
the
flow
if
you
will
of
requirements
from
external
down
to
our
proposed
standard
drafts.
As
you
know,
the
architecture
draft
is
just
entered.
Iatf
last
call
this
mormon
morning.
K
So
this
is
our
reference
architecture,
so
there
is
like
five
components:
observer
with
android
application
up
the
drone
with
raspberry
pi
and
other
add-ons
like
gps
and
battery,
and
when
the
registry
based
on
eroja
blockchain,
which
keeps
track
of
drone
data,
and
then
there
are
different
types
of
users
that
can
request
this
data
from
from
blockchain.
So
next
I
will
describe
like
the
progress
of
different
components.
K
So
code
is
using
open
heap
implementation
of
host
identity
protocol
with
different
additions
and
it's
a
part
which
is
open
source,
so
some
changes
which
are
coming
because
of
change
both
with
in
hierarchical
hits,
format
we'll
need
to
address
that,
and
second
part,
is
that
mostly
python
trips
to
handle
this
registration
and
look
up
messages.
So
it's
not
currently
published,
but
we
work
to
do
it
towards
end
of
year.
K
So
the
the
drone
broadcasts
things
using
stm
format
with
drip
additions
based
on
extension
of
drone
id
and
we
experiment
with
wi-fi
different
modes
as
well
as
bluetooth,
4
and
bluetooth
5..
K
So
why
irocan
it's
a
blockchain
that
it's
permission-based
and
it
has
some
nice
features,
so
we
actually
did
also
some
simulations
to
understand
what
kind
of
number
of
drones
it
can
handle
and
it's
quite
promising.
So
it's
like,
let's
say
hundred
of
drones
within
certain
limited
geographical
areas,
is
supported
in
terms
of
transaction
times
and
processing
times
and
hence-
and
next
it's
also
next
slide.
Please
it's
also
supporting
some
of
all
the
requirements
that
specified
in
with
drip
registry
draft.
K
So
I
hope
it
will
be
also
included
as
one
option
in
the
future
of
revision
of
registries.
Rafat
adam
is
promoting
next.
K
So
I'm
now
going
to
talk
briefly
about
our
experiments
with
bluetooth.
Five,
quite
many
devices
claim
now
they
support
bluetooth
five,
but
it
seems
like
not
all
features
are
actually
supported,
so,
for
example,
raspberry
pi
4
is
not
really
supporting
it.
Well
enough,
so
we
are
trying
to
experience
with
a
dongle
and
development
kit,
rf52
f40,
to
sort
of
test
the
range
and
other
features
next
slide.
K
H
A
question:
yes,
when
you
say
it
does
not
support
what
is
not
support
exactly.
K
I
Okay;
okay,
if
you
don't
mind
andre
I'll,
expand
on
that
a
little
bit.
Basically,
a
lot
of
hardware
chips
will
support
bluetooth
5.
The
spec
is
an
extension
of
bluetooth
4,
but
all
of
the
extensions
for
bluetooth
5
are
optional,
the
only
one
being
back
port
to
bluetooth
4..
I
K
K
So
for
wi-fi
it
works,
but
it's
a
short
range,
maybe
some
less
than
100
meters.
So
we're
also
looking
at
the
neighborhood
awareness
mode,
which
is
getting
support
in
the
recent
phones.
K
However,
people,
like
bob,
pointed
out
that
now
wi-fi
beacons
is
a
way
to
go,
but
I'm
not
sure.
What's
the
level
of
support
of
that
and
the
recent
hardware,
we
have
to
investigate
next
slide,
and
this
is
the
observer
application.
It's
based
on
open
drone
id
extension,
as
in
as
you
can
see,
it
successfully
receives
h,
hits
from
the
drones
and
displays
location
as
well
allows
to
query
the
database
where
registry
based
on
user
credentials
next
slide
and
regarding
the
bluetooth
5.
We
did
some
measurements.
K
It's
not
so
easy
to
find
like
one
kilometer
open
space
in
sweden,
so
we
actually
had
to
go
to
the
two
lake
and
with
this
development
kit
we
were
able
to
reach
about
one
nordic
mile
distance,
which
is
already
much
better
than
let's
say
100
meters
with
wi-fi.
So
once
we
kind
of
resolve
this
compatibility
issue,
we
will
new
to
five
in
different
devices.
Hopefully
it
will
be
good
means
next
slide.
K
So,
as
you
see,
these
are
components
we
have
to
combine
and
put
it
like
add-on
to
to-
let's
say
a
phantom
drone,
so
there
is
a
raspberry
pi
for
when
there
is
battery
hat
and
then
where
is
gps,
so
all
of
that
should
be
like
mounted
on
a
drone
to
actually
transmit
this
id
data.
K
K
So
one
of
the
things
we
were
trying
to
do
is
to
add
the
support
for
open,
ssl
30,
because
it's
like
latest
crypto
library,
which
has
all
the
latest
ciphers
and
hashes
and
so
on
and
the
open
hip
is
it's
historically
based
on
open,
sl
one
zero
and
then
it
was
extended
a
little
bit
to
one
one
zero,
but
still
like
not
the
latest
one.
Next.
K
So
it
was
like
basically
almost
rewrite
of
the
code
because
it
was
like
thousands
of
warnings
and
other
stuff
next
slide,
but
we
kind
of
finished
the
update,
so
the
code
is
compiled,
but
it's
not
well
tested
yet
so
we
are
maybe
in
autumn
we
will
work
on
more
automatic
tests
to
sort
of
and
packet
format
tests
to
make
sure
it's
like
interoperable
and
compatible
to
the
latest
air
fesis.
K
Next
also,
we
were
working
about
not
traversal
implementation.
So
you
see
this
rfc
9028
is
relatively
fresh
from
from
july.
So
again
we
finished
basic
implementation,
but
more
testing
is
needed,
but
I'm
curious
to
see
your
opinion
like.
Is
it
really
helpful
for
for
drip?
Do
we
need
to
go
like
over
utp
or
and
use
ice,
or
we
assume
that
we
can
have
like
always
direct
hip
and
ipsec?
You
know
in
all
cases,
maybe
at
least
for
the
kind
of
remote
registry
access.
Maybe
it's
useful.
K
Next,
so
we
still,
there
is
something
to
do
so.
There
is
like
data
relay
server
implementation
to
do
and
update
the
core
simulator
that
we
used
for
these
use
cases
next,
please
so
what
we
are
also
doing
is
we
are
trying
to
do
formal
verification
like
I
know,
for
example,
bob
likes
this
idea
that
the
security
protocol
should
be
formally
verified
and
the
last
attempt
to
do
it
for
hip.
K
I
think
it
was
like
10-15
years
ago,
so
we
are
now
using
more
modern
tool
and
also
implement
drip
features
and
also
we
are
involved
in
several
eu
projects
which
are
targeting
to
do
big
scale
demonstrations
like
almost
a
drone
flying
taxi
or
ambulance.
K
So,
for
example,
there
are
some
testbeds
planned
in
norway,
scavander
and
in
helsinki,
so
try
to
put
some
prototype
and
hardware
to
these
drones
to
broadcast
remote
id
and
xoro.
Squam
is
another
example
that
is
also
like
large-scale
demonstration,
so
we
plan
to
fly
a
big
drone
between
two
cities
in
sweden
beyond
light
of
sight,
so
maybe
one
of
first
operations
like
that-
and
it
also
would
be
nice
to
to
have
a
drip
as
part
of
this
thing
and
the
final
slide,
please
yeah.
K
So
this
air
more
is
focusing
on
emergency
medical
services
because
based
on
surveys,
it
seems
like
it's
a
kind
of
application
area
that
most
people
will
support
adoption
of
drones.
Even
if
it's
noise
and
some
other
features-
and
you
see
there
are
some
chinese
models
like
which
is
already
purchased
and
being
tested
and
in
norway,
and
they
of
course,
waiting
for
some
authorities
permissions
to
actually
start
flying
people
in
that.
So
it's
ongoing
research
and
active
area
in
new
space
in
europe.
A
Stuart
is
taking
notes
and
I'm
sure
he
recognizes
everybody's
voice,
but
there
may
be
other
people
taking
part
in
the
meeting.
Sorry
stuart
is
taking
notes
of
this
meeting
and
it
probably
recognizes
everybody's
voice,
but
other
people
are
in
the
room
here
or
on
the
internet.
Somewhere
else
might
not
recognize
who's
speaking
something
by
yourself
when
you
come
to
the
mic.
Thank
you
very
much
and
help
first
question
from
daniel.
H
Yeah,
so
I
have
one
question
to
andrew:
it's
a
I
mean
I,
I
don't
see
the
the
migration
to
open,
ssr
three
as
a
huge
challenge,
but
I
just
want
to
check
if
I
am
correct.
H
H
K
Yeah,
I
mean
it's
if
you
have
like
legacy
code,
it's
like
a
lot
of
update.
It's
almost
like
rewriting
from
scratch,
so
I'm
not
sure
about
other
people
using
hip
are
very
going
to
do
the
operator.
C
Pointing
out,
as
I
said
in
the
in
the
chat
that
the
value
one
of
the
big
values
of
hip
for
the
ua
is
going
to
be
for
network
remote
id
and
command
and
control
and
not
being
locked
into
a
single
connection
methodology.
He
has
demonstrated
this
already
in
his
test
over
at
the
uas
site
there.
In
fact,
in
his
neighborhood
here
in
griffith
international
air
force
booth,
you
can
do
that
in
previous
sessions.
C
So
you
may
think
that
this
is
orthogonal
the
the
open
hip
discussion,
but
it
is
going
to
be
important
as
we
move
forward
to
the
next
steps
than
being
able
just
to
well
support
the
activities
for
where
we
go
beyond
the
basic
broadcast
messages.
When
we
start
moving
on
to
the
network,
remote
id
and
and
support
for
better
support
for
command
and
control,.
B
To
clarify,
while
command
and
control
itself
does
not
lie
strictly
within
the
scope
of
the
drip
working
group,
recreating
applications
based
upon
identity
does,
and
so
that
would
include
so-called
detect
and
avoid
command
and
control
vehicle
to
infrastructure,
vehicle
to
vehicle,
etc.
A
H
Andreas
presented,
one
implementation,
I
guess
two
in
adam
as
another
implementation
did
you
do
some
interrupt
interoperability
test
or
are
we
aware
of
any
other
implementation
at
that
point,
and
maybe
if,
if
that's
possible,
adam
was
too,
can
you
just
let
us
know
what
you
are
implementing
I
mean:
are
you
doing
the
equivalent
of
androids
or
is
that
more
restrained
or
more
specific,
I
mean
if
it's
possible,
I'd
like
to
have
some
more
detail.
I
would
be
interested.
B
Okay,
so
I'll
make
it
very
quick,
adam
and
others
at
the
new
york
uas
test
site
are
doing
a
tremendous
amount
of
work
in
prototyping.
Unfortunately,
the
nature
of
our
funding
is
such
that
it
is
a
struggle
to
get
any
of
it
openly
released.
We
will
continue
the
struggle.
I
Right,
yep
thanks.
I
hope
everyone
can
hear
me
so
I'm
gonna
go
over
two
topics
today,
I'm
gonna
go
over
authentication
formats
and
also
the
registries,
so
I'll
start
with
authentication
formats,
because
that'll
be
pretty
pretty
quick
on
us,
so
changing
since
03,
the
fec
section
is
now
fully
filled
in
it
will
need
somewhat
of
an
extensive
review.
I
There
were
a
couple
small
things
that
were
changed
on
two
of
the
formats:
appendix
a
was
fully
filled
in
with
some
diagrams
and
some
text.
An
appendix
d
was
added
for
to
do.
Med's
comment.
I
So,
sir,
some
still
some
pending
issues,
as
I
said,
fec
needs
to
get
reviewed.
I've
noticed
that
with
reed
solomon,
especially
in
my
implementation,
that
you
need
a
specific
polynomial
on
both
sides
for
the
forward
error
correction
to
even
properly
work,
and
I
have
run
into
an
issue
where
I've
had
colliding
polynomials.
So
we
might
have
to
actually
specify
one
in
the
draft.
I
I'm
not
sure
how
to
approach
this
so
I'd
like
some
guidance
on
that
or
we
can
just
work
on
it
as
a
working
group
together,
the
appendix
d
was
to
directly
address
a
comment
from
med.
Hopefully
it
satisfies
his
comment
along
with
a
conjunction
with
appendix
a
and
then
I
need
to
loosen
some
language
there's
some
weird
language
during
some
transition
where
manifest
became
the
required
and
thing,
but
it
used
to
be
wrapper,
but
it
seems
like
both
can
be
used.
I
So
I
have
to
just
fix
some
of
the
wording
around
in
that
to
get
it
right
for
next
steps
on
this
draft,
I'm
going
to
be
sending
it
internally
in
ax
enterprise
to
laura
welch,
for
an
english
language,
review,
she's,
very
good
at
english,
and
maybe
not
so
much
on
the
technical
side,
but
she'll
be
able
to
read
through
the
draft,
make
it
readable
to
humans
that
are
not
technically
as
savvy
and
help
find
any
major
issues.
I
I
I
I
I
hated
the
document
as
it
was
so
I
took
some
time
about
a
week
and
a
half
and
really
cleaned
it
up
reorganized
it
there's
some
new
sections
in
the
introduction
to
get
a
high
level
of
view
of
like
a
story
of
a
typical
life
cycle
using
the
registries
in
drip.
There
was
a
whole
section
of
attestations
and
certificates
that
was
moved
down
into
the
appendix
because
inline
it
was
getting
really
clunky
to
read
the
document.
I
There
was
some
text
added
for
key
rollover
and
federation
of
registries,
which
I'll
touch
on
a
little
bit
later,
and
there
was
an
attempt
at
merging
high
level
points
from
the
deep
section
5
into
the
section
4
of
this
document.
I'm
going
to
be
working
more
with
bob
to
make
sure
that
I
got
all
the
pieces
needed
for
that
and
massage
any
text
there.
The
big
change
from
this
was
sections
seven
and
sections.
Eight
of
zero.
Zero
were
merged
into
one
section,
section
six,
so
that
would
got
a
lot
cleaner
in
formatting.
I
It
was
more
fleshed
out
section.
Seven
in
the
original
document
was
extremely
technical
and
just
very
hard
to
read
where
section
eight
was
more
of
prose
and
like
a
story
and
how
registration
works
with
the
inner
components
they've
been
melded
together
in
a
lot,
hopefully
an
easier
way
to
understand.
I
I
Drip
is
not
bound
to
dns,
epp
or
rdap.
I
think
there
might
have
been
a
little
bit
of
a
misconception
that
this
was
going
to
be
the
only
way
for
it
to
work.
No,
that
wasn't
the
intention.
It
is
we're
going
to
use
dns,
epp
and
rdap
as
a
baseline
to
get
something
out
the
door
standardized
and
working
for
deploying
and
then
also
drip
is
not
exactly
bound
to
the
d.
It's
just
come
up
in
previous
meetings.
There
was
no.
I
There
has
been
no
other
solution
being
put
forward,
but
if
one
does
come
later
in
the
registries,
the
registration
architecture
that
we
currently
have
is
strongly
tied
to
the
drip
entity.
Tags
hid
structure,
the
raa
hda
split.
I
So
if
someone
wants
to
write
another
registry
draft
either
one
they
need
to
mimic
the
hid
in
their
identifier
or
two
produce
a
whole
new
registration
architecture
using
their
new
identifier,
format
and
hierarchy
and
that's
a
bridge
we
will
go
across
if
we
need
to,
but
I
tried
to
make
it
so
that
the
document
was
clear
that
this
ties
with
the
deet
and
if
something
else
comes
along,
it
would
be
a
different
draft.
I
So
pending
issues
there
was
a
error
on
my
part.
When
I
pushed
I
was
asked
to
do
a
contributor
section,
I
accidentally
copied
and
pasted
the
full
acknowledgement
section
into
the
contributors
section,
so
scott
allenbeck
was
pulled
into
the
contributors
section
and
I
didn't
realize
I
had
done
this,
so
he
has
been
pulled
back
out
in
a
running
version.
That's
on
my
side
and
he's
back
as
an
acknowledgement.
Andre
was
pulled
as
a
contributor.
Speaking
of
andre,
I
actually
oversighted
and
lost
his
text
email
a
couple
months
ago.
I
I
found
it
again,
so
I
have
the
text
again
and
I
will
be
adding
it
in
per
andre's
presentation
a
little
bit
earlier.
I
don't
know
if
this
is
an
appendix
or
if
it's
going
in
line,
I
believe
it's
an
appendix
and
that's
where
I'm
going
to
put
it
for
now
and
then
we'll
go
from
there.
I
I
I
need
to
work
with
bob
and
I've
already
discussed
it
with
him
about
pulling
text
for
the
ra
and
hda
into
this
draft.
So
hopefully
that
will
happen
in
the
next
couple
of
weeks
and
then
I'll
push
o2
out
so
the
rest
of
this
time.
Well,
actually,
bob.
Let's
take
your
question
because
I
have
plenty
of
time.
C
Just
quickly
the
top
moving
text
up
from
rid
to
registries
just
text
from
red
to
auth,
we
start
with
the
text
and
read
to
get
it
kind
of
laid
out
and
once
the
where
it
belongs,
started
evolving.
We
moved
the
text
so
dad
and
I
will
do
it
we'll
be
pulling
checks
out
of
red
and
moving
it
where
it
belongs
in
registries.
C
I
Thanks
bob
okay,
so
I
want
to
spend
the
rest
of
the
15
minutes
of
this
to
go
over
some
registration
process
stuff.
This
is
the
first
time
I
think
this
has
been
presented
to
the
working
group.
This
has
been
internal
to
well,
basically
myself
and
stu
for
the
past
year
and
I'm
finally
getting
the
chance
to
kind
of
go
a
little
bit
more
in
detail
to
it.
I
I
There's
a
branch
on
the
left
that
consists
of
the
irm
and
the
mra,
which
is
mostly
dealing
with
serial
numbers
and
then
the
branch
on
the
right
which
deals
with
other
raas,
mostly
under
civil
aviation
authorities,
and
they
have
values
of
ras
greater
than
two
and
hda,
is
greater
than
one.
I
I
But
it's
actually
specifically
the
remote
id
registry
portion
of
drip,
and
this
key
indeed
would
be
used
by
the
operator
during
session
id
registration
and
then
finally
session
id
registration,
also
at
that
uss
or
that
remote
id
registry,
and
that
is
a
deet
proposed
to
be
used
by
the
ua
during
flight.
For
that,
given
flight.
I
So
this
is
a
z
diagram.
It's
not
perfect.
There
are
some
issues
with
this
that
I'd
like
to
fix,
but
to
get
us
started,
so
this
is
serial
number
registration
into
the
mre
or
the
manufacturer's
registry
of
aircraft.
Basically,
at
the
start
of
time,
the
manufacturer
would
build
an
unmanned
aircraft.
I
If
the
unmanned
aircraft
can't
create
the
key
pair
itself
and
they
would
propose
it
to
the
manufacturer's
registry
using
a
self-attack
station,
there's
some
internal
stuff
that
goes
on
extracting
the
drip
entity,
tag
checking
for
collisions
in
both
the
database
and
the
dns.
I
So
to
make
a
comment
that
I've
gotten
from
stu
recently
on
these
slides,
there's
a
reason
that
dns
and
database
are
different
or
split.
Apart
on
this,
the
database
mostly
holds
a
personally
identifiable
information
or
pii
or
just
other
additional
information.
I
In
this
particular
scenario,
we
would
be
holding
ua
information,
the
ua's
weight,
how
many
rotors
it
has.
What
color
is
it
make
and
model?
Obviously,
what
type
of
battery.
I
I
So
this
is
two
examples.
These
are
pulled
from
the
drip
registry
draft,
as
it
is
stands
right
now
on.
The
left
is
an
epp
command
for
registering
a
serial
number
and,
as
you
can
see,
all
of
the
fields
here
are,
you
know,
make
model
color
material,
those
kinds
of
things
that
would
end
up
in
the
database
and
then
on.
I
The
right
is
our
inputs
and
our
outputs,
and
also
our
dns
entries,
what
fields
of
dns
exist
or
what
resource
records
in
dns
exist
for
a
given
serial
number
now,
while
the
serial
number
is
useful
and
we
can
create
a
serial
number
using
a
deet
and
that
helps
for
modules,
the
real
important
one
for
drip
is
the
session
id,
which
is
what
the
deed
is
acting
as
it's
acting
as
a
uas
session
id.
So
a
very
similar
process
happens
with
a
session
id.
I
Hopefully,
the
aircraft
can
create
their
own
key
pair
in
this
scenario,
so,
basically
the
operator
would
poke
the
aircraft
it
would
generate
its
key
pair,
send
it
along
with
a
serial
number
and
additional
information
around
back
to
the
operator
who
x,
is
basically
a
middleman
between
the
aircraft
and
the
registry,
software
passing
it
back
and
forth.
I
We
have
the
same
kinds
of
checks
for
collision
checking
with
the
deets
and
all
the
varying
parts,
and
once
it's
done
importantly
for
this,
the
broadcast
attestation
is
generated,
and
this
is
vital,
as
in
drip,
we
require
that
the
broadcast
attestation
be
sent
over
the
air
in
the
authentication
message.
This
is
what
the
auth
draft
is
all
about,
and
this
is
where
that
broadcast
attestation
comes
from,
and
this
is
all
handed
back
to
the
unmanned
aircraft
through
the
operator.
There
are
other
ways
to
cut
this
cake.
I
You
know
we
could
have
the
unmanned
aircraft
reach
through
an
lte
connection
right
to
the
remote
id
registry.
That
is
a
valid
way
of
doing
it.
This
is
just
one
of
a
different
many
different
ways
to
do
this
process.
I
Again,
this
is
some
examples
so
on
the
left,
which
is
not
the
same
as
the
last
slide.
These
are
the
dns
entries
that
would
be
in
the
remote
id
registry,
along
with
what
inputs
and
outputs
were
needed
for
the
registration
to
occur,
and
then
on
the
right
is.
The
epp
is
an
example
of
the
epp
that
is
sent.
There
is
a
couple
things
in
the
epp
that
we
have
not
discussed
in
this
working
group
and
one
of
the
major
things
is
the
operational
intent.
I
The
operational
intent
is
basically
the
utm
link
back
into
utm
to
get
the
4d
volume
box
if
the
particip,
if
they
are
participating
in
utm,.
I
I
It's
an
interesting
topic
because
we're
going
to
have
to
probably
federate
registries
and
with
the
h
hit
or
the
d
acting
as
its
identifier
and
the
last
64
bits
being
the
hash
it'll
be
interesting
to
see
how
this
works,
because
the
hid
would
be
the
same.
You
could
have
a
registry
like
the
root
registry,
0
0,
but
you
could
produce
2
to
the
64
keys
and
they'll
all
have
different
hashes,
but
it's
all
technically
the
same
registry.
I
So
I'm
curious
how
this
would
affect
deployment
and
use
of
the
system.
I
don't
have
any
free
cycles
to
explore
that
topic
even
on
a
crypto
security
level.
I
So
if
there's
any
takers
for
that
that
be
really
interesting,
and
we
can
add
that
text
into
the
draft-
and
I
hope
to
have
an
interim
not
directly
after
this,
but
maybe
a
couple
weeks
a
month
from
now
as
to
focus
on
the
z
diagrams
there,
the
two
z
diagrams
I
showed
you
are
two
out
of
22
z,
diagrams
that
I
have
and
there
I
would
like
to
do
a
deep
dive
with
the
working
group
and
anyone
that's
interested
to
understand
the
process
and
the
flow
that
we've
had
in
our
heads
for
the
past
year
and
a
half
on
how
registries
would
work
to
get
it
into
the
draft
a
little
bit
better
and
with
that
I
think
I'm
ready
just
to
take
some
discussion
if
anyone
has
anything
to
discuss
for
the
first
time.
B
I
maybe
yep
I've
only
got
one
and
this
at
the
moment.
This
is
mostly
focused
on
adam's
registries
draft,
where
there's
a
question
of
how
much
detail
to
include
on
epp
and
rdap
as
specific
techniques
for
implementing
the
registries
and
also
to
some
extent,
on
the
architecture
draft.
I
feel
like
we
kind
of
have
a
failure
to
commit
here
to
achieve
interoperability.
B
We
need
specifics
and
abstraction
is
a
fine
thing,
but
getting
abstractions
right
takes
a
long
time
and
the
bus
is
leaving
the
station
with
regard
to
regulations
and
manufacturers,
building
application,
specific
integrated
circuits
and
so
on.
So
we're
really
going
to
have
to
come
to
some
decisions
rapidly
on
how
much
specific
protocol
detail
to
include
in
these
documents
versus
how
much
to
attempt
to
continue
to
remain
abstract
and
then
produce
still
more
documents
that
will
have
the
details.
Slash
ram.
A
C
The
concern
about
the
multiple
hits
per
rari
or
or
hda
is
being
issued.
That's
actually
how
how
key
rollover
will
be
achieved
and
and
how
they'll
be
linked
in
registries.
So
that
was
part
of
my
original
thoughts.
When
I
came
up
with
this
idea,
it's
just
that
now,
adam
and
I
are
gonna-
have
to
sit
down
and
get
done
over
the
over
the
next
two
months,
so
that
that's
in
there
it
and.
A
I
So
I'll
say
this
to
a
little
bit
to
bob,
but
just
as
in
general,
so
I
knew
that
key
role
that
that
was
used
for
key
rollover.
But
what
struck
me
is
interesting
was
that
we
have
a
root
server,
hda,
ra0,
hda0
and
there's
only
one
of
them
in
the
registry
tree
and
obviously
having
that
sync
having
it
as
a
single
server
is
a
point
of
failure,
so
you
would
probably
want
to
have
multiple
root
servers
kind
of
like
how
dns
works.
Now.
I
The
problem
with
that
in,
I
think
in
our
thing
is,
is
like
if
you
want
to
have
an
asymmetric
key
pair
to
generate
the
hit
and
dust,
the
deed,
etc,
you
would
need
to
have
a
different
key
on
every
box.
So
if
you
had
say
seven
root
servers
they're
all
going
to
have
different
key
pairs.
I
How
is
this
managed
right?
Because
who
you
don't
want
a
malicious
party
joining
the
club
just
because
they
created
a
key
pair?
You
would
want
to.
There
needs
to
be
some
sort
of
control
on
that,
and
this
happens
at
every
level
of
the
registry
tree,
and
that
was
where
my
thought
of
federation
and
interest
in
the
key
role
over
in
the
keys
came
in.
A
C
Barely
here
I
got
my
sound
crank
cranked
all
the
way
up,
but
just
again
on
the
slides
for
the
rid
that
I
have
permitted
our
proposed
are
out
there
I
put
url
again
in
the
chat.
It
was
also
on
the
list.
Basically,
there's
some
med
has
a
couple
things
he
wants
me
to
address.
They
are
easy
to
do
work
on
them
next
week,
ayanna
says
they
are
going
to
do
a
review
of
the
new
ayanna
considerations.
C
I
added
a
lot
of
text
in
there,
so
they
may
have
a
lot
of
comments,
but
ian-
and
I
will
work
that
through
but
x-
I'm
parked
for
the
end
of
next
week
to
have
dash
18
out
of
any
comments
on
what
I
haven't
had
17.
Please
get
them
to
me
in
the
beginning
of
the
week,
so
I
can
get
them
included.
Thank
you.
I
Okay,
so
I
have
one
more
thing
to
add
to
the
meeting.
This
is
what
I
get
for,
not
putting
it
on
the
slide,
so
this
is
to
answer
daniel
a
little
bit
earlier
when
andre
had
finished
his
presentation.
I
My
intent,
if
all
the
stars
align
and
the
universe
is
nice
to
me-
is
that
in
philadelphia
at
ietf
114,
I
would
like
to
do
a
demonstration
of
the
ax
implementation
of
uas
remote
id,
and
I
want
to
do
a
full,
a
full
demonstration.
I'll
have
an
aircraft
I'll
have
a
puck.
I
I
So
I
do
intend
to
have
a
implementation
share.
Also
to
answer
daniel
from
earlier.
Ax
has
worked
with
another
partner
in
utm
that
was
developing
a
remote
id
application
and
it
was
not
drip
specific.
It
was
astm
only,
but
our
implementation
did
work
with
theirs,
so
we
were
able
they
were
able
to
see
our
identifier.
We
were
able
to
see
their
identifier,
their
side
just
kind
of
made
it
garbled
garbage
on
their
ui,
but
that
was
because
they
didn't
know
how
to
decode
it.
I
They
just
took
the
raw
bytes
and
just
displayed
them,
and
they
were
seeing
all
the
pieces.
They
just
didn't
know
what
to
do
with
all
the
pieces
as
for
for
with
andre.
I
would
like
to
do
an
interrupt
test
with
him.
We'll
coordinate
that
somehow
it's
kind
of
hard
to
do
an
interop
coordination
when
you're
on
the
other
side
of
the
world
at
times,
but
we
I
do
intend
to
work
with
andre
and
get
in
interop
with
drip
to
drip.
Maybe
114
is
the
answer.
A
Has
anyone
got
anything
else
to
say
I
guess
not?
Okay,
this
meeting
of
the
dis
working
group
has
closed.
I
would
like
to
thank
the
speakers
and
also
for
doing
a
fantastic
job
of
keeping
to
the
time,
even
though
I
screwed
it
up
at
the
start,
by
being
unable
to
make
me
tackle
work
properly,
and
I'd
also
like
to
felt
my
fellow
delegates
to
evan
for
his
efforts
today
and
also
to
eric
for
applying
me
take
a
clue
whether
it
was
badly
needed.
A
B
Yeah,
I'd
really
just
like
to
say
thank
you
very
much.
Jim
and
stefan.