►
From YouTube: IETF104-6LO-20190325-1350
Description
6LO meeting session at IETF104
2019/03/25 1350
https://datatracker.ietf.org/meeting/104/proceedings/
B
Okay,
hello,
hello:
everyone
can
you
hear
me
now?
Is
it
better
yeah?
Thank
you.
Okay,
hello.
Welcome
to
the
Knitting
of
the
six
slow
working
group.
Please
make
sure
that
you
are
in
the
right
room,
so
my
name
is
Carlos
Gomez.
This
is
shorter
Bhandari
and
we
are
the
new
church
for
the
six
log
working
group.
As
you
may
recall,
the
former
chairs
Gabrielle
and
Samhita
stepped
down
a
few
weeks
ago,
so
we'd
like
to
thank
them
once
again
for
their
work
and
their
help.
B
During
this
time,
our
responsibilities
suresh
krisshnan
to
day
he
hasn't
been
able
to
attend
in
person.
However,
we
have
Erik,
we
may
help
today
and
we
have
a
minute
taker
Dominique
who
volunteered?
Thank
you
very
much
Dominic,
instead
of
perhaps
anyone
who
would
like
to
be
a
second
minute
taker
to
help
Dominic.
B
Well,
thank
you,
okay,
so
we
have
a
ascribe
the
whole
thing
very
much
for
volunteering,
and
on
this
slide,
you
may
find
a
number
of
pointers
to
important
resources
such
as
the
only
an
agenda,
the
jabber
room,
the
meet
echo
and
the
ether
pad
by
the
way
I
guess
the
meaning
will
be,
and
the
second
minute
ticker
will
be
using
the
iPad,
so
feel
free
to
join
better
path
and
complement
what
is
being
written.
Okay,.
B
This
is
the
agenda
for
today,
after
the
chairs
introduction
we'll
have
a
batch
of
presentations
of
documents
related
with
neighbor
discovery
given
by
Pascal.
The
first
is
the
status
of
waking
Google
Scholar
on
I
just
protected
naval
discovery.
The
second
is
the
status
and
publication
requests
of
the
backbone
water
document,
and
the
last
one
is
in
the
unicast
lookup
and
some
questions
towards
considering
working
rep
adoption.
After
that
we
have
Charlie
who
will
present
the
packet
delivery
deadline.
B
C
D
The
author
of
the
IPC
so
NFC,
actually,
we
had
some
touch
hat
from
of
the
IIE
SG
and
I
got
some
comment
and
discuss
from
the
the
is
chauchat
and
Diane
I'd
like
to
thank
first
I'd
like
to
thank
the
authority.
Also,
videos
from
from
the
the
iesg
and
I
have
plan
to
address
a
little
reviews,
as
as
possible
and
I
will
produce
a
pet
rat,
be
the
new
text
about
the
auto
comment
and
discuss.
That's
what
thank
you.
Okay,.
C
B
C
D
E
B
Thank
you.
So
again,
since
the
last
idea,
we
have
a
new
era
of
seeds.
Eighty
five
zero
five
registration,
extensions
for
6lowpan,
maybe
discovery.
So
congratulations
to
the
authors
and
thanks
to
everyone
involved,
then
we've
already
commented
on
ipv6
of
our
NMC.
Then
the
next
draft
is
packet
delivery
deadline
document
which
was
submitted
to
the
ASG.
It
received
a
number
of
release
from
several
directorates.
The
offers
produced
a
new,
a
date
of
the
draft
and
we'll
present
it.
Today,
then,
we
have
a
number
of
documents
for
which
working
Robles
call
ended.
B
The
first
is
the
backbone
router
document,
and
the
next
step
here
is
to
get
the
Shepherd
right
up.
Then
we
also
have
the
six
will
use
cases
for
which
working
group
last
call
ended.
However,
without
feedback
from
the
working
group.
So
we'll
have
a
discussion
today
on
how
to
proceed
with
the
next
steps,
and
there
was
also
working
with
last
call
for
ipv6
measure
ble
links.
B
There
were
a
number
of
comments
on
the
content
of
the
document,
so
the
authors
produced
in
a
date
of
this
draft
based
on
the
comments
we
represented
also
today,
then
few
days
ago.
The
working
class
Co
on
the
address,
protected
neighbor
discovery
ended
as
well
so
we'll
talk
about
this
also
today
and
we
have
the
minimal
framing
forwarding
document.
The
authors
have
expressed
that
it's
ready
for
working
of
Lascaux
and
the
fragment
recovery
document
has
been
updated.
B
F
Take
it
like
this
much
better
okay,
so
it's
a
series
of
four
drafts
that
relate
to
basically
unicast
registration
and
then
mock-up
for
ipv6
addresses
in
order
to
avoid
the
use
of
reactive
multicast.
As
we
know
it
today,
which
is
detrimental
to
IOT
devices,
which
can
be
sleeping
or
battery-operated,
it's
also
detrimental
to
wireless
in
general
of
our
fabric,
so
we'll
be
discussing
that
I'm
talking
about
and
met
expectations,
because
between
di
chip,
I
Triple
E
and
the
ITF.
F
There
are
a
series
of
expectations
quote-unquote
from
the
other
sides
that
were
never
met,
but
in
particular
the
IETF
expected
that
Wi-Fi
would
provide
reliable
and
economical
multicast
services.
Just
like
Ethernet,
and
we
all
know
it's
not
the
case.
Multicast
is
not
reliable
because
it's
not
acknowledged
it's
also
slow.
Usually
you
have
to
say
that
the
slowest
speed
speeds
possible
on
maximum
power
possible,
so
it's
very
detrimental
to
the
unicast
traffic.
On
the
other
hand,
the
I
Triple
E
was
expecting
from
the
IETF
that
proxy
open
proxy
neighbor
discovery
to
happen
at
Jax's
point.
F
If
you
look
at
it,
an
access
point
is
a
proactive,
transparent
bridge.
The
association
process
is
all
about
proactively
installing
the
MAC
address
of
the
station
into
the
access
point.
So
that
later,
when
there
is
a
lookout
for
that
MAC
address,
the
broadcast
is
not
propagated
about
the
wireless,
because
the
LP
already
knows
that
it
serves
this
particular
MAC
address.
So
what
does
full
trust
cannot
do?
Is
emulate
this
association
process
for
ipv6.
They
are
three,
but
the
concepts
are
exactly
the
same.
Mabel
discovery,
Randolph
unreactive.
F
That
means
that
when
you
look
for
new
tries
you
have
to
broadcast
through
the
network,
which
is
highly
detrimental
to
well
as
the
the
protocols
that
were
looking
at
will
enable
to
register
the
addressed
to
the
router
could
encode
the
access
point.
So
this
registration
is
pretty
much
a
layer,
three
association
and
then,
if
the
registration
is
about
getting
proxy
and
D
services,
then
the
mother
of
those
drives
the
proctor
the
backbone.
Router
draft
will
do
this
proxy
operation
that
J
Triple
E
was
waiting
for.
F
So
now,
after
those
drafts
RFC,
we
can
really
talk
about
fulfilling
the
expectations
that
were
never
fulfilled
so
far.
So,
like
I
said,
this
is
a
series
of
four
drafts.
Aeschylus
introduced
the
first
of
the
four
drafts
that
the
news
since
last
IETF-
it
just
happened
right
after
the
ATF
during
the
I
Triple
E
meeting
in
Bangkok,
so
the
67
75
F
that
draft
became
RFC.
Eighty
five,
four
five,
so
that's
great
news.
I-
will
tell
you
more
about
that.
F
A
bit
later,
the
backbone
router,
the
proxy
that
goes
with
this
association
pass
well
go
class,
go
another.
Has
the
unmet
expectation?
What
the
address
protection
we
have!
This
Savi
WorkSource
address
validation
that
has
been
at
the
ATF
for
a
long
time.
We
know
that
we
want
to
protect
the
ownership
of
an
address
but
say
on
security
was
never
a
very
efficient
answer
to
that
prom
and
it
was
not
deployed.
Now.
We've
got
the
new
address
protection
work
which
just
passed
workgroup
Losco,
which
provides
an
efficient
solution
for
this
na'vi
problem.
F
It's
really
like
you
get
destroying
in
the
Tokyo
Station
that
the
empties
and
all
those
those
guys
have
their
phone
with
them,
but
they
all
want
to
connect
to
the
Wi-Fi
and
get
immediate
connectivity,
because
you
know
they
will
stay
on
the
station
for
just
a
few
minutes
and
during
those
few
minutes,
then
to
have
done
everything
they
need
to
do.
So
you
don't
want
to
wait
for
that
to
complete
after
one
second
and
things
like
that,
you
want
you
to
get
you
address
immediately.
You
want
to
make
sure
it's
unique.
F
You
want
to
communication
to
start
like
in
in
less
than
a
second
everything
included.
So
one
of
the
ways
to
improve
a
situation
like
this
is
to
actually
enable
what
we
call
a
6
lb
R,
which
is
this
register
out
that
we've
introduced
with
Ric
6775,
but
also
I,
have
one
on
the
on
the
backbone
itself.
So
it
would
actually
serve
the
ethernet
people.
F
So
now
you
can
do
a
little
lookup
for
unique
as
you
look
up
to
that
6
lb
r
and
know
which
is
the
MAC
address
for
that
particular
device,
or
you
could
ask
the
6
lb
r,
whether
these
addresses
already
taken
and
if
it's
not
taken,
then
that
is
complete
without
waiting
for
a
second.
So
this
is
what
the
last
draft
does
it.
Basically
propagates.
The
concepts
that
we
had
in
the
wireless
piece
of
the
network
in
the
6
lb
are
actually
now
plays.
F
A
6
lb
are
on
the
backbone,
so
we
can
avoid
broadcast
even
on
the
backbone.
So
this
is
a
little
bit
more
context.
This
is
the
text
of
the
current
specification
from
a
triple
it's
just
an
excerpt
of
what
I
was
telling
you
about
that.
They
are
this
expectation
that
we
provide
proxy
neighbor
discovery
and
they
say
basically,
you
have
to
respond
to
messages.
F
Well,
there
is
a
bit
more
than
this
description
to
really
doing
discovery
proxy
and
she
looks
through
the
backbone
water
trust
and
you
will
find
all
the
things
we
had
to
do
to
actually
provide
a
good
service
for
neighbor
discovery.
Now,
instead
of
this
text,
now
we
are
fighting
IDI
Tripoli
to
get
this
new
tax.
F
This
is
this
is
the
set
of
changes
that
we
are
proposing
to
the
a
to
2.11
group
for
the
main
specification,
and
you
will
see
that
RFC
8,
5,
4
5
is
already
quoted
here
and
that
text
actually,
when
we
proposed
it
before
the
ATF
di
Tripoli,
add
RFC
67
75
update,
because
the
RFC
number
was
granted
like
on
Wednesday
during
the
I
Triple
E
meeting,
so
we
swapped
the
text
during
the
meeting
itself.
The
first
times
I
presented
that
and
some
my
Tripoli
meetings.
F
It
was
early
update
to
be
RFC
and
at
the
end
of
the
meetings
it
was
RFC
8,
5,
4
5,
so
that
was
kind
of
nice
and
as
you
see,
these
takes
now
as
explanation
on
why
you
need
a
trance
protection
and
you
need
backbone
router,
it's!
So
you
see!
It's
a
bit
more
text,
but
at
least
they
understand
that
ipv6
is
not
ipv4.
F
F
So
the
devices
that
comes
up
with
multicast
and
arise
that
will
get
an
error
unicast
from
the
6l
r,
which
is
the
AP
and
that's
how
it
will
know
immediately
when
it
wants
that
there
is
a
network
right
there
and
this
safety
error
a
broadcast
which
are
mostly
unused
on
layer,
2
network
and
then
the
registration
chair
itself,
which
is
the
Association.
We
are
talking
about
it's
this
NS
with
this
new
ero
extension
to
the
eruption,
address
registration
option.
F
So
that's
a
1/2
between
the
station
and
the
AP,
and
then
there
is
this
IP
message
can
go
as
far
as
it
likes
to
the
Registrar,
which
is
the
duplicate,
address
registration
message
that
we
extended.
So
so
you
are
now
so
there
are
a
number
of
changes
to
the
address
registration
process
for
the
interest
of
the
discussion
today.
F
Can
be
a
private
or
public
key,
so
you
can
see
already
that
if
you
transport
a
public
key
associated
with
the
first
address
registration
and
if
the
Registrar
stores
that
public
key
in
some
form
and
and
can
actually
challenge
later,
the
device
for
ownership
of
the
private
key
that
goes
with
it,
then
we
can
actually
make
sure
that
anybody
who
claims
to
change
something
about
an
address
is
the
actual
owner
of
that
address
right.
You
can
see
that
we
can
prove
the
ownership
as
we
need
it
during
the
life
of
the
address.
F
F
Ok!
So
that's
like
five
four
five:
the
change
that
the
experience
that
the
draft
that
experienced
the
most
changes
since
last
IETF,
my
sumo
heat
in
the
room,
actually
is
the
address
protection
draft.
So
this
is.
This
is
the
thing
which
ensures
that
the
guy
who
created
your
dress
and
register
the
first
time
so
first-come,
first-serve
properties,
is
when
things
move
when
the
address
is
registered.
Maybe
someone
else
is
the
owner
of
the
first
registration.
When
you
send
out
a
packet,
that's
a
source
at
that
address.
F
F
F
So
that's
this
capability
to
use
different
sets
of
things
so
as
to
save
some
footprints,
some
code
in
your
mode
that
we
actually
proposed
you're
just
12.
Those
combinations
are
our
C
and
one
is
not
basically
so
those
two
are
FC
and
this
one
is
kind
of
a
mix
of
the
truth
and
the
compared
to
before.
The
flow
is
like
this.
When
you
register
your
dress,
if
the
six
era
did
not
see
you
before
so
doesn't
know
that
you
really
own
that
address,
it
will
challenge
you
with
the
norms.
F
The
device
comes
back
with
a
pair
of
notes,
the
nonce
it
got
and
sat
mounts
a
super
option
and
dpo
option.
One
of
them
is
a
signature
option.
The
second
one,
the
first
one
is
basically
you're
the
components
that
I
used,
including
my
public
key
plus
order
information
to
build
this
cryptographic
token
that
is
placed
in
the
rubber
field
of
the
address
registration
option.
So
basically,
I
said.
F
Imagine
it's
a
public,
it's
not
Republican
more
information
stuff
into
it
and
asked,
but
at
the
end
of
the
day,
it's
as
if
it
was
a
public
key
and
then
those
options
basically
allow
you
to
sign
something
based
on
the
private
key
that
goes
with
it.
But
the
thing
that
you
signed
as
a
nonce,
which
was
a
challenge
from
the
six
lr+
announce
that
you
just
generated
to
make
sure
that
this
thing
is
unity.
F
Okay,
so
you
see
that
FC,
eight
five,
four
five
created.
Actually
the
changes
in
your
options
to
create
well
to
have
this
field,
this
rubber
field,
this
ownership
verify
option
to
newborn
size.
So
we
can
go
all
the
way
to
five
twelve
and
Ronnie.
Actually,
I
did
some
text
advanced
text
to
advance
for
me,
so
you
just
read
it
about
possible
attacks
and
what
needs
to
be
done
about
this
so
you've
got
this
takes
in
the
Security
section
of
the
draft
and
that's
pretty
much
it
for
that
drafts.
F
B
A
But
this
dart
went
through
the
world
which
concluded
last
week.
We
didn't
hear
anything
from
the
workgroup
either
in
support
or
against
it,
but
it
has
gone
through
a
bunch
of
reviews
already.
So
what
is
the
opinion
of
people
in
the
room
about
progressing
there's
draft
further?
Do
we
need
extra
reviews?
Do
we
need
to
go
to
six
man
and
get
it
reviewed
for
anyone
this
one?
Let's
move
the
backbone,
the
backbone.
A
F
It's
more
the
situate
and
we
get
Russell
a
and
providing
us
with
a
advance.
The
early
security
review,
so
I
think
we're
all
set.
We
can
progress
that
document.
The
backbone
router
is
going
to
be
a
lot
of
discussion
because
it
has
more
of
an
impact
to
six
men,
so
maybe
six
men
or
India
one
of
those
two
should
you
know
we
could
have.
We
could
get
a
review
of
to
to
make
sure
before
we
the
button,
but
for
this
one
we
can
go
ahead.
I
mean
we
got
the
only
security
with
you.
Okay,.
A
F
The
next
draft
is
it's
much
thicker,
because
that's
this
access
layer,
free
access
point
we
have
to
kill
about
this-
is
the
proxy
neighbor
discovery
functionality.
So
this
draft
has
been
there
for
a
long
time.
It's
actually
something
which
started
when
RFC
6775
started
and
that
we
split
out
of
it
and
that
was
left
government
for
a
while
and
resurrected
like
two
three
years
ago
there
is
implementation
da.
There
were
a
good
number
of
figures.
F
We
went
through
a
group
last
call,
but
we
didn't
go
through
six
men
or
in
pre
India
review,
so
whichever
of
those
two
might
be
Suresh,
if
so
she's
with
us
now,
I,
don't
know
if
you
can
hear
him
you're
us,
but
we
could
ask
Suresh
for
advice
on
this.
Whether
we
should
go
to
six
men
ought
or
just
name
some
receivers
on
your
receivers,
but
I'm
up
here
to
get
an
early
review
before
we
press
the
button
for
publication.
F
F
So
you
do
the
NS
address
registration
option
actually
extend
it
now,
and
what
the
six
PPR
does
is
transform
this
unicast
proactive
registration
in
to
broadcast
their
the
classical
and
the
operation,
and
you
have
to
wait
for
one
second
before
that
completes,
etc.
So
you
expect
the
distributed
reactive
and
the
classical
ND
on
the
right
on
the
east.
On
that
side
and
on
the
are
you
t,
/
Wi-Fi
side,
it's
going
to
be
a
proactive
registration.
F
Or
here
it's
a
ripple
mesh
and
because
there
is
a
registration
for
that
address,
the
60
BR
will
respond
to
DNS
lookup.
It
may
provide
its
own
address
to
be
clean,
the
ripple
Network
it
will
provide
some
like
address
with
Wi-Fi.
You
could
also
act
as
a
bridge
and
provide
the
MAC
address
of
the
600
of
the
stuff.
In
that
case,
the
data
would
be
bridged
directly
to
the
device,
because
the
MAC
address
that
is
known
here
is
the
device
MAC
address,
but
was
rife
with
with
reborn
doing
a
mesh
here.
F
This
is
VDI
will
respond
with
its
own
MAC
address
it
acts
as
a
rotten
proxy,
so
the
packet
will
reach
the
6p
BRTS
free,
which
will
rot
them
because
it
has
a
host
rot
down
to
the
wireless
side
so
both
mode.
Actually,
so
you
see
the
rotted
version
and
the
switch
version,
the
switch
version,
the
data
packet
is
all
the
way
to
the
registering
node
back
address.
So
in
that
case,
this
node
acts
as
a
switch
as
an
AP.
F
Both
modes
are
available,
so
that's
it
for
the
three
trusts
which
really
made
a
long
ways
for
this
working
group,
but
the
interesting
piece
we
have
a
new
draft
and
this
new
draft.
We
have
actually
matches
a
number
of
modern
deployments
that
we
find
now
in
the
field,
the
point
being
that
we
don't
have
a
standard
way
to
actually
achieve
what
I'm
saying.
So
it
usually
goes
through
proprietary
implementation,
proprietary
protocols.
F
Server
map-resolver,
but
it's
outside
of
the
domain
of
discovery
and
neighbor
discovery
cannot
benefit
from
it.
What
what
this
is
proposing
is
that
you
actually
use
a
variation
of
the
of
what
we
already
have
in
this
series
of
drafts
to
populate
this
six
lbr
and
make
it
copied
Lee
vendor-independent.
F
F
So
what
we
are
doing
here
is
inside
this
tag
that
was
reserved
for
duplicate
address.
We
actually
provide
a
new
code,
remember
ICMP
as
a
type
and
then
a
code.
We
actually
have
a
variation
on
the
code,
but
and
we
reduce
the
type.
So
we
don't
consume
more
space
in
the
ICMP
namespace
and
we
can
do
this
address
lookup
as
well
as
duplicate
address
validation.
F
F
Because
it's
a
resolution,
we
also
needed
to
add
the
source
link
at
reception
or
the
target
link
layer
at
reception
into
these
messages.
So
it's
a
very
natural
thing
to
do.
Remember
in
ng,
NS
is
used
for
that
and
it's
used
for
lookup.
What
we
are
doing
now
is
the
unicast
version
of
that
which
is
the
Adar,
becomes
also
a
unicast
lookup
myth
that
we
do
that
without
consuming
more
space
in
the
ICMP
type.
We
just
do
the
next
logical
thing
and
that's
pretty
much
what
this
draft
is
about.
F
What
I've
represented
to
you
remember
at
the
very
beginning
of
my
speech,
I
I
promised
you
that
we,
we
could
consider
the
case
of
the
Tokyo
Station
and
the
people
going
outside
of
the
Train
at
the
Tokyo
Station
now
I'm
proving
it.
This
is
the
flow.
So
what
really
happens
when
this
Wi-Fi
fails?
Device
gets
out
of
of
the
train,
but
it's
gonna
do
is
gonna
sound,
an
arrest,
multicast?
Oh
maybe
somebody
else
has
sent
it,
but
well
it's
going
to
send
in
a
response
case.
Usually
that's
how
it
happens.
F
It's
gonna
get
immediately
in
an
array.
Unicast.
Remember
the
the
multicast
is
not
rebroadcast
it
anywhere
because
it's
when
I
started
AP
and
the
the
the
real
broadcast
is
always
done
by
the
AP.
So
whether
you
send
that
as
a
multicast
or
as
a
unicast
doesn't
matter,
it's
just
a
single
packet
good
as
unicast
intercepted
by
the
access
point,
which
is
a
6bb,
are
never
broadcasted
anywhere
just
answered
unicast.
So
this
does
not
represent
a
broadcast
at
all.
F
So
now,
from
this
array,
my
star
as
a
Pio
prefix
information
option,
I
can
form
an
IP
address,
just
say
mo
to
confess
before
you
can
use
any
randomization
I
mean
we
have
enough.
Arab
sees
now
to
do
that.
Now
you
can
send
an
address
registration
option
to
the
six
PBR.
If
we
have
this
6
lb
are
on
the
backbone
that
I
just
mentioned
this
new
thing
with
the
first
RC,
then
we
can
do
another
hijack
if
that's
the
only
validation
method
that's
needed.
F
F
If
it
was
not
already
there,
that's
the
optimistic
that
thing,
then
the
router
can
go
back
to
see
PBR,
which
can
go
back
to
the
to
the
staff
and
that's
how
the
traffic
can
start
right
away,
and
you
see
that
that
timeout
is
a
lot
later.
It's
here,
but
sure
what
we
re
doing
is
using
an
SL
errors
really
to
populate
the
state
in
the
router,
and
then
the
router
doesn't
have
a
state
both
to
do
an
SMA.
F
F
F
F
A
F
G
A
F
F
If
you
want
to
scale
the
network
you
want
to
allow
many
devices
must
be
well
as
that's
really
what
scares
you
let
walk
up.
This
is
of
importance,
and
yes,
after
that,
I
would
like
rapid
adoption
once
I
get
enough
reviews,
because
this
draft
is
behind
the
others.
It's
way
behind
and
could
be
good
to
catch
up.
C
Together,
like
you
know
a
couple
of
years
ago,
in
six-man,
the
efficient
nd
stuff
with
Eric
and
samhita,
and
we
ran
into
quite
a
bit
of
opposition
so
like.
Why
do
you
think
this
draft
will
be
different
so
that
I
don't
want
you
to
answer
this
right
now?
But
if
you
want
to
like
proceed
further
with
this,
I
want
you
to
think
about
it.
So
go
back
and
look
at
the
objections.
G
G
G
G
So
well,
I,
don't
have
to
say
too
much
about
this,
but
we
have
been
all
along
responding
to
comments
as
they
were
received
on
the
draft.
So
now
the
issues
I
mentioned,
we
had
gotten
reviews
from
various
directorates,
and
so
these
are
the
people
that
submitted
comments
and
most
of
the
comments
had
to
do
with
this
desynchronisation.
Basically
so
I.
G
Believe
it
was
Dale
whirly
that
suggested
that
it
was
sort
of
not
a
good
idea
to
have
a
multiple
ways
to
represent
the
same
time
and
with
the
previous
design
in
the
draft
it
was,
you
can
have
really
climb
many
different
representations
for
the
same
time
in
the
future.
So
just
some
of
the
new
design
is
intended
to
address
that,
but
also
there
was
a
discussion
about
how
do
you
really
know
what
is
time
to
equal
to
equal
zero?
G
None
other
words
the
start
time,
if
you,
let's
say
you
say
the
deadline,
time
is
a
thousand
and
ninety-four
well
2094
starting
win.
So
we
were
okay
with
the
unit's
to
count
the
time
in,
but
we
were
just
assuming
that
the
synchronization
between
the
networks
would
also
take
care
of
what
time
to
equal,
zero
meant,
and
so
the
new
draft
doesn't
quite
make
that
assumption.
It's
much
more
explicit
about
how
choosing
the
different
time
representations
affects
the
synchronization,
so
there's
a
whole
new
off.
G
So
yes,
so
I
should
mention
that
also
as
part
of
the
problem
of
having
multiple
time
representations,
the
reviewers
suggested
that
we
should
actually
use
an
existing
time,
representation
in
particular
integral
so
I
looked
at
the
NTP
document
and
there's
a
64-bit
version
and
a
32-bit
version.
The
32-bit
version
is
derived
from
I
Triple,
E,
1588,
I,
believe,
and
so
those
two
representations
are,
you
might
consider
standard
and
are
they
are
standard.
G
So
it
was
also
observed
by
one
of
the
reviewers
that
we
didn't
have
to
use
the
full
number
of
bits
for
the
origination
time.
We
could
use
a
delta
and
just
have
the
Delta
be
subtracted
from
the
deadline
time,
because
if
we
specify
the
Delta
then
that
you
can
get
their
origination
time
quite
simply,
and
usually
the
Delta
is
much
smaller
number
of
bits
required.
G
Finally,
since
we
didn't
want
to
allow
for
so
many
different
representations
for
the
same
time,
we
really
got
rid
of
this
exp
field
and
in
favor
of
a
way
of
moving
the
binary
moment
left
or
right
to
allow,
if
either
for
more
integer,
bigger
integer
part
are
more
fractional
bits
in
the
fractional
part
and
with
the
NTP
document,
the
64-bit
and
a
32-bit
representation
at
equal
number
of
bits
for
the
integer
part
and
the
fractional
part.
But
with
this
binary
point,
Missy
can
I
point
edit.
G
G
Modifications
to
the
packet
format,
they
specify
the
new
fields,
and
so
you
can
see
that
here,
whereas
the
previous
format
had
the
exp
and
the
reserved
bits.
Now
we
don't
have
the
obit
anymore,
because
that
meant
to
say
that
the
origination
time
was
optional,
but
now
the
origination
time
is
going
to
be
optional.
If
the
number
of
bits
and
the
origination
time
Delta
is
zero,
so
that
means
basically,
you
are
sending
in
the
origination
time
or
and
just
you're
just
sending
the
deadline
time.
G
How
about
now
that's
better
yeah.
That
was
pretty
obviously
I
need
to
do
that
instead,
so
anyway,
the
binary
point
here
is
up
to
six
bits
and
that
that
actually
allows
to
move
the
binary
point,
32
bits
to
the
left
or
to
the
right,
and
that's
pretty
much
as
much
precision
as
you
might
need
for
that
see
what
else
we
have
and
now,
instead
of
bytes,
these
are
counted
in
hex
digits.
So
that's
a
little
bit.
It
allows
for
somewhat
more
compact
representation.
G
All
right,
so
here's
an
expanded
version
of
what
I
just
said
and
I.
Don't
think
I
need
to
say
it
all
again,
except
I'll.
Just
mention
that
this
destination
time
length
is
actually
a
number
of
hex
digits.
You
should
add
one
to
it
that
allows
you
to
have
destination
time,
length,
zero
to
actually
mean
something.
So
you
add
1
to
the
value
of
this
4-bit
field,
to
get
the
total
number
of
hex
digits
that
are
allowed
to
be
used
in
the
destination
time,
and
then
that
can
give
you
a
quite
wide
range
of
of
numbers.
A
G
F
Can't
you
be
Charlie,
we
I
think
the
answer
is
no,
but
I've
not
read
the
latest
version.
I'm.
Sorry
for
that
at
some
time
during
the
deception
of
this
document,
because
you
just
mentioned
the
reason
why
I'm
asking
is
you
just
mentioned
the
forwarding
activity
based
on
deception
right,
my
understanding
is
the
forwarding
activity
based
on
that
option
is
drop
or
not
dropped
based
on
the
maximum
delay
for
this
packet.
G
So
this
is
about
the
D
bit.
The
debug
gives
you
the
option
of
not
dropping
the
packet,
even
if
it's
past
the
deadline
and
there's
some
text
in
the
draft.
That
says
why
you
might
want
to
do
that
and
circumstances
under
which
you
should
not
forward
the
draft.
When
you
know,
even
if
you
had
the
option
to
do.
G
A
G
C
H
Hi
TC
a
6-row
applicability
and
use
case
document,
and
my
name
is
Jung
Geun
horn.
So
you
know
in
this
document
there
are
lots
of
the
author's
or
me
I'm,
the
also
of
the
PRC
or
energy
document,
and
Carlos
Gomez,
his
expert
and
Brutus
and
Brutus
mesh
and
you're
on
choice,
expert
or
NFC
and
are
Zanghi.
Is
the
experts
of
the
PRC
and
take
an
issue,
is
expert
of
the
MSTP
and
arid
or
that
15.4
technology
and
Sangeeta
also
involved
in
this
document?
So
you
know
many
experts,
including
the
sixth
row.
H
Technology,
are
involved
in
this
document,
so
yeah-
and
this
is
the
sixth
version,
so
you
know
the
working
group
adoption
was
done
in
three
years
of
people,
and
this
is
six
boards
on
and
Sokol
of.
This
document
is
to
help
sick
flow
situations.
Take
the
patient
I
there
to
control
technology
and
help
out
newcomer
understand
how
six
repairs
there
can
be
applicable
in
practice.
So
we
have
TC
purple
new
adapter
or
I
adhere.
So
I
noted
the
sixth
row
expert.
H
H
Okay,
this
is
the
next
step,
so
in
my
side,
in
this
structure
up
oh
six
row
deployment
scenario
in
the
real
field,
one
is
on
Teddy's
chapatti
mesh.
Why
son
and
chief
repair,
see
and
ethnicity,
so
among
them,
I
heard
that
the
trustee
is
moving
to
from
control
power
lines
to
my
son
Alliance,
but
until
now
there
are
door
or
peace
or
annulment.
So
I
am
double
checking
about
his
chains,
but
there
are
no
official
announcement.
So
if
some
chains
about
their
tryst
is
head
point
and
I
will
update
yeah.
H
So
it
is
my
inside
next
step
and
I
would
like
to
ask
other
person
to
debut
this
draft,
and
it
is
very,
very
odd
to
say
to
keeps
your
comment.
What
is
the
missing
point?
What
is
the
wrong
text
about
six-row
technology
and
what
we
give
abroad
did
or
what
you
need
aboard
to
deploy
640
Canaries
in
the
audio
world?
A
So
what
should
be
the
next
steps,
given
that
it's
a
it's
a
living
document,
do
you
do
you
want
to
publish
it
as
an
informational
draft,
or
should
we
do
something
like
keep
it
in
in
the
sixth
floor
icky,
and
so
that
anybody
joining
the
six
lower
group
could
make
use
of
it?
What
are
your
thoughts
on
progressing
this
with
with
a
reference
in
the
wiki?
The
the
data
here.
A
F
B
H
F
B
A
A
C
And
that's
why
I
was
a
bit
concerned
that,
like
you,
we
are
going
for
RFC
and-
and
second
thing
is
the
scope
of
the
draft
which
I'm
not
sure
about
as
well.
So
I
think
the
scope
is
like
pretty
big
for
this
draft,
so
I
think
if
we
decide
to
go
for
publication,
I
think
we
need
to
probably
chop
down
a
bit.
H
Okay,
thank
you
wish.
Yes,
I
got
your
point.
Okay,
then
I
heard
or
discussed
your
command.
We
that
also
at
least
strength,
and
we
had
a
wet,
had
a
better
focus
on
the
narrow
scope
and
what
concrete
scope,
then,
after
that,
we
will
make
a
revision
and
and
they're
waiting
for
comment
about
about
it.
It's
okay,
yeah.
B
So,
first
of
all,
let's
take
a
look
at
the
status
of
the
draft.
There
was
a
working
group
last
call
on
the
previous
version
of
it,
which
was
till
4:00.
Then
there
were
a
number
of
comments
received
and
some
of
them
included
actual
comments
on
the
text
of
the
document.
These
were
the
comments
given
by
Bill,
Rahul
and
Pascal.
So
thank
you
very
much
to
everyone
who
provided
feedback
and,
as
a
result,
we
obtained
the
document.
We
released
version,
zero
5,
which
we
understand,
addresses
the
working
robles,
call
comments.
B
Okay,
now,
let's
take
a
look
at
the
updates
in
this
last
date
of
the
document.
First
of
all,
there
was
a
comment
by
a
bill
related
with
one
of
the
terms
used
throughout
the
document,
which
was
different
variations
around
the
term
I
pick
a
six
man
show
verb
notice,
any
links,
so
we
are
using
this
term,
but
in
different
forms.
So
now
we
have
sticked
to
the
form
that
you
can
see
on
the
slide
and
we
now
use
it
consistently
throughout
the
whole
document.
B
Then
there
was
a
comment
by
Rahul
that
perhaps
it
was
not
clear
for
the
reader
whether
this
document
is
sufficient
by
itself
to
enable
ipv6
measure
verbally
or
not
so
now,
we've
added
in
the
abstract
and
introduction.
Also,
we've
tried
to
clarify
that
the
document
is
not
sufficient
by
itself,
so
we
now
explicitly
state
that
the
routing
protocol
is
not
specified
and
also
we've
change
the
wording
of
some
sentences.
We
used
to
say
something
like
specifies
that
the
mechanisms
that
are
needed
to
enable
this,
however,
we
have
now
removed
the.
C
B
The
mechanisms,
so
it's
clear
that
this
document
is
needed,
but
it's
not
sufficient
by
itself.
Well
then,
there
was
another
comment
by
Bill
who
pointed
out
that
what
afforded
one
has
now
been
deprecated,
so
we
had
that
little
for
the
two
as
a
normative
reference
and
notified
of
one
is
still
a
reference
in
the
document,
but
it's
now
an
informative
reference,
because
the
text
that
explains
that
biddeth
for
that
one
was
the
first
specification
allowing
extended
network
topologies
beyond
the
star
topology
beautiful
energy.
That
is
still
true.
B
Then,
after
a
common
buyer
home,
we
realized
that
we
were
missing
an
important
point
in
the
document
in
section
3.1,
which
discusses
the
protocol
stack
for
us,
the
authors,
it
was
quite
clear
that,
regarding
fragmentation,
we
would
use
the
same
approaches
in
RFC,
76
68.
However,
we
didn't
explicitly
indicate
it
in
the
document.
So
now
we
have
added
a
discussion
on
the
MTU
and
fragmentation.
B
We
explain
that
in
route
of
photo
to
the
lingual-
and
you
mean
the
maximum
size
of
the
payload
at
the
outer
cap
layer,
which
is
the
layer
below
the
other
tissue
layer,
is
247
bytes
and
also
we
had
that
in
previous
versions.
Buta
followed
zero
for
that
one,
the
link
length
new
was
23
bytes,
and
we
explained
that
in
this
document,
as
we
did
in
RFC
76
68,
we
use
the
fragmentation
and
reassembly
functionality
that's
available
provided
by
AutoCAD.
So
there
is
no
need
to
use
the
6lowpan
fragmentation
functionality
here.
B
Then
there
was
a
comment
by
Pascal
and
we
updated
the
neighbor
discovery
section,
because
formerly
we
referred
only
to
RFC
sixty
seventy,
seventy-five
sorry.
So
now
we
include
us
well
RFC,
eighty
five
zero
five
and
we
consider
the
formats
and
the
mechanisms
that
are
included
also
in
eighty
five,
zero.
Five
and,
for
example,
we
are
talking
in
terms
of
the
extended
address
registration
option.
B
Now
we
also
talked
about
the
rover
and
we
explained
that
by
default,
this
field
is
based
on
the
Bluetooth
device
address,
but
we
also
explained
that
optionally,
a
crypto
ID
may
be
used
instead,
such
as
the
one
in
Pascal's
draft
of
just
protected
neighbor
discovery.
In
addition,
we've
also
repented,
as
per
our
CD
five
zero.
Five
to
the
sentence.
The
six
villain
must
not
register
its
little
local
address
and.
B
Also
related
with
these
comments,
we
have
updated
the
security
considerations.
We
now
explain
that
address
theft
and
impersonation
attacks
may
happen
when
with
those
device
when
the
rover
is
generated
based
on
the
Bluetooth
device
addressed.
So
we
explained
that
the
specification
of
the
address
protect
the
neighbor
discovery
gives
protection
against
this
kind
of
attacks.
A
I
So
there's
a
reassembly
that
happens
at
every
hop
six
to
eight
two
does
not
change
that.
So
everything
that's
in
4944
is
still
valid
in
this
case,
and
so
we've
been
looking
at
the
problem.
That
is,
that
poor
hope
fragmentation
recently
is
problematic.
There
are
two
main
problems
with
that.
The
first
one
is
latency,
so
the
problem
is
basically
mote.
A
sends
little
fragments
to
mode
B
and
mode
B
can
only
send
to
mode
C.
I
I
Intermediary
nodes
are
reading
the
data
relay
the
fragrance
without
reassembling,
and
it's
only
at
the
very
destination
that
we
do
reassembly,
and
so
you
have
in
the
network.
You
have
little
fragments
flying
left
or
right
that
are
not
being
reassembled.
It
then
reaches
the
the
low-power
world
router.
So
in
idea
of
101
we
created
the
6
slow
fragmentation,
design
team
that
is
now
closed
and
the
sick
and
exposed
because
the
three
following
drafts
that
it
has
generated
were
adopted
by
two
work
groups.
I
There
is
two
drafts
in
the
sixth
row
working
group
and
one
graph
draft
in
the
Elric
working
group,
and
the
way
this
works
is
that
the
draft
I'm
talking
about
is
the
first
one
which
gives
you
an
overview
of
6lowpan
fragmentation
and
and
and
gives
highlight
the
limits
of
virtual
reassembly
buffers.
That
is
the
mechanism
that
is
being
defined
in
the
second
graph,
which
is
an
element
graph
which
Karsten
is
eating.
I
I
So
this
is
the
status
of
this
was
a
long
intro
for
this
draft.
Basically,
you
see
I
didn't
I
did
minimal
changes,
so
I
populate
my
ten
minutes
with
context,
so
the
last
slides
are
actually
what
I
did
so
on
a
level
of
March
I
posted
a
one.
It's
an
informational
draft
which
really
describes
the
problem
it
doesn't
provide.
A
solution
is
the
Elway
graph
that
provides
the
solution.
So
here
are
the
here's
a
table
of
contents
and
it
changes.
I
No
one
is
very,
very
small,
fix
some
typos
and
I
put
a
link
to
a
study
that
yecchh,
yes,
Yuki,
Tanaka
who's
sitting
there
in
the
back
has
done.
He
has
been
simulating
this
using
the
six
dish
simulator
to
show
that,
yes,
indeed,
there
is
a
problem,
and
yes,
indeed,
the
the
the
the
resolution
proposed
and
Carson's
draft
souls
it,
and
these
are.
These-
are
the
results
of
that
so
yeah
hi
created
those
slides.
I
Please
shout
if
I'm
misinterpreting
your
simulations,
so
here
you
have
a
little
network
of
nodes
that
send
data
up
to
a
root
node
to
J
and
mode
I.
Here
is
an
exposed
note.
There
are
multiple
flows
going
through
it,
and
so
using
the
six
th
simulator
were
able
to
show
that,
if
you're,
just
using
RFC
for
a
nine
for
four.
I
Perha
PS
m
bleah,
the
more
fragments
you
have
in
your
packets,
the
more
likely
your
node
I
here
will
be
to
drop
some
of
these
fragments
and
hence
drop
some
of
the
packets.
It's
it's
trivially
simple,
to
understand
this,
just
graphs
to
back
up.
You
know
the
claims,
but
basically
what
we
see
here
is
that
is
that
the
as
we
have
the
number
of
fragrancing
increment,
the
overall
and
and
reliability
drops
down.
I
Whereas
if
you
don't
do
reassembly
every
hop
and
you
keep
forwarding
the
fragments,
you
don't
basically
have
you're
not
losing
any
packets
because
of
because
of
this
mechanism-
and
a
nice
benefit
of
course
also-
is
that
the
RAM
footprint
of
doing
this,
so
the
amount
of
memory
that
you
need
is
much
lower.
If
you
do
fragment,
read
I'm
sorry
fragment
forwarding,
then
then
reassembly
so
I
believe.
I
J
F
So
thank
you
to
Mel
for
the
introduction,
so
I
don't
have
to
reintroduce
again
the
prom.
So
basically
we
see
that
folding,
the
fragments
alleviates
the
prime
of
Botha
bloating
in
your
notes
and
improves
the
streamlining
of
the
fragments.
So
so
the
finalist
this
nation
is
rich
faster.
What
it
does
not
address
is
the
classical
case
of
one
fragment,
that's
lost
and
if
one
fragment
is
lost,
then
the
buffer
is
is
locked
basically
on
the
receive
side
until
some
kind
of
timeout,
and
during
that
time
the
buffer
is
being
lost.
F
So
that's
why
we
started
this
effort
of
selecting
this
fragment
recovery,
which
is
basically
a
principle
that
has
been
used
since
in
shaken
shiki's.
Already
so,
let's
go,
and
this
thing
is
not
yet,
but
basically
the
idea
is
pretty
much
the
same.
You
send
your
fragments,
you
have
an
acknowledgment
bitmap
and
based
on
the
second
arrangement
bitmap
you
resend
selectively
some
of
the
fragments
it's
not
rocket
science.
It's
not
nice
very
easy.
F
We
saw
in
LP
once,
but
not
necessarily
easy,
either
to
do
that,
we
had
to
introduce
a
completely
new
scheme
for
presenting
the
data,
so
we
could
not
basically
be
backward
compatible
with
RFC
49:44.
We
had
to
have
new
formats
and
everything
and
the
operations,
the
operation
that
we
introduced,
enable
a
bit
of
flow
control
which
cannot
be
done
without
it
and
also
in
tribute,
also
provide
a
bit
of
ecn.
F
You
have
an
cien
bit,
which
is
pretty
much
the
explicitly
explicit
congestion
notification
that
you
are
used
to
at
least
three,
but
it
really
happens
between
the
6lowpan
sub
layer
and
the
Austria
are
supposed
to
the
Austrian
a
of
one,
but
it
still
congestion
notification.
That's
why,
even
even
with
the
streamlining
that
we
we
just
so
if
you
may
still
have
congestion
some
notes
and
will
be
able
to
slow
down
the
emission
of
the
fragments
to
reduce
the
chances
that
are
destroyed.
F
So
what
happened?
Well,
what
happened
is
we
got
implementations?
That's
what
happened.
That's
pretty
good,
and
so
so
we
get
comments
from
implementation
and
from
the
real
world,
and
this
goes
the
commands
from
the
real
world
where
that
the
formats
that
we
had
did
not
really
enable
some
use
cases
like
very
large
frames,
for
instance,
very
large
frames,
fragmented
in
many
many
fragments.
We
could
not
even
address
that.
We
didn't
have
enough
data
gram
tags
in
our
formats,
so
we
actually
modify
the
formats
and
what
we
did
well
show
it
later.
F
What
we
did
is
we
we,
we
have
reduced
the
size
of
the
data
gram
tag
because
there
is
not
so
many
data
gram
in
flight
between
a
source
and
the
destination.
So
why
should
we
have
so
many
like
64,000
possible
data,
Graham
tags
India
at
the
same
time
reduced
that
from
two
byes
to
one
light
and
with
the
bytes
that
we
saved,
we
could
actually
have
larger
data
crammed
sizes
and
larger
offsets.
That's
pretty
much!
F
He
doesn't
matter
if
what
you
output
is
the
same
thing
as
what
your
input
you
might
keep
a
few
bytes
in
memory
that
you
will
happen
to
the
next
fragments.
That's
perfectly
okay,
but
with
the
fragment
recovery,
you
must
basically
provide
the
same
fragment
out,
as
you
add
in
and
remember,
6lowpan
may.
Actually,
the
efficiency
of
the
six
of
Incorporation
malya
might
actually
change
if
you're
the
originator
of
the
packet,
the
receiver
of
the
packet
of
an
intermediate
node
for
that
packet.
F
Okay,
so
that's
that's
this
text,
which
we
cannot
improve
to
say
that,
but
that
was
there.
The
other
thing
which
Michelle
pointed
out
is
okay,
but
if
you
change
the
first
fragment,
it
means
that
the
offset
of
this
data
gram
of
the
modify
data
gram
in
the
packet
in
the
compressed
target,
which
is
how
we
express
things
here,
changes
as
well.
Yes,
it
does
so
if
we
introduce
some
new
bytes,
for
instance,
in
the
first
fragment.
F
F
So
this
is
pretty
much
what
is
being
discussed
if,
if
the
second
half
has
a
less
efficient
fragmentation,
it's
to
add
like
five
bytes
to
the
first
buffer.
We
need
some
slack
to
add
this
from
one
thing
and
then
we
need
to
remember
we
add
for
five
bytes,
because
the
data
gram
size
is
changed
and
the
data
gram
offset
of
all
the
further
data
grams
R
is
also
changed
by
five.
It's
pretty
much.
What
we
indicate
you
know
there
is
the
new
format
and
the
change
of
formats.
F
So,
as
you
can
see
that
the
data
gram
tag,
which
was
to
updates
ridiculously
long
because
that's
to
be
unique
for
a
source
anyway,
so
it
is
reduced
to
one
byte
which
allows
us
to
have
a
wider
field
for
the
fragment
offset
and
for
the
fragment
size,
and
with
that
we
are
able
to
to
implement
use
cases
in
15
4G
whether
the
frame
can
be
2.
2
K
bits
took
a
bite
so
sorry,
and
now
we
can
support
all
those.
It's
pretty
much
the
news,
so
it's
implemented
in
tomatoes
are
happy
with
it.
F
E
F
Actually,
I
would
love
to
have
reduced
by
the
shake
authors
and
the
note
the
mechanism
is
not
exactly
the
same
thing.
For
instance,
I
mentioned
the
fording,
because
chic
is
just
I've
been
spoke,
so
you
don't
have
the
concept
of
forwarding
across
multiple
heart,
so
you
don't
have
the
kind
of
crimes
I'm
discussing
here.
Like
you
know,
changing
the
data
grab
offset
etcetera,
etcetera.
F
You
may
have
multiple
many
data
granting
flights
from
many
sources
to
many
destinations
so,
but
but
the
global
idea
of
having
a
bitmap
which
index
you
know
the
missing
fragments
is
the
same.
So
that's
why
I
would
appreciate
that
the
Sheik
buffers
of
the
fragmentation
and
hey
I
have
two
people
in
the
room
that
caught
the
commit
like
they'd
say.
Yes,
would
actually
read
you.
This
thing,
I
think
that
if
you
two
guys
give
me
a
good
review,
we
are
ready
for
a
second.
J
So
let's
first
amigo
history
of
this
raft,
so
why
we
wrote
this
draft
historically
PRC
power
line.
Communication
has
been
widely
used
for
metering,
but
now
people
have
known
as
the
expection
Mountain
lights.
People
are
using
a
PRC
to
transmit
a
PV
ipv6
packet
for
no
applications
than
metering,
for
example,
to
control
the
traffic
lights
to
transmit
the
the
the
control
comments
for
in
the
smoke.
Wait
something
like
that,
and
so
we
need,
if
ipv6
adaptation
lawyer
for
constraint
plc,
because
historically
only
for
metering.
J
Maybe
the
layer
two
is
enough,
but
now
we
need
to
to
transfer
it
to
layer
Serena.
So
for
this
draft,
the
scope
is
seconds
from
POC
switch.
Have
the
constraint
bandwidth
constraint,
bitrate.
So
what
is
in
the
scope?
Is
the
activity
GT
at
9:03
and
I
should
buoy
19
the
1.1
and
Hawaii
9001
or
two?
So
let's
draft
started
I
march
7
27
2017
and
it
is
adopted
by
six
doe
in
February
and.
J
During
during
the
adoption
we
have
received
many
sport,
but
for
in
terms
of
comments
we
have
received
only
one
from
cousin
and
in
Cass's
opening
that
they're
made
some
misleading
or
confusing
landscape
about
PRCs,
because
in
Section
three
mentions
about
hom
until
1.1
and
G
another
four.
So,
but
we
did
not
mention
this,
we
do
not
mention
this
kind
of
PRC
technologies
in
the
rest
of
the
draft.
J
So
before
we
reach
some
into
this
draft
ice
working
group
draft
we
have
made.
We
have
added
some
clarifications
to
clarify
the
scope
of
this
draft
and
in
Section
three
we
tend
to
give
a
whole
landscape
of
about
to
the
PRC
technologies,
including
the
broadband
technology
as
well.
So,
but
it
is
not
in
the
scope
of
six
zero.
So
we
have
added
some
clarification
to
to
say
that
we
will
be
only
focused
on
the
constrain
PMC's,
which
is
already
included
in
this
draft.
J
So
for
the
future
work
we
will
reference
mall
to
the
the
about
the
the
header
compression.
We
write
more
and
more
content
instead
of
just
a
reference
to
RBC
phone
and
fuller
and
RC
6282,
and
we
would.
We
will
also
add
some
reference
and
rate
description
about
the
sixth
of
everything
header,
something
like
that
and.
J
B
B
Okay,
so
now
the
last
item
in
the
agenda,
the
one
we
have
added
at
the
beginning
during
the
agenda
bashing-
is
about
the
sixth
law
working
group
wiki.
That
is
a
resource
that
has
not
been
updated
for
a
while,
and
one
idea
that
we
had
and
also
was
suggested
by,
the
former
chairs
was
trying
to
to
get
the
wiki
up-to-date.
So
it
would
be
great
if
we
can.
The
working
group
can
provide
content
to
populate
the
wiki,
and
in
this
regard
it
would
be
great
if
you
can
provide
us
details.