►
From YouTube: IETF104-LPWAN-20190326-1610
Description
LPWAN meeting session at IETF104
2019/03/26 1610
https://datatracker.ietf.org/meeting/104/proceedings/
B
This
is
the
Mount.
Well,
you
should
have
read
it
and
if
you
have
not
please
to
read
it,
so
you
have
all
the
nice
things
that
are
there
about
what.
So.
This
is
an
ITF
participation
and
and
everything
that
you
say
here
it
is
going
to
be
considered
an
ITF
contribution
and
what
is
all
the
ITF
contributions?
B
Please
do
don't
forget
to
write
the
blue
sheets
to
write
your
name
on
the
blue
sheets,
so
you
have
the
the
minutes
are
taken
on
the
ether
pads,
so
we
have
the
inner
pad
link
that
is
here
on
this
on
the
presentation
on
the
materials,
so
we
can
find
it
through
the
website
of
the
ITF.
If
you
go
to
the
to
the
agenda
and
meeting
materials,
you
can
find
this
one
there
and
yeah.
Please
do
contribute
to
the
to
the
minutes.
B
B
Okay?
Thank
you
very
much.
Eric
Eric
is
going
to
be
doing
the
Java,
scrapping
and
just
automating
materials
on
the
data
tracker,
all
sloughed.
All
things
are
out
there.
So
my
dear
check,
my
dear
co-chair
Pascal,
has
this
very
good
way
of
showing
how
to
go
and
get
these
things.
So
we'll
see
this
feature
for
our
agenda.
For
today
we
have
a
very
tight
agenda.
Actually
so
we
have
a
lot
of
items,
and
so
we
start
with
the
agendas
here
choose
from
it
was
published.
B
We
have
further
the
main
topic
or
one
of
the
one
of
the
main
topics
that
we
have
until
now.
It
is
the
shape
our
compression,
and
then
we
have
6
or
1
and
and
other
different
technology
drafts,
and
one
really
important
point
is
that
we
add
gender.
The
term
is
word.
We
have
five
minutes,
so
we're
probably
not
going
to
be
having
a
lot
of
discussion
said
yet
so
do
you
have
any
modifications
in
agenda
bashing
at
that
time?
B
No,
so
we
just
continue
with
our
general
overview,
what
happens
in
the
in
the
past
in
the
past
year
or
so
so
we
finished
our
tonight
item
number
one
and
Chat
Chat
for
our
item
number
two
with
it
finished
it
was
submitted
to
the
draft
for
publication.
So
we
are
really
well
danced
and
tried
right
now,
we're
also
in
which
are
Turing
and
we'll
be
talking
about
this
identity
at
the
end
of
the
agenda
this
slot.
B
So
if
you
want
to
see
another
view
of
what
what
has
been
happening
since
our
creation,
we
have
been
very,
very
active.
A
lot
of
so
regular
hackathons
with
regular
results
and
Dominic
is
monitoring
us
about
this
thing.
We
have
again
six
interim
meetings
since
our
last
ITF,
so
really
a
very
good
place
that
if
you
would
like
to
participate,
it's
really
open.
Please
do
the
join.
A
lot
of
work
is
going
is
happening
over
there.
So
this
is,
of
course,
the
the
good.
B
The
good
points
that
we
had
working
with
was
called
up
finished
with
success.
So
that's
so
many
congratulations
and
to
to
the
whole
team
and
congratulations
to
you
to
everyone
that
really
put
a
lot
of
heart
into
doing
this
and
cook,
and
thanks
a
lot
to
every
one
of
the
reviewers
that
did
a
lot
of
very
serious
work
there.
C
C
So
this
draft
is
free,
free
things
in
one
its
specification
of
a
generate
header
compression
engine.
It's
the
specification
of
a
fragmentation
protocol
and
it's
a
specification
of
how
you
apply
the
compression
to
UDP
ipv6.
So
it's
really
free
topics
that
are
related,
but
that
could
potentially
have
gone
into
separate,
but
for
some
reason
we
deliver
them
all
free
in
the
same
document.
C
C
C
One
of
the
decisions
that
we
made
during
the
fall
was
to
make
the
fragmentation
make
optional
again.
This
had
been
a
long
going
discussion,
so
the
the
new
the
text
as
it
is
now
says,
integrity
checking
is
mandatory
when
you
do
fragmentation
and
make
is
one
way
of
doing
it.
But
if
you
have
a
known
better
way
of
doing
it,
then
you
don't
have
to
have
a
midship.
This
was
a
strong
request
by
some
of
the
contributors.
C
As
a
result,
ticket
number
42,
which
captured
that
question
already
a
couple
years
ago,
has
been
updated
with
the
recent
discussion
and
decision.
So
we
can
point
is
at
that
text
to
understand
why
we
decided
that
and
why
wishing
it's
safe,
because
that
critical
issue
and
then
we
rewrote
the
text,
this
fall
based
on
Charlie's
review.
Thank
you
very
much
Charlie
for
all
the
time
you
spent
you
invested
into
making
our
text
better.
You
know
you
a
big
thank
you
for
that.
C
There
was
one
issue
that
naturally
raised,
which
was
a
interoperability
and
the
description
of
the
rules
and
the
details
of
the
rules,
and
we
decided
we
knowingly.
We
decided
that
it
will
stay
rather
vague
in
this
document,
because
we
have
another
draft
coming
and
Rohr
is
going
to
talk
about
it,
and
that
will
describe
that.
Precisely
so.
C
Eventually
we
published
revision
18
and
submitted
to
a
ESG
for
publication,
a
standard
track
RFC
in
December
15,
and
since
then
we
recently
got
an
early
review
by
a
costume,
which
is
only
partial,
a
partial
review,
the
iot
directorate,
and
we
have
already
worked
on
that
and
then
we
had
this
hack
around
last
weekend,
and
so
there
were
nine
team
members.
Some
of
them
not
exactly
all
are
on
the
picture.
C
Three
new
attendees
to
any
form
of
ITF
event
rocket.
We
worked
on
a
open
source
implementation
of
shake,
the
URL
is
shown
on
slide
and
what
we
done.
What
we
did
during
this
weekend
was
to
fall.
One
was
making
the
the
code
easier
to
use
easier
for
newcomer
to
understand
to
grasp
where
what
the
code
is,
what
it
does,
how
to
run
it.
So
we
produce
documentation,
we
added
tests
etc,
and,
on
the
other
hand,
we
also
improved
functionalities.
C
C
C
E
B
F
Well,
the
the
big
change
is
that
a
long
discussion
about
having
these
specifications
not
available
now
they
are
and
it's
a
public
site,
so
I
included
the
link,
but
basically
it's
a
it's.
A
link
that
gives
support
to
to
developers
that
want
to
play,
understand
the
technology
and
then
look
at
all
the
details
of
the
radio
specification.
Now
it's
available
and
it's
included
in
the
indie
draft.
F
So
then
we
can
easily
map
the
sizes
types
of
frames
and
so
on
to
the
to
the
data
sizes
and
payloads
that
we
define
in
in
cheek
and
understand
better
how
to
make
it
work.
So
I
guess
on
the
interest
of
time
one
one
slide
that
I
don't
have
is
we
would
like
to
call
for
adoption
probably
of
the
technology
documents.
This
is
the
time
to
do
it.
So
far
we
have
see
Fox
and
B
IOT
and
Laura.
Of
course
they
are
in
the
works.
A
So
it
is,
and
at
the
end
of
this
meeting
will
be
talking
about
the
reach
out,
drink
and
and
well.
The
discussion
and
those
documents
was
already
present
original
shutters
I
guess
we
could
adopt
that
in
these
documents
as
part
of
the
original
charter,
but
ideally
that
would
be
done
with
the
Richard
ring
and
also,
ideally,
these
documents
would
inherit
from
the
data
model
document
and
be
more
specific.
You
know
for
this
technology,
how
you
you
adapt
to
data
model.
That
also
is
not
chartered
so
long
as
that
other
document
is
not
charted.
B
So
actually,
I'm
really
also
very
happy
to
see
that
there
was
this,
the
specification
that
was
that
was
published.
So
that's
really
really
good,
and
did
you
approve
all
because
I
I
skimmed
through
it-
and
there
are
some-
you
know
some
details
about
different
payload
sizes
and
so
forth.
So
this
is
right
now
also
in
the
in
the
industry,
Fox
document
I.
F
Change
the
reference
I
make
the
public
reference
actually
link
to
to
the
specification.
G
About
Cisco,
what
is
the
meaning
of
now
public,
because
if
you
read
the
the
specs,
the
specs
is
available
on
the
IP.
I
still
belongs
to
six
folks,
so
we
can't
use
it.
Sorry,
could
you
repeat
the
question,
the
the
the
things
that
if
you
read
the
radio
specification
that
is
now
public,
there
is
a
disclaimer
that
said
that
the
IP
are
still
apply,
so
we
can't
do
anything
with
the
spec,
because
the
IP
air
is
not
open.
Well,
we.
F
F
A
F
B
A
H
B
I
So
since
the
last
version
we
had
review
from
she,
which
was
giving
70
times
that
we
need
to
specify
and
some
additional
information.
So
thanks
showing
she-
and
this
led
to
the
publication
of
version
number
three,
and
we
also
got
a
lot
of
new
ideas
and
texts
from
other
people
from
the
Elora
Alliance,
namely
Olivier,
eminence
and
Mark,
blue,
correct
and
sorry.
If
I'm
not
pronouncing
it
correctly,
and
no,
those
new
text
will
be
participating
in
the
next
version
to
come,
namely
version
4.
I
D
D
I
I
There
were
some
of
some
questions
how
we
go
out
of
some
bad
state.
Basically,
if
the
network
is
down
for
a
couple
of
days,
which
is
mostly
a
theoretical
question,
but
in
what
could
happen
so
after
some
discussions
with
the
ship
dry,
chic
routers,
we
got
so
responses
that
were
satisfactory,
so
that
that
would
be
maybe
just
not
in
the
draft
and.
I
I
Okay
doesn't
seem
that
there
are
people
having
I
think
on
this
right
now,
okay,
so
what
is
remaining
is
definition
of
iid
and
checking
again
that
there
is
nothing
remaining
to
be
defined
and
that
all
the
parameters
of
the
ship
draft
are
still
covered
in
the
new
version
of
the
draft,
and
with
that
we
would
like
to
ask
you
after
before
is
published.
Please
please,
review
the
draft,
give
us
any
comments
and
yeah
I
said
the
Co
for
adoption
will
be
a
little
bit
later.
A
I
A
J
J
J
This
is
already
defined
for
rock
in
the
PDC
player
in
the
tree
G
network,
where
there
are
sea
and
the
RLC
can
choose
the
best
channel
to
send
the
compression.
So
here
we
have
all
the
information
about
the
IP
packet
and
we
can
make
compression
between
the
device
and
not
B,
so
for
this
kind
of
transmission.
J
We
think
that
without
really
need
fragmentation,
because
the
aral
sea
layer
makes
segmentation
and
reassembly,
but
there
is
an
RC
mode
of
transmission,
that
trans
transparent
mode,
where
there
is
no
segmentation
and
perhaps
there
we
can
use
firming,
no
akyuu
fragmentation,
but
this
is
also
we
will
need
to
see
how
it
work,
who
really
works
in
the
Trinity
for
the
role
ID
in
this
kind
of
just
case.
There
is
no
problem,
because
here
we
have
a
PD
you
of
one
thousand
three
hundred
bytes.
J
So
there
is
not
really
a
problem
about
which
size
of
variety
we
need
the
next
just
case
we
we
put.
It
is
how
to
send
a
IP
packet
in
the
control
plane,
and
here
I
don't
have
I,
don't
really
have
the
management
of
the
3G
network
I'm
in
the
control
plane.
So
it's
like
I'm
sending
an
SMS,
an
SMS
message,
so
I
have
between
eleven
and
twenty
five
bytes.
J
We
can
use
a
variety
of
two
bits
we
need.
We
need
fragmentation
and
we
can.
We
can
make
this
Sheik
compression
fragmentation
between
the
user
equipment
and
the
router
router,
so
we
can
also
send
IP
unknown
IP
data.
They
call
non
IP
data,
the
coop
massage
for
management
in
the
network.
So
co-op
message
has
no
an
IP
header.
J
There
are
only
co-op,
so
we
can
use
Sheik
for
co-op
only
and
we
can
also
use
chick
for
IP
UDP,
packets
data,
packets
and
the
third
user
case
we
define
is
how
to
use
sheik
beyond
this
network
as
a
tuna,
so
I
make
the
compression
and
fragmentation
in
the
device
and
I
transfer
these
packets
until
the
end
the
application
server.
So
that
then
the
3gpp
network
is
blind.
I
only
transfer
the
data
and
and
I
use
the
SCF
router.
That
makes
an
IP
tunnel
in
between
the
device,
the
application
server.
J
And
here,
of
course,
the
question
is
about
fragmentation.
We
are
not
sure
we
really
need
it
because
he
said
to
null
so
with
the
bad
way
is
not
so
small.
So
we
need
to
see
that
for
rule
I
decides
again,
we
don't
have
any
problem
about
which,
if
we
use
one
by
two
backs,
it
doesn't
care.
So
that's
what
we
have
defined
in
this
version
and
again
we
want
to
know
if
we
accept.
A
A
L
You
so
I'm
going
to
talk
about
the
data
model,
so
it's
something
we
we
started
to
work
at
the
beginning
of
the
Schick
group,
but
in
fact
we
focus
more
on
the
compression
and
fragmentation.
So
now
it's
time
to
go
back
to
that.
In
fact,
when
you
read
a
document
about
compression,
when
we
describe
the
rule
it's
in
a
very
abstract
way,
we
didn't
try
to
put
Jesus
on,
or
things
like
this
to
influence
implementer.
L
We
we
just
wanted
to
define
what
we
have
in
a
rule
and
now
it's
time
to
have
something
that
is
more
formal
to
cover
what
we
will
have
in
all
the
documents
that
the
group
produce.
So
it's
compression
of
IP
UDP
on
coop
on
also
over
groups
that
may
use
shake
unstoned
error
or
non-standard.
So
we
have
to
add
maybe
new
field
ID
new
matching
operator
or
new
city.
So
we
have
to
see
to
have
a
very
flexible
model
for
that
and,
of
course,
that
guarantee
vinter
parity
when
we
exchange
words.
L
So
here
it's
an
attempt
to
do
this
on
by
using
coop
young
sorry,
uncork,
I'm,
sorry
I
didn't
write
it
correctly.
So
I
have
to
learn
more
about
programs
and
what
is
important
when
we
define
this
model
is
that
in
fact
we
will
use
cough
cough.
You
will
use
Sieber
so
to
see
how
we
can
have
the
more
compact
representation
of
the
information,
because
maybe
it
can
goes
to
the
constraint
link
or
we
have
to
store
a
lot
of
rows.
L
So
if
we
go
back
to
to
the
rule
as
it
is
defined
right
now,
so
adjust
the
table
and
ASCII
table
but
say
that
we
we
have
your
IDs
and
for
each
or
ID
we
have
a
list
of
entries
with
an
3
contained,
fill
ID,
so
fill
ID
is
a
unique
value
that
is
used
to
do
the
matching
between
the
rule
and
a
passer
that
will
analyze
a
packet.
So
the
fill
ID
asked
to
be
unit
in
some
implementation
like
open
chick.
L
We
are,
for
example,
ipv6
dot
version
but
say
that
it's,
the
film
version
filled
for
ipv6.
Of
course,
it's
quite
long
value,
so
we
have
to
find
a
way
to
reduce
it.
After
that
we
have
a
length
and
the
length
can
be
the
size
of
the
field
in
bit.
Bits
or
it
can
be
also
function,
for
example,
we
defined
variable
but
say
that
we
don't
know
when
we
create
the
rule.
L
What
will
be
the
size
of
this
field,
and
so
we
have
to
send
the
value
on
the
residue
to
be
sure
that
the
receiver
will
understand
the
same
size.
So
we
are,
can
have
some
function
and
some
number
feed
position.
Fp
is
just
an
integer
because
by
Cooper
in
coop
you
can
repeat
several
times
the
same
field,
so
we
say
the
first
time
is
one,
and
if
it's
repeated
second
ex-director,
we
have
the
direction
that
is
up
done
or
bidirectional.
L
We
have
a
target
value,
so
a
target
value
can
be
a
number
or
bitmap
can
be
a
string
or
can
be
also
because
we
have
the
matching
operator
matching
a
match,
mapping
operator
and
it
can
be
also
an
array
of
values,
an
array
of
value.
So
we
have
this
different
kind
of
things
on
then
we
have
the
matching
operator
and
the
compression
the
compression
action,
but
our
functions
currently
understand
as
a
matching
operator
can
take
an
argument.
L
For
example,
MSB
came:
a
significant
bill,
can
take
an
argument
that
say
the
size
of
a
bit
on
CD.
A
currently
has
no
argument,
but
maybe
in
the
future
we
can
have
our
CD
a
with
arguments,
so
we
have
to
to
put
that
in
a
model,
and
something
also
that
is
important
is
that
the
rule
ID
is
composed
of
the
value
under
length.
So
in
theory,
when
we
are
sending
things
with
sheik,
a
most
common
rule
can
have
a
shorter
representation
van
la
less
common
words.
L
So
we
have
all
this
thing
and
of
course,
fragmentation
and
raishin
are
in
a
same
space.
So
it's
what
we
define
in
in
the
stander.
So
now,
why
can
we
can
represent
it
in
annyeong?
So
here
we
have
the
young
tree.
So
here
it's
for
a
device.
So
we
have
the
chic
context.
The
context
is
defined
by
your
list
of
rules.
L
It's
Rudy
is
defined
by
rule
or
idea
and
a
ready
length,
but
if,
for
example,
you
align
your
variety
on
the
left
side
left,
then
your
ID
can
be
an
index
to
find
the
rule
in
when
you
are
looking
for
it.
When
you
have
the
role
ID
defined,
then
you
have
to
kind
of
rule
the
rule
for
fragmentation
on
the
rule
for
compression.
So
here
in
this
model,
I
didn't
put
any
value
for
fragmentation
because
it
was
big.
The
size
was
more
on
compression
but,
for
example,
in
open
Sheik.
L
We
have
already
defined
some
value
1.
We
can
store
them
in
in
this
model
and
for
compression.
So
here
again
we
are
going
to
define
a
list
of
fills
on
three
and
each
vision
tree
will
be
if
I
will
contain
all
the
value
I
explained
before
the
only
difference
is,
for
example,
saws
a
target
value,
in
fact
the
target
value.
Since
it
can
be
a
matching
list,
then
we
can
have
several
trees
and
vision.
Tree
will
be
indexed
by
their
position.
So
this
give.
L
L
So
here
I
took
a
large
number,
but
not
large
enough,
so
income
fees
will
be
encouraged
just
before
it
will
be
a
larger
number
that
will
be
that
will
be
assigned,
but
here
we
have
all
those
all
the
value
beyond
trees,
but
are
here
in
the
alphabetical
order.
So
if
we
have
a
graphical
representation
of
this,
this
is
a
way
we
can
represent
the
rule.
L
So,
for
example,
rule
ID
value
a
value
will
be
eighty
thousand
fifty
eight
extra
extra,
and
so
each
field
will
have
a
specific
and
seed
number
and
in
a
first
attempt,
what
we
have
to
do
when
we
want
to
describe
a
rule,
is
just
to
put
for
all
these
fields
a
value,
for
example,
if
I
want
to
put
ipv6
at
their
lambs.
So
in
a
first
approach
we
can
put
ipv6
at
all
ends
here,
but
it
will
not
be
very
efficient.
Then
we
put
the
lens
eight.
We
put
the
position
one.
L
We
say
that
the
rule
is
up
and
then
we
have
three
proper
a
possibility:
zero.
Four!
If,
if
it's
one
one
is
it
six
before
on
to
is
its
255,
then
we
put
the
matching
operator,
no
argument,
the
CDA
and
no
argument.
So
now.
What
we
want
to
do
now
is
to
have
a
better,
more
compact
representation
of
the
blue
information.
So
what
we
will
put
in
a
row
so
one
possibility
and
of
course
it
has
to
be
unique
and
understood
by
everyone.
L
So
one
possibility
is
to
use
CID
CID
to
put
in
these
blue
fields.
So
here
it
doesn't
represent
a
column,
but
your
present
value
you
put
in
a
new
entry.
So,
for
example,
if
we
want
to
represent
field
ID,
we
can
have
a
basic
type,
that
is
sealed,
ID
c--
type,
and
then
we
derive
all
the
fields.
We
know
all
the
field
names
we
know
into
new
identity.
L
L
So
it's
a
good
way
to
represent
the
information,
but
the
prime
is
that
if
you
do
that,
maybe
seed
idea
will
be
very
large
and
we
may
have
to
find
some
way
to
optimize
what
we
will
put
in
a
value,
for
example,
ear.
It
can
be
for
bite
for
acid
ID.
If
we
can
have
only
one
bite,
it
will
be
better
because
we
are
in
a
constrained
environment.
L
So
how
we
can
do
that
one
possibility.
I,
don't
know
if
it
was
Maya
now,
because
lots
of
things
may
change
in
in
the
core
curve
is
that
we
can
also
have
a
shortcut
that
will
be
an
enumeration
of
all
these
fields
and
manually.
The
group
will
select
which
fields
we
want
for
a
shortcut.
For
example,
ipv6
version
is
not
very
useful
because
nobody
will
modify
the
version
of
ipv6.
L
So
here
we
don't
need
something
very
specific
for
management,
but
for
other
fields
we
can
use
it
if
you
use
Sieber
value
between
0
and
23
are
in
one
bite.
So
here
what
we
can
do,
for
example,
is
to
use
positive
number
5,
pv6
and
UDP
and
negative
number
4
quad,
and
here
we
have
a
lot
of
room
but
remains
for
new
new
shortcuts.
L
If
we
do
that,
so
we
have
to
use
Union
to
represent
this,
and
we
say
that
the
fill
ID
type
is
a
union
between
identity,
right,
so
seat
value
and
a
number
which
the
small
number
that
we
would
have
currently
Union
is
very
trivial,
because
when
you
send
an
integer,
you
send
an
integer
when
we
want
to
send
an
identity
ref,
you
send
a
tag
and
an
integer
and
you
can
make
the
difference
between
them.
So
this
means
that
there
is
no
extra
cost
to
send
chocolate.
L
B
L
B
L
So
we
can
do
that
for
fit
idea.
We
can
do
this
for
field
land,
for
so
it
means
that
for
of
course,
when
we
send
a
number,
we
sent
a
number
it's
a
positive
number
and
we
create
some
seed
value
for
function
like
variable
or
token
the
length
the
two
guitar
defined
currently
in
the
graph,
and
we
can
have
also
shop
cut
on
to
avoid
confusion,
shot
cut
can
be
here
just
negative
number.
We
are
very
few
shortcut
Brent
right
now,
so
we
we
have
a
lot
of
room
for
that
so
target
value.
L
We
have
two
types
so
here
maybe
we
have
to
work
more
on
the
way
we
do
that,
but
here
it
can
be
a
union
between
in
64,
it's
not
just
field.
We
are
using
right
now
on
string
that
we,
we
can
say,
as
I
said
before,
target
value
is
not
enough.
We
need
a
position
because
it's
you're
using
the
matching
list,
so
we
create
a
group
with
target
value
and
this
position
when
you
have
only
a
for
example
equal,
then
you
will
have
the
position,
but
you
have
only
one
on
three
in
this
one.
L
So
it
means
that
if
we
do
that,
we
will
have
this
cutting
and
instead
of
having
identity.
Here
we
put
the
CID
we
put
lands
here.
We
use
instead
of
using
direction
and
put
up
or
down,
we
put
a
number,
but
we
are
assigned
to
it.
Exeter
extra
matching
operator
has
a
special
specific
value,
is
4
and
CDA,
as
of
so
specific
value.
So.
L
A
L
With
to
decide
which
things
that
can
be
okay,
so
this
was
chocolate
when
I
expected,
but
in
fact
we.
This
is
the
first
attempt
to
make
a
young
model
on
this
of
course
view
you
can
criticize
it
without
program.
I
am
NOT
a
young
expert,
so
it
might
my
first
attempt
to
do
something
onion,
so
we
have
to
check
the
very
deeply
see
if
it's
correct
or
not,
and
what
is
important
here
is
that
we
will
mainly
use
it
on
Coral
Cove
and
so
see
the
impact
of
the
choice
on
the
coding
of
information.
A
B
Actually,
because
we
we
have
one
minute,
more
value
may
be
left
in
until
so
who
is
the
next
presenter
so
Curtis
so
Curtis
you
can
so
chair
hat
off
just
to
say,
what's
really
interesting,
when
this
thing
is
modeled
with
Yang
is
that
we
have
the
protocols
that
go
around
it.
So
once
you
have
the
data
model,
you
have
the
midday
tomorrow
actually
specifying
this,
then
you
can
go
and
configure
it.
You
know
from
a
server
side
over
the
radio
and
all
this
comes
out
of
the
box.
So
that's
that's
very
interesting
thanks.
A
Initially,
I
was
really
asking
the
question
to
the
hon:
do
we
really
need
to
make
that
very
concise
is
in
this
between
some
provisioning
system,
like
the
triple-a
server
and
the
network
side,
so
between
those
two,
we
have
a
lot
of
bandwidth
to
be
very
care
to
make
that
concise
and
I'm
getting
more
and
more
feedback.
Actually,
the
devices
could
provide
the
whole
model
as
they
connect
to
the
network
instead
of
products
producing
the
URL
of
the
module
is.
If
that
sort
of
thing
happens,
then.
E
E
So
the
round-trip
time,
and
also
its
variance
the
round-trip
time
in
lt1,
is
much
greater
than
the
typical
one
that
we
have
on
the
internet
and,
for
example,
the
default
RTO
in
tcp
used
to
be
three
seconds.
It
was
a
few
years
ago
reduced
to
one
second,
also
that
the
fault
RTO
in
coop
is
randomly
chosen
between
two
and
three
seconds
and,
however,
in
in
LP
1,
we
have
retransmission
timers,
for
example,
when
we
use
go
up,
and
if
we
send
a
con
message,
there
will
be
a
retransmission
timer.
E
E
E
E
E
E
I
looked
at
well
for
the
request.
Well,
you
mean
for
the
uplink
message:
yes
well,
I
assume
4
bytes
as
a
minimum
like
a
low
payload
size,
not
totally
sure
it
really
matches
a
realistic
use
case.
However,
it's
like
theoretical,
like
trying
to
find,
which
is
the
the
minimum
RTT
we
could
get
like
in
a
very
small
payload
size,
because.
E
Thank
you.
So
we
have
a
similar
analysis
for
seat
Fox
and
in
this
case
we
have
the
same
assumptions.
What
changes
is
that
the
downlink
response
making
at
the
beginning
of
the
downlink
receive
window
or,
at
the
very
end,
trying
to
find
again
the
minimum
and
maximum
possible
RTT
values,
and
we
find
that
in
this
case
the
default
cop
is
always
below
the
round-trip
time.
E
So,
in
addition
to
what
we
have
we,
we
can
also
find
another
couple
of
problems,
which
is
that
in
some
scenarios
we
find
what
we
call
higher-order
are
titties.
There
can
be
two
reasons
for
this.
The
first
one
is
compliance
with
spectrum
access
regulations
which
are
enforced
in
some
regions
of
the
world,
for
example
in
the
EU.
If
the
device
wants
to
transmit
and
wants
to
use
some
in
some
frequency
bands,
there
may
be
two
approaches.
E
You
may
use
listen
before
talk,
but
if
you
don't
do
that,
then
there
are
duty
cycle
constraints
that
are
enforced,
such
as,
for
example,
the
duty
cycle
needs
to
be
below
1%
in
some
specific
frequency
bands.
So
there
are
lt1
devices
that,
in
order
to
comply
with
this
rule,
send
some
uplink
message
which
may
take
X
seconds
and
then
stay
silent
for
the
subsequent
99
X
seconds.
E
E
Okay,
so
we've
seen
these
special
characteristics
of
the
round-trip
time
in
lp1,
and
now
we
could
think
okay,
what
should
we
do?
There
are
probably
two
scenarios
here,
and
one
is
maybe
if
delay
is
not
really
relevant
for
the
application,
perhaps
we
just
need
to
set
the
the
RTO
or
the
default
RTO
to
the
highest
expected
round-trip
time,
plus
a
value,
and
that's
it
and
doing
this.
We
avoid
experience
timeouts.
E
E
If
at
some
point
we
detect
that
we
are
in
some
interval
in
which
we
have
higher
our
titties
again,
it
is,
we
can
go
back
to
the
high
RTO
state.
So
the
idea
here
is
trying
to
separate
these
two
different
scenarios
in
terms
of
the
RTT
values,
because
if,
for
example,
you
assume
that
you
try
to
handle
all
of
this
with
a
similar
RTO
algorithm-
imagine,
for
example,
the
TCP
RTO
algorithm.
E
Yeah
and,
for
example,
also,
you
might
consider
a
constant
RTO
and
the
point
is
in
that
case
you
really
would
need
to
have
two
different
values
for
that
two
different
constant
rtos,
because
if
you
try
to
use
a
single
one,
it
will
only
be
adapted
to
perhaps
the
low
or
the
high.
But
you
cannot
be
well
adapted
to
both
situations
here,
so
some
possible
next
steps
for
this
document
would
be
analyzing.
E
Also
what
happens
for
what
we
could
call
down
Ling
our
titties,
which
would
be
initiated
in
the
downing,
and
then
there
would
be
an
uplink
response
and,
of
course,
studying
better
refining
the
dual
RTO
algorithm.
That's
proposed
here,
perhaps
evaluating
the
performance
and
the
main
question
here
would
be.
Okay.
Is
there
interest
in
this
work
and
subsequent
question?
If
the
answer
is
yes,
then
would
be
okay
in
this
document
there
are
like
different
kinds
of
contributions.
For
example,
we
have
some
kind
of
guidance
material
for
how
to
set
the
RTO,
which
is
rather
informational.
E
F
Carlos
on
here,
thanks
for
the
presentation,
well,
two
questions.
First,
one
I
noticed
that
you,
the
draft,
is
not
under
any
specific
working
group.
So
are
you
planning
to
expand
the
scope
to
other
technologies
and
the
reason
I'm
asking
this
is
because
I
believe-
and
we
will
hear
from
from
Charlie
later
on
the
update
from
my
trip,
Oviedo
2.15,
but,
for
instance,
there
could
be
applications
of
chic
to
other
technologies
that
are
not
lp1,
necessarily
so
maybe
multi-hop,
in
which
case
this
delay
could
be
even
more
variable
or
unknown.
F
E
So
actually,
the
the
focus
of
the
document
would
be
LP,
one
meaning
the
technologies
that
are,
for
example,
currently
the
target
ones
in
this
working
group
I
was
honestly
having
some
doubts
about
whether
perhaps
maybe
LP
one
could
be
like
the
home
for
this
word,
but
also
because
this
relates
a
little
bit
with
transport
area.
That's
the
reason
why
this
is
like
not
explicitly
indicated
in
the
document,
but
actually
I
only
requested
to
present
this
here.
F
A
It's
related
to
the
work
here
because
we
introduced
a
very
weird
form
of
latency,
but
yes,
we
are
not
any
consumers,
and
this
is
a
transport.
This
is
something
which
concerns
TCP
does
do
the
TCP
algorithm
without
documented
are
not
like
applicable
here,
but
but
I
think
it's
very
important
data
useful
data
for
your
Han
document
to
provide
like
default
values
or
suggest
ways
of
of
tuning
the
d'art
ET
for
coop
I.
Think
that
should
be
part
of
your
documents,
because
it's
an
important
information.
H
E
So
in
the
in
the
analysis,
part
of
the
document-
basically,
we
have
we
study
the
performance
of
ROM
free
time
for
different
technologies,
so
the
idea
would
be
for
each
technology.
Perhaps
we
want
different
settings
and
also
we
may
have
like,
for
example,
some
art
yoga
rhythm
running
at
the
application
layer,
some
other
RTO
lower
layers
like
cheek
fragmentation,
for
example,
and
those
don't
need
to
necessarily
need
the
same,
although
perhaps
it
could
be
interesting
to
study
if,
if
maybe
the
same
algorithm
can
be
reused
across
layers,
you
know,
okay,.
D
H
E
B
So
about
the
bottom
of
the
question
that
asked
about
the
interest:
I
think
that
one
of
them,
so
it
first
observation-
is
that
you
have
some
figures
that
show
that
timers
for
co-op
are
turning
out.
There
are
over
N,
so
that's
by
itself.
It's
something
pretty
interesting
and
it
serves
as
a
support
for
some
other
jobs
that
were
proposed
here
in
the
in
the
working
group.
So
personally,
I
find
this
work.
Interesting
then
I
would
like
also
to
talk
to
our
to
our
ad
and
and
really
to
to
discuss
how.
B
How
would
what
would
be
the
future
of
this
of
this
draft?
We
currently
in
the
proposed
charter
modification
we'll
talk
about
this.
We
don't
have
anything
in
that
aspect,
but
what
I
feel
is
that
if
you
have
enough
interest
in
your
feedback,
then
okay,
so
so
much
is
on
the
on
the
mic
and
is
going
on
the
mic,
and
he
will
give
us
some
more
information
about
this.
H
B
Yes,
yes,
yes,
that
that
was
yes,
sir!
Thank
you
for
for
enjoying
this
I
didn't
want
to
leave
this
impression,
so
it
is
yes,
so
hold
off
until
the
recharger.
Yes,
this
is
definitely
what
we're
doing.
What
I'm
saying
is,
you
know,
keep
the
work
and
we'll
see
in
the
future,
and
if
you,
you
know,
but
I
feel
that
this
is
a
very
interesting
work.
B
L
What
is
important,
too,
is
that
we
believe
that
it's
a
very
important
document,
because
when
you
see
the
feedback
we
got
from
the
accattone
or
the
feedback
from
the
review
from
the
main
chick
document,
for
example,
the
variable
field
in
feed
lunch
is
not
well
understand,
and
there
is
no
example
right
now
in
the
IP
UDP
compression.
This
example
are
in
the
coop
document.
So
it's
not
clear
to
understand
it.
So
Dominique
suggests
to
move
one
example
into
main
document,
and
this
co-op
document
will
explain
in
more
details
also
behavior
further
for
the
field.
A
Mean
I
love
the
idea
of
having
examples
in
the
appendix
I
think
that
it's
as
good
to
put
the
example
in
this
one
document,
because
the
other
one
is
flying
I
mean
it's
already
shipped
yeah
since
the
example
really
realize
to
what
you're
doing
here.
Why
not
put
it
here?
Dominique
has
a
strong
advice
on
that,
not.
C
Strong-
and
this
is
the
mini
person
yeah,
the
thing
is
as
I
mentioned,
then
I've
mentioned
that
the
capital
times
already
the
other
draft
has
free
deliverables
in
it,
the
general
shake
compression
engine,
the
fragmentation
protocol
and
the
application
of
compression
to
you,
tn
ipv6,
and
in
the
description
of
the
generic
engine.
We
try
to
mention
the
fact
that
we
can
compress
variable
and
fleet,
but
we
don't
have
an
example,
and
so
people
have
a
hard
time
figuring.
C
A
A
Informational
reference
in
the
main
spec
saying
you
have
an
example
of
that
Snuka
expect.
But
now,
if
things
change
in
the
coop
spec
I
mean
it's
good,
that
the
examples
in
the
course
back,
because
otherwise
you
may
only
delay
the
Sheik
dark
and
I
mean
it's
complex
enough,
not
I.
Didn't
you
think
that
needs
to
be
reviewed.
Well,.
C
A
Okay,
would
then
we
now
have
a
question
for
Suresh
again,
if
he's
hearing
us,
what
we
seem
to
need
now
would
be
helped
from
probably
core
and
reviews
from
from
people
who
are
more
expert
on
the
website.
Would
there
be
a
way
through
the
AAT
direct
writer
or
directly
through
the
indirect
right,
to
get
some
early
reviews
from
people
who
are
experts
in
core
that
would
really
help,
and
then,
if
we
have
like
a
co
expert,
reviewing
this
and
totally
happy
to
start
the
work
of
Lascaux.
B
And
and
improbably
that
there
will
be
a
second
question
on
that,
and
this
would
be
like
we
see
in
some
of
the
drafts
and
of
the
technology
draft.
We
see
that
the
there
is
interest
for
running
coop
over
over
shake.
We
already
know
that
you
know
it
works
now.
The
question
is
generally
okay.
Do
we
want
to
push
it
further?
So
that's
also
a
question
that
could
be
open
to
you
to
do
the
working
group
is:
do
we
want
to
delay
further
the
document
in
and
try
to
make
it
like,
very,
very,
very
optimal?
B
Or
do
we
say,
okay,
we
we
are
ready
to
ship
this
version,
it's
working!
It's
it's
pretty
good.
We
we
don't
even
know
if
it
can
be
done
better
right.
So
do
we
say
okay,
it's
enough
as
it
is
we
ship
today
and
in
any
case,
we'll
need
to
have
feedback
from
terrain
deployment,
and
that
is
not
going
to
happen
in
a
month.
So
that's
going
to
happen
in
one
year.
Do
we
have
v1
today
and
a
v2
in
a
year
right.
B
Okay,
around
ten
people
are
maybe,
if
I'm
not
mistaking
so
out
of
these
people.
Who
would
consider
that
we
should?
We
should
keep
with
this
simplification.
Let's
say
so
go
with
our
version
today
and
if,
in
one
year
or
year
in
a
half,
we
decide
that
well,
there
are
sufficient
use
cases
to
do
something
better.
Then
we
go
with
the
next
version.
So
if
you,
if
you
are
for
this
option,
please
raise
your
hand.
Okay,.
B
So
everyone
that
has
read
it
I
think
has
voted
for
this
one.
So
who
would
say
that
we
delay
the
draft
until
we
have
some
some
potential
like
some
more
data,
and
maybe
you
know
one
in
one.
We
delay
the
draw
for
one
more
year
for
eventually
get,
maybe
something
better,
so
praise
the
right.
Yes,
please
raise
your
hand
now
so
nobody's
raising
their
hand.
So
for
me
that
that
would
be
that
we
could
do
a
working
group
Blasko
and
okay.
So
I'm.
B
Think
yeah,
and
he
put
also
it
so
okay,
so
we
have
we
have
with
from
our
ad.
We
have
please
ship
it.
So
that
means
that
we'll
be
doing
a
working
group
last
call
and
we
will
copy
color
on
this
and
yeah.
We
have
to
review
by
core.
So
this
means
that
here
it
goes
we're
on
the
way.
So,
thanks
thanks
rush
for
this
and
thanks
everyone.
C
C
Because
it's
new
in
the
new
trotter
we
received
that
work
for
the
future,
which
came
here
to
report
that
we
haven't
done
much
of
the
last
month
on
this
one.
It's
a
little
bit
of
history
for
those
who
haven't
followed
that
one
originally,
there
were
two
separate
drafts
by
two
different
set
of
offers
that
were
presented
and
discussed
at
ITF
100
in
101,
which
is
already
a
long
time
ago,
and
then
we
decided
we
would
join
forces.
C
So
we
merge
everything
in
one
single
draft
and,
as
I
just
said,
we,
this
work
was
put
aside
for
the
best
part
of
2018
to
finish
the
ipv6
ship
draft,
just
to
remind
everybody.
This
is
there
is
a
general
interest
in
operation,
administration
management
for
IT
networks,
and
these
are
typically
I
mean
we
want
to
do
very
simple
basic
stuff.
C
We
want
to
have
ICMP
error
messages
that
users
expect
from
you
know
the
IP
network.
We
want
to
be
able
to
do
a
ping
able
to
do
a
trace
route
and
see
the
the
network
respond
with
the
messages
were
used
to
that's
the
very
basic
stuff
and
we're
still
open
to
other
use
cases
to
move
on
to
do
more,
more
functionalities
in
that
direction.
C
The
use
case
beside
discusses
whether
the
those
messages
should
actually
go
over
the
lt1
or
if
they
should
be
proxied
at
the
core,
and
the
core
should
answer
on
behalf
of
the
devices
without
actually
sending
a
message
about
the
empty
one.
So
that's
also
part
of
that
draft
and
and
of
course,
we're
going
to
use
cheek
to
compress
those
messages.
C
So
this
is
slide
from
IGF
100,
which
describes
the
very
scenarios
that
we
are
considering
right
now,
so
we
want
to
consider
a
device
that
sends
an
IP
packet
to
the
Internet
and
for
some
reason,
message
is
not
delivered.
We
want
the
device
to
get
an
ICMP
error
back,
so
it
can
do
something
we
want
the
device
to
be
able
to
do
a
pinch.
Just
make
sure
the
destination
is
still
there.
C
We
want
users
on
the
internet
or
applications
on
the
Internet
to
be
able
to
send
an
IP
packet
to
the
device
in
get
an
ICMP
error
message
back
in
case.
Something
goes
wrong.
We
want
the
typically
human
user
to
be
able
to
do
a
truss
trace
route
to
the
address
that
corresponds
to
that
device.
Now
we
have
to
decide
whether
this
trace
rod
goes
all
the
way
over
the
lp1
to
the
device
or
if
we
get
an
answer
on
behalf
of
the
device
from
the
lp1.
M
C
C
So
we
wisp
in
the
version
just
two
months
ago
to
revive
that
draft.
That
was
expiring.
We
simplified
a
little
stuff
I,
don't
want
to
go
to
the
details
and
we're
going
to
resume
that
work
and
expect
some
discussion
on
mailing
list.
If
you're
interested,
please
contribute
the
discussion
and
we
want
to
implement
that
using
open,
check
and
experiment
and
see
if
we
like
it.
C
D
C
That's
a
question
so
you're
welcome
to
the
to
the
discussion.
As
we
said,
we
this
ways
it's
a
question,
but
what
does
it
mean,
as
Carl
has
explained
in
his
presentation
yeah
if
the
device
is
a
class,
a
device
in
laura1
the
next
downlink
opportunity
from
the
core
to
the
device?
Maybe
the
next
time
the
device
decides
to
send
an
uplink
which
depends
on
its
application,
so
that
might
be
tomorrow
morning.
So
what
does
it
mean
to
ping
that
device?
C
Maybe
we
it's
enough
for
us
to
say
that
from
the
core,
the
device
is
provisioned
and
is
reported
as
being
as
life
as
it
can
be,
and
so
maybe
this
is
what
women
back
device
is
still
there.
We
we
think
it's
in
there,
but
obviously
we
don't
want
to
we.
We
are
not
even
able
to
send
it
to
downlink
right
now.
So
maybe.
D
C
L
D
C
A
A
Ping
minus
six,
so
you
should
I
think
that's
there,
six
or
whatever
and
same
for
trace,
rot
and
it
used
to
be
different
applications
of
v6.
So
it
might
be
that
you
might
need
an
option
to
be
able
to
ping
a
device
and
get
such
sensible
result
when
I'm,
not
against
that.
No
prob
with
that.
If
there's.
B
This
III
remember
that
yes,
sir
mentioned
that
they
you
know
they.
He
has
been
working
on
on
some
way
to
to
make
the
distinction
you
know
like.
If
you
have,
you
know
the
product,
the
the
shake
thing
that
so
the
the
the
Gateway
or
something
that
will
answer
instead
of
the
device
you
know,
so
we
can
have
a
different
ICMP
code
or
something.
But
that
is
a
good
question,
so
I
maybe
will
need
to
get
some
input
also
from
him.
A
A
We
will
have
this
presentation,
but
I
would
like
to
to
just
take
this
window
of
time
to
do
other
core
adoptions
before
people
leave
this
room
in
case.
Some
people
want
to
leave
early
I
just
want
to
make
sure
that
the
the
call
for
adoptions
are
done,
so
please
be
prepared,
it's
happening
now
and
so
we'll
be
raising
hands
for
the
dumb
question.
So
first
tribes
will
be
talking
about,
would
be
in
the
other
will
presented.
Them
will
be
sick,
Fox.
So.
N
A
A
B
That,
but
that's
great
thank
you
also
to
the
others.
So
we
as
as
cassette,
will
confirm
on
the
mailing
list,
and
once
we
get,
you
know
the
the
necessary
feedback.
You
will
be
invited
to
submit,
as
working
group
document
for
the
rich
chartering,
a
discussion
that
that
we
had.
So
let
me
just
switch
the
slides.
We
have
already
discussed
this
and
basically
most
of
the
things
are
as
in
the
in
in
the
old
charter,
with
some
fact.
The
second
item,
the
second
charter
item,
was
split,
so
here
what
you
have
is
in
in
in
black.
B
That's
that's
what
we
have
today
in
the
charter
and
we
just
are
making
it
explicit,
and
we
had
a
question
on
on
the
green
one
and
on
the
orange
one
eventually,
so
the
green
one
is
about
OAM
and
one
of
the
questions
was
okay.
We
can
really
make
it
pretty
specific.
We
want
ping
in
in
this
sense,
or
in
that
sense
you
know,
and
so
in
the
sense
of
the
draft
of
that
that
was
presented
just
just
be
beforehand.
B
So
that
is
something
that
we
would
like
to
do
to
get
some
input
on.
So
do
we
leave
it
as
it
is,
and
that's
the
first
question
and
we'll
need
to
get
some
answer
for
that,
one
from
also
from
from
suresh,
and
the
second
point
is
you
know
doing
who
is
there
any
interest
in
which
is
the
time
now
about
security
or
something
else.
A
The
point
is
probably
not
the
bodies
in
suresh,
and
I
guess
we
discussed
over
the
last
the
previous
two
meetings,
the
the
pretty
much
the
charter
that
you
have
in
front
of
you.
We
we
had
those
questions
about
security,
ipv4
other.
There
was
nothing
which
came
out
of
of
that,
so
we
posted
to
Suresh
a
candidate
charter
which
has
all
four
items
and
on
this
paper
and
Suresh,
if
you
have
any
news
for
us
about,
you
know
where
that
request
from
us
is
now
standing
anything.
You
want
to
tell
us
about
that.
O
Your
on
cylinder,
slowly,
okay,
so
now,
I
start
again,
so
I
think
this.
The
cheek
care
had
a
compression
of
coop
has
a
very
good
part.
I
mean
a
security
for
compression
for
oo
score,
which
I
think
was
very
useful
and
there
is
a
accompanying
key
establishment
protocol.
A
key
exchange
protocol
called
L
hook
and
if
anyone
is
interested
in
that,
that's
a
very
compact
way
of
doing
key
exchange,
so
you
could
do
it
in
pre,
shared
key
based
authentication
in
45,
bytes
or
less
three
messages
could.
A
O
So
this
was
I.
We've
talked
about
this
offline
and
I.
Really
I
haven't
really
had
time
to
look
at
this,
so
this
is
just
since
the
security
question
work
was
on
this
slide.
I
just
want
to
acknowledge
I
think
was
good
work
done
on
compressing
all
score
and
if
you're
interested
there
is
a
key
exchange
protocol.
If
anyone
is
interested
mystic.
A
P
I
just
want
to
understand
a
little
bit
more
about
the
ipv4
stuff,
like
I
was
not
really
supportive
of
the
ITV
forward
before
so.
If
somebody
has
like
some
real
item,
they
want
to
work
on.
Let
them
put
it
forward
because
I
haven't
seen
any
drafts
or
any
proposals
right.
So
at
this
point
my
answer
is
no,
but
if
somebody
has
like,
let's
talk
about
it,.
J
Q
R
R
Yeah
I
did
some
kind
of
sorbet
try
to
find
out
how
much
interest
the
worst
about
having
maybe
before
for
narrow
variety.
What
I
found
out
is
that
there
is
a
lot
of
deployments
of
operator
networks
at
the
moment.
Ipv4
only,
and
then
there
are
also
a
lot
of
deployments
of
let
a
external
networks
which
are
happy
before,
even
if
internally,
in
the
operators
they
use
ipv6.
D
R
R
R
R
What
are
we
actually
targeting
if
we
are
targeting
like
going
for
legacy
as
well
Hitler,
then
it
would
be
good
something
in
ipv4,
but
just
to
handle
the
legacy.
If
we
are
okay
with,
let's
waiting
what
happen
later
and
then
adoption
and
so
on,
and
then
we
are
targeting
that
kind
of
deployments,
then
I
don't
have
any
problem
to
leave
it
as
it
is.
R
S
H
A
P
T
U
A
P
I'm
not
like
that's
not
what
I'm
worried
about,
because
I
want
to
see
like
so
I
ate
Edgar
was
like
very
non-committal
right
and
I'd
understand,
because
what
Edgar
said
is
like
he
was
not
recommending
it,
but
he
heard
a
survey.
Okay
so
and
that's
what
like
I,
want
to
see
the
survey
and
see
what
the
results
are
like
and
and
is?
P
Is
there
a
way
for
these
people
to
move
forward
right
because
I
don't
want
to
be
like
anti
v4
or
anything
like
that,
but
I
just
don't
see
how
before
can
work
like
to
the
scale
that
we
need
right,
like
especially
with
like
MB
IOT,
where
we
are
trying
to
scale
the
number
of
devices
right
like
you
know,
when
the
devices
become
cheaper
and
and
with
longer
life
like
we're,
gonna
see
like
a
proliferation
of
the
number
of
devices
and
I
just
don't
see
before
cutting
it
right.
So
that's
really
what
I'm
worried
about.
A
P
That's
what
I'm
saying
so
like
until
we
know
more
and
analyze
this
a
work
item
like
I,
don't
want
to
talk
about
it
during
recharter
because
usually
like
the
stuff
we're
talking
about
for
each
other,
has
like
some
kind
of
draft.
That's
been
a
on.
We
discussed
it
right.
So
let
somebody
write
a
draft
or
like
at
least
write
like
a
problem
statement
or
something
like
that
right.
So
what
we
want
to
do
and
then
we
go
for
the
reach
out
rafter
for
that
item.
P
A
P
B
If
I
understood
correctly
and
Pascal
correct
me,
okay,
so
sirisha
some
on
the
mic.
So
does
this
also
question
for
for
Suresh,
so
we
go
on
without
a
key
for
for
now
and
and
we
see
if
there
is
work
coming
up.
If
there
is
a
draft
out
and
if
there
is
simple
from
somewhere
then
in
the
future
we
might
do
it,
but
not
today.
C
D
D
So
this
originally
thought
I
would
come
here
and
discuss
some
of
the
things
that's
going
on
in
the
Standing,
Committee
and
ie
afraid
a
to
2.15
and
so
I'll
do
a
little
bit
of
that
are
a
lot
of
that
relative
to
the
whole
presentation.
But
it's
a
very
short
presentation
and
then
mass
gala
asked
me
to
give
a
little
review
of
what's
actually
other
other
groups
in
NATO.
2.15
are
doing
so
most
of
that
stuff.
D
The
standard
for
X
was
just
approved
by
the
Tripoli
standards
Association
and
and
that
it's
called
field
area
network
extensions.
D
But
it
goes
up
it's
highly
scalable
to
thousands
of
devices
and
the
content
of
10a
had
to
do
with
something
that
was
not
was
under
specified
in
the
original
document,
how
to
handle
source
routing.
Basically,
one
of
the
major
topics
of
discussion
has
been
coexistence
between
a
two
2.11,
a
h
and
802
duck
15.4
G,
and
this
is
a
somewhat
precipitated
by
work
and
they
doted
on
15.4
Z,
which
is
a
as
best
I
understand
it.
A
revision
of
ultra-wideband
and
there's
a
lot
of
well.
D
When
you
get
to
low
power
interference,
issues
can
really
cause
a
lot
of
difficulty
and
there
right
now
it
looked
to
me,
like
IU,
2.11,
aah,
sort
of
winds
on
through
hood,
but
really
suffers
on
latency
and,
conversely,
I
do
Ted.
A
1504
can
get
a
little
better
latency
in
terms
of
when
there's
interference
with
eleven
aah
and
I.
D
Don't
think
this
is
the
only
scenario
where
the
coexistence
concerns
are,
but
it's
really
comes
up
to
the
fore
with
low-power
and
then
lastly,
I'll
mention
in
a
turkic
1512
on
the
basically
the
idea
or
the
charter
of
eight
it's
about
fifteen
dot.
Twelve
is
to
make
802
dot.
15.4
is
nicely
programmable,
as
they
do
2.15
911
on
the
802,
Donald
or
Eric
about
15
as
nicely
programmable
as
they
go.
2.11
because
I
enter
through
911
has
a
relatively
easy
to
understand.
D
Interface
still
to
layer,
layer,
three
and
that's
been
a
source
of
a
lot
of
popularity
and
the
philosophy
of
native
2.15
was
that
when
we
want
to
make
the
device
is
really
small.
So
we
put
all
the
stuff
in
higher
layers
and
that's
not
been
very
successful
in
some
ways,
because
that
means
that
all
the
normal
stuff
you
would
think
of
that
has
to
be
done
on
the
device
for
say
by
how
transmissions,
from
whatever
has
been
done
differently
in
different
place,
mean
different
implementations.
D
So
so
now
we
want
to
make
it
more
like
a
two
2.11
and
that
work
is
proceeding
at
a
regular
pace
and
I
think
it'll
be
made
available
sometime
in
a
year
year
and
a
half.
So
that's
some
of
the
activities
in
8215
too,
but
not
all,
there's
also
an
802
dot
15.4.
Why
that
has
to
do
with
adding
some
security
measures
to
the
15.4
and
I
have
not
followed
that.
V
Communion
yeah,
it's
only
gonna,
mostly
coning.
Just
add
you
know
these
256
bit
AES
there.
We
have
a
hundred
and
twenty
eight
bits,
and
then
there
were
some
a
standard
organization
in
different
countries,
say:
oh,
it
would
be
nice
to
have
a
256,
or
at
least
have
a
roadmap
for
that
in
case
we
happen
to
have
quantum
computers
ever
so
that's
us
getting
ready
for
the
future.
If
somebody
would
ever
is
it
okay.
D
Sorry
about
that
well,
on
this
slide,
I
don't
have
to
describe
to
you,
but
I'll.
Just
I
just
mentioned
that
this
is
actually
the
presentation
I
made
today
to
15.4
group
and
so
I
wanted
to
make.
First
of
all,
the
point
of
this
is
to
make
a
document
for
a
writer
to
dot
15.4
update
of
the
current
document
of
the
document
that
we
had
out
there.
D
It's
not
current
any
or
but
we
wanted
to
show
how
to
use
SCH
c
or
shook
with
a
yogi
duck
15.4
and
not
just
specifically
for
for
w
but
4.4
in
general.
So
in
order
to
do
that,
you
have
to
compare
apples
to
apples
and
in
one
way,
when
problem
was
well
put
about
fragmentation,
do
we
use
shoot
fragmentation
or
do
we
use
a
turkey
duck
15.4
fragmentation
and
in
order
to
figure
that
out,
I
tried
to
make
some
estimate
on
the
minimum
header.
M
D
And
fragment
with
shaked
fragments
and
so
roughly
speaking,
I
think
if
you're
really
really
minimal,
you
can
get
everything
into
a
bite
for
the
fragment
header
for
sure
or
even
less.
Perhaps
this
is
a
single
bite
and
then
there's
this
mi
see
and
actually
I
want
to
make
sure
to
get
this
point
across
since
82.
D
That
15.4
is
going
to
put
a
frame
check
sequence
on
every
every
frame
we
don't
need
to
mi
see
now
was
going
to
try
to
convince
you
to
make
the
MSA
optional,
but,
according
to
the
previous
presentation,
it's
already
been
made
optional
again.
So
that
was
great.
Thank
you.
So,
in
order
to
compare
properly
to
fragmentation
from
shake
versus
using
a
turtle,
15.4
fragmentation
we
had
to
I
had
to
go
in
and
do
some
estimates
on
what
I
did
I
15.4
overhead,
its
per
fragment
and
since
I'm
really
really
short
on
time.
D
So
it
matters
a
lot
about
some
some
shion's
you
make
on
the
idea,
2.15
odd
for
headers,
and
you
can
get
probably
about
5
to
7
bytes
overhead
per
fragment
with
that,
and
that
depends
on
what
all
you
think
about
compressing
on
them
on
the
mac
header
so-
and
I
want
to
also
mention
as
briefly
as
I
can
that
when
I
described
the
shake
editor,
they
looked
at
I
15
that
or
the
Standing
Committee
on
IETF
by
surprise.
I
got
everybody
complaining
because
I
called
it
Mick
and
they
said
it
is
not.
D
C
D
That
what
their
argument
was
it
is
it's
not
any
sort
of
integrity
check,
because
it's
so
easily
defeated.
If
somebody
wanted
to,
you
know
Forge
a
little
bit
of
the
data
and
in
other
words
you
can
do
a
cryptographically,
but
if
you
just
use
the
sort
of
chicks
on
mechanism,
it's
not
good
enough.
It's.
A
D
D
D
D
So
that's
where
I
got
the
Mac
header
overhead
estimate,
because
when
Chicksands
down
to
fragment,
fragments
every
Mac
layer
thinks
every
one
of
those
is
a
frame
and
it's
gonna
put
the
frame
header
on
every
one
of
the
so
Leca
I
am
is
what's
been
in
native
to
a
15.4
for
a
long
time,
low
energy,
critical
infrastructure
monitoring
that
list
what
they
thought
was
going
on
with
low
power
wide
area
networking
10
years
ago.
So
there
was
a
big
debate
about
well,
maybe
we
should
get
rid
of
LEC.
D
I
am
and
just
put
locally
our
wide
area
network
in
there,
but
so
far
that
hasn't
happened
and
the
thing
about
a
talk
about
15.4
fragmentation.
It's
only
defined
for
this,
the
LEC
I
am
or
our
white
area,
and
in
order
to
do
it,
you
have
to
incur
the
overhead
of
first
sending
a
frame
fret
a
fragment
control
information
element,
and
so
what
I
did
was
amortize,
that
initial
fragment
control
thing
over
the
total
number
of
magnet
fragments
and
that
I
don't
know
how
many
fragments
you
would
get.
D
Okay,
well,
that's
the
way
it
goes,
and
so
I
will
spray
you.
This
fabulous
discussion
about
frame,
table
values
and
I.
Guess,
oh
so
one
thing
I
have
to
mention
this
and
in
order
to
compare
apples
to
apples,
we
really
need
to
know
about
the
security
model
for
SCH
c
and
what
is
that
I
try
to
propose
really
reducing
them
to
the
bare
minimum.
The
Mac
header
and
I
people
were
upset
because
there's
no
security
there
and
it's
in
the
argument,
went
on
so
I
guess
I
have
to
be
done.
D
D
B
Charlie,
so
yes,
and
a
very
good
question,
please
the
next
presenter
to
be
double
yes,
thank
you
very
much
Charlie
for
this.
You
asked
you
you
put
some
very
interesting
questions,
hope
to
to
have
them
answered
on
the
mailing
list
and
to
see
progress
on
the
draft
on
the
802.
The
15
note
4
shake
over
your
technology,
so.
M
D
M
Would
like
to
briefly
talk
about
is
the
header
compression,
so
ESP
is
IPSec,
so
IP
security.
So
this
is
clearly
nothing
herein
appear
on
that's
happening
in
a
few
second
it,
but
because
we're
using
a
lot
of
technologies
or
ideas
she
was
developing.
Karsten
encouraged
me
to
present
it
here
very
quickly.
So
I
guess
most
of
you
know
IP,
not
everyone
of
you
probably
knows
IPSec.
M
M
So
we
could
only
so,
for
example,
shake
could
only
compress
the
ESP
header,
but
everything
else
couldn't
be
compressed
and
the
good
thing
about
IPSec
because
build
a
security
context
which
includes
a
lot
of
these
values.
You
compression
could
be
quite
efficient
and
you
have
a
static
context
between
the
two
nodes.
M
So
everything
in
green
is
already
there.
So
we
don't
even
need
to
build
up
a
context
and
everything
in
blue
can
be
calculated
as
it's
done
and
shake
anyway,
and
the
other
few
things
are
typically
static.
So
what
we
do
with
is
the
header
compression.
We
just
used
that
so
we
already
have
a
static
security
context
between
the
nodes
which
are
talking
to
each
other.
We
even
have
a
separate
channel,
which
is
as
far
as
I
know,
but
is
missing
for
chica
took
a
moment
to
agree
on
the
compression
context.
We
can
use
Ike.
M
We
can
use
group
Ike
for
any
kind
of
group
communication
we
can
use
hip
or
we
can
just
do
it
static
and
compile
it
on
the
firmware.
This
context
already
holds
the
values
we
want.
Anyway.
They
call,
we
call
it.
Traffic
selectors,
for
example,
IP
addresses
ports
and
whatever,
and
we
have
done
this
before
I
think
a
few.
A
few
of
you
know
rock
and
rock
over
IPSec,
so
something
similar
has
been
done
there
before.
So
what
we
did
is
we
had
our
compression.
M
We
just
defined
how
to
do
it
and
that's
basically,
that's
probably
why
Karsten
told
me
to
present
it
because
I
guess
most
of
you
know
this
kind
of
actions
and
rules.
They
look
very
similar
to
what
is
defined
in
sick
because
they
are
inspired
from
rock
and
chick.
We
defined
them
in
the
document
for
ESP,
so
for
the
ESP
header
for
ipv6
for
IP
before
so.
This
also
means
IQ
before
it's
not
really
a
big
problem
for
us.
We
defined
them
for
TCP,
for
UDP
and
for
UDP
light,
and
the
this
looks
like
a
lot.
M
So
I
calculate
I
quickly
went
through
it.
That's
like
59
header
fields
to
exchange
rules,
for
if
you
cut
them
like
ports
and
stuff,
then
you'd
still
have
like
44
header
fields.
You
need
to
exchange,
but
because
so
much
stuff
is
already
there.
We
defined
strategy,
which
we
call
via
DSP,
which
optimizes
this
exchange
of
the
context
and
which
leaves
us
to
just
define
nine
or
to
have
Neetu
exchange
and
or
flash
nine
context
all
these
values,
which
we
can
then
use
to
compress
all
these
fields.
So
we
basically
have
in
an
optimal
case.
P
M
Extended
to
because
it
was
also
something
you
couldn't
compress,
otherwise,
that's
basically
the
I'm
happy
to
take
questions
offline
and
if
someone
who
thinks
this
is
kind
of
interesting
wants
to
read
the
draft
yeah
I
think
it
will
quite
aligned
it
to
what
will
be
the
final
document
in
chicks.
So
that
wording
is
similar
once
the
system.