►
From YouTube: IETF108-DRIP-20200730-1410
Description
DRIP meeting session at IETF108
2020/07/30 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
Yeah,
I
think
we
we
can
start
so
we
will
come
up
for
for
joining
this,
the
drape
working
out
meeting.
So
this
is
the
network,
so
make
sure
you
are
familiar
with
this
with
the
network.
So
if
you
have
any
clarification
questions
you
please
don't
hesitate
to
to
raise
them
the
four
for
the
logistics,
so
we
have
a
shui
who
will
take
care
of
taking
the
minutes.
The
the
pointer
is
there
as
we
are
using
mythical.
A
There
is
a
list
of,
I
would
say
the
the
control
tabs
that
you
you
can
use
to.
I
would
say
to
to
ask
to
put
yourself
on
the
queue
or,
if
you
want
to
to
share
your
dvd
and
so
on.
So
please
yeah
make
sure
that
you
are
following
the
those
ones
the.
As
for
the
objective
of
this
of
the
days
meeting
we
have
at
least
here
so
the
we
have
two
objectives.
A
The
first
one
is
to
make
sure
that
the
I
would
say
the
the
various
review
that
we
received
from
the
since
the
last
infrared
mate
in
our
address
and
to
to
have
an
overview
of
the,
I
would
say,
depending
issues
that
need
to
be,
I
would
say,
considered
by
the
the
authors
of
of
the
requirement
draft
and
also
the
architecture
one
and
the
the
the
I
would
say
the
the
other
objective
is
to
make
sure
or
at
least
to
assess
whether
we
are
ready
to
to
for
the
to
launch
the
working
class
call
for
the
requirement
and
for
the
architectural
documents,
as
you
may
know,
so
we
have
the
the
milestone
for
this.
A
One
is
for
july.
We
need
to
to
make
to
have,
I
would
say,
an
assessment
from
the
authors,
but
also
from
the
working
participants,
whether
we
are
ready
or
not
yet
for
for
those
ones.
So
these
are
the
two
objectives
we
have
we
have
for
the
meeting.
So
that's
why
we
have,
I
would
say,
the
first
half
of
the
meeting
that
will
be
dedicated
to
the
requirement
and
to
to
the
architecture.
A
So
stewart
will
be
on
the
floor
to
to
present
us
the
the
recent,
I
would
say,
progress
that
was
made
on
this
on
this
third
documents,
and
this
time
we
are
scheduling
the
the
solution
discussions
so
we'll
have.
We
have
four
talks,
the
because
we
will
also
to
to
prepare
to
do
the
working
of
work
on
this
solution
once
that
will
be
for
for
september.
A
So
this
will
be
an
ignite
of
the
secretary
of
the
discussion
about
the
dissolution,
and
then
we
have
the
the
the
closing
part.
So
unless
there
is
any
version
on
the
on
the
agenda
as
such
as
we
we
proceed,
we
with
this
one
any
in
a
comment
to
that
to
the.
A
A
B
A
B
All
right,
so
this
is
a
set
of
slides
with
a
general
update
as
context
and
then
jumping
into
requirements
primarily
and
then
into.
C
B
How
about
now
great?
Thank
you.
Okay,
anyway,
a
little
bit
of
a
general
update
on
context
focused
primarily
on
requirements,
which
is
the
more
mature
of
the
two
drafts
and
then
a
little
bit
on
architecture,
which
is
far
less
mature,
and
I
finally
figured
out
just
today
the
conceptual
problem
that
I've
been
having
adapting
to
ietf
culture
on
what
is
architecture
in
in
this
this
context
and
more
more
on
that
in
a
minute.
B
What
we
had
just
adopted
in
the
space
of
the
last
month
is
icaos
international
civil
aviation
organizations
terminology,
but
astm
also
has
a
terminology
document,
so
we
want
to
look
at
that.
Excuse
me
also
from
the
faa.
Now,
admittedly,
this
is
just
u.s
only,
but
it
is,
I
believe,
representative
jay
merkel.
The
executive
director
for
the
u.s
uas
integration
office
in
faa
has
said:
there's
many
areas
where
network
coverage
is
not
available,
and
this
is
why
we've
included
a
broadcast
mode.
B
This
really
confirms,
in
my
opinion,
that
broadcast
rid
authentication
cannot
depend
upon
observers
having
internet
connectivity
in
the
field.
Also,
the
drone
advisory
committee
has
put
out
comments
on
the
utm
conops
version.
2.0
and
they've
basically
suggested
crowdsourced
rid,
although
they
didn't
call
it
that
the
icios
aviation
trust
framework
study
group,
their
prototype
certificate
authority
began
issuing
certificates
and
a
use
case
for
digital
identifiers
for
all
aircraft
has
been
drafted
in
the
trust
reciprocity
operating
needs
working
group
for
consideration
by
the
digital
identity
working
group.
B
These
are
all
ikl
working
groups
and
in
various
memos
from
various
government
agencies
with
limited
distributions.
Surprise
surprise:
having
looked
at
the
regulations
that
are
coming
from
the
civil
aviation
authorities,
they
really
want
to
maximize
their
surveillance
of
other
people
but
minimize
their
surveillance
by
other
people,
and
they
likewise
have
suggested,
but
not
by
our
name
of
crowdsourced
grid,
essentially
crowdsourced
grid.
B
An
outfit
called.
The
att
foundry
recently
published
10
bold
projections
on
the
future
of
drones,
and
I
would
just
like
to
call
your
attention
to
their
first
and
their
10th
prediction
that
drones
will
enable
dynamic
communications
networks
and
secure
internet
of
things.
Platforms
will
catalyze
widespread
adoption
of
drones
all
right.
B
The
things
that
are
on
here
are
things
that
we've
been
reporting
on
at
each
of
our
ietf
and
interim
meetings
and
closely
related
topics,
the
things
that
are
in
green-
and
I
apologize
to
any
of
you
who
have
red
green
color
blindness,
but
it's
the
first
one,
two
three,
four
five
six
bullets
are
things
that
are
in
good
shape,
the
things
that
are
in
black
the
next
one,
two,
three,
four,
five
five
and
a
half
bullets
are
things
that
are
moving
along
they're,
not
in
great
shape,
but
I
wouldn't
say
that
they
are
particularly
behind
or
critical
and
then
the
last
one
and
a
half
bullets
are
things
that
are
areas
of
concern.
B
For
me,
we
need
to
get
on
the
use
cases
for
observer
to
pilot
comms
and
the
if
you
will
anti
use
cases
for
observer
to
pilot
comms,
and
we
need
more
help
tracking
what's
going
on,
especially
in
europe,
because
there's
a
lot
of
players
doing
a
lot
of
things
that
affect
this
summary
of
activity
in
the
working
group.
Since
our
last
interim
we've
had
some
promising
discussions
with
domain
registration,
experts
and
michael
will
talk
about
that.
B
We've
had
a
tremendous
amount
of
activity
in
the
international
civil
aviation
organization,
where
a
drip,
related
and
hip-based
approach
to
an
identifier
for
all
aircraft
and
potentially
for
many
aviation-related
ground
nodes
is
getting
support
within
iko
solo
has
provided
some
documents
that
have
enabled
us
to
get
our
definitions
in
accordance
with
those
of
our
user
community
we've
had
some
productive
back
and
forth
discussions
of
clarification
on
the
astm
f-3411
standard
with
those
folks.
B
The
ansi
roadmap
for
standardization
now
includes
ietf
thanks
to
bob,
and
I
have
addressed
most
of
the
inputs
on
the
requirements
and
architecture
document
from
all
those
folks,
but
not
all
of
it.
Yet.
Oh
requirements
summary
of
changes.
There
were
a
lot
of
editorial
comments
and
and
minor
issues
of
content
from
eric
daniel
med,
amelia
sue,
schwei,
ryan
and
most
of
those
have
been
addressed
some
of
them.
I
still
especially
the
editorial
ones.
B
Some
of
the
nits
I
still
need
to
get
to
there's
been
a
considerable
amount
of
explanatory
pros
added,
because
a
lot
of
the
itfers
are
not
deep
into
aviation
in
general
or
unmanned
aircraft
systems
in
particular,
and
so
there
was
a
lot
of
need
for
context
and
in
particular
the
term
immediately
actionable
was
unfamiliar
to
a
number
of
people,
so
that
has
been
explained
at
length
by
immediately
actionable
we're
not
talking
about
the
standards
process.
We're
talking
about
the
information
received
through
unmanned
aircraft
systems,
remote
id.
B
Privacy
and
transparency
is
the
main
issue
that
we've
been
addressing,
which
are
on
the
next
three
slides
and
then
the
last
slide
is
open
issues,
so
privacy
and
transparency
we've
got
a
new
section
in
requirements,
draft
03
motivated
by
comments
in
our
boss
session
and
in
our
first
meeting
during
the
previous
ietf,
and
we
got
a
lot
of
good
input
recently,
thanks
to
a
variety
of
people,
especially
amelia.
B
B
The
privacy
and
transparency
considerations
section
is
kind
of
like
an
iana
considerations
or
security
considerations,
and
it
supplements
the
actual
numbered
requirements
about
privacy
which
we'll
talk
about
in
the
next
two
slides.
I'd
like
to
stop
for
just
a
moment
to
ask:
did
anyone
participate
in
the
pidlock
side
meeting
and
is
there
anything
coming
from
that
direction?
That's
going
to
be
in
time
for
us.
D
Okay,
we
can
come
back
that
later
yeah
stu,
no,
not
nothing
from
pidlock.
E
A
Yeah
the
number
two
so
please
before
we
move
to
the
next
slide,
I
would
like
just
to
to
make
a
pose
on
the
on
the
previous
one
to
to
ask
emily
if
she
she
had
time
to
look
into
the
the
new
version
and
if
she
she's
happy,
I
would
say,
with
the
modifications
that
were
made
on
that
on
the
recent
version
of
the
draft
emilia.
E
B
Okay,
so
privacy
requirement
two
encrypted
transport.
The
top
paragraph
here
is
the
way
it
is
written
in
revision,
three
of
the
requirements
draft
and
I
apologize.
I
was
guilty
of
solution
space
thinking
in
a
requirements.
Document
bob
has
made
two
suggestions
for
changes.
The
first
one
is
that
we
strike
the
phrase
end
to
end,
which
he
suggested
may
lead
us
down
a
rat
hole
of
defining.
What
are
the
ends?
B
I
don't
know
I
kind
of
hate
to
drop
that
qualifier,
but
I
I
grant
that
he
is
right.
It
does
create
a
question
of
defining
what
is
the
end.
His
second
suggestion
avoids
my
unfortunate
solutions
based
thinking,
but
also,
unfortunately,
emits
the
point
about
safety.
B
What
this
is
all
about
is
the
the
so-called
system
message:
transmits
the
location
of
the
pilot
or
and
the
ground
control
station,
and
that
means
that
in
the
clear
anybody
who's
got,
a
bluetooth
or
wi-fi
receiver
can
find
out
where
a
pilot
is
and
go
harass
them,
which
is
not
desirable.
However,
public
safety
and
security
personnel
need
to
be
able
to
get
that
information.
B
B
My
solutions
based
thinking
was
well,
you
know
if
the
aircraft
is
doing
network
as
well
as
broadcast
id
and
it's
not
getting
axe
on
its
network
id,
it
needs
to
stop
encrypting
its
broadcast
id,
because
if
the
aircraft,
with
the
advantage
of
height
of
its
antennas,
can't
get
to
the
internet,
then
some
guy
on
the
ground
who's,
you
know,
surrounded
by
trees,
isn't
going
to
be
able
to
get
to
the
internet
either.
B
B
B
We
got
a
little
bit
outside
the
iatf
swim
lane
here,
but
at
the
same
time
we
wanted
to
encourage
appropriate
behavior.
So
we've
we've
weakened
this
to
drip,
should
facilitate
selective,
strong
encryption
of
private
data
at
rest
in
such
a
manner
that
only
authorized
actors
can
recover
it
and
then,
in
an
explanatory
note,
for
that
number
requirement,
not
the
text
of
the
numbered
requirement
itself.
We've
said
how
the
information
is
actually
stored.
On
the
end
systems
is
out
of
scope,
but
encouraging
privacy
best
practices,
including
end
system
storage.
B
A
Yeah
before
we
discuss
this
point,
I
prefer
we
we
go
back
to
to
the
previous
one
that
you
have
mentioned
with
the
motivation
and
to
see
if
there
is
any.
I
would
say
any
further
comment
from
the
the
participant
any
any
input
or
any
comments
about
the
the
the
current
one
from
the
the
audience.
E
F
E
Yeah,
I
ordered
this
to
punt
to
a
solution
which
then
does
it
that
it's
this,
the
caa,
which
will
be
setting
policies
and
the
solution
would
have
to
implement
it.
Of
course,
I'm
biased
because
I
do
have
such
a
solution
proposed,
so
I
I
am
coming
from
it
from
that
direction,
so
I
would
like
obviously
like
other
people
to
say
whether
I
got
it
or
not.
With
this.
I
think
this
is
I
I
like
my
wording,
but
we
can
add
a
word
about
safety
in
here,
but
this
is.
B
E
Yeah
now,
how
do
I
drop
the
out
of
the
key
out
of
the
advocate?
Get
troubling
like.
E
B
So
because
I'm
sharing
my
slide
screen,
I'm
not
looking
at
all
the
you
know
rest
of
the
meat
echo
stuff.
So
I
don't
know
if
anyone
is
in
the
cube
to
speak.
A
There
is
no
one
currently
on
the
on
the
cube,
but
there
are
some
comments.
I
said
you
on
the
on
the
on
the
chat,
so
the
dress,
I
would
say,
people
who
agree
that
there
is
a
need,
it's
good,
to
define
the
the
ants
when
we
are
talking
about
end
to
end.
A
So
I
think
it's
that's
it's
good
to
at
least
to
define
that
what
you
mean
by
the
ants
when
we
are
talking
about
anti-hands-
I
don't
know
if
alex
or
jonathan,
if
you
want
to
to
to
to
make
your
your
comment
on
the
mac,
you
can
make
it
if
you,
if
you.
G
G
Yeah,
I
I
don't
quite
understand
why
there's
a
particular
difficulty
in
defining
or
why
there's
an
objection
to
defining
the
ends
that
we
that
it
might
be
difficult
to
have
a
like,
reliable
definition
of
the
ends
is
not
doesn't
mean
it
wouldn't
be
useful.
G
G
A
We
can
move
to
the
next
slide
and
then,
if,
when
alex
is
back,
we
can
give
him
the
to
speak.
So
stewart
please.
B
So
the
next
one
again
was
the
encrypted
storage
requirement,
and
I
I
would
like
to
get
a
sense
for
whether
we're
now
satisfied
with
the
text
for
private.
B
H
Okay,
let
me
okay,
let
me
try
to
join
the
video
queue
also.
So
if
you
still
hear
me,
thank
you
jonathan
for
the
comments,
and
so
now
in
front
of
my
eyes.
I
see
this
slide
with
prive
to
encrypted
transport,
which,
generally
speaking,
I
think,
is
a
good
requirement
for
itf
protocols.
H
It
provides
a
it
has
an
entire
security
architecture
behind
it
and
it
provides
a
acceptable
level
of
security
in
that
the
my
traffic
to
another
end
of
the
network
will
not
be
listened
to
by
some
attackers
and
they
will
not
be
able
to
modify
the
the
traffic,
but
this
is
always
a
and
to
end
that
is
unique
us
from
ipc
to
a
web
server,
for
example,
okay
and
it's
good
to
have
encrypted
transport
there.
H
It's
very
good,
but
now
when
we
talk
broadcast
and
broadcast,
has
a
particular
meaning,
then
it's
difficult
to
define
a
good
encryption
and
I'm
afraid
in
ip
already.
There
is
probably
nothing
in
that,
and
also
in
ip
there
is
no
broadcast
id,
but
it's
multicast
ip,
because
ip
is
of
course
ipv6.
I
consider
and
that
that's
a
very
difficult
question
to
solve.
H
I
also
think
that
the
the
person
jonathan
he
said
something
about
m2
ends,
which
sounds
like
multicast.
I
am
an
end.
I
send
the
packet
to
several
receivers
multicast
and
there
might
be
some
something
possible
there
in
terms
of
encryption.
I'm
not
sure
what
exactly,
but
the
other
thing
that
jonathan
mentioned
ends
to
end.
I
think
at
iatf.
There
is
nothing
about
that
and
I
I
think
there
is
nothing
that
could
be
possible
about
that
or
even
though
I
must
acknowledge,
I
admit,
I
know
nothing
about
hip
and
about
pidlock
and
these
things.
B
H
Yes,
thank
you
presenter
for
this
qualification,
and
this
brings
me
the
other
question.
So
what
kind
of
thing
should
I
mean?
I
am
a
newcomer
here.
I
do
not
know
the
entire
context,
but
what
kind
of
thing
could
itf
do
below
ip
right?
If
you
say
broadcast
below
ip,
maybe
broadcast
at
file
layer
or
broadcast
like
in
tv
broadcast?
H
But
what
could
itf
do
about
securing
that
right?
There
is
nothing,
and
I.
B
Think
well,
so,
a
little
bit
more
context.
The
system
as
a
whole
has
plenty
of
components
that
do
use
ip,
but
that
particular
mode
of
doing
remote
identification
over
the
data
link
does
not
use
ip.
So
you
know
all
of
the
players
have
got
ip
connectivity
in
some
places
and
at
some
times
and
the
network
remote
id
mode
does
directly
use
ipconnectivity,
but
the
broadcast
grid
is
just
over
a
data
link.
B
So
matt
is
this
an
appropriate
place
to
do
a
hum
to
to
get
see
whether
the
working
group
likes
the
current
language.
A
I
I
don't
think
personally,
so
I
think
I
would
prefer
to
have
a
discussion.
I
would
say
to
more
inputs
because
yeah,
so
unless
there
is,
I
would
say
the
some
comments
to
to
be
made
here
in
this
session.
I
prefer
that
we
we
discussed
this
further.
You
share
this.
I
would
say
the
the
modification
that
you
have
made
on
the
list
and
then
we
can.
We
can
proceed
on
that
one.
So
may
I
just
call
on
the
participant:
do
you
have
any?
E
A
B
A
D
A
Just
to
to
to
let
you
have,
I
would
say
we
are
running
out
of
time
for
the
for
this
slot,
so
if
you
can
do
it
in
the
you
can
finish
the
your
requirement
discussion
in
the
coming
three
minutes
that
will
be.
This
will
be
really
good
thanks.
B
This
is
the
last
slide
and
it
there's
a
lot
on
it.
I
hope
people
will
have
a
chance
to
look
at
it
after
the
session.
B
A
lot
of
these
are
questions
of,
should
I
do
this,
or
should
I
do
that,
because
individual
reviewers
have
had
their
particular
suggestions
and
in
cases
where
it
was
obvious
that
yes,
this?
This
is
what
we
needed
to
do.
I
just
did
it,
but
there
are
a
lot
of
cases
where
you
know
do
we
want
to
take
the
document
this
way
or
we
want
to
take
the
document
that
way,
and
so
I
would
like
to
have
some
discussion
on
the
list,
so
I
will.
B
B
Yes,
please,
okay,
so
the
first
thing
I
want
to
say
before
I
even
get
into
the
architecture
slides
is
I've
really
been
struggling
to
understand,
ietf
culture
with
regard
to
requirements
and
architecture,
and
I
think
I've
finally
figured
it
out.
B
B
I
need
a
function
that
allows
me
to
maintain
at
30
000
feet
and
I
need
a
function
that
allows
me
to
descend
from
30
000
feet
and
then
that
finally
leads
to
technical
requirements
like
I
need
three
jet
engines
and
two
wings,
and
that
doesn't
seem
to
be
quite
the
way
it
works
in
ietf.
B
And
so
you
know,
for
me,
architecture
always
follows
requirements.
It
does
not
precede
them,
but
I
guess
that's
because
ietf
kind
of
jumps
straight
to
the
technical
requirements
skipping
over
the
operational
and
the
functional,
in
which
case
all
right,
looking
at
architecture
before
requirements,
makes
a
certain
amount
of
sense.
B
But
we
don't
get
to
define
the
overall
architecture,
it's
defined
by
the
regulators
and
by
external
standards,
development
organizations,
and
so
the
architecture
document
that
I
created
is
in
a
sense,
the
wrong
architecture
document,
because
I
guess
what
iatf
really
wanted
is
one
that
described
that
overall
architecture
prior
to
specifying
technical
requirements,
but
that's
already
predefined
and
it
would
be.
It
would
be
pointless
for
us
to
replicate
all
of
the
definition
of
that
architecture.
That
already
exists
in,
in
literally
thousands
of
pages
of
documents
published
by
regulators
and
other
standard
development
organizations.
B
So
I
jumped
directly
to
a
solution,
space
architecture
which
has
led
to
some
confusion
and
some
pushback.
So
there
are
lots
of
open
issues,
many
of
which,
hopefully
can
be
resolved
by
simply
recognizing
that
this
draft
is
in
fact,
for
a
solution,
approach.
Architecture
and
probably
should
be
moved
away
from
the
requirements
and
towards
the
solutions
based
documents,
along
with
what
adam
and
bob
and
and
others
have
been
doing.
So
here
are
the
reviews
that
have
that
I've
received
on
architecture.
B
The
main
point
that
he
has
made
is
the
requirements
document,
and
the
architecture
document
need
to
be
better
coordinated,
so
that
requirements
are
in
one
and
architecture
is
in
the
other,
but
the
architecture
document
has
a
link
to
the
requirements
so
that
each
architectural
point
is
justified
in
terms
of
a
requirement
that
it
satisfies.
B
B
B
I
there's
not
a
common
theme
amongst
all
of
these.
One
thing
that
I
think
I
can
answer
is
this
one
about
asking
the
astm
chair.
My
read
of
the
f3411
document
is
that
for
broadcast
rid,
it
defines
specific
message
formats
for
network
read,
it
defines
only
the
data
dictionary.
The
elements
in
those
dictionary
are
the
same
elements
that
show
up
in
the
specific
message
formats
that
are
used
in
broadcast
id,
but
the
specific
message
formats
themselves
are
not
dictated
for
network
grid.
B
However,
for
confirmation
I
will
ask
the
astm
chair
and
then
there's
some
questions
about
scoping.
You
know
what
really
belongs
in
the
archdocument
and
what
belongs
in
the
other
solution.
Space
documents
and
amelia
did
a
very
thorough
and
very
entertainingly
written
review,
which
I
quite
enjoyed,
and
I've
attempted
to
summarize
here
my
understanding
of
her
points.
B
Some
of
these
I
need
to
go
directly
back
to
amelia
one
to
one
or
on
the
list,
because
I
just
need
to
clarify
some
things.
For
instance,
I
was
not
actually
speculating
on
activities
of
other
sdos,
where
I
said
they
may.
That
was
actually
an
explicit
thing
that
the
regulators
said.
This
is
allowed
and
astm
as
the
primary
sdo
operating
in
this
area
said.
B
Well,
we
have
defined
messages
and
we
have
defined
a
data
dictionary
and
we
have
defined
how
you
transport
them
over
wi-fi
neighbor
awareness,
networking
and
we've
defined
how
you
transport
them
over
bluetooth,
but
if
you
wish
to
transport
them
over,
something
else
have
a
good
time
right.
So
I
was
just.
I
was
just
highlighting
the
fact
that
in
that
the
people
who
defined
the
message
formats
have
said,
yeah
go
ahead
and
carry
them
over
other
things
and
how
you
do
that
is
up
to
you.
B
There
were
additional
points
in
the
thread
that
amalia's
review
launched
and
a
lot
of
it
revolved
around
the
distinction
between
safety
and
security.
Astm
has
said
this
is
a
security
standard,
their
f3411,
which
was
what
we
initially
focused
on
fitting
our
stuff
into
and
augmenting
with
better
trustworthiness.
B
But
now
there
are
other
organizations,
including
euro
k,
who
are
now
stepping
up
and
saying
well
we're
going
to
go
further
and
we're
going
to
do
a
safety
standard.
The
difference
is
security
in
the
mind
of
the
aviation
community
is
about
stopping
people
from
doing
intentionally
bad
things,
whereas
safety
in
the
aviation
community
is
about
not
having
planes
accidentally
crash.
B
Okay,
daniel
also
gave
me
a
very
substantial
review
of
the
version
three
of
the
architecture
draft,
which
is
the
most
recent
and
as
yet
not
reviewed
by
anybody
else,
and
I
haven't
really
addressed
any
of
these.
Yet.
B
B
B
We
need
some
way
to
enforce
aaa
policy
on
the
observer,
initiating
any
kind
of
ip
flow
to
that
pilot,
because
we
don't
want
people
who
are
annoyed
by
that
buzzing
sound
of
the
drone
who
have
no
particular
standing
as
public
safety
personnel
to
be
able
to
bother
the
drone
pilot
while
he's
flying,
and
thus
you
know,
actually
reduce
rather
than
improve
safety
of
the
general
public.
B
Now
the
next
is
my
whining
and
it
has
to
do
mostly
with
draft
scopes,
and
I
will
caveat
a
lot
of
my
frustration
presumably
comes
from
my
own
failing
to
participate
more
frequently
in
give
and
take
on
the
mailing
list.
So
I
originally
tried
to
write
an
applicability
statement
for
uas
red
got
told
to
split
it
into
requirements
and
architecture.
Fine,
I
did
that,
but
I
did
that
with
my
own
idea
of
what
an
architecture
was
which
is
apparently
not
the.
B
I
etf
concept
of
what
an
architecture
is
the
architecture
into
which
drip
must
fit
is
already
defined.
Any
architecture
that
we
define
is
either
a
redundant
document
or
a
specific
solution
approach,
and
I
did
the
latter,
in
which
case
requirements
should
drive
architecture,
not
vice
versa.
Reviews
have
asked
for
both
more
and
less
context.
At
the
same
time,
a
lot
of
the
confusion
in
people
reading
arch
comes
from
lacking
context
from
requirements
and
now
bob
has
drafted
what
looks
an
awful
lot
like
an
applicability
statement
for
uas
rid.
B
So
I
wonder:
should
we
merge
these
three
drafts?
I
don't
know
that
we
can
decide
that
today,
but
I
want
to
raise
the
question
today
and
then.
Finally,
I
want
to
point
out
that,
even
with
all
that
we
have
been
working
on
in
the
requirements
and
solution
spaces,
there's
nothing
there.
That
would
stop
a
malicious
operator
from
registering
a
harmless
toy,
getting
a
private
key
for
that
harmless
toy
then
provisioning
his
big
weaponized
uas
with
that
same
private
key,
so
that
weaponized
uas
can
spoof
and
pretend
to
be
the
harmless
little
toy.
B
I
Can
you
hear
me
I
can
yeah
so
I
mean?
Does
anyone
have
any
specific
comments
or
questions.
G
Can
you
hear
me
yes,
excellent,
sorry,
just
as
a
the
preventing
somebody
taking
another
drone's
id?
G
B
G
I
Well,
what
I'm
wondering
is
that
is
that
a
problem
we
need
to
solve.
I'm
not
clear
about
that,
and
I
I
tend
to
think
that
we
we
need
it's
part
of
one
of
the
assumption
that
the
private
key
is
going
to
remain
private.
B
J
Here,
like
you
know,
today,
most
of
the
chipsets
comes
with
the
module
called
tpm
trusted
platform
module,
which
is
especially
used
for
this
kind
of
security
purposes.
Can't
this
be
used.
B
Right
I
I've
used
tpms
I've
actually
written
a
secure
bootloader
that
uses
them,
but
I'm
not
aware
of
any
small
inexpensive
uas
that
have
tpms
thus
far.
J
I
Yeah
thanks,
but
is
that
unreasonable?
We
we,
I
mean
for
the
architecture
that
we
assume
that
that
private
key
is
self-generated
by
the
ua
and
that
even
if
it's
not
the
case
now
it's
probably
well.
We
can
hope
is
going
to
be
the
case
later
or
is
it
a
real
problem
that,
because
if
the
private
key
is
believed
to
be
public,
it's
it
makes
things
much
more
harder.
B
Understood-
and
perhaps
that
is
the
best
answer
we
can
come
up
with-
perhaps
all
we
can
do
is
say
that
you
know
when
the
world
evolves
to
the
point
where
even
small
inexpensive
consumer
drones
have
the
ability,
the
computational
horsepower
and
the
and
the
volatile
and
non-volatile
storage
and
so
on
to
do
it,
then
we
can
do
it
and
until
then
we
can't,
but
it
also
may
be
that
there
there
are
adjunct
things
that
we
can
do
to
to
mitigate
the
situat
situation.
B
For
you
know
the
foreseeable
future
anyway,
cs
rid
itself
is
not
a
fundamental
part
of
drip.
It's
an
option.
I
think
it's
a
very
attractive
option
and
lots
of
other
organizations
have
stumbled
across
similar
ideas
so
anyway,
that
that's
a
discussion
that
we
can
also
take
to
the
list.
I
just
wanted
to.
You
know
open
the
discussion
at
this
point.
K
Just
took
a
while
to
catch
up,
so
I
think
that
one
of
the
things
is
a
tpm
doesn't
even
really
fully
solve
the
problem,
because
often,
even
if
you
can't
get
the
private
key
out
of
the
device,
you
can
still
use
the
device
to
do.
Do
the
encryptions
that
you
need
for
the
protocol
like
you
can
still.
You
know,
fake
the
big
drone
with
it
just
by
calling
the
cheap
tpm
to
go.
Do
what
you
you
need
to
do.
K
So
I
think
this
is
a
semi
unsolvable
problem,
really
because
it's
not
about
the
private
key.
It's
about
the
access
to
use
the
private
key.
That's
the
important
thing!
You
can't
really
block
that,
and
and
most
attempts
to
protect
the
private
key
haven't
gone
very
well
anyway,
you
know
see
the
you
know:
cable
tv
industry,
but
even
if
you
could
solve
that
problem,
it
doesn't
help,
but
I'm
I'm
very
curious
with
this.
K
This
assertion
that
you
know
the
type
of
flight
controllers
that
we
have
in
this
environment
can't
do
can't
generate
these
types
of
keys.
That
seems
highly
unlikely
to
me.
Can
anyone
say
more
about
that.
I
Well,
I
I
do
share
your
your
concern,
I
it's
something
I
I
I
don't
understand
why
those
flights
I
mean
those
planes
aircraft
can
generate
the
keys.
It's
also
something
that
surprised
me.
B
So
I
guess
it
is
theoretically
possible,
but
you
should
realize
that
most
of
these
flight
controllers
don't
even
have
an
operating
system.
They
are,
you
know,
embedded
controllers,
running
sure.
K
But
I'm
gonna
write
public
key
crypto
on
stm32.
You
know
you
know
f4
ff7
series,
all
the
time
right,
there's
no
big
deal
doing
on
those
type
of
environments.
So
I'm
I
mean
we
we've
implemented
dtls
on
you
know,
8-bit
processor
says
I
I
just.
I
think
I
think,
if
we're
going
to
go
with
that
assumption,
we
should,
if
that's
an
assumption,
that's
critical
to
us.
B
No,
I
I
grant
your
technical
point
about
the
hardware,
I'm
more
concerned
with,
what's
wrapped
around
it,
that
when
you
go
to
the
store
and
buy
one
of
these
things,
it's
running
an
app
that
is
not
only
a
bare
metal
app,
it's
a
closed
source,
app,
so
of
course
right.
So
so
yes,
this
is.
This
is
a
direction
that
we
could
go,
but
it
will
require
more
manufacturer
cooperation.
K
Okay,
that
really
gets
to
a
good
point,
though
I
think
you
should
say
it
that
way
that
that
you
know,
if
you
require
the
manufacturer
to
change
the
software
on
the
drone,
then
that's
a
that's
a
deployment.
You
know
whatever
that's
a
limitation,
but
you
have
to
decide
whether
you're
doing
it
or
not.
That
that
point
I
understand
thanks.
I
But
what
I'm
I
am
wondering
is
toward.
Are
you
asking?
If
are
you
asking
if
we
should
take
as
an
assumption
that
the
the
private
key
remains
reflecting
the
identity
of
the
I
mean
of
the
eua,
and
I
mean
it's
not
a
is
is
expected
to
be
protected
in
a
way
that
it
can't
be
used
another
as
an
oracle.
Also
or
do
you
are
you
asking
if
we
should
consider
what
is
existing
today.
K
Okay,
so
I
I
think
what
I
was
saying
is:
I
find
the
assertion
that
the
cpus
on
a
drone
that
are
capable
of
keeping
it
in
stable
flight
are
not
capable
of
doing
ace
generating
a
key.
I
find
that.
I
don't
believe
that
that
seems
very
unlikely
to
be
true
to
me
and
that's,
and
it
sounds
like
that's,
not
the
actual-
that
that's
not
probably
the
important
assertion
here.
Probably
the
important
assertion
was
you're,
trying
to
do
an
architecture
that
doesn't
require
changing
any
of
the
software
on
the
drone.
That's
a
very
different
statement
right.
K
So
those
are
two
things
and
then
what's
what
accidentally
got
confounded
with
them
was
a
third
thing,
which
is,
I
don't
really
whatever
you're
doing
with
your
private
keys.
If
you
think
they're
not
going
to
leak
you're
out
of
your
mind,
they
are
going
to
leak.
People
are
going
to
be
able
to
steal
those
private
keys
or
at
least
steal
the
ability
to
use
the
private
keys,
even
if
they
can't
directly
read
the
private
key.
K
I
Yeah
so
I
mean
I
completely
agree,
but
my
question
to
stewart
is,
I
mean,
do
do.
Do
we
have
to
consider?
I
B
So
I
guess
my
instinct
was
to
simply
in
the
basic
drip
documents
to
highlight
the
risks
associated
with
private
key
compromise
leakage,
inappropriate
use
by
the
guy
who
generated
it,
etc.
Right,
but
then,
in
the
you
know,
add-on.
If
you
will
optional
things
that
that
drip
can
do
when
extended
with
something
like
csrid,
that
we
have
mitigation
strategies
available.
F
Now
it
works
hopefully,
so
we
have
here
a
little
bit
different
situation
compared
to
normal
consumer
electronic
considerations,
because
there
are
a
regulatory
requirements
to
which
drones
to
be
sold
even
at
walmart
and
even
for
50
bucks,
as
long
as
they
are
heavier
than
the
really
smallest
drones
have
to
comply
with
in
the
foreseeable
future.
F
In
other
words,
you
know
there
will
be
an
time
for
non-compliance
and
warnings
and
stuff,
but
in
in
a
few
years
drones.
If,
if,
if
if
there
is,
if,
if
the
regular
regulatory
authorities
get
it
right,
then
drones
will
create
whatever
key
the
regulators
require
and
if
the
cpu
is
in
those
drones
as
deployed
today,
can't
do
that.
F
F
With
respect
to
the
technology,
that's
there
I
just
looked
up
quickly
a
topic
king,
a
major
major
distributor,
for
you
know
little
little
drony
things
and
other
things
model
planes
and
whatnot.
You
know
every
of
these
controllers
have
like
32-bit
arm
cores
nowadays
as
a
minimum
yeah.
So
the
times
when,
when
your
stability
control
was
run
by
some
some
eight
big
pid
regulating
thingies,
those
are
long
long
long
gone.
F
So
I
wouldn't
worry
about
the.
I
wouldn't
worry
about
the
technical
ability
to
do
these
things.
I
would
worry
more
about
the
regulatory
environment.
Thank.
B
You
great,
I
mean
a
number
of
you-
have
pretty
much
changed
my
thinking
in
the
last
10
minutes
on
this
point
at
the
at
the
top
level,
though,
a
couple
of
people
have
pointed
out
that
that
keys
will
leak,
and
it
would
be
great
if
we
had
some
strategy
for
dealing
with
the
leakage
of
keys.
Even
if
we,
even
if
we
assume
that
at
some
point
in
the
future,
the
keys
will
be
properly.
F
So
so
what
right
things
are
I
mean
we
can
design
as
good
as
as
well
as
we
possibly
can
under
the
assumption
that
the
key
will
leak,
but
the
thing
is
still
called
the
private
key
and
as
long
as
the
system
doesn't
break
down,
if
there
is
no
rich
occasional,
you
know
an
occasional
misidentification
of
a
of
a
drone
because
of
a
bad
actor
who
recorded
keys
of
one
drone
and
put
it
in
another
drone
when
he
shouldn't
have
done
that
legally
speaking,
that
shouldn't
be
our
problem
either.
B
I
I
understand
your
point,
but
at
the
same
time
the
the
whole
point
of
uas
remote
id
is
to
deal
with
what
are
called
the
the
clueless,
the
careless
and
the
criminal.
This
is.
This
is
not
intended
to
be
a
service
that
is
helpful
to
the
operator.
F
All
so,
making
the
hurdles
as
high
as
we
can
with
respect
to
private
key
interception
and
reuse
in
an
environment
where
you
should
do
it
is,
is
certainly
a
valid
design
go,
but
striving
for
perception
is
a
bad
idea,
because
it's
impossible,
it's
it's
it's
as,
and
I'm
100
with
colin
there.
B
Agreed
yeah,
so
I
I'm
basically
starting
from
the
position
that
somebody
else
stated
about
10
minutes
ago
that
we
we
just
need
to
accept
that
either
private
keys
or
the
ability
to
exercise
the
private
key.
You
know
my
big
weaponized
drone
could
actually
physically
carry
my
toy
on
board
as
part
of
its
payload
right.
B
So
accepting
that
that
can
happen.
What
else
can
we
do?
That
is
not
about
trying
to
prevent
the
leakage
of
the
private
key,
and
it
is
not
even
about
attempting
to
prevent
you
know
carrying
around
the
hardware
that
holds
an
embedded.
You
know
non-leaking
self-generated,
private
key,
and
so
that's
you
know
that's
my
bottom
line
on
the
page
is
can't
we
take
bob's,
crowdsourced
grid
and,
and
look
at
you
know
streaming
video
or
whatever
to
to
do
sanity
checks
on
someone's
assertion
that
they
are
a
harmless
little
toy.
I
Okay,
so
I
think
we
we're
going
to
close
this
discussion
and
maybe
maybe
go
going
putting
this
discussion
on
the
mailing
list
and.
F
I
On
to
the
other
presentation,
I
from
what
I'm
hearing
and
my
perception
of
I
think
this
question
is
a
little
bit
out
of
scope
of
the
architecture
document
and
that
we
should
reasonably
take
that
yeah.
The
journey
is
identified
with
that
public
key
and
not
to
dig
too
much
on
and,
of
course,
it's
gonna
leak.
It's
gonna
that
should
be
put
in
the
security
considerations.
I
L
Excellent
I've
clicked
on
the
presentation
screen,
but
I
do
not
see
my
slide.
So
what
do
I
need
to
do?
Next?
Yes,
it
looks
like
yeah,
okay,
yep,
perfect.
There
we
go
okay,
hello,
everybody.
L
I
know
we're
running
a
little
behind
schedule,
so
I
will
try
to
make
up
some
time
here
there
we
go
so
I'd
like
to
begin
by,
stressing
that
my
focus
here
is
on
a
very
small
piece
of
the
of
a
much
larger
drone
puzzle
and
specifically,
what
I'm
looking
at
here
is
creating
a
registry
or
a
repository
of
unique
identifiers
for
drones
and
the
owners
or
operators
of
those
of
those
drones.
L
It
should
not
surprise
people
that
know
myself
that,
based
upon
over
20
years
within
the
icann
and
the
main
name
space,
I
am
using
domain
names
as
a
reference
point
for
a
lot
of
what
I
will
be
doing
and
the
approach
that
I
am
taking.
The
basic
building
blocks
in
which
I've
tried
to
engage
in
a
path
forward
here
is
using
existing
protocols,
specifically
epp
and
rdap
in
the
concept
of
epp
with
a
demandroid.
L
I
am
looking
at
coming
up
with
the
equivalent
of
an
aviation
repository
object,
identifier,
and
this
would
be
right
now.
The
current
best
thinking
is
that
this
identifier
would
be
associated
with
the
airframe
and
right
now,
based
upon
some
of
the
discussions
that
I've
been
having
with
sallow
and
bob
stu
and
some
of
the
other
people
within
the
community.
L
There
appears
to
be
a
tendency
to
not
just
only
address
drones
but
manned
as
well
as
unmanned
aircraft,
so
the
this
proposed
solution
has
the
elegance
of
being
able
to
just
handle
drones
or
the
entire
ecosystem.
L
One
of
the
other
aspects
that
you
will
see
in
the
proposed
hierarchy
is
that
I
am
looking
to
leverage
the
existing
iso
3166
2
taxonomy,
that
is
modeled
after
the
cc
cca,
tld,
name,
space
and
part
of
that,
instead
of
going
with
a
very
flat
file
to
the
to
this
namespace
part
of
this
bifurcation
or
or
if
you
will
distribution,
is
to
take
a
lot
of
those
localized
contact
droids,
it
would
have
a
lot
of
pii
and
allow
that
to
be
handled
under
the
relevant
data
privacy
laws
of
each
country.
L
One
of
the
things
that
I
think
is
important
as
people
begin
to
look,
I
always
like
to
share
what
my
frame
of
reference
is.
I
am
not
trying
to
reinvent
the
wheel.
L
I
am
trying
to
see
what
has
been
done
successfully
in
other
industries,
so
one
of
the
things
that
I
have
done
is
I've
looked
to
the
automotive
industry
where,
when
a
when
a
car
is
manufactured,
there
is
a
vin
number
that
is
stamped
on
multiple
places
on
that
automobile,
independent
of
the
manufacturer
or
independent
of
where
that
particular
car
is
made
that
car
is
then
shipped
and
when
it,
when
an
individual
seeks
to
register
that
vehicle
with
their
local
department
of
motor
vehicle
to
get
a
license
plate,
they
need
to
produce
ids.
L
So
this
is
kind
of
the
construct
that
I
have
looked
at
in
developing
the
the
proposed
ecosystem.
Again,
this
is
current
best
thinking.
L
Welcome
to
criticism
feedback,
as
I
mentioned
before,
in
the
upper
left
left-hand
corner
here,
you
will
see
where,
at
the
time
of
manufacture
the
aircraft
manufacturer,
the
drone
manufacturer
or
in
the
case
of
the
do-it-yourself,
a
hobbyist
who
perhaps
makes
her
own
drone,
they
would
seek
to
have
that
unique
aviation
roid
registered
in
the
t
in
in
in
the
tld
for
purposes
of
this,
I
have
just
referenced
it
as
dot
tld.
L
I
F
I
I
E
Okay,
now,
let's
find
the
right
screen.
E
Okay,
so
let's
go
into
screen
mode
here,
slide
percent
slide
mode.
Okay,
let's
go
here
in
the
charter
which
says
drip's
goal
is
to
specify
how
remote
id
can
be
made
trustworthy
and
available
in
both
internet
and
local
only
connected
scenarios
so,
and
there
are
some
design
goals
that
are
limiting
us
from
technology
or
from
other
standards,
one
we
are
limited
to
an
id
which
is
20
characters
maximum,
and
that's
because
this
has
to
work
over
bluetooth,
4
inside
a
single
broadcast
frame.
E
We
want
deterministically
globally
unique
with
distributed
registry
services
such
that
this
id
is
related
to
this
device
and
not
some
others.
We
also
want
non-spoofable
approval
ownership
without
internet
lookup
in
200
bytes,
which
it
would
fit
within
the
chained,
bluetooth,
4
frame
or
into
bluetooth,
5
frame
and
much
less
for
better
performance,
which
probably
will
require
some
internet
lookup.
E
So
those
were
the
design
goals
that
I
was
I've
been
looking
at
since
I
started
this
and
let's
see,
did
I
get
okay?
Fine,
so
I
had
some
design
considerations
and
is
a
registered
string
non-spoofable
and
the
answer
is
no.
It's
not
non-spoofable
whether
I
look
at
the
proposed
standard
for
you
for
ui
ur
uas's,
the
ansi
cta
serial
number,
or
look
at
a
classic
registered
string,
rfid
epc.
E
E
So
what
about
digital
certificates
are
they
non-spoofable
certificates
themselves
are
not
are
non-spoofable,
but
the
name
is
spoofable.
The
subject
ought
name
can
occur
in
multiple
routes,
who's.
We
trusted
on
a
name
and
again,
we've
had
some
really
classic
issues
here
in
the
web
of
somebody
registering
an
important
fqdn
in
another
pki.
E
You
know
the
ca,
causing
trust
issues
and
what,
if
there's
a
simultaneous
registration
of
of
a
name
in
in
multiple
places
who
wins
how
to
do
the
management
across
multiple
independently
operated
certificate
systems,
so
those
were
design
considerations
which
I've,
which
I
looked
at
and
to
be
trusted.
Non-Spoofable
identity
means
to
be
self-asserting.
E
This
is
my
particular
claim,
and,
and
the
only
way
to
do
a
that,
I've
able
to
find
learn
to
do
a
a
self-asserting
identity
is
that
the
identity
is
derived
from
trustable
information.
That
is
a
public
key
and
there's
an
algorithm
that
this
trust
information
yields,
identity,
hash
of
the
public
keys,
identify
fixed
length
results
is
best
because
of
that's
what
protocols
like
so
worked
on
this
as
design
considerations.
E
What
was
thinking
about
a
year
ago,
when
I
was
first
brought
to
this
problem
space
and
the
globally
unique
list
implies
an
assigning
hierarchy.
Statistical
uniqueness
of
just
hashing,
a
public
key
is
not
sufficient.
Even
the
prior
probability
is
small.
You
will
get
collisions
so
include
a
hierarchy
into
the
identity,
and
you
need
to
include
that
hierarchy
in
the
hashing
for
a
non-spoofable
hierarchy.
E
E
It
has
a
loose
hierarchy
in
the
ipv6
prefix,
which
is
actually
then
hard
to
limit
and
control
for
remote
id.
If
I
did
try
to
work
this
with
cgas,
I
was
not
satisfied
with
the
result.
Maybe
that's
my
bias,
and
so
I
chose
to
take
the
the
the
hit
and
add
hierarchy
to
it
and
that
you'll
see
my
hypercall
hit
draft
as
an
open
discussion
where
there's
a
better
way
of
defining
the
96-bit
partitioning
and
and
I'm
open
to.
E
I
have
changed
that
from
the
original
draft
to
what,
where
it
currently
is,
and
we
can
debate
the
choice
of
vddsa
2459
with
c-shake
128
sweet
choice,
but
the
edd
sa
gives
us
a
public
key
in
32
bytes
without
patent
issues,
which
I
feel
is
is
important.
Unlike
p256
and
seed.
Shake
is
neat
and
it
does
give
me
some.
E
Some
nice
features
that
that
I
I
like,
but
again
I'm
open
to
discussion
on
that,
but
but
that's
what
I've
I've
put
my
my
starting
position
on
the
global
uniqueness
is
through
registration.
E
I
put
out
a
a
draft
used
on
how
to
register
article
hits
within
hip,
but
evp
that
michael
was
presenting
is
probably
a
better
choice.
I'm
willing
to
concede
that
and
look
at
how
we
can
use
evp
for
the
provisioning
and
get
the
global
uniqueness.
That
way.
Look
up
by
dns
since
hierarchical
hits
are
valid.
E
E
So
that
gives
some
of
the
design
and
and
and
direction
I
had.
I
feel
that
the
solution
I've
come
up
with
meets
a
number
of
the
requirements
in
our
requirement
drafts.
It
provides
approval
ownership
in
and
of
itself.
If
you
read
the
draft
and
the
security
considerations,
the
the
the
harco
hit
as
remote
id
does
not
provide
proof
of
ownership.
It's
the
tool
to
to
get
the
approval
ownership
if
that
tool
provides
the
binding
and
the
registration.
E
E
It
provides
uniqueness
and
through
using
the
private
key,
provides
announcement
of
ability
and
in
registry
one
and
two
through
dns
lookup
you
can
get
with
the
information
is
publicly
available
and
going
to
the
registry.
You
can
then
use
as
a
key
to
get
the
private
lookup.
So
I
feel
that
it
is
the
entry
point
to
all
of
these
requirements.
E
And
so
I
would
like
to
bet
that
the
draft
be
called
to
the
adopted
by
the
work
group.
It
can't
be
I've
been
told
by
our
chairs,
not
at
this
this
session.
I
want
people
to
please
read
the
draft.
Please
comment
to
me
directly
comment
on
the
list
so
that
in
the
august
interim
we
can
make
this
as
a
call
for
work
group
adoption
that
covers
my
slides
kind
of
covered
it
fast,
but
that
is
that
is
it
and
I'm
open
to
questions.
I
So
any
any
question
I
I
I
don't
see
anyone
in
a
queue
except
michael,
but
I
know
I
don't
know.
I
know
why
michael
is
on
the
queue.
I
I
M
Hi
bob
hi
dad
did
you
consider
using
identity-based
crypto
for
this,
then,
if
you've
got
some
20
20
byte
identity,
you
can
figure
out
the
public
key
based
upon
whatever
identity
is.
That
would
give
you
you
know.
Every
every
meeting
on
earth
can
have
several
several
drones.
I
thought
great.
E
Dan,
I
will
admit,
I'm
highly
biased
against
identity-based
encryption.
It
puts
too
much
trust
in
the
in
the
identity
server.
It
is
too
much
of
an
attack
surface.
You
get
that
you've
totally
compromised
everybody
in
the
ibe
ecosystem.
E
I
Nice
comment
so
who
actually
read
the
draft?
I
So
I
actually,
I
see
at
least
two
or
three
people
or
yeah.
So
definitely
that's
going
to
be
one
of
the
the
next
work
we
will
have
to
focus
on
after
requirements
and
architecture
are
on
I'd
like
a
little
bit
more
people
to
to
review
that
document.
I
Yeah,
currently
I
have
to
talk
with
my
co-chair.
What's
the
plan,
I
I
I
really
want
to
to
have
the
the
to
the
requirement
and
architecture
document
to
be
sent
before
we
all
focused
on
the
next.
I
mean
the
solution
drafts,
but
we
should
not
also
wait
maybe
too
much
time
for
that.
So
it's
gonna
come
soon.
I
don't
know
when
I
have
to
to
talk
to
my
co-chair.
E
I
I
will
say
that
this
is
the
first
thing
technical
solution
piece
we
need.
We
need
to
agree
on
what
is
remote
id
so
then
we
have
something
to
build
all
the
rest
on
and
what
our
basic
points
are,
and
also
to
the
larger
aviation
community
and
regulatory
community
saying
that
we're
bringing
something
to
the
table,
and
so
that
is
why
I
personally
want
work
group
adoption
soon
rather
than
later.
So,
when
I'm
in
these
iko
meetings,
when
I'm
in
the
the
other
meetings,
I
say
I
can
point
to
that.
E
This
is
no
longer
an
individual
submission.
This
is
a
work
group
adopted
submission.
So
it's
giving
me
a
little
public
weight
is
what
I'm
asking
for.
I
Yeah,
so
maybe
another
question
I
can
ask:
the
working
group
is
given
the
presentation.
I
So,
even
though
you
haven't
read
the
drought
or
if
you
have
a
breadth
of
draft,
is
there
anyone
that
thinks
it's
a
really
really
bad
solution,
a
really
really
bad
way
to
move
forward.
I
So
I
don't
see
anyone
strongly
opposing
to
that
document
so
which
is
a
interesting
information
for
us
yeah,
so
bob
I
do
understand
your.
I
Soon
so
now
I
suggest
that
we've
finished
michael's
presentation.
E
L
Hello:
everyone,
sorry
for
that
interruption
and
hurricane
is
not
supposed
to
hit
for
at
least
another
two
days
so
premature
interruption.
Can
everyone
still
hear
me.
L
L
L
I
think
this
is
self-explanatory
as
far
as
the
hierarchical
nature
of
what
I'm
proposing
and
how
this
is
largely
modeled
after
the
domain
name
marketplace.
This
following
diagram
here
is
a
a
diagram
which
bob
and
stu
had
pre
had
presented
to
the
registry.
Icann
registry
operator
working
group
a
couple
of
months
ago,
which
shows
the
utm
architect
and
the
reason
I've
used.
This
document
here
is
I'd
like
to
show
you
where
the
proposed
hierarchy
or
registry
would
fit.
L
In
specifically,
the
local
registry
which
I
have
referenced
in
the
previous
document
would
basically
sit
as
a
an
interface
to
the
uas
service
suppliers
within
that
specific
national
region,
and
that
local
registry
would
then
interface
with
the
global
registry
directly,
as
well
as
through
rdap,
to
serve
up
the
individual
request
for
identification,
and
then
this
is
just
a
a
larger
perspective
of
how
this
would
work
across
the
entire
ecosystem.
L
All
193
member
states,
which
are
signatories
to
the
iko
avia
treaty,
final
point
here
again
just
trying
to
wrap
this
up.
I
am
going
to
continue
to
engage
in
outreach
just
this
week
since
the
original
submission
I've
had
some
discussions
about
the
existing
identifiers
for
both
drones
as
well
as
aircraft
and
how
that
could
easily
be
interfaced
into
the
registry.
Again,
we
are
not
looking
to
reinvent
the
wheel,
we're
trying
to
use
existing
naming
schemes
with
existing
protocols
within
the
domain
name
space.
L
The
final
point
here
again,
one
of
my
original
involvements
in
drip
was
through
amelia
who
who
is
with
center,
and
we
have
actually
begun
to
socialize
informally,
with
a
number
of
european
cctlds
that
have
expressed
interest
in
iot
type
devices,
how
they
may
want
to
potentially
work
in
a
sandbox
to
demonstrate
this
interoperability
and
one
of
the
things
that
we
have
done
in
connection
with
some
other
work
in
the
domain
name
space
is,
we
have
actually
already
stood
up
in
the
epp
registry.
L
We've
used
cz,
nick's
fred,
as
well
as
some
of
their
registrars
to
begin
testing
out
these
concepts.
So
if
there
is
anyone
that
is
interested
in
this
contact,
either
amelia
or
myself,
and
with
that
I
yield
back
the
balance
of
my
time.
I
I
So
I
recall,
but
maybe
I
I
I
misunderstood
what
stu
was
mentioning,
is
that
did
do
you
quit
during
your
architecture
presentation?
I
had
the
impression
that
you
were
questioning
the
use
of
rdap.
L
No,
we
it's
not
questioning
the
use.
Rdap
will
be
used.
So
if
you
look
at
a
lot
of
the
debate
that
is
going
on
within
the
icann
community
right
now,
as
far
as
how
what
third
parties
can
get
access
to
the
underlying
pii
or
non-public,
who
is
data
as
a
result
of
gdpr
the
scenarios
map?
I
almost
identically,
you
know
the
ability
for
law
enforcement
or
first
responders
to
get
quick
timely.
L
B
I
B
I
guess
perhaps
because
it's
really
only
required
for
the
so-called
observer
to
pilot
initiation
of
coms,
which
I
think
is
important,
but
it's
currently
not
part
of
the
faa
nprm
or
the
european
regulations
or
the
astm
standard.
B
I
L
Okay,
I
don't
know
where
I
got
cut
off
and
again
so.
I
You
got
kind
of
when
you
said
the
requirements
are
almost
the
same
for
as
the
ones
for
rdap,
where
you
had
the.
L
L
Yeah,
so
let
let
me
keep
this
real
real
short
and
again
I'll.
Just
follow
up
on
the
list
to
explain
this
in
more
detail.
I
I
believe
that
our
debt
can
be
used
to
provide
the
differentiated
access
to
the
underlying
data
subjects
for
the
data
subjects
or
the
machines,
and
that
could
be
automated
or
perhaps
manually
reviewed
based
upon
the
data
privacy
requirements
of
the
individual
member
states.
I
Okay,
thank
you.
So
my
perception
of
the
current
work
in
that
review-
I
don't
know
med,
are
you
here.
I
Okay,
so
what
I'd
like
to
is
a
few
minute
discussions
on
the
current
work
of
that
working
group
before
we
eventually
move
to
a
last
presentation.
I
So
I
I
have
some
I'd
like
to
get
the
sense
of
the
level
of
maturity
of
the
so
so
the
the
working
group
amounts
are
currently
the
requirements
and
the
architecture,
and
I
would
like
to
get
a
sense
of
the
working
group
how
they
think
the
the
the
the
the
level
of
maturity
of
those
documents
are
and
when
we
should
be
ready
when
those
documents
are
going
to
be
ready
for
working
with
last
call.
B
Steve
yeah,
if
I
may,
even
as
the
editor
and
primary
author
of
architecture,
I
do
not
believe
it
to
be
ready
for
working
group
last
call,
although
I
will
continue
to
work
on
it
and
and
try
to
move
it
in
that
direction
as
rapidly
as
possible.
The
requirements
document,
I
believe,
needs
one
more
round
of
minor
changes
as
long
as
we
get
confirmation
on
the
list
that
the
language
proposed
today
to
address
those
issues
is
acceptable.
I
Okay,
right
yeah,
it's
it's
also
my
perception.
So
the
requirements,
the
requirements
you
think
could
be
with
one
additional
iteration-
should
be
ready
for
working
group,
less
goal.
I'm
wondering
what
is
the
sense
of
of
the
people
in
the
in
the
room.
E
It's
just
my
while
to
allow
it
sorry
about
that
requirements
is
ready
with
just
the
nits
which
I've
on
the
privacy
one.
I
think
it's
ready
for
that
work
last
call
architecture's
not,
but
I
don't
think
that
should
hold
us
back.
E
We
have
the
requirements
we
can
work
on
that
we
have
enough
of
the
architecture
there
that
we
know
we
do
need
to
do
on
that.
I've
seen
many
work
groups
that
the
architecture
has
gone
on
for
a
long
time
in
in
in
holding
that
down.
So
let's
set
the
required:
let's
get
the
requirements
into
working
class,
call
and
and
and
wrap
that
up
and
let's
do
it,
and
I
continue
to
beat
on
architecture.
I
Okay,
yeah,
that
sounds
presumable.
Anyone
who
wants
to
react
to
what's
bob
just
mentioned.
I
It's
also
conquered
to
my
perception
of
the
work
so
yeah.
So
now
I
think,
do
we
have
time
for
the
last
presentation.
I
think
we
can
go
to
that
presentation.
N
Slides,
can
you
guys
see
my
slides
and
hear
me?
Yes,
awesome.
Okay,
sorry,
I
was
tabbed
out
all
right,
so
I'm
going
to
talk
about
the
authentication
formats
today.
This
is
the
drip
off
trap
version.
Three,
I'm
gonna
start
off
with
some
of
the
fun
stuff.
We
are
actually
flying
drip
drafts.
These
are
just
a
collection
of
some
photos.
N
Of
some
things
to
the
right
is
our
little
broadcaster
prototype
and
you
can
see
in
the
bottom
left-hand
picture
mounted
on
the
bottom
of
our
payload
plate
for
our
mg1
and
we've
been
doing
some
range
testing,
so
you
can
see
the
three
formats
that
were
three
drafts
that
were
currently
implemented:
the
off
format,
zero,
the
identity
claim
zero
and
uas
rid
o3,
which
was
the
latest
up
to
last
month,
and
we
have
python
3
implementations
of
both
the
astm
standard
and
the
drip
drafts,
which
we
call
tm
red
and
from
some
findings.
N
N
N
So
this
is
the
same
slide
from
bob's
draft.
It's
our
goal
of
making
trustworthy
and
available
on
both
local
and
connected
scenarios
and
we're
using
the
solution.
So
a
lot
of
the
pieces
from
this
draft
are
using
other
pieces,
so
we
use
the
hierarchical
hit
from
the
uas
draft
that
bob
just
talked
about
because
we're
using
the
hierarchical
hit.
N
We
have
the
small
key
signatures
of
ed
dsa25519,
which
gives
us
64
byte
signatures,
and
we
all
we
need
to
do
is
really
pension,
the
astm
to
increase
the
auth
page
limit
from
5
pages
to
10
pages.
We
have
gone
to
them.
They
are
receptive
of
the
change
for
the
next
revision
of
the
astm
standard,
so
we
would
have
224
bytes
of
authentication
data
to
play
with
to
add
to
our
solution.
We
would
add
forward
error
correction
for
bluetooth,
4
and
the
certificates
for
local
only
connected
scenarios.
N
N
The
identity
is
in
one
message:
the
position
is
in
another
message
and
then
authentication
is
a
completely
different
message,
which
is
also
paged
on
bluetooth
4..
So
we
get
a
lot
of
fragmentation
of
data,
and
this
creates
a
lack
of
trust
in
the
messages.
Bluetooth,
4,
especially
bluetooth.
5,
is
a
little
less
susceptible
to
this.
N
So
the
question
was
raised
very
early
on
in
our
boss.
Why
so
small?
Why
are
we
stuck
with
24,
bytes
or
20
bytes
for
the
identifier?
This
is
what
a
bluetooth
4
frame
looks
like.
We
only
have
25
bytes
of
data,
and
one
of
them
is
already
taken,
leaving
only
24,
that's
excluding
any
other
extra
headers
that
astm
defines
for
authentication,
specifically,
that
leaves
only
109
bytes
total
for
authentication
data
to
be
used
into
five
pages.
N
So
just
some
high
level
draft
changes
from
version
zero,
zero,
we're
at
version
zero.
Three.
Now
I
can't
type-
and
I
can't
spell
I
am
upset-
we
have
new
auth
formatting,
which
I
will
go
into
detail
in
the
next
couple.
Slides
and
the
entire
draft
covers
three
requirements:
gen
one
gen
two
engine,
three
3.
certificates
address
gen,
1
and
3,
which
are
provable
ownership
and
registration
and
the
auth
types
that
I
will
present
cover
the
provable
binding
or
gen
2..
N
F
N
Authentication
data:
it
has
a
one
byte
header
which
gives
us
fec
signaling
and
our
off
type
signaling.
The
fec
is
read
solomon.
That
is
what
we
are
specifying
at
the
moment,
and
it
always
takes
the
last
page
of
the
authentication
message.
N
N
It
allows
us
to
have
an
independent
fec
flag
gives
us
128
possible
drip
types
which
currently,
we
only
have
nine
defined,
and
the
seven
bit
space
is
broken
into
the
five
areas
that
you
can
see
on
the
bottom
picture,
and
I
have
a
question
to
the
working
group
which
I'll
raise
on
to
the
list
of.
Is
this
the
best
way
to
carve
up
this
single
byte?
This
is
what
intuitively
to
me
seems
like
the
best
way
to
do
it,
but
I
am
open
to
suggestions.
N
N
We
avoid
the
drip
header
because
of
the
fec
bit
because
it
can
be
set
independently
of
what's
in
this
data
and
being
signed.
There
is
a
question
on
the
timestamp.
N
I
can't
really
get
into
that
much
detail
and
I'll
raise
this
up
onto
the
list
in
more
detail
but
effectively.
There
are
multiple
different
types
of
timestamps
being
used
in
the
general
ecosystem
and
right
now
we're
kind
of
doing
a
mix
of
them,
and
the
question
to
the
working
group
is:
what
one
should
we
adopt?
N
Okay,
so
now
we're
going
to
get
into
the
actual
authentication
formats
that
are
defined
so
the
first
one
is
wrapped
astm
messages.
There
are
five
types:
auth
types,
one
through
5
and
the
type
signals
the
number
of
messages
being
wrapped.
N
The
messages
must
be
in
much
as
type
order
and
they
fill
the
payload
of
the
wrapper
frame.
The
special
case
is
type
5.
If
you
have
five
messages,
you
can't
do
fec
and
bluetooth
4,
but
the
entire
authentication
message
now
acts
as
a
pseudo
message
pack,
which
the
message
pack
is
a
bluetooth
five
only
thing
from
astm,
which
uses
the
255
byte
payload
formatting
of
bluetooth.
N
The
next
auth
type
is
manifest.
There
are
two
types
they're
based
on
off
they're,
based
on
hash
length.
There
are
eight
bytes
and
four
bytes.
There
are
two
special
hashes
within
this
manifest
that
create
a
pseudo
block
chain
of
sorts
of
manifests.
N
There
is
a
question
on
the
order
of
operations
that
I
will
raise
to
the
list
after
this
meeting.
There
is
some
agility
in
the
hashing
algorithm
and
it
comes
from
the
hierarchical
hit
directly
with
the
oga
id,
which
is
part
of
the
hierarchical
hit.
So
for
us
at
the
moment,
it's
c-shake
128.
N
The
final
format
for
bluetooth
4
is
the
certificate
registry
on
aircraft.
The
certificate
is
defined,
much
more
detail
in
the
identity
claims
draft.
So
I
encourage
people
to
go.
Look
at
that,
but
effectively
the
200
bytes
fit
snugly
within
the
general
frame
and
give
us
23
bytes
of
fec
so
on
to
bluetooth,
5.
The
bluetooth
5
is
a
little
bit
easier
because
it
is
all
within
one
bluetooth
frame.
N
The
final
bluetooth
5
message
is
a
zero
wrapped,
astm
messages.
This
is
a
special
one
where
the
we
virtually
fill
the
auth
data
of
the
wrapper
frame
and
sign,
and
the
data
is
actually
outside
of
the
authentication
message
and
is
all
the
data
around
it
in
the
message
pack
there's
a
question
of.
We
can
maybe
name
this
something
slightly
better
than
zero
wrapped
astm
messages.
N
Here's
the
entire
auth
type
tree
to
give
you
guys
an
idea
of
the
layout
and,
as
you
can
see,
ascm
authentication
data
general
frame
fits
within
that
and
then
the
wrapper
frame
fits
within
the
drip
authentication
data
and
then
the
payload
has
a
multitude
of
different
formats
that
can
fit
within
that,
and
with
that
I
am
done.
I
blazed
through
this
in
record
time,
so
I
will
take
questions,
comments
or
concerns
on
this
either
here
or
in
the
mailing
list.
I'll
leave
that
up
to
the
chairs.
If
we
have
time.
I
Yeah,
so
thank
you.
I
don't
know
how
much
time
bteko
is
going
to
left
us,
so
I
think
we
well.
The
meeting
has
been
we
get
we
get
over
time.
I
I
think
the
discussion
should
go
on
the
mailing
list
in
the,
and
I
just
want
to
recall
that
we
have
interim
meetings
that
are
planned
so
well.
I
hope
that
by
the
time
we
will,
we
will
have
made
progress
on
that
and
I
just
wondering
if
anyone
has
anything
to
say
maybe
my
med,
if
you're.