►
From YouTube: IETF106-LPWAN-20191119-1520
Description
LPWAN meeting session at IETF106
2019/11/19 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
So
this
is
the
room
for
the
lp1
workgroup
meeting.
If
you
want
to
do
packet
over
helicopter
carriers
you're
in
the
wrong
room
and
with
this
we're
gonna
start,
will
delay
a
little
bit
passing
the
blue
sheets,
because
we
are
used
to
some
people
who
are
low-power
workers
and
arrive
later
in
the
meeting.
A
A
This
meeting
is
being
recorded,
so
it
will
be
published
on
YouTube,
I
guess,
as
usual,
we'll
be
recording
the
presence
on
the
blue
sheets,
we'll
be
passing
the
blue
sheets
in
9
10
minutes,
please
join
the
etherpad,
so
the
link
is
given
here.
This
is
where
we
take
the
minutes
and
mostly,
if
you
come
to
the
mic
and
make
a
point,
please
make
sure
that
your
point
is
correctly
captured
in
the
minutes.
So
the
best
way
for
doing
that
is
actually
to
participate
to
the
minutes
and
help
us
take
them.
B
A
A
Okay,
so
that
was
the
bashing
anything
anything
you
want
to
change
about.
The
agenda
as
proposed
so
we'll
be
talking
about
the
Yucatan
static
contact.
Sick
then,
will
ever
leave
you
first
time
at
the
ATF
presenting
the
sheik
of
aloha
one.
They
know
how
about
the
young
model.
They
will
talk
about
the
progress
and
the
static
context
for
coop
and
Dominique
will
update.
You
are
update
us
on
the
OEM
work.
B
So
that's
a
small
reminder
from
last
time,
so
we
have
our
first
charter
item
that
we
have
completed
and
we
are
working
on
the
second
charter
item.
We
are
really
advanced,
and
that
is
something
that
we
are
really
happy
wait
and
the
the
two
chairs
and
the
whole
working
group
I
think
that
we
can
be
proud
of
ourselves
and
you
can
be
proud
of
your
work.
So
we
got
all
our
milestones
in
green.
B
C
So
description,
so
the
chic
stuff
is
like
gone
through
the
iesg,
a
valid
it's
ready
for
opera,
so
I'm
ready
to
push
the
button.
We
were
expecting
one
review
from
Carsten
on
the
side,
like
so
we're
kind
of
holding
off
for
a
little
bit
to
see
if
something
comes
in
so,
but
we
are
until
end
of
next
week
before
we
approve
and
also
like
you
know,
Dominic
was
just
telling
me
like
you
know:
there's
some
XML
v3
XML,
tar,
cv3
stuff.
That
requests
we
change,
but
it
doesn't
change
the
content.
C
It
only
changes
the
source
file,
so
it
shouldn't
be
a
big
deal
process
wise
for
us
to
do
and
the
the
coop
it's
on
my
ed
eval
pile
it's
like
a
long
pile
now,
so
I,
probably
I,
think
I
have
like
11
documents
or
something
right
now
so
I'll
get
to
it.
Probably
you
know
I
would
say
about
before
end
of
the
year
for
sure
and
hopefully
as
soon
as
possible.
Okay
and
for
the
I
also
talked
to
the
editor.
I
know
like
Alex
did
as
well
and
Pascal.
I
know
if
you
are
there
too.
C
A
C
B
Here
the
only
points
on
all
the
other
things
are,
as
we
discussed
a
couple
of
times
already
so
here.
What
we
would
like
to
propose
is
to
modify
slightly
item
number
one
which
before
was
really
focused
on
coop
and
right
now
we
see
that
there
is
a
lot
of
interest
in
actually
having
other
protocols,
so
the
upper
layer
protocols
to
abusing
shake.
So
we
said,
okay,
how
about
we
reformulate?
B
C
That's
fine
right,
like
the
only
thing
is
like
the
milestones
need
to
be
more
precise
than
this,
because
you
cannot
say:
hey
I
will
send
borrow
or
something
right
like
without
knowing
what
bar
s,
but
so
the
chatter
can
be
like
a
little
bit
wider.
But
as
long
as
the
milestones
are
known
at
a
point,
we
stop.
A
Today
we
will
not
have
any
deliverable
associated
to
item
one,
but
if
somebody
comes
to
the
room
and
say
oh
I've
got
this
technology
like
we
had
the
LMS,
from
which
we
would
need
to
add
a
feature
to
check.
Then
we
would
be
capable
of
adopting
this
group
because
of
the
first
statement,
but
so
far,
and
then
we
would
have
an
item
in
the
in
the
list,
but
so
far
there
would
not
be
an
item.
That's
fine
and.
C
B
You
know
sign
your
destruction
good
to
go
so
with
this
we
can
go
on
to
the
first
presentation
from
Dominic
and
so
for
all
people
that
are
first-time
on
the
g---eight
attending
at
the
ITF.
You
can
go
to
the
IGF
web
site
to
meet
the
meeting
materials
and
then
you
can
see
if
all
the
presentations
you
had
all
the
links
there.
D
Hello,
so,
as
you
may
know,
there
was
a
hackathon
weekend
before
the
this
week,
and
so
the
the
Czech
community
had
a
table
at
the
hackathon
and
I'm
going
to
tell
you
did
so.
First
of
all,
this
is
the
team
about
a
dozen
people
showed
up
the
usual
suspects,
Cedric
who's,
our
technical
lead
wrong
so
which
he
from
Japan
he
actually
flew
in
on
his
own
money,
just
to
be
with
us
physically,
usually
is
removed.
But
this
time
we
decided
to
come.
D
Thank
you
so
GE
for
doing
this
for
us
our
own
as
well
Olivier
a
first-timer
first
time
at
ATF,
first
time
at
the
hackathon,
very
good
technical
expertise.
He
did
a
lot
of
stuff
that
we
hadn't
done
before
Rahul
who's
a
long
time
at
the
IGF,
but
first
time
at
our
table,
I
check
he
dived
into
the
curve
as
well
and
then
usual
suspects.
D
When
colors
myself
son,
we
had
Diego
student
at
University
of
Chile
joining
remotely
and
young
local
colleague,
Juan
Carlos
locally
in
Singapore
and
Ryan
from
Japan,
and
we
mostly
worked
on
the
open-source
implementation
of
shake,
which
is
called
open,
shake
and
is
available
in
github.
The
link
is
available
here,
but
we
also
worked.
Some
of
us
also
worked
on
an
other
implementation,
so
the
hackathon
goals
was
to
advance
the
implementation
of
shake
in
the
open,
open
source
implementation
and
especially
touching
two
drafts,
one,
that's
a
generic
check
mechanism
and
the
other
one.
D
That's
how
co-op
is
compressed
by
a
check,
so
this
well
the
two
basis
for
the
work.
Our
goals
were
to
clean
up
the
repo,
because
we
had
quite
a
few
diverging
branches
before
and
said.
We
did
a
lot
of
work
before
the
hackathon
to
merge.
Everything
so
will
I
clean
rebel
to
start
with,
and
then
we
could
remove
that
code.
We
could
rename
files
restructure
the
repo,
etc
improve
documentation.
D
We
worked
quite
that
on
creating
a
better
dog
so
that
people
joining
the
project
can
understand
why
how
to
work
with
the
code
and
how
to
run
it,
and
also
we
improve
functionality,
fixing
bugs
and
already
set
up
the
trayvis
continuous
integration
tool
so
that
we
have
a
non
regression.
Testing
automated
and
then
Juan
Carlos,
diem
and
Diego
worked
on
the
implementation
of
University
de
Chile,
which
we
nicknamed
budget
and
so
yeah
great.
A
great
lot
of
activity,
I
think
open
shake.
D
What
we
learn
what's
left
to
do
for
the
next
hackathons
on
the
the
time
between
hackathons
I,
think
we
everybody
understood
the
shake
specification
better
by
trying
and
meant
it.
We
spotted
in
one
interpretation
detail
of
the
specification
that,
right
now
we
say
that
the
fragment
receiver
must
have
an
inactivity,
timer
and
our
own
pointed
out
that
in
some
cases,
Wendy
tag
is
not
used.
It
would
be
better
for
the
sender
to
have
the
inactivity
timer
as
well,
so
that
it
can
guess
what
the
receivers
is
being
doing.
D
So
that
was
a
useful
addition
in
terms
of
understanding
the
specification
we
spotted
a
missing
element
in
the
data
model
that
that
will
help
the
future
draft.
On
that
we
spotted
issues,
of
course,
in
European
chic
implementation,
that's
the
whole
purpose
of
the
hackathon
we
fixed
some
of
them
and
basically
we.
We
realized
that
more
tests
on
idiot.
D
That's
why
we
put
it
the
test,
automation
in
place,
and
we
also
need
to
be
better
at
reporting
the
issues
and
missing
features,
and
so
we're
going
to
use
the
issues
of
github
better
in
the
future
and
also
because
now
we
have
several
implementations
of
shake.
We
started
floating
the
idea
of
doing
an
intro
next
time
and
we'll
see
if
this
can
fly
and
under
which
framework.
E
D
The
last
version
so
sorry
for
the
old
timers
you've
seen
that
couple
times
already,
but
this
draft
is
really
free
drafts
in
one
it
has
the
header
compression
engine
specification.
So
it's
a
generic
engine.
It
is
not
attached
to
any
upper
layer,
any
lower
layer,
it's
just
a
mechanism
to
do
compression
using
a
static
context.
Hence
the
name
shake
so
typically,
this
would
sit
here
below
IP
if
you
want
to
compress
IP
headers.
D
The
same
draft
also
has
a
fragmentation
protocol,
and
this
protocol
comes
in
three
flavors
and
the
free
block
boxes.
Here
we
could
have
more
flavors
later
on,
but
right
now
we
have
free
which
addresses
the
needs
of
various
LP
one
technologies.
Various
situations
and
all
the
same
draft
also
has
a
description.
How
you
can
use
that
to
compress
UDP
ipv6
in
simple
situations
where
you
have
no
extension
headers
and
it's
fairly
simple,
because
UDP
ipv6
have
a
fixed
fields
that
occur
only
once
in
headers.
D
And
just
to
set
up
the
context
for
this
work,
there
are
other
related
drafts
that
do
more
than
UDP
ipv6
compression,
typically
compressing.
The
whole
stack
about
UDP
ipv6,
and
this
gets
more
interesting
because
now
cohab
co-op
has
address
that
are
optional,
that
okay,
multiple
times
that
are
variable
sizes,
and
so
this
gets
really
more
complicated.
And
that's
why
we
have
a
separate
draft
for
that
and
the
law
is
going
to
talk
about
it
later
and
then
applying
shade
to
various
lp1.
E
D
E
D
D
F
D
D
Optimistic
by
saying
today,
it's
probably
going
to
be
in
the
next
few
days,
because
I
just
had
a
chat
with
the
RFC
editor
in
the
hall
and
I
realized.
Well,
they
helped
me
realize
right
now.
We
have
tables
in
the
draft
that
appear
as
ASCII
art
and
they
want
this
to
appear
stable
so
that
it's
structured
in
the
document,
and
so
it
is
them
doing
the
change
and,
as
you
know,
sorry,
it
was
a
noticing
later
on
us
doing
the
change
in
XML.
D
Oh,
it's
establishing
a
new
version
in
v2
that
has
a
table
which
markdown,
which
we
use
for
the
editing.
The
document
can
do
for
us,
so
I'm
going
to
rip
in
the
document
and
make
the
tables
appear,
has
real
tables,
not
ASCII
art.
So
it's
a
minor
change,
technical
change
on
a
document
not
on
in
the
content.
D
Another
piece
of
information
that
I
thought
would
be
useful
is
the
current
uses
of
shake.
So,
of
course,
we
have
drafts
at
the
IETF
using
shape
the
ones
I
mentioned
before
compressing
cooperate
check
over
six
four
one,
nine
baat
that
we're
going
to
hear
about
next,
and
there
are
couple
demos
that
are
being
shown
for
a
few
years
already,
of
course,
UDP
ipv6,
compression
or
lore,
but
more
recently
the
LMS
UDP
I'll,
give
it
six
compression
overall,
was
this
month,
I
think
very.
E
D
At
orange
we
show
the
demo
of
compressing
the
coop
headers
over
LTE
M,
so
LT
m
is
IP
protocol,
so
we're
not
trying
to
compress
the
IP
headers,
but
just
the
coop
header
or
all
TM
and
evaluative
if
this
makes
sense,
but
the
benefit
of
that
in
terms
of
power,
consumption
and
airtime
occupation,
and
we
had
a
demo
with
Akio
and
I
mean
how
can
you
in
Cisco
had
a
demo
doing
SSH
over
with
under
evaluation?
We.
D
Instead
of
building
his
own
compression
specification
just
using
shake
as
generic
mechanism
in
a
prior
to
his
be
a
head
of
compression
implementations,
I
already
mentioned
open
shake
which
is
patent
free.
Originally,
we
said
it
would
be
it
would
micro,
Python
and
run
on
PI,
comma
PI
comes
devices,
use
a
flavor
of
non-standard
flavor
of
micro
Python
and
quickly.
We
had
so
much
we'd
spend
so
much
time
fiddling
with
the
hardware
RAID
Europe
icons
that
we
decided.
We
would
run
micro
on
computers
and
micro.
D
D
University
of
chile
has
an
implementation
in
the
Python
flavor
of
micro,
passion
and
our
friends
that
ride
have
been
saying
it
implements
shaking
right,
but
it's
not
committed
yet
so
we're
looking
at
five
known,
implementations
today
and
probably
a
6-1
coming
soon.
That's
why
we
think
we
can
start
talking
about
Interop
and
also
as
I
mentioned
scientific
papers
are
being
published
in
check.
So
it's
becoming,
you
know
more
visible
in
the
community.
The
first
one
here
is
by
the
this
draft
code.
D
Okay,
so
changes
since
the
twenty-first
most
changes
are
the
consequence
of
the
isg
reviews
and
a
few
reviews
we
got
besides.
Oh
yes,
gee
I've
classified
them
in
three
categories.
The
functional
changes
is
this
huge
ones
because
you
shouldn't
expect
to
change
the
functionality
after
iesg
review,
so
I've
classified
as
functional
changes
to
changes.
One
is
mistake
in
the
description
of
our
always.
D
So
it's
not
a
functional
change
is
a
change
in
the
text
that
reflects
functionality,
but
the
algorithm
was
intended
to
work
the
way
it's
described
now,
so
the
algorithm
hasn't
changed
that
the
description
was
wrong
actually,
and
that
was
me
rewriting
it
clean
slate.
A
year
ago,
when
we
changed
the
way
we
describe
the
algorithms
I
started
again
from
a
blank
page
and
it's
well.
D
You
wouldn't
expect
such
a
mistake
to
be
in
the
draft
at
this
stage,
but
anyway
this
happened
and
thanks
very
much
to
Benjamin
Carrick
for
spotting
this,
and
you
know
it's
a
security
area
expert
and
he
went
so
far
than
in
the
explanations
you
know,
following
the
iterations
of
the
state
machines
and
his
potato
mistakingly
in
the
details
of
state
machine,
which
nobody
else
in
this
group
was
supposed
to
look
at
the
state
machine
did
so.
Thank
you
so
much
to
him.
This
avoids
us
writing
an
errata
later
on,
which
is
always
embarrassing.
G
D
D
This
was
some
text
that
was
originally
in
the
main
part
of
the
document
that
we'd
moved
to
an
appendix,
because
we
did
not
quite
know
what
to
do
with
it
and
accurately.
So
the
IHG
reviews
spotted
that
this
was
a
bit
fuzzy
and
they
were
right
so
the
so.
We
rephrase
the
problem
that
the
problem
is
that
two
of
the
three
modes
of
fragmentation
are
bi-directional
protocols.
They
need
acts
to
do
selective
retransmission
so
because
they
are
bi-directional
protocols,
they
require
a
better
bi-directional
link.
Otherwise
they
don't
work.
D
D
This
is
a
case
for
Class
A
mood
of
rora,
when
this
is
kids
for
Sick
Fox,
for
example,
and
so
running
bi-directional
protocol
over
a
quasi
bi-directional
link
is
a
bit
difficult
and
appendix
F
provided
a
solution,
but
the
solution
may
not
be
required.
There
might
be
other
reasons
why
your
you
have
the
pureed
up.
Links
like
you
have
an
application,
that's
doing
a
sending
keepalive
messages
and
therefore
it's
providing
opportunities
for
downlink
transmission.
So
maybe
you
have
nothing
to
do
because
of
the
application.
Is
keeping
this
downlink
channel
open
for
you.
D
Maybe
in
some
cases
you
don't
have
such
a
place
for
any
reason.
So
maybe
you
have
to
do
something
about,
and
so
we
decided
that
this
draft
was
about
the
generate
mechanism
for
compression
and
fragmentation
and
rather
than
provide
a
solution
to
a
specific
case
of
specific
lp1
technologies.
We
would
just
state
that
we
need
a
bi-directional
link
and
you
may
have
to
do
something
special
if
you're
running
over
quasi
bi-directional
names
and
we
leave
it
to
the
she
cover
food
rafts
to.
D
The
second
category
of
changes
were
related
to
security
considerations.
Actually,
most
of
the
ISE
review
comments.
We
got
and
suddenly
most
of
the
discussed
points
where
on
the
security
considerations,
and
we
are
not
security
experts.
This
is
nuts
the
security
community,
so
you
one
could
expect
that
I'm,
not
too
surprised.
So
we
did
a
major
rewrite
of
that
of
that
section.
Again,
we
added
more
cases
that
were
suggested
by
security
expert.
Oh
you
sure
there
is
a
known
attack
on
compression
algorithms.
There
is
no
NAT
icon
using
fragmentation
protocols,
which
is
this
in
that
how'd.
D
Some
of
changes
were
editorial.
One
changed
suggested
by
Alicia
Cooper
was
the
change
of
reference
be
normative,
so
we
had
a
little
bit
of
discussion
with
ration
what
was
best,
but
we
implemented
that
change
made
it
normative.
There
was
one
remaining
mistake
about
the
RC
in
21,
one
nine
language
which,
which
was
the
use,
the
use
of
the
optional
keyword
capitalized,
which
had
not
done
properly.
We
fixed
the
reference
and
we.
E
D
E
B
E
Specifically,
we
were
looking
at
the
the
fragmentation
mode
to
send
this
to
use
cases,
a
text,
file
of
53,
bytes
and
small
image
of
356
bytes,
and
for
that
we
were
relying
on
the
on
the
implementation
that
Sandra
presented
last
time
from
University
of
Chile
off
I
shake,
which
was
very,
very
useful.
So
let
me
jump
to
the
next
one.
This
is
the
turkey
picture
that
we
were
trying
for
the
hackathon
as
Dominic
was
explaining.
In
our
case
we
were
using
the
the
five
shake
on
the
device.
E
This
was
of
a
PyCon
device
and
the
server
side.
We
were
running
it
on
the
Google
cloud,
using
the
tutorial
from
Marku
from
Google
cloud
platform
that
allowed
during
the
api's
to
the
cloud,
and
it
runs
pretty
well.
It
helped
us
fine-tune
and
find
out
a
few
interesting
things
that
we
want
to
work
on
the
draft,
the
architecture
of
the
code.
This
is
what
University
of
Chile
is
doing.
They
are
trying
to
do
it
modular
so
that
they
can
run
it
equally
on
laura1
or
seek
Foxx
reusing
as
much
as
possible
the
code.
E
In
this
case,
we
were
concentrating
on
the
icon
error
mode
for
the
fragmentation.
The
profile
that
we
were
trying,
of
course
was
sick
fox.
The
device
platform
was
vikon,
so
the
python
code
in
the
application
running
on
the
Google
Cloud
I-
guess,
if
you
have
questions,
feel
free
to
ask
Sandra
or
da
WA
but
order
Rodri.
What
about
the
details
of
the
software.
E
So
we
are
only
doing
that
at
the
end
of
every
window
so
that
we
can
allow
they
all
zero
or
they
all
want
to
come
back
and
for
the
for
the
last
all
one
because
of
the
uncertainty
on
on
when
it
can
arrive
in
the
in
the
window.
We
think
that
it
would
be
helpful
to
rely
on
the
on
the
sea.
Fox
sequence
number
that
comes
from
the
from
the
layer,
two
as
information,
and
then
we
can.
E
Sandra
was
very
keen
on
on
on
proposing
this,
and
hopefully
they
will
be
attending
the
next
IETF
meeting
that
sells.
So
the
vancouver
could
be
a
good
opportunity
to
and
we're
at
perfect
time
right
now
to
start
planning
on
how
we
can
work
out
different
combinations
of
of
the
of
the
at
least
three,
that
I
know,
implementations
and
the
two
radio
technologies
Julia.
H
E
Well,
in
fact,
this
is
the
this
is
information
that
you
always
get
from
layer
two
and
what
we
are
doing
is
in
case
the
information
is
being
used
to
feed
as
seek
fox
function.
Sorry,
a
sheikh
function.
This
the
sheikh
function
can
realign
not
only
on
the
payload
but
also
on
the
metadata
that
is
coming
from
from
layer
two
in
this
case,
the
sequence
number,
and
then
it
can
improve
the
behavior
of
sheikh
based
on
that
metadata.
But
I.
E
A
A
E
Okay,
yeah
well
in
this
case
I
think
we
keep
track
of
the
the
the
I'm
not
familiar
with
the
the
way
the
Laura
sequence
numbering
works
in
this
case
is
sequential
but
and
it's
per
per
device.
So
so
as
long
as
the
the
overall
engine
in
the
device
keeps
track
of
the
of
the
increasing
sequence
number
you
can
you
can
get
it
but
yeah.
Maybe
maybe
we
can
discuss
this
offline
and
see
if
we
can
solve
the
problem
for
bolt
and
one
shot.
Okay,
thanks.
B
So
probably
thanks
actually
for
that
question.
Probably
if
you
would
like
to
do
this
kind
of
optimization,
then
that
could
be
discussed
in
the
group
and
to
see
what
would
be
the
conditions
necessary
to
use
this
kind
of
optimization
or
you
know,
because
maybe
you
can
say
okay,
if
in
this
in
to
to
use
this
optimization,
you
only
need
to
do
fragmentation
until
the
session
is
complete,
for
example,
without
interleaving
yeah.
That
will
be
hard
so,
and
maybe
there
is
something
to
work
on
and
I
think
that's
very
interesting
to
have
this
work.
You
know.
B
Maybe
this
exchange
between
the
different
technology
documents,
maybe
have
a
small
draft
I'm,
not
sure
it
can,
but
maybe
both
of
the
drafts
can
specify
how
that
would
work.
Okay
or
have
like
one
common
document
that
says:
okay,
optimization
of
like
using
a
sequence
of
layer,
two
sequence
number
four
that
use,
and
then
you
can
have
like
a
kind
of
suit
conditions.
Okay,
what's
necessary
in
order
that
operation
to
be
to
be
made
and
get
leaders
sounds
like
a
good
thing
to
have.
A
And
just
wonder
if
it's
not
one
of
those
things
that
could
be
in
a
profile
or
something
if,
if
really,
we
can
agree
on
a
method
where
the
layer
to
a
number
is
useful,
then
it
could
be
something
that
goes
in
a
profiles.
It
can
be
enough
or
some
technologies
can
use
it,
and
some
not
but
yes,
I
mean
if
it's
doable
at
all,
we
need
to
to
the
queue
which
conditions
like
maybe
no
interleaving,
and
then
we
would
document
exactly
what
you
win.
B
B
And
the
second
thing
is,
if
you
can,
if
you
have
reviewed
the
data
model,
that
law
has
been
working
to
just
to
make
sure
that
all
the
things
that
are
there
actually
my
map
to
to
to
your
to
your
draft,
so
that
you
know,
we
know
that
the
data
model
corresponds
to
something
that
is
used
and
that
everything
that
you
need
is
also
in
the
data
model
took
it.
So.
F
F
Since
last
IDF
meeting,
we
had
to
draft
published
very
useful
feedback
from
the
walking
ribs,
so
we
will
discuss
at
rest
after
so
the
changes
in
version
3.
We
sank
so
Julian
proposition.
We
unify
the
overhead
size
because
we
had
a
proposition
with
one
by
to
read
and
to
buy
to
read
the
depending
of
the
size
of
the
packet
and
we
we
try
to
reduce
it
to
one
bite
on
me,
which
is
pretty
nice
on
embedded
devices
which
mean
that
the
the
cheeky
there
is
no
two
bytes
and
one
bytes
is
the.
F
Which
can
be
linked
to
the
law?
1F
port?
For
those
who
don't
know
law
and
technology?
Gf
bot
is
a
abide
embedded
in
the
protocol
which
allows
to
differentiate
application
traffic
like
the
port
on
TCP,
computer
or
UDP
computer.
So
would
ID
match
that
definition
and
we
we
squeeze
one
bytes
inside
we
did
it
the
ID
tag.
F
E
F
F
E
F
Think
we
still
have
some
welcome
that
to
do
and
as
she
Liam
contributed
a
lot
directly
in
the
document.
He
has
been
made
an
editor
and
we'll
discuss
that
in
version
4,
because
there
had
been
some
discussion
in
ITF
interim
so
who
should
be
editor,
which
would
be
hotel
and
as
we
almost
all
new
to
ATF
on
that
document,
at
least
on
current
editor.
We
do
everything.
F
F
F
F
C
E
F
Decide
even
that
has
been
fixed
to
I'd,
be
a
bit
because
at
lower
one
SF
10,
which
is
the
minimum
payload
you
can
have
in
u.s.,
you
can
only
have
11
bytes
of
payload,
so
there
is
no
room
to
expand
the
whole
idea
anymore,
but
we
don't
think
it's
an
issue.
If
you
have
any
comment
on
that,
we
would
be
able
to
discuss
it.
I
I
F
F
F
F
Okay,
so
there
is
the
Aloha
one
heater
inside
the
heater,
which
is
by
the
way,
not
aligned
on
that
diagram.
Sorry,
you
have
see
you
cannot.
You
have
something
dedicated
to
lower
one.
We
will
not
discuss
it
there.
You
can
have
some
option
hearings.
It's
example
is
four
bytes,
but
it
can
be
0
even
of
what
Lawrence
Tech
need
to
transmit
to
the
network
server.
Then
you
are
all
ID,
which
is
the
airport
one
bite,
and
you
have
your
Darwin
payload,
which
will
be
in
this
case
the
payload
with
two
bits
windows
who
we
have.
F
A
F
F
F
F
So
for
that
multicast
the
only
links
we
selected,
the
fragmentation,
mod
Noack,
because
we
can't
have
all
the
ICS
answering
to
at
the
same
time
it
will
be
a
nightmare
on
the
network.
So
we
have
no
real
ability
and
shunned
by
the
chick
layer.
It
would
be
up
to
the
year
per
layer
to
have
reliability,
whether
by
forward
error,
correction
or
whatever
other
Ito
that
can
be
used,
the
coop
definition
and
the
lower
one.
F
Only
who
for
class
a
device
are
out
of
scope
of
the
document,
because
each
network
several
different
way
to
the
crack
groups,
but
for
the
lower
one
meeting
points
for
class
II
devices,
there
is
already
a
specification
application
not
made
by
zero
Aryans
I.
Think
it's
not
an
issue
here
and
it
will
be
an
optional
feature.
F
F
F
F
Female
bird,
which
is
not
thank
you
made
by
Loen
specification.
The
relevant
recommendation
like
the
EMS
EMS,
is
a
standard
many
using
meters.
They
like
electricity
or
water
meters.
They
want
to
be
able
to
do
fumer,
glide
thanks
to
the
LMS
and
not
rely
on
law
1
meter.
So
we
need
Malika's
for
that,
because.
A
I
have
a
feeling
that
truly
the
amount
of
reliable
fragments
that
we
have
in
Sheikh
today
are
for
unicast,
but
I
also
have
the
feeling
that
those
those
mines
who
produced
what
we
already
have
a
capable
of
producing
as
well
reliable
multicast
mechanism
and
so
I,
was
wondering
if
we
could
consider
that
type
of
effort.
If
the
use
cases
are,
you
know
important
enough
for
this
community,
whether
we
could
consider
of
you
know,
start
thinking
about
a
reliable
multicast
for
basically
downstream
help.
You
want
and
they
see
some
smiles.
A
Ok,
so
please
come
to
them
to
the
mailing
list
and
let's
discuss
the
importance
of
the
use
cases
and
see
if
we
are
interested
in
having
a
new,
real,
reliable
multicast
fragmentation,
because
sending
out
those
fragments,
if
you
have
many
fragments
and
not
having
any
reliability,
doesn't
seem
like
a
good
idea
to
me
each
for
each
destination.
You
will
use,
maybe
one
fragment
not
the
same
one
and
then
you're
stuck
for
everybody.
A
H
A
B
E
A
A
F
Thank
you
for
the
a
better
than
slide.
You
see
that
there
is
no
motor
guessing
so
on
the
IDE.
We
just
put
that
under
the
new
draft,
which
will
be
might
be
graph
5,
it
is
recommended
to
create
to
create
interface
and
identifier
following
specification.
Rsv
is
72,
970,
sorry
and
Ric
80s
64,
the
other
author
discussing,
should
be
removed.
84,
we
add
85
86
t43.
So
if
you
have
any
input
for
us
on
that,
we
would
be
more
than
happy
to
take
it
because
we
don't
know
really
how
to
to
manage
it.
F
Then
the
10
for
the
last
five
will
be
the
IDS.
There
is
some
typos
left
and
document
cleanup
to
do.
There
is
a
new
chapter
to
add
on
the
bidirectionality
of
law
and
Chico
palawan,
like
Dominic
explained,
we
might
need
to
find
a
shepherd
one
day
or
another.
So
if
there
is
any
anyone
who's
feeling
that
might
fit,
we
would
be
more
than
happy
to
to
accept
Connie
letter
and
we
would
like
some
feedback
before,
because
we
hope
to
put
the
document
in
last
call
in
draft
five
or
so.
A
One
comment
about
item:
one
I
think
that
we
need
to
include
those
that
are
in
in
this
stuck
in
discussion,
so
we
can
actually
start
a
thread
on
the
mailing
list
and
invite
Dave.
So
you
should
start
this
right.
I
will
copy
day,
for
I
can't
even
start
it
myself
if
you
prefer,
and
so
we
will
talk
about
the
IAD
selection.
A
Yes,
that's
that's
a
very
good
point,
because,
obviously
you
want
something
stable
because
you're
compressing
it
so
64
is
good
and
then
privacy
I,
don't
know
so
65
we
have
to
look
at,
but
basically
get
recommendation
from
Dave
would
be
certainly
interesting.
So
let's
include
him
in
the
discussion
in
the
mailing
list.
A
B
I
G
I
I
Okay,
so
during
last
year,
if
we
move
from
v9
to
v
11
and
we
make
some
editorial
change
to
comply
with
viz
format,
so
to
be
so,
the
dreyfus
will
is
compatible
with
bc.
P
14.
We
also
modified
the
abstract
to
be
more
precise
on
what
we
are
doing
and
we
also
changed
reference
because
ask
or
move
from
draft
to
to
RFC,
so
it
has
been
submitted
for
edgy
for
publication,
and
now
we
are
expecting
a
return
from
edgy
on
on
the
draft.
B
Well,
okay,
so
just
when
we
switch
so
just
upload,
it
also
the
datum,
the
yang
data
model.
So
what
you
see
here,
you're
also
going
to
find
it
on
the
under
data
tracker.
So
before
we
switch
to
that
a
couple
of
questions
about
your
of
the
coop
draft,
so
it
is
so
Pascal
is
the
shepherd
the
reviewers
so
next
step
on
on
on
this
one.
It
is
then
going
to
be
reviewed
by
the
80s
and.
C
I
Okay,
yeah
so
go
back
to
the
data
model,
so,
as
I
said
just
before
now,
as
the
draft
has
expired,
but
we
will
publish
soon
a
new
version,
and
so
it
was
not
useful
just
to
renew
the
number
but
to
work
during
that
time.
I
walk
a
little
bit
more
on
the
young
model
for
for
chic,
so
the
idea
is
to
reproduce
what
we
have
in
the
draft.
Currently
she
grasped
it's
a
table
that
has
no
no
real
structure.
I
It's
just
an
explanation
of
what
is
a
rule,
but
it
doesn't
define
formally
word
out
to
write
it.
So
here
you
have
young
model
that
describe
what
is
a
rule,
so
you
have
a
ridy
and
then
you
can
have
ever
a
fragmentation,
information
or
compression
information
and
compression
information
is
a
table
with
fidelity
and
parish
operator
on
it,
and
it's
described
on
on
this
model.
So
it's
just
a
starting
point.
I
Now
we
have
to
work
more
on
it
to
improve
it
and
to
make
it
really
compatible
with
all
the
young,
young
spirit,
young
spirit
but
I
think
it's
in
in
a
good
way
and
of
course,
via
Catherine
L
palace.
Also
to
understand
what
we
need
to
put
in
the
rule,
especially
for
fragmentation
so
for
compression,
is
quite
clear,
because
the
draft
explained
a
lot
of
a
lot
of
things.
So
so
now
what
I
say?
I
We
need
to
have
some
input
from
Sheikh
implementers
to
see
what
you
really
need
really
need
to
put
in
young
medellÃn
for
young
community
for
compatibility
with
wrong
model.
So,
as
I
say,
I
will
publish
a
new
version
with
what
we
have
done
during
the
past
weeks
month
and
then
it
will
be
a
starting
point
to
discuss
on
this
model.
And
so
my
suggestion
will
be
to
put
that
item
in
the
next
entry
meeting.
We
will
have
and
make
all
the
group
work
on
on
this.
B
So
that
there
is
one
point
that's
really
important
here
is
for
it's,
especially
for
the
for
the,
for
the
further
technology
drafts
is
to
talk
to
to
the
hall
and
and
Anna
may
be
one
of
the
next
interims
to
make
sure
that
you
understand
that
you
agree
with
this
structure.
So
once
we
agree
in
the
group
that
it's
good
for
us,
then
we
can
go
to
the
yang
doctors
and
they
can
say
yeah.
That's
like
the
way
the
yang
should
be
formatted.
B
E
D
D
D
So
the
idea
is
to
do
the
usual
stuff
that
you'd
expect
with
an
IP
network.
We
were
saying
with
shake
allows
us
to
bring
IP
to
these
IOT
networks,
and
so,
if
you
bring
IP,
you
bring
a
set
of
expectations
from
the
engineers
technicians
that,
since
its
IP,
we
can
do
pings
and
trace
routes
and
to
get
ICMP
our
messages.
For
example,
when
a
destination
is
not
reachable,
and
so
this
draft
is
first
a
discussion
on
what
people
expect
with
an
IP
network
and
which
is
realistic
to
implement
with
lg1
in
the
IP
enabled
networks.
D
So,
firstly
needs
to
be
a
useless
discussion.
What
we
want
to
do,
what
kind
of
messages
do
we
want
to
relay
on
the
actual
human
network?
What
kind
of
responses
or
messages
we
can
proxy
at
the
call
before
we
get
on
to
the
constraint
length,
the
yl,
t1
link
and
and
and
then
we'll
work
on,
applying
shake
to
achieve
that
and,
namely
you
can
do
header
compression
pretty
easy
to
had
a
compression
on
icmpv6
messages,
starting
from
the
simple
ones
in
our
three
four
four,
four
one,
the
fourth
over
three.
D
D
So
basically,
we
suddenly
expect
a
few
things
to
happen.
Like
a
host
on
the
internet,
pinging
an
IOT
device
that
is
IP
enabled
for
shakey,
we
expected
to
get
an
echo
reply
to
its
equal
request
messages.
We
expect
this
device
on
the
Internet
to
receive
an
ipv6
response,
and
now
the
question
is:
shall
those
be
propagated
all
the
way
down
to
the
device
and
the
response
be
probably
get
back
with
check
compression
or
said
it
shall
be
proxied
at
the
echo
here,
and
we
have
to
go
through
that
discussion.
D
A
Okay,
thank
you
so
much
them
unique.
We
have
no
question
so
what
we'd
like
to
do
is,
since
we
have
a
little
bit
of
time,
is
we'd
like
to
bring
up
the
chat,
Oh
text
from
the
fine-tuned
it
based
on
what
we
just
discussed
so
the
two
discussions.
The
two
changes
that
may
arise
in
the
Charter
for
one
is
the
one
that
we
presented
earlier,
that
we
won't
item
one
to
be
about
maintenance,
so
basically
any
change
that
would
be
required
in
the
Schick
mechanisms
for
new
protocol
for
new
above
over
shake.
A
So
that's
one
change
and
the
other
change
that
we
just
discussed
today
is
to
accept
new
work
on
reliable
multicast,
which
means
I,
guess
mostly
for
you
know
downstream
multicast.
So
there
is
this
packet
for
number
of
nodes
and
some
notes
missed
some
fragments
and
we
want
to
be
able
to
recall
those
fragments.
So
basically,
what
we
would
like
to
do
now
is
just
share
an
editor
session
and
agree
with
you
guys
on
the
tags
that
we
want
to
see
there
since
we
have
suresh
in
the
room.
A
A
C
J
C
C
Guess,
like
we
have
already
coop
right
right
so
I
you
can
just
leave
it
as
as,
if
you
want,
you
know
how
to
put
a
just
say
or
for
upper
layer
protocols
over
chicken
I
can
explain
if
somebody
asks
like
it's
like
other
than
quad,
since
we
did
it.
I
thought
like
you'll,
just
avoid
a
question,
but
it's
fine.
It's
not
a
big
deal
so.
C
D
A
D
A
A
I
A
Using
the
radio
to
multicast,
we
don't
take
every
try,
it
so
I
mean
it's
kind
of
already
there
will
you
have
it
in
the
loja
document
issue
like
so
so,
maybe
recoverable
or
something.
So
what
really
needed
is
something
to
recover
some
missing
fragments
right,
but
but
in
a
multicast
fashion
you
know
the.
F
F
A
F
A
A
F
E
H
C
I
think
you've
got
longer,
but
it
didn't
address
like
Lana's
point
I'd
like
because
Lana's
point
still
remains,
it's
not
reliable.
So
so
the
intent
is
to
have
some
kind
of
acknowledged
mechanism.
Is
that
what
you're
looking
for
like?
If
you
have
some
idea
of
like
you,
know
how
this
is
gonna
look
like
we.
A
C
B
C
This
long,
but
at
least
address
this
is
fine
right,
like
so
that's
kind
of
our
suggesting
I,
there's
no
easy
formulation
for
this
right,
because
it's
not
reliable,
but
we
already
have
multicast
delivery.
So
it's
a
very
small
niche
right
but
you're
trying
to
fill
because
at
the
end
end
result
it's
not
going
to
be
fully
reliable
either
right.
C
But
it's
long
so
like
I'm,
just
saying
it,
the
the
problem
areas
niche
so
you're,
not
gonna,
have
like
a
easy
statement
of
this
right.
So
I
think,
like
you
know,
just
describe
what
you
wanna
do
just
say
like
try
to
improve
the
reliability
of
multicast
fragment
delivery.
That's
that's
really.
What
you're
trying
to.
A
B
I
A
I
I
J
E
J
That
you
got
it,
whereas
reliable
is,
can
include
statistical
reliability.
Now,
having
just
said
that,
we're
not
trying
to
achieve
reliable
delivery
of
fragments
I
will
now
reverse
myself
and
say
that
one
way
to
achieve
reliable
delivery
of
data
that
is
fragmented
is
to
use
a
type
2
hybrid
air
Q
FEC
such
as
is
standardized
in
RFC
57:40
at
the
transport
layer.
B
G
B
G
B
A
I'm
sorry,
but
I've
not
seen
enough
activity
right
now
to
feel
confident
that
the
group
wants
it,
so
you
can
post
it
as
a
response
who
will
post
that
we
said
a
the
mailing
list.
We
are
there.
We
are
desert
geo
discussion
kind
of
know
and
if
we
see
enough
noise
on
the
on
the
mailing
list
to
support
that,
we
also
include
out,
you
will
propose
to
Suresh
I've,
not
seen
so
far.
That
I
would
I
would
not
feel
safe
right
now.
I'm,
sorry,
yeah.
B
Maybe
11.2
to
add
on
this
one
is
I
feel
that,
with
this
five
points,
we'll
have
a
lot
of
work
for
the
next
couple
of
months.
I
I
did
like
your
your
work.
So
probably,
if
you
continue,
you
know
developing
the
work
we'll
be
able
to
include
it
next
time
when
we,
if
we
do
a
smaller
charter,
you
know
that
I
think
that
can
be
fairly
easy
to
achieve.
Compared
to
you
know
the
points
that
we
have
here
so
please
continue
the
work.