►
From YouTube: DRIP WG Interim Meeting, 2020-04-22
Description
DRIP WG Interim Meeting, 2020-04-22
A
So
if
there's
any
initiative
on
the
presentation
so
that
you
can
access
to
them
directly
and
to
to
display
the
slides,
this
is
the
room.
I,
don't
know
if
someone
who,
if
it
was
participant
there.
So
if
there
is
someone
who
would
like
to
do
jabber
scribed,
please
relay
any
I,
would
say
a
question
that
you
have.
A
This
is,
this
is
a
recap
of
the
current
active
drugs.
We
have
been
working
because
you
see
where
there
are
many
military
that
are
that
are
active
that
we.
Unfortunately
we
cannot
go
into
all
this
this
draft,
because
our
focus
will
be
mainly
on
the
requirement
and
the
architectural
document
mainly
to
to
understand
how
they
can
understand.
A
The
time
budget
we
are
located
for
right,
I
would
say
for
the
belts
load
in
the
discussion.
I
would
say
the
presentation
that
will
be
made
by
best
award.
We
don't
need
to
wait
until
the
end
of
the
presentation
to
to
to
raise
the
questions
and
to
meet
your
comments.
So
please
don't
is
it
a
to
to
to
interrupt
and
to
raise
your
question
and
interactive
discussion
between
in
during
the
representations?
A
B
B
So
this
is
the
big
picture
into
which
we
need
to
fit
notice.
Center
right,
the
UAS
services
supplier,
the
USS,
that's
kind
of
the
center
of
the
world
with
regard
to
larger
systems
that
incorporate
unmanned
aircraft
systems
and
there's
lots
of
interfaces,
and
standardization
of
all
of
them
is
ongoing
in
particular,
note
that
there
will
be
more
than
one
USS.
Each
USS
will
support
more
than
one
UAS
operator
and,
except
for
hobbyists,
most
UAS
operators
will
have
more
than
one.
B
You
is
next
slide,
okay,
so
the
key
standard,
that's
out
there
right
now,
which
was
published
in
I,
think
February
and
balloted
upon
this
past
November
is
from
ASTM
it
standardizes
two
types
of
remote
ID,
broadcast
and
network.
The
main
point
I
want
to
make
about
broadcast
is:
it
is
direct
from
the
aircraft
over
a
data
link
not
over
a
network,
whereas
Network
remote
ID
can
be
from
any
part
of
the
unmanned
aircraft
system,
most
typically
the
ground
control
station,
and
it
is
via
specifically
the
Internet
and
it's
a
node
3
hop
process.
B
It
goes
from
the
UAS
to
the
network,
with
service
provider
from
the
network
reg
service
provider.
To
the
network
read
display
provider
and
from
the
network
read
display
provider
to
the
ultimate
client,
the
only
fully
specified
interface
there
is
between
the
service
provider
and
the
display
provider.
Unfortunately,
in
the
United
States,
the
FAA
is
not
even
recognizing
the
display
provider
as
a
distinct
entity
also
note
that
in
both
broadcast
and
network,
ASTM
has
specified
the
framing
of
not
very
many
bytes
of
authentication
data,
and
there
is
no
further
vacation
of
security
mechanisms
next
slide.
B
B
This
is
the
slightly
less
obvious
Network
remote
ID
use
case.
If
you
look
at
the
middle
tier
you'll
see
that
USS
a
is
acting
as
a
network
grid,
what
ASTM
would
call
service
provider
for
the
first
batch
of
you
is
operators
in
the
lower-left.
It
is
also
providing
display
services
to
some
folks
where,
as
USS
be
in
the
center,
is
only
acting
as
a
network.
Remote
ID
service
provider
and
USS
see
over
on
the
right
is
only
acting
as
a
network.
Remote
ID
display
provider
next
slide.
B
This
shows
the
European
and
two
different
sets
of
u.s.
rules
matrix
against
the
broadcast
and
network
modes
of
STM.
Our
gap
analysis
at
the
bottom
that
four
key
gaps.
The
FAS
NPRM
says
that
remote
ID
is
an
enabler
of
various
and
sundry
other
things,
whereas
ASTM
says
no
remote.
Id
is
a
security
standard.
It
does
not
meet
a
high
enough
bar
to
be
a
safety
standard
such
as
DAA,
detect
and
avoid
to
avoid
collisions
amongst
aircraft.
B
B
This
particularly
highlights
the
idea
that
an
observer
will
get
a
remote
ID
and
then
we'll
do
a
query
into
some
to
be
defined
registry
with
to
be
defined
access,
control
mechanisms
to
get
data
about
the
UAS
and
its
operator
next
slide
the
top
level
set
of
Maeda.
If
you
will
requirements
on
our
approach,
we
believe
that
remote
ID
needs
to
be
immediately
actionable,
which
means
the
information
needs
to
be
trustworthy.
Ideally,
it
should
allow
an
observer
to
determine
whether
they
trust
the
operator.
B
Even
if
the
observer
doesn't
have
at
the
moment
of
observation,
Internet
connectivity,
it
should
enable
the
observer
to
reach
out
and
touch
the
pilot
and
say
what
are
you
doing
there
I
need
you
to
exit
that
airspace,
because
something
has
happened
and
it's
no
longer
safe
for
you
to
be
there
and
privacy
has
got
to
be
maintained.
If
it's
not
forfeited,
we
want
to
complement
existing
external
standards,
but
those
external
standards
don't
well
the
reason
we're
doing
this
is
because
those
external
standards
don't
answer
all
the
necessary
questions.
B
We
want
to
leverage
existing
Internet
stuff
and
we
have
a
stretch
goal
of
going
beyond
operator
self
reports.
In
UTA,
the
unmanned
aircraft
system,
traffic
management,
as
envisioned
in
the
US
or
you
space
as
envisioned
in
Europe
tracks,
are
just
self
reports
from
operators
and
operators
can
lie
or
simply
be
wrong
or
their
hardware.
Their
software
can
malfunction
be
really
great
if
we
had
some
sort
of
independent
confirmation
or
refutation
of
those
self
reports.
Next
slide.
B
That
little
stick
man
called
the
pilot,
slash
operator,
there's
a
lot
of
things,
a
lot
of
entities
that
will
often
be
identical
or,
if
not
identical,
at
least
co-located,
likewise
or
on
the
right
registry,
there's
a
lot
of
functions
that
will
be
offered
by
the
same
people.
You
know
in
more
or
less
integrated
fashion
and
there's
gonna
be
other
things
in
play,
but
we
can't
make
remote
ID
depend
upon
a
lot
of
other
things,
such
as
supplemental
data
service
providers.
However,
we
can
enhance
what
remote
ID
does
using
these
supplemental
data
service
providers
next
slide.
B
Ok,
now
we
get
into
the
real
subject
for
the
day
quirements
for
drip.
The
first
and
most
fundamental
requirement
is
if
I
claim
that
my
is
Stu
or
one
two
three:
how
do
I
prove
that
I,
the
guy
who
is
sending
messages
right
now,
is
really
the
owner
of
that
ID
second
I
send
a
lot
of
messages
beyond
just
Who.
I
am
the
basic
idea
CH.
How
do
we
bind
all
of
those
other
messages
to
the
identifiers
that
I
claim
refers
to
me?
C
D
E
D
E
Stu
mosque
was
here
on
Jan
1.
You
said
the
word
that
you
made
a
personal
me
in
terms
identifiable
me
to
be
clear
that
it's
the
you
a
we're
talking
about
as
being
identify
what
you
have
they're,
not
the
UAS.
There
is
a
distinction
there
and
sometimes
we're
speaking.
We
tend
to
be
a
little
bit
theological,
but
we
need
to
make
it
clear
that
we're
talking
about
that
this
is
the
device
identity,
not
the
necessary.
The
operator
identity,
yeah.
B
But
if
you
then
read
the
fine
print
in
the
documents,
it
makes
it
very
clear
that
the
ID
is
mapped
one-to-one
to
each
unmanned
aircraft
and
if
an
operator
has
multiple
aircraft
each
one
of
them
will
have
a
distinct
ID,
whereas
the
operator
will
also
have
an
ID
currently
in
the
United
States
I'm,
not
clear
on
Europe
UAS
operators
get
a
registration
number
that
is
unique
to
the
operator
and
they
put
that
number
on
each
of
their
aircraft,
but
that
will
all
change
with
the
publication
of
the
FAA
s.
Final
rules
sometime.
G
G
B
E
The
registry
is
the
important
part,
not
just
the
IDS,
so
that
all
ties
in
together
then
we'll
need
to
make
this
little
clear.
As
we
proceed.
We
have
to
get
past
the
requirements,
but
yes
in
the
requirements,
there's
no
clear
distinction
of
how
unique
how
reliable
we're
we
believe.
We
hit
zero
zero
one
percent
reliability.
E
B
Let's
move
to
the
next
batch
next
line
of
general
requirements:
okay,
these
all
kind
of
relate
requirement
for
any
member
of
the
general
public
without
doing
any
kind
of
authentication
or
whatever
ought
to
be
able
to
look
up
a
certain
minimal
amount
of
public
information.
What's
public
information?
Well,
whatever
the
regulator
in
that
particular
jurisdiction,
says
needs
to
be
made
public
or
additionally,
if
an
operator
wants
to
make
additional
in
from
a
date
that
we
also
need
to
allow
a
table
in
requirement.
Five,
the
lookup
of
private
information.
B
That,
however,
must
be
access
controlled
and
all
the
regulators
have
said,
is
access
controlled,
but
we
believe
that
it's
not
just
access
controlled.
We
believe
there
also
should
be
some
sort
of
you
know,
accounting,
an
attribution
and
subsequent
audit
capability
so
that
you
can
say
well
who
access
this
information
and
when
and
what
was
the
justification
for
accessing
it
requirement
six
readability.
B
We
believe
the
information
needs
to
be
not
only
human
readable,
which
is
all
that's
really
covered
by
the
regulators
and
the
external
standards,
but
also
machine
readable,
because,
if
we're
going
to
enable
any
kind
of
other
applications
to
trigger
off
of
remote
ID
data,
well,
then,
obviously
those
other
applications
need
to
be
able
to
to
parse
that
data.
And,
finally,
whatever
is
in
all
these
registries,
to
be
looked
up-
needs
to
be
put
there
in
the
first
place
and
there's
both
static
information
and
slowly
changing
dynamic
information
that
goes
into
registries.
B
B
Would
say
that
it
is
some,
but
not
all
fields.
Clearly
there
will
be
some
free
text
fields
in
there,
but
the
ID
and
anything
beyond
the
ID
that
is
needed
to
enable
an
application
to,
for
instance,
establish
contact
with
the
operator
or
the
operators
USS
or
something
we
just
lost.
The
desk
shared
video
yeah.
C
B
Yeah
we're
trying
to
address
everything.
That's
within
what
E
is
a
and
FAA
and
ASTM
are
calling
remote
ID,
which
goes
well
beyond
the
ASTM,
so-called
basic
ID
message,
which
gives
only
an
identifier
and
nothing
more,
although
the
identifier
obviously
is
the
primary
unique
key
for
looking
up
anything
beyond
that.
B
So
I
guess
I
should
point
out
that
there's
two
ways
of
getting
information
above
and
beyond
the
basic
ID.
The
first
way
is
other
messages
that
are
transmitted
through
the
remote
ID
system,
such
as
the
so
called
location,
vector
message
that
gives
you
know,
position
and
velocity
the
operator
message,
the
system
message
and
so
on,
but
those
are
actually
transmitted
through
the
system
and
then
there's
looking
things
up
based
upon
a
unique
key
acquired
through
the
system,
that
being
again
the
UAS
ID.
B
Still
not
seeing
it
there,
we
go.
That's
it
okay,
so
now
we're
getting
into
kind
of
side
requirements.
A
lot
of
this
needs
to
be
protected
with
Triple,
A
and
governed
by
policy,
and
a
is
just
a
point
that
Triple
A
itself
needs
to
be
governed
by
policy
and
anybody
who's
going
to
edit
the
policy
that
needs
to
be
protected
with
your
belay
general
Kermit.
Nine
I've
called
it
finger
for
the
moment
because
it's
it
feels
to
me
kind
of
like
the
old
finger
service.
It's
obviously
not
somehow.
B
We
need
to
be
able
to
get
some
information
through
either
broadcast
or
network
remote
ID.
That
enables
a
suitably
qualified
observer
to
reach
out
and
touch
the
pilot
or
the
pilots
USS
and
reach
out
and
touch
we're
not
trying
to
constrain.
That
I
mean
maybe
it'll
be
a
sip
call.
Maybe
it'll
be
some
kind
of
push
notification,
don't
know,
but
there
needs
to
be
some
sort
of
mechanism
to
enable
these
arbitrary
applications
to
do
a
kind
of
a
reach
out
and
touch
function
and
then
finally,
general
requirement
ten
quality
of
service.
B
There
are,
in
fact,
performance
requirements
from
the
regulator's
and
within
ASTM
to
say
certain
messages
need
to
be
transmitted,
frequently
like.
Where
am
I
and
what
direction
am
I
going?
Other
messages
less
frequently
like
what
am
I
up
to
here
anyway,
I'm
flying
this
forest
to
look
for
forest
fires
or
whatever
any
questions
on
this
patch.
B
Next
slide,
this
is
pretty
much
the
last
of
the
general
requirements.
Obviously,
unmanned
aircraft
move
less.
Obviously,
ground
control
stations
may
move,
consider
a
delivery
truck
that
slowly
drives
from
neighborhood
to
neighborhood,
while
unmanned
aircraft
lift
off
from
the
back
of
the
truck,
make
the
deliveries
to
people's
porches
and
then
land
again
on
the
truck,
as
it
has
moved
a
half
a
mile
down
the
street
that
might
sound
implausible
in
the
near-term.
But
trust
me.
B
It's
not
I'm
involved
with
testing
activities
for
major
corporate
clients
not
to
be
named,
who
are
doing
exactly
that,
and
other
players
may
move
as
well.
Multihoming
is
important
because
unmanned
aircraft
being
small
and
flying
below
trees
and
buildings,
and
so
on,
need
to
do
frequent,
RF
handoffs
of
their
links,
and
if
you
want
those
handoffs
to
go
smoothly,
you
want
make
before
break
make
before
break
implies
multihoming,
which
also
has
a
whole
bunch
of
other
Hey
benefits
multicast
this
one
we
get
into
a
should,
as
opposed
to
a
must.
B
Clearly,
there
are
entities
that
are
gonna
record
that
are
gonna,
want
notifications
of
certain
things,
like
I'm
responsible
for
this
airspace
volume
for
its
security
and
anytime
somebody
reports
that
they
are
in
that
volume
I
want
to
get
a
notification,
that's
an
intrinsically
published,
subscribed
kind
of
thing,
which
obviously
is
most
efficiently
supported,
with
some
form
of
multicast
and
finally
management.
If
I'm
responsible
for
a
particular
coverage
area,
then
I
want
to
know
whether
my
network
is
up
at
the
moment
and
really
providing
coverage
of
that
area.
Any
questions
on
these
okay
next
slide.
B
B
First
off,
there's
a
there's,
a
kind
of
a
fair
witness
concept,
while
I
was
in
this
area
that
nobody
should
have
been
flying
in
and
I
received.
This
broadcast
remote
ID
message
from
oh:
let's
pick
on
Adam
from
one
of
Adam's
aircraft
and
I
assert
that
Adam
was
flying
in
this
place
where
he
shouldn't
have
been
flying.
Well,
maybe
he
was
maybe
he
wasn't.
B
If
I
was,
you
know
a
mile
away
when
I
received
that
and
then
I
assert
that
I
received
it
in
an
inappropriate
location
who's
to
say
we
also
obviously
want
to
defend
against
replay
attacks,
and
then
there
are
optional
supplemental
data
service
provider,
services
such
as
multilateration
that
we
could
support
more
on
that
later
next
slide.
Okay,.
B
Now
we
move
into
civic
requirements
on
identifiers
first
off
can't
be
longer
than
20
bytes
if
we're
going
to
fit
with
the
ASTM
standard
that
FAA
and
presumably
EASA
are
citing
as
a
an
accepted
means
of
compliance
with
their
regulations.
That
identifier
has
got
to
be
able
to
point
you
to
which
registry
it's
in
it's
got
to
be
as
an
entity
ID
requirement
three
unique
within
that
registry
that
it
pointed
you
to,
and
so,
if
you
concatenate
two
and
three
together,
they
make
four.
B
We
need
within
sum
to
be
determined
scope,
uniqueness
of
the
identifier
and
that
scope
is
not
only
spatial
if
you
will
but
also
temporal,
it's
possible
that
over
the
course
of
time
an
identifier
might
get
reused,
we
can
make
the
probability
of
that
extremely
low,
and
indeed,
if
we
are
registering
each
of
our
identifiers
as
long
as
we
keep
a
forever
list
of
used
identifiers,
we
can
prohibit
their
reuse
and
then
some
concept
of
non
spoof
ability
requirement.
Five.
B
Now
that
doesn't
mean
that
an
individual
message
all
by
itself,
is
necessarily
non-smooth
able,
because
these
messages
in
the
case
of
broadcast
over
Bluetooth
four
are
incredibly
short.
But
if
you
listen
for
four
or
five
seconds
and
collect
a
batch
o
messages-
and
you
know,
concatenate
them
correlate
them
in
some
fashion,
then
you
ought
to
be
able
to
achieve
non
spoof
ability
next
slide
all
right.
This
is
another
bunch
of
unnumbered
as-yet
requirements
pertaining
to
identifier,
x',
that
we
need
to
make
a
little
clearer
and
probably
number
some
of
them.
B
The
whole
idea
of
proving
ownership,
then
the
next
one's,
probably
as
well
capable
of
verifying
the
messages
claiming
to
have
been
sent
from
a
given
system
with
a
given
identifier,
really
came
from
the
claimed
sender
and
who's
gonna
generate
this
ID
is
that
the
operator
is
at
the
ground
control
station.
Is
it
the
aircraft
itself?
Is
it
the
USS
or
some
other
registry,
or
is
it
some
collaboration
amongst
multiple
parties?
That's
not
specified
by
the
regulator's
very
loosely.
They
say.
B
B
Requirements
we've
got
to
enable
some
form
of
confidential
handling
of
private
information.
What
do
we
think
is
private
information?
Well,
anything
that's
not
designated
as
public
and
who
would
designate
information
as
public
well
either
a
regulator
or
its
owner
point
to
a
particular
case
of
confidential
handling
is
encrypted
transport.
B
You
know
some
form
of
security
through
obscurity
or
whatever,
at
the
link
layer
and
below
three
encrypted
storage.
This
is
a
should
requirement
because
it's
starting
to
get
a
little
beyond
our
world,
but
if
we
encrypt
stuff
only
in
motion
and
not
at
rest,
you
know
what
have
we
done?
Probably
not
much
now
satisfying
all
these
requirements
may
require
that
authorize.
B
That
doors
have
some
kind
of
internet
connectivity,
for
instance,
if
I
need
to
decrypt
the
operators
location,
then
I
need
to
have
a
key
to
do
that
or
somebody
who
does
have
a
key
needs
to
provide
me
with
a
key
to
do
that
or
somebody
who
does
have
a
key.
Presumably
the
USS
under
which
the
aircraft
is
flying
is
gonna
decrypt
it
on
my
behalf.
For
me.
B
I
E
B
Yeah
III
hear
what
both
of
you
are
saying
and
and
I
agree
and
yet
at
the
same
time,
I
am
continually
frustrated
by
going
to
websites
to
say
all
grey.
Your
stuff
is
protected,
yeah,
it's
protected
on
the
wire
between
me
and
the
bank,
and
you
know
it's
left
in
a
leaky
boat
house
once
it
gets
to
the
bank.
So.
I
Raging
agreement,
I'm
completely
unimportant
with
you,
I
just
think
that
it's
gonna
be
weird
to
try
to
have
a
requirement
that
immediate
I
definitely
think
you
can
write
security
considerations
in
these
documents
and
say:
hey
look,
you
know
you're
a
buffoon.
If
you
don't
do
this
other
thing
as
well,
and
then,
if
we
can
figure
out
some
way
to
point
or
refer
to
something
else,
I
think
we
have
a
better
chance
of
success.
I.
E
J
I
have
another
question:
sorry
free
move
on
I'm,
just
sort
of
at
the
intersection
of
the
last
two
sets
of
requirements
about
the
identifiers
and
and
the
privacy
requirements.
I
wanted
to
see
if
I
kind
of
understand
this
properly,
which
is
that
the
identifiers
will
serve
as
keys
that
exist
in
various
registries,
where
you
can
go
and
look
up
other
information.
B
E
J
Well,
just
like
thinking
about
what
you
had
up
there
about
like.
What's
considered
private
information,
like
you
know,
normally,
if
you're,
if
you're,
if
you're
letting
people
specify
identifiers
that
expire,
you
know
that
only
have
a
certain
lifetime,
then
like
being
able
to
resynthesize
the
fact
that
they
all
belong
to
the
same
device.
Like
that's
a
that's.
That
synthesis
is
a
piece
of
information
that
you
would
want
to
be
able
to
maintain
privately
right.
So
it
sounds
like
that
is
possible,
but
getting
that
to
actually
happen
in
practice,
it
seems
like
could
be
hard
right.
B
Yeah
that
the
idea
is
that
a
that
a
an
adversary
should
not
be
able
to
regenerate
that
record
from
observations
unless
they
have
a
ubiquitous
observation
capability.
You
know
throughout
a
large
area
of
potential
aircraft
operations,
and
you
know
they're,
correlating
patterns
of
use
and
so
on,
whereas
the
registry
with
which
I
you
know
intentionally-
and
you
know,
to
satisfy
regulations
connected
the
dots
between
the
the
temporary
identifier
and
and
me
and
my
aircraft
yeah,
that's
gonna
have
the
record.
Okay,
the
requirements
methodology
input
came
from
dr.
Gert
off.
B
He
pointed
out
that
what
we
are
looking
at
within
ietf
as
requirements
are
driven
by
other
organizations,
regulators
who
are
still
working
on
their
rules
and
external
SD
o--'s
who've
made
design
choices
in
in
their
attempt
to
satisfy
the
regulators,
so
those
things
a
little
fluid
as
well,
and
specifically,
the
choice
of
Bluetooth
and
Wi-Fi.
Those
impose
some
really
severe
constraints
that
that
may
not
always
apply.
B
L
Dax
looks
like
a
really
nice
emerging
datalink
and
what
the
3gpp
people
are
doing
under
the
name
of
5g
a
a
make
them
into
play
at
some
point,
Andres
posting
some
of
his
thoughts
on
the
TM
read
list
and
for
anybody
who
didn't
know
this,
we
were
the
TM
read
trustworthy,
multi-purpose,
remote
identification
baath,
but
we
became
the
drone
remote
identification
protocol
drip
working
group,
so
our
mailing
list
is
still
TM
red
at
ATF
dark.
So
how
do
we
move
forward
with
the
necessary
speed?
B
B
We
could
take
what
we
know
now
attempt
to
prognosticate,
what's
likely
to
happen
in
the
future
and
try
to
pull
it
off
now.
Are
there
any
other
suggestions
on
how
we
might
you
know,
move
forward
on
this
urgent
need
and
yet
deal
with
these
fluid
requirements
and
I
see
that
Michael
would
like
to
speak.
I
think.
K
You
should
go
with
the
first
part.
I
think
you
should
go
forward
with
a
document
go
through
the
various
Security
and
Privacy
reviews
that
will
happen
and
that
that
will
be
valuable
work,
even
if,
after
those
that
process,
you
decide
that.
Actually
you
want
to
wait
for
those
other
stakeholders.
You'll
already
have
done
that
part.
If
you,
if
you
want
to
go
to
an
RFC
I,
think
you
should
do
that,
because
that
will
be
much
easier
to
point
to
the
other
review
or
the
other
stakeholders
that
this
is
quote
real
and
I.
F
You
know
mostly
like
a
participants,
thank
you
for
the
explanation
and
and
by
the
way,
I
agree
with
Michael
on
what
Jesse
said
now
I'm
more
puzzled
by
which
is
the
source
of
those
requirements.
Is
it
many
the
US
FAA,
or
are
you
also
putting
into
the
mix
the
European,
ESA
or
others,
and
maybe
it
could
be
useful
to
mark
those
requirements
with
their
source.
B
F
B
Yes,
the
intention
is,
the
intention
is
not
to
conceal
basic
information
such
as
the
ID,
which
you
can
think
of
as
a
license-plate
number,
nor
the
position
and
velocity,
but
merely
sensitive
information
such
as
you
know,
the
operators
name
and
current
location
so
yeah.
Clearly
we
want
other
vehicles
as
well
as
the
general
public
to
be
able
to
see
you
know,
ninety-eight
percent
of
the
information,
that's
that's
being
sent
and
I
see.
Emilia
would
like
to
speak
so
we'll
be
cutting
the
line
after
Emilia.
B
All
we
have
to
go
on
right
now
is
EU
delegating
regulation,
945
and
implementing
regulation
947
and
some
noises
out
of
eásá
on
how
they
might
go
about
actually
implementing
this
and
I
think
there
was
a
wrap-up
slide,
Danielle
yeah
right
there,
so
you
know
back
up
one.
If
you
were
Danielle
yeah
there
we
go.
Do
we
have
any
requirements
we
should
be
deleting?
Did
we
miss
any
e?
Do
we
have
any
overlaps?
Do
we
need
to
restructure
the
way
classified
it?
B
D
B
B
I
know
this
one's
pretty
dense.
There
are
some
predefined
entities
in
this
world:
the
unmanned
aircraft,
the
ground
control
station,
which
together,
make
up
the
unmanned
aircraft
system,
the
remote
pilot,
who
is
a
guy
actually
at
the
controls,
the
pilot
in
command
who's,
often
the
same
person
as
the
remote
pilot,
but
maybe
a
supervisor
standing
over
the
shoulders
of
several
remote
pilots,
the
one
who's
ultimately
responsible
for
safe
operation,
the
operator
which
is
typically
an
organization,
the
USS,
the
network
grid
service
and
display
providers
and
what
we
call
the
observer.
B
That
term
is
not
actually
defined
in
the
regulations
or
the
ASTM
F
3411,
but
they
use
the
term
user,
which
is
way
too
broad
and
includes
way
too
many
people
without
distinction
and
then
we're
defining
some
things:
a
private
information
registry,
a
Public,
Information
Registry
and
some
optional
entities.
Now
the
private
information
registry,
the
need
for
it
is
clearly
identified
in
the
regulations
and
F
34:11.
But
what
it
looks
like
is
entirely
unspecified.
B
We've
also
got
some
other
information
that
needs
to
go
into
this
private
registry
operator
credentials
is
my
aircraft
of
multicopter
or
a
fixed-wing,
and
how
big
is
it
and
things
like
that,
and
we
are
proposed
approaches
to
leverage
all
this
good
stuff
that
we
have
in
the
internet
by
defining
a
UAS
ad
as
a
domain
name?
Perhaps
only
a
pseudo
domain
rather
than
a
fqdn
and
then
load
up
the
registry
with
the
necessary
information
using
the
typical
protocols
that
we
normally
use
in
a
domain
name:
registration,
where
the
the
UAS
ID
is
indeed
a
domain.
B
Republican
form
a
and
registry.
This
has
got
a
lot
less
information
because
most
of
the
information
here
in
the
background
section
that
needs
to
be
made
public
that
doesn't
sit
in
a
registry
that
gets
actually
pushed
out
through
the
UAS
remote
ID
transmission
mechanisms.
It's
pushed
out
in
the
clear
to
local
observers
over
broadcast
and
it's
served
to
clients
by
a
network,
remote
ID
display
provider
in
network
rate,
and
they
just
point
their
web
browser
to
it.
B
So
what
do
we
really
need
in
the
public
registry?
Well,
we
need
at
least
stuff
that
allow
you
to
find
the
private
registry,
and
we
may
need
some
other
stuff
that
will
allow
you
to
find
servers
or
services
that
you
might
want
to
trigger
using
the
remote
ID
information
that
you
received,
like
I,
don't
know,
make
a
sip
call
to
them
to
the
pilot.
So
once
again,
let's
just
use
the
stuff
that
we
already
have.
Let's
use
DNS
and
not
talking
about
defining
any
new
weird
resource
record
types.
B
Rfc
74
84
tells
you
how
to
find
in
our
DAP
server
from
domain
information
and
whatever
minimal
UAS
remote
ID.
Specific
information
doesn't
fit
into
a
standard
resource
record.
We
would
expect
to
do
the
usual
cheat
of
sticking
it
in
a
text
record
and
then
direct
machine-to-machine
contact
information
would
go
in.
You
know
the
standard
resource
record
types
now:
the
optional
crowd-sourced
remote
ID
to
entities,
a
supplemental
data
service
provider
that
we
slide
in
between
the
network,
remote
ID
service
provider
and
display
provider.
B
It
should
look
like
a
service
provider
to
a
display
provider
and
it
should
look
like
a
display
provider
to
a
service
provider
and
it
can
multilaterally
information
that
it
gets
from
the
finders.
What
are
the
finders?
Well
they're,
just
smartphones
running
an
app
and
they
take
the
broadcast
remote
ID
messages
they
receive
over
Bluetooth
or
Wi-Fi,
and
they
put
a
position
and
time
stamp
on
them
and
they
relay
them
to
that
supplemental
data
service
provider.
B
Okay,
these
are
the
transactions
that
we
presume
will
take
place.
There
are
a
number
of
registration
operations
that
need
to
happen.
There
are
a
number
of
things
that
would
happen,
live
post
registration,
the
first
registration
I
want
to
point
out
registry
to
the
CIA
for
this
to
scale
up
I,
don't
think
the
FAA
is
gonna,
be
able
to
pull
off
what
the
to
pull
off,
which
is
that
they
run
the
registry.
I
think
we're
gonna
see
the
same
thing.
We
see
with
Internet
domain
names.
B
Most
of
the
ones
in
the
middle
are
just
standard.
Uas,
remote
ID,
the
very
first
one
encrypted
broadcast
to
personally
identifiable
information.
That's
something
that
we
are
attempting
to
add
in
the
interest
of
privacy,
whether
it
really
would
be
encrypted
or
not,
would
be
up
to
the
regulator
in
a
particular
jurisdiction
and
then
the
last
couple
last
three
are
things
above
and
beyond
that
we're
adding
this.
B
Where
I'd
like
to
drill
down
a
little
bit,
I
have
really
focused
on
what
will
fit
in
the
Bluetooth
four
constraints.
That
STM
has
specified,
based
upon
their
understanding
of
what
FAA
and
EAS
a
wanted,
and
the
only
thing
I
can
find
that
fits
is
based
upon
the
host
I
entity
tag
the
hit
from
the
host
identity
protocol,
which
I
know,
has
not
garnered
an
enormous
amount
of
traction
within
ietf
over
the
last
20
years.
But
there
you
go
to
fit
the
ID
with
signatures,
is
really
hard
and
to
fit
any
kind
of
certificate.
B
Even
using
modern
techniques
such
as
EDD
sa
won't
fit
even
in
the
maximum
10
page
message
that
is
available
to
us.
So
our
proposed
approach
is
to
adopt
the
host
identity
tag,
which
is
a
legitimate
ipv6
thing,
but
it
is
not
a
locator.
It
is
an
identifier.
It
is
cryptographically
derived
which
gives
us
a
lot
of
benefits.
B
We
need
to
extend
it
to
provide
for
a
registry
hierarchy,
we
need
to
ask
ASTM
and
we
have
asked
them
to
assign
a
new
UAS,
ID
type,
which
would
we
have,
presumably
for
because
there's
only
one
two
and
three
defined
so
far
in
that
16-bit
field.
That
would
be
specifically
a
hierarchical
hit.
Now,
if
they're
not
willing
to
do
that,
we've
got
tricks,
we
can
do
and
I've
disclosed
these
tricks
to
them
kind
of
as
a
strategy
to
say:
hey,
look!
If
you
don't
go
along
we're,
gonna,
do
it
anyway,
but
we're
gonna.
B
B
Beauty
of
this
is
that
a
self
a
dirt
assertion
of
a
UAS
ID
fits
in
only
eighty
four
bytes
and
eighty
four
bytes
fits
in
for
Bluetooth
four
pages,
which
is
a
reasonable
number
to
hope
that
you
can
transmit
without
losing
a
page.
We
can
even
fit
a
registry
certificate
on
an
arat
now
I'm
using
the
word
certificate.
I
know
that
will
cause
some
howls
from
various
corners.
It
is
not
an
x.509
certificate,
it
doesn't
have
the
flexibility
of
an
x.509
certificate.
It
also
doesn't
have
the
bloat
of
an
x.509
certificate.
B
We
can
fit
it
in
two
hundred
bytes.
That
means
that
a
maximum
10
page
Bluetooth
form
message.
Even
if
we
dedicate
the
tenth
page
to
read,
Solomon
check
bytes
to
recover
a
lost
page
will
fit
a
certificate
that
says
yes,
this
unmanned
aircraft
with
this
identifier
and
this
public
key
really
is
in
this
registry,
and
you
can
verify
that.
B
Okay,
so
this
is
a
summary
because
mapping
a
physical
location
to
an
aircraft,
ID
smelled
like
mapping
a
persistent
host
identifier
to
an
IP
address
that
inspired
looking
at
hip
and
that
brought
us
some
other
benefits.
So
we're
proposing
two
minor
tweaks
to
ASTM
F
34
11,
which
their
leadership
has
said.
These
should
be
easy
lifts,
but
we
can
make
no
guarantees
of
what
our
you
know.
Committee
will
actually
ballot.
In
favor
of
we
proposed
some
improvements
to
some
of
the
hip
standards.
B
We
propose
using
EPP
our
nap
with
access,
controls
and
DNS
or
what
they
are
designed
to
be
used
for,
and
we've
actually
implemented
more
or
less
baseline
f34
11,
using
open
drone
ID
code
from
gabriel
cox
and
intel
as
a
model
wrote
our
own
python
prototype
some
of
these
extensions.
It's
worked,
we've
actually
flown
it
in
air
real
aircraft
and
then
winter
came
and
we
stopped
flying.
But
now
we've
added
some
code
to
actually
do
the
authentication
of
claims
in
UAS
read
messages,
and
we
will
fly
that
soon.
B
Next
slide,
which
I
think
is
the
last
yeah,
so
the
architecture
drafts
needs
work.
This
I
mean
it's
my
own
baby
and
I
will
call
it
ugly,
but
I
think
it's
maybe
good
enough
to
serve
as
a
basis
for
group
work.
So
maybe
we
want
to
adopt
it
next
steps
would
be
to
clarify
what
parts
of
it
are:
the
pre-existing
architecture
into
which
we
need
to
fit.
B
A
B
We'll
ask
Gabriel,
but
right
now,
ASTM
is
kind
of
lying
low
on
this
FAA
threw
them
a
curve
ball
with
the
notice
of
proposed
rulemaking
that
was
issued.
Krispies
and
FAA
then
got
an
all-time
record
number
of
comments
on
that
notice
of
proposed
rulemaking
over
50,000,
and
most
of
those
comments
were
negative.
B
Another
organization
that
has
invited
our
participation
is
ICAO,
not
you
know
not
not
with
official
standing
right.
We
can't
have
official
standing
within
ICAO,
but
you
know
informally,
I'm
now
participating
in
one
of
their
working
groups.
That's
involved
in
the
so-called
aviation
trust
framework,
and
we
would
really
like
to
make
what
we
do
fit
with
that
because
it
is
being
informally
said
by
a
lot
of
people
who
should
know
that
UTM
is
the
future
of
atm
manned
air
traffic.
It
is
very
hard
to
make
changes.
B
Unmanned
aircraft
has
been
the
world
West
up
to
this
point,
so
it's
easy
to
make
changes
and
what
we
try
there
if
it
works,
will
help
manned
aircraft
scale
out
for
denser
urban
operations.
So
it
would
be
really
good
if
we
aligned
with
what's
going
on
in
ICAO
s
international
aviation
trust
framework.
B
M
Have
another
question:
okay,
please
you
mentioned
several
times
the
the
problems
of
message
size
in
this
context,
which
I
can
certainly
understand,
but
then
you're
also,
if
I
understand
correctly,
proposing
to
use
domain
names
as
identifiers
and
I
guess,
the
main
aim
is
not
necessarily
the
most
compact
identification
format
that
we
can
imagine.
Is
there
any
conflict
in
that
area?
In
your
mind,
there.
B
Would
be
if
we
used
an
unconstrained
fqdn,
but
what
we
are
proposing
is
a
hip
hierarchical
host
identity
tag
which
is
16,
bytes,
looks
just
like
an
ipv6
address
and
is
in
fact
carved
out
of
the
ipv6
address
space,
and
so
that
can
simply
be
stuck
in
type
II,
six
DARPA
for
reverse
lookups.
That
can
then
lead
to
an
arbitrarily
ugly
fqdn.
If
somebody
wanted
one
or
they
could
actually
be
stuck
in
anything,
would
look
up
space,
presumably
dot
arrow.
That
would
have
a
relatively
flat
hierarchy.
Based
upon
the
the
the
same
hierarchy.
G
That's
just
sick
on
what
to
just
said
about
the
movement:
I
kill
you
I'm,
the
secretary
of
the
rust
framework
study
group
and
we
are
developing
and
we
have
the
participation
of
Europeans.
We
have
the
participation
of
FAA
and
I
have
the
participate,
participation
of
iock
right
manufacturers
as
well,
so
you'd
be
good
to
to
to
be
active
there,
so
we
can
develop
at
the
same
time,
so
we
can
have
hf
regulations
and
international
regulations
on
at
the
same
time,
take
the.
H
So
this
is
Adam
Whittaker
speaking
I
just
wanted
to
go
on
to
the
point
that
e/m
use
you
mentioned
for
the
fqdn
Stu
is
talking
about
reverse
lookups
forward.
Lookups
I've
been
implementing
the
forward
lookup
from
the
hit,
and
it's
just
you
instead
of
nibel
reversing
everything
you
kind
of
placed
the
unique
part
and
then
the
different
parts
between
da
identifiers
and
you
get
a
decent
leash
or
fqdn.
That's
human
readable.
If
you
want
to
consider
it
human
human,
readable,
I,
just
thought
I'd
put
that
out
there.
D
So
one
thing
I'd
like
to
mention
is
I
think
we
will
continue
to
work
on
those
documents,
but
we
absolutely
need
some
feedbacks
on
the
mailing
list
and
not
only
during
the
the
intern
meetings
and
I
mean
more
organization
can
commit.
I
mean
it's
the
right
time
now
so
I'm
really
encouraging
the
I
mean
all
these
older
people
representing
different
organizational
or
that
have
some
concerns
to
really
mention
them
now
on
the
mailing
list.
So
it's
gonna
come
soon.
The
other
thing
I'm
quite
unclear,
and
that
might
be
a
question
for
Eric.
D
Are
we
gonna?
How
are
we
going
to
proceed
maybe
formally
or
informally,
to
get
somehow
an
approval
from
those
for
use,
as
the
OHS
I
mean?
Are
we
in
is
the
process
that
we
send
them
the
document
and
say
this
is
what
we
intend
to
publish
and
we
wait
for
a
statement
from
them
or
I,
don't
know.
What's
the
exact
procedure.
D
F
Are
currently
personnel
document
it
should
be
adopted
by
the
working
group.
That's
the
route
in
group
called
for
adoption
and
I
really
encourage
everyone.
Is
this
call
and
in
this
working
group
to
reply
to
the
similar
on
this
and
the
second
step
in
it?
Getting
it's
not
mandatory,
but
getting
a
liaison
statement
both
way
between
the
ATF
and
this
specific
working
group
actually
to
the
ASTM
and
maybe
as
well
to
FA
and
AAA?
They
could
be
helpful
because
then
it
validates
basically
their
requirements
that
we
got
in
the
draft.
B
So
it's
to
here
this
is
us
only
this
next
comment,
but
ANSI,
the
American
National
Standards
Institute
serves
a
kind
of
coordinating
function
for
many
different
SD
O's
in
the
US,
and
they
have
released
a
three
hundred
plus
page
document
a
few
weeks
ago,
which
comments
are
due
in
a
couple
more
weeks
and
I
do
intend
to
comment.
Those
comments
will
be
without
standing.
It'll
just
be,
you
knows
two
cards
ideas.
F
Okay,
lipstick:
this
is
an
action
item.
I
need
to
leave
the
call
in
in
one
minute
or
two
for
another
one
time.
You
know
to
be
honest
with
all
this
like
I,
don't
think
so,
let's
keep
talking
used
to
the
two
chairs
myself
and
I
will
initiate
this
and
keep
the
working
group
aware
of
four.
So
the
discussion.
A
Can
do
it
anyway,
so
just
yes,
yes,
so
yeah
please
go
on
this
is
D
and
I
remained
what
still?
What
produce
it
is
that
do
we
have?
We
have
already
ended
to
a
call
for
the
adoption
of
the
requirement
draft.
So
please
send
your
I
would
say
your
cameras
on
the
list
and
say
with
the
real
support,
or
it
is
also
for
that
document.
A
We
need
more
feed
from
the
working
group
to
understand
whether
we
are
on
the
right
track
or
not,
and
just
right
after
the
meeting
we
will
be
issuing
a
call
for
adoption
for
the
architectural
document.
It
is
not
that
stable.
We
know
that,
but
it
does
not
need
to
be
stable
for
the
adoptions,
but
it's
we
need
to
have
your
feedback.
Whether
this
is
a
good
I
would
say,
bases
are
certain
point
to
to
work
on
architecture
and
for
the
others.
I
think
that's
yeah,
please.
A
We
are
seeking
for
feedback,
and
the
more
will
get
feedback
now
and
concerns
about
the
approach
which
is
done
by
the
working
look.
It
will
be
really
useful
for
us
because
we
need
to
describe
the
work
and
also,
they
would
say
to
have
more
I
would
say
coordination
with
the
other
organization
hard
when
we
were
working
on
the
or
this
area.
So
please
reply
to
I
would
say
to
to
the
list
and
send
to
your
feed,
but
yeah
thank
I.
Think
that's
we
are.
We
are
now
at
the
end
of
the
each
of
these
meetings.