►
From YouTube: IETF112-ANIMA-20211110-1600
Description
ANIMA meeting session at IETF112
2021/11/10 1600
https://datatracker.ietf.org/meeting/112/proceedings/
B
In
the
right
room,
this
is
the
animal
working
group
and
we're
at
itf
112.
B
So
let's
get
started,
itf
notewell,
I
hope
you're
all
aware
of
this
everything
you're
saying
here
public
and
there
was
actually
another
slide.
I
should
have
added,
but
I
couldn't
find
a
good
template.
You
know
please
expose
good
behavior.
There
is
the
you
know,
rules
of
conduct.
You
know
that
everybody
should
be
aware
of.
I
think
we'll
may
want
to
resend
that
to
the
mailing
list
as
well.
B
Logistics
shang-
and
I
you
see
the
videos
where
the
chairs,
if
you're
presenting
or
when
you're
presenting,
feel
free
to
also
use
the
video
there
is
no
need
for
it,
but
it's
always
nice
to
see
each
other's
faces.
The
minute
taking
is
really
the
most
important
thing
here.
On
the
slide,
I've
seen
working
group
chairs
that
let
their
working
groups
sit
around
for
10
minutes
not
doing
anything
until
somebody
who
was
willing
to
take
notes
was
standing
up.
So
do
we
have
volunteers
here.
B
B
I
volunteer
oh
excellent.
Thank
you
very
much.
All
right
all
right
moves
us
on
the
slide,
thanks
right,
early
ipr
disclosure
process.
Just
as
a
reminder
we
are
asking
for
ipr
disclosure,
also
when
adopting
a
document
to
the
working
group,
not
only
when
it
is
in
last
call
to
avoid
you
know,
problems
other
working
groups
had
in
the
past.
You
know
with
late
disclosures
from
from
authors.
B
All
right
marketing
it's
this
time
of
year
again
we've
got
the
long
comm
period,
which
has
finishing
feedback
by
november
23rd.
B
So
if
you
have
feedback
about
any
of
the
people
running
for
the
various
area,
director,
iab
and
and
other
leadership
positions,
please
provide
feedback
to
nom-com
in
email
and
of
course,
any
type
of
general
feedback
can
also
be
given
through
the
same
tool
that
you
know
is
is
on
the
nomcom
webpage,
the
url
you
see
here,
and
you
know
about
anything
you
don't
like
in
the
ietf
in
the
general
section
or
of
course
kudos
are
you
know
taken
as
well,
and
obviously
this
was
brought
to
you
because
I
happen
to
be
randomly
choosing
to
be
on
amcom
this
time,
so
right,
more
marketing.
B
So
this
is
marketing
for
anima
that
we
did
so
a
bunch
of
the
authors
of
the
phase
one
anima
rfcs
got
together
and
then,
after
you
know,
recycling
the
stuff
for
for
for
several
times,
we
got
it
into
the
internet
protocol
journal
of
october
2021
17
pages
of
what
we
hope
and
what
I
do
think
is
a
really
great.
B
You
know
overview
of
enema
and
what
can
be
done
it
really
from
the
perspective
of
selling
it
to
operators,
users
and
developers,
including
examples
of
asa,
and
so
things
where
we
would
like
to
have
future
work
being
brought
into
enema.
So,
please,
you
know,
take
a
look
at
it
and
when
you
always
had
it,
people
who
didn't
know
what
anima
was.
I
think
this
is
probably
the
best
that
you
can
point
them
to
to
explain
it
to
them.
B
All
right
and
yeah
we've
got
rfcs
now,
and
that
also
means
that
we
likely
should
have
and
will
get
and
do
have
erratas
and
I
think
that's
a
part
of
the
itf
process
that
people
are
often
missing.
So,
especially
when
you're
an
implementer
or
you're
reading
rsc
trying
to
catch
up.
B
B
Please
simply
go
to
that
errata
page
and
file
in
errata
and
then
basically
go
through
the
process
of
review
and
so
yeah
we've
got
three
of
our
rc's
with
erratas,
and
so
that's,
I
think,
also
a
good
show
of
you
know
the
errata's
getting
read
and
or
being
implemented
against
right
so
which
brings
us
to
actual
work.
B
So
the
working
group
documents
the
asa
guidelines.
That
document
was
up
for
quite
a
while,
and
so
we
had
it
passed
through
working
group.
Ask
all
before
itf
112
without
further
negative
comments
and
the
shepherd
pushed
it
through.
And
then
we
got
all
the
ipr
disclosures,
and
so
I
requested
the
publication
to
isg
today.
So
one
thing
to
go
into
robert's
queue
first
and
then,
of
course,
to
itf
and
isg
for
the
brewski
cloud.
We
don't
have
a
slot
today.
B
The
authors
incorporated
the
ietf
111
feedback
and
added
security
considerations,
so
they
think
it's
ready
for
working
group
last
call.
So
we
would
probably
we're
going
to
do
a
working
group
last
call
after
this
ietf.
B
So
then
the
nmr
constrained
joint
proxy,
so
yeah
we
need
a
shepherd
write
up.
Working
group
last
call
finished.
That
was
including
an
early
iot
directorate
review.
So
we
already
got
some
very
good
feedback
from
that
on.
The
latest
version.
05
should
resolve
all
the
issues
and
I
think
we'll
learn
more
in
the
slot
about
it.
B
Will
be
talked
about
by
the
authors,
there
is
a
draft
being
split
out
from
that,
and
so
this
time
we
not
sure
if,
if
how
many
here
are
remembering
similar
discussions,
we
had
when
we
started
enema
at
which
point
in
time
what
kind
of
struck,
by
not
restructuring
documents
and,
let's
say
changing
140
page
long
documents
into
more
smaller
ones.
So
this
time
we
had
good
experience
reference
from
other
working
groups
that
that
process
is
painless
and
can
be
done
without
going
further
back
to
the
working
group.
B
So
I
was
talking
specifically
with
russ
housley
who's.
The
working
group,
chair
of
lamps
and
they've
done
exactly
that,
structuring
into
smaller,
more
manageable
documents
as
well
and
as
long
as
those
documents
stay
within
the
scope
that
was
agreed
by
the
working
group
for
the
larger
document.
Then
this
is
simply
something
that
the
working
group
chairs
can
agree
on
with
the
authors,
so
draft
animal
constraint,
voucher
we've
got
a
slot
jws
voucher.
We've
got
no
updates
on
grass
distribution
and
animal
voucher
delegation.
A
Yeah,
it
seems
there
are
very
long
delay
well
two
seconds,
however,
an
author
of
the
grass
distribution.
Actually,
we
believe
we
have
asked
the
working
group
lascaux
from
last
meeting.
A
B
Okay,
so
I'm
overloaded
right
now,
so,
let's,
let's
take
that
to
email,
so
just
just
make
sure
that
we're
not
losing
it.
I
wanted
to
to
take
it
to
the
notes
here,
but
I
see
that
michael
also
didn't
catch.
I
think
what
what
you
were
saying
so,
maybe
if
you
can
simply
add
it
to
the
notes
so
that
we
it
was.
B
B
Now,
for
all
the
documents
that
we're
working
on,
we
really
need
more
document
reviews
and
so
would
really
be
good.
First
of
all
to
make
sure
that
the
reviews
are
tracked
in
the
acknowledgement
sections
with
all
the
names
that
had
been
done,
the
more
detailed
that
is
the
more
it
helps
at
the
working
group.
B
Last
call
and
iesg
review
later
on,
and
you
know
don't
don't
wait
for
reviews
in
the
last
call,
but
re
reach
out
to
other
authors
of
other
documents
in
the
vicinity
in
in
anima
to
ask
them
for
review.
If,
if
you
have
trouble
getting
getting
more
reviews
by
yourself
to
reaching
out
to
other
working
group
participants,
please
reach
out
to
the
chairs
and
and
we'll
discuss
it
with
you.
B
There
is
also
a
formal
part
of
the
process
for
early
reviews
from
other
things,
like
we've
done
with
iot
directorate
review,
which
you
know
could
have
been
done
before
working
group
last
call
as
well.
There
is
review
from
a
bunch
of
different
formal
languages,
like
especially
young
doctors,
and
also
areas
like
early
security
review.
B
So
all
of
these
reviews
should
as
much
as
possible
be
done
before
we
pass
the
document
on
to
to
the
isg
review,
because
the
better
it
gets
out
of
the
working
group,
the
better
the
working
group
also
you
know,
is
perceived
to
have
operated.
B
Please
contact
us
all
right,
which
basically
gets
exactly
to
the
point,
if
you're
on
the
receiving
end
of
this
request
and-
and
you
should
be
on
the
receiving
end,
if
you're
an
author,
because
you
want
others
to
review
your
documents,
so
you
need
to
reviews
other
people's
document
and
the
best
way
to
do
that
in
a
focused
fashion
is
shepherding
so
become
shepherds
for
some
other
author's
document.
It's
it's
really
about
reciprocity,
and
it's
been
one
of
the
old
principles
of
you
know
the
way
the
iatf
works.
B
It's
one
of
the
pieces
that
hasn't
really
been
written
down.
Well,
so
it's
not
well
formalized,
but
the
ietf
doesn't
really
work
as
at
all
without
this.
So,
let's,
let's
see,
if
we
can,
you
know,
get
shepherds
up.
So
you
you
see
the
you
know
the
documents
we're
talking
about
and
I
think
each
of
the
author
can
mention
if,
if
if
they
have
a
shepherd
or
not-
and
so
if
you
know
you
want
to
step
forward,
become
shepherd
for
one
of
the
documents,
please
do
so
on
the
mic
line.
B
Otherwise
we're
going
to
take
it,
of
course,
also
after
the
meeting
to
to
the
mailing
list
here,
here's
the
list
of
the
document
that
that
we
currently
have
in
the
working
group
that
are
needing
shepherds.
So
you
know,
if
you're
author
of
one
of
them
and
not
one
of
the
others,
please
you
know
really
strongly
consider
now
to
become
a
shepherd
for
it.
Otherwise,
I'm
be
sure,
I'm
going
to
ask
you
in
email
afterwards.
B
Okay,
then,
of
course
also
do
we
never
have
enough
time
for
technical
discussions,
and
it's
all
you
know
a
death
by
powerpoint.
The
itf
has
a
lot
of
processes
and
I
think
we're
learning
that
many
of
them
do
help
us
to
do
the
job
better
and
doing
that.
You
know
for
two
hours
three
times
a
year.
Isn't
really
that
bad.
But
of
course
it's
not
enough
to
do
all
the
technical
work.
B
So
please,
when
you
see
that
the
work
on
documents
can
be
done
better,
you
know
start
to
become
active
as
well
with
the
help
of
the
working
group
chairs.
Of
course,
as
always,
you
know
try
to
do
something
like
a
design
team.
Just
a
two,
weekly
or
monthly
meeting
on
you
know
you
can
use
the
webex
from
from
anima.
B
Right
and
the
best
example,
of
course,
is
the
brewski
design
team,
which
has
been
focusing
on
a
good
subset
of
the
active
working
group
documents
for
brewski
that
we
have
here.
The
time
had
changed
and
it's
been
going
on
very
actively.
So
if
you're
interested
in
the
brewski
aspects
or
so
this,
this
is
basically
the
starting
point
where
you
want
to
go
to.
B
Of
course,
we
also
have
a
github,
that's
not
an
official
github,
but
if
you
it's
not
limited
to
working
group
documents,
so
any
document
you're
writing
for
nmr
feel
free
to
you
know
put
that
into
that
repository
if
you're,
not
on
the
repository,
we'll
be
happy
to
invite
you
to
it
and
that's
it.
I
haven't
put
the
agenda
here
because
kind
of
duplicating
the
stuff
the
agenda
between
all
the
different
places.
So
please
go
to
the
notes
pages.
B
The
agenda
is
there,
so
the
first
speaker,
I
think,
should
be
michael
for
the
post
working
group
last
call
constrain
join
proxy
for
bootstrapping
protocols.
Michael
it's
all
yours.
D
We
had
a
working
group
last
call
in
october.
We
received
a
number
of
comments
from
that
and
just
to
remind
you,
this
is
about
having
a
stateless
proxy
for
dtls.
D
That
means
that
you
don't
need
to
use
memory
for
each
connection
that
you
receive
and
it
replaces
a
stateful
proxy
which
is
in
brewski
there.
So
working
group
call
ended.
A
working
group
last
call
ended
october
14th.
We
got
reviews
by
esco,
russell
and
brian
carpenter,
and
a
new
revision
was
posted
a
couple
weeks
so
ago.
D
Just
I
think,
on
the
deadline,
and
mostly
we
did
some
restructuring
of
the
some
of
the
introduction
to
make
some
of
the
pieces
clear
and
a
little
bit
of
nits
and
that's
about
it.
D
There
wasn't
really
any
significant
technical
concern,
although
esco
did
raid
some
issues
that
I
think
peter
and
I
said
we're
not
we're
not
going
to
solve
that
those
issues
and
that
was
marked
as
such,
and
that's
really
really
that's
really
it
so
peter
has
implementations
of
of
all
of
these
pieces,
and
I
think
so
does
esco
have
some
pieces
as
well
implemented.
D
We
did
yes,
we
did
address
the
comments
from
from
from
the
iot
director
review.
A
D
D
D
D
D
I
just
I'm
just
gonna
get
it
on
my
screen
before
I
share
it.
There
we
go
window
boom
click,
okay,
better!
Here
we
are
yes
there.
We
are
so
just
to
remind
you.
There
is
also
a
bunch
of
there's
now
a
brewski.org
and
there's
a
bunch
of
implementation
stuff-
and
I
mentioned
this
last
time,
but
I'm
just
going
to
mention
this
again
anyway,
just
for
the
hell
of
it.
So
essentially,
these
are
the
changes
that
we've
done
in
the
constrained
voucher
documents.
D
D
Unfortunately,
so
essentially,
what
we
we've
done
is
the
major
things
is
that
one
of
the
things
is
this
updates,
so
as
you,
if
you're
familiar
with
the
whole
debate
as
to
what
is
the,
what
does
the
updates
word
even
mean,
and
so
we
both
amend
rfc
8
995,
and
we
extend
eight
nine
nine
five
and
we
extend
eight
three
six
six.
So
that
is
explained
in
that
section,
and
then
we
have
a
bunch
of
little
changes
to
the
protocol,
a
lot
of
additional
pieces.
D
We
discovered
some
problems
with
the
sid
values,
some
duplications
in
the
previous
draft,
that's
an
oops
and
relates
to
the
renaming
that
we
did
and
we
fixed
that
recently
and
it
may
not
be
in
the
last
version,
but
it's
it
is
fixed
now.
One
of
the
things
that
we
were
worried
about
is
what
to
do.
If
the
yang
seaboard
documents
that
we
depend
upon
did
not
advance
because
they've
been
stuck
in
an
isg
review
since
junish.
D
So
that's
part
of
this,
so
I
went
and
looked
at
that
document
and
the
issues
and
I
tried
to
re
boot-
the
effort
to
get
it
through,
since,
if
that
document
doesn't
go
through,
then
our
document
would
not
go
through
and
at
the
same
time,
what
we
also
did
is
we
said
to
ourselves.
Well,
what
would
we
need
to
do
to
make
the
references
to
it
not
normative,
but
rather
informative,
and
so
we
have
a
pull
request
doing
that
that
we
have
are
not
have
not
yet
at
this
point
merged.
D
So
we're
basically
hedging
our
bets
here
as
to
whether
or
not
this
document
will
advance.
D
I
I
went
over
to
the
the
core
working
group
read
the
comments,
turned
those
comments
into
issues
and
we
seemed
to
have
a
somewhat
of
a
design
team
to
fix
the
issues
finished
and
so
34
of
those
issues
are
now
closed
and
it
looks
like
we
could
just
continue
on
the
way
we
were
intending
depending
on
those
documents
to
see
what's
happening
and
I
swear.
I
changed
the
footer
on
this
thing
about
the
hackathon,
so
we
we
did,
we
were
did
have
some
conversations
last
week.
D
We
didn't,
I
at
least
didn't
have
any
packets
flowing
or
testing.
We
did
several
us
get
the
the
ietf
hackathon
l2vpn
working
and
that
lets
us
test
the
joint
proxy
across
the
the
network
and
I'll
finally
mention
that
there
is
an
iot
onboarding
thing
that
is
finally
active
from
the
from
the
nist
and
the
nccoe,
and
that's
something
we
discussed
last
time
as
well.
D
So
there's
a
document
that
will
tell
you
if
you,
if
you
want
to
bring
your
product
to
to
there,
to
have
them
play
with
it,
then
you
can
go
through
a
letter
of
intent
with
that
process.
So
that's
another
kind
of
interrupt
stuff,
that's
happening,
and
that's
really
quite.
F
It
yeah
getting
back
to
the
hackathon.
You
mentioned,
not
really
any
participation.
Well,
at
least
I
was
there
doing
something.
So,
yes,
I.
F
Well,
not
much,
but
my
client
interacted
with
your
server:
no,
not
your
server
with
your
certificate.
So
maybe
I
can
just
briefly
show
that
I
think
that
was
also
intended
yeah.
So
you
do.
F
D
Yeah
so
so
esco
did
report
a
bug
to
me,
a
big
one
in
the
form
of
my
certificates,
and
I
haven't
been
able
to
fix
it
yet
because
I
just
haven't
had
a
focus
cycle
to
do
that.
So
what
do
you.
F
Have
here
yeah
what
I
have,
what
I'm
showing
is
the
constrained
pledge.
So
this
is
a
usb
stick
format
that
I
use
just
to
show
context.
So
it's
a
really
small
device
with
a
15.4
radio
on
it,
but
this
was
not
the
one
we
used.
I
used
last
week
during
the
hackathon,
so
click
that
away
so
for
the
hackathon
I
actually
had.
F
Maybe
just
show
it
here,
yeah,
it's
basically
command
line
java
program
that
that
looks
like
this.
F
So
you
start
it
up
and
yeah.
F
E
F
Yeah
you
can
see
here,
so
what
was
done
is
I
also
improved
this
diagnostic
messaging
so
that
it
will
the
client
will
actually
display
the
diagnostic
from
the
server.
So
this
is
my
my
own
registrar
server
in
this
case,
and
the
reason
of
the
error
is
that
the
yeah,
the
client
was
using
michael's
certificate.
So
I
I
downloaded
that
from
yeah,
basically
his
website,
so
we'll
just
check
they're.
D
Wrong
they
have,
they
don't
have
the
authorized
key
in
the
thing
they
have
a
subject,
key
indicator
and.
E
D
Couldn't
build
the
idef
id,
and
so
that's
my
that's
my
bad
and
of
course
you
know
if
we
don't
interrupt,
we
don't
discover
these
problems
because
I
didn't
do
anything
with
that
code.
F
Yeah,
so
you
can
see
this
is
the
lucky
dump
of
the
certificate.
So
you
see
the
subject
key
identifier
in
there
and
it
should
be
there
the
authority
key
identifier.
So
that's
the
thing
it's
complaining
about,
and
this
is
actually
the
first
time
I
tried
my
client
with
your
certificate.
So
that's
the
step
I
did
and
for
the
rest
I
also
did
not
have
much
time
similar
to
michael
last
week.
So
that's
about
it,
but
it's
progress
anyway.
B
F
Yeah,
I
think
that
in
this
java
pledge
it
will
just
use
ipv4
or
six
whatever
is
available
to
the
server.
I
think
it
actually
should
resolve
to
ipv6.
To
be
honest,
so
I'm
not
sure
whether
you
see
ipv4.
F
Okay,
you
mean
this
yep
one
of
the
problems.
D
That
several
people
have
is
they're
using
docker
containers
just
deployed
in
under
aws
and
so
they're,
reachable
by
v6,
but
because
of
docker.
They
don't
have
v6
inside
the
container
yeah,
and
so
they
can't
go
out
and
that's
a
major
limitation
with
ec2
containers.
And
I
don't
know
if
anyone
solved
it.
But.
F
Why
it's
using
v4,
because
I
actually
put
the
yeah
the
dns
to
only
give
back,
v6
adders,
I
think
normally,
but
okay,
that
may
be
good
to
check
and
the
the
constrained
one
only
uses
ipv6.
B
We're
10
20
yeah,
we're
10
minutes
behind.
I
think
that's
where
reaching
our
wiggle
room,
so
stefan
status
of
brewski
ae
and
derived
work
please
and
there
he
goes
right
right.
H
Okay,
perfect
so
as.
H
H
So
we
thought
it's
better
to
to
have
a
split
of
the
draft
that
has
a
functionality
contained
and
be
easier
able
to
declare
conformance
to
a
specific
functionality
so
use
case,
one
stays
as
what
was
described
as
support
for
other
kronos
enrollment
in
brewski,
and
it
basically
relates
to
the
using
an
alternative,
enrollment
protocol
other
than
the
est
simple
enroll
that
is
specified
in
brewski.
H
So
we
are
concentrating
there
on
lightweight
cmp
usage
specifically,
and
the
focus
is
placed
on
the
interaction
between
the
pledge
on
one
hand
and
the
register
on
the
other
side
because
from
the
register
to
the
back
end,
it's
also
a
matter
of
deployment.
What
type
of
enrollment
protocol
is
used
there?
H
So
that
was
the
case
where
we
introduced
the
register
register
agent
to
facilitate
the
communication
between
the
two
so
just
to
go
through
through
both
of
the
current
drafts.
So
both
drafts
are
available
in
the
repository
and
for
both
drafts.
We
also
have
a
github
on
the
anima
working
group
kit,
so
the
status
of
risky
ae
so
from
version
02
to
version
3.
H
We
did
some
housekeeping
addressed
some
of
the
open
issues
for
the
voucher
young
for
the
young
of
the
voucher
request
and
included
some
further
open
issues
regarding
the
usage
of
the
young
models
for
getting
the
agent
proximity
into
the
voucher
request.
So
that
was
related
to
use
case
two
and
the
csr
encapsulation.
H
We
used
the
the
ztp
ssdp
sub
module
for
that,
and
that
was
included
also
as
as
an
open
issue
in
there.
So
from
three
to
four.
We
essentially
did
the
split
of
the
two
documents,
so
everything
that
was
related
to
use
case
2
is
now
in
brewski
prn
and
the
remaining
parts
are
contained
now
in
blueski.
Ae
are
still
in
blueski
ae,
so
we
also
have
some
change
of
authors
there.
So
david
from
ohan.
H
He
is
co-author
and
will
be
the
main
editor
for
brewski
ae.
He
is
currently
engaged
in
doing
a
proof
of
concept
of
what
has
been
described
so
far
in
bushki
ae,
and
I
think
that's
very
good
to
have
that
implementation
background
to
be
able
to
progress.
The
draft
thomas
has
left
and
will
concentrate
on
the
second
draft
brewski
prime.
H
So
next
steps
regarding
ae
is
the
clarification
of
the
further
open
issues
which
we
have
stated
in
the
draft
on
the
anima
github.
There
is
currently
no
open
issue,
so
the
ones
that
were
related
to
the
use
case
2
we
moved
to
the
brewski
prn
repository,
so
the
next
step
would
also
include
to
enhance
the
general
description
using
alternative
enrollment
protocols
and
then
concentrate
on
the
lightweight
cmp
profile,
as
stated,
and
maybe
also
on
est,
with
full
cmc.
That
is
something
we
have
to
discuss
further
out
with
elliot.
H
I
don't
think
that
eliot
is
participating
today,
but
this
is
something
we
have
on
the
list,
so
the
updates,
as
usual,
will
be
circulated
and
also
as
usual
working
group
review
is
appreciated,
and
since
I
mentioned
that
david
is
they're
currently
engaged
in
the
proof
of
concept
implementation.
H
We
also
did
some
alignment
with
the
naming
of
the
ietf
vulture
request
with
other
drafts
and
anima,
like
the
constraint
voucher,
for
instance,
to
be
able
to
list
them
accordingly
and
then
in
the
voucher
exchanges.
We
now
use
the
ietf
voucher,
request,
prm,
which
has
the
enhancement
included
for
the
agent
signed
data,
which
is
one
of
the
elements
that
is
included
by
the
registrar
agent,
and
we
also
included
the
changes
from
netconftp
regarding
the
csr
types.
H
Regarding
the
next
steps,
so
we
need
to
further
rework
the
draft
so
adapt
a
little
bit
the
structure
of
the
draft
and
also
the
application
examples,
because
there
were
just
a
couple
of
examples
included
and
yeah.
We
would
like
to
enhance
them
further,
and
then
we
have
some
open
issues
which
are
also
stated
on
the
anima
git
and
also
in
the
draft.
H
So
one
is
to
to
essentially
verify
that
what
is
included
now
regarding
the
ietf
ztp
types,
which
we
use
to
convey
the
pkcs10
request,
if
that
is
defined
in
the
right
way,
and
then
we
have
a
further
open
issue
regarding
the
generation
of
multiple
csrs.
So
the
reason
behind
that
is
right.
Now
we
are
concentrating
of
bootstrapping
a
generic
certificate
which
can
be
utilized
later
on.
H
If
the
pledge
has
already
some
knowledge
about
the
deployment
domain
or
about
the
application
that
he
requires
a
certificate
for
then
it
might
be,
it
might
be
useful
to
also
be
able
to
generate
multiple
csrs
that
are
then
they're
bootstrapped,
essentially
during
the
or
enrolled
during
the
first
first
round
of
boosky
prm.
H
H
If
we,
if
we
think
those
scenarios
further,
then
we
may
end
up
in
including
additional
information
for
either
the
certificate
or
also
some
some
further
configuration
data
for
the
for
the
pledge,
and
when
we
do
that,
then
we
would
for
sure
need
a
signature
on
the
enrollment
response,
because
currently
we
don't
have
a
signature
included
because
the
ldfid
is
assigned
by
itself.
H
H
B
All
right,
thank
you
very
much
all
right
and
I
think
that
bring
us
to
thomas
as
the
next
one
update
on
jws
sign
vouchers.
I
So
can
you
see
it
yep,
so
this
is
just
a
quick
update
on
so
what
happened
in
the
jws
signed
vouchers
draft
so
michael
and
I
working
on
that.
So
to
recap
what
it
is
about,
so
the
rfc836
specifies
cms
sign,
json,
voucher,
artifacts,
and
here
this
draft
proposes
json
another
option,
so
it
does
not
make
any
changes
in
the
in
the
young,
and
so
it
can
be
used
by
the
brisket
rlc8995
and
it
also
so
it
is
used
also
for
the
prisky
prime
stefan
just
reported
about
that
before.
I
So
what
happened
here
also?
What?
What
is
the
content?
So
we
have
two
serialization
options,
so
one
for
compact
area,
serialization,
the
other
one
for
the
adjacent
serialization.
I
So
first
we
first
choice
was
to
go
for
compact,
so
this
is
already
so
implemented,
so
at
least
on
my
side
and
considered
in
the
draft-
and
there
may
be
also
interest
in
in
in
json
serialization
by
opc
ua
foundation.
So
this
is
to
be
clarified
and
analyzed.
I
So
only
small
changes
happened
in
in
that
draft
now
from
zero
zero
to
zero
one.
So
we
in
our
consistent
use
of
the
terms
pledge
voucher,
request,
registrar,
voucher
request
and
the
appropriations
of
that,
and
so
also
the
media
types
are
fixed
and
some
terms
where
were
mixed
up
before
so
so
consistent
uses
of
jws
instead
of
jwt
and
cozy
so
and
some
updates
in
the
references.
I
That's
it
mainly,
and
so
next
steps
here
is
yeah.
I
said
already
investigate
in
the
second
gen
serialization
option,
for
the
json
in
the
jws
and
yeah
circulate
the
outcome
to
the
mailing
list.
Of
course,
feedback
is
always
welcome
here.
I
Maybe
if
somebody
would
be
interested
into
interested
to
do
the
chat
art
that
would
be
also
nice
so
as
tall
as
already
asked
for
that,
and
also
working
group
review
would
be
appreciated
here
and
that's
it
any
questions.
B
B
Then
you
may
receive
back
so
sorry
for
not
being
on
top
of
all
the
workflows
I
was,
I
was
wondering,
is
this:
you
know
the
more
variability
in
you
know,
protocol
options
or
encoding
options,
whatever
we
call
it
we
get.
Is
this
safe
against?
You
know
poor
operator
in
the
end
sitting
there
and
not
knowing
why
stuff
isn't
working
in
terms
of
let's
say
a
pledge
supports
some
different
encoding
than
the
registrar.
B
I
If
this
draft
is
acknowledged-
as
I
think
this
has
to
be
respected
in
the
draft
making
use
of
it,
so
at
the
end,
so
this
draft
just
defines
the
format
or
the
form
factor
so
and
other
standardizations
or
other
other
specifications
making
use
of
it.
For
example,
the
crispy
prm
have
to
make
sure
that
this
that
no
clashes
can
happen.
Here.
I
would
say.
B
Right,
but
I
mean
is
the
what,
when
a
voucher
is
being
transmitted,
is
it
kind
of
done
with
a
request
where
you
know
the
supported
encodings
are
in
there,
so
that
the
registrar
know
which
encoding
you
know
would
be
feasible
when
it
sends
the
voucher
or.
I
This
is
included
in
the
content
type
header
and
in
the
accept
header,
so
by
the
accept
header,
the
pledge
or
also
the
registrar.
If
it
requests
a
voucher
from
the
mother
can
define
or
specify
wants
what
it
wants
to
receive.
I
B
We'll
just
use
just
an
example
right
I
mean
the
more
variability
we
get.
You
know
there
are
two
concerns.
One
is
so
many
drafts
for
the
itf,
but
the
the
other
one
is
just
making
sure
that
you
know
we.
We
may
not
get
interoperability
between
everything
which,
which
is
fine,
but
at
least
we
should
be
able
to
always
get
the
right
diagnostic
to
not
have
the
solution
become
undeplorable
that
that's.
I
Right
and
maybe
something
to
add
so
the
default
here
is
so
the
idea
is
here
by
default.
If
nothing
is
specified
in
the
headers,
so
then
it
replies
back
so
what
what
received
in
the
request
format.
So
if
you
receive
a
jws,
signed
voucher
request,
then
the
server
replies
with
a
jws
voucher
and
if
there
is
need
to
change
the
the
response
this
can
be
addressed
by
the
by
the
except
header.
B
Otherwise,
I
think
we're
back
to
michael
status
of
8366.
This
effort.
G
D
This
parameter
came
out
of
the
brewski
async
enroll,
who
needed
to
have
an
additional
value
for
the
enumerated
stuff,
and
so
we
now
have
all
these
derivations
from
8366.
D
And
it's
been
now
three
years
since
we
published
this
document,
so
the
problem
was
that
we
needed
to
do
this
enumerated
type
and
it
turns
out
that
we
can't
do
this
in.
We
can't
just
extend
the
yang
it's
not
a
way
that
we
can
do
it
because
of
the
way
we
did
it,
but
there
is
a
different
way
and
and
brisky
sync
and
role
would
like
to
have
a
new,
a
new
assertion
type.
D
So
normally
the
assertion
type
in
brewski's
proximity,
the
top
two
possibilities
are
logged
and
the
other
one
I
always
forget
and
but
logged
is
essentially
is-
is
used
to
make
nonceless
ones
and
the
other
one
is
used
primarily
in
srtp.
For
that,
and
I
can't
remember
what
it's
called
now.
It's
lost
my
brain,
so
the
proposed
resolution
is
that
we're
going
to
revise
this
document
and
we're
going
to
make
this
an
enumerated
part
of
an
iana
managed
registry.
D
So
we
have
to
create
that
word
stream,
the
document,
and
then
we
have
to
reference
it
and
there's
a
mechanism
in
or
I'm
not
sure,
as
a
mechanism
as
a
as
a
procedure
in
the
yang
community
as
how
to
do
that,
and
so
we're
going
to
wind
up
with
the
numbers
and
the
registry
that
should
be
just
right.
This
shouldn't
have
any
real
effect
on
anyone
coding
because
we
shouldn't
actually
be
changing
the
the
resulting
json
or
sebor.
That's
derived
from
this,
in
theory,
will
not
change
at
all.
D
So
if
you
aren't
using
something
new,
then
this
will
be
a
completely
no
change
to
the
any
of
the
bits
in
the
wire
but
will
accommodate
new
types
of
bits
in
the
wire.
If
someone
was
generating
something
with
a
yang
code
generator,
then
maybe
there
would
be
some
difference.
I
I
don't
know
exactly.
I
presume
they
would
not
be.
We
would
code
it,
so
there
would
not
be
so.
What
have
we
done
so
far?
The
work
to
do
so.
We
turned
to
the
document
into
an
xml.
D
D
D
D
So
I'm
still
a
bit
unclear
of
the
working
group.
How
the
working
group
feels
about
this.
It
might
be
worth
having
a
consensus
call
or
some
other
other
thing.
Just
ask
the
working
group.
What
do
you
want
to
do?
Is
this
really
what
you
want
to
do
and
I
personally
haven't
had
any
time
to
do
it
since
I
work
on
it
since
at
itf
111.,
what
I
thought
was
that
we
would
adopt
it
first
and
then
we
would
we
would.
D
That
would
be
the
consensus
that
the
working
group
wants
to
work
on
this
problem
and
then
we
would
put
the
changes
and
then
the
adopted
document
would
be
identical
to
the
original
one,
but
that's
not
how
the
group
chairs
would
like
to
work.
So
that's
fine,
we'll
continue
that
there
might
be
some
other
things
that
need
to
be
fixed
in
8366.
D
It
is
now,
although
it
was
published
three
years
ago,
it
is,
you
know,
probably
more
like
four
or
five
years
since
we
really
had
a
working
group
discussion
about
it
and
one
of
the
possibilities
is
whether
or
not
we
could
go
from
proposed
standard
to
internet
standard
in
this
same
step
because
we're
essentially,
we
have
a
large,
fair,
large
amount
of
interoperability
experience
and
we're
essentially
fixing
a
bug
in
the
in
the
document.
We're
not
really
actually
changing
anything
on
the
document.
So
that's
a
possibility.
D
Could
we
go
to
proposed
stan
internet
standard
step
two
at
the
same
step,
and
I
don't
I
don't
really
know
about.
I
don't
know
whether
that's
whether
the
changes
would
be
too
much
or
not
enough
or
what
exactly
that's
it
for
me.
B
I'm
not
quite
sure
about
you
know
your
comment
about
how
the
chairs
wouldn't
want
to
run.
It
so
remind
me
what
what
that
was,
but
other
than
that
I
think
on
on
your
questions.
I
don't
I
don't
see
any
other
options
than
doing
this.
D
We
may
not
have
articulated
our
needs
correctly.
It
may
be
that
the
the
the
the
state
of
yang
four
or
five
years
ago
was
oh,
we
didn't
think
of
that.
Okay
and
now
they
have
so,
I
think
that's
pretty
pretty
part
of
it.
One
of
the
things
that
we
could
do
in
this
revision.
If
it
wasn't
urgent
is
we
could
go
and
collect
all
of
the
extensions
from
all
the
other
documents
right.
I
I
don't
know
that's
a
great
idea,
but
we
could
do
it
right,
it's
something
that
could
happen.
D
So
I'm
not
I'm
not
sure
exactly
what
to
do
that
way.
I
think
we
shouldn't
collect
all
the
extensions
into
this
document
that
those
other
it'll
be
disruptive
to
those
other
documents
and
there
if
we
were
starting
this
work
solely
for
the
purpose
of
going
to
internet
standard,
then
I
would
say,
that's
probably
is
a
good
idea.
We
probably
would
have
published
several
other
documents
already
and
that
maybe
argue
why
we
shouldn't
bother
trying
to
do
this
step.
At
this
point.
B
B
Yeah
exactly
fixing
bugs,
and
then
I
think
we
also
need
some.
You
know
implementation
experience
document
or
so
we've
we've
done
this
in
other
working
groups,
so
it
would
be
a
good
thing
right
if
we
can
show
implementations
into
ability
that
I
think,
would
help
us
to
do.
That.
So
certainly
seems
like
the
easier
thing
now
to
you
know
get
on
top
of
the
yang
thing,
because
that
may
be.
You
know
something
we
want
to
do
for
other
documents
as
well
correctly
and
then
do
the
proposed
the
go
go
to
internet
standard
with
it.
B
That
sounds
like
an
achievable
and
useful
goal.
J
My
hunches,
you
can,
yes,
I
think
I
think,
as
you
say,
I
think
summarize
this
up
well
as
long
as
it's
sort
of
bug
fixes
and
things
going
in,
I
I
think
that
that
would
be
fine.
As
far
as
I
could
see,
there
is
a
choice
also
to
publish
it
was
ps
and
then
the
separate
status
change
document,
but
it'd
be
better
to
one
go.
I
think.
B
B
Okay,
thank
you
very
much.
If
nobody
else
has
comments,
let's
move
on
to
slot
number
seven
autonomic
ip
address
to
access
control
group
mapping.
Yuzu!
Can
you
please
step
forward.
K
Okay,
so
I'm
going
to
show
this
this
deck
right.
Basically,
it
is
update
to
this
to
this
asa
function
called
a
autonomic
ip
address
to
access
control
groups.
Mapping.
Let
me
see
the
next
one.
K
K
So
we
deployed
the
asa
here
in
order
to
pass
around
the
information
from
the
the
mapping
information
from
the
ip
address
or
ip
prefix
to
the
access
control
group.
So
the
the
motivation
for
this
for
this
work
is
the
group-based
policy
is
becoming
more
and
more
commonly
deployed,
especially
in
campus
network.
K
So
we
would
like
this
map
information
to
be
passed
from
the
aap
to
pep
the
we
want
to
define
the
new
grasp
objective.
We
call
it
ip
address
to
access
control
groups.
This
is
pretty
long,
but
we
couldn't
figure
out
a
shorter,
but
still
precise
name
for
it.
So
if
this
new
objective
is
defined
to
carry
this
information-
and
also
this
objective
is
supposed
to
be
used
by
an
asa
we.
Similarly,
we
call
this
asa
and
the
name
is
ip
address:
2
access
control
group.
K
First,
we
give
a
name
to
the
essay
which
uses
which
uses
this
a
new
defined
objective
and
we
clarify
the
terms
pep
and
aap.
Basically,
in
the
context
of
anima
there
are,
there
are
rules
for
asa
supporting,
I
mean
for
asa.
We
start
with
the
same
objective,
but
how
this
rose
is
going
to
be
supported.
K
K
So
there
are
some
other
editorial
editorial
changes,
but
for
this
for
today's
presentation,
I'm
going
to
show
a
few
examples
of
how
exactly
this
information
will
be
passed
around
this
information
passing
around.
Basically,
I
don't
think
it
will
become
part
of
the
standard,
but
it
would
be
informative
for
the
readers
to
understand
it.
The
most
useful
part
for
the
standard
I
mean
the
standard
part
is
most
likely
would
be
the
the
the
information
defined
for
the
objective,
which
is
already
in
the
draft.
K
So
most
likely.
The
aap
will
provide
the
mapping
information
to
pep.
So
there
are
two
stages.
The
first
one
is
discovery.
The
second
one
is
negotiation,
so
the
aap
will
send
the
discovery
into
and
to
find
out
the
path.
Usually,
the
number
of
pepsi
is
quite
limited
in
a
campus
network.
There
might
be
only
two
of
them
all
three,
maybe
so
it
will
send
the
negotiation.
K
The
aap
will
send
a
negotiation
to
try
to
push
the
information
it
knows
about
for
the
ip
address
and
the
group
id
to
all
the
peps.
So,
basically,
that's
the
that's
the
most
common
and
simple
procedures
to
push
the
map
information
and
the
this
slide
shows
the
path
asks
for
this
mapping
information
from
aap.
This
is
rare
because
in
most
of
the
cases
we
think
the
aap
would
voluntarily
push
the
information
to.
K
Perhaps
so,
but
there
could
be
some
corner
cases
that
have
there
is
no
pre-stored
information
mapping
information
on
the
path
so
when
never
have
received
the
first
packet
of
floyd
has
to
ask
for
the
ap:
what's
the
mapping
information
for
particular
ip
address
or
rp
prefix,
so
similarly
we
have
discovery
stage.
Then,
instead
of
the
negotiation,
we
have
a
synchronization
synchronization
message
for
this
procedure.
K
Okay,
so
next
slides
this
basically
shows
us
an
example
of
when
a
new
path
joins.
What
may
happen
so
when
the
new
pipe
joins
it
try
to
discover
all
the
aaps,
because
aps
are
the
owners
of
the
mapping
information,
so
the
we're
assuming
that
aap
will
reply
with
all
the
information.
K
What
reply
the
information
has,
so
the
pap
will
collect
the
info,
all
the
all
the
information
from
from
other
aaps.
So
we
gave
three
examples
of
the
of
how
this
graph
objective
would
kind
of
would
be
used.
K
It's
not
a
exhaustive
list,
but
I
think
that
should
cover
most
of
the
cases.
Besides
that,
after
we
uploaded
the
updated
version,
we
also
we're
still
receiving
the
comments
from
the
list
and
also
off
the
list.
K
K
This
is
basically
to
avoid
the
tcp
long
connection
problem,
and
we
want
to
the
second
change.
We're
going
to
make
is
to
allow
the
discovery
message
in
rapid
mode
to
be
used
in
order
to
accelerate
the
procedures.
Then
the
last
one
is,
as
the
I
think,
the
first
or
second
page
says
we
have
a
role
which
that
basically
it
tells
me
it
tells
the
tells
whether
it
is
an
aap
or
is
a
pep.
K
So
we
are
trying
to
use
the
objective
name
with
the
ip
address
to
access
control,
group,
dot,
aap
and
dot
pap
for
multiplexing
purpose.
That's
an
easy
fix
and
a
quick
fix
for
for
our
for
the
function
of
row
to
work
also
thanks
to
brian
to
suggest
this
quick
fix.
So
this
is
what
we
are
going.
We
we
haven't,
but
we
are
going
to
incorporate
to
the
next
version.
K
The
next
step
is
we'll
revise
the
draft
accordingly,
as
we
show
in
the
previous
page
and
upload
it
when
the
chat
when
the
uploading
channel
reopens
or
it's
already
reopened-
I
don't
know
so.
The
authors
would
like
to
call
for
adoption
for
the
next
revision.
We
think
it's
it's.
It's
is
pretty
clear
and
ready
for
adoption.
I
think
that's
the
last
page
yeah,
that's
the
last
page
any
questions,
comments
or
or
suggestions
to
this
document.
B
So
the
the
thing
I'd
I'd,
really
love
to
see,
even
if
it's
kind
of
you
know
maybe
outside
of
the
scope
that
you
were
intending
to
have
is
you
know
a
really
an
example
of
of
an
actual
service
instance
with
the
service
parameters,
so
that
somebody
could
build
a
prototype
implementation
of
this
that
actually
did
something
in
an
improbable
fashion.
So
I
don't
know
what
you're
kind
of
a
real
great
example
for
such
a
service
would
be
because
it's
it's
so
abstract
that
I
can't
even
circle
in
on.
B
K
Okay,
so
maybe
you
you
wonder,
you
want
me
answer
this
right
now
or
you
want
to
somehow
maybe
put
it
too
late.
B
E
B
An
example
section
of
showing
you
know
here
is
how
you
would
adopt
this
for
a
particular
service
and
that
that
service
is
exactly
named
whatever.
That
qs
thing
is.
B
More
rightness
yeah,
but
then
appendix
ultimately
would,
I
think,
also
allow
us
to
figure
out-
and
I
think
that
is
the
the
really
important
part
toward
this-
the
spec,
if
or
how
we
would
may
need
to
create
registries
where
actual
services
that
want
to
get
standardized
would
go
in
and
if
we
have
services
that
are
not
standardized
right.
So
if
we
basically
pick
up
the
grasp
stuff
that
is
in
here,
we
need
to
very
precisely
understand
how
application
can
use
it
in
a
proprietary
and
or
standardized
fashion.
B
And
that's
where
you
know
an
example
is,
is
really
helpful
to
identify
these
extension
points
and
then
start
for
the
grasp
stuff.
Here
the
same
difficult
discussion
about
ayana
registries-
or
you
know
other
things
to
to
really
be
good
about
the
extension
points.
B
Okay,
any
other
questions.
B
I
think,
then,
we're
up
to
number
eight
autonomic
mechanism
for
resource-based
network
services,
auto
deployment
using.
Can
you
please
step
forward?
Okay,.
M
Okay,
I
have
my
and
how
you
see
my
screen.
M
Oh
okay,
let's
start
I'm
I'm
using
speaking
today,
I
will
presentation
the
draft
auto
deployment
mechanism
for
resource
bases
and
network
network
service
and
in
the
ietf
111
drama,
starter
trust
draft
to
this
classes
on
o2d1
department
mechanism
that
deploys
the
resource-based
network
service
through
the
acp
and
by
using
grasp,
and
this
draft
describes
the
negotiation
between
the
resource
required
node
to
the
required
to
the
results
provider
node,
and
this
draft
want
to
describe
how
the
asa
manages
the
results
in
the
network
automatically.
M
Okay,
according
to
the
mailing
discussion,
the
new
version
returned
a
lot
and
we
summarize
the
major
changes
in
the
volume
modification.
So
first
is
that
the
drafts
sort
out
the
definition
of
the
network
elements
and
the
second.
The
draft
is
plans
more
details
about
the
resource
process,
with
a
suggestion
from
the
boy
and
michael
and
it
is
most
important
change
in
our
draft.
M
First
of
all
clay
is
they
redefine
some
terminology
and
the
the
first
way
should
I
emphasize
is
resource
manager,
aisa
and
the
resource
manager.
Asa
is
a
candle
for
autonomous
server
agents
and
it
manages
the
results
in
the
network.
M
M
On
this
page,
we
introduce
house
to
asa
manages
results
in
the
network,
so
resource
manager,
aic,
is
often
divided
to
the
request
requesting
results
manager
is
assigned
providing
resource
manager
asa
under
the
communicates
communicate
by
using
grasp
manager
under
the
acp
and
the
auto
deployment
mechanism
process
includes
three
parts.
M
And
in
the
resource
negotiation,
the
resource
measure
it
as
a
negotiation
resource
by
using
the
resource
manager
manager
grasp
objective.
This
objective
will
design
we
defined
in
our
draft
and
we
will
introduce
the
next
page.
M
Another
resource
negotiation
may
take
place
in
several
rounds
and
in
each
round
requested
requesting
resource
manager.
Asa
can
request
more
resource
according
to
the
aes
requirements,
and
it
will
decide
either
each
round
how
large
resources
they
should
to
be
offered
and
as
for
the
providing
resource
manager
aic,
it
responds
the
whole
large
resource
they
can
offer
and
they
can
offer
to
the
repressing
resource
manager
aic
and
in
the
behavioral.
After
negotiation.
Part
of
the
research
the
nato
agent
is
already
under
the
resource
provider.
M
M
Okay,
and
this
page
is
about
the
update,
graphical
objective
and
this
grasp
objective.
The
name
is
resource
manager.
The
users
need
to
be
added
to
the
grasp
objective
name
registry
under
the
lobe
taunt
and
objective
file
we
defined
as
in
the
grasp,
should
emphasize
that
different
for
the
div
resource
type
and
the
resource
value
different
resource
type
of
wait.
Time
requests
today.
M
Okay,
there
are
some
questions
to
the
discussed
in
the
future
under
the
first
is
how
to
establish
how
to
deal
deployment
mechanism
to
release
or
increase
the
results
when
the
server
initiator
changes
need.
M
Another
question
is
that
if
the
two,
as
I
say,
are
in
a
different
different
domain,
what
are
the
rules
they
should
follow
and
about
this
question
brian
wrote
me
some
suggestions,
suggestion,
and
I
will
add
this
in
the
next
word
lecture.
The
next
step.
We
will
plan
to
discuss
some
more
open
issue
and
update
some
in
the
next
version.
M
The
last
question
is
that
riser,
do
you
think
this
is
a
useful
word
for
anima
and
the
draft
is
ready
for
adoption?
Okay,
that's
all
my
thought,
all
my
thoughts.
Thank
you.
B
Thank
you
yeah.
I
think
the
the
same
comment
as
on
the
last
document,
an
example
with
really
all
the
concrete
parameters
and
everything
so
that
something
could
be
implemented
to
actually
show
how
how
this
would
work
in
reality
would
help.
I
think,
a
lot
of
reviewers
and
other
working
group
members
to.
D
D
We
had
a
lot
of
conversation
about
about
building
acps
across
domains
at
some
point,
and
I
think
it's
really
important
to
understand
what
is
the
use
case
for
this
to
understand
what
is
the
appropriate
trust
for
that,
and
it
might
be
that
this
is
a
case
for
needing
authentication
and
grasp,
or
it
might
be
that
this
is
the
case
for
actually,
I
think,
your
diagram
kind
of
and
hints
at
this
here,
that
to
go
across
domain,
that
we
somehow
create
a
some
asas
that
that
do
this
application
layer
stuff
between
the
two
of
them.
D
But
I
think
that
what
is
the
right
answer
depends
upon
what
it
is
that
you're
doing,
and
I
think
that
we
need
some
examples,
and
maybe
this
doesn't
apply
for
all
all
things.
Maybe
the
same
answer
doesn't
apply
for
all
things.
So
that's.
What
I
would
ask
is
is
that
that
be
called
out
a
little
bit
more
clearly
in
the
document.
What
is
the
example
for
the
cross
domain
scenario?.
M
Okay,
okay,
I
will
think
about
this
question
and
I
think
her
way
in
this
draft.
We
want
to
discuss
a
negotiation
process
and
always
think
what
they
are
the
scenario
in
the
different
domain.
M
They
will
have
some
more
problem
about
us
supporters,
security,
but
I
see
security,
but
I
think
this
is
a
shouldn't
discuss
in
our
draft,
but
I
will
think
this
more
detail
underway
can't
discuss
in
the
mailing
list.
D
D
Why
would
I
ever
want
to
deploy
a
resource
across
this,
and
I
think
that
we
need
some
real,
concrete
things
to
say
what
they
are
for
that,
and
you
know
I
can
think
of
some
like
optical
paths
or
other
layer,
two
vpns,
or
something
that
have
to
cross
multiple
providers
or
something
like
this,
but
I
I
think
that
that
needs
to
have
some
like
the
word
acros.
The
word
domain
shows
up
14
times
in
your
document,
but
only
two
times
with
cross
domain,
and
it
never
explains
why?
D
L
A
A
Michael,
allow
me
to
answer
you
as
a
co-author
for
this
draft.
First
of
all,
we
are
not
going
to
solve
that
in
this
draft.
That's
out
of
scope,
because
for
all
those
efforts
we
had
in
enema,
we
are
actually
limit
ourself
in
our
single
domain.
A
That's
why
the
brands
suggesting
said
you
know
it's
the
three
separate
into
two
domains,
and
but
we
do
have
the
use
case
in
in
the
real
world.
We
lead
the
cross-domain
coordination,
mostly
for
the
you
know,
undertrained
quality
guarantees,
if
you
only
in
currently
one
because
they,
if
there
are
cross-domain
paths
from
and
understand
the
past,
it
will
have
only
response
resolved
in
one
domain
in
another
domain.
You
actually
has
the
pas
another
part
of
this
pass
for
the
best
efforts.
A
Then
that
means
whatever
you
have
on
on
the
one
single
domain,
with
whatever
resource
you
have.
You
may
waste
that,
because
the
the
in
another
domain,
the
latency
or
whatever
the
quality
may
get
get
damaged
by
the
best
efforts.
So
we
do
need
the
cooperation.
But
again
that's
not
the
purpose
of
our
draft.
A
A
B
All
right,
so
this
is
about
the
the
two
drafts
that
I
already
presented
on:
itf
112,
so
the
grasdian
ssd
and
the
nmr
services
dns,
auto
config,
just
wanted
to
quickly
explain
what
we
again
what
they're
about
and
where
we
stand.
So
the
dns
draft
is
wasn't
updated
since
111
and
it's
a
specification
to
support
the
equivalent
of
the
dns
sd
service
announcement.
B
Discoveries
with
even
you
know,
better
service
selection
parameters
through
grasp
and
equivalent
means
it's
not
any
encoding
of
dns
resource
records
or
mdns
packet,
headers
or
so
into
graphs,
but
really
only
the
encoding
of
the
you
know.
Api
parameters
like
service
name,
service,
weight,
service
sharing,
all
those
and
the
addresses,
and
so
the
service
parameters
which
have
very
convoluted
encoding
into
dns
resource
records.
B
B
And
the
second
document-
also,
we
didn't
update
it
since
ietf111,
but
just
to
re-summarize
again.
That
was
actually
the
driver
to
do
the
first
document
and
that's
really
the
minimum
amount
of
self-auto
configuration
of
services
that
we
need
to
bring
the
a
I
infrastructure
up
to
a
place
where
the
most
likely
shortest
term
you
know
deployments
will
be
able
to
use
it,
and
those
deployments
would
be
the
ones
that
we
described
in
rfc
8368,
which
is
the
a
I
together
with
sdn
controllers,
and
so
we're
basically
talking
about
everything.
B
The
sdn
controller
shouldn't
touch
so
that
the
sdn
controller
actually
has
reliable
connectivity
across
the
whole,
a
I
without
being
able
to
break
it,
and
that
particularly
means
that
we
need
to
have
syslog
for
diagnostics.
We
need
to
have
ntp
so
that
our
certificates
are
even
working
across
all
the
devices,
because
we
have
good
enough
time,
synchronization,
radius
and
diameter
and
ssh
so
that
the
sdn
controller
can
actually
connect.
B
You
know
for
cli
or
yang
netconf
operations
into
the
devices,
so
this
is
kind
of
the
most
core
infrastructure
services
and
and
that
should
ultimately
really
round
up
a
first
round
of
a
I
that
can
be
usefully
deployed.
So
really.
I
I
want
to
ask
for
the
working
group
for
adoption
to
this,
so
this
should
get
on
the
list.
For
you
know,
adoption
call
by
the
working
group
chairs.
A
With
my
shareholder
on
to
ask
you:
is
there
any
reason
you
cannot
merge
this
to
draft
into
one.
B
I
think
that
is
is
logically
quite
illogical
right
because
these
these
these
services
that
we're
talking
here
about
they're,
really
very
specific
to
you-
know
ani
networks.
As
you
know,
I
imagine
them
to
be
used
short
term
with
rfc
a3
888
and
the
the
grasp
stuff
is
very
generic
applicable
to
all.
You
know
the
other
uses
of
asa
and
automatic
functions,
and
so
you
know
one
is
defining
a
protocol,
and
so
this
you
know,
I
think
you'd
be
asking
me
why?
B
Okay,
okay,
all
right!
So
michael,
do
you
want
to
say
something
to
slot
10?
You
said
no
slides!
You
want
to
step
to
the
microphone
or
we
want
to
skip
that
slot.
D
I'll
just
say
that
the
documents
aren't
dead,
that
there
is
some
work
on
the
derived
document
about
idev
id
considerations
in
the
t2trg,
but
that
I'm
not
receiving
a
lot
of
feedback.
That
says
these
are
terribly
useful
documents.
So
if
you
disagree,
that
would
be
great.
So
that's
about
it.
B
Yeah,
you
simply
need
to
click
on
that
icon
on
the
right
of
the
hand.
M
B
Green
chair,
which
is
fine,
we
had
one
presenter
and
before
doing
the
same
thing,
so
typically
it's
for
for
all
the
participants,
unless
your
slides
have
animations
or
so
it's
it's
easier
for
for
all
participants
to
to
see
the
pre-shared
slides.
But
please
go
ahead.
Just
wanted
to
make
the
note.
M
Okay,
I'm
replacing
presentation
the
draft
recommends
under
the
reference
model
of
layer,
2,
basic
ai
and
this
documentary.
We
want
to
discuss
the
scenarios
and
the
requirements
of
layer,
2
sap,
and
it
is
an
incident
of
generalized
ap
to
employment,
part
of
an
eye
function
in
the
layers
of
network,
and
then
it
shows
a
reference
model
to
transparent
search
layer
to
sap
and
as
a
relative
function.
M
M
So
acp
is
a
autonomic
control
player
and
it
is
self-managing
and
as
independent
as
possible
of
configuration
control
plan
and
the
way
it
can
say
that
current
sap
implementation
use
ip
basics
link
to
local
addresses
based
sap
turno.
So
we
can
say
and
is
that
the
current
sap
is
a
layer,
three
control
and
control
plane
and,
however,
there
are
some
cases
that
always
enter
required
is
in
layer,
2,
sap
functions,
and
here
this
picture
shows
some
some
cases
way
to
require
the
layer
to
sap
functions.
M
M
The
number
of
hoses
is
usually
less
than
200,
and
the
second
network
contains
a
different
type
of
the
in
equipment,
some
layer,
two
switches
layers
with
rotors
and
hybrid
layer,
two
and
the
layers
with
switches,
and
we
think
they
are
how
a
multi-level
layer
to
topology
network
so
how
to
control
this
multi-level
network
user
was
discussion
and
the
third
wasting
some
notes
how
a
fewer
results
in
the
network,
like
some
iot
nodes.
M
Lastly,
we
seen
that
the
network
is
sometimes
required
to,
firstly
form
a
local
air
network
disconnected
from
the
internet,
so
that's
about.
We
think
that
autonomous
network
management
with
layer,
2
network
nodes
is
required
about
always
summarize
the
scenarios
requiring
layer
2
sap.
M
So
why
is
that
some
manager
network
is
a
small
layer
to
network
wires
network
knows
how
no
layer
3
physical
interface
and
our
favorite
results,
and
the
answer
is
the
network
manager
would
have.
I
would
like
to
use
and
verify
the
layer,
2
topology
and
the
readability
first
for
some
major
purpose,
because
sometimes
some
parts
can
not
have
ip
addresses,
so
we
should
use
a
layer,
2
topology,
to
control
this
based
on
the
layer.
Two
scenarios
we'll
propose
some
layer,
two
requirements
way.
We
think
we
write
on
this
nine
pointer.
M
So
first
is
starter.
We
send
her
the
ip
addresses
of
the
node
and
its
interface
made
not
to
be
available
upfront
and
the
racing
resources.
Current
acp
turnout
is
suitable
for
this
situation.
M
Under
the
certain
reasons
that
layer,
2,
sap
construction
can
be
used
on
the
layer
to
available
information
and
mechanism,
such
as
the
metal
addresses
the
law
of
physical
part
information,
threes.
Three.
We
think
that
adjacent
node
discovery
should
be
carried
as
a
layer,
two
frame
under
the
first
wave
center.
It
is
there
to
reduce
the
grasp
message
as
much
as
possible.
M
So
not
this
sensor.
We
sent
a
layer
to
sap
for
the
provider
api
to
the
upper
layer
to
allow
the
asa
to
invert
the
layer
to
basic
function
and
the
physical
connectivity
and
the
topology
information
should
be
able
to
connect
it
well.
The
layer,
2
sap
and
the
next
routine
in
the
layer.
2
sap
should
support
there
to
loop,
a
free,
logical,
topology
creation.
The
minimal
manual
configuration
is
required.
M
The
last
is
center
reuse,
exciting,
multitasker
mic
address
is
desired.
This
is
the
requirements
of
resources,
layer,
2
sap
should
how-
and
maybe
this
is
not
very
complete
and
the
this
picture,
which
shows
a
reference
model
to
layer
to
sap
under
for
the
reference
model.
We
think
that
the
trans
transaction
api
should
allow
asa
to
communicate
with
other
assets
by
involving
a
set
of
layers
to
transport,
the
basic
function
and
the
layer.
2
sap
provide
a
similar
function
as
layer
3
says
in
the
printer
and
as
a
layer.
M
2
sap
should
provide
a
lighter
discovery,
negotiation
and
synchronization,
and
always
think
there
are
the
same
like
the
layers
with
atp
about
the
convolution
we've
seen
that
there
are,
there
are
how
some
scenarios
require
there
to
sap
underway.
M
Hopefully
they
always
emphasis
is
an
important
topic
in
the
unm
and
we
want
to
find
a
way
to
wait
to
define
the
layer,
2
sap
and
the
second
is
that
wait,
the
layer
to
sap
with
this
has
a
year.
Our
draft
is
to
build
a
layer
to
basically
the
sap
rather
than
the
sap
on
layer
port,
so
we
send
such
a
way
through
the
master,
to
face
some
situations
after
the
interface
have
no
ipo
addresses,
so
maybe
we
can
use
the
micro
address
about
others
like
a
security
consideration.
M
I
think
if
the
network
is
not
very
loud
with
largely
contained
some
physical
way
to
protect
our
network,
and
but
I
actually,
I
think
this
is
not
over-
not
a
complete
underway
thing.
We
need
a
further
discussion,
okay
next
type
of
way
center.
We
should
talk
about
more
about
layer,
2
sap,
and
I
think
this
should
be
discussed
more
clearly.
Okay,
that's
all
my
thoughts.
Thank
you.
B
Thank
you
maybe
question
from
my
side,
so
in
the
layer,
3
acp,
the
very
simple
process
from
receiving
a
packet
into
the
acp
on
one
interface,
routing
it
at
layer,
3
and
sending
it
out
has
just
a
very
few
steps
right,
so
you're
receiving
a
packet
on
a
link,
local
ipv6
address
you're,
let's
say
decrypting
it
with
ipv6.
B
Oh
sorry
with
ipsec,
and
then
you've
got
an
acp
ipv6
packet,
you're
routing
that
it
is
routed
from
the
ripple
routing
protocol
and
on
the
outgoing
interface.
You
do
the
reverse
thing:
you're,
encapsulating
it
protecting
it
with
ip36
and
sending
it
out,
link
local
to
the
next
hop.
So
can
you
explain
for
your
solution?
B
B
Right,
so
I
think
that
that
would
be
the
first
step
in
terms
of
please
define
a
standard.
You
know
doesn't
have
to
be
the
only
one,
but
one
case
of
how
you
think
the
forwarding
should
be
able
to
work
right
when
the
packet
is
received
and
what
address
is
it
received?
Is
it
a
layer
2
address?
Are
there
3
address?
B
M
Can
you
hear
me
pattern
pattern.
D
One
more,
I
think,
no
or
the
first
diagram
that
one
yeah,
so
I'm
trying
to
understand
this
use
case.
So
we
we
do
acp
work
over
to
talk
to
some
management
interface
and
you've
said
that
none
of
these
devices
is
l2.
Aggregation
switch.
This
l2
access
switch,
the
wi-fi
access
switch.
None
of
these
have
layer,
3
addresses
they
don't
get
managed,
they
don't
do
snmp,
they
don't
do
net
conf.
They
don't
do
rest
comp.
They
don't
do
https.
D
Okay,
I'm
just
asking
because
it
sounds
to
me
like
they
don't
need
to
be
managed,
and
so
they
don't
need
an
acp
if
they
don't
have
any
management
interfaces
that
they
need
to
talk
to.
D
K
So
it
have
the
management
interface
after
it
gets
enrolled
and
if
it
is
in
ipv4
world,
of
course,
let's
leave
v6,
maybe
for
a
little
while
if
it
is
in
a
v
forward,
this
management
interface
still
need
to
re.
Do
the
dhcp
request
to
ask
for
an
ipv
ip
address
to
be
configured
so
that
happens
after
the
something
like
the
layer,
2
loop,
loop-free
topology,
build
up
and
everything
everything
being
done.
Then
it
asks
for
the
dhcp
send
the
dhtp
request.
So
that's
that's
a
step
by
step
by
step
thing.
K
D
It's
not
it's
not
available
at
the
step.
One.
Do
you
think
you
want
to
change
that
because
it
sounds
like
it
works?
Fine
now,
so
why
change
it?
What
change
change?
What
well
look
we've
created
an
acp
specifically
so
that
you
don't
have
to
do
a
dhcp
request
and
set
up
your
layer
2
before
you
can
do
enrollment
and
do
all
that
stuff.
D
We
went
to
a
fairly
fairly
reasonable
effort
to
have
joined
proxies
to
have
a
whole
bunch
of
other
things
so
that
we
can
onboard
devices,
even
though
they
don't
have
connectivity
even
at
layer,
two
or
three.
So
we've
done
all
of
that
in
our
rfcs,
and
we
did
that
specifically
because
the
layer,
two
auto
configuration
just
didn't
work.
D
This
scenario
here
credible
to
me,
okay,
I
think
that
all
of
those
machines
have
layer,
3
addresses
or
have
layer
3
stacks,
I
think,
what's
missing,
is
that
you're
trying
to
do
some
layer,
two
tricks
to
avoid
doing
writing
any
code
at
layer,
three
and
and
to
a
large
extent.
I
think
that's
what
this
working
group
is
trying
to
get
away
from
in
the
same
way
that
we're
trying
to
get
away
from
dial-up
modems
attached
to
switches
as
as
out-of-band
access.
So
I
just
don't
understand
why?
What
the
scenario
here
is
right?
D
What
is
going
to
happen
to
these
devices?
How
are
they
going
to
be
managed
over
a
layer,
2
network
without
and
they
don't
have
a
layer
3
address,
which
is
we've
been
told
in
a
couple
slides?
They
don't
have
a
layer,
3
address
so
you're
telling
me
they
do
have
layer.
D
3
addresses
just
not
at
that
time,
and
so
it
sounds
to
me
like
really
you
know,
I
don't
know
you
have
a
problem
where
you
have
to
solve
it
at
layer,
two,
because
the
layer,
three,
the
people
that
own
their
their
three
won't
change
their
code,
and
so
you
have
to
change
it
at
some
other
layer.
Instead,
it
just
it
doesn't
sound
like
a
problem
that
it
sounds
like
a
manager,
a
people,
management
problem,
a
human
resources
problem,
not
a
network
management
problem
right.
B
Can
we
maybe
consider
that
we're
going
over
right
now
to
the
you
know,
slot
number
11
of
of
the
whole
discussion,
because
I
think
for
your
contention
I
would
have
answers
which
I'm
not
sure
are
actually
what
the
draft
here
is
proposing,
but
would
which
would,
I
think,
exactly
answer.
You
know
why
we
would,
you
know,
benefit
from
some
form
of
layer,
2
acp.
B
Exactly
for
an
example
topology
like
this,
so
you
said
we
don't
want
to
have
dhcp,
that's
fine,
but
so
we
can
do
this
case
here
where,
let's
say
all
the
egg
switches,
the
excess
switches
and
the
access
points,
of
course,
are
in
the
data
plane
only
layer,
two
switches.
B
Let's
assume
that
right,
the
core
router
is
the
only
route
everything
else
should,
in
the
data
plane,
be
just
layer,
two
switches
so
with
the
current
rfc
8994.
We
can
do
that,
but
it
means
that
for
the
acp
we're
really
creating
layer,
three
interfaces
which
are
not
in
the
data
plane,
which
are
you
know
just
for
the
data
plane
they're
just
you
know,
link
local
for
the
encapsulation
on
on
the
bridge
groups
and-
and
we
separate
the
bridge
group
for
the
acp
traffic
and
then
we
do
all
the
routing.
B
And
if
these
are
real
hardware
switches
with
fast
throughput,
only
layer
2,
then
the
acp
will
be
very
slow.
That
may
be
sufficient
for
some
deployments,
but
as
soon
as
you're,
starting
all
the
cool
new
stuff
like
a
lot
of
telemetry
and
firmware
download
and
everything
else,
it
would
really
be
good
that
for
the
aggregation
and
the
access
switches
that
all
the
traffic
even
for
the
acp
would
not
have
to
be
forwarded
by
them
in
software
right.
So
traffic
from
the
call
router
to
an
access.
B
D
You
it
would
be
nice
to
do
something
else,
and
I
agree
that
we
can
create
a
layer,
two
mechanism
to
do
to
transport
data,
but
I'm
not
sure
that
that
requires
or
that
we
create
a
discovery
mechanism
at
layer,
two
or
a
mechanism
to
transport
grasp
at
layer
two,
because,
as
far
as
I
can
tell
all
of
those
devices
you're
removing
the
forwarding
requirement
from
layer
three.
D
But
I
don't
see
why
the
control
plane
that
that's
going
to
receive
and
send
grass
messages
and
other
things
why
that
isn't
has
to
be
layer.
Two.
It
means
to
me
it
could
be
layer
three
just
as
easily
and
if
you
wanna
run
our
normal
protocols,
they
pretty
much
need
to
be
layer.
Three,
don't
they
do.
We
have
a
way
to
run.
B
That
conf
over
layer
two,
I
think
I
think
this
is
this.
What
you're
saying
on
asking
now
is
a
little
bit
too
theoretically
for
me
right,
because
I'm
thinking
about
the
practical,
different
options
that
we
have,
and
I
think
two
or
three
itfs
ago-
we
also
had
a
little
bit
of
time
and
I
was
trying
to
explain
what
I
think
would
be
the
most
easy
solution
to
make
these
layer
two
switches
work
well
and
that
is
as
far
as
the
acp
is
concerned.
B
This
l2
network
yeah,
so
we
would
need
to
depend
on
the
underlying
data
plane
spanning
tree
bridging,
and
we
can
of
course
think
about
how
the
acp
may
help
to
further
protect
it
or
so
what
tricks
we
can
play.
But
otherwise
you
know
we
use
the
layer
to
a
hardware
forwarding
plane
and
all
these
hosts
just
use
the
normal
acp.
B
But
we
may
need
to
build
a
full
mesh
of
host
to
host
connections,
so
there
would
be
no
routing
across
any
of
them
and
that
I
think,
would
be
a
worthwhile
effort
and
would
make
create
a
single
acp
with
mixed
layer,
two
and
layer
three
switches
and
give
us
a
good
solution.
And
unfortunately
I
never
had
the
time
so
far
to
write
that.
D
Down
it
could
be,
it
could
be
that
they
negotiate.
You
know
vlan
495
or
something
like
this.
Yes,
they
apply
max
sec
to
it
and
they
all
look
like
their
hosts
doing.
You
know
dhcp
or
nd
or
whatever
on
it
right
and
and
that's
all,
and
I
don't
have
a
problem
with
that.
We
we
just
need
to
be
able
to
negotiate
that
clearly
with
grasp.
It's
just
a
new
transport
right.
We
have
ipsec
and
we
have
dtls
and
we'll
have
maxsec
or
vpn
or
vlan,
or
something
like
that.
B
Yeah
I
mean
we
would.
We
would
certainly
love
to
use
a
separate
vlan
for
isolating
the
acp
traffic
from
the
data
plane.
But
as
far
as
the
you
know,
crypto
is
concerned
could
still
be
ipsec.
It's
just
then
ipsec
from
a
hardware,
ipsec
capable
core
router
all
the
way
to
each
of
the
layer.
Two
devices
there
yeah
over
over
that.
B
Should
select
the
crypto
for
the
maximum
interoperability
and
performance
and
whatever
the
the
core
factors
are
right,
so
the
question
is:
do
we
need
any
new
crypto
and
the
big
reason
why
I
liked
maxic
and
still
do
like
mexico
is
when
we
really
have
these
cool
layer,
two
plus
layer,
three
switches
that
can
do
layer,
two
and
layer,
three
add
line
rate
in
hardware
forwarding
and
also
have
mac
sec
hardware
forwarding,
so
that
is
that
is
then
faster
than
ip
software
right.
B
So
if
we
have
something
that's
faster
than
ipsec,
we
should
use
it
independent
of
whether
it's
done
at
layer,
2
or
layer
3.,
but
so
far
I
think
the
starting
point
to
me
after
you
know
revisiting
mechsec
after
six
seven
years
is
it
hasn't
trickled
into
all
the
switches.
Unfortunately,
that
was
the
hope
a
long
time
ago,
but
it
still
seems
to
be
for
few
high-end
switches
only.
D
But
but
if
you
can
do
ip
second
software
for
the
traffic
for
your
own
traffic,
only
exactly
well
the
wi-fi
access
switch.
You
know
if,
if
it's,
if
it's
running
slowly,
because
it's
downloading
a
new
firmware
update.
Well,
that's
just
life
right,
but
while
it's
doing
that,
it's
not
actually
screwing
up
the
forwarding
of
traffic
for
anybody
else.
Yes,.
E
D
Agree
with
you
that
would
be
really
good
to
do.
I
I
I
still
worry
about
spanning
tree
in
a
scenario
like
this,
because
there
will
be
dead
links
and
anyone
who
has
built
us
tried
to
supply
spanning
tree,
for
instance,
to
voip.
It's
a
disaster.
You
you
can't
do
it,
it
doesn't
recover
fast
enough.
You
need
to
use
ospf
or
or
even
isis
you
just
I'm.
D
Rapid
you
get
you
get,
you
can
get
down
to
one
or
two
seconds
to
redo
a
link,
but
ospf
keeps
all
the
links
open.
E
D
B
Ripple,
our
ripple
profile
is
also
not
optimized
for
a
very
fast
convergence
speed,
but
for
for
low
load
that
we
can
support
large
networks.
So
I
think
that's
perfectly
fine
that
we're
not
getting
better.
D
E
D
Why
they've
gone
to
an
sdn
solution
that
can
redirect
it
instantly
or
to
some
other
technology
that
that
can
do
it?
Well.
B
B
Of
there
are
a
lot
of
service
provider
access
networks
from
the
dslam
to
the
core,
which
are
using
layer
2,
so
figure
figure
that
right,
so
maybe
the
voice
over
ip
does
sometimes
have
you
know
a
one
second
interruption
from
you
know
the
rapid
spanning
tree.
D
Well,
if
they
do,
then
they
they
get
the
customer
changes
isps.
I
have
experience
with
that.
D
It's
not
an
acceptable
situation
and
why
quite
a
number
of
voip
isps,
for
instance,
they
now
own
access
networks,
because
of
that
the
customer,
the
business
customers
won't
talk,
won't
tolerate
that
kind
of
thing,
but
but
back
to
our
point,
is
that
that
it's
that
the
reason
why
the
stp
might
be
off,
in
my
opinion,
is
for
other
reasons,
and
they
don't
want
to
turn
it
on
for
to
make
this
scenario
work
and
that's
why
there's
a
there's.
D
You
know
a
desire
not
to
have
anything
that
requires
broadcasts
to
work,
because
until
the
s
until
the
devices
are
connected
to
their
sdn,
the
broadcasts
are
dangerous.
Right.
D
That's
what
I'm
agreeing
saying.
I
don't
see
the
point
in
doing
that
right.
You
you,
if
you're
turning
off
spanning
trees,
because
you
want
to
turn
all
of
those
links
into
into
layer,
three
links
and-
and
you
don't
want
to
try
to
do
the
whole
thing,
and
so
you
you're
gonna,
have
layer
three
anyway,
yeah
and
and
so.
D
To
talk
about
this
because
he's
done
some
things
and
I
I
one
of
the
conclusions
I
had
in
the
document
that
I
did
on
air
2
discovery
was
that
I
finally
realized
that
we
could
do
layer
2
discovery
over
lldp,
for
instance,
even
as
originally
thought
of,
but
that
once
we
get
going,
the
the
the
acp
traffic
would
be
simply
unicast
layer,
two
traffic
from
host
to
host,
and
so
it
doesn't
it's
not
vulnerable
to
broadcast
problems,
and
you
just
need
to
suppress
neighbor
discovery.
D
B
I
think,
in
summary,
from
my
side
there
is
you
know
a
business
case
for
or
there
is,
there
is
a
an
acp
use
case.
We
haven't
solved
for
with
with
good
performance
for
layer,
two
only
switches
in
networks
where
layer,
two
only
switches
are
used.
B
What
do
we
do
with
all
of
this
stuff?
Well,
so,
first
for
for
the
for
this
draft,
I
think
we
we
have
the
ask
to
the
authors
that
are
raised,
how
they
are
looking
at
the
forwarding
plane
and
hopefully,
from
the
discussion
we
had.
They
also
have
an
an
idea
on
how
to
position
their
proposal
to
to
to
the
use
case.
Hopefully
the
explanation
of
how
the
layer
3
acp
today
works
with
existing
layer,
2
switches
and
software
is
also
there.
So
you
know
what
I
was
saying
is
is
something
that
you
know.
B
B
A
Sure,
yes,
we
have
done
very
good
discussion
here
and,
of
course,
we
don't
have
enough
time
to
discuss
everything
as
europe.
So
we
should
have
continue
our
discussion
in
the
mailing
list
and
from
this
meeting
we
will.
The
chairs
will
have
to
do
some
homework
and
also
do
the
shaffer
work
and
there
may
be
some
working
group
calls
for
the
adoption
with
we
show
some
potential
here,
robert.
J
Once
you've
finished
once
you're
finishing,
are
you
done?
I
have
done
yeah.
I
was
just
going
to
quickly
pick
up
on
some
of
the
points
that
turles
made
earlier
in
the
meeting
about
sort
of
process
thing.
I
would
like
to
encourage
folks
to
sort
of
cross
review
each
other's
documents
that
helps
them
progress
a
lot
more
quickly,
because
then
you
get
comments
and
also
you'll
help.
You
review
other
comments,
the
shepherding
role.
That
mentioned
again,
I'd
like
to
encourage
folks
to
do
that.
J
It's
a
really
great
way
to
learn
what
the
sort
of
document
publishing
life
cycle
is
and
what
the
steps
are,
and
it
gives
you
a
great
view
as
to
what
that
is
and
helps
you
when
you're
progressing
your
own
documents.
If
you
understand
what
the
steps
are
and
what's
expected
and
required,
there's
different
things.
So
I'm
sure
that
the
chairs
for
people
who
are
new
would
help
you
with
getting
started
and
there's
various
guidelines
and
I'm
gonna.
J
I
can
provide
some
help
and
pointers
for
that,
and
then
the
last
thing
that
telus
also
mentioned,
I
think,
is
really
important.
I'm
really
glad
to
see
this
slide
is
about.
If
you
can
provide
non-com
feedback
on
all
the
people,
you
know
and
the
positions
and
things
I
think
that's
really
helpful
for
nom
com
to
make
make
make
the
decisions
they
need
to
and
choose
the
right
people
going
forward.
So
again,
I
think
that's
that's
a
good
call
out
and
I
used
to
support
that
as
well.
A
Thank
you
robert.
Thank
you
all
for
your
time.
I'm
now
announce
the
meeting
close.
Thank
you
see
you
next
time,
bye.