►
From YouTube: IETF99-LPWAN-20170721-0930
Description
LPWAN meeting session at IETF99
2017/07/21 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
Please
sit
so
this
is
the
agenda
page
from
data
tracker
and
it's
getting
better
and
better
and
better
so
we'll
be
actually
using
it
as
the
starting
page
for
what
would
be
presenting
to
you.
So
if
you're
looking
for
the
presentation,
these
are
fat
etc
will
show
you
as
we
do
it
where
the
links
are,
so
you
can't
activate
to
what
we
are
doing
here,
so
the
the
all
the
material
will
be
showing
is
on
this
button
here.
B
It's
also
available
on
the
cool
applications
that
you
can
download
for
from
your
preferred
store
on
the
web,
but
this
is
really
a
cool
place
to
get
it.
You
get
all
the
those
two
links
here
will
give
you
all
the
documents
we'll
be
talking
about
today
in
video
forms
or
the
Welcome
documents
and
personal
submissions,
and
last
but
not
least,
here
on
this
button
here
you
will
get
the
link
to
the
ISA
pad
clicking
it.
B
So
please
participate
to
the
ether
pad.
This
is
where
we
are
taking
our
minutes.
This
is
also
a
very
useful
page
if
you
did
not
get
everything
that
was
being
said.
If
you
want
to
read
it
later,
please
just
open
this
window.
If
you
think
that
the
minutes
we
are
not
taken
properly,
in
particular,
for
what
you
just
said,
please
go
ahead
and
modify
the
text
live
on
the
ether
pad.
That's
a
very,
very
useful
tool
for
all
of
us
in
this
room
and.
B
C
B
From
this
on
on
previous
meetings,
okay-
and
with
this,
let
us
start
with
the
a
Shanda
bashing
and
all
the
nice
things
that
were
used
today.
So
this
is
the
lt1
working
group,
codeshares
Alexander
and
myself
and
we've
got
a
brand
new,
not
well
I,
decide
shelf.
So,
if
you're
not
used
to
the
not
well,
if
you
have
not
read
the
previous
RFC's
which
provide
the
policies
for
the
ITF,
this
is
a
nice
occasion
to
go
ahead
and
read
them
because
they
are
brand
new
and
shining.
B
This
is
my
HF
meeting.
Minutes
will
be
taken
up
fully
by
many
many
people
using
the
fine
etherpad
link
that
I
just
showed
you.
The
meeting
is,
is
propagated
on
mythical.
You
can
join
the
mythical
from
this
room
or
from
anywhere
else
and
I'm,
giving
again
the
pointer
to
the
ether
pad
will
be
distributing
the
blue
sheets.
In
a
few
minutes
we
are
used
to
seeing
people
come
late
and
I
don't
see
that
today
is
an
exception
to
the
role.
B
So
we
just
delay
the
so
we
not
have
multiple
ways
of
blue
sheets
we
next,
so
we
are
looking
for
minute
takers.
So
do
we
have
volunteers,
I
see
Dominique
Dalio,
so
that
kind
of
cool.
Do
we
have
somebody
for
Jabbar
or
mythical
giggle,
so
fine?
Okay,
so
we
are
just
doing
great,
so
I
just
showed
you
well
I'm,
picking
the
the
meeting
material
life
so
I'll
be
going
back
to
that
page
yeah,
that's
a
good
place
to
get
it.
So,
yes,
our
Chanda.
B
We
have
two
pages
agenda,
it's
quite
flow,
but
we
should
be
okay,
so
we'll
be
Dominique
will
be
presenting
us
the
news
from
the
Agathon.
So
there
are
incredible
stuff
which
one
and
we
are
glad
to
show
that
then
we'll
talk
about
the
results
of
the
World
Cup
last
call
on
the
other
of
you
document
and
Steven.
Is
there
with
us
to
present
this?
B
Then
there
is
two
set
of
slides
for
one
or
actually
two
documents,
but
the
set
of
slides
don't
want
rematch
documents,
so
we'll
be
talking
about
the
static
data
compression
document
which
has
a
fragmentation
chart
and
that
we'll
be
presenting
to
us
by
Calais
and
then
and
on
l'homme,
we'll
be
talking
about
the
Sheik
compression
and
that
compression
actually
spreads
to
documents
right
now,
the
the
sheet
for
ipv6
a
UDP
and
then
the
coop
piece.
Maybe
we'll
discuss
at
some
point.
B
We'll
have
a
little
bit
of
time
for
young
for
Sheikh
and
no
harm
will
be
showing
that
to
us
and
then
we'll
have
quite
some
time
to
discuss
the
the
reach
out
ring.
We
we,
we
left
the
last
five
ten
minutes
for
news
from
I
Tripoli
by
Bob
Bob.
If
you
can
hear
us
so
I
was
at
the
edge
of
last
week
as
well.
There
are
two
interesting
pieces
that
two
pieces,
which
are
direct
direct
interest
for
us.
B
There
is
the
IG
LP
one
which
basically
met
every
day
last
week,
and
there
is
the
15
for
K
effort,
which
is
also
an
ie
I
Triple
E,
designed
t1
technology
and
so
I
hope.
Bob
focuses
on
those,
but
will
give
us
news
from
the
HIV
I
would
strongly
encourage
and
I
see
that
Wonka
Alice
is
with
us
to
to
extend
this
idea
of
giving
us
giving
us
like
a
short
news
from
the
world
about
things
which
happening
in
other
body
like
aged
80
on.
B
So
if
you
could
think
in
further
meeting
to
come
and
present
like
two
three
five
minutes
on
what's
what's
has
been
happening
in
the
last
quarter
in
LTM,
Aloha
one
and
the
IOT
any
of
those
a
small
slots
will
be
would
be
very
good
so
that
we
get
news
from
the
world.
So
this
time
study,
I
trip
point
and
with
the
hotel
to
the
airport,
because
I'll
be.
B
D
This
is
a
short
refresher
of
our
Charter
and
our
milestones,
so
we
were
formed
in
almost
less
than
a
year
ago
with
two
main
charter
items.
So
we
have
the
baseline
technology
description
and
overview
document
and
we'll
be
talking
about
this
in
the
beginning
of
this
meeting
and
then
the
technology
drafts
the
and
then
the
the
drafts
that
are
actually
dealing
with
the
compression
and
fragmentation.
So
in
our
compact,
our
milestones,
so
we
have
most
of
them,
are
we
got
them
on
time?
D
So
we
had
a
design
team
that
met
and
that
really
accelerated
the
things
and
before
the
last
ITF
everything
most
most
of
the
stuff
were
clear
out
and
since
then
all
the
work
has
been
happening
on
the
mailing
list
and
and
it's
very
very
open.
So
here
is
the
the
deadlines
that
that
that
we
had
initially
so
with
the
overview
document
ready
by
April,
then
the
shake
for
IP
UDP
by
May
and
co-op
by
June.
D
So
I
would
like
to
have
a
special
thanks
to
the
to
the
whole,
to
the
up
to
the
group
and
to
everyone
that
has
participated,
because
we
had
a
very,
very,
very
active
work
during
the
past
three
months.
So
we
had
six
interim
meetings
and
I
would
really
like
to
thank
everyone.
So
marvelous
marvelous
work,
so
we
had
actually
we
could
advance
really
really
rapidly.
There
are
a
lot
of
a
lot
of
things
that
were
done
so
the
LP
on
overview
document.
D
We
started
working
with
last
call
in
in
June
and
since
then
there
were
a
couple
of
minor
commands.
We
were,
they
have
been
addressed
and
we
will
see
we'll
have
the
presentation
from
from
Steven
that
will
give
you
that
will
give
us
the
results
of
this,
and
we
will
be
closing
the
last
call.
Reversing
the
shake
IP
UDP
document
is
a
classic
really
really
well
and
in
the
very
very
near
future,
we'll
go
for
with.
D
So
that's
where
we
are
with
with
our
Charter
and
with
our
action
points
and
I'd
like
to
give
you
just
one
minute
overview
of
a
report
of
an
a
meeting
that
happened
yesterday.
That's
called
the
yang
of
things
and
this
meeting
actually
is
the
place
where
the
constrained
world
meets
the
management
world.
So
it
was,
we
had,
it
was
a
side
meeting.
The
room
was
full
a
lot
of
interesting
discussions
and
the
takeaway
for
this
is
actually
that
for
the
next
IDF
will
have
working
implementation
and
will
have
all
that
is
necessary
for
the
car.
D
My
protocol
and,
as
you
know,
the
common
protocol
is
the
one
that
we'll
be
using
that
we'll
be
using
for
that.
Maybe
we
may
be
using
for
configuring
the
compression
contexts.
So
that's
the
thing
that
will
come
right
now
we
have
the
we
are.
We
have
the
compression
mechanism,
but
we
need
a
way
to
go
to
configure
the
contexts.
So
it
is
a
work
to
look
for
and
I
think
it
will
be
that
we
are
right
on
time
and
we
have
all
that
is
necessary.
So,
with
this
Pascal
we
can
shoot
is.
B
That
so,
with
this,
we'll
move
to
the
first
presentation
for
this
meeting
and
our
first
presentation
is
the
LP
one
overview.
So,
let's
see
where
we
are
with
the
LP
1
overview,
so
we
have
done.
We
have
completed.
Let's
go
on
July
4
well
done
for
this
working
group,
not
for
the
80s,
but
we've
we've
complete
completed
the
working
group
last
call
on
the
4th
of
July,
so
document
is
now
visually
independent
and
alexander
panov.
B
B
E
D
D
F
Good
morning,
so
at
the
academy,
just
before
this
IGF
week,
we
had
an
activity
on
cheek
and
it
was
actually
two
activities
going
on.
When
was
the
interrupt
testing
between
various
implementations
and
the
other
one
was
actually
hacking
improving
what
we
had
already
had,
so
the
companies
or
entities
represented
are
listed
here
with
myself.
Apparently
yes,
so
before
the
hackathon,
the
teams
that
came
had
the
foreign
assets
AMD
Atlantic,
previously
known
as
telecom
Britain
in
France,
had
an
end
device.
Implementation
of
shaken
in
network
side
implementation
in
JavaScript
and
rules
set
up
for
Laura
transmission.
F
The
Interop
mostly
happen
on
Saturday
and
then
had
empty
at
an
taken
at
Leo
face
each
other
with
the
opposite.
Implementations
and
device
versus
network
in
both
sites
and
results
will
be
shown
at
the
last
slide,
and
so
that
was
the
interrupt
part
of
it
and
then
the
hacking
part
of
that
was
emt
Atlantic.
F
Adding
the
rules
and
testing
on
SiC
Fox
network
on
their
own
end
device
and
network
implementation
and
myself
wrapping
some
Python
code
from
EMP
Atlantic
end
device,
I'd
put
it
on
the
network
side
and
to
write
a
quick
decompressor
that
would
be
able
to
invent
co-op,
UDP
ipv6
messages
based
on
legacy
frames
being
transmitted
by
my
row.
One
device.
F
F
One
issue
that
was
discovered
is
how
to
manage
the
variable
fields
that
happened,
to
have
zero
length
and
go
up
as
in
a
content,
has
an
interpretation
of
zero
length
as
representing
a
zero
value,
and
she
wanted
her
wants
to
be
able
to
apply
zero
length
fields
to
non-existent
fields
so
that
we
can
reuse
the
same
rule
number
four
frames
which
have
some
fields
present
in
some
non
present.
So
here
we
have.
F
We
had
discussion
on
how
to
interpret
that,
and
one
has
to
agree
on
how
this
works
on
coop,
especially
because
of
this
zero
length.
Interpretation
in
coop
before
contents,
and
eventually
emt
atlantic,
provides
its
implementation
open
source
on
github.
So
this
can
be
used
as
we
can
reference
point
for
any
anybody
wanting
to
implement
that
and
I
think
I'm
done.
B
G
B
B
H
H
There
we
go
next
well,
okay,
okay,
so
so
between
four
and
five
there
was
just
Mesa
Khalid,
minor
and
text
weeks,
mostly
yeah.
It
was
just
minor
editorials
from
oh
five,
two,
oh
six,
it
had
I
got
the
text
to
charity
and
posted
zero.
Six
they're
like
couple
minutes
ago,
have
a
look
at
the
dates.
I
guess
there
was
also
a
bit
of
additional
text
about
sick
that
I
added
in
with
one
Mike
Harris
today.
H
Well,
no
can
we
do
couple
days
ago
and
and
I
there
was
a
minor
tweak
about
the
Laura
text
was
otherwise
it
said.
I
think
we
may
still
be
waiting
on
some
references
from
Charlie's
mail
in
his
new
texts.
So
I'd
say
you
have
a
look
at
it
for
a
couple
days.
Maybe
we'll
add
a
new
version
get
a
couple
of
references,
but
basically
that's
it
so
next
slide,
oh
yeah
I
have
a
chance
a
biggest
lighter.
H
So,
basically
yeah,
so
we
have
now
have
a
zero
six.
So
I
give
a
few
days.
Society
check
it
and
I
guess
when
the
Shepherd's
doing
the
Shepherd
write-up
that'll
happen
anyway,
there's
no
other
changes.
I
think
just
declare
victory
and
sure
enough.
So
unless
somebody
has
a
thing
to
say
it's
like
a
perfect.
B
Steven,
thank
you
so
much
I
mean
everybody,
and
at
special
special
thanks
for
Charlie
felt
for
the
the
extra
thought
of
to
make
to
make
our
dates,
and
so
yes,
I
like
see
the
shepherd.
He
will
be
righting
the
ship
out
right
up
very,
very
soon
and
and
Suresh
will
be
pushing
this
to
the
SG
and
with
this
is
the
fragmentation.
I
Okay,
hello,
everyone
I'm
going
to
present
a
fragmentation
part
of
the
cheek
document.
So,
first
of
all,
let's
take
a
look
at
the
status
of
the
document.
So
since
Chicago
the
the
draft
was
updated
several
times,
revisions
had
been
0,
3,
0,
4
and
0
5
and
specifically,
on
the
fragmentation
part.
We
received
two
detailed
reviews,
one
by
ego
on
version,
zero,
3
and
another
one
by
Dominic
on
version
0
5.
I
So
thanks
to
both
for
the
very
helpful
reviews
and
also
there's
been
a
lot
of
discussion
and
input
received
on
in
working
group
in
dreams
on
the
list
or
also
offline.
So
thanks
to
everyone
who
has
made
comments
and
helpful
contributions,
so
on
the
current
status,
the
last
revision
published
is
0
5,
although
there
are
a
number
of
updates
already
prepared
which
are
ready
on
github
in
the
working
version
of
the
document.
Those
updates
have
been
prompted
by
Dominic's
review
and
we
could
say
that
overall,
fragmentation
is
fairly
stable.
I
So
let's
have
a
quick
summary
of
the
main
updates.
Actually
since
Chicago
the
version
present
that
there
was
in
0.
So,
first
of
all,
we
have
that
packet
mode
has
been
removed
from
the
document
we
found
that
there
were
a
few
things
that
were
not
well
supported.
Few
issues
there,
and
actually
there
were
some
solutions
proposed,
so
we
can
still
continue
working
in
packet
mode.
However,
that
should
happen
on
a
different
document.
I
So,
as
a
result,
in
this
current
document,
what
we
have
is
three
fragment
delivery,
reliability
options
first
is
Noack,
second,
is
window
mode,
icon,
arrow
and
the
third
one
is
window
mode
always,
then,
we
have
also
added
the
possibility
to
support
multiple
windows
sizes,
so
imagine
that,
for
example,
a
node
needs
to
transmit
a
very
large
ipv6
Datagram,
which
requires
a
large
number
of
fragments
to
be
carried.
Then
one
option
is
to
use
a
large
window
size
in
order
to
minimize
as
much
as
possible.
I
The
acknowledgment
overhead,
however,
may
be
the
same
note-
may
need
to
sometimes
send
a
smaller
packet
that
maybe
it
just
requires
a
few
say
two
or
three
fragments
to
be
carried.
So
in
that
case
it
may
be
good
to
have
to
use,
in
that
case
a
smaller
window
size,
because
then
that
leads
to
using
a
smaller
bitmap.
I
So
this
kind
of
optimization
is
now
possible
by
means
of
having
a
special
Real
ID
for
each
specific
window,
size
that's
being
used,
then
we
have
also
added
the
concept
of
a
highest
CFN
in
the
window
that
can
be
lower
than
2
to
the
N
minus
2.
This
is
equivalent
to
having
maximum
window
size,
which
can
be
lower
than
2
to
the
N.
Minus
1
recall.
I
That
n
is
the
size
of
the
CFM
expressed
in
in
bits,
as
you
can
see
in
the
fragmentation
header,
which
is
shown
on
the
slide,
and
this
is
useful,
especially
in
scenarios
where
there
may
be
constraints
on
the
available
space
for
the
bitmap.
So
the
idea
here
is
to
be
able
to
tailor
well
to
exploit
the
bitmap
space
as
much
as
possible
and
tailor
the
window
size
to
that
available,
bitmap
space.
So,
for
example,
imagine
there
are
only
24
bits
for
the
bitmap.
I
Then
we
can
use
a
window
size
of
24
fragments
that
would
mean
high
C
of
n
would
be
23
and
would
be
set
to
5
and
sender
and
receiver
would
be
aware
of
this.
So
there
would
not
be
issues,
so
this
is
optimized
compared
with
the
previous
approaches
of
the
document
where,
if
you
remember,
we
didn't
have
this
flexibility,
so
the
best
option
in
terms
of
low
overhead
in
the
past
would
have
been
to
set
N
to
4,
have
a
maximum
window
size
of
15.
So
there
would
be
one
acknowledgement,
every
15
fragments.
I
So
now
we
have
this
additional
flexibility
and
we
can
have
one
acknowledgement:
every
24,
fragments.
Okay,
then
we
have
also
added
two
fragmentation:
header
field:
one
is
the
W
bit.
This
is
a
one
bit
field
which
carries
the
same
value
for
all,
fragments
that
correspond
to
the
same
window.
This
is
necessary
to
avoid
ambiguity
at
the
receiver
side,
because
losses
can
happen,
so
there
may
be
situations
where
the
receiver
might
not
know
clearly
whether
a
fragment
corresponds
to
the
current
window,
or
maybe
the
previous
one,
and
also
for
the
same
reasons.
I
So
the
purpose
here
is
to
allow
interleaving,
fragmented,
ipv6,
Datagram
transmissions
and,
if
used
then,
the
d
tag
field
is
also
has
to
be
also
included
in
acknowledgment,
so
that
the
fragment
sender
knows
what
is
being
acknowledged
to
which
Datagram
the
acknowledgement
corresponds.
We
have
also
added
timers,
so
in
window
mode,
a
cone
error.
We
have
the
timer
call
while
the
economy
timer,
which
is
started.
It
runs
on
the
receiver
side.
I
It
started
when
the
receiver
gets
the
first
fragment
of
an
ipv6
Datagram,
and
then
it
is
reset
every
time
that
the
new
fragment
is
received
and
the
receiver,
and
if
the
timer
expires,
that
it
means
that
at
least
the
last
fragment
of
the
window
has
been
lost,
so
recall
that
in
a
canary
we
have
nack
oriented
behavior.
So
then
the
receiver
would
send
an
acknowledgment
to
report
what
has
been
received
and
not
received
and
the
timer
would
be
reset
and
restarted,
and
the
receiver
would
wait
for
fragment
retries,
so
in
ACK,
always
in
window
mode.
I
Always
we
have
the
icarus
timer
the
fragment
sender
after
transmitting
the
last
fragment
of
a
window
will
start
this
timer
and
upon
expiration
of
the
timer.
If
the
acknowledgement
from
the
receiver
hasn't
been
received
by
the
fragment
sender,
then
the
sender
will
return
will
send
again
the
last
fragment
that
had
been
sent
and
will
restart
again
the
timer.
I
So
we
also
have
the
some
parameters
that
control,
which
is
the
maximum
number
of
retransmission
rounds,
that
there
will
be
so
in
a
canary
there's
one
parameter
which
determines
the
maximum
number
of
acknowledgments
per
window.
That
a
fragment
receiver
is
going
to
to
send.
This
is
the
first
parameter,
as
you
can
see,
then
in
AK
always
there
are
two
parameters.
First,
one
is
max
at
requests.
I
In
addition,
we
have
added
the
abort
message,
which
is
a
special
message
which
can
be
sent
by
a
fragment,
sender
or
fragment
receiver
in
order
to
abort
all
ongoing,
fragmented
ipv6
Datagram
transmissions,
and
this
special
message
has
also
some
corresponding
special
role
ID
to
signal
it.
And
finally,
we
have
added
a
particular
section
on
downlink
fragment
transmission,
so
this
is
motivated
by
the
fact
that
in
some
in
layer,
2
technologies
sending
a
downlink
data
unit
is
only
possible
right
after
previous
applicant
transmission.
I
So
then,
as
I
explained,
the
last
version
published
e05.
However,
there
are
a
number
of
proposals
already
prepared
on
github
and
there
are
actually
a
number
of
updates.
However,
some
of
them
are
rather
minor,
so
this
is
a
summary
of
the
main
ones,
possibly
so,
let's
go
through
them.
First
one
is
important
for
terminology.
I
C
I
Just
to
avoid
this
possible
ambiguity,
dominic
suggested
to
modify
the
term,
so
the
proposed
update
is
fragment
compressed
number.
So
unless
there
are
objections,
this
would
be
like
the
new
term
used
the
new
acronym,
then
the
highest
FCN
in
the
window
is
actually
a
constant,
so
this
was
not
so
apparent
in
the
previous
version
of
the
document.
I
So
now,
in
the
proposed
that
days,
this
will
be
more
explicit
and
also
there
will
be
a
notation,
specific
notation
for
this,
which
is
proposed
to
be
max
Wynn,
FCN
and
also
there
is
now
an
assumption
that
would
be
made
more
explicit.
Also,
this
is
for
window
mode
akan
era,
and
it
relates
with
the
sender
behavior.
So
the
idea
here
would
be
to
explicitly
explain
that
an
assumption
is
that
the
the
wait
time
for
an
acknowledgment
in
aachen
era
has
to
be
actually
smaller
than
the
time
required
to
transmit
a
complete
window.
I
I
I
He
was
suggesting
that
maybe
we
might
want
to
define
the
use
of
Max
frag
retrace
this
parameter,
which
is
currently
only
defined
for
AK.
Always
it
would
be
to
consider
whether
this
might
be
useful
in
akan
error
also.
So
the
reason
why
this
is
currently
not
yet
considered
in
aachen
error
is
that
a
fragment
receiver
will
send
an
acknowledgment
by
doing
that,
it
will
consume
some
resources
which
may
be
expensive,
and
that
is
done
with
the
expectation
that
then
there
will
be
fragment
retrace
in
response.
I
However,
Dominic
pointed
out
that
maybe
this
could
also
be
used
as
an
attack,
so,
for
example,
it
might
be
possible
to
send
this
kind
of
ACK
to
some
device
and
make
it
believe
that
it
has
to
resend
some
fragments,
and
this
might
be
a
way
to
maybe
deplete
that
battery
of
the
attacked
device.
So
then
there
might
be
different
options
on
how
to
proceed
with
this.
So
there
are
these
three
questions:
a
B
and
C
here.
So
first
is
okay.
I
Should
we
then
define
use
of
Max
frag
retrace
also
in
aachen
era,
then,
okay,
if
we
define
it
for
a
chimera,
should
we
explicitly
say
that
maybe
we
should
allow
up
to
an
infinite
number
of
retries
and
maybe
defer
to
future
shikoku
documents.
What
has
to
be
done
here
or
it
is
something
that
should
rather
be
handled
at
an
implementation
level
and
not
really
be
explicitly
specified
here.
So
what
do
you
think.
B
Piscotty
our
individual
contributor
here
I,
would
certainly
want
to
see
this
discussion
on
the
mailing
list.
I
would
like
to
see
tickets
from
now
on
for
for
things
like
that,
because
we
are
nearing
completion
and
we
need
to
track
those
things
and
again
as
an
injured,
contributor,
I,
don't
I,
don't
think
it
hurts
to
have
the
variable
and
recommend
it
to
be.
One
I
certainly
want
to
see
this
discussion
in
the
Security
section.
B
D
K
D
So
so
that's
it
and
okay.
So
yes
any!
Maybe
this
is
the
final
question.
Has
anyone
started
actually
implementing
the
full
little
shake
document?
So
we
know
that
there
are
the
compression
part
that
have
been
already
shown
for
the
moment
and
now,
with
this
updated
version
of
the
fragmentation
who
has
already
started
actually
implementing
this.
D
So
there's
there
are
two
implementations
there
Diego
and
Diego
auntie
viola.
So
this
is
one
of
the
things
that
I
would
really
like
to
see
before
we
actually
go
into.
You
know
declare
victory
is
to
have
some.
At
least
you
know
some
first
version
of
code
running
so
that
we
are
sure
that
you
know
we
with
because,
but
by
looking
at
the
document
and
all
the
work
in
the
procession.
For
me,
it
seems
that
we've
solved
all
the
big
issues
that
are
out
there.
D
B
With
this
I
will
ask
la
hoja
now:
I,
don't
know
how
he
distributed
the
roles,
so,
like
I
said
earlier,
that
the
presentation
is
not
exactly
match
the
documents,
because
the
fragmentation
is
actually
in
the
same
document
as
the
IP
UDP
compression,
which
is
most
of
the
work
for
the
compression
and
then
the
coop
piece
is
a
separate
document.
But
this
slide,
where
kind
of
covers
the
the
compression
when
I
type
Jakob,
whether
the
documents
as
the
our
structure
makes
sense
or
I
should
want
to
ship.
J
Hello
I'm
Anna
Meena,
where
I
will
present
the
update
of
the
compression
part
of
the
Chicopee
and
UDP
draft
I
want
to
thanks,
Diego
and
Carlos
over
reviews
that
have
already
updated
in
the
document.
In
version
5,
we
are
working
with
Dominique
for
his
updates
and
modifications.
So
thank
you
all.
So,
one
of
the
most
important
things
between
Chicago
version,
3
and
today
version
5
is
the
that
we
define
a
generic
framework.
Then
we
work
a
lot
of
things.
We
take
out
things
of
the
coop
draft
to
the
chic
draft.
J
J
J
Normally
it
was
defined
as
a
list.
Then
what,
as
soon
as
we
see
in
the
implementation,
we
also
accept
to
be
an
arai.
We
have
a
very
weak,
a
discussion
of
padding
as
Dominic
mention
well
before
hackathon.
We
didn't
know
if
we
put
it
padding
between
the
header
compress
and
the
data
or
with
Patten
padding
at
the
end
of
the
of
the
old
packet.
J
We
have
to
add
or
copy
they
architecture,
part
of
the
overview
draft
in
order
to
make
the
reference
not
to
the
informational
document.
So
we
add
it's
a
copy/paste
of
the
architecture
have
that
have
been
already
defined
in
the
overview
draft.
As
you
can
see,
some
modification
is
instead
of
naming
the
hosts
or
things
like
things.
We
put
it
as
device.
We
don't
make
an
acronym.
We
only
reduce
the
name
devices
death
because
the
device
could
be
many
things.
We
also
change
the
name
of
the
network
gateway.
J
J
J
J
Another
thing
that
has
been
discussed
is
for
the
LSB
and
MSB
must
be
matching
operator
or
LSB
compression
the
compression
action
how
to
send
the
lens
of
the
value.
So
the
thing
is
that
for
coop
cop
define
a
maximum
number
of
1,024
bytes,
so
we
need
to
have
very
large
numbers,
but
we
give
importance
to
the
very
little
number.
J
J
It
was
heard
about
the
value
0
value
0.
Normally
you
don't
sent
it
but
because,
for
example,
in
coop
in
Europe,
add
on
your
query
doesn't
exist.
0
is
that
it
doesn't
exist,
but
when
you
have
an
acceptor
or
content,
0
is
value
0.
When
you
have
a
0.
So
in
order
to
go
forward
with
the
chic
compressor
draft,
we
think
that
this
must
be
specified
in
the
coop
draft.
J
B
B
We
still
need
to
keep
some
room
for
new
ways
in
the
forthcoming
documents,
meaning
that,
in
my
view,
it's
in
order
to
ship
this
document
and
it's
cleaner
right,
so
I
not
sure.
Yet
we
we
need
to
be
open,
that
the
forthcoming
document
will
define
additional
stuff,
including
this
I'm
perfectly
happy
to
see
it
push
to
go
up.
K
There
are
about
a
million
ways
of
doing
a
variable-length
field,
I
love
to
have
at
least
some
rough
idea
of
why
this
one
or
three
or
seven
but
thing
one
or
three
years
and
nibble
thing
is
the
the
thing
that
they're
actually
makes
sense.
So
at
least
a
little
bit
of
thinking
about
probabilities
of
certain
videos
and
so
may
be
useful.
K
The
other
observation
is
if
your
code
space
includes
length
values
as
well
as
the
absence
of
the
future,
then
just
use
one
of
the
videos
for
the
absence
of
the
Fiat,
so
you
could
use
0
for
the
absence
1
for
length,
0
or
2
for
length,
1
and
so
on.
So
that
need
not
be
a
problem.
Of
course
you
need
to
define
how
this
mapping
works,
but
that
is
indeed
specific
to,
for
instance,
quad.
Ok,.
J
C
G
One
rule
to
tell
one
remark
about
the
length
is
that,
in
fact,
when
we
put
a
zero
lens
for
your
a
puff
is
because
we
can
have
a
rule
that
contains,
for
example,
three
description
of
the
array
path,
but
you
receive
a
packet
with
only
two
urate
at
so
in
that
case
we
can
have
a
kind
of
negative
compression.
It
means
that
we
send
four
bits
equal
to
zero,
to
say
that
the
first
Yuri
path
doesn't
exist,
so
is,
is
too
rare
to
have
more
flexibility
on
world
selections.
B
Trouble,
since
the
semantics
are
different,
isn't
it
a
different
rule
or
something
I
mean
should
not
do
the
action
say
this
value
means
present
not
present
and
found
different
action.
It
means
the
what
you're
reading
there
is
the
actual
value
like
a
zero
every
trouble
that
that
you
have
a
confusion
of
semantics
when
you
have
a
action
that
can
tell
you
what
the
semantics
are.
No.
G
G
D
This
is
of
a
question
so
here
what
you're
talking
about
is
some
very
advanced
compression
in
coop
and
stuff
like
this.
So
it's
like
it's
something
very,
we
think
good
or
you
think
could
be
nice
to
have.
So
we
don't
know
if
this
is
going
to
be
used,
probably
yeah.
So
what
I
suggest
is
that
we
don't
block
the
document
on
this
like
trying
to
solve
some
some
problem
that
might
or
some
minor
issue
that
we
might
need
to
solve,
and
we.
D
L
G
B
I,
certainly
don't
want
to
delay
the
document
for
something
like
that,
but
but
but
since
we
have
a
solution
on
the
table,
which
was
just
propelled
by
constant,
let's
apply
the
ticket,
because
if
we
now
know
that
that
there
is
a
value
0
for
5
T
and
then
ever
you
would
everything
is
minus
1
and
1
min
0.
That's
a
perfect
solution
for
the
problem.
We
have
time
before
the
working
class
code
to
just
discuss
that
at
the
waiting
list
and
if
it's
better
than
we
ship
it.
G
Okay,
so
I
continue
with
a
new
another
document
which
is
ship
for
coop,
so
the
first
one
is
defining
the
basic
rule
and
we
apply
it
to
AP
visits
and
UDP.
But
for
coop,
as
we
have
said
in
previous
meeting,
is
more
complex
because
coop
is
a
symmetrical.
You
are
variables
in
lands.
You
have
a
lot
of
things
that
are
different
from
the
statical
things
from
UDP
and
IP
with
it.
G
So
what's
new
for
first
a
polite,
but
was
a
document
nothing
so
we
in
fact
the
graphics
prior
and
it's
meant
we
have
to
issue
a
new
value,
but
now
a
new
version.
But
now
we
have
things
to
do,
especially
with
variable
Finland,
so
it
will
be
done
done
soon.
So
why
we
have
done
nothing
is
because
we
move
all
the
tools
we
need
for
coop
into
the
previous
document,
which
gives
a
very
good
way
to
do
a
lot
of
very
flexible
compression.
So,
for
example,
for
for
coop,
we
put
the
matching
list.
G
So
it's
a
way
to
reduce
fields
like
code
or
type.
You
have
a
thousand
for
for
code.
You
have
a
lot
of
value,
but
maybe
you
will
use
your
an
implementation.
You
will
use
only
three
or
four
so
this
way
you
can
reduce
the
size
of
code
or
type
by
just
sending
an
index,
and
this
way
you
you
can
reduce
what
you
are
sending.
We
have
also
the
asymmetry,
so
we
have
the
direction
that
we
put
in
the
main
document.
G
It
can
be
useful
in
96
for
the
up
limit,
but
here
is
very
useful
also
because,
if
I
the
point
in
one
way
you
resend
a
post
on
the
other
way,
you
will
receive
error
message
or
an
acknowledgement
on
this
way.
If
we
separate
buffer
them,
we
can
have
a
better
compression
of
the
information.
So
we
put-
and
we
can
also
compress
coop
message
by
reducing
the
size
of
some
fixed
length
side
like
message
ID
or
token,
and
we
can
use
MSB
and
LSB
option
to
action
to
do
that.
G
So
now
we
we
have
something
that
works
quite
well.
We
begin
to
understand
more
and
more
how
we
can
do
very
optimal
compression
of
coop.
So
yesterday,
for
example,
we
can
call
compress
co-op
in
two
bytes.
So
what
was
something
very
good,
so
the
things
we
have
to
do
now
is
to
describe
very
well
this
very
powerful
things
that
can
lead
to
a
negative
compression.
It
means
that
there
were
something
that
doesn't
exist,
leads
to
four
bits
sent
on
the
wire,
but
can
be
more
flexibility
in
world
selection.
G
So
we
have
to
describe
this
in
details
to
to
see
our
to
understand
how
it
works.
So
what
we
have
to
to
do
next,
so
we
maybe
we
will
have
to
discuss
with
core
people
about
how
we
can
adapt
co-op
to
lp1
environment
because,
for
example,
we
can
have
sensor,
but
with
send
information
every
days
or
every
errors
on
since
now
we
are
putting
IP
server,
cannot
make
the
distinction
between
a
sensor
vats
and
every
days
on
another
one
that
sent
every
minutes.
So
we
will
have
problem
with
time
out
on,
especially
in
the
server.
G
We
keep
a
list
of
the
message:
ID
not
to
process
twice
the
same
value,
but
if
this
list
is
maintained
as
its
just
under
five
minutes
and
we
are
sending
every
hours.
So
if
we
do
a
retransmission,
then
of
course
it
will
be
lost
and
we
will
process
again
the
message,
so
we
have
to
tell
the
server
this
sensor
as
a
priority
of
one
hour,
this
sensor
already
city
of
one
day,
etc,
and
if
we
want
a
generic
server
may
be
a
good
way
to
do.
G
That
is
to
have
an
option
that
gives
the
time
square
of
what
we
are
sending
and
this
will
have
an
impact
or
so
in
the
compression,
because
if
we
know
all
these
things,
we
can
dimension
the
message
ID
field
and
have
something
that
will
be
optimal
on
the
radio.
So
that's
some,
for
example,
things
we
will
have
to
do
to
adapt
co-op
for
lp1,
okay.
So
what's
fantastic.
B
And
since
we
have,
we
have
experience
and
basically
message
dumps.
How
would
it
make
sense
to
put
examples
or
recommendations
in
annex
to
help?
Because
first
thing
is
people
will
read
this
document
and
they
wonder
you
always
find
that's
right.
How
much
can
you
compress
with
this
thing
and
I
have
every
year
6lowpan
document
have
paper
out
right
size.
Oh
six
of
mine
comprises
two
and
they
give
some
numbers
and
and
I,
don't
know
why
they
find
those
numbers.
B
Actually
it
would
be
great
that
you
have
some
some
examples
that
you
feel
are
kind
of
really
representative,
like
temperature
and
pressure
in
this
room.
If
you
could
show
the
exchange
the
compression,
the
rules
that
you
use
for
that
particular
case,
it's
important
because
you
may
actually
find
that
several
rules
so
ever
way
of
writing.
Your
rules
may
work.
There
is
not
a
single
way
of
writing
them,
but
there
might
be
recommendations
about
how
to
write
them
well,
and
there
might
be
examples
of
work
done
well
in.
G
D
Actually,
on
this
part,
I
would
be
I
think
that
one
of
the
things
we
should
actually
take
make
sure
is
that
the
system,
the
whole
system
is
working
right,
and
this
last
point,
for
example,
with
the
timers.
This
is
something
that
seems
pretty
important
to
me
because
otherwise,
it's
you
know
we
can
have
systems
where
you
know
it
just
doesn't
work
because
of
the
time
scale
difference.
D
So
this
is
one
point
that
seems
very
important
and
I'm,
not
sure
if
you
have
other
things
that
you
have
identified
that
need
to
be
fixed
because
before
we
can
need
to
be
addressed
before
we
can
say.
Well,
it's
it's
ready
to
to
be
deployed,
and
you
know
with
the
time
we'll
get
more
and
more
and
more
feedback
on
what
are
the
rules
and
how
we
know
we
can
do
this
efficient
compression.
What.
G
Do
we
have
to
do
this
on
LP
one
or
in
core?
That's
the
question,
because
you
cannot
put
everything
on
this
document
because
we
will
discover
no
need
for
new
options
and
if
we
had
a
new
option,
it's
not
a
problem
on
the
sheik
mechanism,
because
it's
very
flexible
and
we
say
okay
now
in
the
rule,
you
have
this
option
time
square
for
example,
and
it
works
so
it
will
not
influence
the
the
compression
is
more
the
behavior
of
coop
server,
but
have
to
be
more
generic,
more
take
more
diversity
of
source
of
of
clients.
D
D
K
We
have
a
meeting
in
one
and
a
half
or
so.
If
you
can
maybe
generate
a
little
bit
of
slide
where
to
motivate
this,
we
can
discuss
it
right.
There
I
think,
but
we
have
experienced
this
kind
of
problem
before
so
in
the
constraint
space,
all
the
typical
defaults
for
timers
do
shift
so,
for
instance,
we
we
had
to
do
something
to
DTLS
like
to
make
it
work
in
the
constraints
okay.
So
this
is
not
not
a
new
idea
to
anyone
in
the
room
and
I
can
imagine.
L
L
Is
the
contribution
is
to
define
a
way
to
map
icmpv6,
some
compression,
of
course,
and
see
compression,
and
they
think
is
that
we
have
been
done
some
some
extra
work
trying
to
reduce
the
number
of
of
bits
used
a
general
using
bits
on
the
rule
ID
field,
since
we
have
some
freedom
to
use
it,
okay,
so
the
the
fields
we
are
where
the
packets?
We
are
compressing,
the
echo
requests.
G
L
L
G
D
G
D
G
H
D
L
L
D
L
Thanks
so
for
the
time
being,
we
are
going
to
explain
about
this
Manta
kiss,
but
maybe
in
after
the
definition,
I
see
HCA.
Then
we
change
that
okay,
so
we
see
provided
in
maybe
just
named
all
the
bits
just
that
here,
okay
I'm
free
to
the
bits
we
have
given
a
number
of
values:
okay,
so
we
supplied
it,
which
is
the
next
here
field,
okay
of
an
exterior
UDP.
L
So
if
I
we
have
reserved
for
this
okay,
a
hundred
twenty
eight
artists
and
then
we
need
to
define
if
you
the
address,
is
link
local
or
global
okay,
which
are
using
within
the
ACP
field,
and
we
have
reserved
one
bit
for
the
future
use.
Then
the
mapping
continues
with
the
type
of
message
we
are
using
there.
Okay,
so
we
are
not
the
ones
we
have
already
done.
Yeah
and
the
radio
act
is
not
implemented
yet,
but
it
has
already
a
code.
L
Then,
if
another
bit
the
sense,
your
single
packet
is
sent
okay
or
after
party
we
have
some
extra
information.
We
can.
We
can
think
about
some
some
link
options,
and
so
on
so
talking
about
the
echo
request,
I
record
by
specifically
okay,
then
they
say
what
the
generic
header-
okay,
this
one
for
the
echo
quick
reply.
L
So
well
this
over
the
last
one.
It
cannot
be
seen.
Okay
is
optionally.
The
link
layer
option,
which
is
the
only
part
we
are
sending
for
the
road
to
solicitation
type
packet
there
and
there
are
every
other
part
of
the
packet-
is
not
same.
So
we
are
just
using
48
bits,
which
is
just
economic
in
terms
of
bits.
Okay,
for
a
time
of
harvest
ice
meant
the
other.
There
is
packet.
L
Okay,
we
just
again
sending
only
the
old
a
link
layer
option,
that's
which
is
there
in
dispenser
thing
is
fundamental
to
Santa
yeah,
then,
on
the
neighbor
solicitation,
it
becomes
a
little
bit
complex
because
way
either
way.
We
need
like
this
again
to
send
it
the
link,
local,
ok
and
the
global
I
I
either
if
you
are
wasting
one
or
the
other,
because
we
are
trying
to
understand
who's
around
and
if
there's
a
there's
the
same
prefix
all
around
the
notes.
L
L
Used
only
the
target,
others
which
is
64
and
128,
that's
the
only
either
one
or
the
other
okay,
and
we
have
ignore
the
the
option
length
or
link
layer
there,
because
you
are
just
advertising
our
size
that
you
exist
in
within
network
and
that's
it.
So
the
thing
is
that
nothing
is
just
mostly
straightforward.
B
We
are
here
so
you've
selected,
number
of
messages
and
basically,
you've
used
all
the
possible
bits.
So
it
means,
like
the
format
is
stuck
to
to
the
message
in
your
children
and
rule
of
thumb.
I
would
have
thought
that
the
first
message
I
would
have
encoded
would
not
have
been
one
of
those
three
I
would
have
encoded.
I,
see
em
here
to
be
able
to
report
any
form
of
Europe
and.
C
B
L
D
So
actually,
this
is
a
very
thank
you
very
much
for
for
this
work,
and
this
is
a
very
good
question
because
we
are,
it
is
not
in
our
Charter
today
and
at
some
point
we
will
need
to
to
ask
ourself.
Is
this?
Some?
Is
this
a
work
that
we
are
going
to
be
interested
in
doing
so?
I
know
we'll
be
talking
a
little
about
this,
but
as
well
as
while
we
are
speaking
about
this,
I
would
like
to
ask
if
you
consider
it
to
be
a
work
which
is
interesting
for
us,
yeah.
E
So
I'm
sorry
Christian.
So
if
the
current
items
are
all
done,
we
can
have
a
drink,
chattering
discussion,
but
I
know
you
have
some
open
points
right
now,
but
don't
talk
about
option
right
now
like
but
just
or
like,
like
until
we
decide
like
you
know
what
other
things
kind
of
things
you
want
to
work
on,
like
you
know,
hold
it
down
to
then
like
so
you
have
something
on
for
today
so
like
we
can
talk
about
it
at
that
point.
J
G
Okay,
so
that's
something
that
is
very
old,
so
it's
a
real
document
that
is
when
we
started
walking
on
cheek,
so
wish
you
this
document,
but
now
maybe
it's
time
to
to
think
again
to
work
on
it.
So
when
we,
when
we
design
the
rules,
we
don't
in
the
document,
we
don't
say
any
way
to
implement
it,
so
we
have
one
way
is
to
use
design,
but
it's
not
very
efficient
and
another
way
will
be
to
to
use
young,
and
so
this
is
an
attempt
to
do
that.
G
So,
in
the
rule
design,
as
I
now
showed,
we
have
different
fields,
so
we
have
different
words.
So
it's
a
list
of
rules
on
each
each
rule.
We
have
a
list
of
fields
and
we
have
some
value
that
will
be
well-known.
For
example,
I
find
that
this
here
for
examples
of
a
field
we
can
define
some
well-known
value
currently
in
our
implementation
is
text,
but
it
can
be
also
an
identify,
er,
generically,
notify
or
but
save
this
field
is
an
ipv6
reference
field.
This
fig
is
the
coop
your
area
path
for
something
like
this.
G
So
we
are
this
of
the
position.
It's
a
number
Direction
is
three
possible
value.
Be
directional
upstream
dumb
string
target
value
can
be
anything,
it
can
be
a
number
string,
an
array,
so
we
have
everything
we
find
in
a
packet
matching
operator.
Currently
we
have
defined
five
of
them,
but
of
course
we
can
add
over
one,
but
this
one
are
the
one
we
think
are
the
best
now
right
now
to
do
the
compression
and
same
thing
for
compression
the
compression
action.
We
have
a
list
of
action
that
we
can
apply
for
compressing
or
decompressing.
G
So
it
means
that
it's
so
as
I
say,
we
can
use
a
reason
way
to
represent
it,
but
here,
for
example,
this
is
a
rule
we
use
for
the
accattone
it's
about
2500
bytes.
So
if
we
use
some
technology
but
sense
only
and
when
I
read
a
message
a
day
of
12
bytes,
it
will
takes
two
days
to
send
this
word.
So
it's
not
quite
efficient
in
lp1
and
technologies
and
of
course,
what
we
need
also
is
to
do
partial
updates
off
patch.
G
It
means
that
we
may
change,
for
example,
saucepot,
because
a
node
will
change
it
so
spot
or
change
of
rollable,
because
not
one
speci
to
specify
a
floor
level
or
all
these
things.
So
we
need
a
way
to
signal
it
and
not,
of
course,
to
send
everything
on
on
the
radio.
So
that's
why
young
could
be
a
good
candidate
for
first,
because
we
can
have
a
compact
and
unique
representation
for
some
of
the
field
of
the
of
the
rules
and
also
we
can
have
complex
compact
representation
of
the
exchange
between
the
node.
G
He
is
a
device
and
the
compressor
in
the
compressor,
the
compressor
in
the
infrastructure.
So,
for
example,
as
I
say,
we
can
add,
for
example,
a
network
gateway
or
a
compressor
that
will
assign
ipv6
prefix
to
the
device.
So
it's
a
kind
of
neighbor
discovery
or
very
small
level
discovery
and
say
you
have
this
prefix.
So
then
checksum
and
all
those
things
can
be
done
on
this
value
on
the
device
can
assign
or
can
tells
the
network.
G
I
am
using
this
spot
number
I
am
using
this
destination
address
or
not,
may
change
the
destination
address
for
because
you
may
put
an
update
on
the
node,
so
we
need
all
these
things,
and
what
can
be
done
also
is
to
have
something.
Compact
is
that
this
rule
can
also
be
compressed
using
shake.
So
we
have
something
a
kind
of
recursive,
so
we
have
to
to
define
that
in
annyeong.
K
K
G
G
K
But
if
we
use
yang
I
think
there
is
a
certain
expectation
that
we
would
use
the
yangtze
bow.
But
do
you
want
to
do
a
second
see
were
encoding?
Is
young,
Siebert,
yeah
and
and
what
I'm
trying
to
say
is
we
can
go
way
beyond
the
level
of
compactness
or
a
offered
by
that.
If
we
know
exactly
what
you
want
to
do,
so
yang
is
kind
of
the
general
thing
that
works
very
well.
And
yes,
you
can
transport
a
sofa
and
NMSU
the
smart
if
you
have
to,
but
maybe
we
need
a
Vespa.
D
So
a
perv
so
yeah
this
did.
These
are
like
three
points
here
that
are
really
important,
and
this
is
why
I
think
that
yang
is
the
right
tool
to
use.
So
the
first
thing
is:
has
all
that
you
said
there
is
that
it
actually
provides
the
semantics
that
it
actually
says.
Okay,
I
mean
geez,
and
this
is
just
this
is
just
representation
right,
but
you
still
need
to
know
what
co-opted
code
is
and
how
you
know
that
ipv6
that
version,
what
it
is
and
right
now
you
have
city
like
in
a
text.
D
So
yang
is
the
formalism.
It's
the
formal
way
that
you
describe.
Okay,
there
is
a
model,
so
there
are
these
fields
and
I
expect
here
to
dust
at
that
point:
to
have
to
have
this
type
of
value
and
so
forth,
then
you
have,
as
Kirsten
said,
you
have
the
young
to
see
boor
mapping
that
actually
allows
you
to
map
this
thing
to
see,
bore
to
something
that
is
very,
very
efficient
right
and
then
you
have
the
protocol
bindings
that
come
to
kamae
so
that
you
actually
are
using
patch
and
fetch.
D
So
this
is
already
income
I,
so
I
think
that
we,
we
should
also
look
into
the
way
this.
These
things
will
be
implemented
deployed
and
we
don't
want
I
mean
this
is
like
chair
had
a
flaw.
This
is
really
a
personal
opinion
that
we
want
to
have
running
code
and
we
want
to
have
interoperability,
and
we
want
to
have
something
very
efficient,
but
you
know
in
the
same
time,
we
don't
want
to
to
spend
too
much
time
designing
someone
new
to
go
or
some
new
thing
that
is
made
for
this
another.
G
B
Oh,
it's
so
much
complexity,
actually,
at
the
end
of
the
day,
for
the
developer,
because
of
those
tools
are
they're
doing
the
right
thing
is
a
lot
less
expensive
to
develop
and
test
if
we
use
all
those
common
IT
tools
and
that's
really
why
we
are
doing
all
this
right.
So
this
view
of
what
law
is
proposing
here
goes
in
that
exact,
same
direction
of
enabling
the
clean
way
in
an
easy
fashion,
funny
buddies,
so
that
they
don't
do
the
dark
dirty
way.
B
G
Have
not
been
killed
by
a
young
doctor
right
now,
so
Wow
well,
I
don't
show
it.
So,
of
course
we
have
to
do
a
lot
of
work
in
young
representation
and
it's
a
concept
that
it's
quite
new
for
me.
So
we
we
do
an
example.
So
I
think
there
is
one
that
we
again,
but
we
have
to
take
advice
and
discuss
more
about
what.
B
B
I'm
confused
that
the
the
value
is
still
anything
probably
there
is
a
tree
of
representations
that
the
value
is
what
it's
supposed
to
be,
but
souls
so
now:
okay,
fantastic!
Let
us
move
continue.
This
work,
prison
and
just
a
whole
lot
of
helpful
people
at
the
ATF
at
every
ATF,
which
you
could
contact
them.
Work
with.
J
Okay,
I
will
I
will
present
where
the
discussion
we
have
little
bit
in
the
memory
list
for
these
new
items
to
be
working,
the
working
group,
so
the
first
one
was
the
ICMP
compression
thanks
to
the
ago,
to
make
the
first
version
of
draft.
This
item
has
a
lot
of
input
in
the
mailing
list.
There
were
more
than
10
people
that
said
that
they
were,
they
agreed
to
work
in
this
ICMP
compression,
and
then
we
have
also
the
Sheikh
over
specific
help.
E1
technologies
I
think
it's
very
important.
There
were
no
input
about
these
items.
J
Different
variables
of
the
cheek
compression
in
order
to
work
the
best
in
in
the
lp1
technologies-
and
then
we
have
another
item-
is
the
security
for
the
LP
ones,
with
the
sheik
implementation
or
compression,
then
there
are.
There
were
no
input
there.
Neither
and
the
other
idea
was
the
ruse
ID
management.
J
J
D
J
B
I
can
react
to
that
I'd
rather
separate
the
informational
description
of
a
particular
technology,
like
the
nice
drive
that
we
have
today
with
something
which
could
become
normative
and
could
be
very
small
but
which
we
say.
Oh,
let's
focus
now
on
setting
those
parameters
and
and
let's
make
that
establish
accuracy.
So
I
would
like
to
specific
and.
J
A
Regularly
so
there
were
few
proposals
in
the
past
right,
like
radio,
resource
management
and
gateway
to
the
networks
of
standardizing
the
interfaces,
so
I
did
at
least
once
or
twice
you
know.
In
the
previous
site
years,
I
presented
this
proposals
all
right
again,
just
a
list,
one
Israeli,
radio,
resource
management
on
the
gateway
right.
They
firing
the
objects
right,
irrespective
the
protocol
but
I
an
find
the
radio
elements
right,
information
elements
that
need
to
be
managed.
That
is
one
work
item.
Alright,
that
is
for
from
deployment
point
of
view.
That
is
an
extremely
important
aspect.
A
Right,
let's
say
if
I'm
deploying
Laura
right
or
some
other
access
network
I
should
be
able
to
get
the
ready
resources
understand
them
at
least
manage
them.
That's
one
point
second,
point
is:
if
you
look
at
it
currently,
there
is
no
standardized
interface
between
the
out
between
the
gateway
in
the
network
server.
So
if
you
change
the
network
access
technology
Laura
to
seek
Fox
pretty
much,
they
are
the
same
issue.
Fundamentally,
there
is
a
sensor,
there's
an
access
point
or
a
gateway,
and
then
there's
some
aggregation
function
on
boarding
element
right.
A
So
this
in
between,
if
you
can
standardize
one
interface
in
which
we
can
support
multiple
radio
technologies,
I
think
that
will
be
of
immense
use.
Essentially,
you
know
industry
will
really
greatly
benefit
from
an
interoperability
point
of
view.
Even
within
Laura
alliance
is
also
not
defying
that
standard
right.
So
this
is
a
great
opportunity
for
ATF
to
standardize
that
so
those
are
my
two.
You
know
proposals
I.
B
Would
really
love
the
technologies
on
the
mailing
list
or
were
to
react
on
your
proposals,
in
particular
the
latter
one,
because
that
that
request
I
would
like
to
see
it
coming
from
people
who
will
actually
would
deploy
those
things
have
it
do
they
see
the
same
thing
as
you
do
I
mean
I,
really
appreciate
you,
your
view
and
I
would
like
to
see,
if
they're,
to
get
more
people
joining
in
and
say.
Yes,
it's
a
good
idea
right,
I.
B
E
I'm
serious
Krishnan,
so
she
you
proposed
it
right
so
like
do
it
again
right
at
that
time,
the
was
not
Charl
do
it,
so
you
need
to
start
that
process
again
to
get
this
thing
down,
but
this
like
to
think
two
things,
I
wanted
to
say.
First
thing
is
like
we
need
to
figure
out
like
what
font
is
gonna
happen,
so
this
is
gonna,
be
like
a
standard
sized
document
or
like
informational
stuff
on
what
somebody
else
does
right.
E
So
that's
like
the
first
decision
we
need
to
make
if
you
want
to
go
down
this
path.
If
there
is
interest
right,
are
we
gonna
just
document
the
stuff
that
other
people
do
like
for
like
the
overview
stuff
right
like
we
decided
we'll
document
like
what
other
people
are
doing
like
about
other
technologies?
That's
one
thing.
Second
thing
is
like
we
had
like
a
very
good
relationship
with
the
other
SDOs
right
like
going
and
I
want
to
keep
it
that
way.
E
So
we
don't
want
to
be
like
stepping
on
the
turf
and
doing
things
for
them.
Okay,
so
we
need
to
have
an
understanding
from
the
other
SDOs.
What
their
plans
are,
so
they
like
to
come
here
to
the
IETF
and
do
the
work
or
like
do
they
want
to
do
the
things
themselves
right
and
that
might
lead
to
choosing.
E
Let's
say
like
X
of
these
deals,
like
some
subset
says
yes,
and
some
subset
says
no,
that
might
lead
to
picking
a
different
set
of
technologies
than
the
overview
for
doing
this
work
right.
So
that's
also
something
we
need
to
consider
because,
like
for
example,
like
sig
Fox
might
decide
like
I've
done
this
right
and
they
might
just
decide
to
put
it
here
or
not
right
and
stuff
like
that.
A
Thanks
additionally,
one
comment:
is
you
know
if
you
look
back
on
the
cellular
side,
the
gtp
is
what
you
know.
We
never
managed
to.
You
know
push
you
know
mobile
TV
6,
because
gdq
GDP
was
deployed
already
in
the
right.
So
here
we
don't
want
LP
vans
to
go
that
long.
At
least
iedf
can
do
something.
I
mean.
B
It's
very
important
that
you
race
exactly
what
you
said
on
the
meaningless
and
I
would
love
I
will
ask,
for
you
know
people
to
react
from
the
various
technology.
We
have
several
vectors
to
actually
show
interest.
Well,
it's
too
late
for
the
other
of
you,
but
there
is
a
gap
analysis
in
the
overview
and
and
then
there
are
the
individual
documents
and
then
there's
the
meaning
list.
I
mean
there
are
multiple
ways
by
which
the
individual
actually
support.
M
B
B
D
So
I
mean
let's
take
this
in
a
different
way.
No
no
I
mean
that's.
That's,
let's
say
this
in
a
different
way.
Today
we
have
so
I
I
would
not
address
this
like
in
the
sense
of
okay.
We
have
gateways
radio
gates
and
so
forth.
I
mean
that's
has
been
done.
We
have
already
some
things
out
there.
It's
mostly
in
the
fact
that
we
are
bringing
like.
D
We
have
the
compressor,
the
compressor
now
and
we
have
the
and
this
thing
is
like
it
lives
somewhere
out
there
and
it
must
be
surrounded
in
which
I
mean
it.
We
must
construct
something
around
it
so
that
it
is
actually
viable.
Part
of
this
part
of
the
things
that
we
need
to
do
is,
for
example,
how
we
define
the
compression
how
we
express
the
compression
context.
So
during
the
hackathon
there
was
this
JSON
format.
D
That
was,
you
know
like
people
around
the
table
defined
it,
so
they
they
were
able
to
interoperate
right,
but
right
now
we
need
to
go
to.
We
need
to
define
an
extensible
mechanism
for
actually
doing
this,
so
yang
is
the
one
way
to
do
it.
There
may
be
others,
you
know
there
may
be
you
the
use
of
comma
and
and
so
forth
and
so
forth.
D
I
mean
because
we
have
these
discussions
before
that
and
and
I
I
know
that's
what
we
were
talking
about,
so
I
just
didn't
want
to
do
it.
So
it's
like
the
whole
system
how
the
whole
system
works
and
I
will
ask
the
question
make
honkers.
Do
you
want
to
say
something
before
I
ask
the
question
and
if
there
is
interest
of
doing
this
work
we
need
okay,
so
you
need
to
say:
okay
go
ahead
on
Cassie.
N
B
But
I
was
after
a
big
picture,
so
we
can
position
if
you
are
taking.
We
have
to
come
back
to
chattering
here,
so
that
needs
to
be
a
map
and
say:
oh,
we
are.
We
want
to
cover
this
piece
in
the
map
and
so
so
I
think
the
we
start
that
the
when
we
did
the
the
bath
work.
We
provide
a
very
initial
vision
of
what
the
big
picture
was
and,
and
we
said,
oh,
we
could
be
working
here.
We
could
be
working
here.
B
We
could
be
working
here,
I,
don't
know
how
to
position
the
compression
state
in
the
place
where
the
compression
or
the
compression
will
happen,
because
this
thing
I
must
be
agnostic
to
start
with.
It
doesn't
know
which
device
will
be
placed
in
network,
so
there's
a
number
of
functions
that
we
know
will
probably
care
for,
and
if
we
add
this
this
map,
then
we
could
navigate
it
and
say:
let's
shout
out
this:
let's
chatter,
this
and
that's
what
I
was
after
so.
N
So
then,
my
question
is
I.
I
do
well.
First
of
all,
I
I
do
see
value
in
this
document
because
indeed
it's
it's
always
hard
to
explain
to
people
our
development
groups
and
so
on
exactly
how
things
work.
So
a
document
like
that
would
be
very
useful,
but
right
now
we
are
still
talking
about
jung-mi,
ICMP
and
rules,
so
fragmentation.
So
how?
How
do
you
foresee
the
timeline
of
this
document
compared
to
the
work
or
the
where
we
are
so?
Is
this
something
that
will
come
after?
D
Okay,
so
personally,
I
think
that
we
should
have
like
it
should
go
in
somehow
together,
so
that
we
have
this,
we
discuss
and
we
say,
okay.
Well,
there
is
this
first,
it
super
important
piece
that
we
have
now,
that
is
the
shake
compression
mechanism,
and
now
we
need
to
make
it
a
living
thing.
So,
in
order
for
it
to
live,
we
need
this
this
and
this,
and
then
we
need
a
document
that
actually
says.
Okay,
these
two
work
or
these
things
together.
D
They
work
in
this
way
right
so
I
would
go
with
a
pragmatic
approach
where
we
have
like
the
description
of
how
the
things
work,
and
maybe
you
know,
put
some
references
to
ok.
This
thing
could
live
from
as
a
function
in
this
network
element
or
this
network
element,
but
I
would
mostly
focus
on
the
protocol,
part
of
it.
You
know
how
how
how
they
all
interact
so
develop
them
in
in
writing.
Parallel,
so
not
publishing
the
document.
B
B
It's
going
to
be
that
protocol
file,
since
the
joint
process
that
we
are
building
and-
and
some
things
will
maybe
never
happen,
but
that
gave
us
the
map,
the
high
level
from
from
some
distance
view
of
what
we
cover
up
globally,
you
know
and
and
where
we
could
be
working
and
how
those
things
interact
with
one
another
etcetera.
So
so
people
can
can
figure
out.
Oh
you're,
doing
this
building
block,
but
that's
that's
where
it
will
go
in
the
world.
B
N
D
Why
your
stone
the
mic?
Actually
I
would
like
to
get
back
to
the
to
this
list
of
things
that
people,
because
that
we
discussed
and
that
people
say
okay,
that
that
could
be
interesting
to
were.
There
are
some
interest,
so
you
as
as
sick
folks
as
a
technology
provider,
which
one
of
these
elements
seem
important
to
you,
and
you
know
things
that
we
should
be
looking
more
for
a
future
work
like.
N
Well,
the
list
is
very
comprehensive.
I
think
we
have
already
discussed
this
I
see
value
in
most,
if
not
all
of
them
ICMP.
Definitely
she
cover
a
few
sure
security
I'm
still
puzzled
about
what
exactly
because
here
it
says,
everything
and
I
specified
security
for
Schick
and
so
I
think
we
need
to
dig
more
into
what
exactly
it
is
before.
I
could
say
yes
or
no.
N
The
rules
ID
I'm
open
to
discussing
whether
it
falls
into
shake
over
for
or
it's
independent
and
the
yang
for
sure,
I
mean
we've
been
having
this
disgusting
discussion,
so
the
yang
of
things
and
I
think
it's
extremely
valuable
to
to
open
up
a
plus,
of
course,
this
architecture
or
high-level
description
or
functional
description,
etc.
Document.
D
E
Should
address
so
I
I
think
Christian,
so
I
think
you
should
work
on
the
list
like
trying
to
get
this
narrow
down
before
Singapore
so
and
if
everything
is
done
before
Singapore,
we
can
actually
do
like
the
reach
chattering
discussions
completely
on
list
and
beer
each
other
if
a
Singapore
but
I'm
I'm
not
sure
like
looking
at
the
shake
stuff
that
will
be
done
before
Singapore
like
shipping
it
out.
Okay,
so
I'm
glad
to
be
surprised
on
that.
E
O
E
E
C
E
To
take
a
look
and
comment,
because
if
you
miss
like
one
like
they're
gonna
do
a
different
thing,
so
the
idea
of
like
you're,
not
doing
like
common
thing
doesn't
really
happen.
If
we
miss
out
like
I'm
on
other
major
technologies,
we
pick
before
so
as
I
said,
like
get
started
off
on
it
as
long
as
it
doesn't
draw
their
resources
from
people
who
are
writing
the
documents
and
reviewing
the
documents,
if
it
doesn't
take
too
many
cycles,
start
it
off
now,
if
you
want.
D
Okay
and
on
this,
so
if
we've
managed
to
shift
I
mean
when
we
ship
the
IP
UDP
shake-
and
maybe
we
delay
will
be
the
Crab
Shack
big,
because
we
need
to
go
with
the
co-op
option
and
all
these
kind
of
discussions
is
this:
do
you
consider
this
is
sufficient?
For
you
know,
if
you
November,
we
have
the
IP
IDP,
she
can
say:
okay,
co-op.
We
know
we
have
a
milestone
at
the
end
of
the
earth,
something
sure.
E
B
Attention
I
think
you're
gonna
be
the
next
on
the
boiling
plate
so
but
Bobby
she
might
so
I
was
lucky
enough
to
be
I,
do
Tripoli
last
week
and
attend
the
interest
group
LP
WA,
which
has
met
every
day,
and
it
was
a
regreat
regret
sessions
that
we
had
and
then
there
were
also
a
number
of
discussion
about
it
in
4k,
and
then
there
is
the
general
activity
on
my
son,
etc.
So
there's
a
lot
you
can
tell
us
about.
Thank.
O
M
Okay,
I'm
got
some
slides
on
15
dot.
Twelve,
you
a
little
verbal
on
LPW,
a
and
the
revision
of
15.4,
because
we're
endlessly
doing
revisions.
Sadly,
molt
make
that's
good
news.
We
had
a
number
of
goals
in
Berlin
opening
report,
of
course,
but
the
important
stuff
was.
We
had
a
large
number
of
presentations.
This
particular
go
around,
including
detailed
discussions
on
PDD
PP
de
p.m.
pass
through,
etc,
etc.
So,
in
terms
of
a
general
status
update,
we
were
looking
at
various
format
issues
you
know
like.
M
M
We
haven't
arrived
at
a
full
disposition
on
that,
but
they're
they
don't
have
to
be
considered
in
combination,
which
I
suppose
is
a
good
thing
and
then,
in
terms
of
where
should
L
to
our
management
be
situated,
we
decided
that
that
should
be
in
the
application,
should
layer
and
then
ADA
got
15
dot,
12
the
management
functional
block
so
and
then
we
kind
of
looked
over
and
tried
to
develop
a
list
of
generalized
management
functions.
As
you
can
tell,
and
15
dot
12
right
now,
we're
really
trying
to
get
it
fully.
M
Organized
and
there's
a
I
didn't
include
the
the
the
detailed
functional
diagram,
but
you
can
go
find
it
on
the
I
Triple
E
document
server.
So
in
terms
of
data
playing
operation
using
15
dot
12,
we
kind
of
work
through
an
example
based
on
six
low.
I'm
won't
go
through
this
and
you
know
haddassi
him
detail,
but
this
sort
of
describes
the
the
flow
through
the
system.
So
we
Billy
could
understand
how
the
process
worked
and
whether
anything
broke,
and
you
know
I.
You
know
we
think
this
is
the
general
direction.
M
So
if
anything
spots
I
mean
anything
haywire
here,
this
would
be
this,
or
at
least
by
September
would
be
a
good
time
to
speak
up
in
terms
of
the
management
plain
operation
we
did
discuss,
enabling
configurations
from
the
higher
layer
protocols,
specifically
Netcom
Co
me
and
I
Oct,
a
control,
a
need
for
remote
configuration.
We
discussed
how
to
identify
profiles,
so
just
this
was
a
lot
of
generic
stuff
and
then
an
eye
chart
for
those
of
you
in
the
back
of
the
room.
We
did
have
a
number
of
accomplishments.
M
2015.12.25
forces
you
see
two
blanks
there
but
I'm
assuming
Pascal
you're
in
a
couple
of
key
figures,
as
you
were
in
this
last
stuffer
or
6lowpan
and
60-ish.
That
has
not
been
an
issue
so
I
just
I,
don't
know
why
Pat
didn't
put
something
in
those
blocks
and
we're
gonna
do
a
number
of
things
in
terms
of
looking
at
the
functional
block
overview,
just
making
sure
that
we
had
and
everything
about
each
of
those
blocks
and
how
do
they
work?
M
You
know
what
functions
are
they,
including
all
all
the
stuff
we've
been
doing
on
all
those
other
elements?
So,
like
I,
say
if
you
look
at
the
diagram,
there's
a
rather
huge
number
of
functional
blocks
verbally
now
on
LPW,
a
I
think
the
the
biggest
thing
I
really
want
to
talk
about
they're.
Just
you
know,
I
think.
M
Most
of
you
are
aware
that
in
802,
15
we've
had
an
interest
group
which
translates
to
above
an
IETF
looking
at
lpw,
a
sort
of
as
a
generalized
thing
as
it
applies
to
802,
seeing
if
there
are
other
things
with
an
802
that
might
be
brought
to
bear
on
the
problem
of
low-power
area.
So
it's
been
a
very
generalized
study.
It's
not
intended
to
replace
anything.
There's
it's
looking
for
gaps
and
I.
M
Think
the
most
interesting
thing
that
came
out
of
Berlin
meeting
was
we
looked
at
and
I
say
we
I
think
you're,
you
know,
did
the
majority
of
work
on
this
various
the
suitability
of
various
various
aspects,
so
there
were
modulation
schemes,
forward,
error,
correction
schemes,
connectivity,
Network,
topologies,
max
schemes
and
encryption
schemes.
You
did
a
really
nice
piece
of
work
there
that
may
be
of
interest,
I,
think
to
people
here
and
what
I'll
do
since
it's
an
extensive
amount
of
work
and
no
way
can
it
be
covered
in
five
minutes.
B
M
Okay,
so
document
17,
four
five
one.
This
is
an
802
2.15
documents.
I
should
actually
proceeded
with
15
17,
four
five
one
so
you're
in
the
right
place
on
mentor
and
if
you're,
not
a
member
mentor,
you
just
get
an
I
Triple
E
web
account.
You
go
on
to
mentor,
you
sign
in
I,
authorize
it
you
get
the
document
so
very
easy
to
do.
Lastly,
just
a
very.
M
D
M
M
P
M
Know
and
then
lastly,
we
just
finished
15.4
2015,
but
we
already
have
five
completed
amendments.
We
have
a
rollup
so
we're
putting
those
together
as
a
rollup,
but
you
know,
15.4
has
had
growing
pains
and
there's
a
number
of
things
that
still
need
to
be
cleaned
up.
We're
trying
to
be
much
more
methodical
on
this
go
around
and
you
know
I
know
there
are
things
that
might
be
helpful
as
far
as
six
six
low
LPW
a-
and
this
would
be
the
time
you
know
we're
not.
M
This
is
not
a
fact-
we're
not
fast-tracking
this
we're
really
trying
to
assemble
something.
That's
it
really
corrects
or
or
adds
important
things
to
15.4.
So
this
is.
This
is
just
in
the
process
of
kicking
off.
So
if
you've
got
some
stuff-
and
you
know
something
is
going
make
sure
you
get
those
inputs
in
send
emails
to
Pat
Kinney,
whatever
there's
a
number
of
mechanisms
and
if
you're
curious
about
any
of
it,
just
send
me
an
email
at
be
highly
at
I,
Triple,
E,
org
and
I'll
be
happy
to
make
it
part
of
the
process.
B
Think
question
Bobby,
she's,
not
mine,
sure
so
so
far,
1512
considered
6lowpan,
because
that
was
the
only
thing
available
and
now
for
the
most
extreme
cases,
this
group
is
proposing
check
and
I
was
wondering
if
it
would
help
the
developer
and
in
which
fashion
to
to
have
also
shake
somewhere
in
this
picture
of
1512.
Does
it
makes
sense,
or
is
it
really
in
the
world?
M
And
we
had
actually
you
know
in
a
presentation
and
made
part
of
you
know
just
the
material
that
goes
into
the
document.
I
said:
if
there's
a
if
it's
enough
agreement
on
it,
you
know
it's
not
a.
It
doesn't
take
a
you
know
a
lot
of
effort,
but
this
is
enough
agreement
on
it
then
that'll
move
forward
and
could
be
included
in
the
graft
and
stuff
like
that.
I
can.
B
See
that
the
application
user
now
using
1512
and
really
1512
selecting
how
it's
going
to
compress
by
nanowire
bears
and
while
it's
going
and
they
see
a
lot
of
power
in
that
just
sometimes
the
computer.
Okay,
the
constraint
is
not
really
on
the
device
wicket.
We
can
have
this
code
in
there.
The
constraint
is
on
the
medium
so,
but.
B
M
It's
also
by
the
way
we
why
we
separated
twelve
and
four
you
know
did
just
in
terms
of
structure.
It
lets
us
really
add
things
and
for
that
that
that
are
consistent
with
what's
already
in
the
marketplace
and
you
we
don't
so
we
don't
break
stuff
and
and
and
then
twelve
you
know,
becomes
a
way
of
really
adding
to
it.
A
lot
of
things
that
were
deliberately
left
out
of
the
Mac
to
keep
it
light
weight.
D
D
D
B
This
we
can
go
for
any
other
business.
We
are
straight
on
time
perfectly
on
target
we
need
to
because
we
are
very
constrained,
okay,
so
any
other
business
anything
you
want
to
raise
before
we
close
the
meeting,
then
you
just
save
five
minutes
of
your
life.
Thank
you.
So
much
for
for
for
being
here,
use
it
wisely.