►
From YouTube: IETF114 ANIMA 20220725 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
All
right
welcome
everybody.
We've
got
a
hybrid
audience.
I
think
not,
that
many
people
in
the
room,
six,
seven
and
late
a
lot
of
good
food
in
the
outside
feel
free
to
come
in.
Let
me
get
started
so
this
is
the
notewell.
You
should
all
be
aware
of
it,
I'm
not
going
to
dwell
on
it
any
longer,
but
please
comply
with
it
now
as
far
as
the
procedures
are
concerned.
So
what's
new
and
exciting
here
so
shang
had
a
change
of
affiliation.
B
He
went
from
you
know
a
huawei
to
individual
contributor
and
being
in
beijing.
The
time
of
day
is
really
really
bad
for
him,
so
we
agreed
that
he'll
listen
to
it
afterwards,
but
he
was
very
much
active
in
the
preparation
of
the
meeting.
B
So
he's
he's
going
to
be
very
happy
to
continue
this
work
area
director,
nothing
new,
so
we're
always
abusing
the
minutes,
notes
page
also
for
the
agenda
of
the
items
after
the
chair,
slides
so
go
there
and
help
with
the
notes
and
and
see
the
agenda
and
all
the
urls
for
it.
B
Okay,
we're
applying
early
ipr
disclosure
process
in
this
working
group,
which
means
that
the
latest,
when
we're
asking
for
ipr
disclosures,
is
when
we're
adopting
works
for
the
working
group.
You're
also
happy
to
do
ipr
disclosures
for
any
individual
submissions.
You're
doing
I'm
I'm
typically
doing
that
for
mine,
and
so
we
don't
want
to
run
into
the
issue
of
doing
the
ipr
disclosure
question
only
when
stuff
is
being
moved
into
the
isg
at
the
very
tail
end.
B
So
we
now
have
nine
rfcs
and
so
they're
implementers
of
anima
protocol
specs
so
be
sure
that
you
are
aware
of
the
errata
that
we
have
or
even
better
so
you
discover
new
erratas
and
then
you
can
use
that
process
to
make
others
aware
of.
If
anything,
we've
specified
isn't
working
out
as
it
should,
and
there
is
the
url
here
and
if
you
have
any
questions,
write,
ask
on
the
mailing
list
or
just
the
chairs.
B
All
right,
where
are
we
so?
The
new
rfc
is,
was
a
draft
ietf
enema
asa
guidelines
that
or
was
in
rfc
editor
queue
at
itf-113,
so
it
passed
through
and
yeah.
We've
got
a
new
rfc.
B
Congratulations
to
the,
I
think,
also
all
sleeping
authors
being
in
the
pacific,
sorry
in
the
asian
time
zones,
new
zealand
and
so
on,
brian
and
others
right.
We
have
three
working
group
drafts
without
slot
ass,
so
those
are
the
ones
that
I
would
like
to
maybe
get
quick
statements
for
the
notes
here.
Don't
think
how
I
can
share
that
quickly.
B
A
Michael
richardson,
so
I
guess
I'm
responsible
for
all
three
of
those
risky
cloud
isn't
the
same
state.
It
was
in
113,
which
is
we
we're
we'd
like
a
working
group.
Last
call
we
haven't
changed
anything.
It
has
a
we'll,
have
a
normative
reference
on
a
lamp's
document
that
is
not
yet
adopted,
but
that's
not
our
problem.
A
So
voucher
delegation
still
a
lot
of
interest
in
it.
There
is
some
work
outside
the
ietf
doing
something
similar
and
we
should
do
what
they
did.
That
may
somewhat
require
us
to
wait
for
them
to
publicly
publish
but
other
than
that,
it's
basically
it
it
is.
It
needs
attention.
Okay,
8366
bis.
I
did
provide
some
a
slide
which
we
might
get
to
at
the
end
and
there
are
working
group
decisions
that
need
to
be
made
about
what
to
do
with
it
exactly
whether
it
goes
to
internet
standard
or
not.
B
So
this
is
my
long
reminder
which
I'm
not
going
to
read
in
detail,
but
please
you
know,
especially
if
you're
a
co-author
of
any
of
the
drafts,
please
you
know
figure
out
which
other
drafts
you
want
to
do.
B
Reviews
for-
and
you
know,
swap
the
token
buckets
back
and
forth
so
that
we
get
more
reviews
in
the
working
group,
because
I
think
nmr
is
one
of
the
many
working
groups
where
the
isg
is
rightfully
complaining
of
having
to
do
more
work
than
it
should
do
all
right
and
one
particular
you
know
nice
way
to
do.
B
It
is
to
become
a
shepherd
for
for
a
document
which
doesn't
only
mean
a
review,
but
also
some
interesting
itf
process
that
the
help
that
the
chairs
will
happily
help
you
with
you
know
preparing
a
working
group.
You
know
a
shepherd
document
and
so
on.
So
that's
a
nice
way
to
learn
a
little
bit
of
the
bureaucracy
of
the
itf.
If
you
ever
want
to
become
something
like
a
secretary
or
working
group
chair
or
something
like
that,
that's
the
smallest
step
to
take.
B
Okay
and
yeah,
so
this
these,
these
working
group
meetings
end
up
being
a
lot
procedural
kind
of
remembering
what
you
know
marks
to
do,
which
next
steps
to
do
in
the
process
and
maybe
not
enough
time
for
technical
discussion,
and
so
that
just
means
you're
not
asking
enough
to
have
forums
for
technical
discussions
when
we're
running
out
of
time
doing
it
three
times
a
year
in
these
meetings.
So
if
you
have
that
feeling
for
for
your
document,
please
come
to
us
chairs
and
and
we'll
we'll
talk
with
you.
How
to
improve.
B
On
that
and
most
of
the
you
know,
active
work
in
the
animal
working
group
was
started
by
contributors
just
organizing
themselves
and
that's
actually
the
brewski
design
team,
which
is
now
meeting
weekly
from
11
to
12
eastern
standard
time.
Url
is,
is
here
and
that's
pretty
much
doing.
B
Most
of
you
know
the
coordinating
work
for
the
brewski
documents
and
I'm
also
trying
to
smuggle
some
acp
stuff
into
it
when
there
is
time
for
it,
but
obviously,
if
we
have
contributors
of
of
other
work
that
that
would
like
to
have
a
separate
meeting
perfectly
happy
to
set
that
up.
B
I'm
tooling
reminders
so
pretty
much
all
of
the
anima
individual
submission
and
working
group
drafts
are
on
the
inofficial
anima
working
group.
Github
mailing
list
that
allows
us
very
easily
to
you
know,
have
every
individual
submission
go
into
it
and
not
bother
with
you
know
any
constraints
that
the
official
github
procedures
would
otherwise
put
on
us,
and
I
think
that's
been
very
helpful
and
successful
over
the
past
few
years
right,
and
that
brings
me
actually
to
the
end
of
the
official
share,
slides
any
questions,
suggestions.
B
Any
agenda
bashing
going
once
going
twice
all
right.
So
I'm
looking
now
at
the
notes,
page
and
next
thing
up
is
number
one
would
be
stefan,
you
can
step
to
the
microphone
and
do
you.
B
Yourself
should
I
bring
them
up
for
you.
B
B
Sorry,
oh
okay,
yeah!
So
I'm
trying
I'm
not
sure
what
my
problem
is
with
getting
the
meeting
materials.
D
D
D
D
D
The
draft
basically
changes
the
encoding,
but
it
makes
no
changes
to
the
young
that
is
defined
in
8366,
so
the
format
itself
can
be
used
by
brewski,
as
defined
in
8995
and
also
brewski
prm
prime,
which
we
heard
year
afterwards
relies
on
the
jws
form
factor.
So
that
is
basically
the
form
factor
that
that
we
completely
rely
on
in
both
key
prime.
D
So
also
the
jwf
options
that
have
been
discussed
in
the
past
was
were
related
to
the
serialization
and
are
in
jws
voucher.
D
Now
the
the
serialization
was
fixed
to
general
jws,
jason,
z,
realization,
and
there
was
a
switch
from
compact
serialization
and
the
reasoning
for
that
was
to
have
more
possibilities
and
also
cope
with,
or
also
be
as
flexible
as
other
formats
that
are
currently
used
for
the
voucher.
So,
for
instance,
multiple
signatures
are
only
possible
when
we
use
the
generalized
jws
json
serialization,
that
wasn't
possible,
with
a
simple
or
with
a
compact
serialization.
D
D
So
how
does
that
all
look
like,
so
the
switch
from
the
compact
serialization
to
the
general
json
serialization
looks
like
the
one
on
the
left-hand
side.
So
we
have
the
payload,
which
contains
the
voucher
and
just
below
that
we
have
the
signatures,
and
here
in
the
example,
we
have
just
one
signature,
and
that
is
a
protected
part
here
with
the
x5c
and
then
the
algorithm
that
is
used
here
is
elliptic
curve
based
signing
utilizing
sec,
p,
256
r1
and
what
was
included
in
the
version
of
4.
D
Was
this
type
here
to
allow
for
characterizing,
which
type
the
whole
payload
is
over
here
on
the
wire
that
looks
like
here
on
the
right
hand
side.
So
this
is
that
is
that
would
be
the
voucher
response
here.
D
So
that
would
the
view
that
you
see
on
the
wire.
D
So
just
to
recap,
the
changes
here
we
didn't
know
there
was
an
update
of
chapter
one.
The
introduction-
and
there
was
some
rework
of
chapter
three
regarding
the
voucher
artifact
was
a
json
web
signature
based
on
the
fact
that
we
switched
the
serialization
type
and
in
the
last
version
of
four,
this
optional
header
parameter
for
the
type
has
been
added,
and
that
is
being
reflected
also
in
the
different
examples
in
the
draft
itself.
D
So
the
next
thing
is
finalizing
the
the
draft
itself.
Then
there
is
some
further
alignment
on
going
in
the
burstly
design
team
called
that
tallest
was
referring
to
and
the
outcome,
as
usual
will
be
circulated
on
the
mailing
list
for
further
discussion.
D
So
here
there's
also
some
interest
and
interop
testing
with
others,
so
that
would
could
be,
for
instance,
in
the
in
the
context
of
bluesky
prm,
which
I
will
report
about
afterwards,
because
for
bowski
prm
also
the
prototype
implementation
or
the
proof
of
conflict
implementation
is
has
been
finished
and
we
would
be
happy
to
to
do
interrupt
testing
with
both
so
jws
voucher
and
specifically
also
with
postgre
prm
and
working
group
review
is
appreciated
in
the
same
way
as
tallest
also
pointed
to
the
fact
that
for
certain
drafts,
shepherds
are
still
being
looked
for
and
also
for
the
jws
voucher,
we're
looking
for
a
shepherd.
D
B
Thank
you
very
much,
so
I
already
put
in
the
notes
kind
of
the
the
two
process
recommendations
right,
so
the
the
changelog
would
be
good
to
capture
the
names
of
you
know
the
people
that
you
know
caused
the
improvements
of
the
document
to
be
made,
whether
it's
official
review
or
just
in
the
design
team
meetings
or
so
that
that
helps
us
a
lot
when
we
progress
the
document
so
that
we
know
how
many
eyes
were
laid
on
the
document
and
then
also
when
you
mentioned
interop
and
so
on,
that
that
can
also
be
put
into
a
to
be
removed
section,
but
any
information
of
actual
implementation
or
interrupt
or
so
are
always
very
good
input
for
ietf
and
iesg
review
later
on,
even
if
it
will
obviously
be
removed
from
the
document
and
would
have
to
come
into
its
own.
B
You
know
deployment
experience
document
later
on,
but
no
reason
not
to
not
to
write
it,
and
that's
not
specific
to
this
document
that,
I
think,
is
for
all
the
documents
getting
towards
the
you
know.
The
end
of
the
working
group
life
cycle
last
call
and
then
further
further
into
it.
These
these
two
pieces
are
very
helpful
for
the
process.
So
sorry,
no.
D
D
No,
but
but
that's
very
good,
I
mean
we
have
that
since
the
last
itf
meeting
that
we
have
proof
of
concept
implementations
available
for
several
of
the
drafts,
and
I
actually
wasn't
aware
that
it
would
be
helpful
to
put
that
into
the
drafts,
but
I
will
take
that
for
jws
voucher
and
also
for
the
for
the
further
ski
discussions.
Okay
thanks,
I.
B
F
D
Share
the
other
slide
set,
so
this
is
a
longer
list
of
answers
here.
So
that's
the
update
on
risky
with
pledge
in
responder
mode
or
short
brewski,
prime.
D
I
provided
a
link
here
to
the
url
that
we
have
on
github
or
the
draft.
So
authors
of
the
drafts
are
michael
richardson,
elliot
leo
thomas
vanna,
myself,.
D
So
we
we
had
two
two
versions
that
were
provided
to
the
ietf
in
the
since
itf-113,
so
regarding
the
main
changes
from
version
2
to
version
3.
There
are
mostly
editorial
improvements,
so
we
we
got
some
review
comments
up
front
and
we
got
some
discussion
during
the
last
ietf
meeting
that
led
to
the
update
of
examples
to
be
more
specific
regarding
the
x5c
occurrences.
So
we
had
some
some
gibberish
printed
in
there,
but
now
it's
all
called
base64
encoded
value
equal
equal.
D
D
What
was
also
done
to
to
really
improve
readability
was
restructuring
of
section
five.
That
was
the
leftover
from
where
woosky
ae
and
brewski
prm
were
both
connected
in
one
draft.
So
we
resolved
that
the
the
structural
issue
that
we
had
here
in
section
5
and
basically
flattened
the
hierarchy
here.
D
Then
the
main
changes
from
version
three
to
version
four
were
based
on
the
peer
review
that
was
being
done
by
esco.
D
D
The
majority
of
issues
were
targeting
improvements
of
the
current
description
that
we
have
there,
because
in
some
cases
we
had
ambiguities
and
in
some
cases
we
had
to
enhance
the
technical
capabilities
that
we
currently
described
so
one
of
those
technical
capabilities.
What
was
we
added
support
for
nonslash
vouchers,
and
we
had
some
discussion
in
the
design
team
or
the
design
team
list
for
that,
and
that
one
was
basically
added
to
allow
for
provisioning
of
vouchers
via
vlc
channel,
so
that
wouldn't
have
been
possible
without
the
non-slice
vouchers
there.
D
We
had
a
further
point,
a
technical
point
that
was
raised
regarding
the
pledge,
ca,
third
endpoint,
so
current
so
up
to
version
three,
we
only
had
the
ca
thirds
input,
endpoint
included
on
the
register
side
to
fetch
ca
search
from
the
register,
but
we
didn't
have
a
specific
part
or
a
specific
endpoint
on
the
pledge
site
to
provide
those
ca
certificates
and
that
has
been
added
or
enhanced
on
the
interface
to
the
on
the
pledge
side.
D
So
that
also
came
with
a
requirement
at
the
new
registrar
endpoint,
because
since
in
boosky
prm
we
having
we
are
having
the
register
agent
as
intermediate
component,
where
we
not
have
100
percent
trust
to
that
intermediate
component.
D
Then,
in
the
last
ietf
meeting
113,
we
had
some
discussion
about
the
possibility
to
have
proof
of
procession
of
the
registrar's
certificate
of
the
private
key
corresponding
to
the
registrar's
certificate
for
the
voucher
itself.
So
that
is
one
reason
that
we
switched,
that
we
are
using
the
possibility
to
have
multiple
signatures
on
the
the
jws
voucher
that
we
are
using
and
we
are
not
only
having
the
signature
of
the
mother.
We
are
also
having
the
signature
of
the
registrar
now
and
that
provides
us
proof
of
procession
that
was
missing
so
far.
D
So
that
means
we
now
have
a
similar
mechanism
or
we
can
apply
a
similar
mechanism
like
the
preliminary
preliminary
accept
or
provisional,
accept
like
we
have
it
in
the
tls
case
for
the
standard
prosky.
So
that
relates
to
the
issues
32
and
49,
and
it
was
discussed
already
last
time.
The
the
change
that
is
now
included
is
that
we
made
it
mandatory
because
we
had
some
back
and
forth
regarding
how
does
the
pledge
signal
that
he
wants
that
additional
signature?
D
D
D
So
then,
a
further
comment-
oh,
I
forgot
to
mention
the
issues
here.
Further
comment
was
related
to
the
format
of
the
subject,
key
identifier
and
specifically
what
we
what
we
take
from
the
subject,
key
identifier.
If
we
take
that
just
a
20,
20
byte
value
or
if
we
take
it
with
the
framing
ace
and
information
or
not
so
we
described
it
in
a
way
to
just
take
the
s-kit
by
the
20,
bytes
or
octets
that
are
part
of
the
certificate.
D
Then
one
comment
from
esko
was
going
into
the
direction
to
avoid
the
redefinition
of
the
voucher
request.
So
what
we
did
was
we
in
the
first
place,
we
did
a
copy
of
the
voucher
request
from
the
rfc
from
the
guruski
rfc
8995,
and
instead
of
redefining
it.
D
So
what
we,
what
we
did
now
is
we
took
the
definition
from
bruce
key
and
basically
augmented
the
voucher
request
to
include
the
additional
values
that
we
need
for
bluesky,
prime,
so
that
would
be
the
ancient
science
certificate
and
the
agent
signed
data
and
things
which
are
not
defined
in
the
in
the
original
voucher.
So
that
simplifies
the
voucher
definition
at
that
place.
D
D
So
that
was
also
included
and
then
based
on
the
discussion
that
we
had.
We
also
removed
the
join
proxy
in
the
overview
figure,
because
we
we
don't
really
need
the
join
proxy,
as
the
registrar
agent
is
expected
to
be
to
be
a
helper
application
for
the
registrar
and
doesn't
need
to
utilize
the
joint
proxy
here
and
between
the
the
pledge
itself
and
the
registrar
agent.
There
is
no
drawing
proxy.
D
Okay,
next
steps
are
based
on
the
on
the
review
comments
we
got
from
esco.
We
have
14
open
issues,
they
are
partly
cleared,
so
I
just
have
to
incorporate
them
into
the
graph.
Essentially,
they
will
be
addressed
after
this
meeting.
All
of
them
go
into
the
direction
of
clarifying
the
handling
response,
codes
and
endpoint
handling.
D
D
D
A
Hello,
I
hope
that's
loud
enough
for
the
people
is
in
the
room
and
one
of
the
things
I
I'm
unclear
about.
A
So
it's
a
kind
of
a
question
for
benoit
is
whether
or
not
we
we're
augmenting
yang
and
we're
using
it,
and
you
were
using
it
for
data
at
rest,
and
we
have
this
kind
of
thing
where
this
document
imports
from
this
document
and
that
document
imports
from
this
one
and
actually
in
the
end
we
kind
of
actually
want
to
have
something
that
is
just
the
union
of
every
of
all
the
extensions,
and
it's
not
clear
to
me,
because
I
don't
know
enough
whether
we're
really
using
yang
in
the
right
way
this
way
for
this,
and
it
would
be
kind
of
useful
if
we
could
somehow
have
a
yang
doctor
review
of
the
whole
working
group
in
some
sense
like.
A
A
Yeah,
it's
a
request
to
you
or
to
someone
else
in
the
yang
space
about
how
are
we
really
doing
it
right?
I
just
I
don't
feel
confident
that
we're
doing
it
right.
So
that's
what
I
wonder-
and
this
document
is
an
example
of
where
it
makes
sense
in
the
document
what
we're
doing,
but
it
might
not
make
sense
if
you
then
consider
it
with
three
other
documents
that
are
also
doing
something
similar,
and
I
don't
know
I
don't
feel
confident
that
we're.
Actually
this
is
the
absolute
correct
way
to
do
it.
F
C
Rob
wilson,
cisco,
I
I
think,
if
you
just
give
the
examples
then
would
die
to
ben
well
to
me
we
can
probably
say
whether
you
do
it
right
or
not,
or
it's
the
right
thing.
So
I
need
more
context
about
what
exactly
you're
doing.
A
B
C
B
It's
new,
we
couldn't
simply,
you
know,
steal.
You
know
from
from
from
a
lot
of
documents
that
do
the
same
thing
and
that's
why
we're
nervous.
C
So
we
have
benoit's
document,
I
mean
you
can
speak
to
of
the
young
file
format.
Instance
data
file
format,
so
we
do
have
a
document
that's
gone
through
recently
to
actually
have
yang
data
at
rest
and
a
document
format.
For
that.
I
think
that's
quite
right
for
this
purpose,
necessarily
because
that
has
extra
metadata
stuff
that
you
probably
don't
need,
but
so
that
we
are
doing
yang
data
arrest.
F
D
But
but
I
I
would
second
michael's
opinion,
I
mean
we
had
an
early
young
doctor
review
of
what
is
contained
in
the
draft
so
far,
but
I
think
especially
giving
the
last
changes
where
we
essentially
made
the
the
young
description
dependent
on
the
young
description
in
bluesky.
D
It
would
be
good
to
have
some
some
kind
of
overall
review
of
the
young,
young
application
or
young
usage
in
the
context
of
the
different
boothby
graphs
of
ruski
document.
G
D
B
G
B
G
G
Grasp
alternative
enrollment
there
we
go.
G
The
url
of
the
repository
which
you
can
find
here
and
I've
become
the
editor
last
time
and
stefan
fries
hendrick
brockhouse
and
eliot.
There
are
the
authors
mainly
and
I'm
basically
the
editor.
G
G
The
things
that
in
this
dash
dot
box
are
changing
can
be
done
according
to
the
specific
protocol
at
hand,
for
example,
whether
to
get
extra
certificates,
ca
certificates,
whether
maybe
get
some
certificate
attributes
and
then
do
the
of
course
do
the
actual
certificate
request
and
get
a
response,
or
maybe
some
extra
rounds
could
be
needed
in
terms
of
polling
or
whatever
the
protocol
allows
for
and
in
the
end
we
do
the
usual
enrollment
status
from
the
pledge
to
the
registrar.
G
Apparently
not,
then,
let's
see
what
has
been
changed
since
last
iatf.
G
We
have
set
up
two
versions,
the
first
version
of
one,
by
the
way
the
numbering
had
to
be
reset
after
when
changing
document
name.
So
we
start
again
with
version
one
in
this
version,
one
we
did
the
renaming
that
already
mentioned.
G
I
also
added
the
graphics
that
you
just
have
seen,
which
I
also
presented
last
time
and
to
alice,
asked
to
to
incorporate
this
also
in
the
document
itself,
which
turned
out
to
be
quite
a
difficult
thing
to
do,
giving
the
constraints
in
the
format
of
figures
that
are
allowed
for
such
documents.
G
But
in
the
end
I
think
at
least
got
an
black
and
white
version
of
them
of
the
of
the
graphics
in
there
yeah.
B
I
apologize
for
dragging
you
you
folks,
into
this.
It's
it's
great
if,
if
something
went
out
of
that,
I'm
still
very
much
annoyed
about
all
the
new
hurdles
that
the
xml
v3
has
has
been
putting
on.
You
know
the
the
requirements
for
the
documents.
Hopefully
that
can
be
improved
over
time
to
make
it
easier
to
get
the
nice
colorful
pictures
into
rfc's
as
well.
Sorry
go.
G
I
G
G
Can
act
as
a
local
registration
authority
or
as
a
full
registration
authority
or
as
and
simply
as
an
enrollment
proxy,
and
this
proxy
may
have
got
misunderstood
as
such
in
a
way
that
maybe
the
registrar
has
no
control,
okay
or
no
insight
into
what's
going
on.
So
we
clarified
this
and
stated
that,
in
fact,
the
registrar
is
can
delegate
so
towards
the
towards
the
pledge.
G
It's
it's
still
the
the
registration
authorities
from
from
the
pledge
view,
but
it
can
delegate
more
or
less
parts
or
all
of
this
registration
authority
tasks
to
some
further
back-end
server.
G
And
for
the
cmp
instance
of
ruski
ae,
we
just
added
a
reference
to
the
to
another
draft
on
co-op
transport
for
cmp
v2
and
another
reference,
I'm
getting
some
echo.
Hopefully
you
don't
get
it
as
well.
G
Because
this
could
also
be
of
interest
to
have,
for
example,
a
constrained
version
of
a
cmp
with
the
co-op
transport,
and
this
can
also
combined
with
bruce
ke.
Okay.
G
We've
also
done
a
poc
implementation,
and
this
was
well
received
also
by
colleagues
of
us
who
got
the
good
impression
that
this
bruce
kae
this
would
be
ready
for
incorporation
into
their
products.
G
The
only
thing
where
we're
still
waiting
for
some
enhancement
or
extension
would
be
the
instantiation
of
of
the
enrollment
protocol
to
use
estival
for
cmc,
rather
than
the
normal,
simpler
version
of
esd
there.
We
have
been
waiting
for
input
of
elliot,
but
so
far
got
didn't.
Get
it
elliot,
apparently,
is
not
here,
so
I
cannot.
G
B
Yeah,
let
me
let
me
see
you
know
what
what
what
the
order
is.
I
was
trying
to
put
the
my
ai
is
on
the
bottom,
so
it
seems
the
brewski
cloud
maybe
is.
Is
that
higher
priority
in
the
list?
How
do
you
folks
want
to
have
these
things?
Serialized.
B
B
B
These
broad
questions
you,
you
can
almost
no
reply
from
anybody
who's
busy
right
so,
but
if
you
ask
them
individually-
and
maybe
you
also-
you
know-
offer
your
help
with
their
document-
that
that
goes
a
much
longer
way.
G
B
Yeah
for
for
the
folks
in
the
room,
maybe
you
know
we
we
can,
we
can
always
do
do
they
ask
who
has
read
the
document
said.
F
F
B
F
F
B
They're
not
more
questions
again
right
in
terms
of
in
terms
of
the
reviews,
if
I
haven't
checked
the
latest
version
of
the
document,
if
you've
been
trying
who,
if
you've
been
tracking
in
the
changelog
who
has
provided
feedback-
and
you
know,
read
the
document,
if,
if
that's
in
there,
that
that
would
be
the
first
thing,
I
you
know
we
chairs
and
would
be
looking
into
to
judge
how
close
it
is
to
to
working
group.
Last
call.
B
Okay,
then,
I
think
we're
up
for
kyung
chow
for
the
enema
distribution,
the
the
grasp.
H
Distribution,
yes,
exactly
so
how?
How
could
I
show
my
screen
or
or.
B
You
need
to
click
on
the
share,
slides
share
slice
share,
pre,
pre-loaded,
slides.
H
H
Already
yep
yeah,
okay,
okay,
great
great,
so
hello,
everybody
good
afternoon
good
morning,
good
evening,
so
I'm
now
in
germany,
so
it's
already
not
late
night,
but
it's
almost
late.
Okay!
So
since
we
didn't
got
a
chance
for
the
last
meeting,
you
know
because
of
internal,
let's
say
approval
issue,
so
we
didn't
get
a
goal
to
attend
this
meeting,
so
we
could
not
register
itf
130.
H
H
The
main
content
of
the
draft
is
about
how
to
re-utilize
the
let's
say
the
grasp
protocol
api
with
a
very
limited
extension,
so
that
we
can
have
enhanced
information
distribution
module
for
the
whole
ani.
So
this
is
our
main
target
next
page.
So
here's
some
short,
that's
a
short
briefing
since
112
130.,
so
we
updated
from
version
two
to
four.
The
main
change
here
is
that
we
took
the
first
also
and
we
moved
zora
and
then
brands
name
to
the
acknowledgement
and
we've
focused
on
polishing.
H
H
Okay.
So
here's
our
some
comments
that
we
have
addressed
in
this
version.
So
the
first
one
is
that
the
review
comments
says
that
the
use
case
section
is
okay,
but
it
seems
that
automotive
example
seems
not
to
have
the
real
world
demand
at
this
point.
In
general,
we
can
we
we.
H
We
actually
agree
on
these
comments,
but
and-
and
we
are
we're-
and
we
are
thinking
that
this
part
could
let's
say
we
would
like
to
keep
this
kind
of
you
know
use
case,
because
we
at
at
some
point-
maybe
let's
say
the
the
end
point
with
mobility-
could
be
part
of
the
sap,
although,
although
it's
not
let's
take
considered
with
the
acp
setting
yet,
but
we
think
this
could
be
our
nice
futuristic
use
case.
H
If
the
mobility
kind
of,
let's
say
featured,
can
be
included
or
can
be
part
of
the
the
whole
ami,
but
we
can
discuss,
of
course
so,
but
we
add
some
clarifications
and
putting
down
its
gap
to
the
existing
scope
of
the
ni.
H
That's
in
this
version
and
another
comment
about
the
the
use
case
part
is
that
it
pointed
out
whatever
the
c2p
management
functions
could
be,
let's
say,
performed
with
an
ali,
but
but
actually
right
now.
Cpub
does
not
use
the
grasp
protocol,
of
course,
and
you
use
http,
2.0
and
json.
You
know
for
this
use,
but
this
is
a
kind
of
like
our
whole
motivation.
H
You
know
behind
that
because
we
think
there
are
huge
potential
and
even
internally,
when
we
are
discussing,
let's
say
in
huawei,
we
also
promote
less
animals
work,
because
we
think
there
are
huge
potential
where
animals
work,
let's
say:
concept,
protocols
and
architecture
and
so
on
could
play
play
a
very
important
role
in
3gb
network.
H
Let's
say
it's
not
that
easy
that
we
fully
replace
as
everything
in
http
with
anima,
but
I
think
it's
a
very
good
good
good
idea
to
say
that.
Okay,
how
about
the
3d
network
architecture,
even
part
of
that,
could
be,
let's
say
dumb,
but
animals
work,
let's
say
protocol,
even
architecture
that
that
could
be
very
nice.
So
this
is
why
we
we
keep
this
http
use
case
in
our
draft.
H
Okay
and
the
the
last
one
is
the
last
one
is
that
we
actually
mentioned
the
in-network
computing
capability.
Let's
say
features
but
the
by
the
common
sense
that
there
is
no
reference.
So
we
added
one
reference
for
that.
If,
let's
say,
if
needed,
we
can
add
it
more
okay,
so.
H
B
B
Is
it
okay
to
provide
comments
in
the
middle
and
not
only
at
the
end,
because.
B
Course,
yes,
so
so
so
for
the
first
point,
I
think
it
may
be
useful
to
remember
that
originally,
when
we
were
doing
enema,
the
idea
was
to
replace
the
whole
control
plane.
Yes,.
H
B
An
autonomically
built
one-
and
we
just
you
know
degenerated
so
to
speak
to
an
additional
acp
and
that
concept
certainly
is
most
useful
when
you
want
to
get
the
a
into
existing
equipment
service
provider
routers.
I
think
in
the
case
of
these
these
futuristic
er
styles.
We
may
get
it
back
to
the
original
vision
of
anima,
where
the
autonomically
formed
secure,
routing
infrastructure
would
be.
B
You
know
the
only
network
that
you
have
and
actually
would
be,
then
a
layer
three
equivalent
to
what
most
of
these
iot
networks
already
have,
which
is
you
know,
each
technology
has
its
own
layer,
two,
you
know
security
mechanism
and,
and
that
also
you
know,
creates
a
lot
of
unnecessary
islands.
B
So
I
think
you
know
thingy
is
necessary
if,
if
I
may
be
able
to
help
in
improving
that
writing
so
because
I
think
this
this
to
me
shows
a
lot
more
closer
to
what
the
reality
in
the
future
could
be
give
or
take
the.
H
B
Forces
and
now
I'm
just
ranting
here,
because
my
network
connection
seems
to
drop
me
off
and
I'm
happy
that
you
folks
can't
even
hear
me
unstable
connection
to
the
server
trying
to
reconnect.
B
The
main
point,
and
that
I
wanted
to
make
thank
you.
H
Okay,
okay,
then
I
will
continue
so
this
is
really
about
some
replies
to
the
comments
about
the
use
case.
You
know
from
the
shepherd,
but
of
course
there
are,
you
know
many
comments
we
didn't
address
so
far,
but
we
will
handle
that
as
a
later
and
then
it
comes
to
a
very
encouraging
comment
that
the
the
shepherds
think
the
data
backup
could
be.
A
very
interesting
could
be
a
very
interesting
functions
for
ai
and
scpo.
H
Of
course,
we
also
agree
so
then,
but
it
also
pointed
out
that
the
use
case
aside
from
the
data
backup
it
does
not
seem
actually
to
be
relevant
to
to
the
ami
and
acp.
So
then,
we
think,
later
on,
we
should
look
into
more
details
about
the
the
data
backup
use
case
and
see
if
we
should
keep
this
use
case.
H
And
then,
following
this
comment,
the
there
is
one
comment
about
saying
that
we
should
mate.
Let's
say
this
document
more
protocol-oriented
description
and
it
it
refers
to
this
mainly
discussion,
but
we
we
actually
checked
that
this
million
is
discussion,
but
the
the
latter
request
actually
suggests
that
the
opposite
so
less
product
oriented
description.
H
So
here
there's
a
little
bit
confusion.
Probably
we
can
also,
let's
check
it
out
later,
whether
or
not
we
should
make
it
more.
Let's
say
product
oriented
or
less
work,
oriented,
okay.
So
yes,
then
it
goes
to
then
the
order
comments
for
section
2
are
done
here
and
then
it
goes
to
section.
3.
H
first
of
words
pointed
out,
and
let's
say
the
pops
and
sub
you
know,
features
for
the
information.
Distribution
could
be
a
be,
let's
say
less
capable
for
when
the
network
size
getting
larger
and
denser
so
probably
here
and
we
we
should
refer
more
works.
So
we
actually
added
some
representative
reference
here
in
our
number
five
version,
and
we
also
did
a
minor
change.
H
Then
there
are
some
problems
also
pointed
out.
Let's
say
it
says
that
the
government
doesn't
provide
a
reasonable
security
consideration.
So
yes,
of
course,
we
didn't
reach
that
far
yet
so
we
are
asking
what
are
what
or
what
we
should
consider.
Let's
say
the
security
aspect.
So
this
is
the
first
issue,
and
the
second
issue
is
is:
is
about
the
writing?
I
think
so.
We
we
of
course
lack
of
the
experience
of
how
to
write
a
proper,
less
itf
draft.
H
H
Okay,
so
of
course
there
are
many
other
problems
that
we
didn't
touch
from
the
comments
and
opinions
provided
by
surfer,
but
we
will
also
handle
that
in
the
next
version,
then
the
future
works.
You
know,
as
I
said,
we
should
we
will
let's
say
continue,
but
I
would
also
take
this
opportunity
to
to
to
ask
let's
say
more
attentions
and
maybe
more
group
reviews
so
that
we
can
really
speed
up
the
process
of
the
of
this
document.
Of
course
we
can
keep
revising
the
as
the
document,
but
it
seems
endless.
H
H
H
B
Right
so
I
I
think
you
know
an
explicit
implementable
example
of
how
to
apply
these
mechanisms
would
certainly
be
helpful
right.
Okay,
it
could
be
started
just
an
appendix,
but
really
just
the
explicit
grasp
methods
right
who
is
talking
with
whom?
Why
are
they
doing
it
and
how
then
are
explicit?
You
know
grasp
objectives
exchanged
how
right,
whether
you
implement
that
actually
in
any
prototype
code,
maybe
on
on
top
of
brian's
grasp
implementation
or
so
on.
B
That
would,
of
course,
be
icing
on
the
cake,
but
you
know
the
whole
point
is:
you
know,
existence
proof
of
an
implementable
adaptation
of
the
method
in
this
document
right,
okay,
because
otherwise
it's
it's.
It's
always.
You
know
hard
to
figure
out.
Well,
I
can
guess
I
could
apply
this
way,
but
you
know
once
I
see.
B
Would
want
to
start
specifying
this
out
in
in
text
first
before
you
try
to
implement
it,
and
you
know,
maybe
you
know
the
the
people
concerned
here
about
the
the
lack
of
linkage
to
reality
would
already
be
happy
just
to
see
that
written
down,
but
I
think
it's,
it's
certainly
the
best
starting
point
to
resolve
this
issue.
H
Okay,
okay,
I
understand
I
actually
have
a
question
about
this.
Following
up
your
comment,
so
do
you
think
that
we
should
really,
let's
say,
consider
a
very
specific
use
case
or
scenario?
Let's
say:
does
it?
Is
it
necessary
to
really
have
a
very
concrete
example
to
really
say
that?
Okay,
this
is
the
entity
in
which,
let's
say
in
which
application,
in
which
scenario
in
which
kind
of
network
or
something
like
this
or
just
kind
of
very
generalized
the
functionality.
A
Yeah,
hello,
yeah
yeah,
you
need
to
tell
us,
I
don't
see
any
point
in
the
document
unless
it
actually
describes
something
that
someone
can
implement
right.
So
it's
nice
to
wish
for
3gpp
to
take
on
your
stuff.
We
also
wish
yes,
but.
A
Mean
unless
they're
actually
doing
it
or
then
I
don't
see
the
point
or
maybe
you
want
to
implement
it
in
your
3gpp
equipment
or
5g
equipment,
then
great
describe
it
how
it
works.
Okay,
even
if
that
means
the
document
is
describing
your
implementation
and
not
necessarily
a
standard,
and
it
has
to
become
informational,
okay,
but
that's
still
really
useful,
but
a
general
document
about
you
could
do
stuff.
I
don't
I
don't
see
the
point.
I
don't
even
see
the
point
in
reviewing
it
further,
so
I
mean
really.
A
B
Right,
yeah,
maybe
maybe
to
help
some
productive
detail
on
that
right.
So
I
think,
when
you're
referring
to
specific
standard
bodies
and
how
they
could
do
things
when
it
seems
to
be
clear
that
they're
already
on
a
different
track.
That's
that's!
That's
always
a
bad
reference
right,
so
it's
you
know
try
to
to
find
a
reference.
B
I
mean
the
the
benefit
on
how
to
do
it.
The
the
exact
example
that
that
describe
the
detail
of
you
know
the
grass
method
everything
necessary
to
implement
that.
That's
one
part:
the
applicability
to
to
a
particular
use
case
scenario.
For
that
that
should
just
be
you
know
as
specific
as
possible,
but
not
you
know
in
contradiction
to
what
we
know.
Some
particular
part
in
the
industry
has
chosen
right.
So
this
this
is,
like
you
know:
okay,
yeah,
okay,
you
can't
come
up
with.
H
H
So
then
it
means
that,
in
my
understanding,
if
I'm
correct,
we
can
let's
say
just
stop
at
the
the
levels
saying
that
this
is
the
node
and
this
the
node.
This
node
has
implements
the
functionality
that
we
propose
in
the
document.
Then
it's
sufficient.
We
don't
have
to
say
that
what
node
it
is-
and
let's
say
it's
a
very
specific
node,
for
example,
it's
as
a
network
node
running
in
5g
network
or
usb
network,
or
it's
a
let's
say
vehicle
or
it's
an
iot
device
or
something
like.
F
H
B
The
most
concrete
write
down
of
an
example,
and
and
and
and
we'll
basically
start
discussing
it
from
there
right
to
to
to
refine
it
to
a
point
that
that
we're
satisfied
with
it,
okay,.
H
B
B
I
think
it's
rfc
899,
who
one
or
two
there
is
one
from
shang,
young
and
others,
for
you
know,
example
applicability
of
grasp
so
that
that
went
one
step
further
in
the
level
of
details.
H
I
Oh
yeah,
my
recommendation
for
this
question
would
be
first.
We
can
spend
a
little
bit
text
to
describe
a
use
case
as
started
as
teres
suggested.
Then
we
should
focus
on
a
standardized
scenario
which
is
generalized.
I
If
there's
something
you
know
too
specific
to
certain
use
case,
we
can
have
the
appendix
that
would
make
this
document
focus
enough,
but
also
have
enough
use
case
information
for
the
audience
right.
Okay,.
H
F
B
I
think
we
can
happily
take
this
this
this
to
the
list,
and
you
know
please
please
start
on
on
the
steps
that
yeah
we
gave
you
here
and
if
you
have
any
more
questions,
let's,
let's
do
that
actively
on
the
list.
Okay,.
H
F
B
Okay,
update
on
constraint,
brewski
and
join
proxy,
and
that
would
be
mr
richardson.
B
F
H
H
J
F
F
F
B
B
J
Okay:
okay,
okay,
like
let's
start
okay,
okay,
let's
start
I'm
using,
and
this
slope
is
about
the
draft
auto
deployment
mechanism
for
resource-based
network
surveys
and
at
first
I
will
have
a
short
review
about
the
draft
and
this
strategy.
We
want
to
discuss
the
question
about
how
to
establish
a
set
of
autonomic
negotiation
mechanism
to
achieve
the
negotiation
and
the
distribution
of
the
natural
resource
in
the
domain
network
between
the
surveys
and
the
network
and
the
the
key
point
of
our
goal
is
establish
autonomic
negotiation
mechanism.
J
And
the
this
is
a
major
change
from
the
ietf
one
month,
three
seasons,
and
I
also
received
some
comments
from
the
brian
and
in
this
meeting.
I
want
to
explain
my
thoughts
about
this
comment
and
I
want
to
talk
about
some
major
changes
from
the
itfu
biomass
resistance.
J
So
first
thing
is
that
I
add
some
picture
in
the
session
for
to
to
discuss
the
process
of
the
resource
negotiation.
J
I
think
this
is
important
things
and
will
make
our
workforce
to
understand,
and
I
will
introduce
this
in
the
next
page,
and
the
second
is
that
I
add
a
grasp
objective
example
use
case
in
the
section
6
6
1,
and
I
talked
about
this
use
case
as
a
last
meeting
and
I
updated
in
it
into
this
new
version.
J
The
third
is
that
I,
this
has
some
compassion
with
other
technology,
and
brian
suggests
that
we
should
discuss
more
about
the
night
and
I
plan
to
do
this
in
the
next
step.
The
last
thing
is
that
I
created
some
text
error.
J
Okay,
this
page
is
about
auto
deployment
process
and
in
this
auto
deployment
process
we
talked
about
how
the
two
different
kinds
of
asa
can
communicate
with
each
other
and
how
to
this
to
how
it
translates
to
asia
negotiations
resource
and
in
this
process
we
can
warehouse
a
three
stage:
the
discovery
stage
under
the
negotiation
stage
and
the
after
negotiation.
J
What
is
to
assad
should
do,
and
in
this
process
we
will
add
in
this
new
version
underway
at
the
new
staff
about
the
sacred
synchronization
to
other
asa,
and
we
added
this
in
the
after
negotiation
after
negotiations
are
two
different
kind
of
asean:
nato,
a
negotiation
with
salt
and
so
providing
resource
management.
Asa
removes
accessible
results
from
its
resource
poor
and
after
that
we
will
synchronization
to
other
as
a
whole.
J
The
negotiation
results
and
exercises
request.
Resource
manager.
Asa
can
tell
us
so
why
such
as
resource
resource
nation
is
ready
under
the
service
time
uses
resource
center
package,
and
this
is
about
the
auto
deployment
process
and
the
in
this
page.
We
want
to
talk
about
some
uncomfortable
with
other
technologies.
J
J
It
can
support
the
multi-round
negotiation
mechanism
and
supports
multiple
type
of
resource
negotiation
and
the
and,
as
for
39,
we
seemed
that
this
mechanism
supports
a
negotiation
of
the
resource
for
the
denied
surveys
and
the
this
draft
of
racing
can
be
considered
as
a
distribution
solution
of
the
denied
resource
damage,
negotiation.
J
And
the
about
the
society
consideration
and
the
in
this
new
washing.
We
say
that
this
draft
doesn't
want
to
introduction
the
action,
security
problems
for
anima
and
the
wasting
some
eyes,
and
I
think,
there's
a
discussion
about
some
society
matter
is
out
of
this
draft
scrub
and
I
think
some
some
security
problem
is
a
common
problem.
J
For
example,
brian
asked
me
some
some
question
about
multiple
domain
network
and
this
icing
and
as
I've
seen
9
2
2
2,
and
it
says
that
this
will
be
a
possible
weight
part
and,
I
think,
is
a
necessary
to
establish
some
rule
to
retrace
the
about
some
about
this.
The
quality
consider
province
and
I
think
we
need
a
separate
draft
to
this
passage,
and
this
is
not
our
drafts.
I
want
to
discuss.
J
J
So
stands
for
brian's
half
and
he
gave
me
some
related
paper
and
I
will
represent
carefully
and
update
in
the
next
version,
and
the
next
next
question
is
about
two
ways
we
should
consider
more
about
is
practice
scenarios,
for
example,
if
if
the
resource
state
change
in
the
network
and
the
what
we
should
do
something
to
ensure
the
right
resource-
and
maybe
we
should
talk
about
this
more
detailedly-
and
I
think
I
should
add
an
example
in
section
6
to
discussions
this
question
and
that's
all
and
welcome
to
through
my
comments
and
the
contribution.
D
Thanks,
let
me.
B
I
was
wondering
have
have
you
done
any
prototype
implementation,
for
example,
also
on
top
of
brian's
grasp
implementation.
F
B
What
she
was
talking,
the
whole
time
is
she
did
you
mute
yourself?
One
second,
I
mean
see.
B
D
B
Update
on
constraint,
brewski,
which
seems
to
be
primarily
the
join
proxy,
can.
F
F
B
Yeah
yeah
yeah
watching
materials.
Where
is
it
in
a
second
not
share
screen.
B
F
A
You
know
there
we
go.
Oh
look,
okay,
so
this
is
a
I'm
michael
richardson.
This
is
an
update
on
constrain
join
proxy,
which
was
in
wasn't
working
group
has
been
through.
Working
last
call
has
gone
to
visit,
rob
has
come
back
and
it's
also
an
update
on
the
constrained,
voucher
document
and
you'll
understand
where
next
slide,
please
so
big
thing
that
we
did
is
that
we
moved
a
lot
of
the
discovery
text
that
was
in
or
the
discovery
protocol
definition
that
was
in
constrained
joint
proxy.
A
A
So
if
you
are
looking
are
a
red
are
a
joint
proxy
and
you're
looking
for
a
registrar,
then
the
registrar
and
grasp
speak
should
announce
itself
with
an
ip
proto
udp
and
a
5684
or
other
arbitrary
port
on
which
it's
going
to
run
co-op,
and
it
should
announce
it
with
an
objective
of
brewski
jp
which
in
brewski
it's
just
an
empty
string.
We
should
have
put
something
in
there,
but
we
didn't
so
then,
if
you
in
fact
support
other
protocols,
for
instance
the
stateless
protocol,
then
we
say
in
joint
proxy.
A
You
should-
and
this
is
the
bottom
of
the
screen
in
blue.
You
should
announce
it
with
brucey
rjp
as
your
target
and
then
a
different.
B
Yeah,
can
we
get
some
more
remote
participants?
Are
you
getting
video.
F
A
Okay,
so
if
you
in
fact
are
a
pledge
and
you're
looking
for
a
joint
proxy,
then-
and
if
you
want
to
find
one
that
does
co-op
constrained
voucher
join,
then
you
would
see
that
by
an
announcement
that
says
it's
a
udp
and
we
put
in
the
string
there,
dtls
and
you'd
see
a
port
number.
That's
an
arbitrary
port
number,
despite
the
fact
that
I
can't
spell
properly
it's
a
not
an
abbottary,
but
an
arbitrary
port
number
and
the
important
part
is
that
in
the
join
proxy
in
the
constrain
point
proxy.
A
There's
no
change
because,
from
the
pledge
point
of
view
it
doesn't
matter
whether
the
joint
proxy
is
is
doing
a
stateful
join
where
it
stores
its
state
in
memory
or
whether
it's
doing
a
stateless
join
where
essentially,
it
stores
its
state
in
the
network.
Next
slide
different
topic:
oh
wait!
Are
there
questions
about
that
topic.
B
No,
I
think
this
this
is.
Finally
the
the
question
is:
how
can
we
be
as
nice
as
we
are
in
grasp
with
this
with
the
other
discovery
methods
right.
A
Yeah
so
so
the
document
goes
through
it
and
mdns,
but
it's
less.
I
guess
it's
less
visually
interesting,
so
I
didn't
put
it
in
the
slide.
Please
look
at
the
diff.
It's
basically
just
you
look
for
a
particular
name:
brewski,
dot,
jp
or
brewski,
dot,
rjp
and
there's
not
any
difference.
It's
you
know
it's
a
target.
You
look
for
so.
F
B
I
think
I
think
my
major
unresolved,
the
the
unresolved
thing
I
think
we
have
is
with
core
right.
Yeah.
A
Co-Op
is
coming,
okay,
co-op
is
coming
in
it's
at
the
end
of
the
thing,
because
it's
the
the
so
we
improved
the
document
a
little
bit.
One
of
the
things
we
did
is
we
put
an
extra
level
in
the
in
the
mesh,
so
it's
clear
that
it's
a
multi-hop
and
that
not
every
device
is
directly
connected
to
the
registrar.
A
I
keep
getting
a
hiccup
when
I
look
at
the
diagram,
because
I
want
to
put
the
pledge
on
the
left
and
the
registrar
on
the
right,
but
the
other
authors
liked
it
this
way.
So
whatever
the
important
thing
is
that
the
last
hop
is
probably
clear
and
because
it's
not
the
the
device
is
not
yet
part
of
the
network.
A
A
It's
not
what
I
would
have
written.
I
I
believe
it
happened
as
a
kind
of
frustrated
response
to
reviewers
comments
about
not
quite
understanding.
What's
going
on,
so
I
made
this
table
and
I'm
sorry,
it
doesn't
quite
fit
on
the
the
slide.
So
what
does
it
amount
to?
I
think
that
all
registrars
have
to
support
stateful
onboarding,
for
the
simple
reason
that,
if
you're
going
to
make
a
co-op
dtls
connection,
it
is
a
stateful
activity
and
you
have
to
a
registrar
has
to
support
state
for
that.
A
There's
no
other
way
about
it.
So
the
registrar's
always
going
to
support
that
always
going
to
announce
it
and
that's
a
a
simple
first
step.
That's
mandatory
a
joint
proxy
that
implemented
a
stateful
onboarding
process
that
is
it
uses
ram
to
keep
track
of.
What's
going
on,
would
see
that
announcement
and
would
say,
of
course
I
can
operate
in
that
way
and
would
go
if
a
registrar
does
support
the
stateless
method.
A
That's
in
this
jpy
thing,
then
it
would
announce
it
and
the
joint
proxy
that
supported
it
might
prefer
to
do
that
rather
than
the
stateful
one
if
it
prefers
to
use
to
prefers
to
use
network
to
store
the
state
rather
than
ram,
and
that's
not
necessarily
a
pr
all
every
device
there
in
particular,
if
you're
not
battery
operated,
but
you
do
have,
and
you
have
lots
of
ram
then,
and
your
network's
very
poor,
then
stateful
might
be
a
better
choice.
You
know
it's,
it
depends.
A
I
would
like
to
tell
people
if
you
buy
a
registrar
and
it
doesn't
support
stateless
and
you
buy
join
proxies
that
don't
sorry
that
a
registrar
that
does
not
do
stateless,
yes
and
you
buy
joint
proxies
that
only
do
stateless.
Then
it's
not
going
to
work.
So
I
don't.
I
would
say
that
it's
not
an
interoperability
failure.
That
is
a
procurement
failure.
A
In
my
opinion,
the
the
interoperability
failure
would
be
is
if
the
registrar
did,
support
stateless
and
the
joint
proxies
did
support
stateless,
but
they
failed
to
negotiate
that
in
in
in
real
life.
Right,
I
mean
it.
Similarly,
if
I
buy
a
if
I
buy
a
cisco
router
with
short
haul
optics
and
I
buy
a
juniper
router
with
only
copper
connections,
it
also
doesn't
interoperate,
despite
the
fact
that
everyone
else
has
got
a
thing.
A
You've
got
the
wrong
plugs,
so
this,
I
think,
is
a
wrong
plug
situation,
but
I
would
love
to
have
more
comments
on
the
list.
I
don't.
I
just
don't
think
that
we
really
want
to
tell
every
join
proxy
entity
that
you
must
implement
both
or
that
you
must
implement
one
or
you
must
build
the
other,
because
I
really
think
it
depends
upon
what
what
your
target
environment
is.
What
we
should
have
is
we
should
have
whatever
you
have
implemented.
It
should
automatically
configure
and
find
the
thing
that
works.
B
Can
I
add
to
your
myrand
rant
so,
which
is
about
security?
We
have
been,
I
think,
in
pretty
much.
Every
itf
spec
pretty
bad,
about
defining,
really
actionable
state
overload
protection
so
it
from
the
security
perspective.
The
state
list
is
so
much
easier
right.
We
don't
have
to
specify
anything
because
there
is
really
no
problem
of
doing
the
security
and
state
overload
control
on
the
registrar.
It's
a
big
box.
It
can
easily
get
software
updates,
but
on
the
proxies,
that's
that's
a
lot
harder.
If
we
do
stateful.
A
On
the
box,
if
you,
if,
if
the
working
group-
and
you
are
telling
me
that
we
should
make
stateless
mandatory
to
implement,
then
I
actually
don't
have
a
problem
with
that.
B
A
So
so
so
I
would
agree
with
you
that
would
go
with
it
there
there
there
are
some
some
there
are
some.
There
are
different
attacks
in
that
case
and
I
I'm
happy
to
to
go
through
them
and
put
it
in
the
security
considerations,
but
I
think
at
least
the
authors.
We
need
some
more
clear
guidance
as
to
what
to
do
here.
I
would
prefer
to
leave
it
open,
but
I'm
I'll
go
with
whatever
anyone
wants
you're
going
to
speak
from
the
mic.
F
J
C
Robots,
wilson,
cisco,
so
I'm
not
sure.
I
feel
that
strongly
on
this.
I
mean
obviously
raised
a
comment
during
my
review.
I
think
it
was
simply
the
the
observation
that,
if
there's
a
sort
of
minimum
common
denominator
that
all
these
things
support,
that
obviously
makes
interrupt
easier,
that
you
know
that
you've
if
somebody
doesn't
know
exactly
what
they're
doing.
I
know
this
is
probably
not
plausible
in
this
deployment
scenario.
If
they
get
one
of
these
and
one
of
those
they're
going
to
at
least
talk
something
rather
absolutely
take.
So
that's
all
it's
from.
C
A
A
Right,
okay
and
it
and-
and
it's
perfectly
fine
if
the
the
wi-fi
ones
just
don't,
because
you
know
what
the
network's
so
big,
who
cares.
On
the
other
hand,
the
network's
so
big,
it's
easy
to
fit
all
the
state
in
it
right.
There's
no
there's
no
issue
about
extra
extra
big.
You
know
more
packets
because
you
can
easily
fit
in
1500
bytes
the
whole
state.
So
you
know
I.
C
A
Where
you
know
on
this
side
of
the
room,
you
can
you
you
get
really
efficient
onboarding
on
that
side
of
the
room.
You
get
a
different
joint
proxy
and
you
know
something
works
differently
right.
So
so
that's
why
I'm
like.
I
don't
know
right,
but
I
guess
I'm
happy
to
write
anything.
A
B
If
the
implementation
experience,
for
example,
shows
that
the
stateless
isn't
even
significantly
more
difficult
to
implement,
then
we
know
it
has
the
security
benefits,
so
those
two
pieces
together
might
be.
You
know
to
make
that
the
mti.
B
But
I
mean
that's:
that's
basically,
the
implementation
judgment
call
right,
because
I
mean
I
was.
I
was
looking
at
from
the
simple
I'm
writing
an
application
on
top
of
a
tcp
socket
right.
So
the
the
stateless
stuff
was
difficult
in
the
non-constraint
case.
Now
in
the
constraint
case
might
be
turning
opposite
with.
You
know,
dtls
and
everything.
So
if
you,
if
you
can
make
the
judgment,
call
that
the
that
the
stateless
approach
is
equivalent
or
even
better
in
terms
of
implementation,
and
we
have
the
security
benefits
those
two
together,
but
okay.
A
A
With
that,
I'm
okay
with
that,
it's
a
it's
an
additional
piece
on
the
registrar
that
we're
mandating
must
exist,
and
but
you
know,
I'm
actually,
okay
to
say
that
to
say
it
that
way.
I
prefer
the
stateless
way
myself.
Okay,
because
I
I
I
really
think
that
it's
much
better
to
do
that
for
the
the
low
power
devices
for
that
they
don't
need
ram,
particularly
for
that,
and
they
can
just
you
know,
just
go
and
let
someone
else
take
care
of
the
general
service
attack.
C
A
A
A
Okay,
so
we
throughout
our
old
jpy
message.
This
is
a
some
ways,
a
very
big
change
at
this
late
stage,
but
all
the
people
implementing
were
are
basically
authors
at
this
point,
so
they're
all
very
happy
to
do
this.
Basically,
we
said
it's
none
of
your
business.
A
What
we
put
in
the
jpy
message-
and
it's
just
some
context
and
in
the
document
we
suggest
what
you
should
put
in
it
and
that
it's
less
than
16
bytes
and
you
can
aes
cbc
encrypt
it
and
that
authenticates
it
nicely,
and
you
know
you
can
change
the
keys
at
your
whim.
A
Okay,
with
some
caveats
about
how
to
do
this,
it
also
makes
it
much
much
much
closer
to
how
it
works
with
rfc,
90,
32
or
31..
It's
one
of
those
two
which
is
the
six
dish
minimal
security
onboarding
that
uses
the
co-app
extended
token
in
almost
exactly
the
same
way,
and
you
could-
and
it
has
exactly
the
same
problem
and
the
same
things
and
that's
what
we
did
so
you
could
actually
use
the
same
code
if
you
were
implementing
both
on
the
same
machine.
A
So
that's
really
it
this
is.
I
the
working
group
really
needs
to
look
at
this,
because
this
is
a
change
in
the
wire.
You
know
bits
on
the
wire
change.
Why
are
on
the
bits
change?
And
so
please
read
this
and
object
now,
next
next
or
a
proof
or
proof
yeah,
okay,
this
is
the
part
where
we
get
kind
of
icky.
So
when
we're
doing
co-op
discovery,
if
you
were
just
looking
for
an
an
est
or
co-app
in
rfc,
80
9148,
I
think
it
is
recently
published.
A
You
know
you
would
do
something
on
the
left
in
the
green
okay
in
particular,
you
would
do
a
multi-cast.
You
know
request,
tell
me
all
the
est
servers
and
you
get
this
response
back.
That
says
oh
they're
here
and
they
have
this
different
content
types
and
you
can
do
these
different
things.
I
actually
think
that's
wrong,
because
I
think
that
it
actually
should
have
a
co-app
s
at
the
front
and
I
don't
think
you
could
multicast
co-op
discovery
over
dtls
but
anyway,
so
on
the
right.
A
We've
done
the
same
thing
in
this
case
there
happens
to
be
a
stateless
registrar
available,
and
so
he
responds-
and
it
turns
out,
according
to
the
link
formatting
rules.
As
far
as
we
understand
them,
going
back
to
some
3000
rfc
3000-ish
rfc
for
some
details
about
what
the
authority
is.
If
you
want
to
stick
a
port
number
in,
you
have
to
put
the
ip
address
and
if
it's
a
v6
address,
you
have
to
put
parenthesis
or
square
brackets
around
it.
Okay,
so
that's
the
first
one!
So
7434!
A
A
A
A
No,
that's
that's
it
right.
The
second
one
is:
we
can
create
some
new
scheme
jpy
and
we
wondered
what
the
overhead
of
doing.
That
is
how
many,
how
many
reviews
and
external
experts
do.
We
need
to
make
that
happen
and
we
started
looking
through
a
list
of
schemes
and
we
thought
well
maybe
it's
not
as
hard
as
we
think
because,
there's
like
all
sorts
of
garbage
in
there,
so
you
know
what,
if
someone
says,
that's
the
right
way,
then
I
guess
we
could
go
that
way.
A
We
could
abuse
some
other
scheme,
I
guess
but
which
one
I
don't
know
it
would
be
abuse.
We
could
just
not
use
co-op
discovery
for
this
case.
Okay
or
some
other
idea,
your
other
brilliant
idea.
So
this
is
where
I'm
really
really
would
like
a
lot
of
discussion-
and
I
know
no
carsten
has
an
opinion.
B
B
Maybe
I
I
don't,
I
don't
know
when
is
actually
the
the
internet
isn't
working
so
when,
when
is
actually
the
co-op
working
group
right,
if
they
have
five
minutes
time,
maybe
we
can
even
bring
it
up
there
right,
take
it
to
the
original.
Well,
we
we
have.
A
We
have
the
we
have
the
the
carson
is.
Is
the
expert
reviewer
for
some
part
of
this,
and
you
know
so
to
a
certain
extent.
If
he
thinks
it's
okay,
then
it's
okay
and
it's
the
expert
reviewer
for
the
the
name
of
the
ski
of
the
of
the
thing
we're
looking
up,
but
you
know
I
said,
there's
like
there's
other
ways,
there's
other
ways
through
this
process
and,
as
I
said,
one
of
the
issues
is
maybe
there
is
no
issue
ultimately
we're
doing
co-op
s.
It's
just.
A
C
So
rob
my
instinct
is
to
try
and
create
new
scheme
here,
because
I
I
don't
think
it's
that
hard
to
do
so.
That
would
be
my
my
first
step
to
try
would
be
because
it
feels
like
that's
the
right
thing
to
do
and
that's
well
defined
what
this
behavior
is.
I
think
pretending
it's
not
an
issue
is
a
bit
icky,
because
it's
not
going
to
work.
If
you,
you
know,
had
a
server
that
wasn't
expecting
this.
It's
just
going
to
not
talk.
A
So
we're
not
we're
not
really
ever
going
to
use
this
mechanism
anywhere
else.
I
don't
think
right.
Maybe
someone
else
has
another
stateless
co-op
ish
thing
that
they
need
to
do
with
dtls,
but
I
can't
imagine
what
it
is,
but
it
could
come
along,
but
that's
my
concern
is
this:
is
a
single-use
scheme
can.
B
I
just
say
from
the
process
perspective.
I
would
like
to
understand.
First,
what
you
know
somebody
who
best
reads
our
rfc
would
figure
out
is
the
recommended
way
from
the
rfcs.
I
couldn't
do
that.
I
couldn't
figure
out
what
the
recommended
way
is.
If
that
recommended
way,
it
turns
out
to
be.
You
know,
crappy
lot
of
overhead
and
we
can
come
up
with
an
okay
way
that
that's
just
a
fallback
right,
but
how
do
we
figure
out
what
the
recommended
way
is.
B
The
the
encoding
right,
whether
you
know
using
a
particular
scheme
right
having
for
this
thing,
the
port
number
all
the
all
these
things.
What
is
the
recommended
way
to
encode
our
information,
we're
making
it
up
as
we
go
we're
reading
the
rfcs?
We
think,
but
we
feel
you
know
unsafe
about
it.
So
is
the
expert
reviewer,
the
one
that
should
give
us
the
guidance
is
the
working
group
for
that
wrote
the
rfcs,
the
one
that
should
give
us
the
guidance.
That's
that's
my
process,
question.
B
E
So
the
the
thing
is
that
between
these
angle
brackets,
you
have
to
have
a
link
and
there
are
many
ways
to
build
a
link,
but
in
the
end
it
needs
to
be
a
link,
and
if
you
have
a
special
kind
of
plumbing
that
you
are
using
a
long
time
ago,
we
had
the
discussion
about
rfc,
8232,
32
or
83
23,
whether
the
the
best
way
would
be
to
to
essentially
do
the
http
thing
and
and
completely
ignore
the
plumbing,
or
actually
do
schemes
that
are
plumbing
specific
and
we
decided
to
go
for
plumbing
specific
schemes
with
the
the
intention
to
at
some
point
invent
something
that
that
makes
life
easier
for
us
now
that
was
five
years
ago,
and
we
this
invention,
hasn't
happened
yet.
E
So
I
think
right
now,
the
state
of
the
art
is
that
you
come
up
with
a
scheme
describe
what
it
does
and
and
put
it
there.
Okay,
thank
you.
E
And
I
I
got
drawn
into
this
because
I'm
I'm
supposed
to
give
a
destiny,
an
expert
opinion
on
the
rt
part,
which
I
think
that
there
is
no
no
discussion
about
the
rt
part
that
that's
fine
but
the
the
example
with
which
it's
introduced,
that
that
doesn't
work
right
now
and
that
kind
of
taints
the
the
irt
registration
that
we
definitely
want
to
go
forward
with
as
quickly
as
possible.
A
A
E
Quickly,
from
a
systematics
point
of
view,
the
place
that
defines
jpy
should
also
be
the
place
that
defines
the
scheme.
A
A
What's
the
last
is
that
the
last
there
might
be
one
more
slide,
just
questions.
B
C
Okay,
I
was
just
going
to
quickly
I
posted
into
the
chat
the
answer
got
back
from
ayanna.
So
I
put
a
question
to
I
put
a
question
into
the
ice
g
and
I
and
I
on
his
honor
that
as
well
so
and
they
gave
the
answer,
so
it's
in
the
chat
effect.
The
thing
is,
he
don't
think
it's
that
hard.
His
expert
review
needs
to
be
discussed
in
the
mailing
list,
but
don't
I
don't
think
it's
that
arduous.
B
F
A
B
No,
no,
I
I
I'm
saying
it's
it's
fine,
I'm
just
which
one
is
it
now
proxy
eep
to
connect
now
yeah.
A
Okay,
so
there's
a
dot.
This
is
a
document,
but
basically
about
how
do
we
manage
to
run
brewski
with
wi-fi,
so
there
were
efforts
in
the
emu
area
to
do
brewski
teep.
So
one
of
the
problems
is
that
teep
is
not
really
deployed
out
there.
It's
not
really
out
there
doing.
Brewski
t
might
be
neat
but
doesn't
really
get
anywhere
anywhere.
Anybody
anywhere
so
al,
and
I
wrote
this
document
about
how
to
do
it
next
slide.
Please.
A
So,
basically,
what
we
do
is
you
do
an
eap
tls
and
you
use
a
network
identifier
of
onboarding
at
eap.rpa
and
you
don't
verify
the
server
and
you
get
put
on
a
network
where
you're,
probably
very
lonely,
and
you
might
not
even
get
dhcp
v4
and
that's
okay,
because
brewski
doesn't
need
that
but
you're
encrypted
and
you
wind
up
in
a
in
a
captive
portal
of
some
kind.
You
might
get
all
these
other.
A
You
know
v4
things
and
have
a
captive
portal
and
you
might
be
able
to
you,
know,
download
windows
updates
and
a
lot
of
enterprises
have
that
network.
Already,
okay,
it's
it's
it's!
What
happens
to
you
if
you
fail
the
I'm
running
the
latest
virus
scanner
stuff
and
that's
all
we
need.
We
just
need
you
to
be
on
the
right
network
so
that
we
can
then
run
grasp
find
out
where
the
join
proxy
is
and
do
the
rest.
Okay,
that's
really
it
okay.
A
The
argument
against
this
kind
of
thing
has
always
been
that
ssids
are
expensive
and
we
can't
just
set
up
our
own,
especially
in
enterprises.
We
can't
just
set
up
our
own
for
onboarding,
and
the
realization
was
that
we
already
have
it.
It's
a
captive
portal
network
and
the
enterprises
already
have
it.
A
It's
it's,
not
a
clear
text
network,
which
is
what
I'd
originally
imagined
and
you
do
it
this
way
and
it's
we
don't
have
any
definition
that
says:
how
do
you
do
eep
tls
without
client
authentication,
and
so
that's,
basically,
what
we're
going
to
do.
It's
a
missing!
It's
a
missing
slot.
We
can
fit
this
into
this
slot
and
we
think
it
works
next
slide.
Please,
it's
really
very
simple.
A
As
I
said,
there's
the
question
of:
do
you
authenticate
in
eap
the
server
and
brewski
would
say:
no,
it's
provisional,
provisional
you'll!
Do
it
later.
A
On
the
other
hand,
if
it
comes
arrives
at
a
device
that
has
a
ca,
trust
store
and
it
can
authenticate
it,
it
could
authenticate
it.
That
would
be
fine,
there's
an
additional
piece
of
work,
which
is
how
do
I
know
which
network
to
join?
A
There
could
be
many
of
them
and
in
some
sense
that
is
an
80211u
problem
and
I'm
not
even
sure
we
can
do
that
work
in
the
ietf,
but
we
do
have
a
suggested
solution
for
that
for
that
this
work
probably
probably
next
slide.
This
work
probably
belongs
in
emu,
but
I
don't
think
it's
worth
taking
it
to
mu.
Unless
this
working
group
has
a
clear
notion
that
this
is
the
direction
we
want
to
go
okay,
at
which
point
it
becomes,
we
can
argue
over.
Who
gets
the
document
and
that's
about
it.
A
There's
several
other
entities
doing
something
very
specific,
very
similar
in
different
ways,
and
that
captive
portal
network
could
be
used
for
all
sorts
of
things
right.
It
can
be
used
as
a
captive
portal,
literally
okay,
where
you
actually
go
to
a
web
website
and
actually
you
know,
put
in
your
hotel
room
number
and
last
name
and
get
access
to
the
internet
if
it's
your
laptop,
so
that
that
would
be
reusable.
A
K
Yeah,
one
of
the
other
pushes
for
implementing
this
is
things
like
keep.
As
you
say,
people
are
pushing
all
kinds
of
stuff
into
e
because
it's
just
easier
right
so
for
anyone,
who's
read:
rfc
7170,
which
defines
cheap,
there's
a
whole
pkcs7
certificate,
provisioning
thing
there
and
as
an
implementer,
I'm
sort
of
upset
about
just
shove,
everything
in
to
eat
and
what
we
probably
should
have
done
10
years
ago,
when
this
was
originally
published,
is
just
get
people
onto
a
network.
K
So
I've
been
talking
about
this,
this
general
concept
in
emu
and
other
places
for
a
while
there's
some
positive
support
for
it
and
some
pushback.
But
I
think
from
a
layering
point
of
view,
we
have
no
business
doing
anything
in
eep
other
than
authentication,
and
that's
where
this
is
going.
It
just
makes
things
easier
if
everything
is
ip
for
anything
past.
The
initial
authentication.
A
Okay
for
that,
but
when
you're
doing
it-
and
you
know,
we
can
have
10
different
onboarding
mechanisms
that
and
if
they
run
over
ip
or
panna
or
a
whole
bunch
of
other
things
whatever
it
is,
you
want
to
do
well,
it's
just
running
over
you've
got
you're
getting
an
equivalent
of
a
wired,
an
untrusted
wire,
and
I
think
that's
really
valuable,
because
I
think
it
just
brings
us
back.
As
alan
just
said,
it
brings
us
right
back
into
we're
running
ip.
A
Not
this
thing
that
fragments
poorly
over,
you
know
wireless
frames
and
has
no,
you
know,
has
no
other
controls
or
visibility
or
debug
ability
or
that
kind
of
stuff.
B
A
That
no
no,
no,
what
there
is
is
there
is
a
way
for
the
the
access
point
to
announce
the
list
of
realms
that
it
supports.
Okay,
okay
and
so
the
new
realm
that
it's
going
to
support
is
eap,
dot
arpa,
and
it
can
already
do
that.
That's
already
in
the
spec
in
802
11u.
F
A
K
Yes,
so
this
is
what
one
thing
we're
doing
here
is
defining
what
5216
missed
5216
allowed
for
unauthenticated
eeptls,
but
offers
nothing
further.
So
all
these
stos
did
magical
things
themselves,
so
we
just
defined
something
here
which
should
be
much
much
simpler.
B
F
K
F
B
Yep
all
right
sounds
cool.
Thank
you
very
much.
Okay,
I'm
going
to
skip
my
marketing
material
for
the
grasp,
dns
stuff
and
take
it
to
the
list,
and
I
think
we've
reached
another
two
full
hours
again.
Thank
you
very
much.
Everybody
and
yeah
hopefully
see
you
all
in
london.