►
From YouTube: IETF112-ROLL-20211110-1430
Description
ROLL meeting session at IETF112
2021/11/10 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Okay,
we
can
start
welcome
to
a
role
meeting.
B
Yep
so
these
days
the
atf
is
putting
emphasis
on
the
code
of
conduct.
That's
why
we
have
an
extra
slide
for
that,
so
the
atf-
and
we
here
in
the
world
working
group,
expect
to
see
discussions
about
ideas
and
technical
discussions,
but
we
expect
everybody
to
be
treated
with
dignity,
decency
and
respect,
and
that's
even
written
in
a
guideline
for
conduct.
B
A
B
A
A
A
Then
pascal
will
present
the
multicast
registration
and
it's
a
six
law
document,
and
then
we
will
discuss
about
our
current
open
issues,
style
projections,
failure,
router
and
the
enrollment
priority.
A
A
We
have
one
document
in
submitted
to
the
isg
for
publications
and
moppex
capabilities
were
submitted
recently
and
their
work
in
progress.
I
we
hope
to
that.
We
can
go
to
as
well
at
some
point
to
work
in
group
class
call
from
opex
and
then
we're
going
to
as
well
discuss
about
this
failure:
detection
of
the
router
by
contract
and
then
as
well.
There
is
a
new
version
of
a
storing
root,
so
please
review
and
consider
to
have
it
as
a
work
item
in
the
working
group.
A
A
Has
put
some
difficulties
to
complete
some
work,
so
we
are
starting
again
to
get
back
to
what
we
left.
Okay
about
the
experience
internet
draft,
we
assume
that
those
are
going
to
be
continued
later.
A
So
about
the
current
milestones.
Okay,
about
the
first
item
we
have
to,
we
have
to
update
the
date
and
we
still
have
work
on
done
so
this
they
have
to
be
updated
for
the
second
one.
We
we
have
split
in
two
working
items,
two
documents,
opex
and
capabilities
so
as
well.
They
have
to
be
updated.
B
C
So,
with
regards
to
mopex
and
capabilities,
I
think
for
mopex
there
is
just
one
action
item
which
is
open.
It's
already
shared
on
the
issue
list
in
the
in
the
github
repo
that
we
have
the
role
working
group.
But
apart
from
that,
there
are
no
other
pending
items
so
to
speak.
We
would
really
love
to
have
some
targeted
review
stores.
This
documentary
already
dominated
this
review,
based
on,
which
is
the
last
update.
A
B
So
do
you
mean
you
could
work
on
it
in
the
next
few
months,
but
as
we're
going
to
update
the
milestones,
we
don't
want
to
do
that
every
month
you
know
in
pushing
things.
D
C
I
would
say,
even
though
there
is
one
single
work
item,
but
that's
a
call
that
I
working
with
that
that
our
working
group
should
be
taking.
I
I'll
maybe
float
that
question
on
the
voting
group.
Again.
Romney
gave
already
raised
that
in
the
email,
I
guess,
but
we
are
yet
to
receive
any
response,
but
I
would
say:
design-wise.
F
C
Let
me
just
repeat
what
I
said:
there
was
one
one
open
question
on
the
mopex
that
we
have
in
the
issue
in
the
work
working
group,
repo
github
repo-
that
is
the
only
open
action
item
that
the
working
groups
needs
to
take.
A
call
on
with
that
done.
Mopex
is
fairly
a
simple
designs,
badly
a
simple
document,
because
it
does
not
introduce
much
any
new
messages.
C
On
the
other
hand,
capabilities
document
introduces
new
messages,
so
it
might
take
a
little
bit
more
longer
and,
as
I
would
say
that
we
can,
we
can
handle
more
effects
first
and
keep
capabilities
for
later.
A
E
A
B
Yeah,
that's
probably
going
to
be
in
the
end
of
next
year.
I
need
to
resume
work,
that's
going
to
happen
in
the
spring
then,
or
the
usual
delays.
You
know
before
submission.
A
Okay,
great
thank
you
and
then
multicast
would
be.
This
is
a
between
is
a
work
that
will
happen
between
pascal
and
carsten,
so
we
can
ask
them
by
email
or
if
they
want
to
comment
here.
F
Not
moving
on
with
this
one,
and
so
this
one's
recasting,
but
but
the
multicast
work
that
we've
started
so
far
is
told
we
need
to
to
get
more
interest
on
here,
etc.
A
Okay,
great,
thank
you.
Let
us
know:
okay,
okay,
we
have
open
tickets
like
here,
so
please
they
are
outdoors
check
your
tickets.
If
you
consider
your
a
document
close
to
working
with
last
call
share
your
tickets
and
close
them
if
they
are
sold
or
updated
accordingly.
Thank
you.
A
A
Okay,
next
topic:
it's
of
the
variable,
so
we
are
currently
in
version
11.
We
are
working
in
the
discuss,
discuss
comments
from
the
ist
but
as
well.
We
want
to
bring
here
the
conversations
about
the
mode
of
operations
and
if
this
document
should
obsolete
the
6997.
A
A
A
A
So
please,
if
you
are
aware
of
some
deployments,
let
us
know
incrementation,
let
us
know
by
the
main
list,
the
other
question.
If
this
a
draft
audio
variable
should
obsolete
p2p
ripple
and
if
we
go
forward
with
this
option,
we
should
clarify
that
both
implementations
cannot
coexist
on
the
same
network
right
and
what
happened
I
mean
if
they
overlapped.
F
Overlapping
is
a
big
world
because
to
to
get
two
nodes
to
talk
together,
you
need
to
voluntarily
give
them.
You
know
the
network
keys,
so
they
can
see
each
other.
I
mean
it
does
not
happen
by
mistake
or
by
magic.
You
know
all
those
networks
are
secured,
but
layer
two.
So
really
it
would
be
very,
very
surprising
that
someone
comes
in
and
deploys
nodes
with
two
different
protocols
on
the
same
networks,
and
so
it
really
will
not
happen.
F
I'm
fine
with
obsoleting.
The
reason
is,
as
you
said,
there
is
no
non-deployment
and
having
two
options
would
divide
the
market
quote-unquote.
So
if,
if
people
decide
to
to
go
for
a
reactive
protocol,
I
think
it's
good
that
they
have
one
clear
option
and
not
to
choose
between
two
and
did
6997
was
experimental.
Now
we
are
doing
a
standard
track.
That's
exactly
what
we
mean.
A
H
So
we
had,
I
had
asked
the
same
question
when
this
draft
first
came
to
me
about
obsoleting
p2p.
H
There
is
one
of
the
applicability
rc's
that
I
think
recommends
using
p2p.
You
know,
I
think,
there's
a
should
there
use
b2b
or
something
like
that,
or
maybe
it's
a
must.
I
forget
we're
going
to
go
that
way.
We're
going
to
need
to
update
that
right.
So
that-
and
I
understand
there
are
no
implementations
but
yeah.
We
need
to
just
update
that
so
there's
no
pointing
to
something
that
doesn't
exist
anymore.
H
D
It's
my
building
and
it's
the
building
and
home
rfc
87733
that
talks
about
p2p.
I
was
pretty
sure,
and
then
I
looked
and
I'm
right
and
I
think
we
can
relatively
safely
say
that
I
don't
think
that
it's
it's
been
implemented
or
deployed
in
any
significant
amount
or
even
any
insignificant
amount.
D
But
I
understand
what
you're
saying
we:
we
need
to
kind
of
tell
people
if
they
are
going
to
implement
it,
how
they
would
do
it
with
aodv.
Instead,
I
think
that's.
What
your
point
is
is
that
right,
yeah.
H
Right
and
right,
so
I'm
not
sure
if
or
I
was
hoping
that
that
the
update
to
that
applicability
statement
would
just
be
like
a
one
line
thing
of
instead
of
using
p2p,
usa
or
aot.
I
don't
know
if
there
are
other
parts
of
the
profile
that
we
would
need
to
change
there.
H
D
D
D
B
See
what
the
easier
stuff
obsoleting
would
be
nice,
if
it's
not
too
costly
in
terms
of
process,
so
who's
willing
to
examine
that.
H
So
it
would
have
been
nice
if
charlie
or
someone
would
have
been
here.
I
don't
know
if
any
of
the
other
authors
are
here
or
not
conflicts.
H
There
right
with
a
couple
of
discusses-
I
I
need
to
think
about
this,
because
we
might
need
to
pull
it
back
and
you
know
pull
it
back
from
the
asg
queue
and
send
it
back
to
the
working
group,
because
it
may
be
a
more
significant
change.
I
hate
doing
that
because
I
mean
this
document
already
left
the
working
group
like
two
years
ago,
but
it's
just
been
slow
on
getting
provisions
and.
D
H
So
I
guess
what
I
want
to
see
is
probably
what
the
scope
of
the
changes
before
I
guess.
I
make
a
decision
whether
we
need
to
pull
it
back
or
not,
because
since
we're
in
the
middle
of
the
asg
review
right,
I
want
to
just
pull
it
under
people's
feet.
Right
and
maybe
all
we
do
is
ask
them
to
to
consider
it
again
or
something
without
having
to
run
through
the
whole
last
call
process
and
everything
else.
B
D
B
A
few
answers,
not
many,
but
most
of
them
were
in
favor
of
reusing
mob4.
I
think
mostly,
the
working
group
members
are
conscious
of
the
few
more
values
left
until
we
have
no
packs,
and
so
this
is
the
occasion
if
somebody
strongly
objects
to
using
four
and
as
alvaro
said
if
we
agree
that
move
four
is
the
way
where
we
want
to
go
we'll
investigate
exactly
how
much
work
is
involved
and
what
the
process
is
for.
Your
db
report.
A
B
H
A
A
F
Okay,
well,
this,
basically,
let
me
introduce
this
it's
a
fairly
recent
draft
that
was
published.
Let
me
share
video,
maybe.
F
Okay,
so
this
is
this
is
a
fairly
recent
draft
that
was
proposed
at
six
low,
but
really
it
is
both
a
six
low
other
raw
work,
because
it
does
basically
what
eight
five
or
five,
which
is
six
floor.
Fc
does
for
nd,
but
at
the
same
time
it
does
what
nine
zero
one
zero.
Eight.
Ninety
eighty.
Ninety
ten,
I'm
sorry
that's
for
ripple.
Remember
that's
the
ripple,
underwear
leaf.
F
So
in
the
case
of
the
two
existing
documents,
it's
about
using
six
lap
and
nd
to
register
an
ipv6
address,
and
so
that's
h505
and
using
ripple
to
basically
report
that
extra
knowledge
rise
to
the
root
using
non-stone
story
mode
here,
which
we
are
doing
is.
We
are
extending
8505
for
multicast
and
any
cast
address
and
at
the
same
time
we
are
providing
the
operation
in
ripple
to
transport
those
addresses.
F
F
Okay,
so
so,
basically,
just
for
for
the
sake
of
memory
here
is
that
the
family
of
rfcs,
which
come
with
six
open
d,
started
with
6775,
which
was
extended
and
partly
replaced
by
h505.
So
with
this,
you
can
basically
register
using
a
unicast
exchange,
an
address
to
your
router,
and
that
has
the
good
capability
with
h505
to
abstract.
F
Whatever
routine
happens
in
the
network,
in
our
case
it's
ripple,
but
it
could
be
meeple,
it
could
be
a
neighbor
discovery
proxy
and
that's
what
rfc8929
does
there's
also
evpn
there's
a
draft
at
the
vpn
for
injecting
address
my
ip
address,
slash
mac
addresses
as
a
rapid
type
5
in
vpn,
and
there
is
rift
as
well.
F
So
there
are
two
things
which
are
happening
right
now
at
six
low
one
is
to
extend
the
support
of
this
of
the
6lbr,
so
it
can
be
used
as
a
registrar
that
you
can
look
up
when
you
have
to
to
find
an
address
mapping
instead
of
sending
in
the
next
lookup
as
a
multicast
broadcast
message,
you
can
actually
effectively
do
that
as
unique
as
so.
That's
one
piece
of
work
which
is
happening
but
for
our
interest
here.
F
The
the
most
important
thing
is
there:
is
this
six
little
multicast
registration
that
I'm
discussing
today
next
slide,
please,
so
why
did
we
create
it,
and
why
did
we
go
through
swiftly?
Well,
there
is,
there
is
an
external
sdo
called
the
weiss
and
alliance
that
defines
in
the
fan,
working
group
field
area
network
working
group
define
how
ripple
six
slope
and
extra
are
being
used
for
ysl
applications.
F
That's
15,
4g,
typically
for
metering
applications
and
so
far
they
were
using
unicast,
but
they
started
noticing
the
need
for
multicast,
and
for
that
they
wondered
how
to
achieve
it
and
realize
that
implementing
mld
would
would
be
very
hard
for
their
very
constrained
devices.
On
the
one
hand,
and
requires
to
to
listen
to
multicast
and
the
the
low
power
battery
operated,
devices
are
not
friendly
to
broadcast
in
in
any
fashion.
That's
why
we
did
apparently
in
the
first
place,
but
the
same
need
appeared
for
for
the
suggestion
suggestion
was.
Oh,
this
device
is
already
285.
F
Why
don't
they
use
855
as
well
to
basically
indicate
that
they
are
listeners
to
to
a
multicast
address
or
that
they
share
in
any
cast
address
and
for
the
front
from
the
perspective
of
the
6lowpan
device?
6Ln,
that's
pretty
much
the
same
effort,
whether
it's
unicast
any
caster
multicast,
you
just
have
to
say
hey.
I
can
accept
a
packet
coming
to
that
address,
although
in
hand,
and
they
need
to
signal
in
h505.
F
You
know
it's
unique
as
any
cast
or
multicast
to
just
to
be
very
clear
that
they
know
about
it
and
because
any
cast
are
not
distinguishable
from
unicast,
so
you
really
have
to
sign
it.
A
multicast
is
different.
It
always
starts
with
foxbox.
You
know,
so
it
could
be
infer
than
it
was
actually
so
far
in
repo
in
felt
from
from
the
address.
F
But
with
this
draft
we're
effectively
asking
that
the
flags
which
say
anycast
and
multicast
are
propagated
in
ripples,
so
the
the
writing
protocol
is
very
clear
what
type
of
address
and
what
phrase
expected
the
6r
has
a
little
bit
more
work
to
do
because
compared
to
the
unicast,
it
has
to
accept
more
than
one
registration
for
the
same
address,
but
with
different
rovers.
So
basically,
the
tuple
that
identifies
the
registration
becomes
address,
comma
rover
and
remember
the
rover
is:
what
initially
was
the
ui
64.?
F
F
The
same
I
mean
there's
very
little
difference
the
differences
in
the
ripple
behavior,
and
so
we
extend
65
50
to
express
that
behavior
and
that's
when
the
discussion
on
map4
came
into
play,
because
if,
if
aodv
takes
mode
5,
it
means
that,
for
this
draft
we
would
be
asking
map
6
for
the
non-starring
multicast
support,
and
that
would
mean
taking
the
very
last
map
available.
F
So
so
we
said
a
since
four
is
not
reused,
maybe
better
take
the
path
of
of
leaving
six
alone
and
using
five
here
and
four
for
iodp
repo.
That's
really
where
I
started
so
same
thing
as
the
the
arrow
option.
In
h505
we
have
two
new
flags
and
this
time
they
are
in
the
report
target
option
and
because
anycast
was
not
present
in
map
3.
We
also
describe
how
any
cast
works.
So
any
cast
in
terms
of
ripple
process
procedure
is
really
like.
F
Multicast,
like
you,
have
to
accept
and
remember,
keep
track
of
more
than
one
origin,
but
in
the
case
of
any
cast,
when
you
have
a
packet,
you
just
forward
it
to
one
of
them,
whereas
with
multicast
you
forward
to
all
your
children
in
storyboard
multicast
next
slide.
Please.
F
So,
if
the
the
six
sellers
at
the
edge
which
have
six
ln
children
attached
to
them,
which
register
for
multicast
or
any
cast
address
setting
the
flags
in
the
error
will
propagate
that
registration.
If
you
know
us
in
a
five,
the
flag
is
set
to
say:
please
do
the
routing
for
me.
F
So
if
a
flag
is
set,
6lr
will
inject
the
address
using
a
target
option
with
the
appropriate
flag
set,
so
in
non-stopping
mode
that
that's
going
to
be
a
unicast
by
get
to
the
root,
just
just
like
for
a
row,
a
ripple,
no
leaf
and
what
happens
now,
because
if
it's
it's
multicast
in
the
case
of
multicast,
the
route
will
do
what
we
call
ingress
replication,
meaning
that
it
will
send
a
packet
a
copy
of
the
multicast
packet
to
each
of
the
six
sellers
that
have
sent
down.
F
So
each
of
the
six
alarms
that
have
at
least
one
child,
which
registered
to
a
multicast
address
for
multicast
string,
really
will
receive
a
copy
and
the
copy
will
be
tunneled
exactly
like
for
an
external
route.
So
it's
going
to
be
a
just,
an
srh
to
the
6r
6lr,
the
encapsulates
the
packet
and
the
exception.
The
capsulated
packet,
instead
of
being
unicast
in
as
usual,
this
time
becomes
a
multicast
is
a
multicast
packet.
But
for
forwarding
down
the
deal
dag
it
didn't
make
any
difference.
F
It
was
just
a
tunnel
packet
to
the
6r,
so
the
the
route
sends
a
one
to
six
slr
and
and
each
cxlr
looks
you
know
the
destination
and
copies
all
the
six
elements.
That
subscribed
and
note
that
in
the
mailing
list
we
discussed
how
to
call
this
and
we
we
agreed
to
call
it
subscription.
F
So
really
the
6000
subscribe
to
to
multicast
address
when
they
register
to
to
an
unicast
or
on
any
cast
address
just
for
terminology,
because
the
multicast
address
does
not
belong
to
the
device
where
your
unicast
or
even
any
cast
belongs
the
and
then
there
is
also
obviously
this
support
for
any
cast
and
for
the
support
of
any
cast
well.
The
root
will
just
choose
one
of
the
six
at
all
and
and
send
the
packet
to
him.
F
So
it's
it's
again
the
same
unicast
tunnel
as
usual
and
inside
there
is
a
packet
which
is
an
anycast
package,
and
so
the
cxlr
will
look
for
any
of
the
devices
that
register
to
it
and
pick
what
so.
It
really
looks
like
the
support
of
unicast.
You
just
pick
one
and
send
the
only
little
thing
is,
is
if
the
layer
2x
indicate
that
the
600
does
not
receive
the
packet.
The
6r
is
still
free
to
pick
another
6lm
that
registered
for
the
unicast
address
and
pass
the
packet
to
him.
F
And
that's
pretty
much
what
is
being
said
in
more
detail
here
so
as
opposed
to
multicast
in
any
cast
address,
looks
like
a
unicast
address,
so
we
we
effectively
needed
a
flag
to
to
signal
in
ripple
and
in
nd
that
this
is
any
cast
now.
There
is
always
the
question
of
the
backward
compatibility
for
both
cases.
So
basically,
in
the
case
of
multicast,
as
soon
as
you
see
foxfox
in
the
address,
you
assume
multicast
anyway,
finally
cast
the
process.
F
F
But
if
one
of
them
bears
the
any
gas
flag,
it
is
to
understood
that
all
the
registrations
are
for
any
cast,
and
then
it
will
remember
them
all
note
that
for
any
case,
the
tid
is
irrelevant,
because
multiple
nodes
can
originate
advertisement.
F
It
is
relevant
within
the
scope
of
one
rover,
but
the
rover
is
is
not
propagated
when
there
are
multiple
registrations
for
the
same
address,
for
instance
the
first,
the
6lr,
which
receives
three
registrations
for
three
six
elements
which
one
to
be
sent
to
the
same
anycast
and
that's
three
different
rovers
and
that
cannot
be
circulated
inside
ripple.
F
F
What
did
you
say?
Oh
yes,
the
important
one
is.
There
is
no
instruction
right
now
in
the
document
about
in
the
case
of
any
cast,
how
a
node
will
decide
which
child
or
the
root
which
decide
which
cxlr
is
there
some
stickiness
based
on
the
flow?
Is
there
you
know
pure
round
robin
pure
random?
That's
that's
not
discussed.
F
F
So,
last
but
not
least,
we
have
backward
compatibility
considerations
because
repo
is
already
widely
deployed,
in
particular
for
white
sun,
and
it's
always
deployed
with
map
one.
So
if
we
wanted
to
do
this
as
an
addition
to
an
existing
network,
we
have
to
do
two
things.
F
We
have
to
to
explain
how
it
works
in
map
one,
and
then
we
say
yes,
it
can
work,
but
we
have
to
to
basically
tell
the
nodes
that
that
they
have
to
support
it,
because
it's
not
report
which
will
signal
report
will
see
number
one
as
opposed
to
about
five
next
slide.
Please.
F
We
have,
to,
I
would
say
finish
it
on
the
sixth
low
list,
but
would
really
appreciate
comments
from
rip
from
the
raw
mailing
list
cc6
low,
and
then
we
we
started
discussing
with
the
80s
about
you
know
how
we
we
do
this
interaction
between
raw
and
and
ripple.
So
that's
working
progress,
but
eric
client
should
talk
to
alvaro
and
eric
also
suggested
talking
to
pm
people
to
see
exactly
what
kind
of
intersection
we
have
there
and
I'm
done.
H
Hi
yeah,
so
just
to
make
sure
you
just
sit
there
to
make
sure.
I
understand.
F
Yeah
pretty
much
I
mean
so
so
it
was
done
in
two
steps
because
traditional
nd
requires
mld
for
even
unicast
addresses.
You
have
to
use
mld
for
the
solid
state,
not
to
us.
It's
a
very
crazy
and
complex
operation.
Htfo5
got
rid
of
that
so
note
that,
just
as
unique
as
the
505
did
not
have
mlt
and
now
we
are
removing
mrd
from
test
addresses.
H
Right
so
yeah
this
I
mean
obviously
concerns
me
because
I'm
also
the
the
ad
for
pim
and
one
of
the
things
that
pim
has
in
his
plate
is
to
move
mld
v2
to
internet
standard.
H
Mean
the
fact
that
there
are
other
solutions
doesn't
mean
that
mld
cannot
be
an
interest
standard
right,
but
yes,
it
would
be
great
if
they
saw
this,
and
you
know
I
don't
know
provided
opinions
or
whatever
it
may
be.
H
It
may
give
them
ideas
on
how
to
make
him
out
be
mld,
sorry,
more
efficient
or
I
don't
know
whatever.
But
yes
so
I
searched
the
archives.
As
far
as
I
can
see,
pym
has
not
been
made
aware
of
this.
Can
you
please?
Maybe
you
send
an
email
to
pim
or
I
don't
know
if
we
need
to
get
the
six
load
chairs
to
do
that.
F
Okay,
so
that's
to
be
an
email,
but
yes,
we
need
to
congregate
with
them.
I
guess
yes,
that
would
be
neat.
Yes,
we
are
we're
removing
completely
from
the
six.
The
6lm
can
do,
unicast
any
cast
and
multicast
without
any
mld.
That's
really
the
bottom
line.
H
Right,
correct,
okay,
I
mean
so
at
least
if
you
can
I'll
go
talk
to
eric
as
well.
If
you
can
just
send
a
pointer
to
the
pin
list,
hey
you
know,
take
a
look
at
this
and
see.
If
there's
any
reaction,
I
mean
no
no
need.
I
don't
think
that
that
should
result
in
any
holding
of
the
document
or
anything
like
that,
but
just
to
get
your
reaction
from
them
would
be
would
be
good,
at
least
just
to
make
them
aware.
F
F
You're,
right
and
and
well,
we
base
also
has
a
very
complex
story
for
for
multicast,
and
this
this
makes
it
a
lot
simpler.
Actually,
so
we
we
well
incorporating
unicast
any
guest
and
multicast
in
the
same
interaction
host
to
router
would
simplify
the
operation
of
the
router
to
inject
it
in
the
vpn
as
well.
So
so
I
I
plan
to
modify
the
draft
that
you
see
here
to
also
suggest
any
custom.
Multicast.
H
And
all
we're
doing
now
that
I
see
the
word
secure,
all
you're
doing
is
multicast
targets,
not
multicast
sources.
F
Right,
oh,
it's
not
source
dependent,
it's
just!
It's
also
independent
only
because
we
we
do
that
for
repo.
So
for
now
there
is
no
way
to
in
repo
or
0.6
lopez
to
say,
source
dependent.
Yes,
it's
it's
completely
so.
B
H
D
Yeah
hi,
so
I
I
gave
you
my
feedback
on
the
six
little
list
a
couple
weeks
ago
and
we
had
a
brief
conversation
and
I
guess
the
question
I
have
is
whether
or
not
your
document
should
be
split
into
a
six
flow
and
a
role
component,
and
what
I'm
really
particularly
interested
in
is
whether
or
not
the
the
non-role
parts
of
it
will
be
easier
to
understand
by
others
without
the
role.
If
we
do
it
that
way
and
or
otherwise
what
happens
is
that
the
other
people
say?
D
Oh,
this
is
just
about
role
forget
about
that.
I
don't
run
role
on
my
network,
so
I
don't
care
and
I-
and
I
really
think
that,
for
fear
of
violating
the
russian
proverb
you
know,
good
is
good.
Enough
is
better
than
perfect
right
or
whatever
it
goes.
Perfect
is
the
enemy
of
good
enough.
That's
the
proverb
that
trying
to
do
this
in
a
more
general
way
may
actually
sabotage
us
and
doing
it
in
a
more
specific
way.
Is
that
safer?
H
This
is
something
I'll
also
talk
to
eric
klein
about,
but
I
guess
and
dominique
if
you
can
also
talk
to
six
load
chairs,
to
make
sure
that
yeah,
we
last
called
the
document
here
as
well
right
if
it's
going
to
have
ripple
elements
in
there,
we
need
that
to
happen.
D
I'm
not
really
concerned
about
that
alvaro.
I
think
that
we'll
get
that
anyway,
but
I'm
actually
more
concerned
about
the
opposite,
which
is
that
the
non-roll
parts
get
review
out
to
int
area
and
that
they
they
and,
as
you
said,
pim
okay
and
you
know
doing
things
that
that
we
really
can
seriously
consider.
This
is
a
major
that
this.
This
is
a
major
problem
I
think
out
there.
I
actually
am
debugging
mld
issues
across
the
too
many
vendor.
D
Five
different
vendors
of
switches
can
connected
together
and
it
doesn't
work
across
at
all
and
so
v6
doesn't
work
very
well
and
we're
gonna
have
to
throw
out
some
equipment
right.
So
that's
the
only
solution
we
have
at
this
point
so
nothing
to
do
with
protocols
except
that
gosh.
D
I
wish
it
would
go
away
and
not
be
a
problem,
because
it's
not
really
helping
me,
and
I
don't
think
it's
it's
that
that
I
think
that
we
need
to
move
on
to
away
from
what
I
call
layer,
two
tricks
to
make
this
work
and
and
focus
on
layer.
Three.
A
Okay,
thank
you
very
much.
Pascal
and
michael.
We
need
to
move
forward.
We
can
take
this
to
the
mailing
list.
But
yes,
if
this
document
have
role
topics
and
if
we
do
it
in
six,
no,
we
are
going
to
ask
review
for
role
as
well.
F
So
I
saw
that
the
projection
was
on
the
agenda,
but
not
really
a
full
space
for
it,
but
I
just
since
it
a
lot
happened
to
it.
I
wanted
to
give
a
very
short
status,
so
so,
basically,
the
last
revision
is
now
21
and
it
bumped
to
two
levels
because
of
the
interactions
with
dollars.
Tallest
did
the
next
cent
very,
very
deep,
very
complete,
line-by-line
review
of
the
document
both
on
content.
F
You
know
functions
and
and
structure,
so
so
you'll
see
that
the
changes
address
very
much
everything
of
that
and
I
think
it
was
really
really
beneficial
for
document.
I
hope
it's
much
more
readable
for
somebody
who
has
not
read
it
in
the
first
place.
So
that's
why
I
was
asking
ramos
to
hold
his
review
till
I
published
at
least
20.,
but
now,
as
you
realize,
it's
ready
and
I'm
happy
that
you
called
for
reverse
rs2
to
do
his
review
and
mike
as
well.
F
That
would
be
grand
based
on
you
know
the
comments
by
tallest
and
the
revision.
I'm
I'm
personally
happy
to
start
what
group
let's
go
anytime,
because
I
think
that
really
we've
got
we've
gotten
where
we
want
it
to
be
and
anywhere
good
last
call
is
not
publication
request
right.
We
still
have
to
to
get
reviews
and
feedback
and
solve
the
issues
so
mean
if
you
want
to
delay
the
workplace,
call
till
other
reviews,
I'm
fine,
I'm
also
perfectly
fine.
F
F
So
here
is
what
happened
in
one
slide,
because
I
didn't
have
10
minutes.
The
introduction
is
much
simpler,
shorter
because
we
have
a
new
section
three,
which
basically
was
requested
by
dollars
to
to
explain
the
domain.
Explain
what
the
requirement
you
know
why
we
are
doing
this
and
what
kind
of
use
case
it's
how
it's
going
to
work
so
all
the
contacts.
So
we
have
a
large
six
section,
three
now
which
reintroduces
the
story,
and
so
the
main
introduction
now
became
smaller.
F
We
have
moved
the
section
nine
up
in
that
new
section
street
I
was
discussing,
which
is
basically
all
the
context
and
end
goal
of
the
document,
so
the
whole
section,
nine
example
track
signaling,
etc
has
moved
up.
So
you
see
what
we're
doing
and
why
we're
doing
it
before
the
how
we
are
doing
it
yeah
and
there
were
some
identics
about
use
cases,
applications
blah,
and
now
this
also
moved
up
in
in
the
context
and
goal
section.
F
So
you
see
this
context
and
call
section
specifies
nothing
but
gives
a
lot
of
information
about
what
we
are
doing
and
why
we
are
doing
it
top
right
and
we
we
have
more
terms
now.
You'll
see
that
terminology
has
what
I
would
say.
F
I
would
call
domain
terminology
so
terminology
terms
that
are
not
necessarily
defined
in
this
document
by
this
document,
but
used
by
this
document
going
from
the
general
domain
of
the
knowledge,
the
general
knowledge
of
the
domain,
so
they
are
now
redefined
recited
here,
the
section
three
of
this
big
piece
and
the
second
from
top
right
new
and
move
text.
This
is
all
this
big
new
section.
Three
that
I
was
talking
about.
F
You'll
find
particulars
reflect
two
as
new
use
cases
for
making
more
complex
tracks.
F
The
protocol
operation
is
now
section
six
and,
as
you
can
see,
with
the
second
blue
arrow
on
the
bottom
right,
it's
gotten
bigger
as
well.
It
has
all
this
information
about
all
the
steps
for
creating
setting
up,
destroying,
maintaining
tracks
and
again
the
pound
or
less
request.
Bottom
right.
You
see
because
tolerance
was
asking
hey
we
plan
to
use
repo,
we
do
use,
reported
enema
the
control
plane.
So
so,
how
much
does
this
apply
to
anybody?
F
F
So
this
is
this
is
the
result
of
the
review
by
dollars,
and
hopefully
it's
a
lot
more
readable
and
more
complex,
because
you
know
tallest
did
not
leave
anything
to
magic.
You
wanted
everything
really
completely
specified,
so
I
really
appreciated
this
review
and
I'm
I'm
quite
confident
that
we
can
go
for
alaska.
You
know
with
this,
but
I'm
okay.
I
mean
waiting
for
rainbow
silver,
michael
as
well
she's
charcoal,
and
I'm
done.
That
was
all
my
slots.
A
Okay,
great,
thank
you
very
much.
Please
go
through
the
emails,
no
stories
to
the
tickets
and
close
them
if
it's
if
they
are
done.
Okay,
thank
you.
F
A
Okay:
okay,
okay,
thank
you,
content.
E
Yes,
I'm
here
can
everybody
see
me
hear
me
at
least.
E
E
So
what
I
did
is
mostly
from
the
working
group
members,
so
they
concerned
like
floating
products,
virtual
dock
routes
and
sentinel
selection,
and
also
some
minor,
like
editorial
comments
by
michael
and
pascal,
and
also
I
added
one
section
which
allows
for
activating
and
deactivating
the
protocol
on
demand,
and
I
found
this
useful
like
if
you
don't
want
to
use
it
or
want
to,
for
instance,
deactivate
it
because
of
I
don't
know
high
false
positive
rate
or
do
some
like
emergency
deactivation,
then
this
is
what
it
can
be
used
for.
E
So
so
I
think
that
the
protocol
now
addresses
all
major
comments.
I
also
went
through
the
the
talk
during
the
the
recording
from
from
the
interview
about
pascal's
comments
and
well,
I
think
some
of
them
are
beyond
the
scope
and
some
of
them
well.
E
They
cannot
be
like
easily
addressed
so
especially
about
some
parameters
of
the
protocol.
Being
global,
but
I
don't
think
that
well,
they
constitute
much
of
a
problem.
So
the
question
now
is
whether
we
want
to
adopt
the
draft
or
not.
I
guess,
and
if
you
have
any
further
questions,
then
I
can
reply
now
or
via
email.
G
F
F
Okay,
so
I
produce
power
yeah
and
I'm
not
using
my
headset,
because
wireless
and
sometimes
the
mic
goes,
and
so
it
doesn't
help
a
lot.
So
sorry,
I
did
not
move
to
your
recommendation.
So
what
I
was
saying
is
this
is
this
is
classical
byzantine,
general
problem
right.
So
so
you
you
have
to
find
an
agreement
between
at
least
two-thirds
of
the
interventions
to
to
decide
whether
something
is
true
or
not.
F
It's
it's
very
hard
private
general,
and
then
we
have
this
issue
that
you're
trying
you
are
trying
not
to
go
through
the
root
which
makes
the
prime
of
another,
because
for
many
of
those
generals,
only
the
route
is
is
available
to
talk
between
one
another
another.
So
this
this
is
a
hard
problem.
F
The
nodes
need
to
know
if
the
root
is
still
there
and
and
they
need
to
know
rapidly,
so
we
I
believe
we
need
to
adopt,
because
we
want
this
problem
solved,
but
we
we
want
to
be
very,
very
sure
that
it's
not
because
we're
adopting
this
document
that
we
are
completely
sure
that
the
inceptions
you
know
the
basic
mechanism
proposed
here
is:
is
the
right
one,
there's
a
lot
of
art
to
to
resolve
consensus
and
that's
exactly
what
where
this
work
falls
in
it's
consciousness
resolution
we
need
to
make
sure
that
we
have
explored.
E
That
would
be
fine.
I
I
can
imagine
that
we
can
still
correct
the
algorithms,
like
the
initial,
let's
say
command
more
specifically,
so
some
issues
are
left
out
of
the
algorithm
like
they
are
like
external
to
the
algorithm,
and
perhaps
it
would
make
sense
to
actually,
for
instance,
to
get
rid
of
some
of
the
parameters
to
actually
include
like
routing
through
the
root
and
so
on.
So
yeah.
F
B
D
D
B
B
B
A
Okay:
okay,
thank
you
anna
for
about
the
next
topic,
the
enrollment
priority.
We
got
a
preview
from
conrad
and
where
the
contract
proposed,
like
two
use
cases,
global
and
flexible,
two
no
use
cases
two
different
way
of
addressing
for
global.
We
have
this
total
control
congestion
but
load
balancing,
but
for
flexified
we
did
not
find
any
use
case
so
far,
but
for
this
document
we
will
need
more
reviews
and
there
are
some
open
issues
in
github
and
then
I
think
we
can
go
through
workgroup
last
call
someone
volunteered
to
review
this
draft.
D
They
say
that
I
think
that
probably
the
authors
haven't
really
gotten
together
to
discuss
this
enough
and
we
probably
should
do
that
schedule
something
and
do
that
and
I
think
it's
fallen
below
the
below
the
fold
priority
wise
for
us
to
review
this.
So
clearly
we
want
to
have
something
in
the
solution
and
it's
possible
that
what
we
proposed
is
simply
unworkable.
D
But
then
I've
heard
other
people
say
it's
not
a
problem,
so
it
might
be
that
we
have
to
re,
go
step
back
and
try
again
with
capabilities
or
something
I
don't
know.
F
Yeah,
I
think,
michael,
I
think
it's
perfectly
workable
and
that
we
should
ship
it
because
the
again
why
sun
is
asking
for
it
and
this
draft
fits
what
they
want
and
they
have
an
operational
understanding
of
what
they
want.
So
no,
I
don't
think
we
went
outside
the
the
one
thing
that
that
we
missed
was
we
at
some
point.
We
thought
that
this
value
this
priority,
that
we
are
mean
priority,
that
we're
passing
should
be
changed
on
the
way
down
and
that
made
it
unworkable
effectively.
F
But
if
we
agree
that
it's
set
by
the
root
and
just
propagated
without
the
change
down,
you
know
the
dios.
Just
what
you
expose
on
on
the
beacon
can
be
based
on
that
and
can
be
different
from
that.
But
but
at
least
it's
it's
going
down
unchanged.
Then
it's
perfectly
workable
and
perfectly
useful.
D
I
think
that
that's
what
we
yeah
and
I
I
don't
think
we
really
got
that
clearly
into
the
document,
the
last
revision,
but
that's
what
I
think
we
need
to
do
and
if,
if,
if
I
just
not
sure,
I
just
wasn't
sure
that
the
authors
were
all
in
consensus
about
this.
At
this
point,
because
I
don't
think
we
discussed.
F
F
F
D
So
I
will
get
a
new
revision
posted
by
the
end
of
the
month
and
if
that
isn't
is
good
enough,
did
we
start?
Did
we
do
a
working
group?
Last
call?
Are
we
in
the
middle
of
working
group?
No
we're
not
we're
just
in
the
middle
of
nowhere.
G
G
A
B
Yeah,
I
think
we
achieved
good
good
progress.
Thank
you
very
much
everybody
for
your
involvement
and
let's
get
back
on
track.