►
From YouTube: IETF112-DRIP-20211111-1430
Description
DRIP meeting session at IETF112
2021/11/11 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
A
new
policy
that
asks
you
to
behave
properly,
so
I
don't
think
we
we
have
had
any
problem
in
the
past,
but
that's
some
something
we
have
been
asked
to
to
pay
attention.
So
basically,
trying
to
I
mean
try
to
be
always
professional,
try
to
be
impersonal
as
much
as
possible,
but
hopefully
this
is
a
which,
which
we
have
always
been
experimenting
in
that
working
group.
A
A
B
A
Anyway,
it's
it's
not
in
our
plate.
Now
we
do
have
a
document
I
wish
is
gonna
be
is
going
to
be
in
the
rfcq
by
the
end
of
the
year.
So
this
is
a
I
think.
Now
we
are
version
17.,
so
we
had
lately
some
tough
activity
on
that
to
me,
it's
really
the
one.
I
would
like
to
stress
the
people
to
get
focused,
so
we
can
finally
ship
that
one.
A
A
C
A
A
C
C
So
this
is
for
the
architecture
we
had
16
and
that
was
a
month
ago
before
the
meeting
most
comments
or
editorial
and
accounting
improvement,
and
we
have
lots
of
them,
but
it's
16
actually
trying
to
fix
fix
most
of
them.
We
had
a
few
of
the
leftovers
and
also
my
mistake.
I
have
to
say
that
I
phone
called
something
because
the
email
coming
from
different
places
I
just
easily
forget
but
anyway
so
16
actually
fixed.
Most
of
the
comment.
C
C
D
C
But
thank
you
so
much,
and
so
mostly
on
the
section
four
reflects
some
of
this
specific
requirement.
I
think
that's
one
of
the
comments
from
the
rookie
group
and
also
edited
two
new
sections
which
reflects
on
the
solutions
piece
we
had
on
the
trip,
which
is
one
of
the
trip
authentication
and
all
the
journal
content,
so
that
two
sections
already
in
16
and
17
is
also
a
little
bit
taxing
improvement.
C
C
A
A
C
Take
the
money
actually,
okay,
just
one
thing
I
want
to
just
I
actually
want
to
students
speak
up
a
little
bit.
Regarding
the
figure
thing,
we
need
a
consensus
with
the
group,
but
we
are
okay.
Then
that's
only
one
of
the
bigger
things
that
I
had
in
my
mind
regarding
the
figure
for
the
architecture
figure.
I
think
stu
has
a
really
good
a
nice
picture,
but
we
haven't
agreed.
We
want
to
put
on
the
architecture
draft
yet.
A
Okay,
so
one
comment
I
have
for
the
co-authors,
because
a
lot
of
discussions
are
are
between
the
co-authors
and
chairs
and
are
usually
copied
and
probably
not
all
other
people,
but
I
would
recommend
you
to
all
to
to
have
those
discussions
happening
on
the
mailing
list
so
that
everyone
can
see.
The
document
is
active.
At
least
some
people
are
exchanging
on
that
and
it's
not
something
that
is
being
discussed
in
the
back
exchange
or
behind
the
behind
the
door
and
imposed
to
the
working
group.
A
A
A
I
E
E
It
was
determined
that
it
was
too
complex
and
didn't
belong
in
requirements,
but
that
my
understanding
of
the
comments
was
that
it
did
belong
in
architecture.
Schweiz.
Understanding
of
the
comments
was
that
no,
it
was
just
plain,
too
complex
and
confusing
period
and
didn't
belong
in
either
the
documents.
E
So
I
has
mentioned
that
I'm
introducing
two
new
entities
here,
the
gpod
and
the
psod-
I'm
not
introducing
new
entities
at
all.
The
the
note
at
the
bottom
of
the
figure
explains
them.
If
I
put
the
words
general
public
observer
device
in
that
little
box
and
public
safety
observer
device
in
that
little
box,
then
this
figure
is
just
going
to
explode
in
in
size.
So
these
are
merely.
E
You
know
this.
This
is
a
macro
if
you
will
to
be
expanded
there,
and
this
is
a
macro
to
be
expanded
there
mentally
by
the
reader.
This
is
intended
to
show
the
full
picture,
because
nowhere
in
requirements
or
architecture
do
we
have
the
full
picture
of
what's
really
going
on
in
remote
id
that,
for
instance,
a
uas
consists
of
an
unmanned
aircraft
and
a
ground
control
system.
Sometimes
it
must
be
specifically
the
unmanned
aircraft
that
does
the
wireless
communications.
E
Sometimes
it
can
just
as
well
be
the
ground
control
station
so
anyway,
this
is
the
figure
that
we
are
proposing
to
show
the
big
picture
of
all
of
the
different
relationships,
except
specifically
over-the-air
one-way
broadcast
remote
id
broadcasts
which
go
to
anybody
in
range
and
would
hopelessly
complicate
the
figure.
So
that
is
the
proposal,
and
the
question
is:
do
we
want
this
in
architecture
or
do
we
not?
I
will
mu.
H
I
believe
that
everything
in
this
picture
is
in
architecture.
It's
often
not
too
clear.
Sometimes
we
say
it
could
be
the
ua
or
the
g
or
the
gcs.
When
we
talk
about
you,
the
uas
doing
something,
and
sometimes
we
talk
about
that-
the
server
needs
authorization.
Why
we
talk
about
deserving
authorization?
Well,
that's
because
it's
typically
a
public
safety
observer.
H
So
here
in
this
draw
picture,
we
do
expand
what's
in
the
text
and
maybe
with
this
picture
I
can
go
through
the
text
and
maybe
point
things
a
little
better
in
the
text
to
this
picture
to
relate
everything.
Clear
soi
has
done
a
great
job
in
getting
the
text
in
there,
but
I
think
this
tech,
this
picture
shows
the
whole
thing
and
that's
all
I
have
to
say.
C
I
C
F
E
A
C
C
I
think
there's
anything,
there's
something
new
from
the
figures
like
dea
everything
that
wasn't
my
original
concern,
which
is
not
in
the
drip
architecture
text
at
all,
but
I
think
stores
clarify
his.
He
will
do
something
editorial
to
make
sure
all
the
terms
were
released
to
the
architecture
trip
so,
which
is
great.
A
A
G
G
So
these
are
the
requirements
that
this
blockchain
should
satisfy.
They
are
mentioned
in
this
draft
requirements,
draft
which
is
now
submitted
for
publication,
so
possibility
to
do
public,
lookups,
private
lookups,
let's
say
from
authorized
officers
and
then
provide
authentication
and
the
provisioning
of
this
registry.
G
So
we
did
like
a
complete
implementation
of
a
system,
including
this
drip
protocols,
authentication
formats
and
also
the
blockchain
access,
and
that
try
to
do
some
scalability
measurements
like.
I
will
show
some
some
simulations
where
we
have
like,
let's
say,
100
drones
operating
in
in
one
area,
and
there
are
some
requests
to
the
system
just
to
see
like
how
scalable
it
is
in
practice.
G
So
about
the
architecture
of
the
system,
so
it's
a
quite
similar
picture
to
what
stu
has
showed.
So
we
have
vedron
who
broadcasts
messages,
an
observer
who
can
verify
this
authenticity
of
his
label
and
also
it
stores
them
to
this
iroha
blockchain
registry,
which
can
be
later
acquired
by
authorized
users
or
public
users
and
the
drones
directly
not
participate
in
the
in
in
the
blockchain.
G
Since
we
assume
that
maybe
we
don't
even
have
internet
connectivity,
we
just
sort
of
broadcast
using
bluetooth
or
wi-fi
messages,
and
this
is
the
summary
of
the
code
that
we
did.
So
this
authentication
part
is
based
on
open,
hip
implementation,
hip
version
2,
crypto
branch,
which
was
extended
to
support
things
we
specify
for
for
drip
such
as
c
shake
and
hierarchical
hits.
G
G
And
it
has
some
nice
features
like
multi-signature
transactions
and
smart
contracts.
So
what
does
it
give
with
multi-signature
transactions?
It's
possible
that
record
is
signed
by
several
entities.
So
if,
for
example,
ground
station
is
compromised,
it's
not
enough
to
compromise
the
whole
system,
but
also
need
to
compromise
with
drone,
for
example,.
G
Using
smart
contracts,
it's
kind
of
good
to
know,
so
it
keeps
track
of
who
actually
accesses
this
data.
So,
for
example,
if
some
officer
accessed
it
like
outside
of
his
duty
or
something
like
that,
it
could
be
later
tracked
and
verified
and
in
terms
of
performance
evaluation,
we
created
it
like
using
amazon
virtual
cloud,
so
we
were
running
a
few
euroca
notes
over
there
and
then
the
few
simulated
drones
for
submitting
its
like
broadcast
id
data
to
this
system,
and
then
our
users
feel
querying
this
information.
G
And
this
is
the
data
which
was
transmitted
so
coordinates
altitude,
speed,
timestamp
and
so
on.
What
is
now
required
in
eu
for
regulations
for
drone
id
total
123
bytes,
but
it
can
be
also
compressed
to
as
stsm,
which
is
much
shorter,
like
24,
bytes
and
obviously
the
more
data
you
transmit,
the
more
hungry
it
will
be
for
blockchain
storage.
G
And
here
are
some
features
so
like,
for
example,
here
is
16,
blockchain
notes
and
hundred
drones,
and
we
are
sending
some
updates
and
queries.
So
you
can
see
it's
pretty
reasonable
performance,
so
few
hundred
milliseconds
max
for
for
these
queries
and
also
variability
presence,
but
still
like
moderate.
G
So
that's
basically
it
so.
To
summarize,
we
have
a
code
for
drip,
authentication
part
and
for
also
for
blockchain
storage
part,
it's
currently
over
a
bluetooth
four,
but
we
are
extending
to
bluetooth
five
and
also
to
wi-fi
neighborhood
awareness
mode,
which
maybe
is
now
being
replaced
by
something
else.
Like
bob
mentioned
and
yeah,
we
hope
to
have
a
complete
prototype
with
flying
drone
being
tested
end
of
year.
So,
if
you
have
any
questions,
please.
A
H
Okay,
so
let
me
get
going
here,
changes
since
the
last
ietf,
which
was
version
eight
we're
now
on
version
13.,
so
that
we
have
a
name
change,
we're
now
calling
these
grip
entity
tags,
which
ties
in
nicely
with
what
astm
is
calling
things.
We
call
these
entity
tags,
which
is
the
uaa
name
for
hierarchical
hits.
H
H
H
H
So
what
if
that
module
manufacturer
wants
to
use
grip?
How
can
they
do
that?
Here's
a
way
to
map
the
hierarchical
hit
into
the
the
2083
format,
so
they
can
comply
with
the
faa
requirements
and
still
then
take
full
advantage
of
everything
that
we've
done
here.
That
is
the
purpose
of
this.
The
principal
purpose
of
this
section,
the
privacy
section
dt
privacy,
section-
has
been
added,
or
perhaps
I
should
say,
the
lack
of
privacy
because
you
are
on
open
broadcast
media.
H
I
hope
I
I
have
done
a
good
job
of
this.
I've
not
gotten
a
review
by
anybody
in
the
ietf
on
this.
I've
asked
over
in
the
the
privacy
work
research
group,
no
response
yet
from
them,
and
the
security
consideration
section
has
been
expanded,
particularly
the
second
image
attack
possible
with
modern
custom
asics.
Thank
you
for
cfrg
for
some
response
on
this,
but
working
more
with
cfrg
to
see,
if
there's
anything
else
I
need
to
have
here.
H
One
thing
that
this
indicates
is
how
important
the
registration
process
is,
because
there
is
a
attack
and
this
a
loss
of
trust.
If
we
don't
have
the
registration
so
adam,
and
I
will
next
be
working
on
the
registry
draft,
we're
rolling
up
our
sleeves
on
that
with
everybody
else
who,
with
assistance
on
that,
that's
why
the
two
of
us
want
to
finish
drip
rid
and
drift
off,
so
we
can
focus
on
drip
registries.
H
H
I
feel
now
at
this
for
this
point
I
am
done,
except
for
fine
tuning
people
may
take
some
issues
with
the
dns
examples
formats.
Those
are
malleable
you
can
if
people
want
different
ones,
we
can
deal
with
that,
but
I
think
that
this
this
document
is
now
complete
and
it
is
ready
for
workgroup
class
call.
H
D
D
D
F
F
F
D
Could
be,
I
mean
some
of
the
some
of
the
use
cases
for
rats
are
aimed
at
things
like
mobile
devices
or
hardware.
Two-Factor
authentication
tokens
that
kind
of
thing
where
the
entity
manufacturing
producing
and
distributing
the
the
physical
endpoint
is
not
necessarily
the
entity
with
whom
the
user
has
the
operational
relationship.
H
D
H
D
D
H
No,
we've
been
looking
more
at
reg
extensions
for
the
registration
process,
that's
where
most
of
our
attention
has
been
and
you
and
looking
how
epp
could
be
leveraged
for
for
that,
but
definitely
I'll
I'll
go
back
to
look
at
rats
again.
I
was
at
the
beginning
of
it,
but
stepped
away
from
it,
and
maybe
I
can
rattle
hank's
rat
cage
and
get
something
from
him
on
it.
Right.
E
D
F
Okay,
I'm
going
to
transition
to
my
slides
so
because
I
have
15
minutes
to
go
through
all
of
this.
So
this
is
the
authentication
formats
it
was.
Obviously
there
was
a
name
change,
so
change
in
since
01
when
it
was
adopted,
we've
gotten
a
new
title,
much
like
bob's
draft.
I
rearranged
a
lot
of
sections
for
some
clarity.
F
I
followed
bob's
example
removed
f3411-19,
explicit
references
and
just
use
f
3411,
because
the
draft
very
much
lines
up
with
the
in
ballot
or
soon
to
be
invalid,
f3411
and
then
some
high
level
overviews
section
3.3
was
updated.
I
reordered
some
formats.
There
was
a
new
operational
recommendations.
Added
and
appendices
got
shifted
all
around,
so
the
section
3.3
rework
at
a
high
level.
It's
still
an
overview
of
the
current
astm
authentication
message.
F
It
was
reworked
massively
to
make
it
clear
but
remain
abstract
due
to
the
licensing
copyrights
of
the
astm
document,
because
you
have
to
pay
for
it.
We
cannot
just
blindly
copy
paste
in
so
I
have
to
abstract
away
some
stuff
and
abstract
the
not
the
concept,
but
a
lot
of
the
fields
I'll
go
into
more
detail
on
the
f34
v
1.1
specific
changes
that
were
made.
We
have
a
new
constraint
section
which
I'll
go
into
and
f3411
v1.1
is
revaliding.
As
bob
said
later
this
year.
F
So
specific,
f,
v
1
1
changes.
First
off
there
was
the
inclusion
of
a
new
authentication
type
called
sam,
the
specific
authentication
method
and
it's
a
means
to
add
authentication
formats
after
3411
was
published
because
of
the
process
to
publish
the
document.
If
someone
came
with
a
new
authentication
method
or
type,
it
would
mean
changing
the
standard
pulling
the
working
group
together,
rebalancing
sending
it
it
would
just
take
too
long.
F
This
is
now
there's
one
authentication
type
and
there's
a
byte
at
the
very
start
of
the
authentication
data
taking
away
a
byte
that
we
could
use
that
multiplexes
and
that
bite
has
been
decided
by
astm
to
be
maintained
by
icao.
The
international
civil
aviation
organization,
and
so
the
working
group
will
need
to
submit
a
request
for
some
values
in
this
field.
They're
going
to
follow
very
similar
field
requests.
Much
like
ayanna.
F
The
other
addition
change
that
was
massive,
was
the
additional
data
length
and
additional
data
field.
These
are
more
pseudo
fields,
because
we
have
now
all
16
pages
available
to
us
on
the
authentication
message,
but
only
a
subset
of
them
can
be
actually
used
over
broadcast
due
to
media
constraints
which
I'll
get
into
later.
F
So
this
field
is
where
we
put
our
forward
error
correction,
and
so
the
figure
on
the
right
you
can
see
is
excerpts
from
the
draft
as
it
is
now
so
figure.
One
is
a
page
of
authentication
and
figure.
Two
is
the
layout
of
the
fields
found
across
those
pages
and
the
last
figure.
The
very
bottom
figure
is
what
happens
when
the
sam
code
isn't
placed
into
it
because
we're
off
type
five,
so
you
can
see
where
the
fec
would
be
and
where
all
the
data
would
be.
F
So
the
forward
error
correction,
because
that
was
changed,
it
used
to
be
an
appendix
it
was
pulled
up
into
the
main
draft.
It
was
retooled
to
use
the
additional
data
field
and
I
reworded
a
lot
of
the
text
to
make
it
clear.
There
was
some
redundancy
in
multiple
places
across
the
document,
so
that
redundancy
was
removed
and
it
drove
a
bit
better
of
a
constraint.
F
Okay,
thanks
ben,
so
fec
was
aligned.
We
need
to
fec
page
align.
We
need
to
do
read
solomon,
potentially
with
multi-page
fec,
because
now
we
can
do
it,
and
there
was
some
discussion
between
the
authors
about
doing
something
with
more
than
off
the
broadcast.
Anticipation
structure
is
another
section:
it's
brand
new,
well
kind
of
new,
but
it's
been
modified.
It
fits
within
the
sam
authentication
data.
The
signing
timestamp
was
removed
by
me
in
the
last
revision.
F
There
was
some
back
and
forth
between
the
authors
on.
If
this
is
really
what
we
want
to
do,
because
it
was
kind
of
an
ad
hoc
change,
it
will
either
be
re-added
or
stay
removed.
Importantly,
this
structure
is
what
gives
us
self-attestation
of
the
det
and
it
confirms
possession
of
the
key
asserted
by
the
broadcast
attestation,
which
is
in
the
drip
link
message,
which
is
the
attestation
that
comes
from
the
registry
process.
F
There
are
lots
of
broadcast
attestations
potentially,
do
we
send
them
all?
Do
we
only
send
a
subset
of
them?
A
link
type
was
added
to
multiplex
against
these,
because
we
aren't
at
the
200
byte
limit,
so
losing
a
byte,
but
we're
only
four
pages
in
is
kind
of
whatever
appendix
b
has
an
example
of
this.
F
F
The
big
takeaway,
if
you
take
anything
away
from
as
I
speed
through
these
slides,
is
the
drip
link
plus
the
manifest
together
gives
us
the
trust
we
need,
because
we
take
the
drip
blink,
which
tells
us
what
we
do
tells
us
that
the
key
can
be
trusted
because
of
the
registry
and
then
the
manifest,
because
it's
dynamically
signed
by
the
aircraft
validates
the
ownership
of
that
key.
That
was
asserted,
and
there
is
some
text
on
having
to
send
the
drip
blank,
but
also
send
some
dynamic,
dynamic
data.
F
The
drip
frame
is
another
thing,
it's
more
for
future
proofing,
so
I
won't
go
too
much
into
it.
It
might
need
a
rename
there's
a
recommendations
and
requirements
section
that
has
all
the
recommendations
and
requirements
for
drip
to
be
run.
This
is
where
again,
we
get
the
assertions
and
the
recommendations
to
send
the
other
link
messages.
F
Operational
recommendations
needs
to
get
reviewed
and
dependencies
got
moved
all
over
the
stuff
over
the
place.
This
is
a
new
appendice
that
I
need
to
make
and
fix
them.
And
finally,
the
to-do's
bob
has
some
things
he
wants
to
look
into.
Fec
needs
to
be
cleaned
up
and
fixed
the
manifest
window.
Operational
recommendations
needs
to
be
reviewed
and
possibly
expanded.
F
D
A
F
For
questions
yeah,
I
gotta
keep
going.
I
gotta
keep
going
so
four
four
registries,
if
you
have
questions,
send
it
to
the
list,
please
so
for
registries
since
zero
zero,
it
expired,
I
fixed
it.
I
brought
it
back
up
it
expanded
from
11
to
36
pages.
The
attestations
that
were
in
auth
are
now
in
registries,
so
bob
might
actually
have
to
change.
Saying
he's
looking
at
auth
instead
look
at
registries
and
then
I
started
doing
some
stuff.
Overall.
This
is
a
mess,
because
this
is
literally
all
my
notes.
F
All
my
thoughts,
bob's
thoughts,
stu's
thoughts
all
thrown
into
the
draft
and
trying
to
give
some
order.
So
it's
a
nightmare.
Please
try
to
rock
it
as
best
as
you
can.
Some
texts
were
borrowed
from
drift
drafts.
Other
drip
drafts,
the
definitions,
claims,
assertions,
attestations
and
certificates
section
is
in
three
places.
Now
I
don't
like
things
being
in
three
places.
We
should
probably
select
where
it
lives
forever.
F
F
F
F
F
The
dns
records.
I
have
a
list
of
the
dns
records.
I
propose
that
we
will
probably
be
using
and
the
justification
for
their
use
and
some
specific
ns
records
that
are
needed.
That
I
found
as
I
began
my
implementation
and
then
there's
a
whole
section
about
registry
operations.
It's
basically
section
9
trying
to
become
technical
instead
of
pros
it's
a
mess.
F
F
It's
a
rough
http
api
to
register
all
the
different
entities
that
I
mentioned
before
it
manually
updated
dns
zones,
but
it
took
like
four
months
because
of
a
lot
of
other
things
that
were
happening,
but
the
good
news
was
in
the
past
two
months:
we've
been
transitioning
and
doing
stuff
with
epp
and
rdap.
Much
like
the
architecture
said
we
probably
should
be
doing
so.
We
have
been
working
on
that.
I
have
some
xml
tag:
definitions
that
probably
have
to
be
into
the
draft
for
iana
considerations
and
rdap
is
starting
very
soon.
F
So
next
steps
on
registries,
I
have
to
refine
section
4.
section.
8
needs
a
lot
of
help,
because
it's
just
a
just
a
wall
of
text
that
is
badly
organized.
We
need
to
clean
up
and
refine
the
revisioning
process,
which
kind
of
aligns
with
section
8.-
it's
very
us
centric.
So
we
might
want
some
eu
inputs.
F
We
need
to
do
epp,
rdap
stuff,
and
then
we
need
pii
protection
to
protect
the
serial
number
and
other
things.
So
my
plan
is
to
work
with
bob
extensively
to
do
the
x,
509
stuff
that
he,
I
think,
has
in
the
pipeline,
and
this
draft
is
very
important
as
it
supports
not
only
dash
off
and
is
referenced
by
uas
rid.
It
also
supports
operator
privacy,
potentially
another
draft
by
bob.
So
the
question
is:
when
do
we
want
to
adopt
this
document?
It's
gone
in
and
out.
It
was
said
for
many
months
that
we'd
do
it.