►
From YouTube: IETF115-ANIMA-20221110-1300
Description
ANIMA meeting session at IETF115
2022/11/10 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
A
I
changed
my
affiliation
I'm
now
the
professor
in
Beijing
University
of
post
entity,
communication,
and
so
that's
made
you
your
job
I
just
start
this
August
and
and
I'm
still
here
serve
as
the
animate
here,
because
I
just
start
my
new
job,
so
I
don't
have
funding
and
they
support
to
travel
to
London
this
time.
But
it's
in
my
plan
to
Japan
next
match
so
and.
A
This
is
the
our
biscal
information
and
chair
myself
and
theories,
and
we
have
our
Eric
and
director
Robert
Wilton.
A
We
published
our
agenda
and
the
minutes
is
taken
by
myself
and
also
using
all
the
slides
already
uploaded,
and
we
have
this
video
stream
for
this
meeting.
There's
no
physical
blue
sheets.
It
will
take
according
to
the
video
stream
and
there's
no
job
Chopper
anymore,
foreign.
A
E
Yeah
yeah
so
or.
E
No,
this
is
fine,
you
you
can
keep
the
slides
and
I'll
I'll
continue.
Can.
E
Yeah
no
I,
just
from
from
the
prior
slide.
You
know
please
go
into
the
mid
Echo
tool
so
that
you're
being
counted
as
participants
in
the
working
group,
especially
when
you're
in
the
room,
because
otherwise,
next
time
there
may
not
be
enough
seats.
Although
we're
fine
right
now,
but
that's
how
you're
being
counted
by
being
in
the
mid
Echo.
E
That's
that's
the
new
thing
and
also
the
note-taking
right.
You
see
the
note
page
that
everybody
can
edit
it.
So
please
help
us
with
taking
the
notes
when
we
are
in
the
discussion
sections
of
the
different
presentations
so
that
we
capture
what's
being
done
in
the
meeting
this
time.
E
Yeah
right
so
the
the
IPR
early,
this,
the
the
IPR
disclosure,
so
we're
working
group
that
is
asking
for
IPR
disclosures
when
a
draft
is
being
adopted
by
the
working
group
and
not
only
when
it
is
released
to
the
isg,
which
is
kind
of
the
old
process,
but
I
think
now
most
working
groups
have
changed
to
the
early
IPR
disclosure
process.
Next
slide.
E
Okay,
so
when
you're
in
in
implementing
using
reading
animal
work-
and
you
are
discovering
errors-
you
know
there
is
an
error
process
to
report
errors
to
the
RFC
editor
so
that
they're
tracked
and
can
be
verified
or
rejected,
and
we
have
for
a
published
aratas
for
us.
We
have
aratas
for
four
of
the
rfcs
we've
published.
E
So
if
you're
implementing
also
be
sure
that
you
read
the
Errata
so
that
things
that
are
wrong
in
the
rfcs
that
you're
taking
that
into
account
when
you're
doing
implementations
against
them
next
slide,.
E
So-
and
here
is
the
the
set
of
the
working
group
documents,
so
we
have
nine
active
working
documents.
One
is
expired.
E
We
have
four
working
group
documents
for
which
we
have
not
received
slots
to
speak
about
them
in
the
working
group
meeting
today
and
for
one
of
them
we've
received
for
the
anima
grasp
distribution.
We
received
notification
by
the
authors
that
they
are
working
on
it
and
hope
to
have
an
update
for
the
draft
at
iitf
116
and
for
the
others.
We
haven't
received
information
about
why
they're
unchanged
from
itf-114.
E
So
if
any
of
the
authors
could
would
like
to
stand
up
now
and
say
something
about
it,
so
that
as
possible,
we
can
put
it
up
in
the
notes.
E
Let
me
just
also
take
some
time
to
get
myself
in
the
notes
section.
E
We
are
okay,
nobody
from
the
authors
here
wanting
to
say
something
about
this.
Let
me
see.
E
I'm
sorry
I'm
asking
if
there
is
any
update
on
any
of
these
three
other
drafts
with
respect
to
why
they
they
haven't,
they
didn't
seem
to
have
received
work
since
itf14-130.
A
G
G
That's
why
it's
not
changed
grasp
distribution,
I
can't
speak
to
to
to
that
work.
Are
voucher
delegation
may
or
may
not
be
irrelevant
or
uninteresting
to
anybody
at
this
point?
G
Rc8366
bis
is
still
interesting,
but
other
work
took
priority.
So
that's
why
there's?
No
no
reason
no
result
on
that,
but
as
soon
as
we
get
the
constrained
stuff
out
of
my
queue,
then
I
will
come
back
to
that
for
sure.
A
E
A
Don't
have
a
question
when
you
say
you
may
have
the
time
slots
for
the
RFC
h366
bits
do
I
mean
before
next
item
meeting.
Do.
G
I
think
we'll
work
on
it
before
115
is
your
question
seems
reasonable
to
me
that
it
will
make
progress
before
then,
as
I
mean
I'm,
assuming
that
the
constrained
voucher,
we're
going
to
finish
it
this
year
and
one
is
so
I
would
say
just
you
can't
focus
on
12
things,
you
get
nothing
done
right.
So
that's
the
major
part.
A
Okay,
then
I'll
take
your
words
as
you'll
do
something
before
next
eight
meeting
as
a
notes,
thanks.
E
Okay,
so
not
going
to
talk
about
the
draft
for
which
we
have
slots
in
this
meeting
next
slide.
B
One
question
to
yep:
thank
you,
one
question
from
Michael
Michael.
You
said
that
our
voucher
delegation
will
be
irrelevant.
Is
that
did
I
capture
that
right
or
or
was
it
just
regarding
the
state
and
Technical
content
still
will
evolve?
B
G
Tell
me
so
I
I.
We
entered
this
with
great
enthusiasm
a
year
and
a
half
ago,
or
something
and
the
use
case
came
from
a
number
of
different
places.
G
One
of
them
was
opcua
and
they've
moved
on
that
that
the
time
for
for
that
for
them
has
passed
and
the
Char
possibility
to
align
them
their
thing
that
they
call
the
voucher,
which
really
was
not
to
align
it
with
what
we're
doing
that.
We
that
Windows
go
over.
G
They
don't
have
a
lot
of
interest
in
that
they
do
need
the
assembly
process
and
they
have
an
interesting
process,
a
different
process
to
build
assemblies
which
is
very
different
than
what
we
did,
and
so
their
interest
in
that
is
is
gone
now,
Stefan,
so
I
know
you
have
some
other
interest
within
Siemens
for
some
of
this
stuff,
and
so
I
would
say
that
you
need
to.
G
We
need
to
figure
out
what
remains
from
that
part,
and
it
may
or
may
not
be
relevant
anymore
is
what
I'm
trying
to
say
Stefan.
G
That
that
I
think
that
that
this
is
this
is
this
is
work
that
has
value
but
I
just
don't
know
that
we
actually
have
a
customer
for
any
of
it
and
I
don't
see
a
point
in
spending
a
lot
of
time
doing
a
lot
of
things.
If
there's
in
fact
nobody
that
presently
needs
it
right.
Okay,.
B
E
A
A
E
But
Shane
I
think
if
the
the
Siemens
folks
want
to
reinvestigate
what
they
want
to
get
out
of
it
and
then
basically
we
we
work
to
make
sure
that
it
does
solve
that
remaining
use
case.
Then
we
can
continue,
but
otherwise,
if
if
we
don't
have
a
customer
representation
here,
then
maybe
we
declare
that.
G
Yes,
yeah
I
think
it's
okay,
if
it
dies,
we
don't
have
to
probably
every
document
that
we
we
thought
was
a
good
idea
at
one
point
that
they
could
be
come
silly.
The
problem
space
till
like
problem
save
still
exists.
How
do
I
resell
a
device
securely
and
how
do
I
build
an
assembly
of
devices
which
results
in
a
new
device
which
I
sell,
and
this
document
actually
didn't
solve
that
second
problem
very
well,
and
it
may
be
that
the
first,
the
way
it
solved
the
first
problem
was
was
broken.
G
So
I
would
say
that
we
need
to
have
more
more
interaction
with
end
customers
to
be
more
precise
about
what
they
need
right
and
I'll
also
say
that
some
of
the
some
of
the
desires
here
came
out
of
the
reviews
of
of
of
brewski
about
being
unable
to
do
these
things
and
I.
Don't
know
some
of
that's
water
under
the
bridge.
At
this
point
right.
A
E
Right
thanks
next
slide,.
E
Okay,
so
this
is
unchanged
text
right,
so
please
make
sure
that
when
you're
getting
with
your
documents
closer
for
an
intended
working
group
last
call
that
you
did
have
enough
reviews
on
the
document
and
one
way
to
achieve
that
is
to
offer.
E
You
know
in
return
reviews
for
other
authors
documents
so
that
we
don't
have
to
struggle
with
the
working
group
last
call
and
documents
that
haven't
seen
enough
good
reviews
on
them,
and
we
also,
of
course,
always
have
the
earlier
reviews
so
especially
try
to
figure
out
which
of
the
other
directorates
iot
directorate,
for
example,
security
directorate,
the
Yang
doctors
and
so
on,
may
need
to
review
the
document
anyhow
because
it
does
affect
security,
iot
cases
and
has
young
models
in
it,
just
as
an
example
and
make
sure
that
if
that
hasn't
been
done,
that
you'll
you'll
contact
us
chairs
and
we'll
help
to
put
those
early
requests
into
the
queue
for
the
document.
E
We
we
mentioned
that
every
time
and
if
your
document
still
is
missing
in
Shepherd,
please
you
know
look
around
from
for
the
other
authors
who
you
think
not
being
a
co-author
on
your
document
might
be
good.
A
good
catch
and
contact
us
contact
us
cheers
next
slide.
E
Okay,
so
this
these
these
meetings
of
narash,
because
we
have
a
lot
of
items
to
work
on
and
then
a
good
amount
of
processes
to
deal
with
that.
If,
if
you
feel
that
your
document
would
need
more
time
for
a
discussion,
then
please
bring
it
up
on
the
mailing
list.
Talk
with
the
chairs,
it's
always
not
difficult
to
set
up
interims
when
enough
people
are
interested
to
spend
more
time
on
individual
subjects
next
slide.
E
We
obviously
already
have
a
weekly
ongoing,
really
good
discussion
team
for
most
of
the
brewski
documents
and
we'd
invite
you
to
also
join
that
meeting
to
to
discuss
your
brewski
work
when
you're
not
doing
that
already
next
slide
and
yep,
we
we
don't
have
an
official
ITF
GitHub,
but
pretty
much
all
of
the
anima
documents
and
the
individual
contribution
documents
proposed
for
anima
are
in
the
nmrwg
GitHub
and
when
you
want
to
contribute
new
new
work,
we
also
suggest
you
to
just
get
invited
to
that
GitHub
and
put
your
documents
into
that
as
well.
E
All
right
and
I
think
that
is
the
end
of
the
chair,
slides
and
please
go
to
the
the
note
page
where
we
we
have
the
the
agenda.
So
that
would
bring
us
to
slot
number
two,
which
is
an
update
on
the
constraint.
Brewski
join
proxy
and
that
should
be
Michael.
Then
presenting
and.
E
I
think
that's
what
I
was
trying
to
tell
you
why
yeah
wait
a
second,
so
I
was
here
once
Frank
brewski.
Just
give
me
a
second
foreign.
H
G
Thank
you
oh
this
is.
This
is
esco's
talk,
where's,
Esko,
you're,.
E
I
E
F
A
I
A
Do
have
the
agenda,
but
yeah
you
have
to
copy
that
paste
that
to
the
web
browser.
Then
you
can
say
that
in
the
meeting
notes.
E
I
I
I
So
this
repeats
a
figure.
From
a
while
ago,
already
2018
there
was
a
request
for
working
group,
adoption
of
constraint,
voucher
and
some
very
nice
Graphics
to
go
with
it.
So
this
says
need
to
fix
names
here,
so
that
I
think
we
have
some
new
naming
by
now.
But
for
the
rest,
it's
still
yeah
still
valid
okay.
So
we
have
a
long
history,
but
it's
still
progressing.
It
holds
time
not
very
quickly.
So
next
slide
please.
I
So
we
just
tell
you
what
happened
since
the
last
times
we
presented
to
recap
the
goal.
Basically,
we
would
like
to
have
a
brewski
bootstrap
solution
and
one
that
works
for
constrained
devices
and
constrained.
Networks
I
can
take
this
off
I
think
yeah,
so
it's
suitable
for
wireless
six,
open
mesh
networks,
but
also
for
other
types
of
constrained
Networks.
I
So
key
differences
are
that
it
uses,
for
example,
cob
and
DT.
Less
instead
of
https
has
cos
azine
sieber
instead
of
CMS
sign,
Json
uses
constrained,
EST
Co-op
s.
This
is
already
another
RFC
and
in
general
we
want
to
over
want
the
overheads
of
messages
and
options
to
be
minimized.
So
that's
good
for
constraint,
implementations,
so
they
need
less
code
and
the
networks
need
to
transport
less
data.
If
we
do
that,
okay
next
slide.
I
So
now
we'll
go
by
the
previous
versions
that
we
made
this
one
is
still
from
February.
I
might
have
already
been
discussed
in
the
previous
ITF
meeting,
just
as
a
recap.
So
what
we
did
is
we
clarified
their
values
for
the
assertion.
Fields
basically
derives
from
Yang
enum,
but
it's
good
to
make
That
explicit
for
for
those
people
who
are
not
completely
up
to
speed
with
Jiang.
I
We
did
some
editorial
updates
and
also
we
did
an
update
of
the
brewski,
well-known
URI
super
registry,
so
we
proposed
to
add
a
new
column
there,
which
is
done
to
be
applied
by
Ayana
in
the
end.
Okay,
next
slide
we
had
a
version
17
with
some
small
changes,
so
particularly
saying
how
we
amend
the
brewski
RC
and
also
a
new
section
was
added
in
security
considerations.
I
And
then
version
18
appeared,
so
we
have
there
the
number
assigned
to
the
content
format.
So
it's
application,
slash,
voucher
codes,
a
plus
c
bar,
and
also
some
Discovery
extensions
were
added.
So
there
was
a
lot
of
the
recent
discussion
was
on
Discovery.
I
I
So
I
also
implementations
have
been
made
over
the
past
years
and
we
did
interrupt
between
them,
and
this
slide
just
lists
the
implementations,
some
with
a
little
bit
of
detail
and
some
links,
you
can
go
to
the
materials
and
click
on
them
to
see
where
that
code
is
located.
I
I
And
then,
specifically
on
my
own
implementation,
there,
it's
the
second
bullet
I.
Also
yeah
would
like
to
mention
that
it's
also
meant
to
be
a
framework
to
be
integrated
into
automatic
testing,
which
means
that
it
can
not
only
produce
the
correct
formats
for
vouchers
certificates,
Etc,
but
also
produce
some
incorrect
formats
on
purpose
just
to
test
compliance
of
devices
through
that,
so
to
check
that
devices
being
tested
will
actually
stop
the
bootstrap
process
or
throw
the
appropriate
error
message.
I
So
this
says
demo
I'm,
not
sure
if
we
have
actually
have
time
for
a
demo,
it's
just
very
short.
I
can
but
I
have
to
share
my
screen
to
do
that
and
as
we
know
it
can
take
a
minute.
I
Let's
see
if
that
works,
then
then
we'll
just
okay,
then
it's
first
okay,
then
I'll
just
ask
to
share
screen
it's
now
unshared,
so
the
request
has
been
made
now.
I
think
the
shares
could
have
to
press
accept
for
that.
I.
I
I
Okay,
I
can
only
share
a
window,
it
seems
no
that
was
blocked
in
the
whole
screen,
so
I'm
just
sharing
this
window.
You
see
some
Java
code
here,
let's
see,
is
it
readable
at
all
yeah?
This
is
just
to
show
there's
a
list
of
tests
on
the
left
with
a
lot
of
green
bars.
I
So
the
code
here
that
you
see
will
test
multiple
pledges,
so
it
basically
has
a
loop
to
create
pledges.
I
Okay,
yeah
I
can
see
the
cursor,
so
it
creates
a
number
of
pledges
and
then
starts
them
almost
all
together
and
then
it
waits
for
each
pledge
to
finish.
Each
pledge
will
internally
have
code
to
perform
a
bootstrap
process,
so
that's
also
a
way
to
test
the
concurrency
of
the
server
in
a
very
simple
way,
and
there
are
a
couple
of
tests
like
this.
I
So,
every
time
we
hit
some
interrupt
issue
like
weight,
you
did
not
use
that
flag
in
the
certificate
or
in
the
voucher
then
well,
we
can
add
a
test
here
that
tests
a
specific
situation
and
then
yeah
to
see
that
the
register
of
the
miles
home
handles
the
the
case
correctly
is.
E
This
now
you
know
all
your
Commissioners
is
actually
including
testing
of
some
of
the
other
implementation
code
that
you
listed
as
a.
I
Interval
yeah:
this
is
using
only
let's
say
my
code,
which
is
actually
forked
from
the
open
thread.
Project
I
should
say
so.
That's
where
it
started.
There's
an
open
source
project,
but
I
basically
made
my
own
Fork
to
develop
further.
So
it
does
not
test
any
of
the
all
those
codes,
but
you
could
basically
use
the
software
components
to
yeah
access
other
people's
code,
so
maybe
I'll
just
quickly
try
to
share
another
tab.
I
I
I
I
I
Yeah
open
issues
and
next
steps,
so
we
do
keep
the
GitHub
issue
tracker.
So
that's
the
main,
let's
say
indicator
of
open
issues
that
we
use
at
the
time
of
writing.
There
were
about
12
or
13
issues
open,
so
we
have
also
interrupt
issues
and
future
labeled
issues.
These
are
not
really
counted
for
the
documents
and
yeah,
there's
just
I
think
three
important
ones.
The
first
one
is
to
check
all
the
examples
these
are
now
outdated.
So
we
have
to
check
examples
against
the
running
code
to
make
proper
real
examples.
I
Also,
in
the
document
and
I
think
the
discovery
section
still
needs
a
bit
of
update
to
match
the
new
constraint
joint
proxy.
That
Michael
will
talk
about,
and
there
was
one
discussion
item
that
I
opened.
So
it's
a
possibility
to
optimize
optimize
for
constraint,
networks
to
so
reduce
the
data
size
by
yeah,
excluding
one,
the
root
CA
shirt
in
the
handshake
of
the
Pledge,
so
that
was
an
also
GitHub
issue
opened
for
that,
but
that's
open
for
discussion.
I
So
it's
proposal
or
basically
how
data
can
be
reduced,
with
the
assumption
that
the
register
has
root
CA
certs,
already
pre-loaded
of
all
the
devices
that
it
wants
to
onboard
in
its
Network.
E
So
I
see
from
a
year
or
more
ago,
three
early
reviews,
iot
dear
exact
year
in
gen
heart,
and
they
said
it
wasn't
ready.
So
do
you
feel
that
all
their
concerns
have
been
resolved.
I
Yeah
I
think
at
the
time
we
opened
a
couple
of
issues
on
that
on
GitHub.
I
think
these
are
now
closed
or
as
far
as
I
can
see
so
I
did
not
actually
check.
That's
yeah
those
feedback,
emails
but
I
think
Michael
opened
at
the
time
lots
of
issues
for
those
and
one
by
one.
We
have
resolved
them.
I
E
Questions
who
has
read
the
latest
version
of
this
draft.
H
E
Okay,
not
very
many
yeah,
so
try
to
find
more
reviewers.
That's
the
usual
thing
right,
I.
E
G
I
decided
to
dress
for
the
dance
working
group,
which
is
next
so
there
you
go.
Oh
yeah,
all
right,
yeah
sure
you
can
go
next
slide.
So
this
this
document
went
through
to
through
working
group.
Last
call
I
would
say
even
was
it
I.
G
Even
before
the
previous
ietf
and
then
went
out
to
the
Ayanna
for
expert
review,
specifically
on
the
topic
of
the
co-op
pieces
and
the
expert
reviews,
reviewers
were
a
little
bit
displeased
with
our
use
of
Co-op
discovery
and
I
guess
in
September,
I.
E
G
Maybe
it
was
beginning
of
middle
of
October.
A
few
weeks
ago
we
had
a
cult,
a
core
working
group
discussion
about
that
and
it
overflowed
into
the
iot
Ops
working
group
because
they
were
in
fact
they
were
scheduled,
one
on
top
of
each
other
in
Virtual,
in
virtual
interims
and
since
we're
all
going
to
the
other
one
that
we
just
did
that
there
and
the
overall
thing
was
the
question
became
well.
Why
is
the
join
proxy
format
where
we
went
from
previously?
G
We
went
from
bistoc
seabor
to
a
encrypted
bit
of
seaboor,
and
then
the
question
was
well.
Why
exactly?
Is
it
not
just
a
co-op
header
and
I
said
well,
because
I
thought
that
we
were
going
to
blow
too
many
bytes
doing
that
and
the
response
says?
Well,
you
don't
need
this.
G
So
the
short
of
is
that
we
changed
it.
So
this
this
slide
really
just
talks
to
you
about
what
it
looks
like
in
grasp
and
there
are
several
different
ports
that
are
returned
next
slide.
Please.
G
E
G
So,
as
I
said
so
previously,
we
had
this
thing
on
the
upper
left,
this
this
built-up
structure.
Then
we
said
well,
let's
encrypt,
that
in
one
one
four
and
now
we
said:
let's
just
make
it
a
co-op
header
now.
Actually
this
is
wrong.
The
document
is
wrong.
When
arguing
specifically
the
proxy
scheme,
option
which
says
Co-op,
we
believe
that
we
don't
even
need
so
that
actually
saves
another
six
bytes.
G
The
end
result
is
that
the
cost
of
making
it
a
co-app
header
versus
making
it
this
crafted
cddl
in
the
upper
right.
It's
actually
only
two
bytes
two
bytes
extra
to
make
it
a
co-op
header
and
make
it
all
look
same.
So
what
I'd?
Like
the
working
group
we
I've
published
this
document.
G
G
Yeah,
so
that's
basically
it
what
we've
done.
It's
a
it's.
G
A
large
change
to
the
document
at
a
very
late,
State
and
I
would
say
the
implementers
are
like
whatever
we
had
six
changes,
what's
one
more
right,
but
this
at
least
makes
the
core
working
group
and
the
expert
reviewers
happy
and,
as
I
said,
it
cost
us
two
bytes
and
it
now
it
looks
kind
of
really
really
just
correct,
and
the
other
interesting
thing
is
that
it
aligns
it
pretty
much
perfectly
with
RFC
9031,
which
has
OS
core
security
and
no
ttls
and
Rob.
Thank
you.
C
So
that's
just
sort
of
like
a
process
question
really
so
I'm
trying
to
understand
sir
Robertson
6
and
80..
At
the
moment
it's
on
my
sitting
on
my
pad
of
things
with
an
ad
I
can't
say
this
is
85
or
something
does
this
need?
Another
working
group
last
call
should
I
formally
return
this
document
back
to
the
working
group
to
last
call
again:
do
you
think
that's
I
I,
don't
quite
like
the
scope
of
the
changes
you
sort
of
describe
makes
me
think.
Another
last
cause
probably.
G
G
But
we
have
to
come
back
to
the
working
group
with
this,
so
so
that
if
you
go
look
on
the
data
tracker,
you
will
see
the
diffs
because
I
posted
a
new
version.
Okay.
But
if
you
go
look
in
the
GitHub
you'll
see,
there's
three
stacked,
pull
requests
that
make
all
these
changes.
So
if
you
want
to
come
back
and
see
exactly
what
the
changes
are
they're
there
in
the
GitHub
and
you
could
we
can
Wordsmith
them
or
whatever
you.
G
Someone
wants
to
do
that
way,
but
I
didn't
feel
that
it
was
right
to
merge
it
until
you
know
the
working
group
had
a
comment,
but
on
the
other
hand
you
can
just
go.
Look
at
the
document
and
you'll
see
the
the
diff
you
know
makes
it
very
clear.
What's
going
on
for
that,
so.
E
G
C
F
G
And
I
I
would
appreciate
chairs,
if,
if
you
establish,
if
you
did
this
quickly
and
we
I
would
like
to
get
this
off
of
our
plate,
you
know
before
people
disappear
into
Christmas,
eggnog
or
whatever.
E
So
is
there
any
good
marketing
for
this
other
than
we
kind
of
got
derailed
into
this,
because
we
started
using
Co-op
Discovery
and
then
we
got
all
these
Co-op
experts
and
they
wanted
us
to
do
co-op
headers
and
now
it's
just
two
bytes,
but
is
there
any
other
benefit.
G
We
we
are
reusing,
so
if
we
assume
that
the
join
proxy
is
in
fact
an
iot
device
that
otherwise
speaks
co-app,
that
we've
just
removed
a
bunch
of
bespoke
custom
code
and
we're
now
using
the
common
Co-op
code,
so
I
that
might
actually
represent
a
code
savings
but
particularly
the
join
code
is
there.
G
You
better
maintained
is
what
I'm
trying
to
say
right.
So
the
other
thing
I'll
say
is
that
so
Panos
is
one
of
the
co-authors
and
he's
still
around
he's
still
doing
cfrg
stuff.
He
doesn't
have
a
lot
of
Cycles
for
this,
but
Peter
has
really
declared
himself
as
really
really
retired,
so
I'm
the
only
author
standing.
So
please,
please.
Your
comments
will
be
welcome.
Yep,.
I
Yeah,
let's
go
Dyke
yeah
I
agree
with
what
you
said
about
Co-op,
so
you
kind
of
reuse
a
code
base
that
is
presumably
already
going
to
be
on
the
device
yeah.
That's
the
idea,
the
constrained
device
yeah
one
thing
is
that
it
does
have
some
impact
on
the
behavior
of
especially
the
forwarding
so
with
the
old
protocol.
Basically,
the
yeah.
I
I
Yeah,
that's
right,
but
you
still
get
to
response.
So
it's
not
an
acknowledgment
about
every
request
also
gets
a
response,
so
even
the
non-confirmable
ones,
but
the
good
news
is,
you
can
suppress
it.
So
you,
basically
the
server
side
could
decide
to
just
like
generate
the
response
and
throw
it
away
immediately
like
hey,
it
was
lost
and
that's
that's
kind
of
allowed
in
non-confirmable
Co-op.
I
So
that's
something
we
could
do,
but
it
is
something
to
address
I.
Think
to
to
look
at
that.
We
don't
want
that.
2.04
response
message
coming
back
because
it
care
it
has
no
value
in
our
case,
I.
Think.
G
So
so
I
thought
we
got
it
right
in
RFC,
9031
that
there
isn't
a
response.
You're
telling
me
different,
so
I'll
go
back
and
review
the
two
things
and
I
may
ask
you
to
confirm
my
understanding
at
that
point.
I
Yeah
so
yeah
the
thing
is
with
with
Co-op.
If
you
have
confirmable,
then
you
will
get
an
acknowledgment
to
the
message
and
usually
the
acknowledgment
and
the
response
are
combined
in
one.
So
it's
the
most
efficient
way.
I
But
if
you
do
not
have
the
acknowledgment,
you
can
still
get
the
response.
So
that's.
G
See
Marco
back
there
who
might
be
an
expert
she's,
looking
he's
looking
like
no,
so
we
so
90
31
said
confirmable
and
I
just
copy
and
pasted
that.
But
that
sounds
wrong
now.
If
it's
confirmable.
I
G
I
So
it's
non-confirmable,
that's
fine,
I!
Think
that's
a
good
way
to
do
it,
but
you
still
get
this
normally
this
thing
with
Co-op
that
it
also
generates
a
response.
If
you
have
a
request
right.
G
H
C
So
Rob
Wilson
just
going
to
Echo
in
the
comments
that
tell
us
made
it
earlier
that
this
and
this
worker
is
called
across
smaller
numbers
of
people
and
I.
Think
there's
a
couple
of
documents
here
that
haven't
had
that
many
reviews
in
this
one.
So
you're
now
the
only
author.
So
it's
just
a
working
group
if
they
want
to
get
these
documents
to
sort
of
make
progress,
it
needs
more
sort
of
cross
review
from
other
people.
C
So
yeah
I
really
encourage
people
who
are
working
in
this
stuff
in
this
working
group
to
try
and
cross
review
each
other's
work,
because
otherwise,
when
it
gets
to
the
isg
in
those
other
reviews,
it
gets
slowed
down
to
get
a
lot
more
comments.
The
more
you
get
done,
the
working
groups,
the
easier
the
path
is
later
on
yep.
F
E
All
right,
then,
I
think
we're
up
to
an
autonomic
mechanism
for
resource
based
Network
Services
Auto
deployment.
The
authors
have
done
an
update
since
itf114
and
I.
Think
Sheng
will
want
to
give
the
presentation.
A
Actually,
we
already
changed
the
title
a
little
bit
foreign,
a
couple
of
new
words:
one
is
the
generic
to
emphasize
the
generalization
of
this
mechanism
beyond
the
quality
translation
services-
and
we
add
another
word
management
to
emphasize
the
dynamical
autonomic
management.
Besides
the
autonomical
deployment
at
the
beginning
of
the
services.
A
This
time
we
actually
already
largely
rewrite
the
description
text
without
changing
the
document
structure
and
the
purpose
of
this
document.
We
update
the
out
deployment
and
management
process
of
the
quality
Network
transmission
services.
A
A
F
A
This
mechanism
is
generic
for
most
resource-based
network
service.
It
can
be
easily
extended
to
support
many
Network
Services
scenario,
including,
but
not
limited,
difference,
Transmission,
Service,
in-network
cache
or
storage
Services
Computing
Services,
Information
Services.
However,
those
services
are
only
listed
in
this
document.
The
detailed
supports
for
those
services
are
out
of
scope
for
this
single
document.
A
We
change
the
one
step,
discover
the
ASA
to
into
a
two-step
Discovery
process.
It
can
discover
the
relevant
nodes.
First
then
discover
the
resource
manager
ASA
on
those
nodes.
Of
course,
it
can
combine
a
bike
as
one
step
when
they
they
are
actually
deployment
in
the
autonomical
networks.
It's
the
deployment
choice.
A
A
The
server
service
responsor
should
check
the
authentication
of
the
service
initiate
and
the
authorization
information
and,
however,
this
document
assumes
all
autonomic
nodes
within
the
automation.
Network
domain
have
been
authenticated
and
their
request
operation
are
authorized,
giving
the
prayer
condition
the
sap
and
risky
hence
provides
this
secure
environment.
A
We
also
add
a
new
step
to
emphasize
the
releasing
of
resources.
It
must
be
done
during
the
service,
ending
the
search
ending
could
be
lifetime
out
or
the
service
initiator
notification.
A
To
generalize
the
the
purpose
of
also
the
resource
manager,
so
we
actually
update
the
grasp
objective.
We
use
new
parameters
to
identify
our
service
service
type
and
service
ID.
We
also
added
the
service
lifetime.
They.
A
A
Now,
with
all
these
comments,
we
receive
this
meeting
and
in
two
weeks
time,
I
guess
we
both
updates
the
process
of
the
quality,
Network
transmission
service,
automatic
deployment,
the
service
initiator
discover
up
service
pass
because
normally
this
transmission
service
is
from
a
source
to
a
destination
which
pass
many
Network
nodes,
but
they
are
owing
a
pass,
so
the
task
should
be
discovered.
First,
then,
the
service
initiator
know
all
those
nodes.
A
The
resource
manager
is
on
the
service.
Initiator
negotiates
the
resources
with
the
okay
resource
manager,
Asus
and
the
service
responsors
one
by
one,
but
it
normally
a
specific
network
service
should
have
only
one
service
initiator
within
a
autonomical
network
domain
I
mean
for
specific
network
service.
A
After
the
negotiation,
the
SE,
the
resource
manager
is
a
service
responses
also
on
the
service
initiator
reserves,
the
local
resources,
those
resources
can
be
dynamically
changed.
We
have
that
description
in
the
document
here.
We
also
give
a
example
of
negotiation
process.
Those
numbers
are
actually.
A
Yeah
we're,
as
we
said,
we
add
two
new
subfields
service
type,
with
two
initial
value.
Missing
four
bits
is
enough
for
those
different
service
type,
because
that
can
can
give
us
16.
the
resource
type.
For
now
we
have
the
batteries
Q
memory
priority
cache
Computing.
A
For
now
we
think
four
bits
given
the
16
value
space
is
big
enough,
but
if
experts
will
need
more
space
reserved
space
like
eight
bits,
we
are
happy
to
change
that
yeah.
Last
slides,
The,
Next
Step.
Welcome
to
the
comments
contributions,
reviews
as
Warren
said
Robert
said
we
always
look
for
reviews.
A
So
all
kinds
of
reviews
are
welcome.
We
will
continue
to
refine
the
contents.
We
also
have
a
implementation
plan
using
patient.
Hopefully
we
could
download
by
the
end
of
this
year.
So
that's
one
and
a
half
months
time
we
are
targeting
for
working
group
last
call
after
next
IDF
Wellness
X
by
the
way
Michael
Rich
your
successful,
successfully
confused
me
because
this
meeting
is
115
and
next
is
116
right.
A
I
It's
codec
here:
I
had
one
question:
yeah
just
wondering
about
the
overall
security
model,
since
the
driver.
I
That
all
initiators,
for
example,
have
to
be
authenticated,
and
it
also
says
that
they
are
authenticated
at
the
moment
that
they
join
this
yeah.
Basically,
ACP
I
think
it's
called
right
or
the
autonomous
Network
management
plane.
Basically.
H
I
Maybe
I
missed
that
part
of
the
working
groupies
there's
some
some
common
assumption
that
okay,
once
the
device
gets
kind
of
onboarded
onto
the
management
plane,
you
can
just
you
know,
stay
authenticated
for
the
rest
of
the
lifetime
or
or
do
we
need
some
additional
protection
and
to
to
verify
that
this
message
was
actually
coming
from
who
it
was
coming
and
that
it
was
genuinely
coming
from
that
device.
I
E
I
I
think
that
if
we
rely
on
the
ACP,
then
all
the
communications
that
you're
doing
through
the
ACP
will
have
effectively.
You
know
your
authentication
on
The
Binding
of
the
IP
address
to
the
certificate
and
if
you
would
be
using,
you
know
just
brewski
without
the
ACP
and
you
have
the
connectivity
and
you're
doing
this
type
of
service
enrollment,
then
I
think
it
would
have
to
be
through
the
brewsky
certificate
in
your
end-to-end
TLS
connection,
as
the
Authentication
that
part
I
guess
this
document
doesn't
say
because
I
don't
think.
E
In
general,
we've
tried
to
figure
out
how
to
you
know,
suggest
more
lightweight
service
provisioning
without
the
ACP,
but
I
think
that
would
be
the
obvious
way.
Just
do
you
have
the
connectivity
as
then
the
question,
but
with
the
ACP
it
is,
it
is
all
derived
from
the
Broski
certificates,
but
then
you
also
have
the
secured
reliable
connectivity.
F
E
A
Yes,
thank
you.
Your
questions
are
really
valid,
but
actually
it's
out
of
this
scope.
We
just
noticed
in
this
document
say
it
has
to
at
least
must
actually
use.
The
word
must
be
authenticated
and
authorized,
but
how
to
do
that?
It's
out
of
scope.
J
Yeah
so
hope
you
can
see
the
slides
so
good
afternoon.
This
is
a
quick
update
to
the
jws
and
science
vouchers
draft
so
which
is
also
running
for
several
months
already,
and
so
this
update
does
not
contain
any
yeah
new
content.
It's
just
about
yeah
restructuring
or
rewriting
to
make
it
ready
for
working
group
last
call
so
yeah.
What
is
it
about?
So
we
are
specifying
here.
J
Another
voucher
format,
so
in
form
of
jws
Json
generic
serialization
So
based
on
I
would
see
75
15,
and
so
there
are
no
young
changes
and
yeah
I
said
for
from
previous
version:
zero
four
to
zero.
Five.
Now
we
have
updated
examples
in
the
appendix
we
have
a
yeah
yeah,
big
restructuring
and
section
three,
so
also
the
Prototype
objects
and
figures
are
updated
and
some
editorial
improvements
to
the
whole
document.
J
What
else
yeah?
Of
course,
we
have
a
PLC
implementation
for
that,
also,
together
with
Broski
PRM,
which
Stephen
will
report
later.
We
have
implemented
this
voucher
approach
and
format,
and
we
would
be
happy
for
interop
testing
with
other
parties
for
sure.
Unfortunately,
still
a
Shepherd
is
missing,
so
would
be
also
good
if
they
are,
somebody
would
volunteer-
and
last
point
is
so
the
authors
agreed
so
that
this
document
is
now
ready
for
working
group
last
call
and
we
would
bring
it
in
the
next
step
here
and
that's
it
I
think.
E
Thank
you,
yeah.
Any
questions.
E
See
anything
this
this
jws
right
so
I
mean
this.
This
is
a
something
where
what
you
find
some
you
know
good
additional
reviewers
from
the
application
area.
That
is,
that
is
dealing
with
these
jws
things.
Normally,
there
is
anything
like
you
know,
an
a
review
from
App
area
or
so
specifically
for
that
jws
context.
I'm
just
you
know,
thinking
about
the
experience
we
made
with
the
co-op
folks
that
you
know
during
Ayanna
review
that
tell
us
how
to
use
their
headers
better.
So.
F
E
Sense
to
to
to
send
a
request
for
for
review
to
the
Jose
working
group
here.
E
B
Okay,
so
I
would
like
to
give
an
update
about
rusky
with
splatron
responder
mode
test.
Thomas
already
said
so
we
are
in
version
05
now
and
there
is
a
repository
available
online
working
group
GitHub,
and
we
tracked
the
issues
there
and
there's
all
there
are
also
the
latest.
Now
the
the
latest
source
of
the
document
is
there
what
we
have
referenced
here.
B
That's
also
a
reference
that
we
provide
in
brewski
PRM
is
the
general
architecture
or
an
abstract
protocol
overview
about
the
architecture,
so
just
to
recap
what
what
rusky
PRM
is
doing
differently
compared
to
brewski
rusky
PRM,
essentially
reverses
the
direction
for
client
and
server
between
the
pledge
and
the
registrar
agent,
the
registrar
and
is
doing
that
by
introducing
a
new
functionality
which
we
call
registrar
agent,
the
registration
itself
may
be
a
standalone
component
or
a
separate
component,
or
it
may
be
part
of
the
functionality
of
the
of
the
domain
registrar.
B
So
it's
essentially
triggering
the
pledge
to
perform
certain
actions
like
creating
a
voucher
request
or
creating
an
enrollment
request,
and
then
the
registrar
gets
back
to
the
to
the
the
registrar
agent
gets
back
to
the
to
the
registrar
and
does
the
interaction
with
the
back-end
infrastructure
in
the
name
of
the
pledge.
B
So
here
nothing,
nothing
really
has
changed.
We
have
some
some
further
tweaks
down
here,
which
I
will
come
to
at
the
next
slide.
So
you
see
that
there
is
some
exchange
between
the
registrar
agent
and
the
domain
registrar
further
into
the
backend
infrastructure,
and
once
this
is
done,
all
the
different
objects
that
have
been
collected
by
the
registrar
agent.
So
that
means
a
voucher
and
also
the
the
enrollment
response.
B
Essentially
the
certificate
and
also
the
ca
certificates
are
provided
to
the
pledge
and
the
pledge
can
consume
all
those
data
objects
and
can
then
operate
in
the
Target
domain.
B
So
what
has
changed
from
last
version
to
this
version?
We,
meanwhile
had
a
couple
of
reviews.
So
in
summary,
we
have
seven
different
reviewers,
which
are
not
all
of
them
are
stated
yet
in
the
in
the
draft.
So
that
is
one
thing.
I
I
still
have
on
the
table
to
to
put
the
names
of
the
reviews.
In
there
the
review
led
to
several
technical
clarifications
to
some
enhancements.
B
B
So
specifically,
we
have
included
as
mandatory
now
a
signature
on
the
voucher,
so
that
means
once
a
voucher
has
been
issued
by
the
Maza
and
comes
back
to
the
through
the
registrar
and
through
the
register
agent
down
to
the
to
the
pledge,
the
registrar
in
between
has
to
provide
a
medicinal
signature
on
the
on
the
voucher,
so
that
additional
signature
provides
a
proof
of
possession
of
the
private
key
where
the
pledge
has
seen
the
the
certificate.
B
So
that
means
the
public
key
during
the
triggering
of
the
of
the
registration
at
the
beginning,
and
that
additional
signature
is
some
kind
of
yeah.
Explicit
authorization
store
the
vote
from
one
hand
and
on
the
other,
that
terminates
the
professional,
except
from
the
on
the
pledge
side
of
the
registrar
certificate.
B
So
that
has
been
discussed
in
the
design
team
and
also
been
included
in
the
in
the
document
now.
So
we
also
defined
a
new
endpoint
for
pledge
bootstrapping
status
inquiry,
so
we
had
already
status
messages
in
the
same
way
as
they
were
defined
in
brewski.
So
that
means
we
had
a
status
message
for
that
that
we
provided
from
The
Pledge
back
to
the
registrar
agent
once
a
voucher
has
been
supplied
and
also
once
a
enrollment
response.
So
the
certificate
has
been
replied.
B
There
was
some
requests
to
provide
an
additional
specific
endpoint
to
inquire
the
status
of
the
The
Pledge
in
in
case
that,
for
instance,
a
service
technician
is
stepping
by
and
may
not
know
if
the
pledge
has
been
bootstrapped
already
or
if
the
pledge
is
in
some
kind
of
intermediate
state
of
bootstrapping.
B
So
for
this,
the
endpoint
and
also
the
messages
and
the
error
codes
have
been
defined.
Regarding
error
codes,
we
have
some
thanks
to
ESCO.
We
had
some
some
more
integration
of
error,
code,
search,
more
fine-grained
or
to
enable
them
or
fine-grained
handling
of
arrows.
That
may
happen
during
the
bootstrapping
we
put
in
some
some
clarification
regarding
the
knowledge
of
the
marzers
that
is
necessary
for
verifying
the
ldf
ID
that
comes
in
the
voucher
request
from
The
Pledge,
so
the
lfid
from
the
registrar
agent
and
also
the
lfid
from
the
registrar.
B
So
we
we
require,
meanwhile,
that
they
have
to
be
under
the
same
administrative
control.
So
that
means
that
another
needs
to
process
a
corresponding
issuing
or
root
certificates
already
to
be
able
to
verify
the
different
data
pieces
in
the
voucher
request
and
based
on
that
issue
assertion
or
an
agent
proximity.
B
So
then
we
enhance
the
security
consideration.
So
there
were
some
questions
regarding
potential
Tech
scenarios
and
they
have
been
clarified
and
also
the
Privacy
configurations
have
been
enhanced
for
last
Point.
Regarding
the
enhancements
here
is
the
registrar
agent
certificate.
We
had
that
in
the
pledge
trigger
as
optional
component
included,
and
we
decided
to
basically
drop
that
because
it's
being
provided
in
the
registrar
created
voucher
request
where
the
pledge
voucher
request
is
part
of
that
register.
B
Auto
request,
and
we
would
we
we
saw
that
because
it's
optional
from
from
The
Pledge
side,
it
is
it
it
complicates
the
handling.
So
we
would
like
to
have
some
simplification
there
and
to
also
save
bandwidth
between
the
pledge
and
the
registrar
agent.
B
So
those
were
merely
the
technical
points
that
have
been
addressed,
and
then
we
had
some
further
clarifications
and
editorial
improvements,
and
they
relate
to
a
lot
of
terminology
like
enrollment
objects,
certification
object,
so
we
aligned
that
type
of
terminology.
B
B
We
also
clarified
that
the
registrar
needs
to
verify
the
response
messages
that
that
come
from
The
Pledge
and
match
them
to
the
audit
logs
that
he
gets
from
the
Mazda
also
in
during
the
bootstrapping
phase,
so
that
is,
there
is
no
no
deviation
to
brewski
it's
more
or
less,
emphasizing
that
this
is
a
requirement
on
the
registrar.
B
We
also
clarified
that
the
pledge
user
created
on
time
from
the
Dutch
vulture
request
trigger
object
that
he
gets
from
the
registrar
agent
in
the
cases
where
there
has
been
no
time
synchronization
been
done
before,
then
we
also
removed
the
reference
to
the
cap
Forum.
That
was
not
needed
anymore,
so
we
we
basically
dropped
that
reference.
B
Then,
regarding
the
general
structure
of
the
document,
we
completely
restructured
Section
5,
to
make
it
better
readable
and
to
better
have
a
red
line
throughout
the
document.
So
I
hope
that
that
simplifies
the
the
reading
of
the
document,
and
in
that
context
we
also
reword
all
the
different
prototypes
that
we
had
in
the
different
sections
there
for
the
prototypes
itself.
We
now
have
an
appendix
that
lists,
different
examples
for
the
for
the
objects
that
we
have
and
also
includes
size
information.
B
That
was
one
of
the
issues
or
one
of
the
points
that
has
been
raised
because
we
one
intention
of
boost
kprm
is
also
to
allow
for
different
transport
means
between
the
pledge
and
the
registrar.
So
that
means
we
don't
necessarily
rely
on
protocols
like
like
TLS
or
TCP.
Since
we
have
the
security
handling
on
the
objects
itself
and
in
certain
scenarios
we
can
utilize
the
brewski
PRM
approach
based
on
Bluetooth,
for
instance,
Bluetooth,
slow
energy,
and
for
this
it
is
interesting
to
also
list
some
message:
sizes
in
the
appendix
okay.
B
So
far
for
the
for
the
update
from
the
o4
version
to
o5
I
set,
the
the
discussion
on
the
different
issues
is
is
available
on
the
animal
site,
so
the
the
remaining
the
only
remaining
open
Point.
That's
not
a
remaining
open
point
for
for
booski
PRM
Standalone,
but
for
all
the
different
documents
that
Define
vouchers.
B
There
is
some
definition
or
some
clarification
ongoing
on
the
young
usage
there
that
relates
to
augmentation
of
the
young
documents
that
we
have
there
to
enable
the
combination
of
different
drafts
that
we
currently
have
that
relate
to
the
voucher
handling.
So
that
is
an
issue
that
Michael
took
over
and
that
basically
needs
to
be
applied
to
all
of
the
different
anima
documents,
defining
vouchers.
B
Then,
as
as
Thomas
already
said,
we
have,
since
we
are
utilizing
the
jws
voucher
heavily
within
Broski
PRM.
So
the
the
jws
format
approach
we,
we
have
a
proof
of
concept
for
for
the
implementation
available,
that's
available
for
all
of
the
different
components.
If
there
is
interest
to
do
interop
testing,
please
get
in
touch
the
the
addresses.
B
The
contacts
are
available
on
the
first
slide,
as
in
the
last
working
group
meetings,
the
document
Shepherd
is
still
needed
for
the
document,
and
here
we
are
in
the
same
situation
as
for
jws
voucher.
From
the
answers
perspective,
we,
after
the
the
review
of
seven
different
persons.
We
now
have
addressed
all
the
different
issues
except
the
first
one.
So,
besides
that
the
authors
agreed
that
the
document
is
ready
for
working
group
last
call,
so
that
would
also
end
my
my
information
or
my
update
about
boost
key
PRN.
Any
questions.
E
Yeah,
thank
you
very
much.
Let
me
see
if
there.
F
E
Any
other
questions,
so
if
the
open
issue
is
is
clear
in
the
document
somehow
then
I
think
before
we
go
to
working
group
last
call.
Maybe
we
want
to
consider
an
early
review
from
I
guess
there
is
a
Yang
usage
right,
so
the
young
doctors,
and
so
we
do.
We
think
that
the
security
aspects
are
relevant
to
us
for
early
Security
review,
I
mean
we've
I.
B
Yeah
I
think
it
would
be
good
to
have
to
have
some
Security
review
as
early
review.
I.
Think
that
that's
probably
fine,
the
the
person
said
that
the
review
so
far
were
all
experienced
regarding
security,
but
I
think
it's
good
to
to
have
already
the
first
review
from
from
the
security
Community
there.
Regarding
the
young
doctors,
we
we
had
an
early
review
which,
from
The
Young
doctors
at
the
very
early
stage
of
the
document.
Since
then,
the
voucher
itself
hasn't
changed.
B
Much
and
I
think
we
should
do
that
once
we
have
the
clarification
on
the
young
usage
to
avoid
any
problems
with
augmentation
of
the
voucher.
C
J
E
Okay,
I'll
trigger
the
two
early
reviews.
What's
the
plan
to
get
the
these
Yang
issues
resolved,
it
seems
to
be
for
the
the
augmentation
stuff
who's
who's,
leading
that
whom
are
you
waiting
for
I,
guess,
Michael.
E
G
Yeah
I'm
dressed
for
the
dance
meeting,
there's
other
reasons
yeah,
so
the
augmentation,
so
he'll
go
go
back
to
the
beginning.
I
just
looked
at
my
inbox,
beginning
of
August
to
the
mailing
list,
I
posted
the
Lost
efforts
and
Jan
lindblade
told
me
how
I
did
it
wrong
and
I
just
need
to
repeat
that
and
I
was
just
trying
to
figure
out
whether
I
can
do
that
tomorrow
afternoon,
whether
I'm
weak
enough
and
so
we'll
get
that
I'll
get
that
cleared
out.
G
I
said
I'd
get
that
cleared
out
for
this
meeting
and
I.
Think
we
can.
We
can
do
that.
The
the
big
concern
is
that
that
we
got
something
wrong
in
8366
and
we
have
to
revise
that.
That's
the
big!
The
big
worry
is
that
we
can't
combine
things
and
if
you
go
back
to
that
document
or
that
emails
and
that
thread,
if
I
can
post
repost
it
or
I
will
repost
it
tomorrow,
then
you'll
understand
what
I'm
thinking
about
right.
G
So
I
know
that
Stefan
you
have
it
it's
just
really
for
the
rest
of
the
other
people.
We
just
need
to
do
the
simplest,
stupidest
experiment
of
combining
things
from
different
places
and
see
that
we
can
do
it
and
that
we
didn't
make
a
we
didn't.
Do
the
Yang
wrong
and
from
what
I
the
feedback
I
got
is
that
we
maybe
need
to
do
it
slightly
differently.
So
we'll
see.
F
Someone
had
was
behind
me:
oh
oh,
okay,
that
guy
just
disappeared.
All
right.
I
thought
he
was
getting
the
mic
thanks.
E
D
Great
yeah
so
today
I'm
going
to
to
give
an
update
on
brewski
AE
the
changes
between
version
two
and
three
next
slide.
Please,
as
you
recall,
whose
GE
is
invariant
of
brewski,
that
uses
an
alternative
protocol
in
rather
than
EST.
D
So
what
you
see
in
the
orange
dot
marked
box
is
any
certificate
enrollment
protocol
that
has
self-contained
signed
objects,
but
a
requests
which
then
supports
end-to-end
security
for
the
certification
requests
and
there's
good
news
on
the
document,
because
now
we
have
two
more
reviews.
Actually
three
one
was
removed,
internal,
the
other
one
was
by
Michael
and
another
one
was
by
a
Shepherd
or
less
I'm.
Very
glad
that
we
have
these
reviews
in
place
now,
and
this
gave
valuable
feedback
which
I
and
the
other
co-au
authors
implemented
in
the
text.
D
So
we
did
several
editorial
changes
and
also
clarified
various
requirements
which
were
kind
of
implicit,
so
nothing
surprising
but
still
good
to
to
state
them.
Clearly
and
I
can
best
show
this
at
the
picture
itself,
namely
on
the
left
hand
side.
You
can
see
the
messages
going
from
pledge
to
the
registrar
and
on
this
channel
we
of
course
reuse
the
existing
TLS
Channel,
and
what
we
didn't
mention
so
far
is
that
the
enrollment
protocol
that
is
being
used
here,
of
course,
needs
to
support
this.
D
D
So
of
course
we
need
to
use
the
same
protocol
in
order
to
have
the
end-to-end
property
that
we
are
after
and
another
pretty
obvious
thing
is,
of
course,
that
register
needs
to
support
at
least
one
such
enrollment
protocol
with
a
self-signed
objects
for
the
requests,
and
the
first
fourth
thing
was
yeah
that
the
registrar
itself
May
already
do
part
of
the
of
the
domain
of
the
registration
Authority
if
functionality
or
it
may
delegate
part
of
this
or
all
of
this
to
an
upstream
array
component,
which
is
somewhere
else
in
the
pki.
D
D
I
already
mentioned
the
various
clarifications
that
we
did
in
the
document,
and
here
I
only
wanted
to
mention
that
we
did
quite
a
number
of
small
editorial
improvements,
for
instance
on
the
comparison
between
plain
brewski
and
brewski,
also
a
better
differentiation
of
the
various
flavors
of
Ras,
for
example,
local
Ras
and
register
and
pki
side
Ras
in
the
back
end
and
a
better
description
of
offline
message,
transfer
versus
synchronous
with
the
transfer
and
so
on.
So
not
really
a
big
technical
issues,
but
just
for
better
readability.
D
Some
various
improvements
and
one
further
thing
that
happened
in
the
meantime
is
I
reached
again
out
again
to
Elliot
Lear
about
his
contribution
of
EST
full
CMC,
and
it
turned
out
that
he
simply
doesn't
have
time
to
follow
up
on
this
and
apparently
the
interest
also
diminished.
Somehow,
so
we
agreed
that
he
would
drop
off
as
a
co-author
and
now
he's
listed
as
a
contributor,
and
we
have
left
out
the
details
of
EST
full
CMC,
which
were
anyway
not
finished
at
all.
D
So
the
focus
of
the
document
is
meanwhile
that
is
CMP.
Instantiation,
but
of
course,
we
do
mention
that
there
is
the
possibility
to
plug
in
other
certificate,
enrollment
protocols
that
also
offer
the
self-signed
and
not
the
sales
entities
designed
self-contained
request
objects
for
getting
the
end-to-end
property.
D
So,
to
sum
up,
all
open
points
that
have
been
open
recently
have
been
resolved.
Meanwhile,
there
is
a
POC
implementation.
We
have
the
decision
on
to
remove
the
EST
full
CMC
flavor
instantiation
of
risky
AE,
and
we
have.
We
got
a
working
group
review
by
Michael
and
we
got
the
Chevrolet
review
by
tallest
and
though
we
will
leave.
The
document
is
now
ready
to
work
in
group.
Last
call
okay.
As
far
as
that
was
my
presentation,
and
do
you
have
comments
on
this
or
questions
now
about
the
last
call.
E
Yeah
I
think
the
typical
thing
in
terms
of
any
earlier
reviews
that
we
would
like
to
do
security,
for
example,
not
sure
if,
if
that
should
be
done
or
in
parallel
or
before
working
group
last
call,
but
I
think
we
could
as
well
unless
there
are
opposing
opinions.
Start
working
group
last
call
with
this
one
I
mean
at
least
from
the
shepherd's
side.
I'm
fine
with
that,
but.
E
I'll
discuss
with
Shang
on
the
share
side.
D
E
Okay,
great
so,
where
are
we
I?
Think
we're
at
the
end
of
the
working
group
draft
I
think
Michael
was
saying
that
he
would
like
to
have
some
minutes
on
the
the
hackathon
which
I
consider
to
be
somewhat
related
to
working
group.
So
I
wanted
to
make
sure
that
we
spent
the
time
first
on
that
one.
G
So
what
I
want
to
talk
about
was
the
hackathon
VPN,
which
brewski
implementers
have
tried
to
use
over
two
years.
I,
don't
know
if
we
ever
got
it
ever
working
I
know
Peter
tried
and
I
tried,
and
it
worked
for
a
while.
So
I
had
a
couple
meetings
with
Charles
eckel,
the
hackathon
guy,
and
we
then
met
with
the
ietf
knock
and
they
would
love
to
do
all
sorts
of
things
for
us
and
but
the
choices
we
just
like
it
to
work.
G
But
but
essentially,
what's
going
to
happen
is
that
if
you
have
or
want
to
buy
like
it's
a
20
Euro,
20,
Microtech
Rider,
the
smallest
one,
they
have
will
run
the
lttp
stuff,
and
then
you
wind
up
with
a
a
Wi-Fi
and
an
Ethernet
which
is
essentially
layer,
2
bridged
to
the
hackathon
network,
at
which
point
you
can
plug
in
whatever
physical
devices
or
thread
gateways
that
you
want,
and
they
said
that
we
might
even
we
probably
can
have
DHCP
V6
prefix
delegation
as
well.
So
you
get
a
prefix
for
your
802.154
network.
G
As
they
take
their
equipment
out
of
the
rack
and
ship
it
to
the
ITF
and
for
about
10
days
after
the
ITF,
so
it
will
actually
probably
work
I
think
they
said
it
will
work
well,
the
itf's
going
on,
which
is
maybe
less
interesting
for
remote
people
who
are
physically
present
right
so
but
between
ietfs.
We
can
have
a
network
that
we
can
do
things
and
we
can
do
all
of
the
mdns
grasp
Etc
type
discoveries,
because
it's
a
layer,
2
Network,
that
we
want
to
be
able
to
test
so
I.
Think.
G
G
What
happens
is
that
when
you
don't,
when
their
equipment
is
being
shipped,
you
wind
up
with
you
wind
up
with
a
VPN
that
appears
to
be
up,
but
it's
not
connected
to
anything
right
and
so
I
presume
sometime
in
in
a
week
or
so
in
10
days
or
so
it'll
just
start
working
again,
as
they
say,
they'll
turn
it
back
on
and
they've
considered
other
ways
of
doing
this,
including
the
possibility
that
during
ietf
week,
we
would
be
able
to
just
essentially
turn
on
anything
anywhere
and
we'd
be
able
to
get
onto
that
Network
and
it
would
work
I,
don't
think
that
was
as
important,
because
I
think
we're
almost
all
too
busy
to
during
the
week
to
actually
do
any
work.
G
It's
afterwards,
so
I
just
wanted
to
let
the
recruit
the
group
know
this
and
I
mean
I
had
a
Raspberry.
Pi
is
what
the
previous
generation
of
it
was.
That
was
harder
to
use,
and
although
I
had
some
reservations
about
GPL
compliance
of
Microtech,
routers
I
was
happy
to
just
pay
20
some
units
for
a
tiny
little
device
that
just
seemed
to
work.
So
that
was
it.
Okay.
E
Thank
you
so
is,
is
Roland
in
the
room,
yeah,
so
I'm
happy
to
revert
our
slots
because
I
I
don't
have
high
priority
and
Reviving.
My
drafts
I
put
them
on
the
agenda,
but
let's
go
first
with
the
yokira
thing.
Yeah.
K
So
I'm
Ron
bless
from
kit
and
yeah.
This
is
Joint
work
with
Machina
Zoran
Arturo,
so
I'd
like
to
introduce
briefly
skira
Kira,
which
is
a
scalable
ID
based
routing
architecture
for
control
plane.
So
quite
a
nice
fit
for
anima
here,
I
think
and
its
name
is
comes
from
kademia
directed
ID
based
routing
architecture.
I
don't
have.
K
Okay,
so
what
Kira
aims
at
is
interconnecting
large
pool
of
network
resources
being
compute
storage
Network.
What
have
you?
It
provides
a
resilient
connectivity
for
the
control
plane
so
that
the
controllers,
like
sdn
controllers,
that
control
our
sdn
switches
Can
exert
their
control,
and
we
also,
since
we
are
ID
based.
We
provide
stable
addresses
for
moving
resources
like
virtual
machines
that
move
or
drones
whatever
you
next
slide.
K
So
what
it
provides
is
massive
scalability,
so
we
scale
to
100
thousands
of
nodes,
it
is
zero
touch
requires
no
configuration.
K
It
is
quite
fast
in
conversions,
it's
Loop
free,
even
during
convergence,
which
is
also
nice
for
robustness.
It
is
works
well
in
many
different
topologies,
so
we
call
this
topological
versatility.
So,
instead
of
having
specialized
variants
for
let's
say
denser
data
center
topologies,
we
we
don't
need
that
so,
and
we
also
aim
for
efficient
routes.
But
connectivity
is
first
so
to
say
so.
K
There's
this
related
work
for
sure,
but
they
either
like
one
or
the
other
property
and,
for
example,
Ripple
here,
which
would
cause
traffic
concentration
near
the
route,
and
it's
probably
not
really
zero
touch,
since
you
always
have
to
say
what's
the
root
node
I
mean
so
next
slide,
please
yeah.
So
the
main
concept
is
that
we
have
two
tiers.
One
is
the
routing
tier
where
the
routing
protocol
lives,
which
we
call
Art
you
cat
and
the
other
one
is
the
forward
interior.
K
So
the
routing
tier
provides
uses,
ID
based
addresses
and
it
uses
Source
routes
and
works
on
top
of
any
link
layer.
K
While
the
forward
interior
can
be
seen
as
some
kind
of
optimization,
so
we
try
to
get
rid
of
source
routing
due
to
the
overhead
and
the
path
ID
based
forwarding
is
some
kind
of
label
switching
approach
that
simply
reduces
overhead
next
slide.
Please
so
I
will
talk
briefly
about
r2cap
next
slide,
so
the
main
idea
is
that
we
need
some
kind
of
path
Discovery.
K
So,
in
order
to
find
path
through
our
Network
since
we're
unknown
environments-
and
so
here
we
have
a
simple
topology
consisting
of
the
the
white
node
white
bullets
here
and
the
white
dots.
So
this
is
a
link
layer,
topology
and
each
node
simply
creates
randomly
a
node
ID,
which
can
be
seen
as
the
the
uppercase
letters
in
the
the
blue
dots
here
in
the
blue
circles.
So,
moreover,
every
node
learns
it's
through
a
vicinity.
K
So,
for
example,
here
x
learns
the
contacts
which
we
call
them.
The
circle
also
calls
in
Academia
this
way
a
y
b
and
M
next
slide.
Please.
K
So
now
how
can
XR
learn
a
path
to
Z,
so
the
approach
is
basically
to
construct
underlay
routes
by
using
the
node
ID
based
Olay.
So
the
source
route
to
the
context
that
is
the
closest
to
the
destination
already
is
simply
used
as
next
top,
and
if
we
mention
closeness,
we
need
some
kind
of
metric.
That
shows
us
what
is
close
to
each
other
and
we
are
using
the
Excel
metric
from
cademia
for
that.
K
K
K
So
in
order
to
find
a
path,
we
usually
send
so-called
find
node
requests
out,
and
so
here
the
final
request
that
that
eventually
arrives
at
Z
will
record
the
complete
route
that
the
pagal
travels,
and
this
naturally
incurs
some
path
stretch
so
that
it's
not
necessarily
the
shortest
route
and
also
here
it
contains
a
cycle,
but
we
can
get
rid
of
the
cycle.
So
next
slide,
please.
K
So
the
answer
picket
usually
eliminates
already
that
cycle
and
later
Breakers
can
even
do
better.
So
in
the
sense
that
x
no
is
a
shorter
route
to
M.
So
it
can
take
a
shortcut
so
that
reduces
stretch-
and
in
case
you
have
or
I
can't
afford
to
have
stayed
for
later
packets.
Then
you
can
achieve
lower
stretch
release.
Moreover,
archicad
offers
a
flexible
memory
stretch
Trader
of
due
to
its
routing
table
design.
The
next
slide
please.
K
So
the
routing
table
is
basically
the
same
as
in
Academia,
so
it's
arranged
by
the
xor
distance,
so
we
have
buckets
of
fixed
sizes,
usually
of
a
small
number:
okay
equals
20
or
40.
K
So
that's
a
the
bucket
size
limit
and
the
bucket
the
bucket
here
and
the
the
topmost
bucket
here,
the
the
gray
one
that
contains
the
context
G,
for
example,
that
that
holds
all
the
contacts
from
half
of
the
ID
space,
which
could
be
quite
large
and
in
that
case
that
that
the
the
ID
was
overlay
needs
always
to
or
is
based
on
the
property
that
you
know
your
ID
wise,
neighbors,
there's
a
certain
strategy
that
causes
buckets
to
split
once
they're
full
in
case
they
are
in
your
ID
wise
vicinity,
so
lower
buckets
usually
contain
your
ID,
wise
neighborhood.
K
So
what
we
do
now,
in
addition
to
that,
is
that
we
call
the
Discover
path
as
path
vectors
for
each
contact,
and
we
can
do
so
in
a
way
that
we
prefer
always
shorter
routes
and
that
leads
to
efficiently
learning
the
shortest
path
to
the
context.
The
size
of
the
buckets
is
choosable
so
per
on
a
per
node
basis,
so
in
case
your
node
can
afford
more
memory.
K
K
So
with
respect
to
Dynamics,
we
assume
that
we
have
some
kind
of
detection
of
node
link,
Theory
and
the
underlay,
and
then
we
have
it
performing
a
two-step
strategy.
The
first
one
is
that
we
inform
the
ID
wise
Neighbors
about
the
Fate
link.
Here,
for
example,
X
informs
Y
and
Z
about
the
failing
next
slide.
K
Please,
and
so
the
second
step
is
to
ReDiscover
a
alternative
path
via
the
Ola
strategy
that
I
just
explained,
but
this
time,
including
a
not
via
information
telling
other
nodes
that
may
not
hurt
over
the
broken
link
that
they
cannot
use
path
that
contain
the
broken
link
and,
furthermore,
periodically
since
it's
not
guaranteed
that
the
routing
updates
or
that
information
about
the
broken
linger
spread
over
the
all
nodes
that
need
that
information.
K
You
just
checked
regularly
whether
the
path
to
your
contacts
work,
and
you
also
have
to
look
up
your
own
node
ID
in
order
to
keep
the
overlay
together
and
to
detect
Network
partitioning,
for
example,
and
we
ensure
the
validity
of
the
routing
information
by
using
State
sequence,
numbers
and
also
path
information
ages.
Next
slide,
please.
K
Yeah,
so
briefly,
what's
it
about
the
the
path
ID
based
forwarding
next
slide,
please.
So
there
are
many
backup,
slides,
don't
worry,
and
so
the
forwarding
tier
now
tries
to
get
rid
of
the
source
router
for
the
control
plane
packet.
So
in
case
we
want
to
ask
this
H
to
our
router.
K
So
the
the
approach
here
is
to
replace
the
source
routes
with
so-called
path
IDs
and
the
path
ID,
basically,
is
just
the
hash
of
the
node
IDs,
the
source
route,
and
so
the
path
ID
is
used
as
labor
for
the
source
route
and
then,
basically,
we
do
some
label
switching
between
the
nodes
and
the
the
reason
why
we
need
the
two
of
the
physical
vicinity
which
isn't
actually
required
for
the
routing
protocol
safe.
But
here
for
the
path
ID
forwarding
it's
nice
because
we
can
pre-calculate
the
path.
K
K
So
we
implemented
a
thing
and
showed
that
it
works
on
top
of
IPv6
packet
format,
so
we
just
provide
IPv6
connectivity
out
of
nowhere
so
to
say
with
Kira,
and
then
the
data
packets
can
use
the
faster
forwarding
in
the
forwarding
tier,
which
requires
a
node
ID
based
forwarding
table
and
a
path
ID
based
forwarding
table
and
in
order
to
use
path,
IDs
in
addition
to
the
node
IDs,
we
simply
use
GAA
encapsulation.
So
there's
one
additional
header
for
that
path
that
you
based
forwarding
in
the
current
scheme,
and
so
your
control
plane
app.
K
K
So
this
slide
shows
its
performance
in
various
topologies
of
site
of
10
000
nodes,
and
what
you
can
see
here
is
that,
for
example,
the
average
multiplicative
stretch
along
the
y-axis
one
of
the
different
topologies
are
along
the
x-axis
and
the
first
packet
stretch
for
the
first
packets
that
we
need
for
pop
Discovery
is
are
the
Green
Dots
here,
and
you
can
see
that
it's
even
lower
than
the
ACP
variant
of
Ripple,
so
we're
not
doing
the
so
bad.
K
Even
while
we're
doing
overlay
based
routing,
more
or
less
and
also
the
blue
triangles
here
are
showing
that
the
pay,
the
thresh
for
the
later
crickets
can
be
even
lower.
And
the
really
nice
thing
is
that
in
all
topologies
we
learned
the
shortest
path
to
all
the
contexts
that
we
know.
So
you
always
have
shortest
path
in
your
own
routing
table.
But
in
order
to
get
to
other
nodes
that
you
don't
know,
you
have
to
at
least
have
some
stretch
right.
K
So
next
piece,
yeah
and
dynamic
wise.
We
are
also
doing
quite
well
so
in
100,
000
topology,
when
15
of
15
or
the
links
fail
randomly
and
simultaneously,
which
is
quite
a
large
outage.
K
I
would
say
you
see
that
it's
able
to
get
back
to
nearly
100
delivery
ratio
for
the
control
packets
and
also
then
for
the
data
packets
a
little
bit
later
within
10
seconds
roughly
and
the
overhead
is
small,
so
we're
not
flooding
right
so
due
to
the
small
size,
routing
tables,
we
can
do
quite
well
with
the
overhead
of
the
the
whole
protocol,
so
we
have
here
nearly
80
packets
in
average
per
node
per
second
that
is
sent
in
that
kind
of
failure.
Next
next
slide,
please
yeah,
sir.
K
That
concludes
already
my
talk.
Sorry,
there
are
more
backup,
slides
in
case
you're
interested.
There
will
be
a
site
meeting
today.
So
at
seven
in
lesson,
9
12
here
there's
a
small
room,
so
Kira
is
actually
designed
for
large
provided
domains.
It's
could
be
a
replacement
here
for
ripple
in
the
ACP,
but
we're
not
standardized
yet.
So
the
idea
is
to
start
that
off
here.
So
I
have
to
to
write
internet
drafts
and
design
packet
formats
here
and,
and
so
on.
K
Ripple
was
designed
for
iot,
so
QR
was
not
designed
for
IIT
in
mind,
but
for
fixed
networks,
basically,
but
I
guess
we
can
tweak
also
to
that
we
simply
use
Link
local
addresses,
as
I
said,
so
that
can
be
used
out
of
the
box.
In
that
sense,
the
nice
thing
is
that
it
offers
more.
It
offers
integrated
DHT
for
simple
name
resolution
services
and
Discovery,
and
that
could
lead
to
a
more
efficient
and
simplified
Discovery
than
with
grass.
When
you
do
with
your
graph.
K
It
also
supports
multi-path,
routing
and
forwarding
due
to
the
path
IDs,
for
example,
and
it
also
supports
scalable
and
efficient
topology
Discovery.
So
you
within
five
seconds,
you
can
basically
discover
100
000
nodes
topologies
with
nearly
100
of
all
the
links
in
five
seconds.
So
that's
kind
of
amazing
yeah.
That's
that's!
It.
K
E
Much
any
questions
Michael.
G
K
Yeah
I
mean
yeah,
there's
I
I
want
to
just
see
whether
there's
interest,
what
people
think
about
it,
whether
it's
useful
I
think
for
future
networks.
We
need
some
kind
of
robust
control,
plane
connectivity,
because
you
you
know
that
that
people
misconfigured
bgp
at
meta
and
then
they
lock
themselves
out
of
their
own
control
plane.
That
is
impossible
with
gear.
In
that
sense,
in
case
you
have
physical
connectivity,
you
will
get
there
right,
and
so
that's
really
a
robust
way
for
your
control
playing
connectivity.
K
So
yeah,
the
idea
is:
maybe
I
don't
know
if,
if
I
think
I
have
to
to
write
IDs
first
and
then
maybe
next
time
we
can
have
a
buff
official,
buff
I,
don't
know
so
so.
But
it's
not
you.
Sorry,
it's
not
useful
unless
you
have
key
run
all
your
resources,
so
that's
of
course.
Of
course
we
need
to
standardize.
G
It
okay,
so
so
so
we've
had
two
thoughts.
One
one
was
that
so
ACP
you
know
is
intended
to
run
over
secure
overlay.
We're
using
you
know,
point
to
point
out
every
sec,
one
of
the
you
know
one
of
the
pathologies
when
we
have
Layer
Two
connectivity
that
doesn't
participate
in
the
ACB.
G
Excuse
me,
one
of
the
pathologies.
Is
we
formed
too
many
too
many
adjacencies
right?
If
you
have
a
layer,
two
switch
that.
G
Is
that
you
wind
up
with
this
mesh
and
it's
silly
right,
because
you
just
don't
need
everything.
On
the
other
hand,
if
you
have
actual
real,
you
know
devices
separated
by
cities
and
stuff,
then
the
connectivity
really
makes
sense,
and
you
you
have.
You
have
the
right
things,
but
despite
that,
what
we
don't
have
in
Ripple
at
this
time
is
any
kind
of
reasonable
origin
authentication.
So
we
have
all
the
security
we
have.
We
know
which
node
has
which
I
p
address.
G
We
even
have
certificates
with
that
attest
to
that,
but
a
routing
protocol
actually
makes
no
use
of
that
fact
to
to
make
sure
that
our
our
control
plane
does
hasn't.
Part
of
it
hasn't
gone
bad
and
it's
not
just
a
to
my
mind,
a
question
of
a
defense
against
maliciousness,
but
it's
a
defense
against,
as
he
said,
Facebook
or
Rogers
in
Canada
had
a
worse
meltdown
on
July
8th.
G
They
didn't
just
Knock
Lock
themselves
out
of
data
centers.
They
they
just
posted
their
entire
control,
plane
to
the
point
where
they
couldn't
even
phone
each
other
up.
G
Fix
it
because
their
phones
didn't
work
right,
but
you
know
it
would
be
nice
if
that
was
also
if
that
security
was
also
providing
for
defense
against
misconfiguration,
and
so
that's
something
I
would
really
be
excited
to
about.
The
other
part
I
wanted
to
win
is
it
sounds
to
me
like
we
could
run
Ripple
and
Kira.
G
At
the
same
time
now
we
don't
have
a
big
installed
base
of
of
ACP,
but
imagine
if
we
did
right
that
finding
those
those
cross
links
and
not
going
through,
as
you
said,
going
through
the
knock-
would
be
an
interesting
thing.
Well,
you
know
I
mean
I,
don't
know,
maybe
some
synergies
here
that
make
that
makes
it
worthwhile
or
maybe
a
stupid
thing
to
do
just
wasting
more
time.
K
A
G
It's
it's
not
the
Integrity.
We
have
that
part.
It's
the
this
route
really
did
originate
from
the
that
node
right.
That's
that's
the
thing
it's
that
so,
like
you
know,
right
now,
we
have
you
know
in
bgp
right
we
have
our
pki,
but
what
we're
missing
is
Route
authentic
origin.
K
E
Yeah
I
have
one
question
too.
The
what
I
was
missing
was
a
little
bit
better
understanding
the
forwarding
plane
that
you
get
ultimately
right.
The.
D
E
E
Okay,
so
you
have
on
one
segment,
you
have
some
okay,
Jerry
is
just
one
of
your
choice
is
the
choice
that
you
came
up
with
yeah.
K
E
The
GRE
key
as
the
the
key
is
the
path
ID
or
which.
E
K
Yeah
you
can
so
the
path.
Id
concept
is
basically,
we
are
capable
of
using
multiple
path.
Ids
you.
So
you
can
do
multi-path
routing.
If
you
want.
E
To
no
no
I'm
saying
that
to
get
to
a
particular
destination,
how
many
you
know
steering
points?
Do
you
need
across
the
network.
F
E
K
Yeah,
okay,
okay,
I,
see
I
see
is
here
yeah,
so
so
it
depends
on
the
on
the
topology.
So
the
larger
your
topology
is
the
longer
the
the
the
higher
the
number
of
intermediate
jobs
that
you
need
and
that
grows
logarithmically
with
the
size
of
the
network.
Typically.
E
Fairly
clear
that
by
using
Source
routing
and
having
you
know
an
incremental
set
of
source
routes
that
help
you
to
get
closer
to
the
destinations,
one
of
the
cool
ways
on
how
we
can
achieve
you
know
better
than
what
Ripple
does
but
I
think
that's
exactly
the
stuff
that
we
want
to
review
and
what?
What
also
I
think
the
forwarding
planes
that
have
this
ability,
like
mpls
or
srv6
or
obviously
Ripple-
has
it
in
in
its
way
too,
although
they're,
using
it
differently
right.
But
all
these
Source
routing
headers
might
be
exactly.
K
So
so
we
are
currently
trying
to
optimize
a
bit
on
the
path
ID
forwarding
requiring
fewer
entries
in
the
intermediate
hubs,
but
we
didn't
so
we
have
the
concept,
but
we
didn't
program
it
into
the
simulation.
So
we
want
to
have
a
better
understanding
how
many
following
entries
are
actually
required
in
the
worst
case
and-
and
that
is
I
mean
we're-
we
are
very
scalable
and
the
control
plane
of
Kira
itself.
So
let's
say
about
on
the
data
plane
for
keyword.
We
need
to
figure
that
out,
but
it
doesn't
seem
too
bad.
E
Who
had
a
really
good
routing
idea
got
his
own
working
group
right?
So
if
you
work
hardwood
yeah.
E
F
E
Very
much
okay,
I
think
we've
reached
the
end
of
time.
Shane
do
you
want
to
close
it
down.
A
Yeah
we
finish
our
working
group
document
update.
We
still
don't
have
enough
time
for
the
non-working
group
documents,
including
two
from
Terrace.
Whatever
we,
the
first
working
place
for
IDF
working
group
is
the
main
list.
Please
do
invoke
the
discussing
email
list.
That's
all
from
today,
thanks
for
you
all,
hopefully
see
you
in
Japan.