►
From YouTube: ROLL WG Interim Meeting, 2020-09-30
Description
ROLL WG Interim Meeting, 2020-09-30
A
B
A
In
the
chat
is
the
editor,
but
so
please
you
can
join
welcome
to
the
meeting.
Please
be
aware
that
this
beauty
is
aligned
with
the
notebook,
the
meeting
materials,
the
other
path.
A
This
is
the
agenda
for
today,
so
we're
going
to
go
through
the
statues
and,
what's
going
to
happen
with
rolling
the
idea
179,
the
progress
of
the
rpc
is
giving
a
pascal,
then
the
updating
capabilities
by
raoul,
and
then
we
are
going
to
discuss
how
these
ripple
version
2
topics
microphones.
We
update
the
the
milestone
for
about
richard
and
working
group
for
close
to
la
next
year
and,
of
course,
we
probably
have
to
get
there.
A
C
If,
if
that
was
the
agenda
bashing,
I
would
like
to
bash
the
agenda.
Okay,
yeah.
I
would
like
to
to
see
if
we
can
steal
a
little
bit
of
time
from
the
repository
to
give
it
to
me.
Yes
for
the
pizza,
because
a
lot
of
things
happen,
they
would
like
to
steal
like
25
minutes
no
problem.
We.
A
This
is
no
problem,
yeah,
okay,
about
the
milestones.
Okay,
we
probably
have
to
update
these
updates.
We
have
updated
myself
so
about
the
state
of
the
active
internet
traffic,
how
they
be
ripple
and
still
notice.
We
got
a
new
version,
but
still
some
reason
have
to
be
handled
there.
Probably
you
have
a
new
version,
the
introduction
we
are
going
to
discuss
today.
This
modification
is
a
step.
It's
a
working
progress.
A
Video
is
in
the
rpc.
Thank
you.
Another
priority
was
a
new
version
and
we
are
looking
for
a
previews
for
workplaces
where
we
have
an
innovation
density.
Extension
is
a
the
shepherd
document.
Central
triple
observation
active
turn
off
recent
iec
evaluation.
You
know
you
have.
The
update
today
is
an
award
link
as
well.
These
are
people
informed
we
updated,
and
I
have
to
update
the
thief
documents
and
when
I
update
it,
we
can
ship
to
alvaro
to
continue
the
process,
but
I
need
to
complete
this
tip
and
then.
D
A
D
Can
you
maybe
try
to
speak
close
of
the
mic
to
overcome
the
noise?
We
know
you
have
some
noise
issues,
but
custom
thing
can't
hear
you.
Okay,.
A
A
A
A
C
So,
thank
you
enough.
Can
you
please
move
one
slide.
C
C
C
But
it
was
very
hard
to
to
say
that
correctly
in
a
draft,
because
for
in
the
one
hand
we
appear
to
be
changing,
rfc6550
ripple
because
ripple
never
said
that
there
is
a
time
bomb
in
how
long
the
the
flags
are
available,
and
so
there
was
nothing
that
said
that
for
certain
mobs
those
flags
would
be
variable
and
for
other
maps
the
flags
would
not
be
defined
anymore.
C
So,
just
adding
this
capability
to
put
a
time
bomb
on
the
flags
flags
seem
to
be
a
update
to
rfc6550
and
then
how
to
express
it.
Whether
there
was
a
need
to
do
some
changes,
etc,
that
wasn't
clear,
and
it's
not
just
this
draft.
It's
also
unaware
leaf,
and
it's
it's
also
use
of
ripple
info
and,
as
you
know,
user
info
is
actually
the
first
in
line
it's.
C
It
should,
and
we
will
see
news
today,
but
it
should
go
back
to
rfc
editor
very
soon,
and
basically
it
is
the
one
that
should
be
being
the
first
in
line
that
should
be
updating
rfc6550
to
say
that
the
flags
are
time
bombed
and
that
the
iron
tables
should
reflect
that
there
is
this
time
bomb,
and
so
what
I
did
in
this
draft
and
what
I
did
in
underwear
draft
as
well.
C
Underwear
lips
as
well,
is
to
point
on
unaware
and
say,
since
that
update
the
the
flags
are
undefined,
for
you
should
not
use
the
flag
for
a
map
of
seven.
So
obviously,
when
a
new
implementation
will
implement
a
map
of
seven
or
more
packs,
there
will
be
a
definition
for
the
flags,
but
the
problem
was
for
an
implementation
written
today.
What
should
it
be
doing?
C
Basically,
the
implementation
must
use
the
compression
without
checking
a
flag
if
the
cyclopedia
compression
applies
to
the
link,
and
otherwise
it
must
not
compress
if
slope
and
does
not
apply
to
the
link.
Obviously
so
so
that's
that's.
Basically
what
we've
reached
discussing
alvaro
discussing
with
michael
so
so
we
had
this
course
and
then
us
thank
you,
and
so
so
we
will
reach
that
kind
of
decision.
C
C
So
we
pick
the
default
behavior,
because
we
we
consider
that
this
is
a
transition
between
the
mode
where
you
know
the
flag
is
kind
of
up
off
and
the
future
world
where
the
cat
the
flag
is
on.
So
we
decided
that
in
this
far.
E
C
Future
of
mopex
and
ripple
v2,
the
transition
would
be
finished,
so
we
used
as
default
the
other
side
of
the
transition.
So
for
this
particular
case,
compression
is
odd
and
that's
pretty
much
it
for
this
discussion.
C
E
Yeah
yeah,
so
I
hope
so.
Essentially
it
means
that
the
turn
on
draft
is
going
to
mandate.
Rpl
veto,
behavior,
anyways
right.
C
So
the
term
on
draft
doesn't
speak
about
ripple
v2.
It
just
says
that
map
7.
Does
we
don't
know
what
happens
in
map
7,
that's
what
it
says.
So
so
it
says
if
there
is
a
ripple
v2
and
we
want
it
to
be
backward
compatible
with
an
implementation
that
we
do
today.
With
this
draft,
then
ripple
v2
has
to
have
rfc8138
on
by
default
on
six
loop,
admins.
C
C
C
So
in
the
future,
when
we
write
ripple
v2,
we
will
have
to
mandate
eight
one
three,
eight
in
six
loop
and
links
or
will
be
compatible
with
the
best.
F
Yeah,
I
think
I'm
the
one
with
the
other
question
so
that
pretty
much
what
you
just
explained
was
another
question
that
martin
asked
me
separately,
which
is
we're
assuming
here
that
seven
and
whatever
happens
in
the
future,
is
going
to
use
compression
and.
C
B
F
F
Right,
so
his
question
was
basically
the
same
thing
that
you
just
explained.
You
know
what
happens
if
you
guys
change
your
mind
or
what
happens
if
in
some
extended
mop
in
the
future?
Let's
call
it
10
or
you
know,
I
don't
know
whatever
the
working
group
changes
its
mind.
So
my
answer
to
him
and
just
to
double
check
with
you
is
that
you
know
by
that
time.
F
If
we
ever
get
to,
I
don't
know
something
called
map
10,
you
know
either
the
notes
that
are
implementing
this
specification
turn
on
the
specification
that
that
don't
understand
mod
10,
but
they
understand
seven,
and
you
know
they
assume,
there's
seven
in
something
else.
Well,.
F
They
only
see
seven
correct
so
from
their
point
of
view,
they're
going
to
say
well,
this
looks
like
seven
I'm
going
to
try
and
use
composition
on
this
link
in
10..
The
working
group
said:
no,
we
don't
want
to
use
compression
anymore
for
whatever
reason,
then
the
nodes
just
won't
be
able
to
operate
there.
C
But
yeah,
so
that's
exactly
correct,
at
least
specifying
something
gives
us
that
we
know
if
we
are
backward
compatible
or
not.
So
as
long
as
we
maintain
those
decisions,
we
are
backward
compatible
and
the
day
we
change
this
decision.
We
know
we
are
not,
and
then
we
have
to
say
those
old
nodes
need
to
be
retired
from
the
network
because
they
cannot
operate
in
that
network.
C
C
So
next
slide,
please,
as
opposed
to
the
turn
on
draft
unaware
leaf,
is
just
entering
the
ietf
last
call
process.
So
for
now
the
the
the
review
we
had
was
alvaro's
review
as
the
idea
review
for
our
own
area.
So
thank
you
again
alvaro.
I
mean
you
you're
doing
so
much
for
us,
but
so
I
can
only
say
thanks
and
thanks
again,
so
the
discussions
that
we
had
were
not
very
much
on
the
operation.
C
It
seems
that
the
operation
looked
okay,
it
was
more
like
definitions
and
terms
and
what
is
a
rule?
Is
it
a
host?
Is
it
a
plain
ipv6
host,
but
no
because
it
needs
to
do
this
thing,
do
we
define
the
rule
as
being
a
host
which
can
do
the
things
that
we
we
place
as
requirements
on
the
host
in
this
draft,
and
so
the
answer
to
that
is
two
things.
C
There
will
be
so
so
we
what
we
needed
to
clarify
what
additional
requirements
we
had
on
the
role
so
that
it
can
effectively
operate
by
this
specification.
So
it's
it's
not
creating
new
standards,
because
the
standard
is
already
there.
It's
at
five
zero
five,
but
it's
how
you
use
it.
What
you
place
in
this
field,
this
field,
this
field
and
h505-
was
designed
for
this
to
happen
so
that
there
was
a
clear,
for
instance,
flag
in
the
registration
saying
hey.
I
want
the
router
to
give
me
routing
services.
So
it's
an
abstract
flag.
C
It
doesn't
say
it's
a
it's
for
ripple,
because
the
host
doesn't
know
it's
ripple,
but
the
flag
says
I
want
routing
services.
So
we
have
a
requirement
on
this
draft
that
this
particular
interface
in
h505
is
implemented
correctly,
meaning
that
if
the
rule
wants
us
to
do
ripple
for
him,
then
he
has
to
to
set
the
flag
as
specified
by
855
for
this
case.
C
So
we
we
don't
want
to
change
definition
of
row.
It's
it's
a
leaf.
That
is
a
whole
edge
to
a
report
network
and
it's
repairing
aware,
meaning.
Okay,
it
doesn't
speak
the
the
rfc
for
ripple,
but
we
also
have
had
to
explain
clearly
what
the
requirements
were
on
the
rule
so
as
to
to
to
operate
with
us.
C
So
the
changes
that
were
needed
on
this
draft
was
to
to
to
be
more
specific
on
when
we
used
the
term
row
to
make
sure
that
it
reflected
the
original
definition,
and
there
was
also
a
lot
of
use
of
6lm
and
6lr,
and
6l
and
6lr
are
defined
by
4
6
le
pen
and
we
are
repo.
We
are
not
six
low-paying.
So
why
is
it
that
we
have
to
use
that
terminology?
C
Well,
that's
because
the
other
side
of
the
interface,
eight
five,
four
five
uses
the
terminology,
and
actually
we
started
reflecting
that
in
user-friendly
info
for
the
routers,
which
are
the
border
of
the
ripple
network
and
that
serves
external
destination.
We
already
used
the
term
6lr.
C
So
in
our
terminology
in
this
draft,
I
had
to
explain
that
by
67
and
6lr
we
meant
hosts
and
routers
which
implement
the
function
defined
in
h505,
not
necessarily
anything
else.
Six
low
bands-
I
mean
it's
just
by
600,
we
mean
just
the
6
ln
functionality,
as
described
in
a
545,
excluding
the
rest
of
6..
It
can
be,
it
could
be,
it
can
be
out,
but
for
us
for
this
specification
just
means
at
505
contribution,
so
clarified
that
so
so
now
we
know
what
a
six
element
is
in
this
document.
C
So
there
again,
we
have
the
the
status
of
the
ripple
configuration
option
flag,
the
adapt
configuration
option
flags.
So
we
same
resolution
pretty
much
now
I
duplicated
completely
the
text
between
the
two
drafts.
Just
changing.
You
know
what
the
flags
are
and
what
the
default
values
are
for
those
flags.
C
There
was
a
final
rewarding
that
alvaro
asked
me.
I
made
it
in
the
github,
I'm
just
waiting
for
the
next
opportunity
to
publish,
because
it's
a
very
minor,
I
would
say
functionally
speaking-
doesn't
change
anything.
So
it's
just
clearer.
So
I
thought-
let's
not
just
publish
plus
one
for
that.
Unless
you
want
me
to.
C
Since
the
flag
is
not
there
and
we're
past
the
transition,
the
flag,
meaning
the
route
is
capable
of
proxying
the.
So
when
you
see
when
you
get
a
dao
at
the
root,
the
route
will
do
the
the
redux
exchange
with
the
6
mbr
on
behalf
of
the
host.
So
we
save
all
the
traversal
of
the
network,
which
is
one
of
the
functions
in
this
draft.
Well,
we
expect
that
for
ripple
v2
the
route
will
must
be
capable
of
doing
this.
So
it's
on
by
default
and
that's
pretty
much
it
any
question
on
this
draft.
C
Maybe
we
can
move
on
ines.
Do
you
mind?
Okay?
So
I
left
those
two
drawings,
it's
not
to
speak
them
for
for
the
for
unaware,
but
they
will
be
useful
for
the
discussion
on
the
rod
projection
because
we
are
also
using
tunnels,
and
I
will
explain
why-
probably
using
those
two
drawings
and
also
last
time,
I
was
asked
to
publish
them.
So
I
thought
hey
what
if
I
just
keep
them
in
these
slides.
So
if
people
need
them,
they
will.
They
will
know
where
to
find
them.
C
C
Actually,
there
were
many
discussions
on
many
fields
so
just
to
to
remind
people.
This
work
is
not
benign.
It's
not
a
small
piece
of
work.
It's
introducing
a
new
writing
paradigm
into
ripple,
it's
introducing
sdn
into
ripple,
and
so
it's
kind
of
normal
that
to
do
a
major
addition
to
ripple
like
this.
We
have
to
define
new
formats,
new
messages
or
new
options
and
yeah.
It's
also
normal
that
we,
we
cannot
hesitate
whether
we
should
do
it
this
way
or
that
way,
etc.
And
that's
when
the
discussions
on
the
mailing
list
are
so
necessary.
C
So
I'm
trying
to
trigger
discussions
on
the
mailing
list-
and
I
thank
harold,
michael
et
cetera,
we're
helping
more
contribution
is
always
appreciated.
C
So
one
of
the
the
facts
of
graph
that
is
stood
in
the
recent
version
is
it
got
overly
complicated
and
the
reason
for
that
is,
you
could
be
operating
in
a
main
geodag,
which
was
stirring
mode
or
non-story
mode,
and
you
could
build
storing
mode
and
non-storing
mode
rats
pirates
about
projected
routes
over
it
and
actually
those
projected
routes
could
be
injected
in
the
main
instance,
or
they
could
be
traffic
engineered
path
that
we
call
truck.
C
So
the
question
was:
how
can
we
make
things
simpler
and
so
the
also
there
was
the
case
where
you
have
a
an
instance
which
has
multiple
roots
and
so
multiple
geoducks,
and
so
do
you
want
to
build
a
path
that
goes
across
from
one
diode
to
the
next
diode
across
the
frontier
and
then
which
route
would
signal
that,
because
each
shot
can
only
talk
to
talk
to
the
nodes
in
front
of
the
attack?
So
basically
it
was
getting
crazy.
C
So
we
had
to
to
to
to
to
do
some
a
cab,
razor
kind
of
choices
and
make
simplifications
like
we
did
for
the
installing
mode
and
non-story.
In
my
ripple
we
had
to
go
the
same
path
and
say:
let's,
let's
get
this
too
complex,
so
the
first
simplifying
change
that
that's
proposed
is,
and
actually
I
wrote
it
that
way.
I
can.
I
can
roll
back,
but
I
wrote
it
that
way.
In
the
version
I
published
yesterday
that
we
have
only
one
main
instance,
so
we
we
don't,
we
are
playing
within
one
main
instance.
C
C
Is
it
possible
that
it
is
actually
on
the
next
geoduck
and
and
still
a
neighbor
to
a
node
in
this
diode,
and
I
tend
to
say
yes
that
we
should
be
able
to
do
so.
We
can
continue
on
the
other
side,
but
we
would
not
have
hops
across
geodex,
even
if
it's
the
same
instance.
So
that's
the
first
thing,
so
one
route
can
actually
control
every
node
at
every
hub
on
this
track.
That
makes
things
a
lot
simpler.
C
C
The
the
fact
is
that
down
stirring
is
for
the
most
thing,
the
the
the
mode,
which
is
mostly
deployed
out
there.
The
other
thing
is,
we
need
topological
information
at
the
root
or
at
the
pc
to
be
able
to
to
push
those
pedals
to
establish
those
routes
in
downstairing
mode.
The
diode
is
already
known
by
the
root
in
storing
mode.
We
would
have
had
to
add
some
signaling
to
tell
the
route
about
the
diode
so
saying
that
the
main
instance,
the
main
geodetic
has
to
be
non-storing,
makes
our
life
a
lot
simpler.
C
We
don't
have
to
signal
the
geoduct
the
route
he
already
has
it.
The
only
thing
that
we
need
to
signal
is
maybe
additional
siblings
or
possibilities
for
right
computation
at
the
pc,
but
it's
just
advertising
more
siblings,
not
the
whole
structure
of
the
geoduck,
so
that
that's
a
huge
benefit
on
stage
and
non-story.
So,
basically,
the
second
simplified,
simplifying
change
that's
proposed
here-
is
to
make
it
so
that
only
non-storing
is
usable
for
the
main
instance.
C
Now,
third
thing,
our
main
instance
now
is
non-storage,
should
we
use
pdows
in
the
main
instance,
and
what
would
that
be
for?
Well,
if
you
remember
when
pretty
much
the
first
use
case,
we
we
ever
had
for
pidao
was
to
say
hey.
If
this
non-storing
mode
wrought
down
the
diode
is
long,
many
many
hops.
That
means
that
rotting
header
has
many
many
entries
in
it,
even
if
they
are
compressed.
It's
still.
A
lot
of
of
space
in
my
pocket
and
my
frame
is
conf
is
is
constrained.
C
C
Before
we
did
those
tracks
and
this
traffic
engineering
and
blah
it
was.
It
was
initially
just
to
to
shortcut
between
the
hops
in
a
loose
source,
routing
meter
and
so
to
do
that,
if
you,
if
you
use
a
non-storing
mode,
you
re-insert
the
well,
you
don't
even
insert
your
own
caps
for
the
steps
that
you're
skipping
that
you're
saving.
C
So
if
you
do
do
it
only
once
in
the
network
or
on
the
path,
you
actually
save
nothing,
even
worse,
you're,
adding
more
space
actually
in
the
frame
just
to
have
this
this
right
together
between
those
two
loose
squat,
perhaps
so
so
that
doesn't
help
really
to
to
use
non-storing
mode
pidao
to
complete
loose
source
routing
normal
now.
So
so.
C
The
third
simplification
is
to
say:
hey
when
you're
in
the
main
diode-
and
you
just
want
to
add
routes
to
the
main
gear
deck,
then
the
only
thing
you
may
want
to
do
is,
and
you
can
do-
is
storing
mode
p
down
so
now
in
the
main
geoduck.
The
result
is.
The
only
possible
combination
is
storing
mode
pdown
over
non-storing
mode
wrath,
main
main
bag,
meaning
that
it's
really
meant
to
enable
loose
sweating
and
that's
pretty
much
it.
But
you
can
also
do
traversal
with
with
story
mode.
C
C
Actually
I
clarified
that
text
in
in
the
the
recent
version,
but
it
was
already
there
just
try
to
rewrite
it
a
little
bit
more
clearly,
but
when
we
establish
a
route
or
kind
of
traffic
engineering
purpose
to
to
basically
shortcut
avoid
going
through
the
common
parent,
we
use
ideo,
dag,
which
is
rooted
at
the
destination,
and
we
call
that
that
thing
a
track.
So
I
I
lied.
Well,
the
last
discussion
remaining
list.
C
C
I'm
getting
a
message
from
it's
a
proposal
right,
it's
it's
so
so,
let's
see
what
hal
tells
us
it's
cool
to
take
the
comments
as
we
go
so.
E
Yeah
so
pascal
you
know
I'll,
let
you
finish
and
then
come
back.
You
know
I
just
keeping
my
points
ready,
so
yeah.
C
Okay,
but
I
see
that
it's
a
major
change.
Well,
it's!
Yes!
It's
a
major!
We
eliminate
a
lot
of
case.
So
yes,
yes,
major
church,
so
that's
why
he.
E
Pointed
out
like
so
so,
if
we
in
a
way
we
are,
we
are
reverting
back
to
the
version
one
of
this
draft,
except
for,
except
for
the
track
part
and
the
multi-segment
track
parts
right
yeah.
So.
C
It's
a
way
of
saying
it,
but
it's
just
for
when
we
manipulate
the
main
instance,
because
what
we
we
wanted
to
do
those
non-storing
projected
route,
this
they
are
completely
there,
but
they
they
are
taken
from
the
local
instances
of
the
destination,
a
lot
easier
to
signal
it.
This
way
than
to
try
to
add
those
routes
to
the
main
instance,
and
if
you
add
those
routes,
the
main
instance,
you
start
creating
this
risk
of
doing
loops,
and
this
is
the
one
thing
we
did
not
want
to
to
create
loops
in
the
main
instance.
C
So
we
basically
say
hey,
we,
we
we
do
only
the
the
easy
game
of
basically
pedals
along
the
short
under
the
this
straight
sorcerer
to
make
it
loose
now.
The
other
thing
that
we
want,
we
we
do
here-
and
that
was
one
of
your
points
earlier-
is
to
avoid
looks
right.
So
the
the
the
primary
you
have
a
truck
which
doesn't
go
all
the
way
to
the
destination,
and
that
is
not
so
slotted.
C
Then,
as
you
you
go
through
that
truck
and
when
you
reach
the
end
of
that
track,
you
you
have
to
rot
to
to
to
the
destination,
but
the
truck
is
finished.
So
you,
how
do
you
do
that?
If
you
go
through
back
through
the
main
diode,
then
you
might
go
all
the
way
up
to
a
common
parent
and
then
it
would
go
down
possibly
to
the
ingress
of
the
truck
and
now
you're
in
the
loop.
So
the
the
home
buy
help
games.
I'm
sorry,
the
the
story!
Mode
projected
route
games
can
be
very
dangerous.
C
It
seems
kind
of
easy
to
create
loops
with
those
things.
If
we
don't
make
them
strict,
like
you
give
every
hub
and
you
don't
provide
rules
to
ensure
that
when
you
put
them
one
after
the
other,
you
don't
end
up
in
a
loop,
and
this
is
the
piece
where
we
are
not
100
percent
clear
still
on
the
document.
C
C
If
you
do
that,
then
you're
sure
you
don't
make,
you
don't
create
loops,
but
if
you
do
that
you
cannot
build
complex
tracks
either,
because
complex
tracks
will
have
a
sequence
of
segments.
So
right
now,
as
as
the
draft
as
yet,
this
is
two
constraint
we.
If
we
want
to
use
storing
mode
pure
rs,
two
complex
tracks,
then
we
have
to
to
make
it.
We
have
to
allow
like
taking
a
packet
off
a
track
of
a
segment
and
put
it
in
the
next
segment.
F
C
Is
specified
right
now
is
a
story
mode
pure
art,
so
a
segment
is
trigger
by
half
educate
that
take
from
one
segment
and
put
in
the
next
segment,
meaning
that
you
cannot
do
complex
tracks
with
the
draft
assist
stance.
Obviously
we
are
not
going
to
let's
go
with
it.
We
need-
or
we
need
to
accept,
that
that
restriction.
C
C
C
C
The
the
bottom
line
is
as
written
right
now.
You
will
see
tax
which
says
when
you,
when
the
the
increase
of
the
track,
takes
the
packet
of
the
track.
So
usually
it's
an
encapsulation,
so
it
encapsulates
he
has
to
do
a
local
delivery,
at
least
when
it's
a
story
mode
period,
local
delivery,
meaning
either
to
its
own
stack
or
to
a
neighbor.
E
The
way
I
understand
this
is
the
egress
node
yeah,
so
you
you've
been
very
clear,
so
the
egress
node
has
to
make
the
delivery,
but
how
would
that
decision
be
made?
You
know
what
I'm
trying
to
say
is.
How
would
I
tell
I
mean
it's
a
data
plane
operation?
How
would
I
tell
my
stack,
which
already
is
there
to
make
sure
that
that
delivery
is
done
locally?
If
not,
how,
on
what
basis
will
it
not
send
it
back
to
the
route
to
you
know
and
form
a
loop?
So
so
we.
C
Packet
has
every
indication
that
it's
for
it's
being
forwarded
on
the
track.
C
The
egress
is
the
destination
of
the
packet,
even
if
there
was
a
source
route
when
the
source
rat
is
completely
exhausted,
consumed
the
the
destination
in
the
end
is
the
grass.
So
the
grass
gets
these
packets
for
local
processing
inside
this
packet.
There
might
be
inside
this
encapsulation
there
might
be
a
packet
to
to
a
neighbor
and
that's
when
the
pictures
of
crude
etc
can
be
used
for
the
one
that
we
just
kept.
C
But
we
may
go
back
to
that,
but
the
bottom
line
is
the
tracking
grass
will
be
the
end
of
that
track.
There
will
be
an
api
which
has
the
instance
id,
which
is
the
local
instance
identified
that
identifies
this
track.
So
based
on
that
information,
the
the
egress
knows
it
is
digress
and
it
knows
which
track.
That
is
so
he
can.
He
can
make
the
decision
as
his
to
this
nation
and
encapsulates
that's
when
you
can
make
this
decision.
C
Another
simplification
that
we
just
discussed
and
with
oops
no
packet
back.
Please.
Yes,
it's
how
we
build
the
pidao.
So
initially
you
could
do
like
tao.
You
know
you
could
have
in
the
dao
just
to
remind
you
can
have
a
number
of
targets
and
then
you
can
have
a
number
of
transits.
C
So
the
target
are
the
final
destination.
The
transits
are
the
parent,
so
a
node.
It
could
have
multiple
addresses,
for
instance,
and
put
them
all
as
targets,
and
he
could
have
a
number
of
parents
and
he
could
put
all
them
as
transit
and
just
send
that
to
the
root
as
an
example
or
an
access
router,
a
border
router
at
the
edge
of
the
ripple
network
could
have
enough
children
which
are
unaware,
leaves,
and
so
he
would
do
the
dow
for
them.
C
So
that
would
be
multiple
targets
again
all
those
rules
and
he
might
indicate
himself
as
parent
for
all
of
them.
So
you've
got
this
concept
of
factorization
multiple
targets,
potentially
even
multiple
cios,
and
you
could
even
do
that
multiple
times:
sequence
of
targets
and
tios,
then
more
targets
and
more
tios,
etc,
etc.
So
so,
though,
allowed
all
this
complexity,
we
tried
to
figure
out.
You
know
how
it
could
work,
having
too
many
things
in
the
same
pedal
and,
for
instance,
in
storing
mod
pidao.
C
The
pidao
is
forwarded
across
the
reverse
path,
from
the
egress
to
the
ingress,
and
then
the
dow
arc
is
sent
by
the
ingress
to
the
root.
So
imagine
if
you
wanted
to
have
two
paths
in
the
same
message
that
would
be
two
acts
from
two
different
egresses
that
would
have
to
be
generated.
How
what
happens
if
half
of
that
works
and
the
other
half
doesn't
work,
so
it
really
led
to
to
huge
complication.
C
C
When
you
look
at
each
time
we
have
to
tunnel
or
we
don't
have
two
tunnels,
you
don't
know
it's
exactly
the
same
game
so
so
think
about
this
game
and
for
a
minute
just
think
that
we
turn
a
lot
of
the
time
you
remember
and
use
of
repo.
We
don't
tunnel
exactly
all
the
time,
but
almost
all
of
the
time
and
and
see
how
the
children
and
the
siblings
of
the
egress
of
the
tunnel,
as
as,
if
they
were
unaware,
leaves
I
get
in
the
track.
C
So
you
have
to
signal
all
those
siblings
that
you
can
reach
over
this
tunnel
and
you
have
to
see
now
the
hops
of
the
tunnel,
but
you
have
to
give
a
name
to
this
tunnel,
okay.
So
what
we
we
decided
already
is
that
the
name
of
the
tunnel
is
is
the
track
id?
It's
the
local
instance
id
taken
from
the
namespace
of
the
egress
okay.
So
we
have.
C
C
Second
thing
we
want
to
signal
in
the
pidao
is
all
those
siblings
and
children
of
the
egress
that
we
can
reach
about
this
tunnel,
but,
like
we
said
there
must
be
one
up
away,
at
least
when
we
are
doing
a
story
mode,
even
in
non-story.
But
it's
it's
a
bit
more
weird,
so
so
we
need
to
to
signal
all
the
siblings
and
then
we
needed
to
signal
the
hops
either
that
ends
up
as
a
source
route
or
that
ends
up
just
as
a
state
in
all
the
hubs
to
go
in
that
direction.
C
We
needed
to
signal
this
sequence
of
hubs,
so
the
questions
was
the
question
was:
how
do
we
do
that
and
we
tried
and
we
discussed
with
raoul,
etc,
and
we
ended
up
with
what
I'm
going
to
show
very
soon,
which
is
that
we
signal
the
track
identification
in
the
that's
very
normal,
because
you
know
now
it's
adele
in
the
the
the
main
control
message:
the
base
object,
you
you
have
a
geoduck
id
and
you
have
an
instance
id
that's
already
there
in
the
dow.
So
the
p
now
is
a
dow
just
like
the
others.
C
But
if
it's
signaling
a
track,
then
the
geodes
id
is
the
egress
and
the
local.
The
instance.
Id
is
a
local
instance
id
that
identifies
the
track
so
that
that
was
a
very,
very
logical
mapping,
because
we
are
building
a
diode
and
it's
rooted
at
the
egress
of
the
track.
So
it's
completely
normal
that
we
signal
those
things
in
the
dow
message
itself.
C
C
Okay,
what
becomes
of
the
tio,
which
is
the
transit?
Well
remember:
the
transit
was
just
giving
you
a
harp,
the
parent,
but
here
we
are
giving
a
sequence
of
hops
so
tell
you
could
not
be
used.
We
have
invented
the
vio.
Instead,
what
is
a
vio?
You
can
see
it
as
a
generalization
of
the
tio,
but
with
multiple
halves
in
them.
C
C
Then
you
have
a
number
of
target
options
just
like
in
normal
dao,
and
then
you've
got
a
vio
or
source
rod
vio,
which
is
this
via
information
option
that
replaces
the
tio
and
that,
instead
of
having
just
one
para,
there's
multiple
halves.
So
it's
kind
of
logical
the
one
thing
that
we
we
made
as
a
simplification
is
to
say:
hey.
We
have
only
one
vio.
C
There
were
a
number
of
reasons
for
that,
but
just
think
about
the
flow
in
storing
mode
where
the
acknowledgement
has
to
come
from
the
ingress.
If
you
have
multiple
ingress,
who
sends
the
acknowledgement?
How
does
that
work?
What
what
kind
of
failures
should
you
have
to
handle?
So
we
said
hey
much
simpler.
We
can
have
multiple
targets,
but
we
just
have
one
vio.
C
Also,
at
some
point
in
the
past,
the
source,
the
story
mode
vio,
so
the
normal
vio.
You
would
basically
have
one
options
option.
Perhaps
so
it
was
a
collection
of
options
indicating
something
surreal,
but
that
would
consume
a
lot
of
bites.
It's
actually
easier
to
to
put
them
all
in
a
single
vio
with
a
list.
So
that's
a
change
that
that
I
made
in
the
draft
and
that
enables
a
better
compression
with
rfc8138,
because
that's
what
the
decision
we
made
now
we
can
compress
the
vio
with
rfc8138.
C
Remember
in
normal
operation,
only
the
root
builds
those
source
routing,
either
in
the
press
fashion,
because
the
source
writing
editor
always
start
at
the
root
in
normal
operation
and
a238
enables
a
very
efficient
compression.
C
But
it's
it's
more
code.
It's
harder
to
do
so
being
able
to
provide
in
the
pedal
the
sauce
rotator
exactly
in
the
way
that
it
would
be
put
in
the
packet
was
a
huge
simplification
for
the
devices
themselves.
They
just
have
to
pick
it
from
the
pedal
put
it
in
the
packet
and
there
you
go
so
we
wanted
to
enable
that
format,
and
so
so
so
that
was
done
in
the
in
the
recent
publication
like,
like,
I
said
earlier,
the
ripple
instance
I
did
the
local
reference
ripple
instance.
Id
is
the
track
id.
C
So
that's
consistent
with,
like
I
said,
60-ish
and
raw.
So
all
those
drafts,
all
those
works-
are
expected
to
be
done.
That
way,
what
is
a
bit
harder
is
if
it's
a
local
instance
id
it's
always
associated
to
an
ipv6
address,
because
the
ipv6
address
is
the
namespace
for
which
this
local
insert
id
is
taken.
So
you,
you
always
need
to
have
both
in
the
packets,
so
in
ripple
that
was
already
specified
like
this.
C
F
C
So,
basically,
in
this
draft
we
say
hey
when
you
you
write
a
track
id,
you
have
to
have
the
bit
always
set,
so
there
are
not
two
version
track
id
the
one
that
would
just
not
specify
the
bit
and
the
one
which
has
the
bit
set,
which
goes
in
the
packets,
so
let's
always
set
the
bit.
So
there
is
text
now
to
say
that
the
the
the
complexity,
the
complication
that
goes
with,
that
is
when
you
have
a
packet
and
you
use
the
the
non-stirring
mode.
So
you
use
the
routing
editor.
C
The
actual
destination
of
the
packet
is
at
the
end
of
the
routine.
It's
not
the
destination
in
the
ipv6
header
itself,
because
you
have
to
consume
all
the
ratigators
until
and
when
all
everything
is
consumed,
then
it's
actually
in
the
ip600.
Otherwise
it's
the
routing
editor.
So
it's
kind
of
hard
in
the
normal
ipv6
formats
to
find
who
is
the
final
destination?
C
You
have
to
look
at
whether
the
routing
header
is
consumed
or
not.
If
it's
not
consumed,
then
it's
the
last
hop
the
last
plotting
error.
If
the
ratigator
is
consumed,
then
it's
the
destination,
the
ipa
wow.
So
I
had
to
write
text
to
explain
that
so
I
did,
but
if
you're
using
eight
one,
three
eight
eight
one
three
eight
made
it
so
that
we
actually
encode
the
destination
in
the
alkyder
as
the
first
entry
in
the
rotting
header.
C
So
everything
is
in
writing
either,
and
that
also
makes
it
so
that
the
last
entry
in
the
in
the
routing
editor
is
always
the
final
destination.
There
is
never
a
question,
so
8,
1,
3
8,
is
really
meant
to
make
the
forwarding
much
simpler.
Well.
That
also
makes
this
particular
operation
of
identifying
the
namespace
of
the
track
id
a
lot
easier.
So
if
we
have
a
translated
cz,
if
you
don't
have
it,
try
it
one
three
eight
you
have
to
look
at
whether
the
horizontal
is
present
if
it's
present
whether
it's
consumed.
C
C
C
C
So
so
you
may
have
to
decide
which
siblings
are
useful
and
should
be
signaled
to
the
root
and
which
one
should
be
ignored,
for
instance,
because
they
don't
give
it
in
that
direction.
You
have
enough
seedlings
to
progress.
You
don't
need
more
sleepless
in
that
direction
to
go
to
somewhere,
and
I
don't
know
so
the
reason
why
you
should
signal
siblings
and
which
siblings
you
should
signal
in
this
sibling
option.
C
We
don't
have
text
for
that.
We
don't
explain
it's
out
of
scope.
Tipping
selection
is
something
else.
So
if
you
have
very
few
siblings,
an
implementation
can
just
signal
everything
and
we
are
happy.
If
we
have
a
dead
situation,
there
will
have
to
be
some
intelligence
to
decide
which
siblings
to
to
signal,
and
that
may
depend
on
the
use
case,
it's
out
of
scope
next
time.
Please.
C
C
An
example
of
that
is,
if
you
look
at
the
tsn
architecture
so-
and
I
don't
have
a
drawing
for
that,
so
you
have
to
bear
with
me-
there
are
three
modes
in
the
tsm
architecture.
C
The
first
mode
is
you
have
an
application
controller
talking
to
to
the
network
controller
and
the
application
controller,
tells
network
controller
build
this
path.
So
there
is
no
interaction
between
the
the
the
node
that
generates
the
packet
and
and
the
deterministic
tunnel.
If
you
like,
it's
all
happening
between
the
controllers,
so
the
the
node
may
talk
to
its
controller
say
I
need
this
path.
C
C
The
act
arrangement
goes
back
to
the
pdwa
goes
to
the
root
and
the
root
talks.
The
pc,
which
is
better
controller
I'll,
say
mrp.
The
better
controller
goes
to
the
application,
controller,
say
mrp,
and
that
goes
back
to
the
the
node
which
needs
it.
That
can
start
the
traffic.
So
there
is
no
interaction
between
the
the
device
and
the
network.
There
is
no
uni.
C
The
second
model
is
completely
the
opposite.
It's
completely
distributed
it's
when
something
like
rsvp
happens
in
the
network
and
there
is
no
control
at
all,
so
it's
a
model
as
possible,
but
it's
not
one
that
we
support
with
that
net
or
rts
and
really
now
we
we
go
for
to
controller-based
at
least
for
the
network.
C
Now
there
is
a
nybrid
model
where
you
have
a
uni
user
to
network
interface
between
the
device
and
the
first
operator,
something
like
what
we
do
with
real,
for
instance
with
that
iphone
5.
So
you
have
like
an
nd
abstraction
between
the
host
and
the
network,
and
then
the
network
goes
to
the
root
and
say:
oh,
we
have
this
request
to
build
this
track.
C
C
C
One
remark
is
inside
this,
this
pdr
and
in
the
pdr
acknowledgement
you
have
the
track
id
that
is
present,
so
it's
the
same
locally
significant
instance
id
for
for
the
egress
of
the
track,
where
the
requester
makes
the
request
for
the
first
time
it
does
not
even
know
who
the
egress
is.
C
If
it's
a
status,
zero,
saying,
okay,
it
will
come
back
with
the
egrass
ipv6
address
and
the
local
instance
id,
so
everything
to
identify
the
track
and
then,
if
the
the
ingress
needs
to
continue,
I
mean
maintain
that
track
beyond
the
lifetime.
Then
it
will.
It
will
use
that
information
to
renew.
Basically.
C
So
it's
not
a
big
surprise.
The
the
thing
that's
more
interesting
is
that
the
the
pdow
and
the
lifetime
of
the
segments
in
the
pinau
is
completely
separate
from
the
lifetime
of
the
track,
meaning
that
say
it's
a
simple
tunnel:
multi-arab
segment,
just
one
segment
source
to
destination
and
that's
the
track,
a
serial
track,
so
say,
you're,
building
that
you
may
say
so.
The
pdr
may
say
I
want
it
for
an
hour
and
that's
the
track
lifetime
in
the
the
the
pdr,
the
pdow
request.
C
Well,
the
route
may
send
a
p
down
of
10
minutes
and
after
10
years,
a
new
one
after
10
minutes
a
new
one
and
maintain
that
completely
different
time
scale
as
the
track
does
so
so
the
pedal
lifetime.
So
the
segment
lifetime
in
the
pdow
doesn't
have
to
be
the
segment
the
track
lifetime
at
all
they're
completely
decaffold.
C
C
C
Tactic
so,
as
we
said,
the
meaning,
this
way
line
the
the
the
wording
for
track,
and
I
have
issues
that
are
tickets
that
are
raised
for
the
security
section.
I
know
I
still
have
to
handle
them,
but
right
now
we're
handling
the
main
operation.
When
we
know
what
the
main
operation
is,
we
can
look
at
the
security
issues
with
them.
F
C
Yeah,
so
I
did
not
do
improvements
on
the
security
section
right
now.
Next
slide,
please.
C
Okay,
so
this
illustrates
what
I
just
discussed
earlier,
so
what
you
look
at
if,
instead
of
track
id,
you
have
instance
id
and
if
instead
of
ipv6
address
of
the
tracking
drives,
you
have
geodag
id
guess
what
it's
exactly
the
dao
us
in
rfc6550,
so
we're
just
saying:
hey
a
pdaw
is
a
dao
same
format.
Some
information,
the
ips6
of
the
address
of
the
tracking
grass,
is
the
geodag
id
of
the
track
and
the
track
id
is
actually
a
local
instance
id.
So
it's
an
instance
id
it's
confirming
next
step.
C
C
C
Okay,
so
this
draft
introduced
the
vio
and
the
srvio,
as
with
a
generic
name
of
rod,
projection
options
which
replace
the
tio.
Basically
when,
instead
of
having
just
one
parent,
you
have
this
multi-hop
path
to
get
to
the
target.
C
C
C
One
segment
may
be
killed
and
replaced
by
another
segment
and
the
rest
of
the
track
could
stay
the
same,
so
they
are
completely
managed
individually.
They
have
a
sequence
in
the
lifetime
like
everything
repo.
C
So
this
is
not
very
surprising,
so
it's
the
same
kind
of
sense
sequence
as
we
had
in
in
the
tio
and
then
what
you
see
is
the
necessary
six
flower
cheddar
because
we
enabled
8.38
compression
now,
if,
if
you
don't
want
the
via
addresses
the
the
hops
to
be
compressed
at
all,
well
sixlar
has
a
format
for
that.
C
You
just
use
a
type
four
and
that's
basically
the
full
address,
but
then,
if
you
use
another
type,
they're
going
to
be
compressed
in
the
case
where
you
have
8138
enabled
in
the
network
and
you're
using
non-storing
mode,
so
you
you,
you
put
a
rod
together
in
the
packets.
You
encapsulate
with
the
rotator.
What
we
want
is
what
you
see
here,
as
I
said
earlier,
to
be
exactly
what
goes
in
the
packet.
C
C
C
The
first
must
be
set,
then
one
bit
which
says:
source
or
destination
and,
like
I
said
earlier,
when
it
is
set,
it
indicates
that
the
namespace
is
the
destination
and
then
left
are
six
bits
for
the
local
instance
id.
That's
why
you
can
have
at
most
64
local
instances,
so
64
tracks
that
terminates
at
the
same
increase,
but
for
each
node
in
the
network.
You
can
have
64
tracks
that
dominate
in
this
node,
so
that
gives
us
quite
a
bit
of
signaling
space
next
slide.
C
I
had
a
question
about
step
of
frank.
I
think
I
did
it,
but
I
forgot
yes,
somebody
wants
to
speak.
C
C
So
here
is
the
pdr,
don't
be
surprised,
there
is
a
lifetime
which
is
the
the
duration
for
which
the
track
should
be
built,
and
if
we
want
to
make
it
longer,
we
have
to
send
a
new
pdr
with
the
track
id
that
we
get
the
first
time
so,
the
first
time
the
track
id
is
set
to
zero
next
slide.
C
C
So
the
the
first
big
planning
issue
is:
how
do
we
do
do
we
have
to
to
place
the
egress
of
the
truck
in
the
sequence
of
hops
in
the
vio?
C
There
are
other
reasons
as
well,
for
which
you
would
like
to
to
place
the
egress
in
the
sequence,
for
instance,
if
you're
changing
the
main
instance
as
opposed
to
building
a
track.
In
the
case
of
the
main
instance,
you
need
to
know
the
last
half,
because
the
the
geodetic
id
is
the
main
diode
again
so.
C
You
don't
have
to
signal
a
geodag
id,
because
it's
it's
a
global
instance.
There
is
no
diode,
there
is
no.
There
is
no
namespace
associated
to
it.
It's
just
a
global
namespace,
so
we
don't
place
the
geoduck
id
in
the
tao,
and
so
it
has
to
be
indicated
in
the
sequence.
So,
overall,
there
are
many
cases
where
you
want
the
egress
to
be
indicated
in
the
vio,
but
then
it's
kind
of
a
duplication
with
the
fact
that
in
some
cases
it's
also
in
the
dow.
C
E
Anything
on
my
side,
pascal
and
I
I'm
still
not
sure
as
in-
why
the
why
the
last
the
egress
address
should
be
for
present
as
the
last
element
in
srbi.
You
know
so.
E
C
So
first
case
is
you're
in
the
main
instance
right.
So
in
the
main
instance,
you
don't
signal
the
diode
in
the
dow,
because
that
would
be
the
route
anyway
right
right.
Okay,
so
even
if
you
signal
it,
it's
the
wrong
thing.
Actually,
the
draft
has
published
says
two
different
things
at
two
different
place
and
both
are
wrong.
You
should
not
have
anything
there,
because
the
diode
is
is
the
main,
and
if
you
start
signaling
the
tracking
grains
there,
then
it
looks
like
a
mess,
because
it's
not
the
deodorant
idea
of
of
that
instance.
C
C
If
you
don't
do
it
there,
the
only
place
where
you
have
it
is
the
last
entry
of
the
segment
in
the
vi,
the
last
in
the
vi
that
expresses
the
segment.
Yes,
you
must
now.
The
other
case
is
so.
You
have
eight
one
three
eight
deployed
right,
so
you're
running
the
compression
and,
as
I
said
earlier,
I
made
every
effort
so
that
the
the
srvio
which
has
the
source
rod
header
built
by
the
root,
is
built
exactly
like.
C
C
C
D
E
The
second
reason
so,
pascal
now,
I
think
I
get
a
hang,
but
I
think
I'll
have
to
revisit
8138
again
to
understand
that
point
more
clearly
as
to
what
you're
seeing
is
that
the
compression
depends
on
the
the
uncompression
depends
on
having
that
last
element
present.
Yes,.
C
C
If
you
know
the
previous
address
and
and
the
routing
editor
will
tell
you
how
many
bytes
differ
and
you
just
override
those
bytes
now
if,
for
instance,
the
the
the
the
egress
differs
by
only
two
bytes
from
the
penultimate
hope,
then
you
need
a
a
six
srh
which
which
expresses
two
bytes
now
say
for
some
reason
that
the
previous
node
as
a
system
srh
that
uses
four
bytes,
then
you
need
to
insert
a
natural
signal,
as
I
just
say.
C
So
just
doing
the
complications,
the
computation
of
how
to
add
something
basically
brings
you
to
have
to
understand
all
the
complexity
of
how
you
encode
a
six
leverage
in
the
first
place,
which
is
complex
and
and
right
now
in
repo.
The
note
don't
have
to
do
that.
They
have
to
be
able
to
read
them,
but
they
don't
have
to
be
able
to
write
them,
and
I
wanted
to
keep
that
simplicity
where
the
node,
even
if
they
are
the
ingress
now
of
a
track.
Well,
they
have
to
do
this
encapsulation
and
place
the
raw
together.
C
E
Okay,
pascal
another
question
I
have
is
in
context
to
the
siblings
information.
E
F
E
We
are
introducing
the
sibling
options,
the
new
option
to
specify
all
the
siblings
for
this.
For
this
node
can
we
come.
C
E
Yep
yeah
so
here
so
one
thing
that
you
mentioned
in
in
during
your
presentation
is
that
the
calculation,
the
the
quality
of
link
from
the
node
from
the
egress
node
to
its
sibling,
is
an
of
type
calculation
and
it's
clearly
out
of
scope
for
this
document,
but
in
this.
So
so
then,
why
do
we
want
to
add
the
sibling
information
option
at
all
in
this
document?
If
that
is
if
that
is
out
of
scope,
for
you
know
that
okay.
E
C
With
with
the
current
draft,
is
we
don't
know
how
the
stepper
franc
is
computed,
but
it's
present
so
dof?
Is
there
right?
There
might
be
a
different
off
for
building
the
track,
but
then
you
know
I
don't
know,
but
at
least
the
step
of
frank
for
the
character
f
between
this
node
and
the
sibling
is
expressed
in
here
as
a
step
of
rank.
Now
this
is
computed
with
the
main
geodag
oath.
C
If
we
do
that,
then
we
don't
even
know
what
the
objective
function
is
at
the
pce
that
computes
the
track.
We
just
know
the
result
of
the
track
that
that
includes
he
has
chosen
an
egress
which
was
near
the
sibling
for
a
particular
oath
of
ease
and
the
nearness
of
the
selected
egress
to
the
sibling
would
be
known
because
each
potentially
grass
sent
sibling
information
with
the
metric
option
in
there.
So,
like
ripple,
does
you
can
put
all
the
metrics
like
I
read
this
lq.
I
read
this
whatever.
C
E
I
I
just
like
to
bring
to
the
notice
that
you
know
the
same
type
of
information
is
required.
You
know
we
discussed
that
even
the
nsa
extension
requires
such
a
similar
type
of
information
to
be
sent,
so
so
that
is
sort
of
an
open
item
for
this
working
group.
You
know
we
so.
C
And
explain
what
the
premise
is
and
what
the
relationship
with
nsa
is,
etc,
etc.
But
the
short
answer
for
this
draft
is:
we
provide
the
step
of
rank
for
the
main
off.
So,
if
we're
talking
about
doing
something
which
is
as
the
same
objective
as
the
main
left
then
use
step
of
rank.
C
If
the
root
uses
the
computation,
which
is
more
specific,
then
we
can
always
for
each
sibling
relationship
pass
the
metric
information
that
we
already
have
in
normal
dial,
so
everybody
could
pass
metric
informations
and
the
whichever
of
the
pc
decides
to
run
as
long
as
the
metrics
are
present
in
this
metric
information,
it
can
run
and
we
don't
have
to
know
what
it
does.
It's
completely
internal
to
the
pc
and
and
then
it
comes
back
with
a
track,
that's
magic,
but
we
don't
have
to
know.
So.
That's
basically
where
we
are
with
this
draft.
C
C
Yes,
that's
the
missing
feature.
It's
a
traditional
list
of
security
considerations.
They
said
I
did
not
do
and
next
step.
The
one
group
let's
go
around
next
itf
is
certainly
not
a
good
idea.
We
are
not
there
yet,
but
maybe
the
one
after.
If,
if
the
group
helps.
C
So
I
I
I
provided
a
number
of
news.
I
would
like
to
to
assess
if
what
I
presented
today,
people
agree
with,
because
there
are
recent
changes
which
were
made
or
are
being
made,
but
if
there
is
something
which
is
wrong,
for
instance
in
the
selected
simplifications,
or
if
you
guys
want
more
simplifications,
then
just
feedback
on
the
mailing
list.
Please-
and
so
I
have
you
know,
I
keep
reading
it,
but,
like
everything
you
write
when
you
read
it
after
you
miss
the
bugs.
C
There
are
still
a
number
of
bugs,
including
the
duodec
idea
of
the
mendiodag,
which
should
not
be
there,
and-
and
there
is
things
which
appear
several
times
and
not
necessarily
consistent.
I
need
to
fix
so
there
is
some
some
editorial
work,
but
I
have
the
feeling
that
we
are
converging
on
on
the
main
operation.
C
E
Okay,
so
let
me
begin.
A
Okay,
all
right,
thank
you
very
much
for
your
information.
Do
you
are
aware
of
some
implementation
of
things
I
we.
C
C
So
obviously
we
don't
have
a
final
implementation
of
the
draft,
which
is
not
final,
but
yes,
the
other
side
we
are.
We
are
beginning
an
implementation
of
itself.
We
have
one
person
assigned
and
you
know
one
can
go
and
put
some
code,
but
you've
seen
the
draft
right.
I
mean
I've
published
like
three
versions:
three
upgrades
without
the
number
of
discussion
on
the
mailing
list.
Each
time
you
know
the
formats
change
and
law
and
the
restrictions
change
so
not
like.
We
are
doing
your
product
tomorrow.
E
Okay,
I'll
just
the
capabilities
draft
it
has
so
can
you
go
to
the
next
slide?
Please,
sir?
We
had
we
had
got
received
feedback
from
dominic
on
the
github
repo
and
we
have
made
changes.
So
let
me
just
clarify
here
that
there
were
no
changes
which
impacted
the
basic.
You
know
structuring
of
any
of
the
options
or
any.
There
was
no
major
design
change
as
such
in
the
in
the
document,
but
thank
you
dominic.
You
know
we
have
received
an
elaborate
review
of
the
complete
document.
E
The
changes
are
already
pushed
in.
Another
aspect
is
in
listed
some
of
the
open
items
during
the
beginning
of
this
meeting.
Those
open
items
are
already
taken
care
of,
especially
in
context
to
the
capabilities
draft.
In
context
of
the
observations
draft,
those
some
of
the
some
of
the
items
are
open.
So
let
me
let
me
just
you
know
summarize
what
the
document
contains.
Currently
it
contains
the
capability
options
that
can
be
carried
as
part
of
our
ripple
messages.
E
How
do
you
advertise
the
capabilities?
So
it's
a
new
type.
It's
a
new
control
option.
Then
we
need
some
instant.
We
needed
some
instantiations
of
existing
capabilities,
so
so
we
have
two
two
types
of
capabilities
right
now
there,
the
one
is,
the
capability
indicator
flags
for
any
capability.
We
just
can
be
signaled
using
a
simple
flag
and
then
there
are,
you
know,
more
verbose
capabilities
which
requires
some
sort
of
additional
information
to
be
sent.
So
currently
we
have
the
indicators,
flags
and
the
resource
routing
resource
capabilities.
E
In
the
last
version,
we
even
had
something
called
as
neighbor
neighbor
table
capability.
You
know
which,
which
basically
signaled
the
nce
the
amount
of
information,
the
amount
of
entries
that
can
be
part
of
nce.
We
have
removed
that
because
we
didn't
had
any
specific
use
case
in
mind
right
now,
then.
The
next
thing
that
we
have
in
the
document
is
the
query
and
response
signaling.
E
This
was
already
discussed
in
the
last
entering
in
the
last
idf
session
and
then
the
guidelines
for
defining
new
capabilities.
The
only
must
that
we
have
in
the
document
is
that
the
kp
handling
of
capabilities
is
is,
is
mandatory
required
if
the
network
uses
mopex,
basically
mop
greater
than
or
equal
to,
seven
next
slide
piece.
E
E
There
are
two
tlbs
currently
defined
the
capability
indicators
and
router
and
resource
routing
resource
tlvs,
and
then
there
is
another
option
which
is
specifically
used
in
context
of
query
and
response,
which
is
the
capability
type
list
which
which,
which
will
in
using
that
option.
It
is
possible
to
enumerate
all
the
capabilities
that
are
supported
by
that
particular
node.
E
Please
this
is
the
basic
signaling
that
we
have
for
query
response.
You
know
there
are
some
some
cases
which
which
has
some
detailed
information
as
in
if
there
is
so
so.
The
first
first
diagram
is
about
querying
the
supported
capability
types.
Like
I
mentioned
in
the
previous
slide,
there
is
a
capability
type
list
option
which
can
be
responded
with.
E
E
Then
the
node
sends
back
the
capability,
the
corresponding
capabilities
with
the
corresponding
values.
Now
it
is
possible
that
only
the
partial
list
is
supported
for
the
the
query
is
made
for
cap
1
and
cap
2,
but
only
cap
1
is
supported,
so
the
draft
has
handling
for
that
as
well,
and
there
are
corresponding
secure
messages
for
this
query
and
response
messages
as
well.
The
cap
queue
on
campus
messages.
E
So
that's
that's
pretty
much
it.
You
know
from
the
capabilities
side,
we
didn't
had
any
major
update
since
and
whatever
work
items
we
envisioned
during
before
starting
this
work
has
been
fulfilled.
So
I
would
like
you
know
to
see
if
there
are
any
specific
opinions
as
to
how
we
can
proceed
with
this
draft.
You
know
from
from
for
from
my
side,
there
are
no
further
updates
that
that
are
pending.
Can
we.
F
E
F
C
And
yes,
I
offer
you
a
review
by
the
way.
The
question
is
more
like
we,
the
for
ripple
v2,
so
it's
going
to
be
just
put
in
a
table
now,
but
we
we
have
this
report
v2
discussion.
C
C
This
are
the
other
bits
in
the
configuration
option.
The
geodesic
configuration
option
that
we
may
want
to
clear
after
map
7
the
the
change
that
we
we
do
for
use
of
repair
info
says
basically,
that
the
configuration
flags
are
not
defined
after
map
it
renames
the
the
registry
to
say,
format,
zero,
six,
meaning
this.
E
Okay
yeah,
so
that's
so,
but
one
thing
is:
if
we,
if,
if
we
decide
to
not
have
a
secure
message
for
any
of
the
existing
message,
then
it
basically
means
that
the
secure
rpl
will
be
broken.
So
if
that
is
okay
for
the
working
group,
you
know
yeah,
we
don't
have
any
implementation.
Yeah.
B
C
F
B
Well,
I
I
agree,
so
I
think
the
point
was
you
know:
do
we
just
define
ever
any
new
message,
as
also
having
a
secure
version
is
the
point?
Is
that
because
the
registry's
not
arranged
that
way,
it
actually
is
arranged?
You
could
actually
create
secure
messages
that
don't
have
unsecure
ones
and
vice
versa.
The
registry
isn't
say
it's
just
as
bit,
it
doesn't
say,
there's
this
upper
bit
and
then
a
seven
bit
value.
B
It
says:
there's
there's
256
things,
some
of
which
are
secure
and
some
of
which
aren't
so
we
could
not
bother
defining
it
in
a
secure
form
because
of
the
reasons
pascal
gave
that
we're
probably
going
to
rip
them
out.
Okay,
I
I'm.
I
would
be
fine
with
that.
B
B
B
B
E
That
you
mentioned
michael,
was
you
know
we
don't
have
a
mandate.
The
article
doesn't
mandate
that
you
know
for
every
message.
You
need
to
have
a
corresponding
secure
message,
but
but
in
a
way
the
way
message,
the
message
type
is
decided.
For
example,
it's
0x01
for
dio.
It's
assumed
that
0x81
is
for
a
security
I
o,
so
that
one
to
one
mapping
is
in
in
some
way
it
is
there.
You
know
we
might
want
to
yeah.
E
E
Me
please
go
to
the
next
line.
The
mopex
updates,
so
mopex
the
primary
update
has
been
extending.
So
so
there
is
earlier.
The
draft
only
talked
about
extending,
adding,
adding
and
mopex
option.
Basically,
the
base
mop.
If
it
is
seven,
how
would
the
extended
option
looks
like
the
new
mopex
option
looks
like,
but
in
the
last
version
we
added
something
called
as
extending
rpo
control
options
in
a
way
in
which
it
could
be
backward,
compatible.
E
The
new
options
that
we
keep
adding
and
we
are
adding
new
control
options
at
a
very
great
you
know,
pace
even
in
the
dow
projection,
even
in
the
capabilities
options,
we
want
to
make
sure
that
we
have
a
good
system,
especially
if
anyone
decides
to
add
a
new
control
option
to
hack
to
keep
it
backward
compatible
in
a
in
a
proper
way.
So
this
particular
apple
control
options
make
sure
that
you
know
we
can
have
backward
compatible,
arcade
option
format.
E
That's
that
that's
it!
You
know
the
the
only
problem.
The
the
one
problem
in
the
last
version
was
that
the
location
of
xbit
was
assumed
to
be
second
most
msb.
The
assumption
was
that
the
first
bit
was
used
for
secure
control
option,
but
there
is
no
such
thing
as
secure
control
option,
so
we
moved
the
msb
to
the
first.
E
We
now
started
making
use
of
the
expert
as
the
first
industry.
The
ins
section,
is
updated
to
reflect
all
these
changes,
because
this
this
is
an
update
to
rfc
6550
yeah.
That's
so
that's
it!
I
guess.
Can
you
please
go
to
the
next
slide
in
us.
A
Thank
you
very
much
raul
yeah.
We
will
request
a
comment
for
both
of
these
documents
and
so
from
ripple
version,
two
topics.
We
need
to
prepared
the
contents
but
yeah.
I
think
we
before
going
to
deeply
that
we
need
to
solve
our
projection
misuse
validated
objects
as
well,
so
how
to
think
they
will
proceed.
We
need
to
prepare
the
table
of
content
and
put
topics
and
then
figure
out
as
well.
What
about
the
secure
messages,
this
version?
A
So
do
you
want?
Do
you
have
some
comments
on
that
week?
We
have
already
the
developer
content
in
github,
so
you
can
update
it.
I
think
as
well.
It's
important
to
solve
the
current
draft
that
the
working
group
has
like.
Well
now
we
are
having
a
line,
the
use
of
triple
info
on
our
leaf
compression
turn
on,
but
as
well.
A
Do
you
have
some
additional
comments
on
it?
Probably
probably
is
going
to
be
as
well.
This
topic,
the
main
topic
for
the.
C
C
Oh
yeah,
so
basically,
one
thing
here
from
this
list
is
that
pidao
and
aodv
ripple
are
kind
of
things
we
do
for
ripple
v1
as
well
right.
C
They
are
defined
in
the
ripple
v1
world
and
would
be
imported
in
the
ripple
v2
world.
But
the
question
I
had
on
secured
options
applies
to
pidao
as
well,
because
we
have
this
the
the
pdr,
the
pdr
act
probably
will
require
a
secured
version.
C
Yes,
unless
in
this
the
group
tells
me
you
know
not
to
write
them,
I
would
like
to
take
my
turn
and
and
emulate
what
to
do
first
option.
Even
if
I
know
the
body
will
never
entertain
it,
which
is
kind
of
a
pain
I
just
did
not
want
how
to
go
through
that
same
time
if
we
decided
for
it.
So
we
don't
do
that
right.
A
I
don't
remember
which
exactly
which
part,
but
in
650
there
are
some
kind
of
sections
that
say
this
is
for
future
work.
This
part
is
for
future
work
and
this
is
for
future
work,
so
we
we
will
have
to
check
which
kind
of
this
future
work
that
6550
was
mentioned
can
be
applied
here
now
I
don't
recall
exactly
which
sections,
but
I
will
check
that
as
well.
I
think
we
have
to
do
like
a
priority
list.
A
What
issues
have
to
be
solved
before
we
can
proceed
with
that,
but
I
mean
nothing,
nothing
avoid
to
work
in
the
table
of
content
and
update.
It
just
have
to
put
the
topics
or
make
a
draft
of
that,
but
you
feel
more
comfortable,
but
I
think
we
need
to
the
priority
list
to
issue
solve
to
start
working
on
that.
F
C
Relied
via
your
information,
there
are
functions
which
are
from
the
from
v1,
and
that
includes
pidao,
repo
iodv4
and
functions
that
we
keep
from
ripple
v1
when
we
go
through
the
document,
and
there
are
probably
the
missing
extensions
or
the
refinement
of
year,
one
where
we
said
like
you
said
this
is
for
future
or
we
said
we
don't
know
exactly
how
this
is
done.
So
we
leave
it
to
implementations,
and
maybe
somebody
will
define
that
in
the
future
or
start
a
report.
So
there
are
things
like
how
do
you
know
your
neighbors?
C
A
Yeah
as
well
yeah
as
well,
we
have
to
identify,
I
would
say,
which
part
of
the
6550
get
obsolete
with
this
new
version
and
put
it
like.
Please
pay
attention
that
these
kind
of
things
are
obsolete,
this
kind
of
thing
and
why
the
reason
why?
Because
we
get
this
improvement,
so
yeah,
we
can
start
working
on
that.
A
Thank
you
additional
comments.
What
do
you
think
is
the
way
of
working
the
github,
it's
okay,
for
you
start
putting
there
or
a
draft.
C
I
don't
know
if
it's
an
official
policy
in
us,
but
it
looks
like
it
is
almost
official,
because
every
worker
document
should
be
in
the
world
guitar.
A
Yeah,
exactly
yes,
yeah,
sorry
yeah,
so
action
points
like
identify
from
6550,
which
sections
are
are
specified
as
a
future
work
and
just
add
it
to
the
list
and
then
set
the
priority
issues
that
have
to
be
solved
before
we
can
proceed
with
this
rpe
and
two
version,
two
topics.
So
do
you
agree
with
these
action
points.
A
B
A
Yes,
the
action
will
be
like
going
through
6550
and
identify
the
sections
that
state
as
a
future
work
and
then
add
into
the
list
as
well.
Alongside
with
the
priorities
issues
that
have
to
be
solved
before
we
can
proceed
with
these
people
version.
2
topics.
A
A
Okay,
I
will
probably
this.
This
meeting
is
record.
Okay,
the
itf
secretariat
is
going
to
put
it
into
youtube,
and
then
I
will
share
with
you
the
link,
so
it
won't
be
useful
to
unders
to
follow
the
the
person
that
could
not
attend
about
the
new
modifications
and
down
projections
and
capabilities
as
well.