►
From YouTube: IETF101-LPWAN-20180321-0930
Description
LPWAN meeting session at IETF101
2018/03/21 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
So
if
you're
aware
of
situations
or
if
you
live
through
situations
now,
you
have
a
link,
this
Ombuds
team
link
that
you
can
see
on
this
not
well
page.
These
are
a
team
of
people
that
you
may
contact.
If
there
is
a
situation
which
requires
a
discussion,
all
the
enticements
procedures
are
listed
in
VCB
25,
and
then
we
have
a
code
of
conduct
and
rules
about
copyrights,
and
all
this
has
now
now
expressed
presented
on
the
knot.
Well
as
well
so
they're
whole
here.
A
Reminder
we
will
in
turn
use
from
now,
because
there
are
always
people
riding
light
will
be
distributing
the
blue
sheets.
There
will
be
two
blue
sheets
going
from
the
top
of
the
room
to
the
bottom.
Please
put
your
email
name
and
email
in
there.
The
minutes
of
this
meeting
will
be
taken.
The
meeting
will
be
recorded
and
filmed
so
you
will
be
on
TV
show
coming
to
to
the
my
chair.
A
If
you're
coming
to
the
mic,
please
sit,
we
stand
within
this
pink,
a
square
that
is
on
the
sides
here,
and
so
so
your
your
smiling
face
can
be
seen
on
TV
and
your
presence
is
being
logged
if
you
care,
and
that
would
be
very
nice
to
participate
to
the
minute
taking
we
have
a
nice
of
pad
page.
The
link
is
on
the
screen,
both
so
that's
where
all
the
minutes
are
being
taken.
A
So
if
you,
if
you
find,
since
you
came
to
Mike,
said
something
and
you
feel
that
what
was
recorded
does
not
really
matter
what
you
wanted
to
say,
please
go
ahead
and
idiot.
It's
also
a
good
way
to
to
track
what
was
just
said.
If,
for
some
reason
you
could
not
catch
to
understand
what
was
just
said,
maybe
the
minutes
will
help
you
understand
something.
B
C
A
So
the
agenda
for
today,
so
we
have
a
long
session
and
many
things
to
say.
So
there
is
this
presentation
that
we
are
doing
now
for
the
introduction.
So
if
y'all
not
happy
with
the
agenda,
please
let
us
know
now
with
yes,
oh
that's
true,
so
I
guess
we'll
we'll
talk
about
the
Akutan
right.
After
my
talk
before
we
start
the
meeting
okay,
so
we
got
the
presentation.
A
Then
anon
Dominic,
with
the
shepherd
of
the
document,
will
present
the
status
of
the
last
call
of
the
static
context
at
a
compression
document
and
then
we'll
go
through
a
number
of
documents
which
enable
the
Sheik
compression
and
various
technologies.
So
Sharia
will
present
us
Sheikh
of
Aloha
one.
Then
one
calais
will
show
what
is
doing
on
sick
Fox
and
it
got
a
yes
or
no
God
will
present
and
be
a
UT.
A
A
B
So
on
the
status
and
where
we
are
since
our
last
time
that
we
that
we
met
so,
of
course
we
have
to
charter
items
as
of
today.
So
we
have
the
baseline
technology
description,
which
is
known
as
the
LP
one
overview
and
then
the
the
compression
draft.
That
is,
the
shake
over
co-op,
IP,
UDP
and
Sheik
over
co-op
and
IP
and
UDP.
So
the
milestones
are.
We
have
managed
to
advance
pretty
well
from
the
last
time
that
we've
met
from
the
last
IDF
and
the
op1
over
overview
draft.
B
It
has
been
submitted
for
publication
to
to
the
is
G,
so
everything
is
working
pretty
well
there
and
we
are
really
happy
with
our
with
our
progress
with
the
progress
that
we've
made.
The
two
milestones
that
we
have
the
two
points
on
route
202
a
trio
working
is
the
document,
the
draft
shake
over
IP
UDP
and
that's
the
thing
that
a
shake
for
IP
IDP
and
that's
the
main
point
that
we're
going
to
be
discussing
today
and
then
we'll
be
talking
about
future
changes
to
this
chart
or
things
to
anticipate.
B
So
the
history,
of
course,
is
well
known.
We
have
been
doing
things
in
a
pretty
rapid
pace,
so
we
had
many
many
interim
meetings
to
be
able
to
deliver
into
this
in
such
a
short
timeframe.
And
yes,
so
as
as
promised,
we
submitted
the
option
overview
to
the
SG
and
things
could
be
going
going
pretty
well
there
and
Pascal
will
tell
us
more
about
it
later
and
today.
B
Here
we
are
going
to
be
talking
about
this,
as
I
said,
the
main
IP
chic
for
IP
UDP,
so
that
won't
be
the
main
core
of
the
of
the
discussions
today
and,
of
course,
the
the
future
charter
items.
So
that
was
the
the
history
and
now
Steven.
He
asked
us
to
step
in
and
to
about
the
hackathon.
Before
this
we
are
going
to
talk
about
the
hackathon,
and
so
during
this
during
the
the
weekend.
Just
before
the
ITF,
there
was
this
wonderful
hackathon,
and
there
were
many
participants.
B
Dominical
tell
us
a
couple
of
words
about
it.
I
must
say
that
the
hackathon
is
something
really
important
that
is
getting
for
the
ITF
and
for
the
whole
community.
So
personally
encourage
you.
If
you
are
able
to
come
for
the
next
IDF
the
week
before
that
to
come
and
participate,
it
is
really
and
something
that's
becoming
super
important
and
the
hackathon
of
lp1
has
been
there
from
the
start
and
has
really
helped
us
tremendously
advanced
and
show
how
things
are
done
and
solve
outstanding
issues.
B
A
So,
just
for
the
participant
and
then
I
will
let
you
so
I'm
just
showing
how
we
basically
can
easily
get
access
to
the
documents
during
this
meeting.
So
if
you
go
to
data
trackers,
write,
EF
or
meeting
101
agenda
dot,
HTML,
which
is
the
link
I
provided
in
my
email
for
this
meeting,
you
will
find
lp1
here,
oops
a
lot
of
other
things,
and
the
first
button
here
is
show
material
meeting
when
you
click
that
button.
A
D
Good
morning
everybody
basically
Alex
set
it
on
next
time.
Please
come
and
join.
Do
you
want
me
to
present
the
other
site?
So
why
should
you
join
next
time?
First,
it's
a
big
fan.
All
the
food
is
provided
morning
midday
evening.
You
don't
have
to
care
about
anything.
Just
two
days
focused
I'm
working
on
the
technology,
I
really
love
it.
So
if
your
family,
your
employer,
allows
it,
please
do
come
and
you
will
not
regret
it.
I
can
promise.
D
The
other
thing
is.
We
include
everyone,
so,
even
if
you
think
eh
I
don't
have
an
implementation,
I,
don't
know
whatever
micro,
Python
or
JavaScript
or
anything
to
come
anyway,
because
we
have
little
notes
little
BOTS,
like
these
ones.
We
have
enough
for
everybody,
especially
if
you
let
us
know
that
you're
coming
and
we
teach
you
how
to
use
them,
and
you
can
we
have
code
in
the
repositories.
D
You
can
just
download
the
code,
control
the
little
board
and
run
the
code
and,
as
we
run
the
code,
you
get
familiar
with
the
implementation
and
with
the
draft,
and
then
we
can
discuss
details
and
Feinberg's
in
the
draft.
And
if
you
do
know
how
to
code
micro
passion,
then
you
can
help
improving
the
code.
In
addition,
but
if
even
if
you
only
come
to
play
and
run
the
code,
that's
good
in
a
forest
I
think
that's
it
yeah.
We
wanted
to
disseminate
awareness
practice,
that's
what
we
did.
We
advanced
the
code
a
little
bit.
D
Two
of
the
participants
are
really
good
at
coding.
They
advanced
the
code
quite
a
lot,
the
others
just
you
know,
discussed
and
played
and
tested.
But
it's
it's
okay
and
it's
helpful.
We
had
one
remote
participant
switchy
from
Japan
who
contributed
and
stayed
there
for
the
whole
day,
and
even
though
it
was
late
late
at
night
in
in
Japan,
and
so
we
got
his
picture
in
the
group
photo
as
well
over
Skype
and
yep.
D
D
E
A
Okay,
so
Stephen
at
conflicts,
and
it
could
not
be
with
us
to
present
the
status
of
his
document.
There
is
nothing
much
to
say:
the
progress
through
the
ISSG
has
been
very
good
and
now
the
document
is
in
the
RFC
editor
q.
So
we
expect
the
idiot
as
soon
as
we
as
they
can
to
be
submitted
as
informational,
and
we
are
very
happy
with
document
we
got
credit
commands
and
people
really
appreciated
the
reading.
So
we're
very
happy
with
it.
Any
question.
A
B
Well,
the
sky
is
loading.
The
next
presentation,
which
is
shake
for
IP
UDP
I'd,
like
to
take
the
opportunity
to
also
thank
all
the
reviewers
that
and
all
the
contributors
have
helped
you
an
overview
document
which
made
an
actually
an
excellent
document
and
I
believe
is
the
first
standard
body
document
that
goes
out
that
that
is
published
and
that
actually
regroups
information,
useful
information
for
the
main
lp1
technologies.
So
great
job
and
I
think
everyone's
super
happy
for
this,
and
it's
a
great
contribution
for
the
whole
community.
Thanks.
A
So
the
way
we
structured
this
presentation
right
now
is
more
like
a
discussion.
We
have
the
miniature
with
the
Shepherd
and
Anna
who
represents
the
authors
of
the
document
and
basically,
since
there
were
a
number
of
problems
which
were
raised
during
the
work
group,
let's
go,
the
Shepherd
will
present
the
problem
and
the
architect
will
talk
about
the
solutions.
I
guess
so,
let's
try
it.
F
Thank
you
very
much
here.
I
will
present
the
history
of
this
last
version,
10
from
last
UTF.
So
we
go.
We
start
with
version
8,
where
we
start
working
in
the
fragmentation
part
in
order
to
add
terminology
to
clean
the
text
to
create
state
machine
fragmentations.
We
improve
a
lot
of.
We
work
a
lot
in
the
fragmentation
part
in
version
8.
Then
we
create
next.
We
continue
working
cleaning
up.
The
fragmentation
text
moves
to
the
compression
text
a
little
bit
less.
F
We
put
the
state
machine
diagrams
in
the
appendix
for
version
9
and
we
start
making
more
integration
of
compression
of
fragmentation
for
this
version
9,
and
we
make
the
last
call
in
December.
We
start
in
December.
So
thank
you
very
much
for
all
the
reviewers.
We
received
a
lot
of
valuable
inputs
from
you.
We
got
a
lot
of
work
and
with
all
these
inputs
we
create
the
version
10
on
the
end
of
February.
F
F
We
try
to
interact
more
the
fragmentation
of
the
compression.
Then
we
create
three
new
sections.
The
first
one
is
overview
where
we
try
to
show
where
compression
where
fermentation
is
done.
Well,
then,
we
create
a
role
ID
section:
okay,
we
create
a
global
rule,
I
this
section
where
we
said
why
or
when
we
need
a
real
ID
and
we
create
a
padding
section
to
give
the
default
solution
for
padding
is
in
the
case
it
will
be
needed.
F
F
F
During
this
time
we
create
and
close
and
open
tickets.
These
are
the
tickets
that
have
been
already
done
during
the
internet
meetings.
You
will
see
the
first
one
is
Real
ID.
It
comes
again
and
again,
I
think
it's
a
very
good
subject
to
continue
working
in
this
group.
The
first
ticket
number
two
rule
ID
default
size
was
the
question
to
know
this
space.
He
had
how
many
beats
it
has
how
cited
sighs?
How
did
the
pattern?
F
How
can
I
design
it
and
so
forth
and
while
were
discussing-
and
we
said
that
this
document
is
more
about
to
define
compression
fragmentation
and
perhaps
we'll
need
a
new
document
to
talk
about
undefined
his
rule
ID
space?
And
now
it's
out
of
the
scope
of
the
compression
fragmentation
document,
then
we
have
a
ticket
number
three.
They
see
Bob,
where
we
add
in
the
security
part
that,
when
a
decompressive
received
a
lot
of
information
to
be
decompressed
normally
is
that
normal
or
something
that
is
not
normal?
F
F
Then
we
have
ticket
number,
nine
reordering
between
radio
gateway
and
network
anyway.
So
there
was
a
very
big
discussion
in
the
last
intern
meeting
about
that.
Also
where
we
define.
We
say
that
we
concrete
that
is
better
to
say
that
there
is
no
no
out
of
sequence
between
radio,
getaway
and
network
gateway
and
not
reordering
in
order.
So.
D
F
Because
when
we
start
working
the
sheet
compression,
we
assume
this
part,
so
we
don't
want
to
make
a
real
sequence
to
have
a
out
of
sequence,
packets
between
the
radio
gateway
and
the
network.
It
ok
ticket
number
seven
was.
The
question
was:
if
we
need
default
values
for
hub
limit,
for
example,
well,
I
think
we
don't
need
any
default
values
for
any
header
field,
because
when
we
have
a
new
value
in
a
field
for
Heather,
we
create
a
new
rule.
So
new
rule
gives
you
the
new
value
ticket
number
six.
F
Can
we
can
we
do
partially?
Can
we
partially
fill
the
window
in
the
fragmentation?
Well
for
all
one
windows
of
the
last
window,
most
of
them
are,
maybe
most
of
them
will
be
partially
filled
because
it's
the
last
window-
and
perhaps
it
will
not
be
completely
filled
for
the
all-0
windows
we
weave.
We
give
them
the
best
behavior.
We
will
fill
the
window
completely
in
all
0
windows,
but
it's
not.
F
We
are
not
against
to
do
not
feel
it,
but
if
you
use
the
partial
filled
window,
it's
only
for
always
mode
4
ticket
number
4,
the
DNS
lookup.
Ok
again,
it's
about
role
idea
how
to
fill
this
rule.
This
context
and
I
think
that
this
is
more
or
less
out
of
scope,
because
here
we
are
talking
about
how
we
compress
the
header
information
and
how
we
get
the
header
information,
so
I
think
we
need
something
to
define
all
this
part
of
role
ID,
how
we
create
it.
F
F
We
were
asked
to
give
the
technology
specific
parameters
that
each
technology
will
need
to
define
the
and
in
their
document,
so
I
opened.
The
ticket
number
15,
I
put
Dallas
I
have
created
for
version
7,
and
we
need
to
update
this
list
in
order
to
be
according
to
the
version
10
or
the
next
version.
11.
D
Okay,
so
this
was
the
the
tickets
that
have
been
closed
using
the
interim
meeting,
so
these
topics
have
been
discussed
during
the
meetings
if
one,
if
you
were
not
part
of
the
meeting
and
want
to
understand
exactly
what
these
tables.
Where
of
the
discussion
you
can
come
to
us
or
with
the
the
minutes
of
the
meetings,
we
decided
not
to
take
too
much
time
discussing
close
tickets
and
spare
time
for
the
open
tickets
which
are
going
to
come
next.
D
Okay,
thank
you.
Okay,
overall,
we
have
26
tickets
in
here
right
now,
a
few
of
them
were
closed,
which
we've
just
gone
through,
and
so
this
is
a
tickets
that
we
have
in
front
of
us.
So
we
decided
process
and
take
them
by
ticket
number.
We
would
group
them
by
topics
and
discuss
the
topics
and
we've
listed,
which
tickets
the
topics
relate
to
so
don't
bother
reading
this
list.
So
basically
one
topic
that
comes
again
and
again
is
the
overview.
How
does
that
work
says
compression
does
fragmentation.
D
They
seem
to
have
things
in
common,
like
rule
IDs,
but
the
comments
we
got
I
mean
we
in
the
comments
you
got
I'm,
not
an
offer
the
comments
that
came
up
where
we
don't
understand
how
these
two
things
work
together.
Can
you
provide
an
overview
or
an
explanation?
So
I
think
this
has
been
addressed,
that
you.
F
F
Addressed
in
the
in
the
new
section
in
the
first
section
of
the
draft,
we
will
create
a
section
overview
where
we
put
these
figure
in
the
left.
Here
we
explain
where
the
chic
layer
is
behind
the
layer
tree
and
the
functional
part
is
we
create.
We
make
compression
before
fragmentation,
then
in
the
dry
right
part
of
the
figure.
I
explain
more
in
detail
that
the
terminology
of
this
behavior,
so
when
we
receive
from
layer
tree
an
ipv6
packet,
it
goes
to
the
compression
the
compression
here.
F
F
D
One
of
the
issues
was
that
we
had
no
specific
name
to
to
name
this
thing,
that
is
behind
compression
fragmentation,
and
so
the
text
went
about
various
for
the
naming,
the
either
compressed
or
not
compressed
if
it
could
not
be
compressed
or
blah
blah
blah.
So
now
we
termed
it
a
shake
packet.
So
that's
a
new
term
that
goes
into
the
template,
technical
terminology,
so.
F
G
F
Then
this
chic
packet,
if,
if
needed,
if
it
doesn't
fit
in
the
layer
to
a
PD?
U
it
will
be
fragmented
and
it
goes
to
the
chic
fragmentation
and
it
will
be
cutted
in
SiC
fragments.
So
we
create
chic
fragment
chic
fragmentation
because
before
we
were
talking
about
fragmentation
and
fragments-
and
now
we
add
the
chic
acronym
before
in
order
to
join
these
two
parts
of
Cheikh
document
and.
D
F
D
D
I
didn't
actually,
if
needed
here,
because
what
does,
if
needed
me,
who
decides
if
it's
needed
or
not
so
right
now
what
the
proposed
diagram
that
will
likely
be
in
the
11
version.
Look
like
this
and
so
we're
seeking
inputs.
If
it's
this,
if
this
is
clear
or
if
we
need
to
do
even
more
so
can
I
explain
what
happens
here
then.
B
F
I
received
an
ipv6
packet
I
go
to
compression
whatever
it
happens
here,
I
get
a
ship
packet.
If
this
chick
packet
fits
in
the
layer,
I
didn't
make
I
do
not
make
fragmentation,
I
and
I
send
it
to
the
other
side.
If
this
ship
packets
doesn't
fit,
then
I
need
Sheik
fragmentation
and
I
cut
it
in
fragment
and
I.
F
Send
this
fragment
when
I
don't
did
induced
this
fragmentation
in
the
other
size,
I
only
get
decompression
and
I
send
a
the
decompressed
packet
to
the
layer
tree
when
I
make
fragments
here
than
in
the
reassembly
SheiKra
assemble
part.
I
will
get
all
the
fragments.
I
will
make
all
the
Sheik
mode
of
fragmentation
modes
and
then,
when
I
get
all
the
packet
I
send
into
the
decompression.
H
H
D
D
B
About
the
way
to
proceed
here,
we
hear
there
are
quite
a
lot
of
open
issues,
so
what
I
would
say
is
because
I
don't
want
to
make
everyone
vote
for
like
10
times
in
the
next
30
minutes.
In
case
you
feel
that
you,
you
are
not
clear
on
this
or
in
case
you
feel
that
you're
against
something
that
is
said
here.
Please
go
to
the
mic
or
raise
your
hand,
and
this
way
we'll
know
to
go
out
in
discussion.
D
D
D
We
don't
understand,
you
know
how
do
you
name
things
and
so,
as
we
said
before,
we've
decided
on
chick
packet,
shake
fragments,
we
will
kept
a
nice
packet
and
we've
decided
on
compressed
header.
Compressed
header
is
what
is
achieved
after
compression
of
the
packet
coming
from
the
upper
layer.
We
shake
his
head
or
compression
the
HC,
so
we
are
compressing
the
header
we're
not
compressing
payload,
which
was
not
always
understood.
So
we
have
now
we
are
going
to
define
a
compressed
header
as
being
what
results.
D
What
comes
out
of
the
compressor
and
the
compressed
header
is
composed
of
two
things.
One
thing
is
a
rule
ID
and
the
rest
that
we
need
to
transmit
is
called
the
compression
residue.
Hopefully,
in
the
best
case,
the
rule
is
so
well
adjusted
to
the
packet
header
that
needs
to
be
compressed
that
it's
enough
to
send
a
rule
ID
and
it
the
rule
idea,
tells
everything
about
the
compressed
header.
In
some
cases
there
are
a
few
bets
that
are
not
totally
defined
by
the
rule.
D
H
H
D
But
then
you
know
things
get
confusing,
so
we
decided
that
we
will
coin
a
new
term
which
will
be
a
shake
act
so
that
we
don't
confuse
it
with
reacts
at
other
layers
and
it
will
have
its
own
name.
It
will
no
longer
be
described
as
a
special
case
for
a
fragment,
and
so
the
encoding
hasn't
changed,
but
it
will
be
called
a
shaker.
One
thing
also
I
requested
is
that
we
didn't
have
a
name
for
a
in
the
rule
table
and
again
the
text
went
about.
D
D
If
the
layout,
who
wants
to
do
act
if
they
are
for
wants
to
do
AG,
that's
their
problem,
but
if
we
do
a
fragment
and
it
becomes
an
array
of
Sheikh
fragments
and
there
we
have
realized
a
few
but
reliability
mode,
two
modes
that
do
involve
acts
so
they
are
chic
acts.
Do
you
think
we
should
add
chic
acts
on
this
diagram
with
a
an
arrow
going
backwards?
I
see,
yes,
is
okay,
good
point
we'll
do
that.
I
Maybe
20
for
me
again
George
from
Atlantic
what
about
having
a
small
condition
just
before
the,
if
no
fragment
like
saying
that,
if
fit
to
l2
then
transmit,
if
not
go
back
to
the
or
to
the
fragmentation,
yeah
good.
A
J
The
Ramos
from
Erickson
we
have
had
a
discussion
in
the
interim,
and
the
problem
is
that,
depending
of
the
technology,
you
might
not
even
want
to
have
fragmentation
activated
at
all,
because
you
could
have
fragmentation
in
lower
layers.
So
then
I
mean
why
you
have
threatenin
fragmentation
or
not.
Maybe
it
would
be
good
to
be
left
out
of
the
document
and
leave
it
in
each
technology
document.
D
So
yeah
20
point.
Actually,
when
we
do
this,
we
we
had
your
case
in
mind.
Well,
it's
a
purl,
saying
transmission.
If
no
fragmentation
included
the
case,
if
that
a
given
technology
does
not
want
shake
to
do
fragmentation,
not
just
that
the
packet
fits
into
the
actual
frame,
so
the
if
Noah
was
vague
enough
to
include
at
cos
case
now.
If
we
go
your
way
adding
the
diamond-shaped,
then
maybe
we
need
to
have
another
thing
thing.
Maybe
you
don't
want
to
do
fragmentation
as.
K
A
restriction
so
Edgar
just
to
confirm
you're,
saying
like
the
best
you
need
to
be
made
after
the
input
pipeline
or
like
the
technology,
can
decide
based
on
it's
empty,
whether
it
wants
fragments
or
not
right.
So
the
input
to
this
pipeline
is
an
ipv6
packet,
so
you
could
have
decided
before
that
right.
J
Sure
sure
the
problem
is
this
is
a
girl
again
that,
for
example,
naruban
IOT,
you
could
have
basically
no
empty
you
limit
because
you
can
segment
the
lower
in
the
lower
layers.
So
if
there
is
any
segmentation,
the
optimization
is
done
by
the
lower
layer.
So
you
don't
need
to
order
at
Heather's.
On
top
of
that,
so
then
it
makes
sense
not
to
have
fragmentation
in
in
certain
transmission
mode.
So.
J
Is
and
yes,
yeah,
the
problem
is
that,
for
example,
for
naruban
iot,
you
have
link
adaptation,
which
it
means
that
you,
the
video
sizes,
don't
known
until
transmission
a
couple
of
milliseconds
before
transmission.
So
then
it
would
be
pretty
difficult
to
adjust
this
all
the
time.
So
what
is
the
maximum
size
that
you
are
going
to
have
so
in
a
working.
D
A
B
G
B
Would
like
to
I
mean
I
would
keep
this
in
mind
and
not
put
too
many
complexification
in
the
picture
because
people
they
say,
ok.
Well,
you
know
there
is
this
thing.
I
would
like
just
to
have
like
a
big
picture
overview
without
going
down
to
the
nitty-gritty
details.
So
is
it
I
mean
there
is
maybe
something
for
you
to
consider
and
for
Edgar
and
for
everyone
like?
Is
it
ok
to
leave
it
simple
and
have
some
star
and
then
say?
B
Well,
you
know
if
blah
blah
blah
blah
other
ifs,
but
at
least
you
have
the
picture
pretty
simple
for
people
to
grasp
very,
very
rapidly:
ok,
first,
a
little
compression,
then
you
know
if
I
need
fermentation,
then
I
do
the
fermentation
and
then
okay,
if
I
need
I,
need
to
define
and
that's
in
a
different
document.
So.
D
J
What
it
means,
if
needed,
fragmentation
that
might
be
like
maybe
three
lines
in
the
text
that
it
says
if
needed,
fragmentation
is
up
to.
You
know
each
of
the
documents,
but
majority
of
the
case
would
be
fit
in
a
if
it
fits
an
MTU.
So
it
could
be
something
like
that
that
it
says
kind
of
a
default
that
it
would
be
fitting
there.
They
name
to
you,
but
then
also
clarify
that
it
could
be
meaning
something
else
in
these
other
documents.
J
K
K
K
H
Point,
thank
you.
Juan
Carlos,
who
knew
yeah
well
like
I,
guess
just
reporting
the
duration
and
Alex
points
and
I
understand
well,
Edgar
can
perhaps
I
would
have
other
constraints
for
it
with
sick
folks
or
so,
if
we
just
add
it
to
the
list
of
to
be
done
by
layer
to
specific
documents,
and
then
we
point
to
there
it'll
be
clear
to
say:
okay
well,
this
is
not
known.
I
have
to
see
what
what
is
on
here
and
then
once.
D
Okay,
MSB
LSB,
so
the
the
comments
forgot
about
that
is.
The
text
is
a
bit
unclear.
What
do
you
mean
which
is
x
and
y?
So
just
to
recap:
for
those
who
haven't
been
following
closely:
we
have
a
matching
operator,
so
we
have
the
incoming
packet
on
the
top.
We
match
it
again
against
pattern,
which
is
a
target
value.
D
If
it
does,
then
the
rule
applies
and
if
everything
else
matches
in
the
rule,
we
go
to
the
compression
action
CDA
and
we
do
something
and
actually
you
don't
have
to
have
the
CDA
lsbe
when
you
use
a
matching
operator,
I
must
be,
but
it's
what
it's
meant
I
mean
there
are
meant
to
work
together.
So
this
is
a
normal
situation
and
in
the
document
we
say
we
match
with
an
X
bits
and
we
can
send
Y
bits.
D
So
the
people
were
confused
about
x
and
y,
and
you
know
what
happens
if
x
and
y
are
disjoint
and
missing
bits
in
the
middle,
and
the
draft
currently
didn't
say
that
the
target
value
has
to
be
at
least
experts
experts.
Otherwise
you
don't
have
data
to
match
the
packet
to
so
you
know,
what's
the
situation
here,
can
you
explain
us
how
this
works
and
what
the
draft
would
say.
F
Is
V
X
bits
and
you
have
a
match
in
a
parameter
operator:
MSB
you
will
you
will
now
the
the
length
of
the
film
and
you
can
you
can
compute
there?
Why?
Because
you
know
the
length
and
you
send
the
residue
in
the
sheik
packet.
Sorry.
So.
F
E
D
On
this
one,
if
it's
x
and
y,
don't
add
up
well
if,
if
there
are
bits
in
between
next
one
is
a
variable.
So
if
x
and
y
I
don't
add
up
to
the
field
size,
if
the
total
is
smaller,
then
you
there
are
few
bits
that
will
not
be
matched
against.
So
they
are
don't
care
bits
actually
and
they
will
not
be
sent
either,
so
they
will
be
reconstructed
from
the
other
side
and
so
basically
you're
replacing
don't
care
bits
by
a
priori
bits
on
the
other
side.
D
A
Did
you
find
a
Pascal
Cisco?
Do
you
have
a
particular
case
while
you
use
it
already
the
the
hole
in
the
middle,
because
I
was
thinking
about
reserved
fields
and
when
we
have
a
result
field,
usually
the
rule
is
like
you
must
set
it
to
zero
at
the
ignore
it.
You
know,
if
you
don't
know
what's
in
there,
and
so
it
looks
like
the
default
behavior
of
filling
with
zeros
could
be
like
reserved
wheel.
But
if
you
think
about
other
use
case
then
reserve
that
maybe
it's
a
different
value.
L
D
D
B
Exams
are
here,
so
what
I
would
say
here
is
that
you
could
imagine
that
you
can
use
in
the
LSB
in
other
contexts.
Independently
of
that
must
be
at
some
point,
so
it's
good
to
be
able
to
specify
LSB
like
to
say.
Okay,
LSB
takes
a
parameter
and
it
takes
the
least
significant
bits.
Then
I
would
go
with
something
like
if
it's
necessary
either
go
Pascal's
way,
say:
okay,
well,
others
should
be
zero
or
or
you
know,
maybe
they
can
give
taken
from
the
target
value
or
something
but
I.
B
Don't
I,
don't
have
strong
opinion
on
this,
so
it
could
be
really
as
the
room
decides.
I
would
feel
that
it's
good
to
have
it
as
it
is
like
the
minimum
changes
to
the
draft,
and
if
you
feel
that
there
must
be
some
develop
values,
then
you
know
set
it
to
zero.
Otherwise,
if
it's,
if
it
works
from
this,
then
it's
okay.
Okay,.
D
So
I'm
hearing
that
this
is
okay,
we
you're
suggesting
you
not
to
change
anything.
There's
anybody
in
a
room
thing
that
which
this
is
really
headache
and
it's
no
use
so
which
should
change
it
raise
hands.
Nobody
so
yeah,
just
clear
it.
This
way,
we'll
try
to
I
mean
we
came
up
with
the
drawings
so
that
we
are
able
to
explain
it
to
you.
These
drawings
aren't
in
drew
draft
right
now.
This
is
why
I
think
people
were
confused
over
again.
I
suggest
the
office
put
this
drawing
in
the
draft.
Yes,.
M
M
D
L
D
D
Of
the
x,
not
okay,
interesting
okay,
if
you
thought
this
was
complex
now
we
get
to
the
real
meat
of
it,
because
because
this
was
all
with
fixed
size
fields,
and
now
we
have
variable
sized
fields.
So
why
do
we
have
variable
size
fields?
We
I
mean
the
group
wants
to
compress
coop
cohab,
as
you
are
eyes,
you
are
eyes,
are
variable
in
length,
contrary
to
ipv6
UDP,
which
have
fields
that
have
well-known
sized.
You
know
it
in
advance
is
if
it's
going
to
it,
be
a
PVCs
you'd
find
so
many
bits
for
this.
D
D
The
only
case
we
have
for
variable
length
field
is
co-op
your
eyes,
so
it
was
kind
in
the
mind
of
the
office
that
this
was
the
only
use
case
and
I
mean
the
explanation
was
kind
of
driven
by
that
assumption,
which
may
not
have
been
present
in
the
readers
head.
So
we're
trying
to
explain
what's
going
on
here
and
then
we'll
decide
what
we
put
in
a
draft.
D
So,
let's
take
the
case
of
the
URI
needs
to
be
transmitted,
it's
random
and
we
can't
hide
it
and
in
any
way,
because
we
don't
know,
what's
going
to
come
so
then
we
would
use
a
matching
operator
which
is
ignored.
So
we
just
ignore
this
field
value
and
we
use
a
CDA
which
is
send
it.
So
we
will
send
as
a
residue
this
field
value.
Now,
because
it's
variable
length,
we
have
to
tell
the
decompressor
what
the
size
of
this
residue
is,
because
it
can't
tell
from
the
rule.
D
So
we
need
to
pass
this
shake
packet,
that's
coming
in
and
it
needs
to
know
how
many
bits
are
in
this
residue,
which
is
a
field
value.
So
the
draft
says
we
send
a
field
length
so
that
the
decompresses
knows
how
many
bit
is
a
residue,
because
it
was
meant
for
co-op,
your
eyes
and
your
eyes
our
strengths,
which
are
8-bit
bytes.
The
draft
currently
says
the
length
is
expressed
in
bytes,
so
everything
else
is
bit.
D
6A
is
no
alignment
whatsoever.
Everything
is
bit
except
here,
which
is
we
treat
data
byte
data
by
the
line
there,
and
so
the
length
is
a
number
of
bytes,
and
this
got
people
confused.
Why
is
it
bites?
You
said
it's
only
bits,
so
this
is
why,
of
course,
the
offers
could
make
it
bets,
but
in
most
use
cases
you
will
have
three
bits:
free
extra
bits
to
the
number
of
bits
with,
and
the
number
would
always
be
a
multiple
of
eight
anyway
before
I.
D
Let
you
interject
law
I
just
want
to
explain
one
more
thing:
the
length
is
sent
before
the
residue
and
the
offer
decided
the
length
can
be
extremely
variable.
You
can
have
small
fields,
small,
your
eyes,
like
one
character
or
three
characters,
and
you
can
have
long
ones
like
dozens
of
bytes
in
your
string
and
so
what
size
should
be
the
length
that
is
sent
on
over
the
wire.
D
Should
it
be
three
bit
five,
eight
six
bit
eight
bits.
If
it,
if
you
make
it
too
big,
then
you're
wasting
bits.
If
you
make
it
too
small,
then
you
cannot
encode
longer
values,
and
so
the
smart
idea
with
that
the
length
will
be
variable
length
encoded
like
he
bought
for
those
who
knows
he
bow.
So
if
the
length
is
a
small
number,
it
will
take
few
bits
on
the
wire.
If
the
length
is
a
large
number,
it'll
take
more
bits,
and
so
the
draft
explains
this
encoding,
which
is
not
the
same
as
evil.
D
E
D
Okay
and
we're
just
explaining
what
happens
and
again,
if
you
strongly
object
and
say
no,
we
want
lengths
in
bits
not
bytes,
because
I
have
a
use
for
variable
length
field
that
is
not
white.
Tell
us
or
no
I
won't
bit,
because
the
philosophical
ground
I
want
everything
to
be
bits.
Tell
us.
Otherwise,
things
are
going
to
stay
the
way
they
are.
The
thing
I'm
doing
here
is
explaining
what
how
it
is
right
now
in
the
draft.
If
you
have
attempted
to
read
it
not
succeed,
I.
L
Just
want
to
add
that,
normally,
when
you
define
the
rule,
you
have
a
length
field
at
the
beginning,
but
tell
you
the
length
of
your
field,
of
course,
and
it
can
be
a
number.
So
it's
a
fixed
length
or
you
put
a
keyword.
Currently
we
defined
var
to
say
that
is
a
variable
length
and
it's
not
in
the
text
now
we
have
to
add
it,
but
we
have
to
say
that
the
unit
is
all
bytes,
but
we
can
also
create
another
keyword.
L
D
L
It's
different
from
Sieber,
because
in
Sivir
you
have
small
values
and
then
you
say
it's
a
bite.
It's
to
bite
is
for
vertex
they're
extra.
But
here
in
fact,
what
we
want
to
do
is
to
be
to
the
closest
on
the
smallest
value.
And
so
we
don't
want
to
waste
the
smallest
value
to
say
it's
one
bite
or
two
right.
So
we
go
to
the
end
and
then
we
extend
to
one
more
bite.
So
we
want
to
have
only
small
value
because
it's
stupid
to
send
along
the
URI
when
we
want
to
send
another
one.
D
D
D
Now
we
get
to
another
one
which
is,
you
are
expecting
a
few
possible
your
eyes
like
full
bar
or
index,
who
is
free
characters,
bias,
free
characters,
indexes
five
characters
and
that's
the
only
free
your
eyes.
You
are
expecting
anything
else.
You
don't
need
to
process,
you
can
drop
the
packet
or
we
don't
want
to
optimize
that.
So
we
have.
You
have
a
variable
length
field,
which
is
a
URI
coming
in
and
you're
expecting
three
values:
free
potential
values.
D
So
you,
the
basic
mechanism
in
Shaikh,
is
to
use
match,
mapping
and
mappings,
and
so
you
look
at
the
incoming
packet
see
if
the
field
value
is
among
a
list,
the
target
value
in
your
list
in
this
key
in
matchmaking
opera,
and
if,
if
it
is
among
the
lists,
and
instead
of
sending
that
field
value,
you
send
the
index
into
the
table,
the
table
is
known
as
a
receiver.
So
from
the
index
the
receiver
would
be
able
to
reconstruct
the
field
value.
D
So
the
residue
in
this
case
is
going
to
be
the
index
into
the
table.
Not
the
value
and
the
index
has
a
static
length,
it's
known
from
the
other
side,
so
we
don't
have
to
send
the
length
because
the
index
is
a
fixed
length.
So
again,
this
was
a
confusion
in
the
draft
that
we
talked
about
the
incoming
length
incoming
field.
That
has
variable
length,
but
then
we
don't
send
the
length
on
the
wire,
even
though
the
incoming
packet
incoming
field
is
a
variable
match,
and
this
is
because
index
is
of
static,
sighs
no
inside.
A
D
A
D
A
G
A
A
D
F
N
F
G
D
M
B
D
I'm
saying
I:
don't
think
they
were
that
many
people
who
really
could
understand
what's
going
on
with
the
text
we
spent
about
six
hours
in
the
next
in
the
previous
two
days
to
make
sure
with
everybody
around
the
table
agreed
on
what
actually
was
going
on,
and
we
try
to
capture
that
in
the
drawing
and
now
I'm
expressing
this
over
to
you
and
I'm
asking
if
everybody
everybody
is
happy
with
that
behavior.
If
I
get
a
yes,
then
the
office
will
try
to
capture
that
understanding
into
a
document
that
is
legible.
K
D
G
D
D
D
Okay,
rule
ID.
Now
we
come
to
the
real
debate.
D
D
F
Is
needed
to
identify
the
compression
rule
on
the
context
for
compression
it's
needed
for
identified
a
specific
mode
of
fragmentation
and
the
settings
of
fragmentation,
and
it's
at
least
we
need
perhaps
one
rule
more
than
one
for
the
case
where
compression
is
not
possible
and
fragmentation
is
not
needed,
and
then
we
have
an
ipv6
packet
and
we
need
to
have
a
rule
ID.
For
this
specific
case.
Okay,.
D
So
yeah,
maybe
to
jump
back
to
this
one.
So
actually
the
road
IDs
are
just
there
to
tell
things
about
when
you
are
the
receiver
of
the.
How
do
you
know
what
you're
getting
on
your
you
know
leo
to
payload,
so
it
could
be
either
a
compressed
packet,
so
you
have
a
rule
ID
and
the
rule
I
details,
it's
a
compressed
packet
sheik
packet
and
this
is
a
rule
to
be
applied
to
decompress
or
it
could
be
a
shake
fragment.
D
You
have
to
be
able
to
tell
them
about
that's
why
we
have
rule
IDs
so
to
be
able
to
identify
what
we
get
on
the
receiver
side,
but
there's
no
absolutely
no
assumption
on.
How
do
you
tell
them
about
as
long
as
you
can
tell
them
tell
them
about
your
fine,
and
so
you
could
use
any
numbering
system.
You
can
use
entropy
coding,
variable
length,
open,
open
numbering
to
the
right
could
be
anything,
so
the
draft
does
not
assume
you've
allocated
a
fixed
number
of
bits.
D
D
J
Go
ahead.
Carano
second
I
think
it's
important
what
you're
saying
that
it's
not
a
specified
as
a
fixed
number,
because
otherwise,
if
you
have
a
packet
that
is
not
compressed
and
you
need
to
attach
to
the
other
rule
ID.
So
actually,
instead
of
compressing
you're,
adding
more
overhead
you
so
then
something
clever
has
to
be
done.
Maybe
technology
wise
to
indicate
that
that
that
rule
ID
is
actually
meaning
that
there
is
no
compression
and
then
try
to
reduce
the
overhead
asset
to
the
minute.
D
J
One
beat
then
actually
you're
adding
a
bite,
because
you
know
they
they
they,
because
they
they
octan
alignment
and
so
on,
but
I
mean
it
was
just
an
observation.
I'm
not
really
a
fighting
against
this.
Just
that
to
keep
in
mind.
That
then,
put
that
that's
a
consequence
of
this
and
it's
good
to
keep
it
in
some
way,
free
so
that
it
can
be
found
a
clever
solution,
yeah.
So.
D
E
D
D
And
and
what
God
people
confused
is
that
in
the
draft
we
have
these
figures
nine
to
twenty
three,
which
is
fourteen
figures
that
I
found
confusing
because
it
they
had
this
R
value,
which
was
the
size
of
this
fragment
header
and
she's.
A
constant
and
it's
a
constant.
It's
explained
in
the
draft,
so
I
was
kind
of
assuming
that
our
was
a
constant
as
well,
but
it
didn't
have
to
be.
F
Fragmentation
Heather
anything
is
fixed
at
but
W.
That
is
one
bit
because
row
ID
has
not
a
fixed
size.
D
tag
has
not
a
big
size
and
if
Sheehan
has
not
a
fixed
size,
so
it
depends
what
you
are
choosing
to
do,
that
you
have
this
harder
or
smaller.
So
when
you
look
at
this,
of
course,
as
I
said,
you
said
we
could
get
confused
to
the
know
if
R
is
always
the
same
size
all
the
time
or
not.
So
perhaps
we
can.
How
do
you
think
of
removing
this
R
and
put
it
fragmentation?
Header?
F
D
H
Yeah
I
I'm,
not
sure
you're.
You
know
it's
just
we're
trying
to
digest
what
you
are
explaining
at
least
that's
my
case.
So
what
you're
saying
is
that
the
values
will
I
mean
I,
understand
that
they
can.
There
can
be
different
sizes
of
@cn
and
they
rule
ID
itself.
But
what
you're
saying
is
that
they
will
vary
nine-time
over
the
same
technology
and
the
same
connection,
no.
L
F
Are
in
fragmentation
for
compression,
we
can
vary
from
politely
from
variety
and
different
package
has
a
different
role:
ID
with
a
different
size,
but
here
in
fragmentation,
all
the
packet
that
is
fragmented
will
have
the
same.
Provideed
attack
FCN
size,
all
the
fragments
of
this
packet
that
will
be
fixed
in
a
certain
way.
D
H
F
L
E
F
E
F
F
D
When
one
example
could
be
an
Aurora,
for
example,
this
is
this
specific
bite.
That's
called
the
export.
It's
there
anyway,
it's
not
costing
anything.
It
has
some
reserved
value,
but
as
long
as
you
use
the
UN
reserved
value,
it's
free,
so
you
could
map
route
IDs
onto
the
free
values
of
F
port,
because
you.
E
D
Doesn't
cost
more
on
some
other
technologies
which
don't
have
this
kind
of
F
port
bite?
That's
special
you're
eating
into
your
payload
and
so
human.
You
want
to
be
very
thrifty
in
a
number
of
bits.
You
are
locate
or
you
can
do
entropy
coding
or
whatever,
and
if
you're
doing
an
interoperable
system
you'd
better
have
the
two
ends
agree
on
the
this
thing:
if
you're
doing
a
private
network,
then
you
can
divine
design
your
own
okay,
you.
C
D
C
D
D
H
Or
implementation
from
California,
so
I
originally
had
the
same
concerns
as
Julia.
That's
that's
why
I
was
asking
you.
You
know
if
it's
May,
so
at
least
personally
I
would
say
just
clarifying
this
document.
You
know
that
it's
it's
a
man!
You
have
that
flexibility.
That
may
be
useful
for
some
people
and
for
some
other
people
may
not
be
useful
at
all.
So
it's
just
clarifying
that
it's
not
one
or
the
other
that
we
are
yes.
D
My
recommendation
to
the
office
is
to
be
explicit
as
to
why
we
need
to
write
is
what
they
are
used
for.
What
the
last
single
purpose
is,
which
is
to
tell
things
apart
and
leave
all
the
rest
to
the
other
documents,
and
maybe
we
can
have
an
appendix
that
suggests
things
like
a
fixed
number
of
bits
or
finishing.
K
K
Then
I
had
the
same
question
as
Julian
and
and
one
Carlos
right
because
either
we
say
like
just
leave
it
to
the
technology
and
let
the
technology
figure
it
out
and
they
explain
whatever
right,
just
lay
like
artists,
whatever
the
technology
says
and
handled
in
the
technology
specific
document.
Yes,
it
is
fixed
or
not,
because
somebody
might
want
to
keep
it
fixed
or
not.
So
let's
not
even
go
there.
The
current
text
is
good.
I,
don't
want
to
change
anything.
The.
D
K
D
O
D
So
yeah
this
can
be
another
discussion,
but
right
now
I
they
share
the
same
space.
And
that's
why
I'm
saying
you
need
to
you
need
to
be
able
to
tell
things
apart
and,
but
you
just
said
is
that
this
has
the
same
space
is
actually
a
consequence
of
what
I
said.
You
need
to
be
able
to
tell
things
apart,
because
you
can
be
getting
a
check
packet
and
fragmented
or
you
could
be
getting
fragments
and
you
need
to
be
able
to
tell
things
apart.
D
F
D
So
maybe,
let's
speak
openly:
there
is
one
technology
out
there
which
is
sick
fox.
That
has
a
four
word:
payload,
that's
not
byte
aligned.
We
know
one
it's
exhausted,
so
yeah
I
mean
it's
part
of
our
target,
so
they
can
transport
any
payload
of
any
number
of
pits,
not
bytes.
So
we
don't
want
to
constrain
any
alignment
in
this
document
because
you
know
why
waste
bits,
every
padding
is
a
news
bit
that's
being
on
a
wire.
So
what
this
document
says
and
aims
at
doing
it's
not
being
aligned
on
anything,
only
bits,
of
course.
D
So
that's
the
intention
and
actually
I've
personally
think
that
the
document
could
be
better
because
it
does
talk
about
byte
boundaries
here
and
in
the
in
the
document,
so
I'm
I'm,
advocating
for
it
to
talk
about
natural
boundaries
for
the
underlying
technology,
which
might
be
bits
in
some
cases.
So.
H
Honker
losing
six
just
clarifying
because
we
thought
we
had
a
small
but
perhaps
a
little
confusing
text
that
I
just
recently
updated
so
clarifying
on
on
the
way
it
works
in
sick
fox.
You
can
send
either
one
bit
or
bytes.
Oh
so
so
I
try
to
add
some
sound.
That's
in
the
uplink
on
the
downlink.
It's
an
eight
by
that's
a.
H
A
A
D
A
Also,
when
you
talked
about
the
coop
and
things
which
is
considering
byte,
do
you
imagine
that
people
would
shift
that
it
seems
that
at
least
the
the
variable
byte
aligned
the
well
strings
for
viable
lengths?
This
should
all
be
byte
aligned
right,
no
I,
don't
see
you
shifting
those
things.
Would
you
yes.
D
K
Krisshnan,
so
not
like
related
to
any
specific
thing,
but
I
found
the
issue
tracking
to
be
a
bit
difficult
because
when
he
said
for
the
last
one,
it's
an
issue
number
12
right,
I
think
it'd
have
been
useful.
If
you
had
a
real
issue.
Tracker
and
I
offer
a
set
up
one
with
because
it's
like
everything
is
just
on
the
mailing
list
and
it's
hard
for
me
to
keep
track.
I,
don't
know
if
you
have
another
system
somewhere
at
a
keeping
track
off,
but
I
only
see.
M
F
G
K
D
K
D
K
K
D
D
Let
me
explain
what
the
thing
is
and
now
you
explain
the
solutions.
Yeah.
We
have
two
AK
formats,
there's
AG
for
Windows
that
are
not
the
last
one
of
a
packet
and
there
is
the
AG
for
the
last
window
on
the
packet
and
for
the
last
window
we
have
a
C
bit
which
tells
if
the
Mickey
checked,
okay
or
not,
because
we
think
we've
reassemble
the
whole
packet,
and
so
we
verify
that
assumption
by
computing,
the
mech
and
comparing
it
to
the
one
that
was
sent
and
yeah.
E
D
This
is
a
way
we
know
the
transfer
of
all
fragments
were
is
is
completed,
okay,
and
so
we
have.
The
fragment
format
has
one
a
bit
for
the
last
window,
so
presenting
windows
of
fragments,
getting
axe
for
each
window
in
the
last
window
gets
an
axe,
and
this
nag
has
a
slightly
different
format
than
the
previous
acts
for
the
same
flow
of
fragments
coming
from
the
same
packet,
and
this
fragment
is
this
Aggie
coming
back
has
one
more
bit:
is
it
a
problem
or
not
so
yeah?
It
may
be
a
problem.
F
D
Are
cases
where
this
is
no
problem?
If
you
are,
if
your
l2
is,
has
a
payload
big
enough
to
accommodate
for
all
bits,
you
don't
care,
you
have
one
more
bit,
so
what
okay
just
send
this
one
more
bit
now
we
are
discussing
the
situation
where
your
l2
payload
is
kind
of
small
and
you're
trying
to
optimize
its
use,
and
so
we
are
discussing
you
know
fitting
eggs
into
the
n2
payload.
D
F
F
D
E
D
A
right
to
sorry
it
might
hit
you
just
pay
attention
if
you're
short
on
on
your
l2
payload
make
sure
your
max
window.
Fcn
is
a
bit
smaller
than
you
would
think,
because
you
have
to
accommodate
this
extra
bit
on
the
last
act.
So
you
will
not.
What
does
it
have
a
link
with
max
window
FCN,
because
a
bitmap
that
you're
sending
back
on
an
AK
has
a
number
of
bits,
that's
equal
to
the
max
window,
I've
seen.
D
So
if
this
bit
is
a
problem
for
you
make
sure
you
don't
fill
up,
the
other
acts
leave
space
for
this
extra
bit.
Another
option
would
be
to
change
the
mechanics
that's
currently
described
by
this
draft
saying
the
last
window
is
an
exception
to
the
fragmentation
mechanism.
The
last
window
would
not
send
max
when
FCN
fragments
at
most
it
will
send
at
most
max
wind,
FC,
n,
minus
1,
and
we
know
in
the
both
ends,
know
that
so
we
create
that
extra
space
for
this
one
extra
bit
so.
D
No,
no,
that
was
option
one.
What
you
just
said
price
to
option.
One
now
option
two
for
the
oldest
your
windows:
we
still
have
the
same
number
of
fragments,
so
we
utilizing
the
full
bandwidth
both
ways
and
we
create
an
exceptional
processing,
which
is
the
last
window,
has
a
different
processing.
It
has
a
different
bitmap
size,
so
we
create
a
space
for
the
cbut.
Does
anybody
have
an
opinion
on
that.
D
Well,
we
got
comments.
Can
you
explain?
We
have
a
sentence
in
the
draft
that
says
something
about
this
extra
bit
and
something
that
people
should
be
paying
attention.
So
we
got
the
comments.
What
do
you
mean?
What
what
exactly
should
we
be
paying
attention
to
and
so
I'm
trying
to
explain
you
what
we
should
be
paying
attention
to
and
then,
during
the
discussion
once
an
option
to
emerge
that
we
could
change
the
behavior
of
the
machine
such
that
people
don't
have
to
pay
attention
well,.
O
A
F
L
It's
eight
bits,
so
it's
not
that
big,
so
it
fits
in
most
of
beyond
surf.
So
it's
very.
It
will
be
a
very,
very
rare
case
and
in
which
case,
maybe
it's
better
not
to
use
over
there
Nowak
or
something
so
I,
don't
think
it's
a
problem.
I
think
we
should
document
it,
but
we
must
document
it,
but
alright.
D
L
D
Your
second
option,
one
and
what
I
heard
you
saying,
also
is
reminding
people
that
we
are
discussing
this
special
case,
where
you're
very
constrained
on
your
l2
payload
size
on
the
return
path,
and
so
that
this
extra
bit
does
matter
and
so
you're
saying
in
most
situations
most
technologies.
This
extra
bit
does
not
matter,
and
we
are
discussing
something
that
nobody
cares
about
so,
rather
than
changing
in
mechanic's
you're
suggesting
changing
your
sentence
and
explanation
sentence
in
a
draft.
So
I
think
this
is
pretty.
B
Short
question
about
that:
it
can
this
be
solved
also
in
ticket
15,
to
say
to
technology,
so
that
the
information
that
is
requested
by
technology,
specific
documents
to
say
well,
please
take
a
look
at
this
and
put
a
sentence
in
your
technology
specific
draft.
What
do
you
do
in
this
case?
Okay,
so
if.
D
The
working
group
decides
we
go
option.
One
then
you're
right.
We
can
add
this
into
ticket
15
to
be
explicit,
have
an
explicit
warning
to
the
other
draft.
If
the
working
group
decided
to
go
option
2,
then
we
would
need
to
change
the
state
machines
and
everything.
But
what
I'm
hearing
right
now
is
option
1,
but.
A
M
A
C
M
D
B
D
The
okay
so
we'll
go
to
the
meaning
list
with
all
the
other
issues.
With
some
some
of
the
discussion
we
have,
the
good
news
is
I've.
Probably
given
you
the
impression
that
things
are
fuzzy,
but
the
good
news
is
the
protocol
is
stable.
Actually,
we
are
discussing
a
explanations
of
what
is
going
on
and
not
discussing
what
is
going
on
in
most
cases,
and
so
we
we
are.
We
are
not
changing
the
mechanics,
and
this
is
a
feedback
I
get
from
this
session
as
well.
D
So
this
is
good
news,
and
so
my
role
is
to
try
to
have
a
text
that
is
as
clear
as
possible
as
to
what's
going
on
within
shake
so
we're
going
to
address
all
the
issues
proposed
new
text
in
version
11,
so
we
kind
of
figured
that
would
be
in
three
weeks
from
now
and
and
we'll
go
for
another
round.
So
we
should
have
more
comments
if
eleven
is
not
good
enough,
we'll
wrap
it
up
again
and
if
yep
thank
you.
L
A
K
So
there's
no
way
like
I
cannot
go
and
look
at
this
thing
and
say
this
was
fixed
by
version
11.
It's
not
there
like
I'm,
because
I
did
the
query
and
there's
nothing
turned
up
right
like
so.
We
need
to
make
sure
that,
like
the
link
is
made
one
way
or
another,
even
the
tracker
way,
you
say
it's
fixed
in
this
version
or
in
in
the
draft
itself.
The
change
dog
saying
I
fix
issue,
15
yeah.
A
K
That's
fine,
like
I'm,
just
saying
like
for
people
who
are
not
in
the
meeting
to
follow
this
right,
because
the
last
call
will
be
on
the
list
and
like
if
somebody's,
not
here,
who's,
not
following
this,
like
they
need
to
somehow
correlate
these
two
things.
And
as
long
as
you
do,
that
I
don't
need
a
full
last
call
for
this.
C
I'm
feeling
it
that
enough
from
killing
I
will
present
the
Sheik
of
Ellora
one
draft
so
I'm
one
of
the
order
with
several
people.
So
that's
the
first
slide.
The
status
of
the
draft
is
that
we
set
up
a
task
force
with
the
help
of
our
chairs.
We,
who
invited
some
people
from
the
lower
islands
last
time,
so
they
did
a
good
job.
So
thank
you.
C
The
task
force
is
led
by
sente
who,
as
you
know,
might
know
that
they
are
the
inventor
of
the
Laura
and
the
leaders
of
the
Technical
Committee
of
the
Laura
Islands
protocol,
so
the
company
involved
in
in
this
in
this
work,
our
Sam,
take
a
Clio
here
with
the
value
also
activity
with
all
Perry,
again
business
here
today,
killing
with
myself
and
Vincent
with
EDF
Rd.
So
we
are
quite
a
good
group
of
people
not
knowledgeable,
but
Laura
one.
So
that's
that's
good
news.
C
So,
first
of
all,
I
want
you
to
make
a
status
about
what's
new
in
a1.
So,
first
of
all,
we
added
the
architecture
chapter,
the
summing
up,
the
out
the
lower
one
is
mapping
to
help
even
entities.
So
on
that
on
that
part,
on
that
chapter,
we
suggest
where
the
Sheik
compressive,
the
compressor
and
the
Sheik
fragmentation
should
be
performed.
So
on
the
figure
you
see,
this
is
a
typical
Laura
one
architecture
network.
C
So
the
end
devices
who
which
are
running
the
Sheik,
the
compressor,
the
compressor,
then
you
we
have
a
transparent
gateways
and
server
for
a
for
our
case
and
the
Sheik
compression.
The
compression
and
fragmentation
should
be
also
held
in
the
application
server
right
on
the
the
right
hand
side.
So
this
is
typical
Laura
one,
and
this
is
where
we
are
intending
to
put
the
Sheik
layers
on
top.
C
So
what
is
that's?
What
what
we
are
discussing
together
is
the
lower
one.
Sheik
role
are
being
defined,
so
we
are
right
now,
working
on
one
I,
PVC
qdp,
with
their
bite
will
tear
a
bit
sent
on
the
wire.
So
the
goal
here
is
to
prove
that
technology
is
really
compressing
the
payloads
all
all
the
fields
on
that
on
those
were
all
not
sent.
C
Other
rules
are
defined
for
co-op,
so
ipv6
UDP,
co-op
for
Epling
and
online
post.
The
same
thing
for
gets,
so
we
are
trying
to
describe
how
to
do
a
hand
to
and
co-op
a
connection
with
with
the
remote
server
on
the
fragmentation
part
we
also
defining
new
parameters.
So
we
have
three
types
of
fragmentation
parameters.
C
One
photo
is
for
a
blinks
which
are
different
constraints
as
for
the
darlings
and
the
daleks
has
been
separated
in
two
parts,
so
in
Laura
one
you
do
have
done
in
Class
A,
which
is
for
a
very
constrained
devices
which
are
not
listening
all
the
time,
but
only
opening
your
list
window
after
transmission.
So
the
fragmentation
here
is
must
be
adapted
for
for
such
case
and
the
don't
leak
for
Class,
B
and
C.
So
Class
B
is
for
our
devices,
which
are
listening
vertically
and
class
C's
for
a
constant
listening
devices.
C
C
C
That,
on
the
on
the
floor
on
the
monitor
end,
devices
are
the
smaller
things
which
are
running
on
the
radio
link.
So
that's
like
your
your
device
with
the
centigrade.
You
drop
your
world
HTTP
yeah
yeah.
So
actually
the
final
goal
is
to
to
have
a
conversion
between
kept
an
HTTP
at
the
end.
So
the
the
idea
in
the
air
is
to
make
the
UN
device
bus
something
to
Amazon
Web
Services,
okay,.
D
C
C
So
what
we
foresee,
as
as
a
group,
is
that
to
do
that
more
easy
fashion.
What
we
would
need
is
a
she
cruel
file
format
to
be
loaded
on
our
application
server
and
a
she
compressor.
The
compressor
that
would
mean
that
the
the
rule
could
be
could
be
provisioned
as
a
device
profile
thing,
and
that
would
make
the
all
the
application
server
defining
the
in
the
Laura
one
compatible
with
each
other,
and
then
we
we
do.
We
do
have
compatibility
and
to
answer
them.
C
H
C
A
Conceptually
we
often
have
a
proxy
of
some
form
at
the
compressor,
because
some
numbers
have
to
imagine
things
like
that,
so
the
proxy
can
be
a
very
simple
proxy,
which
you
put
the
right
members
from
the
shot
numbers
and
things
like
that.
Oh
it
could
go
other
way
to
add
HTTP
to
coop
proxy.
In
this
case,
you
would
go
all
the
way
works,
yeah.
J
B
A
If,
if
the
frame
is
fragmented,
then
we've
got
a
very
large
checksum
because
we
have,
we
are
checksumming,
did
all
the
fragments
together
and
we
also
after
the
quote,
unquote
checksum
of
lo-har
at
the
end
of
the
frame.
Now,
if,
if
the
frame
is
very
small,
it's
just
no
one
packets
feels
feels
focused
in
one
frame.
Then
the
uncheck,
some
we
get
is
the
loja
checksum
and
we
alight
the
UDP
checksum.
So
that's
couldn't
be
always
this
discussion
just
make
you
aware,
but
it's
it
did
the
case.
A
K
You
could
be
cases
where,
like
you
know,
the
UDP
port
could
get
changed
in
transit
and,
like
might
not
get
detected,
those
kind
of
things
I
think
we
need
to
do
the
same
thing,
because
I
personally
think
the
applicability
statement
we
have
today
for
UDP
zero
checksum
doesn't
apply
here,
because
that
is
like
really
meant
only
for
tunnel
endpoints.
So
you're
saying
that
we
already.
A
Have
an
exception
there,
because
if
in
6lowpan
we
already
elide
the
UDP
checksum,
because
we
claim
that
we
have
additional
make
in
the
messages
which
give
us
the
same
strength.
So
at
the
end
of
the
day,
it
just
placed
somewhere
else
and
asked
you,
but
but
this
because
we
have
the
same
strength
globally,
I
I!
Think
it's
because
it
came
before
this
issue
came
up.
No.
P
A
K
Can
talk
about
it,
offline,
I,
think
because
I
I
think
if
something
is
written
up
already
for
this,
it's
ok.
If
not,
we
need
to
write
something
up
for
it.
We
cannot
just
like
do
the
analysis
internally
and
just
leave
it,
because
we
at
some
point,
like
somebody
from
the
transport
area,
will
say
like
hey.
You
know
how's
this
gonna
work,
so
we
need
either
point
to
some
existing
document
like
well.
B
Just
honored
to
cover
it
on
this
point,
I
think
that
could
be
very
useful
input
for
ticket
15,
now
I
think
I'm
going
to
remember
this
ticket
so
take
a
15
for
technology
dependent
documents
to
write
up
that
the
authors
must
provide
must
ensure
that
the
checksum
of
the
technology
is
strong
enough
to
fulfill
this
or
provide
some
justification
about
this.
So
this
way
the
people
we.
K
Need
to
have
sufficient,
so
my
thinking
is
this,
like
the
link
area.
Technology
provides
like
checksum
for
that
hop
right.
But
if
you,
if
you're
going
past
at
hop
like
very
UDP
supposed
to
be
so
like,
we
are
trying
to
relax
if
you
can
relax
it
for
a
specific
one,
hop
thing
it's
different
than
saying,
like
I'm,
gonna,
relax
this
for
UDP
right
because
UDP
runs
over
the
Internet.
You
cannot
say
like
hey.
My
Ethernet
checksum
is
good
enough
right.
Otherwise,
people
that
are
the
original
argument.
K
My
Ethernet
checksum
is
good
enough,
but
what
happens
if,
like
in
our
router,
cut
up
something
right
so
that
so
like
we
need
to
think
from
the
perspective.
We
cannot
just
say
like
hey.
If
the
link
layer
is
good
enough,
you
can
do
it
so
that
we
need
to
be
careful.
Let's
actually
do
the
work
and
see
how
the
list.
K
H
So
again,
it's
an
early
draft,
not
much
content
so
far,
but
a
lot
of
discussions
and
testing
going
on
in
behind
the
scenes.
So
what
we're
trying
to
do
is
optimize
the
parameters
that
we
have
to
define
now
that
we
know
ticket
sitting
will
be
there
our
reference
so
basically
we're
trying
to
answer
ticket
15
even
before
it's
been
created.
H
So
what
the
draft
describes
is
a
network
picture
similar
what
was
described
before
for
Laura
the
sheep
rules
in
the
fragmentation
and,
of
course,
we're
trying
to
optimize
as
much
as
possible
because
of
the
small
payloads.
So
a
quick
reminder
also
the
generic
architecture
on
the
right
hand,
side.
We
talk
about
radio
gateways,
network
gateways,
servers
and
applications
and
the
sea
Fox
network
architecture,
because
we
have
all
the
base
stations
connected
to
the
single
cloud.
H
The
output
of
the
cloud
is
indeed
HTTP
and
and
therefore
we
have
to
adapt
differently,
so
any
chic
compression
the
compression
function
would
be
after
that.
This
cloud
and
therefore
implemented
after
the
callback
of
the
cloud
still
TBD
whether
the
cloud
will
will
provide
a
chic,
specific,
API
or
connector
or
not,
but
so
far
it's
HTTP
and
the
device
of
course
is,
is
open
so
for
the
implementer.
H
So
where
we
are
putting
attention
in
this
over
the
past
few
weeks
and
at
the
hackathon
is
on
the
optimization
of
the
rules
for
the
most
common
type
of
cfox
helpy
one
applications.
So
that
was
part
of
my
questions.
I
was
asking
the
the
rule,
IDs,
sighs
and
the
rule
ID
world,
because
we
do
want
to
optimize
and
make
sure
that
we
can
use.
The
minimum
number
of
rule
is
to
to
to
optimize
this
space.
H
As
you,
as
you
know,
and
we
talked
about-
we
have
this
12
bite
of
uplink
payload
size
that
is
variable.
I
could
be
one
bit
or
or
multiple
bytes,
but
but
variable
2
to
optimize
the
size
of
the
packet
on
the
down
on
the
down
link.
We
have
this
8
byte,
a
constant
payload
that
it's
up
like
triggered
so
pretty
much
similar
to
the
class,
a
Laura
one
mode
and
of
course
we
need
to
optimize
that
the
padding
again
to
make
sure
that
the
the
the
messages
are
consumed
as
little
energy
as
possible.
H
So
again,
this
is
post
hoc
at
all.
My
hope
is
to
start
providing
some
recommendations
for
the
next
for
the
next
version
of
the
document
specifying
those
parameters
optimizing
them
for
the
for
the
better
usage
and
its
ongoing
work.
So
if
you
are
interested
in
contributing,
please
let
us
know
so
far,
we
have
a
good
number
of
people
trying
this
out
and
trying
to
come
up
with
the
best
recommendations,
any
questions.
J
Niccolo
I'm
at
the
Ramos
I
work
in
Ericsson
and
together
with
Anna
and
shortly
we
are
starting
this
draft,
which
is
saying
that
six
fox
raff
is
basically
just
the
beginning.
We
is
a
container.
There
is
not
that
much
text
on
it,
but
then
I
wanted
to
present
just
some
of
the
issues
that
we
will
have
to
deal
with
when
we
are
working
in
this
draft.
Some
of
the
things
has
to
do
with
the
peculiarities.
J
If
we
want
to
call
it
like
that
of
neuro
variety
and
how
it's
different
with
respect
to
the
other
two
and
then
there
are
some
architectural
issues
that
I
have
called.
One
of
them
is
the
different
transmission
modes.
So
basically
in
narbonne
IOT
you
could
have
different
ways
of
transmitting
data
depending
of
the
state
that
the
terminal
is,
if
he's
in
a
connected
state,
or
is
it
just
starting
the
transmission
or
it
has
been
connected,
but
then
it
went
to
to
power
saving
mode.
J
Then
we
have
also
also
depends
of
the
configuration
of
the
operator
so
how
the
operator
managed
that
terminal.
So
remember
that
narrow,
an
IOT
so
far
is
over
licensed
spectrum.
So
the
operator
has
a
lot
of
even
legal
responsibility
over
how
it
is
handled
those
connections.
The
bidder
handling
has
to
do
pretty
much
with
the
same
of
the
transmission
mode,
since
they
are
different
in
transmission
mode.
The
UE
might
I
mean
the
equipment
might
go
from
one
mode
to
another,
and
so
that
is
more
effective
depending
of
the
let's
say
the
buffer
size.
J
J
The
other
thing
that
Nirvana
UT
is
quite
strong
or
is
one
of
the
strengths.
Is
the
mobility
and
in
here
I'm
not
only
talking
about
mobility
in
one
network,
but
also
you
have
to
think
about
mobility
from
roaming,
so
when
you
II
suddenly
wake
up's
in
another
country
and
it
has
to
attach
and
have
data
to
send.
This
is,
for
example,
a
use
case
for
containers
which
might
have
sensors
and
are
traveling
in
the
sea
or
by
plane.
And
finally,
there
is
a
possibility
that
we
could
also
include
cases
for
LTM.
J
That
has
been
specified
very
recently,
it's
a
type
of
terminal
for
LTE,
which
is
also
a
target
in
a
machine
type
communication
and
then
also
5e
n
R.
So
the
new
radio
m
TC,
which
there
is
not
so
much
yet,
but
it's
starting
some
work
already
of
what
would
be
used
for
for
machine
tech
communication,
then
the
idea
well.
This
is
about
a
little
bit
more
detail
about
the
transmission
mode.
J
If
anyone
is
interested-
and
you
could
say
that
they
are
this
kind
of
these
two
type
of
transmission-
the
data
on
us
and
they
under
connected
mode
and
the
difference-
is
that
the
way
how
the
lower
layers
protocols
works
in,
for
example,
in
data
when
asked
they
are
very,
very
much
deactivated.
So
there
is
where
cheek
could
work
pretty
much
with
all
the
features
so
that
you
could
have
fragmentation
that
you
could
have.
J
J
Basically,
even
when
you
have
PDC
P&R
LC
LC
is
it's
a
layered
layer?
Well,
we
don't
say
that
it's
layer
2,
but
something
between
layer,
2
and
layer,
3
protocol
that
that
could
handle
reliability.
So
you
could
configure
it
to
be
reliable
or
not
for
narrowband
yo
T
now
in
release
15
they
are
including
non
reliability
because
it
was
for
release.
13
and
14
was
only
used
reliable.
So,
but
now
there
are
some
cases
like
streaming
where
you
might
not
need
to
have
acknowledged
it.
J
So
then
there
are
now
for
at
least
15
bringing
it
on.
Then
you
have
mock
which
have
a
hard
protocol,
so
it
means
that
you
have
automatic
retransmissions
and
that
is
configured
by
the
operator.
How
many
retransmissions
want
to
have,
and
even
when
there
is
some
sort
of
reliability
depending
of
the
channel
quality,
so
those
packets
be
lost
and
then
basically,
you
have
to
two
layers
of
rail
ability
in
the
connected
mode,
which
is,
which
is
what
you
have
here
so
here.
J
These
two
provides
reliability
and
also
RLC
provides
fragmentation
or
segmentation,
as
we
call
it
in.
So
that
means
that,
in
the
connected
mode,
the
fragmentation
wouldn't
be
needed
now,
because
they
this
architecture,
it
means
that
you
would
have
to
have
for
each
of
the
of
the
modes,
different
placement
for
the
compressor
and
the
compressor.
So
basically,
you
would
have
one
compressor
that
works
for
connected
mode
in
PD,
CP
level
here
and
then
for
the
data
Barnard's.
J
You
will
have
it
basically
here,
so
these
are
things
that
we
need
to
consider
and
then
again
how
you
switch
from
one
mode.
So
you
are
transmitted
in
this
mode
and
then
you
get
upgraded.
Let's
say
like
that:
the
connected
mode,
then
what
happened?
How
that
transition
is
this
tone
is
something
that
we
have
to
think
as
well.
J
Additionally
to
that.
Well,
there
is
basically
ticket
15
that
I
copy/paste
some
of
the
parameters
that
were
already
there,
which
we
have
to
take
care
and
the
padding
treatment.
We
also
have
padding
treatment
in
layer
2
for
the
connected
mode,
which
means
that
maybe
we
don't
even
want
to
have
padding
at
all
for
for
shake
I
mean
the
padding
will
be
handled
by
the
lower
layers
and
then
this
thing
of
the
rule
ID.
So
what
happened?
J
If
there
is
no
fragmentation
or
there
is
no
compression,
and
then
is
it
really
adding
then
overhead
and
how
you
handle?
That
I
think
it's
very
important
to
have
this
possibility
that
it
can
be
variable
or
it
can
be
defined
in
some
way,
how
the
role
ID
size
or
how
it
is
a
mark.
So
it
can
be
that
if
I
start
with
1,
then
you
have
to
read
something
else.
If
you
start
with
0,
then
you
know
there
is
no
compression,
but
well
that's
something
to
look
at.
Q
H
Well,
I'll
ask
both
at
the
same
time
and
for
the
connected
mode.
Well,
I
assume
this
yacht
covers
both
LTE
m
and
then
VI,
yo,
T,
okay,
so
and
then
the
question
is
for
the
connected
mode.
Are
you
plan?
Is
the
idea
to
have
some
IP
in
IP
or
over
the
eyepiece
completely
independent,
or
how
do
you
match
that
yeah.
J
That's
a
good
question
because
of
course,
if
we
do
this
in
in,
let's
say
P
DCP,
this
means
that
it
has
to
be
standardized
in
3gpp
and
then
in
that
case
you
would
use
the
IP
of
the
terminal,
which
is
the
one
that
is
given
by
by
the
target
gateway
right.
If
not,
then
we
have
to
think
if
it's
possible
to
use
it
in
other
way,
but
I'm
not
sure
at
this
point.
I
cannot
really
look
at
answer.
Okay,
thank
you
very.
E
E
Handmade
in
this
version,
we
have
built
a
new
verse,
okay,
since
I'm
at
the
beginning.
Okay,
we
started
with
this
variable
length,
okay
and
then
we're
told
we
should
keep
their
rule
ideas
a
whole
thing.
Then
we
can
go
back
now
today
to
the
length
with
us
already
sure
the
shorten,
depending
on
the
number
and
then
since
we
are,
we
were
implementing
for
for
the
icmpv6
on
Laura
and
okay.
E
E
D
D
So
what
did
we
do
since
I
Jeff
100?
We
have
not
advanced
a
draft
at
all
due
to
lack
of
time
and
time
you
spend
on
other
things,
but
we
did
prototype
ping
proxy
on
the
server
side.
So
we
added
a
more
recently
where
we
should
could
ping
lp1
device
from
the
outside
and
have
the
proxy
respond
on
behalf
of
the
device
and
we
chose
to
implement
as
time
threshold.
If
the
device
has
been
seen
for
the
last
10
minutes,
the
proxy
will
respond
with
an
echo
reply.
D
D
N
Maybe
please
it's
not
about
this
draft
I
wanted
to
just
announce
that
the
anatra
Plato
through
wireless.
There
is
now
an
LP
WI
group.
It's
been
approved
and
we've
sent
out
some
project
goals
for
the
group,
and
one
of
them
is
to
have
a
header
compression
draft
for
the
freighter
2.15
on
4
depending,
but
it
could
depend
on
various
of
things,
but
I
just
would
invite
any
if
anybody
here
is
interested
in
joining
that
effort.
We're
definitely
interested
I
presented
about
a
CIC
at
the
recent
meeting
of
802
Wireless,
and
there
was
interest
in
that.
K
Description
so
just
to
dominate
so
you
said
no
48
61,
but
that's
a
legal
type
in
44
43,
so
you're
gonna
just
go
for
a
smaller
subset
of
types
that
you
want
to
compress.
Is
that
the
goal,
because
I
I
didn't
understand
that
statement
right,
like
the
the
nd
messages,
are
legalizing
view
messages
right
right.
D
D
D
Yeah,
if
you
remember
last
meeting
we
disrupt,
is
also
about
use
cases.
Why
do
we
need
that?
But
what
situations
are
we
looking
at
and
and
not
just
compressing
things
and
sending
them
all
over
the
wire,
but
what
kind
of
X
behavior
do
we
expect?
If
requests
come
from
the
internet
to
the
device,
shall
we
transfer
that
device
or
respond
as
a
proxy,
and
so
the
draft
is
discussing
all
those
situations
more
than
providing
compression
and
diego's
draft
provides
the
compression
details.
Okay,.
K
K
This
IOT
stuff,
so
one
of
the
things
was
I,
started
writing
up,
something
which
said
like.
If
you
are
on
a
cellular
link
somewhere
and
the
device
is
on
a
sleep
cycle
right,
you
would
send
a
different
ICMP
message
back
than
the
regular
ICMP
messages,
so
so
I
I
would
really
like
to
see
like
instead
of
saying,
only
44:43,
to
have
like
a
listed
set
of
like
ICMP
types
that
we
want
to
compress
and
do
each
one
separately.
A
B
Too
many
slides
today,
you
know
the
batteries
are
out
so
I'm
going
to
do
this
in
two
three
minutes,
but
it's
super
important
to
prepare
for
what
is
going
to
come,
and
this
is
data
models
for
shake.
So
basically,
how
do
we
do
the?
How
that's
an
issue
that
will
a
question
that
we
need
to
answer
here
at
some
point,
and
this
point
is
coming
very
very
rapidly.
So
that's
kind
X
I,
please!
B
B
So
today
what
we
have
is
we
have
some
ad
hoc
JavaScript,
sorry,
ad
hoc,
Jason
description,
something
like
this.
That
works
pretty
well,
but
the
thing
is,
you
know
that
we
will
need
to
go
a
step
further
and
should
it
formalize
this
thing
next
step
next
yeah.
So
today
what
we
are
doing
is
we're.
We
have
the
device
and
on
the
other
side,
you
know
the
thing
that
here
is
called
client.
B
So
we
have
the
context
that
today
are
provisioned,
and
this
way
it
works
next
slide
and
today
days
are
provisioned,
and
what
we'll
need
to
have
is
the
way
to
do
the
to
do
to
enable
discovery
of
how
the
client
or
the
device
you
know
is
going
that
the
client
at
least,
is
going
to
discover
what
the
device
is
is
able
to
support.
And
what
is
what
are
the
contexts
on?
It
also
be
able
to
do
runtime
modifications
or
minor
modifications.
B
B
So
one
point:
one
possibility
is
to
go
with
the
egg,
and
here
I'm
really
sorry
Pascal,
but
I
try
to
have
animation
so
we'll
need
to
press
a
couple
of
times.
So
we
have
Netcom
go
ahead,
go
ahead:
internet
conf!
We
have
this
and
in
any
restaurant
and
income
I.
So
if
we
have
the
yang
module
the
young
model,
then
you
have
the
representation.
They
have
the
expression
of
XML
in
JSON
and
in
Seaborg
how
you're
going
to
be
able
to
express
the
context.
So
you
have
one
ski.
B
We
have
one
schema
that
for
the
for
the
context
and
we
have
all
these
representations
and
protocol
bindings.
So
there
is
already
a
solution,
Yampa
and
comma,
and
it
works
really
well
and
we
are
not
going
to
start
from
from
scratch.
So
there
has
already
been
a
submission.
I
think
it
could
be
a
good
starting
point,
and
this
is
something
to
to
to
look
at.
B
It
is
not
the
only
way
to
do
it
and
that's
the
thing
for
us
to
study
as
a
working
group
to
decide
pretty
rapidly.
So
we
have
a
starting
point.
We
have
something
that
could
work
really
well
and
the
alternatives
are
basically,
we
can
go
with
raw
JSON
as
it
is
for
the
moment
they
say
well
now.
This
is
the
structure
that
we
expect
to
be,
and
that's
it.
We
can
do
it
with
C
bar.
B
We
can
imagine
some
binary
encoding,
we
can
use
CDL
to
the
validation
and
so
forth,
and
we
can
also
go
the
road
of
defining
our
protocol
on
the
on
the
sheik
level
to
say
all
the
resulting
exchanges,
and
this
way
you
know
we
put
some
configuration
and
so
forth.
So
these
are
alternatives,
but
the
point
here
is
that
we'll
need
this
document
and
right
now,
when
we're
nearing
up
the
the
finalizing
of
schick,
then
it
is
the
time
to
to
look
at
this.
So
that
will
be
the
next
point.
B
G
C
Q
A
B
Think
we
will
need
to
have
some
mech
so
that
that's
that's
an
all.
These
are
open
questions
right,
I
think
that
we'll
need
to
have
some
protocol
or
something
that
is
able
to
that.
We
are
able
to
configure
some
values
of
the
of
the
ship
context,
so
not
provision
the
whole
context.
So,
let's
be
able
to
do
find
configurations
like
okay,
I
have
the
hook.
I
have
the
context
with
some
rules
and
some
of
the
rules
I
have
a
value
that
I
want
to
configure
for
this
device.
I
need
to
tell
this
device.
So
let's.
Q
Q
B
P
Erika
Anna
Erikson
on
the
options
for
different
formats.
Please
not
let
let's
not
invent
new
ones,
so
definitely
use
one
of
tech,
since
it
was
seaboard,
probably
which
starting
point
and
as
you
mentioned
on
the
fetching
and
patching
part,
you
know
this
want
to
be
interesting.
Work
done
in
core
also,
so,
let's
see
what
are
the
synergies
there?
What?
How
can
we
use
the
mechanisms
that
we
are
using
as
well?
That
should
be
perfect.
Thank
you
very
much.
B
Re
and
so
we're
getting
into
in
the
last
part
of
this
talking
I'll
try
to
do
really
really
quick
on
this
one.
So
we're,
as
you
see,
we're
nearing
up
the
thicket
of
fulfillment
and
the
completion
of
our
initial
charter
items,
or
we
might
have
some
of
them.
So
next
slide.
Please,
and
so
these
are
our
two
main
charter
items
that
we
have
today,
the
first
one
that
is
the
LP
one
overview
is
fulfilling
it
and
the
second
charter
item
that
we
are.
That
is
actually
we.
B
We
took
really
a
lot
of
time
with
with
Pascal
and
and
we
look
deep
down
in
it
in
the
state
where
we
are,
and
we
actually
identified
that
we
were
a
little
bit
ambitious
when
we
specified
it.
So
the
shake
over
IP
shake
for
UDP
IP
document
is
fulfilling
the
part
that
is
in
green,
but
then
we
have
still
the
chic
for
co-op.
So
we
would
like
to
make
this
a
new
work
item.
B
So
in
the
in
the
future
we
chartering
and
then
we
have
a
new
work
item
that
is
to
include
the
definition
of
the
data
models.
So
the
data
models
are
things
that
that
I
just
talked
about,
so
these
will
be
two
separate
work
items
and
we'll
have
a
third
one,
which
is
the
technology
specific
documents
for
which
we
talked
about
today,
the
Laurel
and
the
Sig
Fox,
the
NDI
ot
and
the
future
Wyson.
B
So
these
will
be
three
charter
items,
so
here
we
have
a
proposed
text
that
is
basically
reflecting
getting
the
previous
text
striking
out
the
things
that
were
done
and
just
splitting
this
in
these
three
work
items.
So
these
things
would
be
sent
over
the
mailing
list
also
so
that
we
can
take
a
rhythm
that
I'd
like
to
take
a
new
reading
of
them.
If
in
case,
you
have
any
any
comment
about
this,
so
that
would
be
this.
A
Well,
stay
instinct
here,
you
know:
we've
got
this
work
that
Dominique
and
Diego,
which
is
just
present
it
right
now
on
which
we
are
looking.
If
we
could
derive
an
actual
work
item
which
would
make
sense-
and
that
was
that's
what
I
discussed
earlier.
We
don't
want
to
make
an
exercise
of
trying
to
compress
ICMP
as
a
whole.
A
We
want
to
have
a
real
use
case
and
a
real
operation
which
is
useful
for
the
network,
and
we
considered
that
OAM
is
actually
an
important
function
for
the
network
being
able
to
to
go
to
the
device
or
go
near
the
device
and
check
the
network
condition
without
device
a
life
without
network
the
life
what's
going
on,
and
so
we
figure
that
actually
the
work
item
behind
the
work
which
was
done
by
Diego
and
Dominic,
was
REO
a.m.
and
some
to
be
defined
exactly
what
what
I
do,
but
taking
ping
as
a
reference.
A
And
so
that's
what
we
wanted
to
turn
into
a
new
work
item.
So
that
would
be
the
only
new
work
actually
in
the
Charter.
So
we
would
take
we
complete,
as
we
said,
the
ap1
overview.
We
will
have
completed
the
shake
and
around
that.
I
would
like
to
be
able
to
to
have
a
chartered
item
around
the
work
which
is
done
on
I.
Am
that's
pretty
much
for
you
squash.
K
K
Because
I
want
to
like
one
of
the
things
that's
happening
is
like
the
tele
chats
have
getting
like
really
really
full,
so
we
have
like
thousand-page
Stella,
chat
and
stuff,
and
it's
very
difficult.
So
I
would
really
like
some
heads-up
on
when
you
expect
things
to
get
to
me
right,
and
so,
if
you
update
the
milestones
on
at
least
the
coop,
because
I
have
like
no
clue
how
far
off
it
is
like
UDP,
IP
IP
is
pretty
close,
but
co-op
I
have
no
clue
like
how
far
out
it
is
so.
B
Okay,
so
we'll
do
this
and
we
got
the
message
that
we
need
to
finish
the
the
we
need
to
deliver
the
check
for
IP
UDP
before
we
do
any
recharging.
So
that's
really
important
for
us
to
to
finish
this
for
this
work
in
time
and
that's
the
first
point
on
a
sheik
overcoat
for
co-op.
Basically,
there
have
been
no
advancement
because
we
need
like
a
co-op,
assist
you
think
thing
so
either
we
will
make
such
a
very
generic
compressor
that
will
be
complex
and
maybe
to
just
to
taking
too
much
power
and
and
so
forth.