►
From YouTube: IETF108-ANIMA-20200730-1100
Description
ANIMA meeting session at IETF108
2020/07/30 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
So
I
haven't
figured
out
how
to
actually
share
the
slides
full
screen
and
be
in
the
jabra
room
at
the
same
time
to
see
it
on
the
second
notebook,
sorry
that
was
kind
of
yeah
in
any
case.
So
if,
if
if
there
is
any
issue
that
you
need
to
bring
to
my
attention
here,
I
think
today,
unfortunately
I'm
the
only
chair-
I
don't
see
a
shang
here,
then
please,
chime
in
on
the
audio
channel
and
interrupt
me,
and
I
think
that's
that's
how
we
can
go
on.
A
So
let
me
bring
up
the
standard,
slides,
okay,
so
reminder
of
the
itf
policies
right.
So
everything
that's
being
said
here
is
is
under
the
itf
laws
and
everything.
So
hopefully
I
don't
need
to
read
this
all
in
detail.
A
So
there
is
no
need
for
blue
sheets
that
should
happen
automatically
through
meet
echo
when,
when
you
are
locked
in
here
we
have
the
jabber
running.
So
if
somebody
would
care
to
be
the
jabber
scribe,
can
we
have
people
chime
in
to
be
minute
takers
I'll
try
to
do
it
myself
as
well?
I
think
rob
has
also
suggested,
but
if
there
is
any
more
who
would
be
happy
to
take
notes
given
how
it's
the
etherpad
code
emd,
it
should
be
easy
to
do
that
simultaneously
from
multiple
people.
A
Oh
slide
here
back,
so
I
think
we're
done
with
this.
So
let
me
go
through
the
list
of
working
group
documents,
so
I
think
the
most
important
one
we
want
to
get
out
is
the
acp
document.
28
on
the
telechat
in
august.
A
Update
will
be
given
as
the
first
slot
in
the
meeting,
so
that
should
then
also
unlock
all
the
cluster
weighting
on
it,
with
the
bootstrap
grass
prefix
model
and
reference
model
waiting
for
it,
the
grasp
api,
so
the
publication
request
went
out
one
month
ago.
There
was
a
mess
up
with
the
shepard
write-up.
So
that's
now
done
so
it's
in
rob,
wilson's
ad
review
queue,
so
that
should
be
a
fairly
soon.
Then
we've
got
brewski
async
and
roll
that
was
newly
adopted
after
107
update
will
be
given
this
meeting
the
constrained
voucher.
A
So
I'm
not
sure
about
the
status
of
that.
There
is
an
update
since
itf
107,
but
no
slot
request.
Is
there
anyone
from
the
authors
here
and
would
like
to
quickly
speak
up
on
behalf
of
that
draft.
A
So,
let's
move
on
yeah,
so
the
anime
grasp
distribution.
There
was
no
update
since
107,
because
there
was
the
goal
to
integrate
the
draft
car
printer,
nmr
grass,
bulk,
05
and
that's
still
ongoing.
So
there
is
no
update
for
that
in
this
itf
meeting,
then
the
non-working
group
documents
that
we
have
we've
got
the
draft
richardson
anima
voucher
delegation.
A
There
was
good
interest
in
the
working
group
in
this
document
and
the
author
said
that
their
should
probably
be
a
design
team
to
to
continue
work
on
that.
So
that
would
be
something
to
ask
here
after
the
slot
and
in
in
the
mailing
list,
and
then
we
would
ask
for
adoption
after
this
meeting
and
then
the
whole
other
list
of
documents
that
we're
going
to
have
updates
for
in
this
meeting.
A
So
then
general
reminder,
if
you're
working
on
any
drafts
that
you
think
are
related
to
anima,
whether
the
working
group
or
not
feel
free
to
use
the
enema
wg
github,
and
you
can
just
ask
any
of
us
who
have
drafts
in
there
to
add
you
to
that
github
so
that
you
can
contribute.
We've
been
using
that
for
quite
a
long
time
for
quite
a
large
set
of
the
drafts
in
this
working
group
so
and
that
basically
gets
us
to
the
agenda.
A
A
So
enema
at
itf
107
was
at
version
24..
We
had
the
open
discuss
from
ben
that
was
worked
on
by
russ
housley
about
the
rfc
822
name.
We
received
a
joe
halpern
routing
review,
so
in
25
we
first
fixed
the
remaining
ipsec
fix
ups
through
discussions
on
the
ipsec
me
mailing
list.
A
So
thanks
a
lot
for
valerie,
paul,
michael
and
others,
and
then
also
the
routing
directorate
re
review
from
joe
halpern
and
then
26
27,
the
fixes
for
russ
halsey
on
behalf
of
ben
cadog,
and
at
that
point
in
time
the
authors
thought
all
outstanding
issues
were
closed.
A
Eric
vinke,
as
the
responsible
ad
for
the
document
added
a
yes
to
the
isg
record,
was
put
on
the
telechat
for
july
by
barry,
and
then
we
received
a
set
of
new
security
or
ad
discuss
and
reviews
from
roman
danielev
ben
cadog
tentatively
cleared
his
discuss
from
the
submission
of
2627
and
bear
leiber
delayed
the
telechat
for
august
13,
because
there
were
too
few
ads
to
finish
the
review
in
july,
because
the
document
is
so
long.
A
A
So
just
the
highlights
of
the
maybe
technically
interesting
to
the
working
group
changes
enhancements.
So
the
primary
discussion
with
the
ipsec
folks
was
about
the
diagnostics
of
making
sure
that,
even
when
an
acp
secured
channel
connection
through
ipsec
is
failing,
because
it's,
for
example,
from
an
acp
node
in
a
different
domain
that
we
are
exchanging
the
trust
anchors
in
both
sites
that
is
possible
with
ipsec,
but
not
something
that
people
have
thought
about
being
usually
required.
A
So
that
was
a
good
discussion
and,
and
the
text
should
accordingly
reflect
this
now
joe
halperin's
review.
A
So
and
given
how
late
we're
in
the
game
here,
I
think
it
would
be
too
intrusive
to
try
to
change
that
terminology
that
we
had
from
day
one.
There
were
a
lot
of
good
review
and
detail
improvement
on
the
ripple
functionality
for
the
profile
for
the
routing
the
whole
acp
loopback
text
was
diligently
overhauled.
A
A
Version
26,
so
this
is
about
the
rfc
822
name
change,
so
there
was
a
for
a
long
time.
The
feedback
from
rus
via
benz,
discuss
why
the
rfc
822
name
is
not
to
the
liking
and
the
review
of
that
dragged
on,
and
so
the
arguments
changed
over
time.
So
ultimately,
and
obviously
that's
something
that
could
have
probably
been
done
earlier.
We
had
a
phone
call
myself
with
russ
and
I
also
invited
barry
leiber,
because
it
was
all
about
the
semantic
of
how
an
email
address
is
permitted
to
be
used.
A
Unfortunately,
turned
out
that
barry
was
on
the
side
of
russ,
so
that
at
that
point
in
time
I
had
to
pull
the
rope
and
basically
see
that
any
further
discussion
about
that
topic
needs
to
be
decoupled
from
the
progress
of
this
document
and
I'll
skip
about
the
all
the
you
know,
disagreements
that
maintain
on
this
subject.
So
the
proposal
from
rus
was
to
use
subject:
alt
name
other
name,
and
then
you
know
a
new
name
type
that
would
require
iana
allocation
for
that
new
other
name
name
type.
A
We
brainstormed
an
alternative
on
the
mailing
list
around
using
an
actual
urn
string,
and
I
felt
this
was
you
know
a
tiny
bit
better,
but
then
the
final
solution,
26,
is
really
to
go
with
the
proposal
from
russ
a
little
bit
a
cowardly
approach,
because
you
know
there
is
pre-existing
good
examples
of
other
certificate
extension
having
used
that
approach,
and
so
it's
on.
A
It's
not
our
fault
if
it
doesn't
work,
but
it
should
also
be
easy
to
add
a
urn
equivalent
to
other
places
outside
of
certificates
where
we
want
to
indicate
you
know
such
an
acp
note
name
in
places
where,
for
example,
only
urls
are
supported
so
in
26
the
whole
asn
code
definition
for
that
was
tested
by
russ
and
verified.
We
got
the
early
code
point
allocation
by
anna
also
done
so.
A
I
think
this
is
now
being
coded
into
the
experimental
implementations
that
exist.
Where
does
this
leave
us
with
respect
to
functional
changes?
So
obviously,
if
you
look
at
the
prior
acp
versions
of
the
draft
that
will
show
the
technical
benefits
of
rfc
82
names,
I
think
you
can
make
up
your
mind,
comparing
that,
with
the
benefits
of
of
of
this
version
listed
there.
The
one
new
thing
that
just
came
up
in
the
reprocess
is
that
there
is
this
ongoing
draft.
A
Ietf
acme
email
s
mime,
which
allows
to
do
get
a
certificate
from
a
public
register
if
with
an
rfc
a22
name.
So
that
option
is
now
not
possible
with
the
other
name.
But
then
again
that
was
never
a
consideration.
We
started
acp
we're
always
thinking
of
a
private
pki
chain
for
use
with
acp
and
enterprises
in
service
providers,
so
not
public
pki,
so
no
loss
versus
where
we
started
from,
but
maybe
still
something
to
consider
as
interesting
for
future
extensions.
A
Okay,
there
were
a
lot
of
really
good
editorial
things
from
russ
housely's
review
as
well.
I
was
looking
through
the
whole
list
and
figured
what
was
interesting
here
and,
I
think,
maybe
a
reduction
in
the
in
the
complexity
of
the
requirements.
A
Russ
was
pointing
to
that.
So
the
must
requirements
for
the
key
sizes
in
certificates
is
just
now
reduced
to
the
lowest
ones
that
we
feel
are
important,
2048
rsa
and
the
elliptic
curve
p256,
then
the
28
review
final
one
discussed
from
roman
danlav,
also
a
lot
of
good
editorial
enhancements.
So
thanks
a
lot.
What's
the
highlights
so
roman
was
asking
for
what
happens
when
we
don't
have
a
trusted
clock.
So
there
is
new
text
to
suggest
using
untrusted
ac
ntp
so
that
you
can
trust
the
peer
certificates
to
bring
up
the
acp.
A
A
Even
against
that
there's
a
more
more
elaborate
about
the
set
of
misconfiguration
sap
protects
against,
so
that
was
basically
about
the
interface
down
command
and
maintaining
acp
reachability
across
interfaces,
and
then
additional
security
considerations
that
are
actionable.
There
was
also
an
interesting
feedback
in
terms
of
saying
the
acp
significantly
reduces
this
requirement
for
operators
right.
So
that's,
basically,
hopefully
something
that's
considered
to
be
after
roman
reveals
it
against
useful
text,
and
we
forgot
to
do
a
must
against
the
ipsec
profile.
So
as
a
overlook.
A
So
I
hope
that
we
don't
have
to
return
with
these
updates
as
interesting
as
all
these
details
might
be,
and
that's
it
for
the
acp
update.
Let
me
see:
do
we
have
anybody
here
in
the
my
queue
any
questions
comments
for
that?
A
C
Do
you
hear
me
yep?
Okay,
so
I'm
slightly.
Has
the
proceed
process
issue?
What
would
be
a
happening
because
we
seems
have
enough?
C
I
know
we
don't
have
enough
ad
giving
the
their
opinions,
but
we
we
had
that
before
I
mean
we
had
that
number
of
the
opinions
from
previous
80s
before
what
happened
for
now,
because
I
see
it,
there
is
only
one
discuss
what
happened
when
we
after
we
addressed
that
one
did
discuss,
then
we
don't
have
enough
current
id
to
give
the
opinions
probably
best
for
eric
to
answer
yeah.
D
I
was
about
to
say
something
in
the
same
vein,
so
thank
you
shang
for
prompting
the
questions,
so
I'm
eric
wink.
I
am
the
responsibility
for
this
draft
because
the
ops
id
had
to
basically
pass
the
ball
to
somebody
else,
as
he
was
previously
an
author
of
the
document.
D
Basically,
first,
thank
you
to
ellis
for
addressing
all
the
comments.
Thank
you
for
the
viewers.
Thank
you
shang
as
well
for
asking
for
the
early
allocation.
Now
we
have
put
it
back
on
the
isg
evaluation
in
august
2013
or
something
like
that
august.
It
means
at
that
point
of
time
people
will
review
it
and
change
the
evaluation.
D
So
for
13th
august
you
will
see
much
more,
hopefully,
no
more
discus,
much
more
comment,
maybe
one
abstain
or
whatever,
but
I
am
quite
confident
this
time
that
it
will
go
through.
So
don't
be
surprised
that
if
the
discus
is
still
there,
it
will
only
be
clear
when
the
discus
owner
had
time
to
review
it
and,
as
you
can
guess,
I
mean
ad
this
week
are
fully
busy.
So
don't
expect
any
move
between
me
before
me
next
week.
I
would
say
hope
it.
D
A
Sorry,
I'm
just
taking
the
notes
and
waiting
for
the
next
thought
any
more
question.
Thank
you
very
much.
Eric
any
more
questions
about
the
acp.
E
A
E
Can
you
see
what
I'm
sharing?
I'm
sharing
yep
slides
it's
okay
yeah,
so
this
should
be
fairly
quick.
E
So
this
is
an
update
on
the
draft
guidelines
for
economic
service
agents,
together
with
other
authors,
brian
cheng
and
pierre,
and
so
we
issued
very
recently
version
nine.
Essentially,
this
is
a
keep
a
live
version
with
very
minor
updates,
a
few
extra
words
on
authorization
of
aza
and
some
editorial
fixes
and
all
by
brian-
and
this
was
on
purpose
because
we
already
presented
this
work
in
in
previous
meetings
and
we
have
no
further
technical.
E
I
mean
work
to
progress
on
this
one,
and
this
is
why
we
give
very
quick
status
and
requests
for
this
for
this
work
in
anima.
We
believe
the
document
is
quite
stable
for
some
time
I
mean
we
had
several
revisions.
So
now
we
add
version
nine,
which
is
just
to
keep
alive
so
most
of
the
technical
element
that
we
wanted
to
provide
in
the
document
I've
been
here
for
some
time.
E
We
had
some
revisions.
We
have
some
discussion
a
bit
among
the
authors,
but
also
with
the
working
group
which
we
made
improvements.
This
document
is
informational,
it's
just
some
guidelines
about
how
to
approach
the
design
and
implementation
of
of
aza's,
and
we
believe
this
could
be
useful
for
for
the
anime
ecosystem.
E
We
have
already
presented
this
work
multiple
times
in
the
anima
meetings,
but
also
discussed
it
on
the
mailing
list.
Recently,
we
got
only
limited
feedback
on
what
to
do
next.
We
we
raised
the
question
a
couple
of
times.
I
don't
think
we
had
any
opposition
in
continuing
on
this
work.
E
Also,
for
I
mean
further
developments.
We
believe
this
work
is
important
for
anima
and
can
be
linked
also
to
use
cases
and
different
applications
of
anima
technologies.
E
So
if
we
have
additional
documents
detailing
the
different
autonomic
functions
and
autonomic
service
agents,
I
mean
these
documents
could
prove
useful
to
indicate
guidelines
and
different
patterns.
How
to
develop
these.
These
asas,
especially
with
different
context
of
use,
different
design,
implementation
and
deployment,
consideration
a
link
to
the
different
use
cases.
E
So
that's
why
we
believe
it
will
be
good
to
progress
this
document
in
the
in
the
working
group
to
have
it
adopted
as
a
working
group
document,
so
that
when
we
also
address
aside
other
use
cases
in
application,
as
we
see
also,
for
instance,
new
new
use
of
grasp
and
different
use
cases,
this
could
serve
as
a
baseline
reference.
So
our
main
purpose
of
this
presentation
and
call
today
is
this
working
group
document
adoption
and
that's
it
for
for
this
presentation.
As
I
say
very
simple,
and
we
don't
have
so
much
update
to
discuss.
A
Right,
thank
you
very
much
laura.
What
what
what
amount
of
review
have
you
received
in
in
terms
of
people?
Having
read
the
document
and
commented
on
it.
E
Honestly,
I
cannot
remember
because
it
was
some
time
ago
that
we
made
the
latest
large
updates.
I
think
it
was
in
not
not
singapore,
but
the
meeting
before
where
we
had
this
discussion
on
the
anima
asia
ecosystem.
E
We
surely
could
benefit
from
a
bit
of
update
reviews
if
we
have
this
call
for
document
working
group
document
adoption.
I
think
if
a
couple
of
participants
will
be
willing
to
read
the
latest
version
and
give
us
feedback.
This
could
give
us
good
indication
is
at
least
the
technical
content
is
accurate
and
relevant
and
show
maybe
some
I
mean
some
line
in
terms
of
either
his
support
or
no
support
for
pressuring
this
work.
E
A
So
I
mean
we
can
try
to
ask
here
the
room,
whoever
who
has
who
have
read
the
document,
but
there
is
not,
I
think,
a
real
good
tool
to
do
this
right
now.
I'm
not
sure
that
the
humming
tool
allows
us
to
really
do
this.
I
mean
if
people
want
to
chime
in
on
the
chat,
but
otherwise
I
think
the
the
right
way
would
probably
be
after
the
meeting
to
do
an
adoption
call.
F
Yep
I've
been
in
other
sessions
where
the
chair
just
asked
people
to
put
themselves
in
the
queue
so
that
big
green
box
got
bigger
and
gave
them
an.
A
Indication,
okay,
yeah
sure
we
can
try
that
now
so
for
anybody
who
has
read
the
document,
if
you
can
simply
try
to
put
yourself
in
the
queue
just
you
know,
click
on
the
race
hand.
Okay,
and
now
why?
Oh,
here
there
we
go
okay,
I
can't
even
raise
my
hand.
So
that's
two
okay.
A
So
yeah
to
the
authors,
maybe
you
really
want
to
start
sending
out.
You
know
nagging
emails
to
the
folks.
You
think
have
done
this
and
maybe
we
should
then
first
have
and
ask
on
the
mailing
list
about.
You
know
who
has
read
this
draft
the
draft,
and
if
we
got
some
critical
mass,
then
I
think
we
can
go
from
there
into
the
adoption
call.
E
Yeah,
of
course,
thank
you
and
we
will
be
willing
to.
I
mean
continue
discussion
on
the
mailing
list
if
they
are
in
interest
or
any
comments
right.
G
B
C
With
my
post
chair
head
and
also
closer
ahead,
I
believe
this
document
is
useful,
for
you
know
how
we
may
extend
the
enema
and
also
the
toolkit
we
give
for
others.
C
You
know
grasper
press
key
and
sap
to
the
ups
up
layer,
applications
to
use
those
tools,
animator
tools,
so
this
would
nor
the
band
for
them
to
use
enema
and
giving
us
an
informational
document.
I
could
think
that's
already.
You
know
reached
the
limit
reached
the
bar
to
adopt
by
the
working
group
and
yes,
you'll,
have
the
you
know
right
procedure
to
asking
the
in
the
amenities
to
to
move
this
forward.
H
A
Cool
thank
you
by
the
way
I'm
just
you
know.
For
for
ourselves.
There
is
a
bot
at
the
bottom
of
the
notes.
There
is
a
the
action
items
for
the
chairs,
just
so
that
we
don't
you
know,
forget
again
to
do
adoption
calls
like.
I
think
it
happened
once
or
twice
in
the
past,
so
trying
to
get
better
organized
lauren.
A
Just
the
last
question
is:
is
this
something
where
you
think
that
actual
you
know,
prototyping
work,
you
know
by
by
researchers
is
something
that
would
help
or
is
this
you
know
more
like
something
that
is
at
a
more
abstract
layer.
E
No,
I
think
the
guidelines
we
provide
are
quite
I
mean
pragmatic,
it's
not
too
conceptual
so
yes,
clearly
there
could
be
a
link
with
some
implementation
or
proof
of
concept
that
could
mean
reinforce
or
be
be
presented
along
this,
this
document
so
yeah
it
could
be
also
a
direction
to
follow.
Okay,.
A
Cool,
so
if
there
are
no
more
questions
and
the
queue
is
empty,
so
let's
move
on
to
slot
number
four.
I
think
it's
going
to
be
soon.
Can
you
step
to
to
the
mic?
Let's
see.
A
Stefan,
sorry,
sorry,
I'm
always
right
and
again
I
would
appreciate
if
you
can
share
your
own,
slides,
yep
being
requested
and
being.
B
Granted
right
so,
hopefully
you
see
the
slides
now
hello,
yep,
okay,
so
I
would
like
to
give
an
update
on
the
brisket
other
kronos
enrollment
risky
ae.
B
So
brisky
ae
has
been
adopted
as
working
group
item
end
of
july
after
the
last
ietf
meeting
107.,
just
to
make
a
short
recall
about
the
problem
statement
and
the
overview.
The
background
behind
that.
That
draft
is
basically
that
we
see
different
industrial
scenarios
in
which
we
have
limited
connectivity
to
several
services
like
the
pki
itself,
so
we
have
a
limited
onsite,
pki
functionality
support
or
we
even
may
have
limited
connectivity
to
a
domain
registrar.
B
So
the
intention
of
the
draft
is
basically
to
address
those
two
scenarios
by
utilizing:
consistently
authenticated
self-contained
object
or
signed
wrapped
objects
also
for
the
certificate
enrollment.
So
currently
the
voucher
exchange
sequence
in
risky
already
utilizes
self-contained
objects
that
have
no
binding
to
the
underlying
transport,
and
we
would
basically
enhance
risky
to
support
the
same
for
the
enrollment
as
well.
B
B
So,
first
of
all,
from
a
functionality
point
of
view,
we
have
an
inclusion
of
different
discovery
options
in
the
draft
now
for
the
enrollment
endpoints
that
are
offered
by
the
domain
registrar.
B
So
that
was
something
which
was
already
announced
or
remarked
in
in
section
503
513
in
the
o3
version
of
the
individual
draft,
and
now
we
moved
it
out
of
that
specific
use
case,
because
the
discovery
option
seems
to
be
more
important
and
also
seems
to
be
applicable
to
the
use
case
2..
B
So
I
have
some
some
slides
for
that
afterwards
to
basically
discuss
the
approach
for
the
discovery
of
those
enrollment
endpoints,
then
there
were
some
missing
details
in
the
description
of
the
call
for
the
second
use
case.
So
the
second
use
case
introduces
a
pledge
agent
that
basically
provides
the
connectivity
during
the
onboarding
phase
between
the
pledge
and
the
domain
registrar,
and
the
intention
is
to
keep
the
interface
between
the
pledge
agent
and
the
domain
registrar
as
it
is
defined.
Right
now.
B
For
the
for
the
interface
for
the
pledge
to
the
domain
registrar
as
as
much
as
possible,
so
we
we
basically
aligned
better
with
the
risky
draft
and
also
included
the
distribution
of
ca
certificates,
optional
message
in
there.
So
there
is
some
more
explanatory
text
in
the
in
the
draft.
Regarding
that,
then
we
updated
the
cmp
example,
which
was
provided
in
section
6
as
one
example
for
utilizing
alternative
enrollment
protocols
that
support
the
feature
of
self-contained
objects
or
of
authenticated
self-contained
objects
to
use
the
lightweight
cmp
instead
of
cmp.
B
We
received
several
comments
also
during
the
adoption
call
regarding
structure
and
shortening
certain
text,
and
that
was
already
included
in
the
in
the
updated
version
that
was
provided
as
draft
zero
on
sitf
draft
zero,
so
so
more
details
regarding
the
the
changes
in
the
draft.
So,
as
said,
we
have
added
the
discovery
support
here
and
the
intention
is
to
to
support
different
enrollment
endpoints
at
the
domain
registrar
and
therefore,
is
it
necessary
to
allow
the
pledge
to
to
pick
the
appropriate
one
so
to
provide
the
information
to
the
pledge
to
take
the
appropriate
one.
B
So
what
we
did
here
is
we
defined
a
new
worry
for
the
discovery
as
well
known,
well-known
risky
and
by
by
doing
a
get
on
the
well-known
risky.
The
domain
registrar
is
intended
to
return
the
endpoints
available
at
the
server.
B
So
we
already
included
an
illustrative
example
for
est
and
lightweight
cmp,
which
I
have
on
the
next
slide,
and
let
me
jump
back
and
forth
between
those
slides
just
to
give
you
an
and
how
that
looks
like.
So
the
request
would
be
a
get
on
the
well
known
part
with
with
risky
here
and
then
the
result
would
be
which
endpoints
are
available
at
the
domain
registrar
and
as
you
can
see,
this
is
the
voucher
handling.
B
What
you
can
see
here
is
that
we
changed
and-
and
that
is
also
a
question
that
has
been
discussed
on
the
mailing
list-
we
changed
for
the
voucher
handling
the
naming
here
from
est
to
brisky,
because
from
our
perspective,
it
was
more
stringent
to
to
utilize
risky
here
and
not
est,
as
the
voucher
handling
itself
is
decoupled
from
est.
B
So
if
you
would
like
to
allow
for
alternative
enrollment
protocols
here,
then
it
would
be
more
straightforward
to
use
a
different
naming,
and
that
was
one
issue
that
was
discussed
on
the
mailing
list,
and
I
think
we
we
haven't,
found
a
conclusion
here.
So
the
proposal
is
basically
to
rename
the
endpoints
for
the
voucher
handling
from
est
to
brisky
in
the
brisket
document.
To
avoid
that,
we
have
her
inconsistencies
regarding
the
naming
or
have
even
have
two
different
namings
for
the
end
points
that
are
provided
by
the
domain
register.
Back
to
the
pledge.
B
Nothing
more,
nothing
more,
but
from
from
a
logical
point
of
view,
the
voucher
request
or
the
voucher
handling
itself.
It's
it's
decoupled
from
the
actual
enrollment
protocol
and
people
might
get
confused
if
they
read
est
here
and
somebody
is
using
a
different
enrollment
product.
B
So
then
we
would
have
a
mixture
of
est
and
whatever
cmp,
for
instance.
So
from
that
point
of
view.
Yes,
it
is
a
beauty
thing,
but
it
tries
to
to
provide
consistency
in
the
naming
of
what
is
voucher
related
and
what
is
certificate.
Enrollment,
related
yeah
and.
I
Let's
see
here
good
afternoon
good
morning,
good
evening.
I
Twirlis
I,
like
the
the
new
coved,
look
you're
sporting.
So
congratulations
on
everybody
surviving
this.
Thus
far,
I
was
going
to
add.
I
think,
first
of
all,
there's
a
let
us.
Let
us
first
take
note
that
the
discovery
mechanism
that
stefan
has
put
forward,
I
think,
is
something
that
is
sorely
needed.
I
The
the
fact
is
that
regrettably-
and
regrettably
I
should
say,
there's
not
a
single
way
to
do
these
enrollment
functions
and
personally
I
would
like
there
to
be,
but
given
that
there
isn't,
if,
if
a
client
is
able
to
figure
out
quickly,
whether
or
not
it
can
be
supported
or
whether
it
can
answer
with
one
of
the
supported
mechanisms,
I
think
this
is
very
useful.
I
The
second
thing
is
that,
regarding
what
the,
what
the,
what
the
end
points
are
for
brewski
there's,
one
aspect
that
I
think
deserves
a
little
bit
of
programmatic
thought,
which
is
how
these
functions
might
be
routed
on
the
server
implementation.
I
So
the
there
are
a
couple
of
things
to
think
about
the
first
of
which-
and
there
may
not
be
a
right
answer
here,
right,
the
the
first
of
which
is
you.
Could
we
could
separate
out
brewski
endpoints
right
such
that,
if
you're
offering
them,
you
can
route
them
to
the
brewski
process.
I
I
Python,
this
probably
shouldn't
be
a
problem
if
you're
using
something
like
flask
or
a
flask
like
mechanism,
but
with
more
of
with
it
will
very
much
depend
on
some
of
the
architecture
around
the
implementation
too.
So
that
that's
the
only
comment,
I
think
there's
a
little
bit
more
work
to
be
done
here,
whether
or
not
we
actually
want
to
add
aliases
or
rename
or
other
things
like
that.
I
think
I
wouldn't,
I
think
what
we
said
on
the
mailing
list
and
stephanie.
I
Please
correct
me
if
I'm
wrong
and
you're
tutorials
is
that
making
a
late
change
like
this
to
to
actually
change
things
probably
isn't
appropriate,
given
that
there
really
are
some
implementations
hanging
around
out
there
and
if
we
did
so
we'd
have
to
leave
aliases
or
or
indicate
some.
A
Thank
you,
I
kill
it
so
so
my
suggestion
would
be
to
see
if
we
can
simply
extra.
You
know,
after
having
experience
with
way
too
large
way
too
long
running
big
documents,
how
about
really
the
the
option
to
writing
a
small
document
that
will
update
brewski
with
just
these
name
changes
and
that
future
things
goes
under
brewski
when
it
extends
brewski
and
make
that
a
small
you
know
update
to
brewski.
You
know
that
that
that
will
basically
push
out
after
we
have
a
brewski
rfc.
B
Opinions,
stefan
yeah
would
would
be
fine
for
me
as
well.
So
that's
that's
then,
rather
related
to
a
timing
issue,
instead
of
including
it
right
now,
because
it's
already
in
the
edit
okay,
yeah.
A
Okay,
yeah!
That's
that's
basically
that,
because
I
mean
we
wouldn't
want
to
make
this
document
an
update
to
brewski,
because
it's
kind
of
an
independent
document
itself-
and
there
will
be
you
know,
I
think,
other
documents
that
are
extending
brewski,
for
whom
we
also
want
to
apply
the
the
update
with
this
prefixes.
A
Okay
thanks
and
if
you
can
hurry
up
a
little
bit,
we're
already
starting
to
have
to
think
about
timing.
B
Okay,
so
then
there
was
further
details
that
further
details
regarding
the
changes,
so
we
provided
missing
details
for
the
description
of
the
call
flow
of
the
patch
use
case
pledge
agent
use
case.
I
stated
that
already
also
the
updated
cmp
example
and
some
editorial
changes
which
basically
relate
to
the
structure
of
the
document
and
reworking
and
shortening
some
text
to
be
more
crisp
in
the
in
the
in
the
description.
B
So
regarding
the
discussion
itself,
so
I
take
from
that.
It
would
be
good
to
have
the
the
the
discovery
part
as
part
of
this
document,
but
not
include
the
the
renaming
of
est
of
of
the
endpoint
names
from
est
to
brewski.
B
Have
this
one
as
a
separate
document
that
updates
brewski
an
open
issue
I
have
regarding
the
discovery
of
enrollment
options
or
if
we
rely
on
something
like
which
was
proposed
in
the
example
in
the
document,
well-known
brewski
or
if
we
go
with
something
like
proposed
for
co-op
like
a
well-known
and
then
core
question
mark
and
the
result
would
be
risky.
This
is
something
we
we
don't
need
to
decide
right.
Now,
that's
more
related
to
the
discovery
itself.
Then
right.
B
So
right
now
we
intend
to
require
no
specific
device
credentials
on
the
pledge
agent
itself
to
authenticate
towards
the
domain
registrar.
The
reason
for
that
is
to
allow
arbitrary
devices
to
be
used
as
a
pledge
agent,
and
we
rely
on
the
fact
that
there
is
a
signature.
Wrapped
object,
that's
being
exchanged
between
the
pledge
and
the
domain
registrar
via
the
clutch
agent.
B
So
this
is
something
we
we
should
also
discuss
on
the
list.
So
I
numbered
that
here.
So
we
can
easily
reference
to
that
on
the
list,
not
quite
sure
if
there
is
an
immediate
answer
for
that,
but
I
would
post
that
question
to
the
list
all
right.
B
Okay
and
the
last
two
questions
is
the
if
it
is
necessary
to
do
the
provisioning
of
the
proximity
registrar
certificate
to
the
to
the
pledge
from
the
pledge
agent
or
if
this
can
be
done
via
the
voucher
response
that
is
provided
by
the
domain
registrar
already
containing
the
registrar's
certificate.
B
So
that's
currently
an
open
issue
in
the
document,
and
the
proposal
here
were
to
rely
on
the
voucher
response
containing
the
domain.
Registrar
certificate,
also,
a
point
that
we
can
we
can
take
to
the
list.
Probably
and
last
but
not
least,
we
we
thought
about
different
transport
options
in
the
addressing
scheme
for
the
enrollment
protocol,
and
the
proposal
here
in
this
document
so
far
is
to
align
with
risky.
That
means
to
use
https
as
we
intended
risky
aes
update
to
brewski.
B
What
I,
what
I
took
from
the
discussion
so
far
is
that
it
would
not
be
intended
that
brewski
ae
is
updating
brewski,
but
is
seen
as
an
accompanying
document
to
to
brewski
is
that
is
that
right.
A
I
hope
my
interpretation
of
the
wonderful
update
word
is
correct
right,
but
yeah.
If
we,
if
the
change
is
done
in
another
document
and
that
other
document
becomes
the
normative
reference,
then
this
wouldn't
need
to
be
the
an
update
anymore.
But
that's
really
just
you
know
a
one-liner,
oh
and
then
we
got
the
expert.
Yes,
please
rob.
J
Hi
so,
as
far
as
I
understand
there
aren't
any
very
strict
rules
on
exactly
how
update
is
defined,
so
I
I
think
we
can
come
to
a
sort
of
sensible
interpretation
here
and
that's
probably
good
enough,
although
you
may
find,
then
it
goes
through
isg
review
that
people
have
different
opinions.
So
so
just
be
aware,
thank
you.
H
So
I
think
that
the
most
of
this
document
would
follow
under
the
subcategory
of
extends
and
the
part.
The
discussion
we
had
earlier
about
the
end
points
would
fall
under
the
amends
right
and
that's
the
the
distinction.
A
I
think
immense
means
update
but
yeah.
So
I
think
that's
that's
a
fun
discussion
to
have
later
yeah.
A
A
B
A
B
A
So
does.
B
This
need
to
be
an
individual
submission,
or
should
that
already.
A
B
A
Okay:
okay,
thank
you
very
much
and,
and
also
just
wanted
to
give
kudos
that
you're
one
of
the
unfortunate
not
that
many
drafts
in
our
working
group
that
has
a
real
change
lock.
So
it's
actually
easy
to
also
what
you
said
to
get
that
from
the
document,
so
meant
as
an
encouragement
to
other
authors
that
might
be
listening
all
right.
A
If
there
are
no
more
questions
here,
let's
move
to
the
next
slot.
Michael,
do
you
want
to
step
forward
broski.
A
A
H
Share
my
screen
there
we
go
risky
cloud,
you
can
see
it.
You
can
hear
me
and
you
can
see
me
and
you
can
see
my
document
right.
H
H
Click
there
we
go
so
short
of
it
is
that
the
brewski
document
says
there
could
be
something
called
the
cloud
registrar
and
it
says
nothing
about
what
it
does,
and
this
document
tries
to
do
that.
We
had
four
possible
uses
in
the
original
document.
Four
possible
meanings
in
the
river
mountain.
We
reduced
this
to
two
unique
situations
and
the
use
cases
there
I'll
go
into
them
in
a
little
bit.
H
So
the
basic
concept
is
that
you
have
a
pledge
and
it
would
like
to
do
something
with
the
cloud,
and
so
it
has
something
built
in
some
anchor
there.
Typically,
this
pledge
somehow
gets
on
the
internet
through
magic,
probably
because
it
has
a
cable
and
it
gets
plugged
into
a
network,
and
the
network
has
something
like
ipv6
ras
or
dhcp
v4,
and
but
it
still
needs
to
join
the
rest
of
the
secure
part.
So
this
is
primarily
not
about
devices
that
need
to
some
to
do
something
to
get
on
the
network.
H
First,
if
you
need
to
do
that
wi-fi
kind
of
thing,
then
you
may
be
into
the
space
of
brewski
teap
or
something
else.
So
we
things
that
we
did
figure
out
is
a
bunch
of
things
that
I
crossed
out
that
we're
not
gonna
do
and
I'll
go
into
that
that
processes.
H
So
we
did
figure
out
that
it's
going
to
be
a
307
redirect
if
there
are
any
redirects
in
the
http
level,
that's
the
one
we
expect,
and
this
solves
this
scenario
solves
the
problem
that
the
pledge
has
been
deployed
in
a
network
with
no
joint
proxy.
No
acp,
no
grasp
nothing
to
have
any
idea.
What's
going
on
so,
for
instance,
your
employer
gives
you
a
voip
phone
for
pandemic.
Take
tells
you
take
it
home
plug
it
in,
but
it's
it's
actually
still
in
the
box.
They
haven't
touched
it
at
all.
H
It's
done
nothing
whatever
or
you
know
it
was
drop
shipped
to
you
from
the
supplier,
so
when
it
turns
on
and
it
discovers
that
there's
no
local
resources
to
help
it
as
a
fallback,
it
calls
home.
It
calls
the
cloud
registrar
and
it
says
something
to
that
device
to
the
registrar
and
says:
hey,
here's
a
voucher
request
and
in
that
voucher
request.
Of
course
it's
signed.
It
has
an
idf
id
and
a
bunch
of
of
identifying
information,
and
the
cloud
registrar
says:
oh
yes,
I
remember
this
device.
H
I
sold
it
to
tourists,
so
I
should
redirect
him
to
the
his
employer
or
his
enterprise's
home
registrar,
which
is
somewheres
out
on
the
internet.
Maybe
it's
in
their
office
in
the
private
cloud,
and
maybe
it's
a
multi-tenant
system
in
a
public
cloud
doesn't
matter
what
matters
is
that
there's
a
url
goes
into
307
message
and
the
process
continues.
Brewski
continues
as
normal,
with
a
new
vote
to
request
to
this
and
all
the
rest
of
the
the
normal
process
back
to
a
massa
and
an
enrollment
with
that
part.
H
So
that's
scenario
one
and
you
get
a
certificate
out
of
it
scenario.
Two
is
a
little
bit
different
in
this
case.
It
solves
the
problem
that
the
enterprise
would
like
to
do.
Brewski
but
they're
not
yet
ready
to
do
it,
but
they
do
certificates.
They
do
have
perhaps
an
est
server
which
they're
using
for
other
things,
but
this,
but
they
don't
do
brewski
at
this
point.
They
don't
know
how
to
do
that.
H
So
you
send
a
voucher
request
and
you
get
a
voucher
back
and
it
still
pins
the
home
registrar
and
again,
it
knows
who
the
home
registrar
is
because
supply
chain
integration
tells
you
what
the
who
was
sold
to,
and
so
the
pledge
then
says:
oh
okay,
and
it
just
jumps
to
the
point
where
it
normally
would
do
an
enrollment,
but
now,
instead
of
doing
the
enrollment
with
the
registrar
that
it
started
with,
it
does
the
enrollment
with
the
registrar
that
it
was
told
about
which
is
now
just
a
straight
est.
H
So
the
pledge
already
supports
and
trusts
that
thing
and
the
home
registrar.
Well,
it
trusts
it
because
it's
got
it
knows
which
devices
it
purchased,
or
it
just
supports
everything
from
particular
manufacturer.
H
In
fact,
as
far
as
I
can
understand,
they
do
the
parts
one
and
two
and
are
still
trying
to
figure
out
the
part
three,
and
so
this
may
be
a
good
addition.
Work
remaining
to
do.
We
need
to
properly
and
in
detail,
articulate
the
applicability
for
each
use
case.
We
need
to
define
the
voucher
extension
for
the
8366
voucher,
that
we
need
for
scenario
two
and
we
need
to
consider
if
supporting
cmp
or
as
the
ep
is
desired
and
how
we
would
signal
that
and
that's
about
it.
A
H
So,
for
instance,
if
someone
in
the
case
of
if
you
know
intel,
sdo
or
arm
palladian
pelanian
works,
you
actually
wind
up
phoning
home
to
the
vendor
of
the
chip,
not
the
vat
manufacturer,
but
we
just
think
it's
enough
to
say
it's:
it's
not
it's
not
it's
not
part
of
the
home
domain
and
it's
not
part
of
the
where
you
are
now
it's
in
the
cloud
and
yeah.
If
it's
in
the
manufacture,
that's
probably
the
likely
case,
but
that's
not.
H
I
don't
think
that's
exclusively
the
case,
so
I
don't
think
I
would
wanna
okay
to
confuse
people
with
the
mass.
So
we
had
a
long
conversation
as
to
whether
this
is
the
masa
and
one
of
the
things
that
we
realized
was
that
well
yeah
it
it
share.
It
make
sure
our
database
with
the
nasa,
but
it
also
could
be
completely
separate
in
a
lot
of
ways.
A
I
just
think
cloud
is
so
cloudy
right,
so
anything
that
would
be
more
specific
as
to
you
know
a
difference
in
well,
it's
not
yet
delegating
I
mean
it's
before
delegating
to
the
supposed
owner
right,
so
that's
would
be
lovely
to
find
a
better
term.
H
C
Shang
hi
hi
michael
this
is
shane.
I
actually
has
another
program
rather
than
the
term
cloud
in
principle,
I'm
fine
for
the
term
cloud,
but
I
have
problem.
How
do
you
find
the
cloud
register?
Looking
at
your
document,
it
still
looks
like
a
magic
for
me.
You.
C
But
that
means
you
have
to
use
other
mapping
system
to
fund
it
or
you
have.
You
know,
funds.
Well,
we
are
known
cloud
register.
That's
actually
another
issue,
is
you
know
another
security
issue?
If
you,
you
know
have
to
rely
on
such
mechanism,
because
you
don't
know
whether
your
dns
resolver
is
secure
enough
or
not,
then
that
make
you
know
redirected
to
another
untrustable
register.
C
G
H
So
it's
over
https
and.
C
G
H
And
then
the
tls
connection
will
fail
and
then
either
the
device
will
try
again
and
get
to
the
right
place
or
it'll
continuously
fail
and
get
returned
to
the
manufacturer.
With
some
problem-
and
you
know
attackers
that
could
do
this
could
could
drop
any
packets
they
like,
but
but
they
can't,
they
can't
fake.
They
can't
fake
it,
because
the
pledge
has
the
trust
anchor
for
the
cloud
registrar
built.
H
I
Yeah,
I
was
just
gonna
just
sell
it.
I
was
just
gonna
answer
torrellas's
my
question
about
using
the
term
cloud.
One
thing
that
I
liked
about
using
the
term-
and
I
I
agree
with
you:
it's
a
bit
buzzwordy
when
we
say
it
at
the
ietf
store
list-
is
that
there
are
oftentimes
some
complexities
that
are
introduced
because
you're
dealing
with
more
than
one
element,
and
so
maybe
the
thing
to
do
is
if
we're
going
to
use
the
term,
maybe
call
out
what
it
means
in
this
context
and
what
complexities
are
introduced.
H
I
would
be
happy
to
call
it
potato,
but
I
just
at.
H
Think
it
it
works
the
potato
yes,
but
at
this
point
it
it,
I
think,
there's
actually
some
benefit
by
by
by.
H
B
Michael,
I
just
realized
I
should
have
switched
on
the
video
as
well.
I
just
found
the
knob
for
that.
Anyway,
you
stated
that
the
address
of
the
cloud
register
would
be
provided
at
compile
time,
which
really
makes
it
fixed
to
the
to
the
vendor
of
the
device.
Actually,
is
there
any.
H
Since
the
device
has
never
been
configured
before
and
the
point
is
to
get
a
an
anchor
a
trust
anchor
shared
with
the
device
that
would
allow
the
home
registrar
to
configure
it
right,
so
we
have
to
start
with
somewhere
so
once
the
device
has
been
configured
once.
If,
if,
for
instance,
you
then
want
to
change
something
like
that.
Well,
that's
fine!
I'm
not
suggesting
a
a
mechanism
there.
It
could
be
done
through.
You
know,
net
conf
for
sure,
but
I
don't
see
I
don't
see.
H
I
don't
see
a
point
in
in
having
anything
other
than
the
manufacturer
can
figure
this
anchor
in
because
they're,
the
ones
that
have
to
decide
whether
they're
going
to
support
it
and
how
they're
going
to
answer
the
question
right.
So
I
I
don't
think
I
don't
think
it
makes
any
sense
to
do
this
by
dhcp
or
anything
else,
because
if
you
have
access
to
configure
some
data
by
dhcp
in
this
case,
then
you
probably
have
access
to
configure
the
address
of
the
home
registrar.
H
H
Okay,
the
scenario
specifically
like
I
said
you
know
you,
you
bring
something
home
for
the
pandemic
and
you
need
it
to
be
part
of
your
corporate
environment
and
owens
that
was
they're
very
much
and
they're,
both
in
the
voip
space
that
was
the
their
absolute
number
one
that
was
their
their
use
case
right.
There.
A
B
Software
yeah-
I
I
was
just
thinking
about
there-
are
potential
use
cases
where
somebody
would
build
a
device
that
consists
of
several
other
devices,
and
there
is
maybe
some
kind
of
proxy
mechanism
necessary
to
be
able
to
configure
a
cloud
register.
B
A
That
actually
is
a
good
good
point
where
you
may
actually
found
the
loophole.
In
terms
of
saying
there
are
other
solutions,
I'm
not
sure
whether
I
I
know
people
who
have
been
working
on
on
on
these
bootstrap
problems
and
might
rather
justify
a
separate
document,
because
I
think
what
you're
now
saying
is
that
through
physical
access,
initially,
you
are
creating
another
possible
chain
of
trust.
G
I
G
Okay,
so
so
my
question
is
so
there
is
a
familiar
problem
that
I'm
we're
trying
to
solve.
Basically,
I'm
I'm
looking
at
a
problem
in
front
of
from
a
fintech
point
of
view,
fintech
application
point
of
view
where
we
are
rolling
out.
Thousands
of
swiping
machines,
for
instance
like
adc.
G
And
one
of
the
challenge
that
is
to
how
do
you
securely
authenticate
the
systems
when
they
come
with
transactions
on
the
on
the
machine?
So
so
I
was
interested
in
this
proposal,
so
this
is
one
of
the
reason
why
I'm
following
this
so.
J
G
Yes,
that's
right!
Oh
okay,
that's
been
no,
it's
slightly
different.
So
let's
say
I
know.
Okay,
let
me
just
take
a
minute
to
explain
the
whole
scenario
right.
So
we
have
a
vendors
like
assume
that
we
have
fighting
machine
vendors
from
which
we
ship
the
swiping
machines
to
the
merchants,
so
the
merchants
are
going
to
get
like
like.
Similarly,
what
you
mentioned
about
some
employee,
getting
a
machine
from
the
employer
right
from
the
supplier
triggered
by
the
employee.
Now
this
merchant
gets
the
machine.
G
So
let's
say
they
are
manufactured
by
a
by
a
supplier
called
foo.
Now,
as
you
said
right,
it's
coded
hard
coding
to
actually
go
back
to
that
supplier
as
as
a
part
of
initial
provisioning.
Now
can
the
supplier
say
that
because
the
supplier
knows
what
range
of
machines
have
been
shipped
or
maybe
a
serial
number
of
machines,
possibly
something
as
indicator
and
then
redirect
that
enrollment?
G
To
my,
which
is
let's
say,
I'm
a
bank
or
maybe
a
wallet
provider
right
as
an
enrollment.
H
Yes,
that's
exactly
the
point.
The
point
is
that
that
the
the
the
supplier
has
a
record
of
of
which
devices
they
sold,
to
which
enterprise
okay
and
therefore
is
able
to
redirect
intelligently
based
upon
this,
and
this
initial
gotta
move
the
most
in
the
right
window.
This
initial
voucher
request
here
it's
a
signed
object.
H
It
contains
serial
number
of
the
pledge
it's
signed
by
the
pledge's
private
key,
and
so
the
registrar
is
very
confident
that
it
it
actually,
the
cloud
director
is
very
confident
that
it
is
receiving
a
request
from
a
legitimate
place.
G
H
Of
the
problems
that
we
often
have
with
voip
telephony
is
that
often
it's
done
with
an
unauthenticated
http
or
sometimes
you
know,
dhcp
tftp,
to
get
their
configuration
and
then
the
problem
is
that
you
wind
up
providing
the
sip
credentials
in
the
clear
effectively
to
anyone
who
asks
right.
This
has
been
a
great
source
of
fraud,
so
they
really
want
to
know
that
it's
the
really
the
legitimate
phone
before
they
send.
They
redirect
it.
G
Understood,
okay,
so
yeah
I'll
be
more
interested
to
have
this
conversation,
maybe
offline
with
you
and
elliot
well,.
G
Yeah
yeah,
okay,
yeah,
so
so
because
what
we
hear
from
the
suppliers
that
they
everybody
has
admin,
as
you
mentioned
the
term
cloud
right,
so
everybody
have
that
store
and
they
call
it
a
store
and
they
say:
okay,
you
come
to
my
store,
get
your
image
or
your
patches,
and
similarly,
this
could
be
a
certificate
could
be
one
more
addition
to
their
artifacts.
I
mean
I'm
just
looking
at
thinking
around
that.
A
Okay,
so
it's
already
10
past
your
you
know
all
the
remaining
slots
are
yours,
just
you
know,
try
to
finish
a
few
minutes
before
the
end
and
split
up
the
time
as
you
like.
H
H
A
Okay-
and
I
think
that's
an
ai
here,
may
I
ask
for
well
I
mean
we
can
basically
try
it
try
the
same
thing
again
like
get
into
the
audio
cue
raising
your
hands.
If
you
have
read
the
document.
A
H
Okay,
so
I'm
going
to
talk
about
three
other
documents
and
those
they're
they're
listed
there.
So
I
talked
about
this
an
hour
ago
at
sec
dispatch
some
of
those
details,
but
with
a
different
point
of
view.
So
obviously
we
have
these
two
documents.
Everyone
knows
about
them,
they're
in
various
states
of
being
done.
H
Last
fall,
I
wrote
a
document
on
operational
considerations
for
the
registrar
and
includes
you
know,
suggestions
on
different
things,
prescriptive
suggestions
on
how
to
run
the
appropriate
ca
for
appropriate
sized
enterprise,
and
I
wrote
a
document
on
that's
supposed
to
be
prescriptive,
on
how
the
vendor
operates
its
ca
for
doing
its
idef
id
work
and
how
it
deals
with
maintaining
the
need
to
sign
the
vouchers
over
time.
H
After
a
fair
bit
of
feedback,
particularly
in
the
pki
side
of
things,
I
decided
it
made
sense
to
split
the
document
up,
partly
because
it
had
a
probability
far
beyond
anima,
but
also
because
it
was
turning
out
to
get
hard
be
hard
to
do
so.
The
greenish
color
document
there,
the
idea
of
consideration,
so
I've
just
brought
that
to
you.
H
H
Am
I
sharing
slides
now?
Yes,
okay!
Well,
that's
too
bad,
so
it
was
showing
them
on
my
screen
as
being
shared.
That's
really
bizarre,
but
also
giving
me
errors.
So
I
just
ignore
the
errors.
Okay.
So
this
document,
okay,
I
told
you
about
the
documents.
Then
we
had
two
documents.
H
I
wrote
a
two
documents
relating
to
operational
considerations
decided
the
second
one
was
far
too
broad
and
I
split
it
up
and
I
about
an
hour
ago,
I
spoke
at
the
sec
dispatch
meeting
about
this
document
in
the
green
and
the
feedback
is
a
bit
confused,
but
I
think
that
it
may
not
go
forward
in
the
ietf,
but
it
might
have
a
place
in
the
irtf
and
we'll
see
the
document
that
what
remains
of
the
master
considerations
document
is
intended
to
be
normative
and
sorry
prescriptive
and
and
is
supposed
to
reference.
H
What's
in
the
green
document,
that
part
is
a
replay
so
to
recall
this
anima
brewski
acp
security
architecture
has
a
vendor
and
an
enterprise
operator
and
the
anima
registrar
considerations
are
about
what
he
does
and
the
massive
considerations
are
about
what
he
does.
The
document.
The
green
document
basically
is
about
linking
what's
in
the
device
to
what's
in
the
manufacturer's
point
of
view,
and
then
also
it
says
a
little
bit
about
the
registrar.
I
hope
so.
H
I
presented
that
sec
dispatch
a
few
minutes
ago,
as
I
said
the
operational,
so
this
is
about
the
mat,
the
operational
considerations
for
the
registrar,
so
primarily
it
centers
around
this
diagram,
and
it
goes
into
some
detail
as
to
thoughts
as
to
how
to
build
the
various
pieces
and
how
to
do
them
at
the
right
scale
for
the
right
size
of
enterprise.
It's
not
normative
in
the
sense
that
you
don't
have
to
implement
it.
The
way
that
suggested,
but
but
this
is
a
suggestion
on
on
how
certain
things
could
work.
H
H
How
do
I
deal
with
my
database
and
do
I,
for
instance,
want
the
same
platform
that
listens
to
new,
potentially
malicious
devices,
to
also
be
the
device,
the
platform
that
talks
to
the
nasa
okay?
Or
do
you
want
to
put
that
through
a
database?
And
if
you
do
there's
some
asynchronous
and
synchronous
considerations
that
that
apply,
and
so
that's
part
of
it,
and
then
you
there's
other
parts
like
for
instance?
How
do
you
do
the
grasp
and
how
do
you
bootstrap
the
whole
thing?
H
How
do
you
boot
that
so
there's
some
discussion
about
acp
connect?
How
you
may
built
that
in
that
scenario,
particularly
when
you
start
with
just
deploying
a
a
registrar
into
a
knock
that
has
nothing
else:
okay,
so
synchronous,
a
sacred
issues
that
I
talked
about
incremental
deployment
of
acp
okay.
So
there's
a
lot
of
references
into
the
acp
document
about
you
know
you
want
to
use
one
of
these.
You
want
to
use
one
of
these.
This
is
when
you
use
it.
This
is
how
you
use
it.
Okay,
knots
not
normative
device.
H
You
don't
have
to
do
it
this
way,
but
it
is
intended
to
be
prescriptive
and
that
that
this
is
a
way
to
do
it.
A
I
was
just
thinking
that
the
things
you
explained,
I'm
not
sure
if
everybody
would
think
they're
just
within
the
scope
of
operations
versus
development
and
engineering,
but
you
know
that
might
just
be
terminology
right.
H
So
so,
partly
the
goal
here
is
that
if
someone
is
an
enterprise
is
trying
to
deploy
an
acp
and
they
go
to
some
developer
of
registrars,
they
may
like
to
have
some
terminology
that
describes
how
it
is
they
want
to
have
it
run.
H
So
they
would
say
I
want
it
like
.4,
okay
of
this
document,
and
I
don't
find
point
three
compelling
because
I'm
not
a
whatever
okay.
H
So
the
the
second
document
deals
with
operational
considerations
for
the
nasa,
and
so
this
is
about
the
manufacturer,
building
the
new
device
and
he
has
to
put
a
private
key
in
there
and
he
has
to
put
a
certificate
that
corresponds
to
the
private
key,
which
is
signed
by
a
pki
that
they
operate.
So
he
has
to
learn
how
to
sign
an
offer,
a
pki.
H
These
documents,
I
think
in
large
part,
came
about
because
I
had
people
said.
Oh
manufacturers
will
never
do
this.
This
is
too
hard.
No
one
knows
how
to
do
this
and
I
said
well,
no,
actually,
it's
been
done
by
quite
a
few
manufacturers
and
the
intent
was
to
collect
some
of
that
experience
such
that
other
manufacturers
who
think
it's
too
hard
would
be
convinced.
No,
it's
not
so
hard,
or
in
some
cases
they
didn't
even
know
they
were
doing
it
already
right.
H
So
you
can
see
a
little
anchor
built
in
the
dock
there,
and
particularly
it
needs
to
be
able
to
validate
the
voucher
okay,
so
they
have
to
put
us
a
voucher,
signing
a
voucher
verification
key
to
the
new
device,
but
you
also
probably
also
need
other
trust
anchors,
like
a
software
update,
trust
anchor
as
well,
and
all
of
this,
the
voucher
side
of
things
also
applies
to
rfc
8572,
which
is
the
secure
zero
touch
protocol
that
from
netconf,
which
uses
the
same
voucher
protocol.
H
So
this
is
common
between
brewski
and
sctp.
H
So,
as
I
said,
they
have
to
install
trust
anchors,
a
public
key
into
the
device
and,
if
they're,
installing
a
public
key
into
the
device,
the
manufacturer
then
has
to
deal
with
the
question
of
how
do
they
secure
the
private
key.
Initially
I
was
thinking
about
well
the
voucher
signing
key.
They
have
to
keep
that
because
if
they
lose
that
or
disclose
it,
then
they've
the
security
of
all
the
devices
has
been
compromised
or
but
possibly
they
need
to
recall
them
all
to
replace
the
trust
anchor.
H
So
that's
a
big
deal,
so
that's
that's
discussed
and
the
other
document
idea
of
considerations
talks
a
little
a
lot
more
about
that
problem,
so
putting
the
key
in
there
so
changes
since
107
massive
considerations.
Most
of
it
was
gutted
moved
into
the
other
document.
There's
been
a
slight
change
of
authors
and
it
needs
to
be
rewritten
to
leverage
the
idf
id
considerations
document.
H
If
that
document
will
go
forward
because
it
needs
to
simply
say:
do
it
like
this
or
do
it
like
this,
or
do
it
like
this
for
appropriate
things,
registrar
considerations,
I
use
the
word
certificate
authority,
which
turns
out
to
be
wrong
change
of
authors.
There
hasn't
been
a
lot
other
comments
about
it,
not
since
itf
107.
Anyway.
I
think
we
had
a
fair
bit
of
discussion
about
the
documents
in
the
december
to
march
time.
A
A
Three
three
times
through
it,
maybe
one
one.
G
H
Mean
anima
could
consider
adopting
it,
but
I
don't
think
it
belongs.
I'd
have
considerations
does
not
belong,
but
it
does
need
a
home
yeah.
Is
that
and
you're
still
looking
for
a
home
in
terms
of
do
you
need
to
well
sex
dispatch
ruled
this
morning
and
there's
some
ongoing
discussion,
so
I
think
it
will
find
a
home
at
this
point.
A
Okay,
yeah,
I
mean
if,
if,
if
you
want
to
take
the
time,
maybe
we
can
ask
again
who
has
well?
Shall
we
do
it
separately?
Read
the
the
first
draft,
the
registrar
considerations,
if
you
can
step
to
the
mic.
A
A
A
Yep
well
for
for
all
the
rest,
please
check
it
out
and
let's
take
the
discussion
to
the
list
and
yeah
and
I'll
also
put
it
on
my
to-do
list.
A
Okay,
do
you
want
to
take
the
last
few
minutes
for
does
anybody
else
have
something
you
know
for
the
open
mic
or
as
always,
we
we
have
the
overflow
presentation
from
michael
about
the
l2
acp,
but
if
anybody
else
has
some
urgent
matter
here
to
speak
up,
then
do
it
now
maybe
elliot.
A
I
Hey
so
I
just
had
one
point
I
want
to
raise
that
I
see
as
being
something
that
we
people
should
be
thinking
about
with
all
of
this,
which
is
something
that
came
up
in
the
last
call
for
brewski.
I
I
do
think
it's
worth
giving
a
bit
more
consideration
to
how
ownership
transfer
happens
over
time.
That's
something
that
we
have
some
words
in
the
brewski
document
that
sort
of
hedge
on
that
point,
but
I
think
it's
an
area
where
it's
worth
more
exploration,
whether
that's
in
a
research
forum
or
this
forum-
I
don't
know,
but
it's
an
area.
A
H
H
We
didn't-
I
didn't
bring
the
delegated
voucher
document
back
here,
because
I
was
insured
by
the
chairs
that
they
would
have
an
adoption
call
on
it
without
further
time,
and
I
think
that
that
within
that
document
is
some
of
the
discussion
about
about
about
transfer
of
ownership,
because
I
think
that,
fundamentally,
if
you
can
sell
some
resell
something,
then
you
probably
did
own
it.
In
the
first
place,.
A
Yeah
I
was
implying
into
what
elliot
was
saying.
Also
things
like
you
resell
things.
You
know
so
secondary
ownership
transfers,
not
the
initial
ones
that
we're,
I
think,
focusing
primarily
on
right
now.
I
think.
J
I
just
wanted
to
make
a
comment
on
a
sort
of
different
subject.
What
I
can
is
warren-
and
I
are
thinking
about
setting
up
an
ops,
iot
working
group
under
ops
area
and
that
would
probably
focus
mainly
on
maybe
moving
the
mud
work
there
and
potentially
also
onboarding.
J
So
this
is
something
that
probably
will
send
an
email
out
and
try
and
get
feedback
as
to
whether
people
think
that's
a
good
idea
or
not,
but
I
just
wanted
to
raise
that,
potentially
in
the
context
of
some
of
the
discussions
about
where
some
of
this
work
belongs.
J
A
Yeah-
and
you
know
five
minutes.
H
A
Half
of
the
hour,
you'll
we'll
all
be
killed
here.
So
take
your
time.
H
We
have
until
8
40,
I
think
oh
crap.
Yes,
I
want
to
share
my
screen.
H
I
don't
know
why
the
title
says
that
that's
really
bizarre,
okay,
so
at
the
last
itf
we
brought
for
a
document
about
ipv6
over
link
level
discovery
protocol,
and
I
guess
I
adapted
the
document
slides.
I
should
change
the
title
again.
So
that's
wrong.
I've
renamed
the
document
to
l2,
friendly
acp
and
I'll
just
get
to
that.
So
the
history.
H
The
background
is
that
you
have
some
campus
network,
for
instance,
that
you
want
to
boot
up
in
an
acp
and
you
can't
actually
operate
the
network
very
well
until
you
have
the
sdn
controller
connected
because
there
are
loops
and
because
the
network
is
designed
not
necessarily
to
work
with
sdp.
H
So
you
can't
just
put
it
as
a
flat
layer
to
network
because
you'll
have
loops
until
you
get
some
control,
and
so
you
need
the
sdn
up.
But
you
need
to
get
the
sdn
up.
You
need
the
acp
and
to
get
the
ecp
up.
You
need
the
yeah.
You
need
a
circle
of
bootstrapping,
so
we
had
proposed
what
if
we
do,
this
run
an
acp
over
lldp
and
we
had
a
bunch
of
conversations
about
this.
H
Many
found
it
gross
and
finally,
we
found
that
actually,
even
though
we
probably
could
make
it
all
work
in
the
gross
way
that
it
didn't
actually
solve
the
problem
that
we
wanted,
because
what
we
were
trying
to
avoid
was
additional
configuration
of
the
switching
fabric
and
it
would
still
require
additional
configuration
switching
fabric
and
the
bandwidth
would
be
in
the
order
of
packets
per
second
as
well.
So,
let's
not
do
that.
So
we
stepped
back
and
said
what
is
the
problem?
What
is
it
we
want
to
do?
Well,
we
want
ipv6
packets.
H
We
want
them
to
be
transferred
in
a
in
a
way
that
is
distinct
from
the
normal
unicast
ether
type
of
86
dd,
and
we
want
them
never
to
be
forwarded
by
a
layer,
two
device.
Okay,
so
we
want
them
on
the
local
wire,
only
oh,
that's
it,
and
when
we
receive
them,
we
want
to
know
which
port
they
arrived
on
and
when
we
send
them,
we
want
to
be
able
to
send
them
just
on
the
port
on
a
particular
port
and
not
on
every
port.
That
happens
to
be
part
of
an
l2
domain.
H
H
If
so,
then
this
is
a
bit
of
an
ipv6
over
food
document,
and
so
we
have
some
requirements
for
this
at
this
point
and
if
we
do,
then
we
think
we
should
bring
this
to
the
ietf
ieee
coordination
committee
and
ask
for
the
advice-
and
you
know
maybe
the
document
wind
up
with
six
man
with
anima
being
the
setting
the
requirements.
A
I
so
thank
you
very
much
I
I
didn't
quite
so
I
I
understood
the
things
that
you
wanted
to
to
to
do
from
the
list,
but
why
I
mean
the
why.
H
Why
is
that
the?
Why
is
that?
If
we
turn
on
the
network-
and
we
try
to
form
a
flat
layer,
two
okay,
that
the
network
will
have
ethernet
loops,
because
there's
no
spanning
tree
necessarily
turned
on
in
this
network,
because
spanning
trees
not
necessarily
desired
in
this
network?
Rather
they
want
to
have
multi-path
networks
with
sdn
dealing
with
what
the
topology
of
the
network
really
is,
so
the
sdn
controllers
would
essentially
control
well.
Is
it
going
to
be
equal
cost
multipath?
H
A
So
you
say
I
I
think,
let
me
try
to
restate
you're
saying
I
want
to
build
an
acp
on
layer,
two
switches,
and
the
problem
is
that
a
lot
of
the
ports
may
not
be
usable
because
spanning
tree
has
disabled
them.
H
We
get
broadcast
storms
throughout
the
network,
particularly
when
you
first
turn
it
on.
There
would
be
no.
There
would
be
no
policy
set
up
at
that
all,
but
but
your
your
point
you
the
way
you
said
it
is
also
true.
I
would
like
to
run
acp
over
ports
and
that
might
be
disabled
because
of
spanning
tree
turning
them
off.
So
I
did
turn
on
spanning
tree,
and
the
problem
is
that
I
want
to
run
the
acp
over
ports
that
possibly
would
be
turned
off
so
so
I
don't
really
want
to
have
spanning
tree.
H
H
A
I
guess
there
I
would
first
come
up
with
a
couple
of
questions
to
give
to
l2
experts
right
so,
for
example,
as
I
I
think
we
had
an
email,
I
I'm
not
sure
what
happens
with
switches
that
are
not
by
default
using
spanning
tree.
I
think
the
ones
that
are
using
by
default
spanning
tree
like
the
enterprise
switches,
I
know
they
they
would
come
up
and
automatically
bring
up
ports.
Only
if
spanning
tree
is
happy
with
it.
That's
the
default
behavior
to
avoid
loops
by
default.
A
H
So
I'll
tell
you
what
happens
if
you
take
two
prosumer
switches
on
managed
switches
that
you
find
in
small
enterprises
and
you
plug
them
with
two
cables
between
them.
The
answer
is:
all
the
lights
go
on
and
they
melt
down.
H
A
Whether
those
would
ever
be
capable
to
to
do
something
like
an
acp
or
anything
close
to
it,
because
I
think
most
of
them
we
weren't
even
able
to
get
something
like
simple,
open
wrt
on
them
right.
So
it's
well.
H
A
A
Yeah
gotcha,
okay
cool
well,
we've
got
still
has.
Has
anybody
read
the
the
document
or
russ?
I
think,
has
a
question
sure
go
ahead.
F
Hi,
michael
there's
a
conversation
already
going
on
in
the
ietfi
802
coordination
space
regarding
lldp
version,
two:
okay,
because
the
ieee
2.1
is
working
on
some
updates
to
that.
So
the
timing
may
be
really
good
to
get
your
requirements
heard.
F
So
I
suggest
you,
you
formulate
your
question.
Okay
and
I'll
I'll
be
glad
to
facilitate
the
discussion.
H
A
All
right,
no
closing
slides
from
the
chairs,
so
I
guess
we'll
all
see
ourselves
in
video
or
not
in
bangkok,
virtually
and
otherwise.
We'll
have
the
ais
for
for
the
list.
Please
read
more
docs
and
comment
on
them
on
the
list
and
thank
you
very.
C
J
Yeah
the
formal
decision,
it
will
happen
at
the
end
of
august.
I
think
that's
all
right
so
now
right,
but
it's
a
two-stage
process,
so
that
that
would
be
whether
the
llc
thinks
the
meeting
could
go
ahead.
Even
with
that,
I
think
the
ict
would
also
have
to
evaluate
whether
they
thought
there'd
be
enough
attendees
to
make
an
imp
meeting
viable.
So
there
was
also
probably
an
indication
given
in
that
plenary
that
it
seemed
to
me
that
it
was
more
likely
to
be
an
online
meeting
than
in
in-person
meeting.
A
Hey
rob
the
thank
you
very
much
for
for
the
minutes.
That's
that's
as
good
minutes
as
I've
ever
seen.
So
you're
hired.
Sorry.
If
you
need
to
give
up
that
other.
K
A
L
Sorry
this
is
andre
bondi,
I'm
I'm
a
performance
specialist.
I've
been
looking
at
these.
These
call
flows
with
interest,
I'm
wondering
if
any
consideration
is
given
to
the
amount
of
time
spent
in
each
of
the
stages
and
how
much
can
be
parallelized
and
so
on.
Is
that
a
consideration
when
you're
putting
these
things
together?
I
haven't
really
heard
much
mentioned
about
that
in
any
of
the
meetings.
A
No-
and
I
think
the
only
place
where
I
think
you
you
might
want
to
chime
in-
is
to
michael's
operational
consideration
where
he
was
mentioning
parallelization
right
so,
and
I've
also
seen
these
cloud
native
type
of
deployments
with
highly
parallelization,
where
you
need
to
look
at
throughput
and
latency
and
so
on.
So
maybe
you
want
to
look
at
those
operational
consideration
documents
or
directly
contact
michael
or
take
it
to
the
list.
L
Michael
all,
right,
right,
okay,
sure,
yeah,
sure,
okay,
and
that
that
all
of
that
is
going
to
be
in
the
in
the
in
the
rfc's
that
that
were
downloadable
from
this
side,
then.
A
That
that
are
here
in
the
last
official
slot,
these
the
considerations,
ones
the
two
animal
consideration
ones.
A
Hey
rob
I
didn't
thank
you.
I
didn't
quite
get
the
the
form
of
what
you
said
with
the
mobs
and
the
enrollment
and
so
on.
What
was
that?
What
what
type
of
is
that
a
working
group
or
a
forum
or
what
sorry.
J
What
was
the
plan
iot
ops,
it
would
be.
A
working
group
in
the
ops
area
is
what
we
are
considering
effectively
and
part
of
that
is
to
potentially
move
some
of
the
mud
work
out
of
ops
awg.
It's
not
necessarily
fitting
in
there
that
well,
but,
but
it
also
would
potentially
tighten
the
onboarding
stuff
into
there
as
well.
It
was
what
we're
thinking
of,
but
it's
still
early
stages.
J
We've
raised
the
idea
with
the
isg,
I
think
they're
broadly
supportive,
but
we
still
need
further
planning
to
work
out
what
that
would
look
like
okay.
Another
thought
was
the
reason
for
doing
this,
and
your
question
as
to
what
is
iot
is,
it
seems
potentially
helpful
externally.
If
people
look
at
itf
can
see
if
there's
a
place
where
iot
work
is
happening
in
its
more
obviously
by
just
looking
for
the
word
iot,
where,
obviously
it
does
a
lot
of
iot
stuff,
but
it's
not
necessarily
easy
to
find.
Having
something.
J
A
Had
some
discussion
with
that,
when,
with
with
ignas
in
before
you
joined
yeah,
the
isg
okay,.