►
From YouTube: IETF111-ANIMA-20210729-1900
Description
ANIMA meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
At
the
top
of
the
hour
and
when
you're
dialed
in
here
welcome
everybody
we're
at
the
second
anima
working
group
meeting
and
I'm
going
to
quickly
show
this
as
it
is
mandatory
right,
itf
note.
Well,
everything
you
say
and
write
in
the
ietf
shall
be
used
against
you
in
a
competing
draft.
No
sorry,
but
please
be
aware
of
everything
written
here,
I'm
not
going
to
repeat
it
all
all
right,
so
I'm
going
to
quickly
skip
across
everything.
We
said
on
monday.
A
Otherwise,
I
think
we
wouldn't
need
an
official
jabber
scribe
to
you
know
list
the
individual,
slides
the
ipr
disclosure
process
also
mandatory
just
for
the
folks
who
weren't
here
on
monday,
you
know
as
a
reminder
from
the
other
stuff.
I
just
wanted
to
say
that
there
was
some
concern
raised
about
the
time
managing
management
on
monday
that
there
wasn't
time
for
question,
and
so
I
think
there
are
a
couple
of
things
to
be
said
about
that.
First
of
all,
you
know,
please
feel
free
to
reach
out
to
the
chairs,
discussing
that.
A
A
Ask
your
question
that
shows
interest
in
the
work,
and
only
when
we
see
interest
in
the
work
will
we
basically
be
able
to
allocate
more
time
in
the
future
and
obviously,
as
soon
as
you're,
going
beyond
a
zero
zero
presentation
on
a
document.
We
would
also
expect
you
to
as
a
slot
owner
manage
your
time
accordingly
between
you
know,
power,
death
by
powerpoint
and
the
more
important
question
and
feedback
from
the
audience
right.
A
So
there
are
also
a
lot
of
other
collaborative
options
right,
usually
after
a
meeting
we
stay
around
and
talk
with
each
other.
We
can
do
that
perfectly
fine
and
exactly
you
know
this
room
place
on
gather
town
after
the
meeting,
so
I'll
certainly
be
there
and
invite
you
to
to
join.
If
you
want
to
have
follow-up
discussions,
but
please
you
know
anything,
you
do
the
more
you
disseminate
it
across
the
mailing
list.
A
Michael
told
me,
I
can
simply
inline
the
constrained
join
proxy
status,
update,
I'm
going
to
talk
about
it
and
when
michael
wants
to
say
something
more,
he
can
step
up
to
the
microphone,
so
both
join
proxy
versions
have
been
implemented
in
work
there.
The
authors
are
not
aware
of
any
issues
yet
so
the
authors
are
wondering
whether
this
is
ready
for
last
call.
I
haven't
checked
how
many
people
in
the
working
group
had
chimed
in
to
you
know
talk
about
whether
they
reviewed
it
what
they
felt
about
it.
A
A
C
C
I
think
still
to
do
so.
There
is
a
there
is
a
draft
in
github
and
the
anima
in
the
animal
working
group
github
that
we
haven't
actually
published
yet,
but
we've
made
a
lot
of
changes
and
since
the
last
ietf
that
we
haven't
published
yet
we're
looking
to
publish
in
the
next
week,
because
you
didn't
get
around
to
today,
securities
considerations,
we've
added
sections
on
how
to
handle
redirects
are,
I
think,
the
two
most
significant
changes
in
the
draft.
It
is
in
github.
C
So
how
we
handle
multiple
and
redirects,
and
we
want
to
ensure
that
you
know
a
provisional
tds
connection
may
be
hijacked.
We
want
to
ensure
that
we
protect
against
that.
So
when
the
pledge
connects
to
the
blue
c
cloud
register
and
it
will
enforce
mutually
authenticated
tls
and
as
per
the
risky
draft,
there
are
two
ways
that
the
cloud
ra
can
handle
that
they
can
either
issue
a
voucher
directly
or
they
can
do
three
or
seven.
C
C
So
what
we're
illustrating
here,
after
the
very
first
three
or
seven
and
step
three,
and
when
we
go
on
to
the
next,
we
should
authenticate
the
t-list
of
our
example.
Assuming
the
the
glitch
can
do
the
search
validation
here,
then
it
will
accept
another
three
or
seven.
But
if
we
don't
step
four
here
and
the
pledge
is
unable
to
do
a
full
and
a
tls
search
validation,
then
it
must
not
accept
any
more
redirects
and
I
must
wait
until
it
gets
voucher.
C
We
just
we've
aligned
the
naming
convention
and
ietf
outro
through
bar,
and
so
we've
renamed
idea
for
redirected,
voucher
to
idf,
itf,
voucher,
redirected
and
the
same
pattern
applies
for
ie
gf
constraint,
voucher,
an
idea
of
constraining
factor
requests.
We
just
we're
just
aligning
the
terminology
and
made
it
consistent.
C
A
A
C
There's
only
one
there's
only
one
voucher,
so
what
what
the
cloud?
What
the
cloud
already
will
do
is
the
category
will
either
redirect
you
somewhere
else
and
you
get
the
value
from
somewhere
else
or
else
the
battery
of
what's
illustrated
here
is
the
cabaret
will
issue
the
voucher
directly
and
inside
in
the
battery
response
will
be
inside.
The
json
will
be
a
pointer
to
the
est
domain,
where
you
can
then
go
to
get
your
to
your
east
general
and
get
your
certificate.
C
A
D
A
D
A
D
A
D
A
D
I
I
don't
know
what
is
on
the
edge
of
that
and
if
I
did
know
what
was
there,
then
you
could
probably
convince
me
to
bring
it
within
right.
It's
it's!
Okay,
all
right!
So
so
so
I
I
I
don't
like
there's
a
gray
area
where
I
can't
think
right
now,
but
there's
probably
a
bunch
of
things
that
we
could
talk
about,
that.
It's
like
no!
No!
This
is
not
a
pro.
This
is
not
an
appropriate
thing
to
do
this.
D
There
is
some
logical
crossover
with
as
stp
as
well,
except
that
it
doesn't
do
a
voucher
request
exactly
in
the
same
way,
but
in
terms
of
the
modeling.
So
there's
some
stuff
like
that
that
that
might
make
sense
to
where
this
would
be.
You
know
on
the
boundary
of
something,
but
I
don't
know
what
it
is.
D
For
instance,
I
don't
know
a
cable
modem,
wouldn't
should
probably
doesn't
need
to
do
this
because
it
probably
can
find
a
joint
proxy
within
the
cmts
and
it's
not
owned
by
the
end
user,
it's
owned
by
the
isp,
so
this
might
be
inappropriate
for
them,
but
it
might
be
an
example.
I
don't
know
what
else
that's.
A
D
Right
and
what
I
don't
want
to
have
is
a
six
month,
long,
security
analysis
by
drive-by
review
that
we
had
with
with
brewski,
and
so
I'd
like
to
really
up
front,
be
able
to
say
this
is
what
it
applies
to
and
if
someone
argues
well,
but
I
want
to
use
it
for
this
other
thing
or
like
well.
I've
actually
a
good
idea
right.
Let's
put
that
in
rather
than
the
other
way
around.
A
D
C
Yeah,
okay,
so
the
text,
the
text
in
the.
If
you
look
at
what's
in
github,
the
text
in
github
outlines
the
two
use
cases,
one
where
the
voucher
redirected
to
different
registrar
and
two
word
this
floor.
That
shown
here,
but
in
the
voucher
redirecting
to
a
different
register,
and
it
just
gives
us
an
example
and
bootstrapping
is
it
might
be
phone
against
an
ippbx,
but
it
doesn't,
it
doesn't
restrict
your
prohibited
any
other
use
cases.
It
just
gives
one
explicit
example
of
use
case,
which
is
simplified
before
bootstrap
discovery.
A
D
So
so
you
know
one
of
the
places
where
I
think
this
there
may
be.
Some
space
is
in
the
ysun
space
and
I'm
kind
of
hoping
that
elliott
or
nancy
or
someone
else
involved
in
that
will
say
something
more
about
that,
because
I
think
that
one
of
the
things
they
had
was
the
the
desire
to
be
able
to
move
from
statically
deployed
relationships
to
onboarding
process.
A
A
A
E
E
E
So
here
we
have
a
quick
overview
from
the
document,
so
there
is
not
much
change
in
the
content
from
the
individual
submission,
so
I
can
quickly
go
over
that
so
also
in
the
options.
So
we
took
a
decision
to
go
for
a
jws
compact
serialization,
but
nothing
new
today
on
that
and
conclusion
here
is
so
the
there
was
an
adoption
call
on
the
mailing
list.
E
A
A
Now
so,
in
terms
of,
if
the
voucher
includes
all
type
of
crazy
elements
in
the
header
where
you
know
the
registrar
isn't,
doesn't
even
know
what
they
are
and
isn't
sure
about
them,
you
know:
should
it
be
able
to,
you
know
not
accept
it?
Should
we
say
that
please
only
include
in
the
voucher
what
we
describe
here.
Nothing.
E
D
Oh,
please
go
ahead
so,
as
I
said
on
the
list,
I
think
that
if
we
do
anything
that
involves
filtering
or
rejecting
things
we
don't
know,
then
we
make
it
really
hard
for
us
to
add
new
attributes
in
the
future
right
we
get
into
the
whole
tls
1.2
version
debacle
that
you
know
means
that
we're
running
tls
1.2
forever
now
and
we
have
another
way
of
negotiating
1.3
because
of
things
that
were
enforced
in
the
middle.
So
I
I
I.
A
Yeah.
Okay!
Oh
that's
a
good
point,
so
I
was
just
writing
in
the
notes
that
this
might
simply
be
a
good
paragraph
to
write
into
the
security
consideration
section
right
that
we're
not
recommending
any
filterings
to
to
maintain
extensibility,
but
that,
obviously,
implementations
of
registrars
are
happy
to
audit
additional
fields
that
are
not
in
need
for
the
version
that
they're
implementing.
G
G
A
A
A
F
F
F
So
that
means
we.
We
follow
the
voucher
exchange
as
defined
there,
but
allow
for
alternative
enrollment
protocols
to
handle
situations
where
we
have
limited
connectivity
or
no
connectivity
to
be
able
to
have
a
proof
of
identity
bound
to
some
of
the
enrollment
information.
So
for
that
other
enrollment
protocols
that
provide
that
functionality
could
be
used
like
cmp
or
cmc,
for
instance.
So
the
second
use
case
is
the
one
where
we
did
the
main
changes
since
the
last
itf.
F
It
is
a
pledge
responder
mode.
So
what
we
do
there
is.
We
reverse
the
kind
of
interaction
between
the
pledge
and
the
registrar,
so
that
means
the
pledge
itself
is
acting
as
a
server,
and
we
call
that
that
responder
mode,
and
so
the
pledge
is
triggered
for
certain
actions,
and
we
will
see
that
later
on.
So
I
have
some
kind
of
call
through
there.
F
F
So
we
had
two
version
updates
in
the
last
site
here,
so
in
the
first
one
we
have
this
detailed
code
flow
and
also
the
definition
of
the
different
objects
that
are
exchanged
for
the
specifically
between
the
pledge
and
the
registrar
agent,
which
is
a
new
component
here.
That
directly
interacts
with
the
pledge
and
has
some
further
interaction
with
the
infrastructure,
so
the
the
registrar
and
the
mother
itself.
F
So
we
aligning
with
the
jws
sign,
voucher
and
utilize
that,
basically,
as
a
wrapper,
to
protect
the
objects
that
are
exchanged
between
the
registrar
agent
and
the
pledge,
so
what
we
did
also
since
the
last
ietf
was,
we
removed
the
proposed
handling
of
the
connection
using
using
tls
psk,
because
we
would
like
to
avoid
the
strict
relying
on
a
secure
transport
channel
which
allows
to
also
have
some
kind
of
different
connections
between
the
pledge
and
the
registrar
agent.
Those
could
be
bluetooth,
low,
energy
or
other.
F
We
defined
enhancements
in
the
voucher
request
young
model
to
allow
for
those
additional
parameters
that
are
provided
by
the
register
agent.
That's
also
visible
later
on
the
call
flow,
and
we
further
did
some
terminology
alignment
but
yeah
regarding
naming
of
pledge
agent
and
the
different
models
pull
and
push,
because
it
wasn't
quite
clear
for
everybody
what
what
is
the
model
addressing.
So
we
call
it
pledge
initiator
mode
and
pledge
responder
mode.
F
F
Sorry,
the
enhanced
voucher
requests
that
we
have.
So
this
is
the
enhancement
with
certain
data
which
is
signed
and
provided
by
the
registrar
agent.
Then
we
have
an
enhancement
regarding
the
assertion
enum
of
the
voucher,
and
I
think
that
will
be
handled
later
on
in
rfc
83
66
bit,
because
the
current
definition
of
the
voucher
doesn't
allow
to
to
enhance
the
enum
definition
in
there
and
what
we
are
looking
for
is
an
enhancement
to
allow
for
signaling
proxy
agent
proximity
instead
of
proximity
for
the
for
the
use
case
too.
F
But
it
turned
out
that
this
is
not
straightforward
possible,
because
it's
we
would
have
to
use
the
complete
module
and
not
just
the
sub
module
for
the
stp
csr.
So
we
had
some
exchange
on
the
mating
list.
Regarding
that
and
yeah,
I
think
that
this
discussion
is
still
ongoing.
So
kent
had
some
reaction
regarding
that,
because
he
is
authoring
the
stp
csr
draft
and
I
think
we
need
some
some
further
discussion
to
have
this
kind
of
stand-alone,
what
more
young
module
for
them?
F
Okay,
so
just
to
jump
to
the
abstract
view
of
the
use
case
too.
So
thanks
for
thanks,
michael
for
giving
me
the
the
impression
on
how
the
slides
could
look
like
to
make
it
more
simplified
for
the
for
showing
a
culture
like
this.
So
the
scenario
is
that
we
have
the
pledge,
which
is
that
is
on
the
left
side.
F
So
the
the
registrar
agent
is
provided
with
a
device
serial
number,
so
he
can
either
read
that
or
scan
the
serial
number
or
is
configured
with
the
serial
numbers
of
the
different
pledges
that
he
would
like
to
bootstrap
in
the
basement
and
then
based
on
that
data,
he
provides
the
registrar
certificate.
So
the
lfid
ee
certificate
of
the
registrar
and
also
some
agent
signed
data
in
jose.
F
The
pledge
on
his
site
then
creates
a
voucher
request
as
normal
in
brewski.
But
in
addition,
it
includes
into
the
pledge
voucher
request.
The
agent
signed
data
that
data
is
later
later
on,
used
by
the
registrar
and
also
by
the
mother,
to
vouch
for
a
proximity
of
that
registrar
agent
to
the
to
the
pledge.
F
F
The
registrar
itself
can
can
check
if
the
agent
signed
data
via
the
agent
signed
data
that
the
authorized
registrar
agent
was
in
contact
with
the
pledge
and
then
can
provide
his
own
voucher
request
containing
the
prior
signed
voucher
from
the
pledge
and
are
sent
it
over
to
the
mazda.
The
mother,
in
turn,
also
has
a
possibility
to
validate
the
agent
signed
data
and
can
then
issue
a
voucher
with
the
assertion
agent
proximity,
instead
of
instead
of
just
proximity.
F
F
Proof
of
possession
of
the
private
key
of
the
registrar
and,
in
case
of
of
the
model
that
I
just
described
here,
the
pledge
just
get
the
register
certificate
via
the
registrar
agent,
so
he
doesn't
have
has
a
confirmation
that
the
registrar
was
is
really
in
procession
of
the
corresponding
private
key.
So
hence
the
distinction
between
proximity
and
agent
proximity.
F
Then
the
registrar
sends
a
voucher
further
to
the
registrar
agent,
which
simply
stores
that
information
and
then
the
second
round
goes
regarding
runs
regarding
the
enrollment
request
handling.
So
the
csr
in
the
enrollment
request
is
sent
to
the
register
the
register
unpacks
this
rep
csr
and
does
the
handling
that
he
would
usually
do
based
on
on
brewski.
F
F
That's
just
a
verbal
explanation
of
what
I
just
was
stating
parallel
to
showing
the
slides
so
that
the
ancient
proximity
is
achieved
by
having
this
additional
piece
of
information
in
the
voucher
request
that
the
pledge
is
provided
with
from
the
registrar
agent.
And
then
it
makes
this
round
via
the
registrar
and
towards
the
mazar
and
the
the
registrar
as
well
as
the
mazda
has
the
possibility
to
verify
that
the
registrar
agent
was
the
authorized
one
to
onboard
or
to
bootstrap
the
pledge
and
at
the
bottom
here.
F
Okay,
so
the
open
issues
in
the
draft,
so
version
3,
addresses
most
of
the
issues
that
we
have
discussed
in
the
github
of
the
animal
working
group.
So
we
discussed
the
current
state
and
certain
open
issues
during
the
weekly
meetings
of
the
anima
design
team.
So
there
are
some
open
issues
there.
One
is
the
early
review
of
the
enhanced
voucher
request
in
section
six
by
the
young
doctor,
then
the
young
module
for
the
csr,
as
stated
at
the
beginning,
to
be
used
for
the
enrollment
request.
F
So
besides
this,
we
have
stated
throughout
the
draft
several
open
issues
and
discussion
items.
So
if
you
read
the
draft
which
I
would
like
to
encourage
you,
you
will
find
some
some
more
open
issues
and
those
can
also
be
obviously
discussed
on
the
mailing
list
or
should
be
discussed
on
the
mailing
list.
F
So
then
tell
us,
I
sent
some
information
up
front
to
you,
but
I
think
we
didn't
have
the
chance
to
really
discuss
about
that.
We
were
discussing
in
the
round
of
authors
of
the
draft.
We
were
discussing
that
currently
within
the
brewski
ae.
We
have
two
different
use
cases
which
somehow
developed
in
on
different
levels
and
in
other
and
somehow
different
level
of
detail
so
use
case.
One
essentially
provides
some
kind
of
requirements,
definition
for
a
potential
communication
architecture
that
uses
alternative
enrollment
protocols.
F
So
that
means
enabling
something
like
cmp
usage
or
cmc
usage,
or
also
motivating
esd,
full
cmc
request
and
leaves
the
voucher
handling
untouched,
and
this
is
more
some
kind
of
requirement.
Draft
and
use
case.
Two
is
really
a
specification
of
the
reversed
coil
model,
so
that's
to
to
have
a
description
of
the
call
model
itself
and
also
about
the
different
exchanged
objects
and
the
definition
of
this
new
component.
A
D
D
A
F
Yeah
definitely
so
so.
The
the
important
question
from
my
point
of
view
is,
would
that
be
a
way
forward
that
the
working
group
and
and
also
the
chairs,
see
as
as
as
a
good
way
forward
to
split
the
draft
into
two
to
separate
documents,
handling
the
use
cases
in
separate
documents,
because
they
have
somehow
developed
in
different
directions
and
the
proposals
essentially
to
split
that
current
working
group
document
into
two
new
working
group
documents
that
focus
on
just
one
of
the
use
cases.
A
H
Hi
good
evening
to
both
of
you
good
afternoon,
good
morning
to
others
and
good
evening
and
good
night
to
those
people
who
are
even
later
than
us.
I
have
two
two
very
brief
comments.
The
first
is,
I
really
do
think
that
it's
important
to
split
this
document.
I
I
think
stefan
is
exactly
right
in
in
going
in
this
direction.
H
The
reason
is
that
the
ae
draft
itself
is
getting
a
bit
unwieldy
and
you
know
in
terms
of
its
size-
and
I
think
it's
nicer
to
be
able
to
to
slim
it
down
with
a
pointer
to
the
other
work,
to
indicate
here's
how
we
solve
problem
x,
here's
how
we
solve
problem
y,
just
with
pointers.
I
think
that
would
be
a
really
nice
thing.
H
H
Actually,
I
think
it
would
be
helpful
if
the
chairs
could
help
us
in
terms
of
issue
tracking
a
bit
more
in
terms
of
just
catching
things
to
make
sure
they
get
open
in
github
or
wherever
you
want
to
open
them
and
then
just
make
sure
that
we're
not
losing
a
sight
of
anything
that
anybody
any
issue
that
anybody
has
and
that's
just
a
request.
Thank
you
very
much.
A
So
no,
I
one
high
level
question
that
was
coming
up.
While
I
was
listening
to
your
presentation,
stefan
in
in
brewski
and
and
the
voucher,
what
we
did
was
expanding
an
existing
online
csr
scheme,
namely
rfc
7030
with
a
voucher.
Is
there
any?
You
know
existing
standardized
scheme
without
a
voucher
to
do
a
csr.
D
A
D
Of
is
without
a
voucher,
but
it
involves
the
user
confirming
the
connection
in
some
way
or
validating
it
out
of
band.
And
then
we
have
all
the
cmp
methods
which
I
think
stefan
was
going
to
mention,
and
then
we
have
lots
of
methods,
but
they
almost
all
involve
they're,
not
zero
touch,
including
acme.
A
F
So
between
the
agent
between
the
agent
and
the
registrar
we
can,
we
can
use
what
is
already
defined
in
brewski,
so
that
is,
that
is
intention
to
to
not
really
deviate.
So
the
only
deviation
is
that
we
don't
use
the
ideator
authenticate
towards
the
register,
but
we
use
the
lfid
from
the
from
the
registrar
agent
and
we
send
those
rep
objects
as
json
objects.
Instead
of
sending
just
a
plain
p10
request,
because
the
p10
is
originating
from
the
pledge
and
not
from
the
registry
agent.
A
Well,
I
was,
I
was
just
saying
that
it
would
be
good
to
understand
if
there
is
or
is
not
a
need
for
a
solution
without
the
voucher
replicating.
You
know
what
est
70
30
would
be
for
the
synchronous
enrollment
without
the
voucher
right
so,
but
we
can
take
it
to
the
list
we're
running
out
of
time
here,
ken
last
one
on
this
on
this
thing
here,
yeah.
I
A
Thank
you
so
yeah.
Let
please
you
know
any
further
comment
on
the
list,
so
it's
certainly
important
that
we
get
this
this
right,
especially
on
the
split
up
any
opinions.
Please
bring
them
forward,
but
let's
here
for
the
matter
of
time,
move
to
the
last
two
slots
by
michael,
you
will
manage
the
time
between
the
two
by
yourself,
michael.
A
D
I'm
waiting
to
share
my
to
click
on
the
slides.
I
think
you
have
to
let
me
there.
We
go
okay,
so
we're
doing
8366.
First
right!
Okay,
that's
working
all
right!
One
of
the
things
that
came
up
in
doing
brewski
ae
was
writing
the
yang
to
extend
the
8360s
or
writing
the
yeah.
Writing
the
yang
to
extend
the
yang
in
83.
A
F
D
D
D
D
That's
the
problem,
new
type
of
assertion
we'd
like
to
have,
and
so
one
mechanism
that
in
googling
we
came
across
and
I'm
hoping
that
kent
might
be
able
to
tell
us
something
more
about
this
using
this
empty
leaf
mechanism
that
allows
us
to
do
some
new
things
and
it
looked
really
hacky
and
it
wasn't
clear
whether
it
was
really
blessed
or
something
that
just
slipped
through,
and
you
know
people
said:
oh,
you
could
do
this,
and
people
said.
Oh
no,
please
don't
do
that.
That's
terrible!
D
D
So,
even
if
someone
does
something
weird,
that's
unlikely
to
to
have
any
effect
at
this
point
at
some
point
in
the
future,
probably
somebody
will
be
doing
code
generation
from
yang
modules,
but
that
may
not
really
apply
to
objects
at
rest,
like
vouchers
for
that.
So
what
we've
done
so
far
with
this
document
is:
we've
turned
the
xml
from
three
years
ago
into
markdown.
D
You
did
use
the
martin
thompson
make
file
instead
of
the
kind
of
hack
together,
one
that
we
used
before
extracted
the
yang
module
to
a
file
added
some
rules
to
make
sure
that
they
get
generated
right
and
we
posted
a
xero,
a
new
document
which
should
be
word
for
word
identical
to
the
other
one.
So
the
plan
is
to
get
agreement
that
this
work
needs
to
be
done,
and
this
is
the
right
process
get
the
working
group
to
adopt
the
zero
zero
as
being
essentially
identical
to
80.
D
J
D
A
D
My
intention
was
that
the
zero
zero
would
be
word
for
word
identical,
so
the
working
group
would
say
we
have
an
identical
document
to
the
rfc
and
then
going
forward.
It
requires
working
group
consensus
to
change
so
that
you
know
you
know
that
what
the
conversion
process
didn't
screw
something
up
or
slide.
Something
in
you
know
sideways
that
wasn't
didn't
belong.
D
D
Waiting
push
the
button
tar
list
push
the
button
push
the
button.
Yep
yep
push
the
button.
Thank
you
constrained,
voucher,
hackathon,
that's
what
we
want!
Okay,
so
this
is
about
constrained
voucher
version.
13
was
posted
on
sunday
pretty
early
and
a
little
bit
of
a
reminder.
If
you
don't
know
what
it's
about
it's
about,
doing
it
brewski
without
with
replacing
a
bunch
of
protocols
with
smaller
ones
and
here's
a
large
pledge
being
onboarded
that
I
found
on
the
internet.
D
We
switched
to
referencing
the
published
rfcs
three
directorate
reviews,
which
we've
opened
37
issues,
but
we
haven't
dealt
with
a
lot
of
that.
Yet.
Thank
you
very
much
for
those
reviews
or
some
another
slide.
We
removed
some
of
the
requirements
with
respect
to
with
respect
to
discovery,
recognizing
that
when
there's
a
joint
proxy
or
something
like
that,
you
can't
actually
do
any
kind
of
discovery,
but
in
some
cases
the
the
registrar
can
be
discovered
using
seabor
coat
methods
rather
and
well.
D
You
can
look
through
the
diff
yourself
if
you
like,
and
I've
proposed
we
haven't
done
it
yet,
but
we've
proposed
to
change
the
module
name
from
ietf
constrained
voucher
to
itf
voucher
constrained.
I
I'd
like
so
that's
a
bit
of
a
bike
shed
issue
but
I'd
like
some
opinion
from
some
yang
experts
as
to
whether
this
is
even
worthwhile
or
whether
I'm
just
being
silly
for
that.
D
So
that's
about
that.
I
thought
they
would
sort
better.
I
thought
it
would
be
more
clear
how
things
went
to
be
went
together
if
we
named
them
that
way,
and
I
don't
think
it
has
a
material
effect
on
implementations
in
any
way.
In
fact,
the
running
code
won't
matter
because
it's
all
translated
to
sid
codes
about
that.
So
we
got
some
direct
reviews.
Three
reviews,
there's
a
bunch
of
issues.
D
Thank
you
to
russ,
daniel
and
hank
russ
did
his
direct
review,
like
I
think,
torrelis
pushed
the
button
at
nine
o'clock
in
the
morning
and
I
think
we
had
a
review
by
2pm,
so
that
was
really
cool
and
the
other
two
generated
a
bunch
of
stuff.
We
did
not
have
security
considerations
when
we
had
the
sector
review,
but
that's
why
we
were
interested
in
an
early
review.
What
do
you
think
that
you
know
of
of
the
security?
D
We
had
set
a
value
which
we
forgot
to
tell
people
during
the
hackathon
that
this
for
among
some
of
the
implementers,
so
65502
is
one
of
the
private
use,
content
type
content
formats
and
I
think
that
early
early
allocation
is
in
progress.
So
let
me
quickly
get
oh
and
I'll
mention
the
sid
roo
documents
which
we
depend
upon
are
in
iesg
review.
There
are
some
big
red
discusses
you
can
see,
and
your
help
in
fixing
the
document
would
be
over
in
the
core
working
group
would
be
greatly
appreciated.
D
J
D
F
D
This
point:
it's
early
enough
that
it's
still
in
the
working
group
and
still
internet
draft.
I
think
I
think
it's
it's
our
change
control,
not
ayanna's,
so
sure,
so
I
think
we're
okay.
That
way,
at
least
nobody
complained
has
complained
about
that,
and
that's
partly
what
I'd
like
to
hear
is:
if
there
are
some
complaints
about
that
process,
so
hackathon,
so
we
had
esco
iot
consultancy,
peter
vanderstalk.
I
think
he's
working
for
ocf
and
fairhair
aurelio
who
comes
from
this
swiss
university
of
technology.
D
Taurus
jones
joined
us
myself
and
we
had
thomas
from
siemens
all
had
implementations
there.
We
couldn't
use
the
itf
l2vpn
because
it
wasn't
really
ready
enough
for
people
to
do
some
things
with,
and
so
we
were
not
able
to
to
do
any
of
the
discovery
testing.
So
we
basically
had
our
pledges
talked
directly
to
each
other's
registrars
by
explicitly
telling
them
what
where
it
was,
and
we
had
a
bunch
of
things
and
we
basically
met
every
day
at
what
was
for
me
10
a.m.
D
They
give
us
a
half
hour,
long
presentation
of
a
project
involving
putting
this
in
a
lab
starting
in
september,
but
it's
kind
of
too
long
for
this
meeting
to
talk
about
so
issues
as
we
hit
the
top
of
the
hour.
Well,
so
we
forgot
to
the
earlier
collocation
I
and
a
couple.
Others
realized
that
we
had
a
problem
with
getting
ccm
8
turned
on
and
I
finally
was
was
turned
there.
One
of
the
questions
is:
should
we
allow
ccm8
on
the
registrar
to
mass
a
connection?
D
I
have
a
slide
for
that.
There's
more
issues:
x5
bag,
there's
issues
open
for
there,
I'm
not
going
to
have
time
to
go
through
all
of
them.
I'm
not
going
to
skip
that.
I
think
this
is
the
most
important
one
for
the
group
in
the
co-app
makes
the
ccm
8
modes
the
mandatory
to
implement,
and
so
people
want
to
do
that
between
the
pledge
and
the
registrar.
A
A
J
Just
a
quick
comment
I
on
there
I
think
I've
seen
two
of
them,
not
three
of
them.
I've
not
looked
them
that
closely,
but
it
looked
to
me
that
maybe
they
would
fit
into
perhaps
hold
for
document
update,
rather
than
be
verifiable
in
terms
of
the
scope
of
the
errata,
which
is
the
two
I
was
thinking
of.
A
J
Yes,
I
need
to
follow
that.
I
think
it's
fine.
I
think
there
was.
This
is
a
separate
email
about
just
including
an
email
address
for
the
structure
of
it.
I
think
the
castle
raised
an
issue.
I
don't
know,
that's
been
fixed
for
the
media
type,
but
once
that's
fine,
I
have
no
issues
with
it
at
all,
so
I
will
get
back
to
you
all
right.
Thanks.
A
E
A
D
A
G
Hi
we're
giving
that,
since
we
are
short
first
time
for
both
season,
we
should
consider
to
ask
the
slots
request
earlier
next
meeting
and
try
to
get
better
time
management,
and
hopefully
the
speakers
could
response
12
years
earlier
than
before.
We
did
have
issues
each
time
to
have
very
large
millions
slides,
so
that
makes
the
chairs
work
very
hard.
So
we
are
calling
the
support
for
everybody
to
help
us
to
better
manage
the
time
by
support
by
applying
your
time
slots
and
give
the
chairs
slides
as
early
as
possible.
Thank
you
all.