►
From YouTube: IETF110-6LO-20210311-1200
Description
6LO meeting session at IETF110
2021/03/11 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
I
think
it's
one
minute
past
the
start
time,
so
we
should
get
started.
We
have
about
23
people
and
we
have
about
90
minutes
of
the
agenda.
B
Before
we
get
started,
we
need
a
mini
taker
and
javascript.
The
links
for
both
are
here.
A
C
So
perhaps
well
hurry
to
ask
basically
that
perhaps
anna
I
don't
know
if
we
might
be
able
to
take
a
few
minutes,
perhaps
if
more
people
can
join
so
this
should
be
actually
some
collaborative
process
and
you
can
see
actually
there's
the
code
dmd
link
on
the
slide.
You
can
also
find
it
from
the
agenda
page
and
yeah.
B
B
All
right
should
we
get
started.
B
B
And
this
is
our
agenda
for
the
day
we
have
about
90
minutes
of
agenda
items.
Anyone
wants
to
add
or
modify
this.
C
C
B
A
quick
update
on
all
the
active
graphs
that
we
have
since
the
last
time
we
met
in
november
2020.
We
we
have
four
rfcs
published
for
the
work
we
did
in
the
last
few
years.
B
Congratulations
to
the
work
group
and
for
the
rest
of
the
the
drafts
that
are
in
various
stages
of
ist
processing.
We
will
have
a
quick
update
in
the
in
the
discussion
today
for
the
packet
delivery
deadline.
That's
in
the
rfc
editor
queue
eric.
D
I
can
report
that
it's
in
cluster
310
many
many
many
things
were
blocking
on
cluster
238
being
published,
which
finally
happened
and
the
rfc
editor
seems
to
think
there
are
still
three
references
that
need
to
be
published.
D
First,
I
think
six
dish,
architecture,
detonate
architecture
and
roll
routing
dispatch,
and
I
wonder
if
that's
actually
true.
D
Because
there
was
another
case
in
a
quick
document
where
there
was
yeah
so
dead.
Knit
architecture
is
a
normative
reference,
as
is
roll
rounding,
ditch
batch.
D
So
if
you
want,
I
can
email
the
rfc
editor,
but
it's
it's
part
of
this
cluster
310
and
I
will
paste
that
link
in
the
java.
D
So
it's
it's!
You
can
see
there
what
its
three
dependencies.
D
D
But
I
I
suspect
that
the
answer
will
be
a
many
things
were
blocked
on
238
and
b,
the
other
defenses
are
still
in
the
process
of
being
worked.
B
Okay,
cool
thanks
eric,
so
the
next
status
update
on
on
the
draft
that
we
have
will
be
on
the
ble
mesh
callus.
C
So
perhaps
one
point
before
starting
with
this
presentation
would
be
again
eric
if
you
could
provide
us
some
feedback
about
the
nfc
draft,
because
there
was
some
message
from
benjamin
who
had
discussed
on
the
document
in
october.
I
think
so
well
would
be
good.
Perhaps
if
you
have
any
updates
on
that.
D
The
nfc
draft-
oh
so
not
the
bluetooth,
mesh,
yeah,
yeah.
D
A
D
Yeah
this
is
in
my
this
is
in
my
queue.
There
was
an
update
and,
let's
see
one
of
the.
D
One
of
the
blocking
comments
well
from
someone
who
is
no
longer
on
the
isg
was
centered
around
the
fact
that
the
nfc
spec
is
not
public
to
read.
I
don't
suppose
that's
changed
at
all
and
I
don't
suppose
it's
going
to
change.
C
So
truth,
if
there's
any
author
from
the
mfc
draft,
who
could
explain
if,
for
whatever
reason
now
the
nfc
specification
is
available
is
open.
D
And
apart
from
that,
I
don't
think
I've
seen
well.
Sorry,
I
don't
remember
any
yeah.
I
say
I
have
to
check.
I
don't
I
don't
see
that
I've
I've
seen
any
response,
that's
closed
out
all
of
ben's
issues,
but
I
have
to
admit.
I
have
also
not
followed
closely.
D
Yeah
I'll
I'll
have
to
catch
up
on
what
happened
with
this
document.
D
C
C
So,
first
of
all,
let's
take
a
look
at
the
status
of
the
draft.
So
since
the
last
meeting
there
were
a
number
of
pre-isg
reviews
on
the
previous
version
of
the
draft,
which
was
08.
Those
were
the
reviews
from
the
routing
directorate,
iot
directorate
general
area
and
security
directorate
and
well.
We
would
like
to
thank
all
the
reviewers
for
the
very
helpful
feedback
and
most
of
the
comments
were
editorial,
perhaps
except
for
the
review
by
dominique
from
the
iot
directorate,
which
included
also
a
few
technical
points
and
questions.
C
C
C
C
C
C
However,
yeah
now
after
the
feedback
and
also
there's
another
comment
by
benjamin
who
also
points
out
that
this
same
issue
could
be
considered
a
security
issue
as
well,
then
our
approach,
our
proposal
for
the
next
update,
would
be
to
to
fix
this
by
stating
that
the
mtu
size
in
ipv6
mesh
over
bluetooth
le
is
280
bytes.
So
this
would
be
in
the
style
of,
for
example,
what
is
in
rc4944,
which
is
in
that
case,
for
the
15.4
network.
C
Okay,
so
if
there's
no
comments,
let's
move
to
the
next
slide.
Please
thank
you.
So
the
second
discuss
point
is
by
sorry
by
benjamin
and
that's
on
the
section
which
focuses
on
label
discovery.
So
currently
we
have
a
sentence
which
is
that,
as
per
out
of
c8505,
the
six
line
must
not
register
its
link
local
address.
However.
Well
we
need
to
apologize
because
we
missed
adding
with
the
signal
br
at
the
end.
C
So
here
the
intention
was
to
explain
that
we
use
the
simplified
procedures
for
duplicate,
address
detection
which
are
offered
by
8505
and
then
there's
another
point,
which
is
that
anyway,
in
this
case,
in
our
mesh
of
a
ble
scenario,
registering
the
switzerlands
lla
with
the
cxlr
would
be
redundant.
Okay,
because
the
6lr
would
know
the
prefix
and
also
would
know
the
id,
because
it's
formed
based
on
the
bluetooth
device
address,
which
would
be
known
at
the
moment
of
linglia
connection
establishment,
so
yeah
this
would
be
redundant.
C
This
is
according
to
8505
and
on
the
second
point
we
would
add
that
by
this
specification,
sigzeln
must
not
register
its
link
local
address
because
it
would
be
redundant
and
also,
as
the
cslr
already
ensures,
link
local
address
uniqueness
as
part
of
bluetooth,
le
connection
establishment
procedures,
so
yeah
pascal,
you
may
have
a
comment.
F
Yeah,
yes,
can
you
hear
me?
Yes,
the
the
problem
with
with
this
is
the
the
registration
of
the
link.
Local
is
used
because,
after
that,
you
will
use
the
link
local
as
source
to
to
do
do
anything
like
register
the
global
address,
and
so
this
step
was
actually
making
sure
that
there
is
neighbor
cache
it's
throughout
the
router.
F
C
Yes,
so
so
yeah,
the
idea
probably
was
trying
to
save
like
a
couple
of
messages
here
but
yeah.
I
agree
that
this
is
actually
the
the
clear
sorry
the
clean
way
to
to
proceed
so
yeah.
That's.
F
That's
no
more,
I
mean
if,
if
you
just
register
to
the
6lr,
that's
you
said
correctly:
the
6lr
doesn't
need
to
go
to
the
6lbr.
So
it's
just
very
local
between
those
two.
If
you
just
do
it,
it
doesn't
cost
much
and
then
you're
cleanly
inside
the
architecture.
If
you
try
to
save
that
you're
putting
yourself
in
a
nightmare
of
primes,
so
why
would
you
do
that.
C
C
C
C
Okay,
in
some
cases
trying
again
to
be
a
bit
more
efficient,
and
we
also
include
the
consequences
of
not
doing
so.
Basically,
we
state
in
the
document
currently
that
the
6lm
would
be
unreachable.
There
would
be
no
duplicate,
address,
detection
and
so
on.
So
here
benjamin
made
the
question
of
where
could
he
find
like
the
complete
list
of
consequences
of
not
registering
the
non-llas
so
well,
I
think
we
are.
The
authors
are
perhaps
not
aware
of
such
a
document,
compiling
all
these
consequences.
C
So
pascal,
I
don't
know
if
you
may
want
to
make
a
comment
here.
F
Yes,
two
comments.
Actually
the
first
one
is,
if
I
think,
I'm
pretty
sure
at
five
for
five,
so
it's
a
must,
and
so
you
must,
if
you
make
it
a
should,
you
need
to
indicate
that
you
update
or
whatever
term
8545
the
the
the
reason
why
it's
a
must
is
also
because
the
expectation
is
that
the
cxlr
might
do
savvy
operation
whereby,
if
a
node
sources
a
packet
with
an
address
which
was
not
validated
as
being
his
address,
then
it's
valid
for
the
cxlr
to
to
drop
the
packets.
F
F
C
Okay,
thank
you.
Thank
you
again
for
the
feedback.
Yes,
so
I
guess
well.
This
came
from
some
comment
from
the
list
some
time
ago,
as
some
way
to
try
to
be
a
bit
more
efficient,
save
a
few
messages
here,
especially
for
some
devices
which
may
be
sending
some
packet
quite
infrequently,
perhaps
not
expanding,
not
expecting
a
response,
but
yeah
again,
I
understand
the
reasons,
so
perhaps
it's
clearer
or
cleaner
to
to
perhaps
avoid
these
sort
of
issues.
F
Anyway,
yes,
you
would
have
to
to
document
it.
Why
infringing
the
architecture
is
a
good
idea,
but
I
I
can't
see
that
it's
such
a
good
idea.
It
doesn't
cost
a
match,
and
that
was
my
point.
You
can
use
a
very
long
lifetime,
so
you
do
it
and
you
can.
You
can
make
a
lifetime,
for
I
mean
if
your
system
accepts
one
year,
why
don't
you?
I
don't
remember
what
the
maximum
in
the
signaling
but
make
it
very
very
long,
and
so
again
it
doesn't
cost
so
much
and
and
join
nightmare
of
hidden
consequences.
C
C
C
Another
comment
was
on
the
array
of
header
compression
by
benjamin,
so
we
stayed
currently
in
the
draft
that
an
ra
router
advertisement
may
include
this
xco
here.
The
point
is
that
it
used
to
be
a
must
in
rfc
7668.
C
F
F
Yeah
yeah,
I
understand
you're
trying
to
save
something.
But
if
you
have
enough
bandwidth
to
put
the
c6co,
then
it
really
should
be
there.
Otherwise,
you
don't
know
if
your
router
does
it
505
now
you
may
say
it
obviously
does
it
because
it
always
does.
Then
there
must
be
another
mess
somewhere,
which
says
the
any
router
that
connects
to
those
things
must
be
6lrs,
because
otherwise
you
don't
know
if
it
is
or
if
it
is
not.
C
Okay
yeah.
Thank
you.
Thank
you
for
the
point
yeah
we
will
well.
I
guess
we'll
need
to
take
into
account
your
your
comment
and
yes,
so
yeah
we
will
come
up
with
some
approach,
some
some
solution.
But
yes,
definitely,
if
we
need
to
signal
8505,
then
probably
this
might
need
to
be
a
must
so
yeah.
Okay,
then
thanks
again
pascal
then
perhaps
we
can
move
to
the
next
slide.
C
Okay,
so
then
there
there
are
other
comments,
so
the
first
one
by
martin
is
about
the
requirements
language.
So
basically,
here
in
the
section
which
is
at
the
beginning
of
the
document,
the
usual
2119
section.
C
C
The
first
comment
was
suggested
to
to
remove
the
bubble,
which
is
surrounding
the
subnet
part
of
the
figure,
because
it
seems
this
confused
him
a
little
bit
so
yeah
there's
no
problem.
Let's
do
it
for
the
next
update
and
then
there
was
some
question
about
whether
the
top
left
note
in
that
figure.
Is
that
actually
intended
as
a
6lr
or
was
that
some
sort
of
typo?
C
So
the
answer
is
that,
yes,
it
was
actually
intended
as
a
6lr,
because
it
is
to
illustrate
that
perhaps
temporarily
or
perhaps
more
permanently.
We
could
have
something
like
this.
That's
a
router,
perhaps
for
a
while
or
for
a
longer
time,
at
the
edge
of
a
network.
So
pascal.
F
Yes,
I'm
sorry
just
to
express,
I
was
confused,
it
was.
The
previous
comment
was
about
the
six
cio
and
and
you
you
were
talking
about
the
six
co.
It
was
my
confusion.
Please
don't
worry
the
six
cio.
A
A
C
C
C
C
Because
I
believe
this
is
the
last
well
yeah
the
last
slide
with
actual
content,
so
yeah
our
plan
is
to
update
the
draft,
take
into
consideration
all
the
feedback
thanks
again,
and
we
hope
that
soon
we
may
have
version
10
which
hopefully
well
it's
intended
to
address
the
different
points
by
the
isd
members.
So
thank
you.
B
So
post
edits
will,
will
you
be
publishing
and
would
you
like
a
review
from
pascal
before
the
ist
review
continues
or.
C
Well,
well,
it
could
be
valuable.
I
think
perhaps
pascal
reviewed
some
earlier
version
of
the
document.
I
don't
know
if
well.
F
I
read
not
long
ago,
but
yes
once
you've
done
the
the
changes
that
we
just
discussed.
If
you
don't
mind
sending
it
to
me,
I
will
I'll
do
a
pass
on
it.
B
Thank
you
thanks
carlos,
so
is
rennie
or
any
other
author
for
plc
plc
goes
next,
so
I
don't
okay,
yeah.
E
E
Actually,
the
the
comments
are
from
the
general
area,
the
ops
area
and
the
security
area
and
transporter
area,
and
we
have
replied
to
these
reviews
in
the
meeting
list
and
will
update
the
draft
very
soon
and
the
next
slide
please
yeah.
Thank
you.
The
review
of
the
security
area
is
done
by
robert
and
his
first
comment
is
about
the
section
5
in
the
draft.
E
In
this
section
we
mainly
talk
about
the
scenarios
and
topologies
of
the
constrained
plc
networks
and
roberts
considers
that
this
section
is
informational
and
has
no
impact
to
the
implementers
of
construing
the
plc
network,
and
we
think
it
is
true.
It
is
a
firm
con
comment.
So
our
question
to
the
working
group
is
that
if
we
can
remove
this
section
or
move
it
to
the
appendix
so
any
ideas
on
this
comment,
should
we
remove
it
or
just
put
it
into
the
app
index,
which
is
the
correct
way.
C
Hello,
so
speaking
here,
so
I
think
we
have
a
similar
section
in
the
different
ipv6
over
four
specifications
in
the
text
in
the
body
of
the
document,
so
not
in
an
annex.
So
I
understand
that.
Well,
there
are
like
different
figures
and
it's
quite
informational,
as
the
reviewer
says,
but
well
I
wouldn't
see
an
issue
in
keeping
that
section
in
the
body
of
the
document.
But
well
perhaps
that's
just
my
opinion.
C
E
Discussion
of
id
mapping
the
security
consideration
is
not
enough.
Thus,
we've
added
more
clear
reference
to
the
rfc
80
65
talking
about
the
privacy
strikes
and
gives
solutions
from
the
itf
rfcs
robert
singh.
That
thinks
that
the
text
is
better
but
needs
more
review
from
people
with
more
expertise.
E
E
and
rc864
reveals
that
the
a
clear
and
direct
mapping
between
the
link
layer
address
and
the
id
may
have
privacy
issues,
and
actually
the
problem
has
been
solved
by
six,
though
in
drc
8065.
E
You
can
fully
use
the
entropy
of
the
the
range
of
the
id
space,
so
we
think
that
we
will
change
the
reference
from
the
reference
to
rfc
at
64
into
the
reference
to
rfc
8065,
so
that
we
can
have
the
a
more
concrete
solution
to
deal
with
the
privacy's
rights.
E
E
E
Actually,
the
rc
4963
raises
an
issue
that,
with
the
data
rate,
is
high,
the
16
bit
tag
is
not
enough
to
guide
the
correct
rear
assembly
of
the
syn
packet.
However,
in
constraint,
plc
network,
which
is
used
in
the
lte
scenario,
the
threshold
data
rate
cannot
be
reached.
However,
josef
suggests
to
add
more
description
in
the
craft.
Just
as
a
reminder,
and
next
page,
please.
E
The
review
from
the
ops
area
is
done
by
it's
from
dan
actually
and
he's
curious
about
the
operation
and
the
management
of
the
constraint
plc
network,
and
we've
explained
that
the
constraint
plc
networks
are
designed
to
be
self-organized
and
self-managed,
and
they
the
management,
is
different
from
some
traditional
network,
like
enterprise,
network
or
career
network,
and
actually
itf
is
working
on
more
features
on
the
management
of
lt
networks
in
the
recently
formed
ltops
working
group,
which
is
aimed
to
design
more
features
for
the
management
of
iot
networks,
then
suggest
that
we
may
add
a
subsection
talking
about
the
operation
and
the
management
of
the
plc
network,
and
we
think
that
we
can
add
a
very
short
subsection
talking
about
the
plc
network
is
self-organized
and
self-managed
and
how
we
can,
for
example,
view
the
topology
or
all
the
devices
online
by
the
gateway,
for
example,
and
no
more
comments
comes
from
the
general
area
and
will
update
the
draft.
E
According
to
these
comments
in
the
in
the
next
version
very
very
soon.
So
any
comments
on
this
on
these.
E
C
D
Yeah,
I
think
carlos
you're,
the
shepherd
for
the
documents,
so
I
can
just
wait
till
you
tell
me
that
draft
six
or
seven
or,
however
many
updates
are
necessary
to
incorporate
the
feedback.
Let
me
know
when
it's
ready
to
go.
D
G
Yes,
okay:
this
is
the
circle
of
three
and
used
accent,
so
I
want
to
mention
that
we
have
the
change
of
the
author's
information
in
the
previous
version.
We
had
the
take
and
shoot
from
modio
av,
but
we
try
to
contact
the
tech
and
shoot,
but
it
is
impossible
to
contact
him.
So
we
moved
him
from
the
author
list
to
acknowledgement
section.
So
it
is
the
change
of
the
author
list.
G
Page
yeah:
this
is
the
history
and
status
and,
as
you
can
see,
it
is
a
very
long
time
ago
to
start
this
work.
So
now
we
have
the
10th
version.
So
this
is
the
update
to
result.
The
command
from
the
second
or
working
group
last
call.
G
Please
yeah
in
this
trap
we
have
the
sixth
sixth
law,
lincolnia
technology,
g-wave,
ple,
textually,
mstp,
nfc
and
plc,
and
the
related
rfc
and
interdrive
are
as
follows.
As
you
can
see
next
page,
please.
G
Yeah,
this
is
the
useful
information
to
compare
across
sixth
role
in
clear
technology.
So,
in
this
table
of
comparison
we
have
the
gba,
the
led
valley,
msd,
nfc
and
felsi,
and
we
tries
to
analyze
the
usage
of
its
technology
and
technology
and
subnet
and
mobility
requirement
security
requirement,
problem,
climate
and
etc.
G
Yeah
during
the
second
working
group
last
call,
we
got
comments
from
the
five
person
of
kerry
lynn
and
spoiler
anand
and
the
shared
body
parody
and
pascal
super
and
the
house
gym.
G
G
G
So
he
suggests
that
this
left
is
above
sixth
row
like
other
sections,
so
it
is
better
to
use
only
six
law,
the
section
title
just
for
consistence,
so
we
follow
on
his.
G
The
certain
part
of
the
same
section
requires
a
bit
of
rewarding
so
that
the
leader
appears.
It
is
a
six-row
document
rather
than
a
summary
of
the
sixth
european
protocol,
so
he
expressed
the
concern
of
concern
of
the
usage
of
the
sixth
row
pan
so
to
reserve
this
com
command.
We
add
the
following
sentence
and
at
the
beginning
of
the
section
there
is
sixth
law
aims
at
reusing
and
or
adopting
existing
sexual
pain
functionality.
G
You
know
in
order
to
efficiently
support
ip
physics
of
a
variety
of
ielts
technology
and
the
second
or
the
third
command
is
that
for
cyclone
network
they
use
wired,
link,
technologies
or
short
dots
on
the
pedal
and
how
secure
pen
can
possibly
be
adaptive
health,
so
we
think
that
we
have
or
a
text
of
the
wild
technology.
That
is
a
plc.
G
So
in
the
plc
section
there
are
already
the
relevant
text,
so
we
don't
need
to
add
another
text
for
document
and
the
first
command
is
that
the
emergency
over
banknote
ip
as
an
alternative
for
pen
mstp,
cannot
be
ignored,
so
he
suggests
the
uses
of
so
he
suggests
to
add
the
banknote
ip.
G
G
Yes,
this
is
a
comment
from
third
match
literally,
so
it
is
a
little
to
the
correct,
typo
and
the
expression.
So
we
follow
his
suggestion
as
like
this.
Please
go
to
next
page
thanks
for
addressing
the
comments.
Oh
okay,
okay,
thank
you,
and
this
is
comment
from
task
car
super.
So
I
personally
thanks
to
pascal
silvers,
because
he
helped
to
improve
this
threat
because
he
gave
many
comments,
so
I
want
to
explain
one
by
one.
G
The
first
comment
is
that
he
feel
that
there
are
some
should
be
placed
on
the
grammar
by
a
native
speaker,
so
I
and
colors
to
our
best
to
improve
the
writing
of
the
document,
and
the
second
command
is
that
there
are
the
this
typing
of
the
six
row
pan.
So
we
change
as
he
suggests,
and
the
third
command
is
that
he
suggests
to
update
their
discovery.
Optimization
for
sexual
pain,
rfc
675,
to
include
rfc
l505.
G
G
Fifth
command
is
that
he
suggests
that
the
bluetooth
c
and
ip
link,
so
we
discussed
this
issue
from
among
us,
so
we
conclude
that
the
ip
link
it
is
difficult
to
find
the
information
in
the
public
space.
So
there
seems
to
be
no
public
available
information
regarding
the
ip
link
at
first.
So
we
would
like
to
add
information
on
that,
but
only
as
long
as
it
is
public
available.
G
Please
and
the
sixth
command
is
that
the
g3
plc
is
dead,
so
g3
plc
used
on
escape
to
the
six
row
pan
and
you
discuss
in
the
section
4.1.
So
why
not
a
word
with
a
course
reference
here?
So
as
he
to
resolve
this
command?
We
add
a
short
text
of
c3prc
and
our
reference
and
the
seventh
command
was
that
the
section
paul
has
denied
9903
and
the
death
risky,
but
he
want
to
add
the
white
sun.
So
you
know,
though,
in
the
previous
version
of
our
draft.
G
G
Yeah,
thank
you
so
in
the
previous
section,
or
we
had
the
white
sun
part,
but
to
make
it
compact
of
our
draft,
we
are
delete,
so
rice
learn
and
the
website
is
based
on
I
triple
edit
rapid
in
that
port
technology,
so
both
of
the
passcode
suggests
that
he
is
better
to
include
the
white
sun
section,
so
we
restore
the
section
of
the
white
sun
in
the
update
version,
and
the
eighth
comment
was
that
the
the
factory
automation,
so
we
found
that
the
text
of
factory
automation
was
already
exist,
so
we
used
no
action
for
this
command.
G
The
nice
comment
was
that
the
the
missing
of
the
thread,
so
I
know
that
the
thread
also
uses
i3
is
based
on.
I
briefly
edited
the
15.4,
so
we
have
some
concern
about
that.
This
document.
This
draft
is
targeting
on
the
sixth
row
that
are
the
sixth
row.
Ten
and.
G
G
The
six
row
pen
at
the
andy
and
he
suggests
to
broadcast
or
avoidance
the
blade
so
to
reserve
this
command.
We
follow
his
suggest
and
we
add
the
jubilee
broadcast
avoidance,
and
the
surps
comment
was
that
some,
the
host
route
interface
and
the
proxy
level
discovery
there.
So
we
add
post
to
router
interface,
read
and
fractional
discovery
and
the
third
com.
Certain
comment
was
that
it
is
released
to
ap
nd.
G
So
we
update
the
reference
and
the
first
command
was
that
the
sixth
group
and
nd
and
the
address
or
assignment
related.
So
we
update
the
relevant
text
in
the
address
assignment,
read
and
the
pip's
comment
was
there,
but
we
think
that
there
we
need.
We
don't
need
to.
G
And
this
comment
was
the
whole
thing
the
drag,
so
he
suggests
some
typo
and
the
expression.
So
it's
I
think
that
it
is
a
little
divider,
so
we
change
the
text
as
he
proposed.
G
G
G
G
And
we
found
that,
after
submitting
the
tenth
version,
we
had
a
comment
from
the
tarot
kibby
nin.
He
suggests
to
include
i33
edit
ortuda
pip,
titan
9,
but
unfortunately
in
the
author
we
don't
have
any
expert
to
regarding
i338
or
59,
but
in
the
update
version
we
try
to
reserve
this
comment.
G
B
Thank
you.
I
don't
see
anybody
in
the
queue.
So,
let's
move
on
to
the
next
topic,
carlos
she
had
a
compression.
C
Okay,
hello
again
so
again
as
a
working
group
participant
I'm
going
to
give
this
presentation
about
the
idea
of
using
chic
heather
compression
in
six
law
environments.
Next,.
C
Please,
first
of
all
about
the
motivation
for
this
idea.
We
have
the
rfc
6282
has
been
the
basis
for
header
compression
in
six
load,
pan
and
also
in
6
low.
This
rfc
was
designed
for
15.4
as
the
target
technology
below
ipv6,
and
it
has
also
been
adapted
or
reused
for
relatively
similar
iot
technologies,
such
as
the
ones
that
we
deal
with
in
six
low,
like
bluetooth,
low
energy,
nfc
and
so
on.
C
So
with
62a2,
it
is
possible
to
compress
an
ipv6
udp
header
of
48
bytes
down
to
a
size
of
7
bytes,
assuming
the
best
case
and
with
global
addresses,
and
on
the
other
hand
recently
there
has
been
the
publication
of
another
specification
which
is
rfc
8724.
C
C
So
this
specification
chic
has
been
designed
for
technologies
which
are
even
more
constrained
than
the
ones
typically
handled
in
six
load,
pan
or
six
load.
Specifically,
those
are
the
lp1
technologies,
low
power,
wide
area
network
technologies
like
sigfox,
lora1,
narrowband,
iot
and
so
on,
which
are
actually
more
constrained
than
the
typical
six
lower
six
lowpan
ones.
C
C
Okay,
so
then,
if
we
look
at
the
application
layer
protocols
as
well,
it
turns
out
that
there
has
been
no
six
low
or
six
low,
pan
defined
header
compression
for
an
application
layer
protocol
like
co-op,
and
in
that
case,
if
we
want
to
compress
the
ipv6,
udp
and
co-op
headers,
the
result
would
be
a
size
of
11
bytes.
If
we
use
rfc
6282
like
the
the
6lowpan
traditional
one,
and
we
cannot
actually
compress
the
cob
header.
C
But
it's
actually
possible
to
use
chic
to
compress
the
header
of
quad
and
in
fact
there
is
a
document
that
just
recently
entered
the
rfc
editor
queue
produced
by
the
lp1
working
group,
which
specifies
how
to
do
so.
And
in
that
case
it
would
be
possible
again
with
no
cop
header
options
and
best
case
global
addresses
to
compress
the
ipv6
udp
and
co-op
headers
down
to
a
format
of
just
the
two
bytes
and
well.
C
Actually,
the
improvement
could
be
greater,
meaning
that
the
uncompressed
header
sizing
co-op
can
be
of
greater
size
depending
on
the
use
case.
Okay,
but
well
assuming
these
conditions,
we
would
have
the
results
that
we
can
see
on
the
slide.
C
So
here
we
can
see
on
the
left.
We
can
see
the
protocol
stack,
that's
the
traditional
six
load
plan
based
protocol
stack
and
on
the
right.
We
can
see
what
we
plan
to
do
here
and
the
idea
would
be
that.
Well,
perhaps
in
some
cases
we
might
want
to
use
chic
for
header
compression
instead
of
the
traditional
6lowpan
header
compression,
so
to
to
be
clear,
the
idea
would
not
be
trying
to
obsolete
6lowpan
header
compression.
C
So
we
might
make
ourselves
the
question
of
okay
should
or
might
we
use,
chic
header
compression
for
this
kind
of
six
low,
single
pan
environments
and
well.
Some
of
us
believe
that
the
answer
is
yes,
at
least
for
some
of
these
environments
and
there's
related
background
materials
in
the
couple
of
individual
drafts
that
you
can
see
on
the
screen
and
also
these
ideas
were
already
presented
in
couple
of
previous
itf
meetings,
and
we
believe
that
there
was
positive
feedback
actually
from
this
idea
and
well.
C
So
to
do
that,
we
can
follow
the
approach
shown
on
the
slide,
which
is
defining
some
frame
format,
which
in
this
case,
would
be
placed
as
the
lead
to
frame
payload,
which
would
correspond
to
some
encapsulated
chip
compressed
packet
and,
as
you
can
see,
the
the
first
field,
the
leftmost
field
would
be
a
dispatch
indicating
that
what
comes
next
is
a
sheet
compressed
packet
and
at
the
right
of
the
dispatch.
We
would
have
the
sheet
packet
with
the
possibly
compressed
header
and
then
the
payload.
C
So
here
the
proposal
is
to
use
the
rfc
8025
concept
of
page
and
use
actually
dedicate
a
whole
page
for
chic
to
keep
low
overhead
and
considering
that
currently
pages
are
mostly
unused,
except
for
page
zero
and
partially
page
one,
and
the
idea
here
would
be
to
use
a
paging
dispatch,
which
is
the
one
byte
pattern
that
you
can
see,
starting
by
four
ones
and
then
a
number
of
well
four
bits
to
be
determined.
We
could
use
that
as
the
sheet
dispatch,
so
the
signal
open
dispatch
type
which
would
indicate
that
next.
C
So
then,
assuming
that
we
follow
this
path
and
we
use
this
sort
of
dispatch
for
chic,
then
okay,
which
could
be
the
potential
performance
improvement
that
we
might
achieve
still
considering
the
same
conditions
mentioned
earlier
well
in
the
traditional
way,
we
could
compress
ipv6
udp
header
by
using
6282.
C
Have
the
co-op
header
and
under
those
conditions
mentioned,
the
size
of
the
resulting
header
would
be
11
bytes,
whereas
if
we
take
this
one
byte
sheet
dispatch
plus,
then
the
sheet
compressed
header,
which
would
be
of
two
bytes
in
that
case,
then
the
result
will
be
a
format
of
three
bytes
and,
of
course
well.
We
have
this
a
by
difference,
so
we
are
sending
or
receiving
less
bytes
with
the
chic
approach.
So
in
that
case,
imagine
that
we
have
some
battery
operated
device
which
is
specifically
sending
some
message
some
packet.
C
Then
it
would
be
possible
to
well
in
theory
to
achieve
a
battery
lifetime
increase
by
up
to
40
over
15.4,
considering
any
topology
like
well,
for
example,
mesh
topologies,
but
if
we
consider
the
star
topology
where
there's
the
pan
coordinator
address,
that
is
not
present
in
the
frame
size.
So
then
the
frame
is
shorter.
Then
the
impact
of
this
potential
improvement
is
slightly
greater
and
it
might
reach
theoretically
up
to
44
so
well.
We
need
to
be
aware
that,
anyway,
the
improvement
in
a
more
realistic
setup
will
be
lower.
C
So
these
numbers
here
are
just
like
asymptotic
values
upper
bounds.
Okay,
so
there
are
different
parameters
and
different
things
that
will
influence
on
which
is
the
actual
improvement
which
will
be
lower
than
these
numbers
like
payload
size.
As
you
will
see
later
so,
improvement
will
tend
to
increase
with
payload
size.
Then
mclear
settings
will
have
some
influence
as
well,
because
we
might
use
short
or
long
mac
addresses
or
perhaps
in
some
cases
we
don't
have
ling
lay
acknowledgements,
but
in
some
others
we
do
also.
The
actual
hardware
features
will
be
relevant.
A
C
Well,
we
usually
have
a
non-zero
sleep
current
consumption,
even
if
it's
typically
the
order
of
just
few
micron
pair
and
also
things
like
transitions
from
sleep
state
to
transmit
or
receive
also
consume
some
amount
of
non-negligible
amount
of
energy,
okay
and
then
other
parameters
here
could
be
like
application
settings
like.
How
often
does
the
device
transmit
a
packet?
Well
all
this
being
said.
Well,
if
we
can
move
to
the
next
slide,
please.
C
Well
then,
first
of
all,
here
we
have
some
figure
showing
on
the
vertical
axis
the
amount
of
bytes
which
would
be
transmitted
or
received
at
the
physical
layer
under
the
assumed
conditions
with
six
low
pan,
say
the
traditional
way
of
header
compression
and
the
chic
one
so
well.
These
are
actually
results
not
affected
by
all
these
factors.
I
was
mentioning
right
now.
You
can
see
there's
the
eight
bytes
constant
difference
here
and
you
can
guess
that.
C
C
So
again
you
can
see
how,
as
we
increase
sorry,
the
horizontal
axis
label
is
incorrect.
It's
not
udp.
It's
collapsed.
Okay
and
well,
as
you
can
see.
Well,
the
performance
that
can
be
achieved
decreases
with
payload
size,
but
still
can
be
somewhat
significant
for
some
somewhat,
not
so
small
payload
size,
okay,
so
perhaps
this
could
be
useful
and
well.
We
definitely
need
to
take
into
account
that
the
actual
improvement
again
will
be
lower
than
the
numbers
shown
here,
which
are
just
the
upper
bounds,
the
theoretical
ones.
Okay-
and
next,
please.
C
There
is
by
the
way,
if
we
consider
the
star
topology
scenario.
There
is
the
particular
characteristic
of
having
the
involvement
of
the
pan
coordinator
when
we
transmit
or
receive
a
frame
where
there's
the
pan
coordinator
as
one
endpoint,
then
the
address
of
the
pan
coordinator
is
not
included,
so
we
can
still
have
a
little
bit
more
of
improvement
in
theory.
C
C
So
this
dispatch
probably
would
not
be
specific
to
any
particular
underlying
l2
technology,
so
it
would
be
quite
generic,
then
we
may
want
to
handle
padding,
because
a
sheet
compress
header
might
have
a
size
which
is
perhaps
not
always
a
multiple
of
an
l2
world
by
the
way.
L2
word
is
a
quite
lp1eh
working
group
term,
which
would
mean
the
minimum
quantum
of
information
that's
handled
by
some
layer,
2
technology.
C
C
So
there
could
be
different
approaches
like
pre-provisioning
or
using
out-of-band
beans
or
using
some
sort
of
dynamic
approach,
and
in
that
case
that
would
not
be
so
static
and
anyway.
Well,
we
may
want
to
look
at
the
solutions
that
may
come
from
the
lp1
working
group,
because
this
working
group
is
also
considering
the
same
problem.
C
Yeah
then
there's
another
option
to
use
chic
in
six
low
or
six
low
pan,
like
environments,
which
would
keep
compatibility
with
existing
layer,
3
header
compression
mechanisms,
for
example,
well,
two
eight
two
and
then
one
eight
one,
three
eight
four
round
over
mesh
and
well
as
a
reminder,
there
exists
two
lowpan
nhc
formats
defined
in
6282,
one
intended
to
allow
header
compression
of
ipv6
extension
headers,
the
other
one
for
udp
header,
compression
and
well.
C
Perhaps
one
idea
if
one
wants
to
keep
using
the
same
mechanisms
for
header
compression
like
six
three
two
and
one
eight
one,
three
eight
could
be
to
use
chic
to
compress
apple
ear,
headers,
meaning
for
protocols
like
udp
or
perhaps
udp,
co-op
and
so
on,
and
we
could
define
like
a
third
lopan
nhc
format,
which
could
be
a
chic,
open,
nfc
format
indicating
that
what
comes
next
is
sheet
compressed.
C
Well,
so
that's
the
end
of
the
presentation.
So
we
would
like
to
know
what
does
the
working
group
think
about
this
whole
set
of
ideas?
Do
you
think
that
this
could
be
interesting
to
consider?
H
Yeah,
no,
I
am
from
the
sick
world,
but
I
think
it's
a
good
thing
to
to
establish
links
between
these
two
technologies.
I
J
C
C
F
F
But
most
of
all,
I
believe
that
if
we
start
doing
check-
and
if
you
support
shaking
the
node,
then
it's
better
to
compress
both
ip
and
co-op
using
shakes.
So
I'm
not
convinced
that
there
is.
There
is
value
in
just
compressing
co-op.
I
really
support
the
work,
but
I
believe
the
most
useful
case
is
when
you
compress
both
ip
and
co-op.
F
I
Yeah,
this
is
dominic
again,
I
agree
with
you
pascal.
I
think
you
get
more
benefit
by
compressing.
Everything
in
one
go.
Have
some
doubts
on
how
we
apply
the
address
compression
then,
because
in
chic
we
assumed
that
we
have
an
asymmetric
link
with
a
device
and
a
core
network,
and
here
we
have
a
peer
relation.
So
let
me
think
about
that.
Unless
you
have
an
idea
ready.
F
Well,
if
I
may,
when
you
think
about
the
chic
over
ppp
approach,
we
are
not
in
the
same
model
where
you
have
a
gateway
and
the
device.
We
are
in
a
peer-to-peer
model,
and
it
might
be
that
the
the
model
for
chicago
is
more
like
the
chic
of
our
ppp,
where
any
there
is
no
specific
role.
I
mean
this
kind
of
more
peers
appear.
F
F
So
in
your
rules,
you
might
not
be
able
to
fully
compress
the
ip
address,
but
chick
is
very,
very
open
and
you
can
do
whatever
you
like
with
it.
So
if
you,
if
you
want
to
compress
like
the
prefix
but
not
the
autofs,
you
can
always
do
that.