►
From YouTube: IETF111-DRIP-20210728-2130
Description
DRIP meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
I
assume
you've
read
it
so,
basically,
where
we
are
in
into
that
working
group.
I
might
I'm
just
gonna
do
go
through
the
working
group
status
and
then
maybe
I'm
gonna
ask
the
ad
if
they
have
anything
to
ask
and
then
we'll
probably
move
to
the
presentations
so
where
we
are
now
so
we
we
had
a
requirement
draft
which
has
been
sent
to
the
asg
and
now
we're
heavily
working
on
the
architecture
draft,
and
I
expect
this
session
to
be
the
one
closing
the
I
mean
this
working
group
last
goal.
A
A
Then,
once
we
have
those,
I
would
call
them
preliminary
documents.
We
can
focus
on
the
solution
space
and
we
have
an
rid
document.
A
It
already
has
had
some
iot
and
secure
reviews.
I
guess,
but
as
far
as
I've
seen
I
mean
they're,
not
I
mean
we
need
some,
probably
additional
reviews
so
and
we
also
have
the
auth
document
so
it
which
is
also
one
document
that
we
you
should
ship.
I
mean
a
relatively
in
a
relatively
short
delay
once
the
architectural
document
is
going
to
be
sent,
and
then
we
have
one
document
that
is
related
to
the
registries.
A
A
So
a
big
change,
I
would
say
with
that
working
group-
is
that
we
didn't
have
as
many
interim
meetings
as
we
used
to
have
I'm
just
wondering
if
anyone
has
wants
to
share.
If
you
think
that
interim
meetings
more
interim
meetings
would
be
needed
if
they
are
useful
to
to
make
the
work
progress
or
if
we're
fine,
to
do
as
we
are
doing
on
the
mailing
list.
A
So
if
you
have
a
two
minutes
to
say
something
around
this
organization
of
the
working
group
and
then
I
will
ask
our
ad
eric
if
he
has
anything
to
say.
C
Astm
is
working
toward
a
face-to-face
meeting
on
oh
early
october,
so
if
we
should
be
working
at
having
the
rid
and
the
auth
document
well
in
shape
for
early
october
for
us,
interacting
with
astm
having
face-to-face
potentially
in
in
august
september,
to
accomplish
that
could
be
important
somehow
other.
We
want
to
have
those
two
documents
not
to
wait
to
the
november
ihf
meeting,
but
instead
target
our
audience,
which
is
astm
for
their
meeting
in
october.
A
It
mostly
depends
on
the
response,
restfulness
or
responsiveness
of
of
the
working
group,
and
I
think
we're
pretty
good
for
now,
but
we
have
been,
we
had
a
a
huge
gap
so
but
I
don't
see
those
october
deadline
as
infeasible.
A
D
Okay
here,
I
also
believe
a
interview
is
going
to
be
very
useful
in
terms
of
the
architecture
we
have
been
quiet
for
so
long,
then
get
all
the
comments
in
last
month
or
so
so,
even
though
we
can't
give
this
feedback
update,
there
will
be
no
time
for
others
to
review,
so
I
believe
that
that
would
be
definitely
useful.
D
D
Only
a
close
group
people
in
the
author
or
chairs
has
access
to
it.
Then
in
in
order
to
get
a
moral
comment,
feedback
with
the
meaningless,
I
have
to
actually
compile
a
different
meaning
thread
in
the
mailing
list,
so
it's
kind
of
repeated
work.
D
So
it's
also
hard
for
authors
and
whoever
commented
to
reply
and
then
I
have
to
close
in
both
places.
So
I
don't
have
a
very
good
solution.
Either
we
make
the
github
public
everybody
and
whenever
we
have
comments,
we
refer
to
the
github
link
by
the
pr's
or
we
stick
it
to
the
meeting
list
just
by
pressing.
So
one
place.
A
Yeah
so
I
mean
the
github
is
public,
but
it
doesn't
mean
that
every
people
look
at
these
issues.
A
I
know
that
in
some
working
groups
we
have
the
bunch
of
issues
that
is
regularly
be
sent
to
the
mailing
list.
To
be
honest,
I
haven't
found
out
how
to
configure
that.
So,
if
anyone
can.
A
D
I
know
carson
or
hank,
I
don't
think
they
are
in
the
call
right
now
they
actually
okay.
B
A
Okay-
okay,
I
I
I
will.
I
will
ask
some
folks
how
to
do
that
and
make
make
sure
it's
going
to
be
working
eric
eric.
E
Yes,
danielle,
as
you
asked
me
for
my
point
of
view
on
the
drip
working
group,
so
first
quite
happy
to
see
at
least
one
document
coming
into
the
isd,
even
if
there
is
still
a
one
this
case
on
it,
I'm
pretty
sure
it
will
be
solved.
Roman
reigns
and
a
nice
question.
It's
just
a
matter
of
stu
and
roman.
To
talk
about
it.
So
good
regarding
bob
is
pretty
much
what
you
said
daniel.
E
E
That's
a
concern
of
mine,
because
normally
this
is
the
meaning
list.
That
is
the
official
media.
This
is
where
the
consensus
needs
to
be
reached.
Of
course
nothing
prevents
authors
and
editors
and
everyone
to
participate
on
the
issue
tracking
of
the
guitar,
but
don't
forget
the
consensus
is,
is
basically
made
on
the
mailing
list,
so
the
balance
is
not
easy
to
reach
and
we
need
to
work
on
this
for
in
whatever
my
working
group
against
my
audience,
some
audience
are
more
used
to
githubs.
Some
are
less
that's
all.
E
I
I
wanted
to
say
here
mp2
series
working
group
going
forward,
and
maybe
we
can.
We
need
some
more
interims
if
we
want
to
get
some
october
deadline,
even
if
they
are
not
iitf
deadline.
But
I
understand
that
other
sdos
are
important.
A
Okay,
good
I've
taken
the
point,
so
the
agenda.
A
Yeah,
we
probably
need
someone
to
take
some
notes,
not
I'm
thinking
about
it
daniel.
I
just.
F
A
Okay
right
so
looking
at
the
agenda,
I'm
asking
if
anyone
can
take
some
notes,
some
we
would
like
to
have
maybe
a
minute
taker.
A
I'm
not
sure
we
need
a
job
I
want,
but
a
mini
attacker
would
be
good
and
as
soon
as
we
have
a
minute
taker,
I
will
give
the
floor
to
bob.
E
And
sorry
to
book
you
danielle,
we
do
need
a
minute
taker.
Now,
yes,
it's
recorded.
So
if
somebody
wants
to
take
the
minutes
after
the
meeting,
it's
still
doable,
but
we
need
to
get
the
minutes
and
we
can
start
without
a
volunteer
on
this
and
med
is
unable
to
join.
So
we
have
only
one
chair
today,
so
we
cannot
rely
on
the
poor
danielle,
who
is
doing
a
one-long
show
today
or
tonight.
D
Then
I
do
it
if
somebody
can
take
a
news
when
I'm
present.
A
C
Okay,
am
I
coming
through
clear,
yeah,
good?
Okay?
This
is
a
presentation
of
the
latest
draft
that
I
posted
on
sunday.
This
is
the
version
808
and
it
did
it
was
submitted
on
sunday.
So
it's
you
only
had
a
little
bit
of
time
to
read.
So,
let's
review
the
changes
and
what
I
need
to
do.
409,
please
come
okay,
remember
our
target
audience
for
this
document
is
people
outside
the
itf,
it's
the
regulators
and
the
ma
and
the
manufacturers
of
the
of
of
the
amen
aircraft
systems
that
this
is
targeted
to.
C
So
read
this
document
as
an
itif
outsider,
might
help
me
get
what
when
I
get
lost
in
the
weeks,
look
at
this
document
and
say
what
do
I
need
maybe
to
expand
upon?
What
do
I
need
to
improve
my
references
to
maybe
not
do
references
if
there's
hispanic
texts,
but
remember
that
our
audience
are
manufacturers
of
the
uas?
Why
should
they
take
this
approach
versus
just
putting
just
their
manufacturer
id
in
or
just
using
your
id?
C
C
So
what
are
my
updates?
Most
of
the
dependencies
have
moved
to
the
core
I've
pretty
much
just
done
a
a
move
and
note
that
rfc
diff
gets
lost.
When
you
make
these
sorts
of
moves,
it
doesn't
know
any
changes
I
made
in
dependencies.
It
did
not
highlight
so
you
really
got
to
go
through
it
this
this
sort
of
a
of
a
change.
I
don't
see
how
rrc
diff
works
with
it.
I
made
a
major
cleanup
of
the
iana
considerations.
C
This
document
adds
to
the
hip
registry,
so
I
put
very
explicit
instructions
to
iana
on
what
exactly
they
need
to
change
in
the
registry.
For
that
there's,
some
minor
alignment
real
a
lot
realignment
to
changes
made
in
the
requirements.
C
I've
had
a
number
of
comments
that
about
x509
section,
which
shows
that
I
wasn't
getting
across
about
x509.
So
I
hope
I
have
improved
the
text
there
and
I've
cleaned
up
the
text
elsewhere,
a
bit
as
well
next
slide.
C
Now
it's
only
in
one
place
that
I
did
consolidate
and
because
I'm
not
done
yet,
but
at
least
now
you're
only
going
to
see
that
in
one
place
all
these
sections
still
need
editor
review
because
for
the
most
part
I
just
moved
them.
I
did
not
edit
do
much
of
the
way
editing
the
content
and
I
really
need
to
work
over
the
new
section
6,
which
is
the
proof
section
adam,
and
I
really
need
to
to
fine-tune
that
and
make
sure
we
got
it
done
well.
C
C
So
the
text
in
iana
considerations
and
throughout
now
better
instruct
ayanna
on
what
is
needed.
I've
copied
from
other
documents,
I've,
I've
done
and
or
elsewhere,
and
I
think
I
have
a
good
set
of
in
instructions.
C
So
please
review
this
note
that
I
am
one
of
the
the
I
am
the
hip
registry
experts,
along
with
jeff,
so
other
eyeballs
out,
because
it's
like
yeah,
I
would
approve
it.
But
that
is
not
the
point.
So
please
people
take
a
look
at
the
diana
considerations
edsa.
C
It's
still
a
draft
for
those
who
are
on
sag
yesterday,
ira
posted
that
in
the
post
quantum
workshop
this
postcard
workshop
in
june.
This
did
say:
oh
we're,
sorry,
for
the
delay.
We
hope
we
expect
to
get
this
done
soon,
and
this
is
important
because
we
are
using
eddsa
we're
putting
it
pointless
to
it
for
iko
in
their
digital
identity
in
their
it
will
go
into
their
certificate
policy
and
they
don't
want
to
reference
an
rrc.
C
They
want
to
represent
repre
reference,
f5s
document,
so
just
that
you
know
that
that
ecdsa
really
doesn't
work.
Couldn't
work
for
this
eddsa
has
the
the
features
we
need,
but
eddsa
is
just
an
ihf
rc.
It's
not
yet
a
fips
standard,
but
you've
been
told
finally
soon
and
it
does
affect
iko
work
and
in
their
certificate
policy
and
where
this
also
place
it
next.
C
Expanding
the
x509
comparison
comments
made
it
clear
that
I
was
not
clear,
hopefully,
that
the
text
introduction
is
better
now,
look
at
it
see
if
you
under
see
how
you
read
it
and
what
you
get
out
of
what
I
say.
I
do
not
want
to
label
the
point
as
this
is
the
document
on
rid
using
http,
not
x509
but
note
elsewhere
in
the
uas
utm
ecosystem,
x5
and
inserts
are
important,
so
there
will
be
a
connection
some
way
or
another,
and
this
may
mean
either
some
additional
work
either
here
or
the
septic
draft.
C
C
The
hits
as
as
the
6060
2063
numbers
adam
says
he
has
a
python
script,
almost
ready
for
me
and
it's
almost
working
so
I'll
need
to
get
that
from
adam
and
see
how
it
works
to
see.
If
I
can
then
have
examples
to
put
into
this
section
as
a
result,
so
stay
tuned
on
that
I
don't
have
to
ask
them
to
do
the
python.
It's
adam
has
been
busy
often
one
of
his
many
corners.
C
C
I
really
need
to
tighten
up
the
proof
section
or
loosen
up
with
more
text,
and
people
need
to
understand
this,
but
there's
also
a
question
how
much
of
this
belongs
in
the
rib
document?
Now
that
we
had
adam's
off
document,
does
this
section
really
belong
in
red,
or
do
I
reference
the
auth
document
and
we
rip
almost
all
of
this
out
of
the
red
document?
C
That's
important
point
in
conversation,
and
I
want
comments
and
feedback
and
guidance
on
that
before
I
spend
a
lot
of
time
improving
this
this
section
and
there's
some
other
things
I
need
to
fix
and
expand
and
like
it
would
for
those
of
you
who
have
not
been
noticing
inset
stu,
adam
and
I
have
been
making
astm
is
now
imbalancing
on
version
1.1
of
the
remote
id
standard.
C
This
will
almost
for
sure
come
out
still
this
year,
so
we
have
34
11-21.
How
long
does
it
know
if
we
go
right
to
the
balloting
writer
don't
have
to
rebalance?
C
It
could
come
out
very
quickly
when
it's
published
you'll
see
that
I
have
to
make
changes
in
the
writ
document
and
adam's
going
to
make
changes
in
his
auth
document
to
match
up
with
what
they
what
we
were
able
to
get
them
to
do.
We
didn't
get
everything
we
wanted,
but
we
got
enough
of
what
we
wanted.
C
Magnus
made
some
comments
in
his
sector
review
about
some
things
and
adam
has
given
me
some
python
scripts.
Do
I
put
those
python
scripts
right
in
the
document?
The
the
hd
gen
python
script
is
249
lines
long.
Do
I
put
that
right
in
the
document,
or
do
we
put
that
in
github
with
some
pointer?
How
do
we
handle
something
like
that
in
our
documents
now,
so
that's
more
for
our
a.d
and
our
chairs.
C
How
they
want
to
handle
adam
also
has
a
poison
resistant
script
that
we've
used
magnus
asked
about
by
issue
about
the
second
pre-image
attack.
I
haven't
seen
anything
good
in
the
literature
about
that
and
all
we've
done.
You
know
if
we
can't
generate
collision.
Collisions
cash
collisions
what's
a
chance
of
getting
second
image
attacks,
so
but
that's
the
that's
that
part
of
and
we,
so
what
do
we
need
to
do
for
that?
C
Do
we
put
these
scripts
in
the
document
which
would
blow
the
document
a
lot
of
pages,
or
do
we
put
them
on
the
github
and
do
we
reference
them
in
the
github
guidance?
Please.
The
next
note
about
hcits
to
cta
numbers
adam
says
he's
got
something
for
me.
So
we
construct,
I
have
to
work
on
it,
but
I
don't
have
to
ask
for
help
other
than
adam.
Getting
me
the
script.
C
There
are
a
couple
other
things
in
the
sector
review
that
I
need
to
take
to
the
cfrg
list.
There's
the
half
size
discussions
a
few
other
things.
These
are
20
year
old
issues.
What
does
a
small
hash
mean?
What
do
the
collisions
mean,
and
it
gets
also
then,
to
the
registry
that
how
we're
counting
on
the
registry
to
eliminate
duplicates
and
to
defend
against
the
second
image
attack
somebody
actually
be
able
to
pull
it
off.
C
So
that
completes
the
changes
which
I've
made
in
draft
08,
where
I
think
I
need
to
go
for
draft
09.
I
hope
to
be
able
to
focus
in
in
the
next
few
weeks
to
get
an
09
out
based
on
comments,
which
means
please
everybody
give
some
comments.
E
Thank
you
both
for
the
summary
there
and
the
update
regarding
the
crypto
forum.
I
think
this
is
really
mandatory.
Magnus
there's
a
good
point
there
for
that
to
the
crypto
from
research
srp
as
soon
as
possible.
As
an
earlier
review
now
regarding
the
title
script,
I
am
really
ambivalent.
There,
it's
slower
so
to
be
an
appendix
into
the
rfc.
E
Allowing
everyone
to
run
it
basically,
but
it's
not
me
to
decide
on
this
specific
aspect
towards
grouping.
C
I'll
take
it
to
the
list
I'll
ask
for
know
what
people
want
to
do,
we'll
we'll
make
the
the
python
scripts
available.
So
people
can
say
yeah.
It's
only
240
lines,
long
put
it
in
the
document
or
something
like
that.
A
I
think
if
we
have
some
code,
unless
we
want
to
use
that
code
to
explain
what
we're
saying
if
we
want
to
run
it,
it's
always
better
to
have
a
link.
So
in
any
case,
I
I'd
like
to
link
into
the
the
rfc.
A
And
well,
that's
it,
that's
that's
how
we
want
to
use
it
regarding
a
code
of
one
mega.
Did
you
mention
so
200
line
is
fine?
Is
the
double
larger
codes
might
be
a
little
bit
tricky.
C
I
don't
know
how
big
adam's
other
scripts
are,
because
he
hasn't
given
me
those
other
scripts.
I
just
know
he's
done
the
work
for
for
us
I
mean
it's
just
the
one
that
he's
given
us
so
I'll
have
to
see
how
big
they
are.
Yeah.
The
script
that
he
did
is
that
we
ran
through
was
able
to
run
through
a
million
hsit
generations
and
determined
that
there
were
no
collisions
within
that
one
million
generated,
so
we're
not
getting
any
hash
collisions
in
a
population
that
size.
C
That
was
what
that
was
about,
and
that's
like.
A
So
next
I
I
think
it's
we
can
go
to
the
architecture
document.
Why
do
you
want
to
present.
F
D
All
right,
so
I'm
just
doing
all
right,
I
think
adam
is
taking
over
the
note
race
right.
So
this
is
the
update
defense.
Our
first
working,
google
last
call
next
slide.
Please.
D
So
currently
we
have
a
dividend.
15..
We
have
addressed
a
lot
of
comments.
I
will
see
most
of
editorial.
D
There
are
a
few
major
concerns
from
stu
just
coming
in
a
week
after
a
month
before
the
meeting,
so
we
bob
and
I
tried
to
address
it
and
the
revenue
15
have
some
of
the
comments
in
there.
I
did
see
stuart
has
a
reply.
Yesterday.
D
I
haven't
got
time
to
review
that,
yet
maybe
stu
can
express
his
major
concern
from
that
email
during
the
meeting,
but
anyway,
so
mostly,
I
have
compiled
all
the
issues
and
in
the
mailing
list,
as
well
as
in
the
github
link,
so
I
managed
to
close
with
some
feedbacks
so
mostly
yeah.
So
that's
all
right,
so
I
was
looking
for
comments
and
feedbacks
from
from
from
those
issues.
D
So
hopefully
I
can
get
some
for
the
for
the
next
revision
next
slide,
please
so
for
for,
for
this
planet
is
only
one
thing
I
actually
want
to
bring
up
to
the
working
group.
It's
something
we
have
been
discussed
and
never
get
a
conclusion,
or
never
actually
talk
about
that.
It's
regarding
if
we
should
treat
hditx
the
only
one
drip
I
identified
in
the
itf,
because
the
primary
means
for
me
that
is
secondary
right
if
there's
no
secondary,
I
think
there's
no
point.
D
We
have
the
primary,
so
that's
that's
one
thing
bob
has
commented
on.
I
also
send
the
question
to
the
main
list.
I'm
not
sure
if
people
saw
that,
hopefully
we
can
resolve.
At
least
this
question
in
this
meeting
receives
more
comments.
Next
slide.
D
Yeah
that
that's
that's
the
only
thing,
so
all
the
all
the
feedbacks
comments
in
the
mailing
list
and
github
to
please
go
there,
look
at
it
if
the
improved
text
has
addressed
your
concern,
so
maybe
we
can
go
back
to
slide
three
see
if
we
can
at
least
solve
this
problem
regarding
if
hhit
is
actually
the
primary
one
or
we're
just
the
only
one
in
iot.
D
A
Wondering
so
please
explain
what
are
the
pro
and
cons
and
where
the
discussion
is
so
we
can.
A
C
C
To
the
list
on
this,
it's
again
my
position
that
our
audience
is
the
uas
regulatory
community.
The
ietf
needs,
in
my
highly
biased
opinion,
needs
to
speak
out
as
a
voice
to
that
community.
Here's
how
we
say
to
do
the
remote
id
in
a
trustworthy,
secure
manner.
Now
here's
one
way.
This
is
our
way
of
doing
it.
C
I
should
point
out
that
qualcomm
3gbp
is
pushing
1609.2
as
their
way
of
doing
it,
they're
not
bringing
their
approach
to
ietf
they're,
doing
it
through
three
gbp
so
ietf
way
of
doing
it,
3gbp,
maybe
a
way
of
doing
it
and
the
pros
and
cons
of
each
be
discussed
in
the
large
community,
but
the
ietf
say
this
is
how
we
see
it
to
work
with
our
technologies.
C
We've
been
at
this
now
two
years
there
have
been
no
other
approaches
put
forth,
and
so
that's
why
I
say
this
is
our
proposal,
not
our
primary
proposal.
It
is
about
truly
about
marketing.
A
Yes,
so
I
I
think
the
debate
was
that,
because
it's
an
architecture
document,
it
might
be
sufficiently
generic
to
to
be
reused
by
a
potential
other
solutions.
A
Now,
if
you
look
at
the
architecture,
it's
I'm
not
so
sure
I
mean.
If
we
we.
If
we
were
to
come
with
another
solution,
it
would
have
a
major
impact
on
the
document.
So
my
personal
feeling
is
that
we
should
not
try
to
it's.
We
should
not
try
to
say
we
are
expecting
to
give
the
message
that
we're
expecting
multiple
solutions
to
to
be
standardized.
A
And
it's
not
that
we're
really
closing
those
solutions,
but
if,
if
another
solution
is
coming
yeah,
it
might
be
integrated
in
a
document
that
specifies
how
it's
going
to
be
integrated
to
the
current
hip
or
if
it's
going
to
replace
it
completely
or
whatever,
but
so
yeah.
I
I.
A
I
am
sort
of
thinking
that
we
should
not
try
to
open
the
door
to
something
that
is
not
necessary
to
be
open.
C
C
B
Something
stu
here
share
the
computer
with
with
with
adam
I
just
want
to.
B
I
just
want
to
mention
that
the
impetus
for
the
creation
of
the
drip
working
group
started
with
my
coming
from
the
aviation
community
and
going
to
bob,
because
I
happened
to
be
familiar
with
his
work
with
hip
and
suchlike,
and
I
felt
that
a
host
identity
tag
was
an
eminently
suitable
identifier
and
in
the
two
years
that
it
has
been
no
one
has
stepped
forward
with
another
one,
and
I
I
fully
agree
with
bob
that
we
should
not
weaken
our
position
in
dealing
with
other
standards,
development
organizations
and
regulators
by
obviously
hedging
our
bets.
B
E
There
is
one
thing
that
is
important
in
atf
is
whether
the
charter
is
defined,
one
solution
or
multiple
solution.
It's
really
important
to
respect
the
charter
or
we
need
to
respect
the
ch
or
recharge
the
working
group.
Everything
is
possible
right,
but
it's
really
important
and
if
we
don't
follow
it,
it
will
cause
problems
later
in
the
process.
E
A
Yeah,
so
I
can
have
a
look
at
the
charter
right
now,
but
I
don't
see
this
as
going
fundamentally
against
the
charter.
F
F
A
A
A
Yeah,
so
let
me
ask
a
question
who
is
willing
to
who
is,
who
thinks
that
secondary
is
should
be,
because
I'm
only
hearing
that
secondary
is
a
primary
is
not
so
much
needed.
So
do
we
have
anyone
that
is
pushing
for
having
secondary.
A
So
I
mean
currently
I've
only
I'm
only
hearing
the
point
of
view
of
people
that
do
not
want
to
open
that
door
and
want
to
remove
this
primary
term.
So
I'm
just
wondering
if
we
have
anyone
thinking
that
we
should
have
this
primary
into.
A
A
A
So
my
question
was
as
the
editor
of
the
document
and
it's
an
issue
we
want
to
solve.
Do
you
know
what
are
the
arguments
for
keeping
primary
into
the
text.
D
Well,
so
I
took
over
this
draft
long
before
the
primary
was
there.
So
I
don't
understand
the
history
why
we
have
the
problem
in
the
first.
I
think
we
should
ask
ourselves
why
we
have
the
problem
in
the
first
place.
That's
not
something
I
don't
know,
I'm
sorry,
I'm
just
that
doesn't
enjoy
do
dripping
at
the
beginning,
so
it
probably
was
there
a
long
time
ago.
A
D
The
second
thing
is,
I
think,
is
the
bob's
position.
As
I
mentioned,
it
has
been
two
years
as
we
discussed.
Stu
also
has
a
expertise,
opinion
that
we
don't
have
any.
We
haven't
seen
a
second
solution
on
on
this
issue,
so
I
would
just
drop
it.
D
For
yeah
for
the
safe
purpose,
we
can
send
this
as
to
the
minion
list,
saying
that
we're
gonna
drop,
that
unless
we
have
a
behavior
here
different
voice
and
give
a
data
line
for
like
a
week
or
so
after
the
meeting
right.
A
No,
so
I
expect
to
have
a
version
15
next
week.
F
D
This
is
we
have
here.
The
current
one
is
of
around
15
already.
A
Okay,
so
that
so
so
we
have
all
the
latest
changes,
because
I
mean
you,
you
started
saying
that
you
had
some
discussions
with
adam
and
sue.
Oh.
D
Yesterday,
I'm
just
getting
through
it,
it
looks
like
some
editorial,
I
think
still
maybe
has
comment
on
the
section
5
regarding
more
text
regarding
the
architecture,
I
think
my
question
is
you
still
want
to
discuss
on
the
list
or
you
want
to
explain
a
little
more
if
the
if
the
requested
text
is
ready
in
the
different
draft,
which
I
have
no
problem
to
just
kind
of
refreeze
it
and
put
in
architecture.
D
So
this
is
the
question
if
the
the
things
you
requested
is
is
already
there
in
a
different
draft.
Okay,
I
can
just
organize
the
language
and
put
in
the
section
five.
A
Okay,
because
my
question
is
if
we
can
have
a
next
version
next
week,
we
may
ask
for
some
people
to
to
review
that
version.
D
Yeah,
that's
that's
really.
If
stu
can
give
me
a
brief
answer
or
maybe
in
the
list
because
he
sent
it
to
the
to
us
right,
not
not
in
the
meaning
list,
then.
B
B
Yeah,
I
can
give
you
a
real
high
level
short
answer
right
now.
I
think
your
latest
revision
addresses
almost
all
of
my
editorial
knits
and
it
begins
to
address
my
substantive
concerns,
and
I
do
not
believe
that
you
can
further
address
my
substantive
concerns
until
the
working
group
achieves
a
consensus
on
how
we
want
to
go,
and
I
actually
bring
that
up
in
my
slides
later.
A
B
Okay,
you
want
me
to
go
there
next
sure,
great
sure,
okay,
so
I
call
this
requirements
and
related
issues
next
slide.
B
Okay,
so
there
these
are
the
one
two
three
four
five
six
things
I
want
to
briefly
talk
about
we're
doing
some
interoperability
testing,
some
functional
demos
astm
is
revising
their
f-3411,
as
bob
alluded
to.
We
have
a
discuss
and
I'm
hoping
that
eric
can
get
roman
to
join
us
to
explain
his
discuss.
B
There
is
a
more
complete
scenario,
figure
which
I'm
hoping
will
go
into
the
architecture
document
it
went
into
and
was
pulled
back
out
of
the
requirements
document.
I
think
it
might
help
people,
including
roman,
understand
the
issue
that
led
to
romans
discuss.
B
Then
I
would
like
to
suggest
what
I
think
the
relationships
ought
to
be
between
the
various
documents
that
we're
working
on
and
then
I
think
that
leads
into
some
very
fundamental
questions
for
the
working
group
that
we
need.
Consensus
on
before
schwei
or
I
or
bob
can
really
proceed
next
slide.
B
Okay,
so
adam
worked
with
a
utm
provider
that
had
independently
developed
a
baseline,
astm,
f,
3411
implementation.
B
Our
drip
stuff
is
all
basically
enhancements
to
the
astm
f3411
standard
and
adam's
implementation
of
f3411,
with
our
drip
enhancements
successfully
interoperated
with
the
baseline
f3411
implementation
that
was
independently
developed.
Now
that
doesn't
say
that
our
drip
enhancements
are
interoperable
with
anybody,
because,
as
far
as
we
know
so,
nobody
else
has
yet
implemented
our
drip
enhancements.
B
But
it's
a
step
in
that
direction
and
the
pictures
below
show
where
adam
and
our
adam-
and
I
are
right
now-
we
are
out
in
the
great
plains,
and
people
are
flying
lots
of
aircraft
and
we're
simulating
lots
more
and
we
are
demonstrating.
B
You
know
the
drip
work
to
the
u.s
department
of
homeland
security
and
so
on
and
so
forth.
Okay,
astm,
the
the
revision
that
they
are
balloting
on
right
now
has
everything
in
it
for
drip
to
be
a
recognized
extension,
the
uas
id,
that
is
in
the
basic
id
message.
There
were
formerly
three
types
and
we
were
ex
and
we
were
asking
for
type
4
to
be
allocated
for
drip.
They
did
not
do
exactly
that,
but
they
did
something
that
works
out
nearly
as
well.
B
They
created
a
type
4
which
is
for
a
so-called
specific
session
id,
as
opposed
to
the
type
3
which
is
which
is
a
utm
system
assigned
id,
and
then
there
will
be
subtypes
of
this
type.
4
and
subtype
number
1
in
in
astm.
F3411
draft
is
ietf
drip,
subtype
2
will
be
from
ieee,
and
then
there
can
be
other
subtypes.
B
The
only
cost
to
that
is
that
the
subtype
index
choose
up
one
of
our
bytes,
so
the
20
bytes
that
we
used
to
have
for
our
identifier
are
down
to
19
bytes,
which
still
we
fit
an
h,
hit
at
16
bytes
comfortably
within
that,
and
should
somebody
someday
actually
step
forward
within
ietf
with
another
proposed
drip
entity.
Identifier,
great
we've
got
three
bytes
that
we
can
use
to
demultiplex
between
h
hits
and
whatever
they
come
up
with.
B
This
allows
for
numerous
authentication
formats
to
be
devised,
and
adam
is
expecting
that
we
will
want
to
register
probably
four
subtypes
for
drip
authentication.
You
know
a
type
for
a
certificate,
a
type
for
a
signed
message,
type
for
this
type.
For
that.
B
The
other
thing
that
I
want
to
mention
on
while
we're
talking
about
the
revision
of
this
standard,
is
that
the
faa-
which,
admittedly,
is
only
one
of
the
civil
aviation
authorities
in
the
world,
but
it's
it's
one
of
the
major
ones
they
know
they
need
help
with
session
ids,
and
we
are
hoping
that
we
can
submit
our
drip
documents
as
so-called
means
of
compliance,
so
the
faa
can
say:
oh
yes,
this
is
a
way
that
that
we,
the
faa,
accept
as
a
way
of
securely
managing
issuing
and
so
on
session
ids.
B
A
B
Okay,
roman
made
a
number
of
comments
and
he
also
lodged
a
a
disgust
and
a
interview
on
this
one
roman
just
joined
the
call
yeah
rather
than
me
talk
about
that.
Perhaps
roman
could
could
step
up
to
the
microphone
and
explain
his
his.
B
H
Sure
so
my
so
the
crux
of
my
discuss
is
we
provide
some
really
nice
crisp
security
properties
that
we
want
in
the
requirements
document,
which
is
great.
My
concern
is
that
there's
a
number
of
places
in
the
document,
then
that
caveat
that
you
know
the
strength
of
those
requirements
and
so
what
it
sends
the
message
to
me
that
what
we're
saying
is
that
these
are
best
effort
requirements
and
that's
a
little
inconsistent
with
well,
not
a
little.
It's
inconsistent
with
using
rfc2119
language.
H
H
That's
the
crux
of
it
and
then
I
think
in
the
in
my
follow-up
mail
to
I
think
the
the
last
bullet,
which
is
you
can't
satisfy
everything
because
you
cut
the
underlying
ethernet
cable
yeah,
that's
completely
understandable,
but
I
think
the
way
you
manage
making
security
guarantees
with
the
fact
that
there
is
a
layering,
a
layered
architecture
or
that
you
have
dependencies
is
that
you,
you
draw
some
boundary,
some
scope
around,
which
you
provide
the
guarantees
and
if
those
things
are
in
the
architecture
outside
of
that
bubble,
the
guarantees
don't
apply.
H
A
Yeah,
so
probably
should
I
mean
med
is:
is
the
document
shepard
for
that
one?
A
So
I
can
it's
not
nice
to
do
that
to
my
culture,
but
so
I
haven't
been
following
those
discussion
very
closely
for
sure
I
I
tend
to
agree
with
with
roman
saying
that
we
cannot
have
a
must,
with
exceptions.
A
And
it's
something
I
I
really
see
well
into
those
documents.
Is
there
anything
blocking
on
on
your
point
I
mean,
is
it
should
having
issued?
Is
it
something?
Is
it?
Is?
It
gonna
be
the
end
of
the
world
in
the
requirements?
B
I
hate
to
let
implement
I
hate
to
give
implementers
a
carte
blanche
to
not
satisfy
the
requirement.
You
know
I
would
like
to
somehow
work
out
language
that
makes
it
clear
that
you
know
when
a
particular
link
is
present.
That
allows
this
to
be
done.
B
Then
you
indeed
must
do
it,
but
that
that
link,
indeed
will
not
always
be
present,
and
so
you
are
not
being
required
to
do
it
when
it
is
physically
impossible
to
do
it,
and
so
I
think
that
roman's
position
in
mind
can
somehow
be
reconciled
with
appropriate
language,
because
when
you
can
do
it,
it
is
indeed
a
must,
but
we
just
know
for
a
fact
that
you
won't
always
be
able
to
do
it
due
to
the
underlying
physical
connectivity
scenario
and
the
physical
connectivity
is
not
under
the
control
of
a
drip
protocol.
H
C
At
it,
I've
been
through
this
with
roman
on
other
things.
I
know
where
he's
coming
from
and
so
see.
Let's
see
what
I
can
do
to
help
stew
out
with
the
the
language,
nuances,
roman
and
I've
been
around
this.
This
particular
merry-go-round
number
times
sure.
F
So
this
is
actually
adam
speaking.
You
were
talking
to
stu,
but
because
we're
sharing
a
computer
today,
I'm
wondering
being
somewhat
naive
on
this,
would
it
be
a?
Could
you
put
should
and
then
must
directly
after
it?
You
should
do
this.
If
the
link
is
there
blah
blah
blah
blah,
and
if
it
is
there,
you
must
be
doing
it.
Is
that,
like
overlaying,
those
two
in
the
sentence
make
any
sense
asking
from
a
naive
perspective.
C
Here
be
dragons,
adam,
we'll
work
it
out
and
we'll
just
take
this
off
on
the
side
and
come
back
with
some
wording
and
and
see
if
we
can
get
address
roman's
points.
I
I
hear
clearly
where
he's
coming
from.
Okay.
B
So
I
guess
the
only
question
that
I
have
right
now
for
the
working
group
is,
you
know
as
editor
of
requirements,
I
don't
feel
empowered
to
change
the
numbered
requirements
to
which
we
have
agreed
and
that
made
it
through
working
group
last
call,
I
feel,
empowered
to
make
clarifications
in
the
supporting
prose
text
right.
B
So
what
I
would
like
to
know
is:
is
it
the
working
group's
consensus
that
I
can
you
know
in
in
cooperation
with
roman
and
bob,
and
so
on,
tweak
the
wording
of
the
numbered
requirements
to
clarify
that
musts
are
musts
when
they're
physically
possible,
given
the
lower
layers
and
they're,
not
when
they're
not
physically
possible,
given
the
lower
layers,
I
you
know,
I
don't
think
that's
doing
violence
to
the
intent
of
the
number
of
departments,
but
I
would
like
I
would
like
clearance
from
the
working
group
to
do
so.
C
I'm
putting
boundaries,
as
we
said
as
roman
said
putting,
but
you
know
what
are
your
boundaries
for
your
musk
claims.
G
A
C
Well,
yeah:
let's
do
right,
stu
and
I
will
get
we
get
together.
First
stu
has
to
come
back
from
north
dakota
and
and
then
we'll
we'll
get
cracking
on
it
real
quickly.
All.
B
Right
so
and
roman,
thank
you
very
much
for
joining
us
today.
A
So
yes
yeah
yeah
yeah,
so,
but
just
before
we
move,
I
I
expect
to
that.
We
have
we.
We
addressed
roman's
comments
by
end
of
next
week.
B
Okay,
this
is
the
more
complete
scenario,
figure
that
I
think
may
help.
Some
people
understand
what
the
connectivity
situation
is.
B
The
the
thing
on
the
left
in
a
in
in
a
box
is
the
uas
which
has
two
boxes
inside
of
it:
the
unmanned
aircraft
and
the
gcs
and
there's
a
c2
link
between
the
unmanned
aircraft
and
the
gcs
or
maybe
there's
not
because
there's
also
a
link
from
the
gcs
to
the
internet
and
a
link
from
the
unmanned
aircraft
to
the
internet
or
maybe
there's
not,
and
so
clearly
the
gcs
must
exercise
command
and
control
over
the
unmanned
aircraft,
but
it
can
do
it
either
over
a
direct
wireless
link
right.
B
So
so,
you've
got
a
physical
connection
directly
between
the
gcs
and
the
unmanned
aircraft,
which
we
can
then
reuse
for
other
drip
purposes,
or
it
may
exercise
c2
by
the
gcs
talking
somehow
to
the
internet
through
the
internet
and
then
somehow
from
the
internet
to
the
unmanned
aircraft.
That
can
be
the
c2
path,
and
so
it
is.
It
is
things
like
that
that
that
lead
to
these
different
scenarios,
where
different
things
are
possible
or
or
not
possible.
So
I'm
hoping
we
can
at
least
get
this
figure
into
the
architecture.
B
This
is
just
my
opinion
on
how
our
documents
ought
to
fit
together.
External
inputs
are
on
the
left,
we
have
regulations
from
caas
and
we
have
another
sdos
work
in
f3411
those
drive
requirements
once
requirements
are
defined.
We
now
can
largely
forget
about
f3411
and
caas
and
derive
from
the
requirements,
architecture
and
once
architecture
is
defined.
We
can
then
refine
the
elements
that
make
up
that
architecture,
and
we
have
three
key
areas:
the
one
that
is
furthest
the
one
that
is
least
mature.
B
Thus
far,
is
the
registries,
and
then
we
have
the
authentication
draft
from
adam,
and
then
we
have
the
thing
from
bob
that
is
being
called
a
red
draft,
but
I
would
assert
that
everything
in
drip
is
rid
and
bob's
draft
is
really
focused
specifically
on
providing
drips
entity,
identifier
and
and
using
the
the
hierarchical
hit
to
do
that
now.
There
are
other
documents
that
we
will
produce
for
command
and
control
blah
blah
blah,
that'll,
okay,
and
so
here
are
the
fundamental
questions
we
have
to
address.
B
Schweiz
architecture
is
this
about
cyber
physical
entities
in
general
or
uas.
Only
I
don't
have
an
opinion
on
that,
but
we
need
to
know
which
we're
talking
about,
and
is
it
the
drip
architecture
or
only
a
drip
architecture?
Again,
I
don't
have
an
opinion.
Should
we
be
using
normative
language
in
it
that
we've
had
some
back
and
forth
on
that
here's,
my
key
issue:
we
can't
in
an
architecture
document
just
list
possibilities,
we
could
use
apples
or
we
could
use
pairs.
No,
we
must
specify
what
will
be
used
so
as
to
enable
interoperability.
B
B
Is
it
supposed
to
really
cover
all
of
remote
id
identifiers,
registries,
authentication
formats
and
everything
in
which
case?
Why
is
it
merged
into
architecture,
or
is
it
going
to
specifically
cover
identifiers
only
which
is
my
belief
what
it
should
be
and
then
is
hierarchical
hit?
We
already
talked
about
this
a
little
bit
the
drip
entity,
identifier
or
only
a
drip
entity.
Identifier,
I
think
we've
converged
on.
It-
is
the
identifier.
B
What
will
hopefully
become
michael
pelage's
draft,
which
is
currently
adam's.
Placeholder
draft
is
this
domain
name
based
drip
registries
and
there
could
be
other
kinds
of
drip
registries
or
it
is
drip.
Registries
adam,
as
the
current
author
of
the
draft
has
a
preference
for
it
being
domain
name
based
drip
registries,
because
he
does
indeed
anticipate
that
there
may
well
be
registries
based
upon
other
underlying
technologies,
especially
as
we
move
beyond
just
a
broadcast
rid
to
also
network
grid,
and
then
his
authentication
formats
document
are
these
drip
authentication
formats
in
general?
B
Or
are
they
only
broadcast
authentication
formats?
And
again
it's
adam's
preference
that
it
be
drip,
broadcast
authentication
formats
because,
as
we
move
into
network
grid,
we're
going
to
have
more
degrees
of
freedom,
and
we
can
accomplish
more
because
we're
not
in
tiny
little
packets
and
then
finally,
we're
going
to
need
to
come
up
with
a
means
of
compliance
document,
which
is
how
to
use
the
technical
standards
to
satisfy
the
regulations.
B
We
need
to
do
this,
at
least
for
the
faa,
probably
for
other
caas,
and
the
question
is:
could
bob's
draft
be
tweaked
to
serve
this
role
as
the
one
area
where
the
faa
admits
they
need
help
above
and
beyond,
astm's
work
is
on
the
session
ids,
which
is
exactly
what
bob's
identifier
would
serve
as
so.
That's
everything
I've
got.
Thank
you
for
indulging
me.
A
So
I
think
we
have
to
conclude
that
session,
but
I
guess
that
we
have
most
of
the
answers
to
the
question
you
raised.
Do
you
have
a
specific
question
we
need
to
address
and
if
so
I
suggest
you
put
that
on
the
mailing
list.
B
Mostly,
we
just
need
to
to
to
to
answer
definitively
the
questions
on
the
architecture
document
so
that
that
can
move
forward,
and
we
can
do
that
on
the
list.
A
Thank
you.
So
I
think
we
we
can
conclude
this
meeting.
I'm
I'm
asking
if
our
80s
eric
has
anything
to
say.
G
A
So
I
see
schwei
on
the
on
the
on
the
q
list.
So
schwei
do
you
want
to
say
something.