►
From YouTube: IETF115-DRIP-20221110-1530
Description
DRIP meeting session at IETF115
2022/11/10 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
B
Okay,
so
hi
everyone.
So
this
is
the
drip
working
group
that
I'm
chairing
with
Med.
B
If
you
haven't
seen
the
note
well
since
the
beginning
of
the
ITF
I
would
be
a
little
bit
surprised,
but
it's
part
of
the
rules.
So
if
you
have
any
questions,
just
come
back
to
the
chairs
or
any
person
from
any
chairs
or
any
AD,
and
it
will
be
happy
to
respond
to
your
question.
B
So
I
guess
you
know
the
rules,
but
so
if
you're
using
I
mean
we,
we
ask
you
to
use
mitiko
to
go
into
the
line,
even
though
you're
in
person,
so
you
have
to
click
to
to
go
into
the
queue
of
the
meteco,
so
that
everyone
knows
who
you
are.
Who
is
speaking?
Who
is
asking
a
question?
B
Usually
we
ask
you
not
to
use
the
video,
but
if
you
I
mean
if
you're
speaking
not
on
site
remotely,
then
you
you
can
use
the
video.
Otherwise,
if
you
don't
speak,
make
sure
the
audio
is
mute.
B
B
So
this
is
the
current
agenda
for
today,
so
we
have
a
little
bit
of
a
I
mean.
This
is
the
introduction,
and
then
we
have
some
administrative
here,
which
is
how
we
liaise
with
other
organizations
to
get
some
Sam
cut
points.
B
I,
guess
Stu
is
probably
going
to
clarify
that
for
us,
then
we
have
a
some
some
active
duck
around.
The
working
group
is
focused
on
now
and
just
for
a
reminder,
the
one
we're
putting
all
our
effort
is
the
authentication
draft,
and
then
we
have
the
Registries.
So
these
two
are
I
mean
the
main
focus
of
the
working
group.
Then
we
will
have
a
point
from
Andre
on
what
are
the
implementation,
the
current
implementation
so
Andrea
and
Adam,
and
then
closing.
B
B
So
document
status
we
have
two
documents
that
are
at
the
ASG,
we're
basically
waiting
for
the
authentication
draft
to
be
completed
so
that
we
we
assure
the
three
drafts
are
equivalent
between
each
others.
A
Slide,
please,
if
you
can
just
yeah
so
as
as
mission
is
flies,
so
we
have
the.
There
was
a
lot
of
work
which
was
done
for
the
the
drip
architecture
and
the
the
read
specifications.
So
there's
a
lot
of
discusses
that
we
received
during
the
Azure
review
that
were
that
were
resolved
and
as
an
outcome
of
that
of
the
discussion,
there's
another
individual
draft
that
was
edited
in
the
APC,
the
work
group,
and
it
is
now
it
is
sponsored
by
Roman,
so
Bob.
A
A
A
There
was
some
commitment
during
the
the
previous
ATF
meeting
for
people
to
review
and
we
didn't
receive
the
four
people
that
committed
to
to
do
that,
but
received
at
least
if
I
remember
two
or
three
of
them,
and
then
we
launched
the
second
working
class
call.
There
was
Major
modification
in
the
specifications
we
hope
to
see
more
eyes
on
this
document.
A
So
far
we
only
have
the
the
working
of
chairs
who
will
review
the
document,
and
we
are
doing
this
as
a
courtesy
for
the
work
group,
but
we
would
love
to
see
more
eyes
on
this
one.
So
please,
even
if
it's
the
working
op
is
closed,
there
is
time
so
that
you
can
share
your
comments
on
this
one
before
we
decide
to
send
it
to
to
to
our
Ed.
So
there
is.
We
also
requested
the
the
early
their
expert
review
views.
Two
of
them
are
really
positive.
A
The
one
about
the
gene
art
and
the
security
directorate,
the
one
I
was
hoping
to
see,
was
from
the
operational
directory
because
there's
a
lot
of
aspect
there
about
the
provisioning
which
are
important,
we
didn't
receive
any
news
from
them.
We
really
contacted
them
so
that
we
can
send
us
the
review,
but
we
didn't
hear
from
them.
So
please
get
into
this
document
and
share
with
us
in
the
commentary
app
so
Daniel
peace.
B
Right,
so
these
are
the
miners,
the
milestones
so
so
the
authentication
is
sent
to
the
IHG
two
months
ago.
So
we're
I
mean
we.
We
need
to
to
make
sure
that
it
happens
by
the
end
of
the
year.
B
So
this
is
why
it
is
important
that
we
get
some
additional
reviews.
So
we
we
confident
we
we're
going
to
reach
that
goal
and
same
for
Registries.
We
would
like
that
to
be
sent
by
the
end
of
the
year.
I
guess
we
will
have
some
ad
words,
but
well.
The
idea
is
basically
that
all
the
Don
all
the
work
is,
we
will
be
done
by
the
next
ITF.
B
That's
we
don't
want
to
meet
for
the
next
ITF
I
think
that
should
be
the
message,
but
now
I'm,
maybe
giving
the
floor
to
Eric.
D
Yeah,
so
everything
the
responsibility
for
this
just
wanted
to
say
a
few
words
in
addition
to
the
image
sent
by
the
chairs
of
end
of
September.
As
you
know,
the
Arc
in
Rhythm
are
approved
from
calculation
for
changing
and
going
through
everything.
I
know
addressing
this
case
takes
time.
Thank
you
on
this.
D
I
am
waiting
like
we
said
that
the
old
progress
to
be
sure
that
they're
all
in
saying,
because
we
need
to
be
coherent,
so
good
news
for
the
arch
I
will
request.
Another
iitf-wide
last
call
because
there's
been
two
important
change
to
it
that
are
not
editorial
right.
In
section
402
3
there's
been
added
blockchain
in
addition
to
DNS,
so
which
is
a
major
change
and
the
other
one.
Another
major
change
was
replacing
DNS
over
TLS,
which
provides
only
privacy
by
DNS
SEC
that
provides
authenticity
and
integrity
right.
D
So
that's
major
change,
so
we
request
another
Last
Call
on
this
I.
Don't
expect
anything
bad
for
read
by
the
way.
I
would
need
to
send
an
email
on
the
mailing
list,
because
I
saw
that
in
Section
5,
when
we
do
the
reverse
DNS,
the
canonical
format
is
not
used,
so
two
IPv6
addresses-
or
it
can
end
up
in
the
same
name,
which
is,
of
course
not
really.
What
we
want
anyway,
detail
and
I
think
we
will
talk
and
get
some
news
about.
D
The
code
points
that
I
owed
right,
I'm,
not
sure
we
can
go
and
progress
to
the
IG
without
those
code
points,
and
we
may
need
to
do
some
document
surgery
or
whatever
I'm
there
to
help
but
I'm
kind
of
helpless,
though
on
this
one
yeah.
A
Eric
about
the
the
the
last
call
that
you
plan
to
to
issue
for
the
for.
A
When
do
you
think
that
that's
that
will
happen?
Oh.
D
It
will
I
mean
it
will
happen,
whatever
happens
to
oldness,
if
all
progress
right
within
one
month
or
two
months,
I
will
shift
together
because
it's
easier
for
the
people
doing
the
review
right
getting
the
edge
simply
for
this.
For
for
their
Leisure,
let's
say
for
their
comfort.
If
nothing
moves
on
old
and
right,
which
I
think
is
a
bad
scenario,
I
will
move
those
two
forwards.
Oh
then,
and
wait.
A
This
slide
is
a
focus
on
the
Registries,
so,
as
you
know,
there
is
a
proposal
to
to
split
the
the
content
of
the
current
Registries.
We
have
into
various
spaces
so
that
people
can
easily
digest
and
also
grasp
the
the
specification
it
is
really
I
would
say
for
me,
it's
a
good
risk.
Fraction
of
the
content
is
really
more
important
for
I
would
say
to
structure
this
aspect,
but
it
is
up
to
the
working
to
decide
whether
we
maintain
the
current
structure
or
we
go
to
this
account
proposal.
A
A
It
is
today,
but
the
editors
need
to
to
be
aware
about
about
this
and
not
deviate
from
what
we
have
at
least
agree
so
far,
and
the
other
point
that
we'll
discuss
also
during
this
lot
of
registration
is,
we
need
to
decide
where
to
to
send
the
other
documents
because
they
don't
believe
to
belong
to
to
the
drip
working
group.
So
there
is
some
I
would
say
some
Logistics
to
be
to
be
figured
out,
and
you
will
discuss
that
during
the
Adam's
laws.
A
There's
a
third
point,
which
is
really
procedural,
but
we
will
depend
on
the
you
will
need
an
approval
from
Eric
is
to
to
change
the
the
status
track
of
the
registration
from
proposed
standard
into
informational.
But
this
is
something
that
we
can.
We
can
discuss
Daniel.
B
Okay,
so
a
steam
I
I
can
contact.
So
we
send
an
email
and
to
contact
us
organizations
but
I.
Think
Adam
or
Stu
did
some
follow-up,
so
I
I
think
I
think
it
might.
It
might
clarify
Where,
We,
Are
and
and
what
are
the
next
step
to
to
be
done.
A
B
F
E
Yeah
I
I
had
just
like
three
slides,
which
I
had
uploaded
and
I
think
Med
has
approved
them.
Yes,
so
if
you
can
pull
them
from
the
data
tracker
or
whatever,
okay.
E
Okay,
so
there's
essentially
three
externalities:
there
are
what
are
The
Regulators
you're
up
to
and
what
are
the
other
standards
development
organizations
up
to
and
what
are
the
early
adopters
doing
so
we've
had
several
interactions
between
the
regulators
and
the
external
standards
development
organizations
that
have
affected
drip
since
IHF
114.
in
July
ASTM
published
f-3411-22a.
It
explicitly
acknowledges
drip
in
the
section
that
talks
about
session
IDs
there
used
to
there
used
to
be
three
types
of
IDs.
Now,
there's
four,
the
fourth
type
is
called
a
specific
session
ID.
E
So
This
only
affects
the
United
States,
but
it
describes
how
f-3411-22a
can
be
used
to
satisfy
the
FAA
regulations,
and
that
was
mostly
approved
by
the
FAA,
but
they
added
a
couple
of
additional
requirements
in
August
the
FAA
said
yeah
we
like
that
means
of
compliance,
but
you
need
to
have
tamper
resistance
and
there's
a
lot
of
pain
surrounding
that
one,
the
reason
being.
How
do
you
do
tamper
resistance
with
something
that
can
be
sold
profitably
for
49
at
Walmart?
E
E
I
filed
a
comment
now:
I
normally
don't
use
the
first
person
singular
pronoun
in
a
context
like
this,
but
I
made
it
very
clear
that
I
was
speaking
for
Stu
card,
but
informed
by
work
with
my
employer.
Ietf
drip
the
Air
Force
blah
blah
blah
and
pointed
out
that
if
you
run
the
drip
extensions
to
ASTM,
f-3411
you're
going
to
have
a
private
key
store
on
board
the
aircraft.
E
And
if
you
have
tamper
reactive
Hardware,
you
can
simply
wipe
that
and
that
will
achieve
the
faa's
purpose
more
effectively
and
at
a
lower
cost
than
putting
the
thing
in
a
titanium
can
also
in
October,
representatives
of
the
FAA
agreed
with
the
need
for
authentication
which
goes
beyond
f-3411
requires
you
know
what
we're
doing
in
drip
or
or
what
the
IEEE
is
doing
is
the
other
specific
session
ID
subtype,
and
they
unofficially
expressed
their
appreciation
of
what
we're
doing
in
drip
drip.
E
Really
needs
participation
from
folks
outside
the
United,
States
and
notice
the
whole
first
half
of
this
slide
is
what's
going
on
with
the
FAA
and
many
of
you
shouldn't
care
what's
going
on
with
the
FAA,
so
we
really
need
some
help
from
from
you
folks,
outside
the
U.S,
we're
going
to
need
probably
a
means
of
compliance
addendum
or
something
like
that,
showing
how
to
use
drip
in
addition
to
ASTM
f-3411
to
more
fully
satisfy
the
requirements
because,
as
I
mentioned,
when
the
FAA
said
yeah,
we
like
the
ASTM
thing,
it
was
with
a
yeah,
but
you
have
to
do
these
additional
things.
E
Presumably
our
basic
drip
document
set
consisting
of
requirements,
architecture,
the
identifier
which
is
Bob's
riddraft,
the
authentication
formats
and
protocols
which
is
atoms
major
draft
and
at
least
the
architecture
of
the
Registries.
If
we
go
ahead
with
that
that
restructuring,
interestingly,
there
are
folks
with
really
urgent
needs
for
remote
ID
and
so
before
we
have
FAA
or
any
other
caa's
blessing
of
any
rfcs
or
indeed
any
rfcs.
E
Actually,
beyond
the
requirements,
which
is
the
only
one
that's
been
published
so
far,
dtn
working
group
is
considering
whether
our
hips
fit
their
node
and
endpoint
identify
our
needs
for
at
least
some
cases
and
some
U.S
agencies,
which
I
am
not
at
Liberty
to
name,
but
they
are
big
ones
with
a
lot
of
money
and
a
lot
of
aircraft
are
conducting
field
trials
that
are
intended
to
rapidly
become
actual
deployments
of
drip
Daniel.
Could
you
put
up
the
next
slide?
Please.
E
Okay,
how
do
these
Drive
our
work?
Well,
the
asdm
document
and
the
rules
of
the
different
cias
already
drove
our
requirements,
which
drove
our
architecture,
which
is
really
closing
in
on
publication
as
an
RFC,
which
then
points
to
and
introduces
the
identifier,
the
authentication
formation
protocols
and
whatever
our
Registries
document
structure
proves
to
be
and
I'll
leave
that
to
Adam
to
talk
about
next
slide.
E
If
you
would
please
Daniel,
okay,
so
some
other
interactions,
somebody
in
ITF
I'm,
not
sure
who
I'm
not
sure
whether
it's
ESG
or
IAB,
wants
points
of
contact
from
Iko
and
istm
to
make
sure
that
this
whole
thing
isn't
just
bobbing
me
ranting
and
they
are
willing
in
principle
to
you,
know,
to
provide
those
points
of
contact.
E
Iko
wants
what
they
call
an
observer,
which
is
actually
a
full
participant,
but
with
no
voting
rights
in
their
new
trust
framework
panel,
which
is
for
all
of
Aviation
unmanned
aircraft,
manned
aircraft,
Airline
operation,
centers,
Air,
Traffic,
Control,
Towers,
the
whole
nine
yards
right,
they've
already
adopted
the
a
variant
of
the
drip
identity
entity
tag
as
one
of
their
identifier
formats,
so
Bob
and
Stu
Bob
and
Stewart.
E
Already
on
the
panel
and
the
first
meeting
will
be
in
Montreal,
and
we
really
need
somebody
to
represent
ITF
or
ITF
drip
not
be
Bob.
Not
me.
Astm
wants
Iko
to
act
as
the
registrar
for
remote
ID
types
and
code
assignments.
E
Fortunately,
our
drip
entity
ID,
is
already
burned
right
into
the
standards
document
itself,
and
it's
been
said
that
when
this
registry
is
stood
up,
entry
number
one
will
be
drip
and
then
the
specific
authentication
methods
there's
going
to
be
several
subtypes
and
we
need
at
least
three,
but
there's
no
process
yet
in
place
to
to
register
those.
E
Each
of
these
organizations
has
procedures
for
establishing
official
Liaisons,
but
those
procedures
take
time
and
we're
not
so
much
trying
to
establish.
You
know
ongoing
broad
organizational
relationships
or
trying
to
address
the
specific
issue
of
getting
our
Sam
codes,
and
so
ASTM
has
drafted
a
letter
which
is
still
in
a
STM
legal
review.
That's
going
to
go
to
Iko
to
officially
request
that
Iko
be
the
registrar
for
that.
E
Iko
has
unofficially
said
yes
already
as
soon
as
those
documents
are
mutually
signed,
so
that
there
is
a
registrar,
we
will
immediately
file
our
registration
paperwork
with
them.
We've
had
to
identify
some
informal
interim
points
of
contact,
So
Adam
for
drip,
because
the
authentication
draft
is
where
those
stem
codes
get
used.
E
Salo
de
Silva
who's
a
very
highly
placed
individual
at
Iko
headquarters
and
Gabriel
Cox,
who
chaired
the
ASTM
working
group
that
developed
the
remote
ID
standard
f-3411.
to
identify
an
appropriate
DNS.
Apex
we've
been
talking
with
the
appropriate
people
and
to
identify
an
appropriate
IP.
Prefix
we've
been
mostly
talking
amongst
ourselves,
but
informed
by
the
assignments
that
were
previously
made
for
hip
and
hip
B2.
So
anyway,
to
summarize,
even
though
drip
drafts
are
mostly
drafts
and
not
yet
rfcs,
we've
already
got
enormous
momentum.
D
Yeah,
just
please
stay
there
for
the
first
line
right
just
to
clarify
a
little
bit,
maybe
a
little
bit
fuzzy
there's
yet
in
general,
the
ieb
is
in
charge
of
all
the
liaison
right.
This
is
the
thing,
and
typically
the
isg
will
require
in
the
evaluation
that
all
those
check
has
been
done.
So
you
get
all
the
piece
together
with
somewhere.
We
say
it's
formal
yeah.
We
have
a
process,
but
it's
simply
an
email
in
the
case
of
the
ATF
IAB,
so
you
can
say:
hey
Eric,
blah
blah.
E
A
And
also
to
to
answer
to
the
first
point
you
have
in
the
slides:
it's
us
as
a
chairs
who
try
to
to
get
this
license,
because
we
have
a
problem
with
the
authentication
draft.
If
we
don't
have
allocations,
we
cannot
send
them
to
to
to
Eric.
So
that's
a
real
problem
in
the
process.
If
you
want
to
have
interoperability-
and
we
need
to
fix
this
anyway,
so
Jim-
please
yeah.
G
Generally,
just
a
random
Bozo
on
this
particular
bus
I
think
the
points
were
made
earlier
are
quite
valid
too,
that
we
probably
don't
need
to
have
a
formal
liaison
relationship
set
up
between
the
ITF
and
these
other
organizations.
Perhaps,
as
you
say,
a
non-voting
subject
matter
next,
but
see
a
designated
ITF
expert
to
potentially
serve
nuts
committee
and
I
think
something
as
simple
as
Eric
appointee,
or
stuck
key
with
probably
the
best
mechanism
for
that,
and
let's
not
get
too
tied
down
ideas,
setting
up
a
formal
reason
channel.
G
D
You
Jim
Eric
Derek,
zinc
again
and
like
you
who
to
partially
answer
you,
but
you
answer
yourself
to
what
you
said.
So
we
don't
need.
There
are
two
steps
for
liaison
liaison
manager,
which
is
some
guy,
which
is
there
for
many
years
and
then
don't
see
everything
we
have
different
3gpp
I3
poly.
It's
not
the
case
here.
I,
don't
think
so.
So,
since
simply
liaison
statements,
it's
simply
an
email
that
is
kept
forever
in
one
specific
place
in
the
web.
That's
what.
B
Yeah
I
mean
I,
mean
I,
don't
think
we
would
have
that
discussion
if
they
would
answer
to
our
email.
B
Actually
we
just
want
to
get
yes,
we
agree
on
that.
Yes,
we
will
have
those
count
points,
but
currently,
when
we're
trying
to
contact
them
with
an
email,
we
don't
get
any
response.
We
haven't
seen
any
response
so
well.
E
I
really
know
show
this
in
the
in
the
in
the
meeting
notes
or
anything,
but
one
of
those
guys
had
a
very
recent
change
of
employment,
which
has
muddled
things
a
little
bit
and
the
other
one
just
defended
his
PhD,
which
has
kept
him
rather
busy,
but
I'll
ping
him
again.
G
Just
one
final
point
on
this
to
meet
again:
whoever
is
going
to
serve
not
trusted
that
that
Fremont
panel
thing
you
were
talking
about
before
this-
they
will
not
be
speaking
for
the
ITF
or
representing
the
ITF
they're,
just
someone
from
the
ITF
who
can
advise
and
give
information
yeah.
A
A
F
B
Okay,
so
let.
F
B
H
H
Useless,
okay,
so
just
a
quick
update
to
touch
back
on
that
ASTM
and
ik
are
working
through
the
process
to
set
up
the
registry
for
the
code
points
for
the
Sam
types.
The
formal
letter
is
to
be
sent
I
contacted
Gabriel
earlier
in
the
week,
it's
through
their
legal
processing,
so
it
will
be
going
out
of
ASTM
soon
to
get
to
Iko.
H
Once
Iko
gives
the
official
confirmation
they
should
be
ready
and
we
can
just
send
the
email
through
Eric
or
Matt
or
Daniel
to
Iko
requesting
what
they
need
to
be
like.
Are
you
going
to
give
us
code
points
a
simple
yes
and
then
we
can
move
forward,
and
those
are
the
four
code
points
we're
looking
for,
link
wrapper,
manifest
and
frame,
and
the
Stu
said
we
at
least
need
the
first
three.
H
So
on
the
working
group
last
call
for
authentication.
There
was
no
substantive
reviews.
Medheads
put
some
issues
on
GitHub
for
me,
so
thanks
Med
I'm
going
to
be
working
on
those
at
the
end
of
this
week,
beginning
of
next
week.
So
there
should
be
a
dash
27
pushed
out,
hopefully
by
the
end
of
next
week
after
I've,
recovered
from
traveling
from
London
next
slide.
H
All
right,
so
we're
going
to
talk
about
the
hackathon
very
quickly.
Next
slide.
It
was
really
successful.
I
had
a
good
discussion
with
the
Liu
students
from
Andre.
They
were
all
remote.
We
found
some
issues.
I
did
a
very
quick
just
interrupt
bash
things
seem
to
be
working
just
barring
a
few
knits
they're
going
to
be
working
on
the
changes,
hopefully
during
the
week.
So
maybe
Andre
will
give
some
updates
on
that.
At
the
end
of
the
meeting
we
had
two
physical
attendees
Philip
and
Marius.
H
H
F
H
I
did
I
think
a
small
update,
push
right
at
the
end
or
right
after,
but
there
was
the
a
general
agreement
of
a
concept
in
114,
but
it
wasn't
formal
of
doing
a
split
as
we've
been
discussing,
but
a
dry
run
was
requested,
so
I
split
the
documents
through
them
in
an
email
threw
them
to
the
mailing
list.
H
Nothing
happened,
I
think
for
like
a
month,
I
waited
and
then
Bob
said
drafts
are
free,
put
them
in
the
data
tracker
under
a
personal
draft,
so
I
threw
them
in
his
personal
drafts
into
the
working
group.
There
were
no
comments
from
either
set
of
pushes
other
than
I.
Think
Bob,
plus
wanting
it
very
early
on
the
my
live
prototype
is
fast
tracking
these
documents.
It's
live
in
on
the
Internet,
it's
using
DNS,
it's
doing
all
of
its
good
things.
So
I
want
to
focus
today
solely
on
the
discussion
of
this.
H
You
know
splitting
of
the
documents
and
get
consensus
now
next
slide.
So
this
image
is
probably
familiar
to
you
from
114.
It's
a
bit
parsed
down
and
not
as
wordy
and
has
color
this
time.
H
So
this
is
the
general
architecture,
the
detm
architecture
and
each
one
of
those
arrows
represents
a
draft
that
is
currently
pushed.
There
are
five
documents:
the
denim
architecture,
the
DPA
HTTP
document,
the
registry,
HTTP
document,
the
registry,
Epp
document
and
the
DIA
rdap
document-
and
you
can
see
on
this
image
where
they're
located
in
the
whole
architecture
stack
next
slide.
H
So
the
datum
Arch
is
the
primary
document.
That's
going
to
I
think
affect
the
working
group.
It
replaces
the
registry
document
that
we
have
now
it
becomes
goes
from
standard
to
informational,
maybe
I'm
not
quite
sure.
We're
gonna
have
to
talk
to
Eric
and
get
working
group
consensus
on
it,
but
it's
the
primary
architecture
for
the
registration
and
lookup.
It
rips
all
of
the
implementation
details
out
and
says
these
are
in
other
drafts.
We
just
talk
high
level
models,
roles,
components
for
the
system.
That
is
it
next
slide.
H
As
I
said,
it's
a
copy
of
the
Registries
document
with
the
following
changes.
The
terminology
I
can
confirm
lines
up
with
the
current
version
of
architecture.
It
happened
at
the
end
of
work.
14.
I
made
sure
that
everything
was
lined
up
if
it
isn't
lined
up.
It's.
Maybe
one
word
here:
one
word
there
that
just
missed
a
control
find
replace.
If
that's
what
I
did
there
were
some
additional
sections
explaining
the
logical
components,
added
I
updated
the
attestation
to
endorsement
again
the
changes
for
definitions.
H
It's
also
been
moved
to
the
main
body
implementation
details
have
been
ripped
out.
We
may
need
to
tweak
text
here
and
there
that
might
be
broken
based
on
that,
but
for
the
most
part
it
read
fairly
cleanly
at
least
to
me,
and
then
there
was
a
new
Ayana
registry
put
in
for
some
value
stuff
for
registration
data
per
some
comments
from
Stu
now.
H
Overall,
this
makes
it
easier
to
parse
and
modulize,
as
Med
said
earlier,
so
I
as
the
author
and
I
believe.
The
editor
of
the
document
believe
that
this
is
a
great
move,
because
it
was
a
hard
time
in
114
of
the
guys
from
info
networks.
It
was
so
much
it
was
a
fire
hose
to
them
and
they
just
couldn't
grok
anything
and
it
took
hours
and
hours
and
hours
to
get
them
up
to
speed,
and
that
was
just
horrible.
So
hopefully,
this
fixes
a
lot
of
the
problems.
H
Let's
go
to
the
next
slide,
so
this
is
the
next
biggest
important
draft
that
probably
stays
in
the
working
group.
It's
the
drip,
provisioning
agent
document
and
it's
the.
If
we
looked
back
at
the
previous
diagram,
which
you
don't
have
to
go
back
to,
we
might
go
back
to
later.
It
was
the
red
arrow,
and
this
is
just
the
interface
between
clients
and
the
dime
inputs,
the
formatting,
all
that
good
stuff
I
hope
that
this
working
group
document
gets
adopted
or
the
document
gets
adopted
by
the
working
group.
H
H
H
Finally,
the
documents
to
move
to
the
working
group:
these
are
the
ones
that
I'm
not
really
sure
where
they
go,
the
registry
to
http,
Dia,
rdap
and
registry
Epp.
H
They
seem
to
be
better
suited
into
the
registry
extension
working
group,
but
it's
an
argument
of
do
we
give
it
to
them
and
they
work
on
it
and
I
travel
with
the
documents
to
give
guidance
for
the
use
case,
and
they
are
the
primary
authors
or
we
leave
them
here
and
bring
primary
authors
to
here:
I'm,
not
quite
sure
how
this
is
handled
and
where
the
work
lives.
So
we're
probably
have
to
discuss
this
next
slide
all
right.
H
So
these
are
just
some
open
issues
that
are
left
the
apex
of
the
DNS
tree
as
Stu
pointed
out
encryption
key
management,
which
is
kind
of
a
stretch
goal
in
a
way.
It
ties
into
Bob's
personal
draft
on
operator
privacy,
which
privacy
which
has
expired,
but
I,
know
based
on
my
work.
That's
the
next
big
item.
I
have
to
work
on
implementation,
wise
serial
numbers
for
non-drip
participants.
H
This
is
something
that's
been
knocked
around
by
the
authors
a
little
bit
and
then
finally
endorsement
just
definitions
they're
in
Json
right
now,
which
is
terrible
I'm
going
to
convert
them
to
cddl.
So
this
is
more
just
an
action
item
for
me
and
to
remember
next
slide.
Okay,
so
this
is
the
discussion.
So
those
are
the
big
major
questions.
Do
we
proceed
with
this
restructure?
Do
we
have
any
problem
with
the
names
and
the
Scopes?
What
do
how
do
we
adopt
denim
Arch?
If
we're
going
to?
H
Is
it
just
a
rename
of
the
Registries
document?
Is
it
just
a
push
of
the
Registries
document
with
the
content
completely
changed,
I,
don't
know
personally,
I
don't
care
as
long
as
we
agree
to
what
we
want
to
do
and
what
makes
it
life
easier
for
everyone
and
then.
Finally,
what
documents
stay
so
I
opened
the
floor
to
anyone
and
everyone
to
give
their
opinions
and
their
input.
Hopefully
we
can
reach
consensus
by
the
end
of
the
hour.
I
H
The
endorsement
dividends,
definitions
are
in
the
detm
architecture,
so
the
architecture
document
it
is
Section,
8,
I,
believe
of
the
personal
document
and
that's
where
they're
defined
the
structures
are
defined
and
just
generally,
what
goes
in
the
evidence.
What
is
goes
in
evidence
is
defined
in
other
documents.
The.
I
I
may
have
a
little
bit
of
a
problem
of
how
much
information
is
in
the
architecture
other
than
saying
these
things
exist,
but
in
terms
of
the
definition
of
content
that
may
be
problematic
having
that
in
in
architecture,
I'll
have
to
look
and
review
it
be
careful
here
because
our
because
that
may
be
getting
a
little
bit
too
much
detail
in
architecture.
So.
H
I
Out
yeah
defining
what
they
are
and
why
they
are
belongs
in
in
architecture,
and
that
is
there
now:
okay,
defining
their
Continental.
What's
in
them,
even
just
describing
the
elements,
all
that
belongs
elsewhere
elsewhere.
Okay,
that's.
G
Yeah
Jim
Reed
back
again
to
claim
I'm
just
speaking
for
myself
in
general,
I
think
this
is
a
great
step
forward
and
breaking
down
the
existing
documents
along
the
lines
you
suggested.
Adam
is
a
good
idea.
It's
much
more
modular,
it's
easier
to
understand
and
it's
easier
to
figure
out
how
the
bits
are
going
to
try
to
fit
together,
so
I
think
going
down.
This
way
is
probably
the
right
thing
for
the
working
group
to
do.
The
other
comment
I
had
to
do
is
about
the
potential
for
an
Epp
extension.
I.
G
Think
we
would
do
should
do
this
work
here
because
we'll
be
better
placed
to
I
know
what
the
requirements
might
be
and
then
eventually,
when
we've
got
something,
that's
reasonably
well
baked
chuck
it
across
the
road
to
the
to
the
regex
group
to
ask
them
for
any
final
comments.
But
since
all
we're
going
to
lightly
be
doing
is
adding
another
piece
of
XML
to
the
schema
I,
don't
think
it'll
be
a
big
problem.
There.
D
Is
the
ad
I'm
afraid
they're
really
paraphrase
or
repeat
what
Jim
said?
Indeed,
it
looks
like
it's
better
for
Martin,
easier
to
swallow
so
cool
and
for
the
extension
2p
spirit
is
only
an
XML
extension
stayed
here
right.
The
only
thing
we
will
do
the
working
group
last
score
forward
it
to
the
regex.
Okay,.
H
And
I
think
it's
important
because
the
architecture
document
was
well.
The
original
registry
document
was
so
big,
so
convoluted
that
we
had
everyone
me
Bob,
Stu.
Everyone
had
a
hard
time,
deconflating
things
we
kept
putting
things
in
buckets
that
we
shouldn't
have
and
I
think
this
will
clear
it.
So
now
it's
just
like
we
thought.
Oh
Epp.
We
have
to
change
everything
now
we
can.
A
Yeah
yeah,
the
only
point
I
would
make
as
a
chair
is
that
we
cannot
I
would
say,
carry
all
these
pieces
in
parallel
because
of
the
limitation
of
the
resources
we
have
so
I
and
I
need
to
discuss
this
with
Danielle.
We
are
not
planning
to
adopt
any
other
documents
rather
than
the
dim
architecture
itself.
So.
C
A
C
Hi
ajbl
Naval
Postgraduate
School,
just
kind
of
looking
through
the
the
architecture
and
the
mailing
lists
repo.
That's
there
there's
not
really
a
specification.
There
is
some
RF
link
that
advertises
this
and
I.
Don't
think
it
belongs
in
the
architecture
to
specify
it.
But
I
was
wondering
if
the
F,
you
know
the
FCC
or
equivalent
International
bodies
have
said
what
RF
frequency.
Oh,
this
would
advertise
on
Okay.
H
So
Stu's
laughing
that
is
not
defined
here.
It
is
defined
in
ASTM.
H
E
Yeah,
where
this
came
from,
is
it
the
faa's
aviation
rulemaking
committee
strongly
recommended
and
the
FAA
adopted
that
any
media
to
be
used
for
this
should
be
license
free
media
that
are
readily
available
to
any
citizen.
Astm
then
said
that
means
Bluetooth,
4,
Bluetooth,
5,
Wi-Fi,
neighbor
awareness,
networking
and
802.11
Beacon
and
others,
as
we
may
add
later.
H
H
Right
I
will
get
with
the
two
of
the
Eric
and
Matt
I
will
get
with
you
directly
after
this.
Let
me
know
what
I
need
to
do.
Well,
if
I
have
to
submit
what
whatever
you
want,
let
me
know
and
I
will
push
it
through,
probably
either
later
tonight
or
Friday,
so
that
it's
done
before
we
even
leave
London.
Okay,.
J
Good
so
I'm
happy.
J
Experiment
update
on
behalf
of
myself
and
our
students
at
Lynn,
Champion
University
Sweden
next
slide.
Please.
J
We
have
implemented
this
reference
architecture
which
is
partly
compatible
with
what
rippers
doing
at
the
moment
in
terms
of
broadcasting
messages
from
the
Drone
and
receiving
it
at
the
application,
and
we
also
have
alternative
implementation
of
registry
now,
which
is
based
on
blockchain,
which
might
be
something
interesting
for
working
group
in
future.
If
you
have
energy
to
specified
and
maybe
put
it
in
separate
draft-
but
next
please
so.
F
J
Mentioned
we
had
very
nice
preparation
for
this
IDF
in
terms
of
testing
our
mutual
implementations,
our
open
source
Adams's
proprietary.
So
we
had
also
some
success
in
hackathon
in
the
in
the
Sunday
to
to
identify
some
issues
between
our
different
implementations
in
our
Android
phone
and
also
in
the
drip
broadcast.
So
mostly
they
are
compatible,
but
we
identified
some
issues
which
are
now
being
resolved,
so
I
think
it
was
very
nice
and
thanks
Adam
for
for
joining
by
the
hackathon.
J
As
you
know,
Bluetooth
4
is
currently
mostly
used,
but
it
has
limited
range
so
and
Bluetooth
5
can
provide
reception
up
to
like
one
kilometer
from
from
a
flying
drone.
So
it's
we
are
working
on
also
adding
both
to
five
support,
which
is
a
bit
challenging
in
Raspberry
Pi
4,
because
some
drivers
are
not
so
up
to
date.
J
So
we
also
tried
some
external
dongles
that
we
can
connect
and
then
try
to
to
add
this
support,
and
also
in
Bluetooth
5
in
so-called
new
unit
of
computing,
which
is
Intel,
which
we
already
like
operating
and
testing,
but
Raspberry
Pi
is
still
in
in
progress.
Next,
please
and
our
application
for
for
Android
for
receiving
direct
data
is
in
progress
also,
so
we
used
open
drone
ideas
as
a
starting
point,
but
the
problem
it
was
requiring
Google
API
key,
which
is
requiring
credit
card
and
so
on.
J
So
we
could
not
really
publish
ready
packages,
but
now
we
switch
to
open
street
maps
version,
which
is
free.
So
now
we
have
on
the
trip
application
page.
We
have
ready,
APK
and
also
we
are
in
progress
to
Publishers
Google
Play
app,
which
unfortunately
requires
a
lot
of
questions
and
answers,
and
and
still
in
progress,
but
we
hope
to
finish
it
within
a
few
days.
J
J
Next
slide,
please
so
Hardware
we
use
the
Phantom
4
drone
as
a
starting
point
with
Raspberry
Pi
4,
and
then
this
battery
on
the
left
side,
as
well
as
GPS
receiver.
J
So
we
just
put
it
all
together
and
then,
as
always,
when
you
start
doing
things
in
recover
some
funny
stuff
like,
for
example,
the.
J
Antenna
was
completely
messing
up
the
Drone
system,
so
we
had
to
actually
remove
it.
But
if
you
put
the
next
slide,
we
actually
got
it
flying
as
you
see
on
the
left,
the
Phantom
drone
in
in
a
bag
carrying
the
complete
drip,
operational
transmitter,
which
has
a
GPS
support
and
Bluetooth
4
and
Wi-Fi,
and
as
you
see
on
the
application,
you
can
get
the
data
about
host
identity
tag
of
a
drone
and
also
the
coordinates
and
on
the
right
side.
J
You
can
see
our
back
end,
which
is
a
again
not
compatible
with
current
registry
draft.
But
it's
like
what
we
produced.
So
it's
some
kind
of
registry
where
you
you
can
register
your
drone
ID
if
the
public,
key
and
so
on,
which
can
be
used
like
remote
for
remote
queries,
see
like
what
is
the
public
key
of
a
drone
and
then
verify
the
a
veteran
identity,
and
actually
it's
Backward
Compatible
with
current
standard,
which
is
not
secure
prone
ID,
because
it's
kind
of
based
on
it
text.
Please.
J
Next
experiment
area
was
using
this
so-called
new
unit
of
computing,
which
is
basically
a
normal
PC,
but
it's
like
small
factor
and
it's
8
86
architecture,
which
makes
it
a
bit
easier
because
Raspberry
Pi
is
Arm
based.
So
it's
easier
to
get
like
more
up-to-date
drivers
on
this,
this
nuke
device
and
as
you
see
here
on
the
Matrix
digitron,
it
actually
integrates
fully
with
a
drone
in
terms
of
API.
So
it
gets
a
power
from
a
drone,
GPS
data
and
other
stuff.
J
So
we
have
this
nice
big
public
demo,
event
in
Sweden
by
valenberg
Foundation,
where
we
could
fly
this
drone
and
actually
test
the
range
of
ID
that
we
could
think.
At
that
time
we
had
only
Bluetooth
four
variables,
so
we
could
have
less
than
200
meters
range,
but,
as
I
mentioned
in
other
tests
in
Bluetooth
5,
we
could
have
about
a
kilometer
so
which
is
much
better
and
as
well.
J
We
contributed
to
open
Chrome,
ID
patch
developed
by
Intel
to
have
GPS
support
for
them
and
check
that
we
are
kind
of
Backward
Compatible
so
that
we
can
have
both
secure
and
insecure
drone
ID
received
on
this
on
the
same
app
and
same
same
device.
So
it's
work
working
well
excellent.
J
Also,
we
were
analyzing,
this
drip
protocol
with
a
tool
called
Tamarind
or
any
errors
in
security
specification
and
while
in
general
we
found
that
drip
protocol
is
all
secure,
except
we
identified
some
risk
for
replay
attacks,
which
we
plan
to
communicate
to
draft
coffers
to
see
if
there
is
anything
that
we
need
to
fix,
but
in
general
I
guess
it's
a
good
sort
of
support
for
protocol
going
forward.
As
we
know
with
TLS
latest
version,
we
had
also
full
verification
with
turmering.
J
And,
as
we
know,
drip
is
using
a
host
identity
protocol
for
generating
IDs
and
we
are
supporting
open
source
implementation
of
it.
So
there
is
a
patches
needed
to
implement
latest
draft,
such
as
hierarchical
heat,
support,
new
crypto,
like
hudiak
and
so
on,
and
also
we
likely
implemented
Docker
support
so
that
it's
easy
to,
for
example,
test
on
Mac
device
or
any
any
other
windows
or
device
which
doesn't
have
full
Linux
support,
so
welcome
to
download
it
and
try
on
your
your
own
device
next.
J
So
one
of
the
challenges
we
had
is
that
now
there
is
new
openssl
3.0
and
the
old
SSL
free
one
one
one
is
going
to
be
duplicated
in
a
year,
which
was
pretty
big
change
in
open
Heap
code.
So
we
have
the
to.
You
know
change
many
things,
and
the
current
status
is
that
the
code
is
compiling,
but
it's
still
pretty
Alpha.
So
it
needs
more
testing
and
more
verification.
But
since.
J
A
A
J
Yeah
well
to
to
fix,
replay
attacks.
You
need
some
kind
of
freshness,
freshness
and
nonsense
and
well,
if,
if
a
drone,
just
let's
say,
broadcast
hait,
it's
a
lot
of.
You
know
hard
to
just
record
it
and
broadcast
it
somewhere
else
right.
So
so
you
need
some
kind
of
maybe
what
query
report
protocol
it's.
You
know
Adam
had
this
picture
in
his
slides
about
sending.
E
Andre
is
still
here.
The
formal
analysis
that
you're
undertaking
is
that
on
the
protocol
or
on
the
implementation.
J
J
I
A
A
So
so
now
we
are
the
last
part
of
the
open
mic.
I,
don't
know
if
you
have
any
comments
or
any
questions
to
to
the
chairs
or
do
you
the
Ed
or
for
the
working
Queen
General
you
can
get
to
the
mic.
A
Okay,
if
there's
no
commentating
that
we
can,
we
can
adjourn
here.
So.
Thank
you.
Thank
you
for
attending
and
see
you
next
time
in
the
next
drape
session
and
thank
you
all
for
your
work.