►
From YouTube: IETF103-LPWAN-20181106-0900
Description
LPWAN meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
A
B
E
C
Hello,
everyone
Pascal
said
this
is
the
LP
one
working
group,
and
this
is
some
ITF
meeting.
So
I
see
no
ITF
meetings.
The
please
read
the
note.
Well,
so
all
the
regular
Apr
rules
applies
if
you're
aware
of
any
Apr.
Please
do
say
so
or
don't
talk
about
it
here,
so
everything
that
you
say
is
considered
as
an
ITF
contribution.
Also
everything
that
you
write
on
on
Java
or
on
the
on
the
meet
echo
and
also
please
do
read
the
code
of
conduct
and
all
the
BCPs
that
are
listed
on
this
note.
C
Well,
you
know
why
are
you
participating
here
so
as
a
reminder
minutes
are
taken,
we
have
similar,
so
we
have
our
minute
takers.
Thank
you
very
much
evil,
oh
and
Carlos,
for
agreeing
to
do
this
and
thanks
Tomas
or
the
backup
as
minute
taker
and
our
jabber
scribe
a
Cedric
for
this
meeting.
And
yes,
please
do
sign
the
blue
sheets
when
you
see
them
circulate
so
the
minute
taking
takes
place
in
the
ether
pad,
so
you
can
go
to
the
agenda
click
on
lp1
and
then
you
can
have
this
thing.
So
this
is
official
link.
C
So
today
we
have
a
pretty
tight
agenda
because
with
the
new
timing,
there
are
maximum
of
two
hours.
That's
when
we're
very
happy
to
have
this
time.
So
we
squeezed
a
little
bit
different
type
of
the
different
presentations
that
were
in
the
agenda
announced
two
weeks
ago,
because
we
wanted
to
spend
a
little
bit
more
time
on
discussion
with
rich
chattering.
C
So
we'll
have.
The
bulk
of
the
time
will
be
dedicated
to
the
announcement
to
the
advancement
in
the
reworking
of
the
IP
UDP
shake
draft,
and
then
we
have
some
other
presentations
for
sig,
Fox
Laura
when
I
Triple
E
and
then
some
other
discussions
on
the
rich
chattering.
So
do
you
have
any
adjustments
that
you
would
like
to
make
it
to
the
agenda.
C
No
adjustments,
so
we
can
just
move
on
and
you
know,
go
I'm
doing
this
very
shortly,
so
that
we
have
more
time
for
the
for
the
real
work
here.
So
we
have
just
a
little
reminder.
We
have
our
status.
We
had
our
two
charter
items,
the
first
one,
the
first
one
is
done,
we're
working
on
the
second
one
and
it
is
going
to
be
the
basis
for
the
new
chattering
we'll
be
talking
about
this
later.
So
we've
been
very
active.
A
C
Past
five
years
and
in
between
so
every
time
at
every
idea
for
five
time
in
a
role,
there
is
a
hackathon
and
we
have
quite
a
lot
of
interim
meetings.
We
had
five
intern
meetings
since
the
last
ITF.
So
please,
if
you
are
interested
in
following
this
work,
you
are
very
welcome
to
to
participate
to
these
interim
meetings.
They
are
announced
and
accessible
over
the
internet,
really
very
open
discussions
and
very,
very
interesting
things
happening
over
there.
C
A
short
reminder
of
what
happens
and
this
with
this
I'm,
going
to
pass
the
word
to
Dominique
afterwards
is
the
main
working
document
that
we
are
focusing
today
is
the
shake
for
IP
UDP.
So
we
had
working
group.
We
entered
a
working
group
last
call
in
around
the
beginning
of
this
year,
and
we
had
a
lot
of
work
done
actually
to
clarifying
a
lot
of
aspects
until
the
the
pasta
last
night,
yet
in
July,
and
we
actually
really
were
very
happy
with
the
compare
the
part
of
the
compression.
C
So
we
declared
success
the
compression
part,
but
the
draft,
but
there
were
some
ideas
of
how
these
things
could
be
improved
in
the
fragmentation
part
and
also
make
the
document
a
little
bit
more
readable.
So
the
the
team
really
worked
really
hard
during
the
summer
and
thank
you
very
much
guys
for
the
team
for
for
that
work
and
today
we're
very
happy
with
the
fragmentation
part
and
we'll
be
starting
working
with
Pasco
after
days
after
this
idea
and
with
this
I'm
going
to
pass
the
work
to
Dominique.
So
we
can
switch
slides.
C
F
F
So
for
those
of
you
who
are
new
to
this
group,
maybe
you
come
here
for
the
first
time,
just
to
recap
what
I'm
talking
about
this
draft
is
about
three
things
and
they're
all
in
one
draft
for
historical
reasons,
but
anyway,
so
there's
a
generic
compression
engine
ahead.
Russian
engine,
that's
here
in
the
stack
there's
a
generic
fragmentation
protocol,
that's
below
it
and
there's
the
application
of
compression
for
ipv6
and
UDP
headers.
So
this
how
this
generates
stuff
is
used
for
this
part.
F
So
these
are
the
free
deliver
bound
3
things
that
you
will
find
is
draft
the
other
things
which
are
how
you
apply
all
this
generate
stuff
to
a
given
LP
one
technology.
This
is
in
separate
drafts
that
are
discussed
in
this
session.
After
my
presentation
or
in
other
drafts
that
are
not
going
to
be
discussed
today.
F
Ok,
what
has
happened
since
last
meeting?
So
if
you
have
been
following
the
work
on
this
draft
the
over
the
summer,
we
mostly
focused
on
fragmentation,
we
believe
compression
is
done.
We
had
a
working
group
last
word
on
that
in
the
first
half
of
this
year,
but
we
said
we
would
rework
the
fragmentation
part
for
in
some
requested
game
at
Memorial
and
before
so
also
no,
we
designed
a
new
icon
note
over
the
interim
meetings
and
we
also
extensively
rewrite
this
fragmentations
section,
even
though
some
things
were
not
change.
F
F
So
in
the
abstract
and
introduction
section
with
slightly
improved
the
text
and
we've
introduced
the
notion
of
profile
that
was
I
swore
by
Pascal,
rightfully
I
believe
and
we've
removed
the
assumption
that
there's
no
out
of
order
delivery,
which
was
present
right
in
the
introduction
before
that,
because
we
believe
now
that
one
of
the
modes,
the
fragmentation
which
does
work
without
a
halt
that
delivery.
So
we
remove
that
statement.
F
The
energy
section
was:
they
did
according
to
Charlie's
comments
that
if
you
don't
use
fragmentation,
you
shouldn't
have
to
read
about
fragmentation
terms
and
variables,
etc.
So
the
fragmentation
terminology
has
been
moved
into
the
fragmentation
section.
So
if
you
want
to
ignore
fragmentation,
it's
easier
I.
F
F
Then
we
have
this
PDP
ipv6
compression
using
the
general
compression
engine
which
now
image
mentions
how
you
handle
the
Sen
bits.
If
you
have
them,
that
was
a
request
in
monrell
and
improves
the
text
a
little
bit,
and
then
we
updated
the
appendices
mostly
to
reflect
the
changes
in
the
fragmentation
material.
F
F
F
Okay,
so
this
is
something
we
have
to
go
to
every
time.
Ticket
stages
so
bear
with
me,
since
monorail
me
vote
in
two
new
tickets
that,
on
our
first
take
it
23
with
something
related
to
the
description
of
the
MIT
computation,
and
since
we
totally
rewrote
that
section,
the
comment
is
no
longer
valid.
So
it's
closed
and
to
get
twenty
whoops
okay
number
and
we
stake
here.
F
A
F
F
Ok,
so
now
moving
to
the
meat
of
the
presentation,
these
the
restructuring
of
the
fragmentation
section.
So
if
you
have
read
this
before
in
the
16
draft,
what
you
can
expect
from
reading
17
is
a
totally
new
structure
of
the
section
8,
and
it's
been
later,
such
that
the
description
of
the
tools
you
can
use
to
do,
fragmentation.
The
tools
are
messages
that
you
change
back
and
forth.
Carrying
data
are
carrying
acknowledgements
carrying
reports,
etc.
F
The
the
notions
that
you
use
to
do
the
fragmentation,
which
are
tiles,
which
are
pieces
of
data
windows
which
are
bunches
of
times,
manipulated
together,
bitmaps,
which
are
used
to
acknowledge,
which
style
you
have
received
in
a
window,
timers
counters
at
a
trial.
So
you
have
a
listing
of
all
the
stuff
and
what
they
look
like
and
even
to
me,
the
the
last
part
is
the
algorithm.
It's
what
you
doing
with
all
stuff.
F
So
again,
news
here
is
those
kind
of
graphs.
A
packet
is
cut
into
pieces,
called
ties
they
may
or
may
not
be
of
the
same
size.
Some
words
require
that
they're
the
same
size,
but
some
don't
and
if
you
call
them
by
Windows
and
you
have
a
window
number
a
tile
number
into
a
window
and
then
you
might
manipulate
stuff
with.
G
F
We
have
made
the
credits
distinguished
distinction
between
the
pieces
of
data,
which
are
the
tiles
and
the
messages
which
we
called
check,
fragments
if,
in
earlier
versions
of
the
draft,
there
was
a
confusion
between
the
piece
of
data,
and
that
is
carried
by
a
message
that
sends
that
piece
of
data.
So
now
the
decision
distinction
is
very
clear
and
you
can
have
one
message
that
carries
several
pieces
several
times.
B
F
A
F
A
F
A
F
Know
a
clue
you
cut
as
you
send
messages
you.
Can
you
get
enough
of
data
that
fills
your
into
frame,
and
so
that
could
be
different
sizes?
We
don't
have
to
have
them
in
the
same
size
because
you
don't
intend
to
every
transmit
them
anyway.
So
in
the
in
the
general
description,
we
don't
mandate
that
tiles
are
the
same
size,
but
in
each
of
the
modes
Noack
a
corner
is
a
corner
we
do
specify
if
they
need
to.
H
You,
okay,
so
we
go
in
more
detail
on
a
corner
because
there
is
a
lot
of
change
since
last
ITF.
So
we
have
a
lot
so
I
remind
you
that
the
goal
of
a
corner
is
to
minimize
the
number
of
acknowledgment
that
we
are
going
to
set.
So,
in
fact,
as
the
name
says
when
you
are,
when
you
see
that
something
is
missing,
but
you
send
an
acknowledgement
and
when
everything
is
correct,
you
don't
send
an
acknowledgement.
H
So
the
goal
of
this,
of
course,
is
to
reduce
the
number
of
acknowledgment
you
will
have
and,
for
example,
in
some
lp1
technology,
when
the
link
is
a
symmetric,
for
example,
don't
link
is
very
expensive.
View
is
good
to
minimize
the
number
of
darlings,
so
we
have
only
one
acknowledgment
that
is
mandatory
is
the
one
that
acknowledged
the
old
one
Windows
and
let's
say
that
this
the
end
of
a
transmission.
So
we
never.
H
H
The
fragment
are
also
ties
with
a
unique
number
which
will
be
composed
of
the
W
number,
the
window
number
and
the
FCN,
and
when
you
will
get
an
acknowledgement,
this
acknowledgement
will
get
the
window
number
and
a
bitmap,
but
we
represent
the
FCM.
So
this
way
we
are
can
also
limit
the
size
of
the
acknowledgment
because
we
can
have
a
way
to
to
solve.
H
This
is
to
have
a
very
big
FCN
field,
and
this
way
we
will
have
only
one
window
and
we
send
a
bitmap,
but
we
have
we
can
have
trouble
because,
of
course,
this
bitmap
can
be
too
long
for
further
feedback.
So
this
way
we
continue
to
cut
it
into
pieces
and
it
solve
a
lot
of
things
and
the
other
thing
that
is
good
with
having
a
large
w
is
that
now
each
packet,
each
chef,
see
if
Steiff
has
a
unique
number,
and
so
we
don't
need
to
synchronize
very,
very
strongly
the
sender
and
the
receiver.
H
So
it's
simplified
also
a
lot
the
implementation
of
the
receiver
and
the
sender.
So
what
is
the
benefit?
So
you
you
have
it
here
in
them
in
the
ring
here
so
W,
instead
of
being
one
bit
here,
can
be
any
size.
So
what
could
be
this
size?
So
here
we
take
an
example
to
to
compute.
So
this
is
maybe
the
worst
case
scenario,
because
we
have
tired.
So
you
need
that
we
are
sending.
They
are
on
six
six
byte.
So
if
you
look
at
current
technology,
the
worst
case
is
eight
byte.
H
So
six
bytes
means
that
I
have
a
six
byte
of
information
and
2x2
feeders
and
we
take
the
largest
packet.
We
will.
We
have
to
send
this
one
1280
bytes
and
if
we
do
the
computation,
it
means
that
we
need
5
bits
for
the
W
field.
We
have
three
bits
here
for
the
FCM,
so
all
the
numbering
of
tires
will
be
on
one
byte.
So
it's
a
little
bit
more
of
at
what
we
have
in
icon
error,
because
not
open
error.
We
can
do
it
in
4
bytes.
H
Here
it's
the
double,
but
it's
it's
not
something.
That
is
a
realistic.
So
we
with
that-
and
of
course
this
is
for
the
worst
case,
so
you
can
imagine
to
have
several
rules
in
your
context.
One
rules
for
large
packet
with
a
large
W
field
and
for
small
packet,
but
a
more
comment,
another
rule
that
will
have
sort
of
fields,
because
it's
something
that
is
common
and
you
use
it
more
often.
So
this
is
quite
flexible
to
two
years.
H
So
as
I
say,
we
don't
need
now
a
very
strong
synchronization
between
the
sender
and
the
receiver.
In
fact,
the
sender
is
sending
all
the
times
and
the
receiver
is
sending
from
time
to
time
a
bitmap.
Let's
say:
I
have
not
received
this
information.
I
have
not
received
this
information.
When
I
send
a
receiver
I
received
a
complete
window,
then
it
will
not
acknowledge
it.
It's
Akane
bro,
so
we
just
acknowledge
or
we
send
a
feedback
for
for
error.
H
So
it's
as
I
said,
simplify
everything
and
here
so
we
we
have
the
example
that
Dominique
has
shown
before
it
means
that
we
have
in
a
corner
or
social
all
the
ties
at
the
same
size.
What
we
do
is
we
can
send
a
packet,
a
chic
packet,
a
chic
fragment
with
only
one
tile,
but
we
can
also
send
a
fragment
with
several
tiles
on
it.
It's
next.
H
Okay
yeah,
so
we
so
we
send
a
Lister.
A
group
of
tiles
here
that
are,
and
that
have
a
size
on
this
side
is
empty.
You
of
your
a
packet.
So
here
it's
not
really
so
you
have
a
window.
So
here
we
have
a
real
numbering,
so
we
increase
the
window
number
and
we
decrease
the
FCN
value.
So
you
start
with
zero
four
zero
streaks.
It
directs
try.
So
you
reach
the
end
of
a
window.
Then
you
send
the
next
window
so
four,
three,
two
one:
zero
extra,
etc,
etc.
H
Until
you
finish
to
send
all
your
types,
so
the
last
tile
here
can
be
smaller
than
the
normal
size
of
that
you
have
fixed
for
your
fragmentation.
So
what
you
have
to
do
when
you
have
a
specific
technology,
is
to
select
a
tile
value
or
tile
ends
that
can
walk
well
for
all
your
empty
use,
final
port
in
roja
one!
We
have
all
these
MTU,
so
the
smallest
one
is
11
by
so
you
have
of
code
to
take
into
account
the
fragmentation
either.
H
So,
for
example,
if
you
take
a
style
of
8
bytes
and
it
unter
into
11
empty
you
extra
answer,
so
you
can
put
more
ties
when
you
are
33
X
direction.
So
you
can
increase
the
number
of
ties
you
are
sending.
If
your
empty
will
change
and
increase,
and
if
you
empty,
you
decrease,
you
can
reduce
the
number
of
ties
you
are
sending
so
Y.
H
If
you
have
received
the
previous
fragment
and
you
have
value
from
6
to
4,
then
you
don't
acknowledge
this
one
and
if
you
receive
the
next
fragment
with
0
0
same
thing,
you
will
not
acknowledge
this
window,
so
this
small
numbering
of
ties
will
not
generate
more
traffic
on
the
radio.
So
that's
the
magic
of
this,
and
the
advantage
is
that
we
can
adapt
to
a
change
during
your
transmission
and
we
go
to
this
unit.
That
is
what
is
a
type.
So
here
we
have
an
example.
H
We
have
at
the
beginning
a
MTU
that
has
to
send
10
times,
so
we
are
sending
the
first
one,
so
the
receiver
receive
it.
The
first
window
window
0
is
full,
so
we
will
not
send
acknowledgement
the
second
window
window.
1
is
not
full,
but
it's
a
normal
process.
So
we
don't
send
anything.
We
wait
for
the
nest
fragment.
We
send
another
fragment
here.
This
fragment
is
lost,
so
the
receiver
saw.
H
The
sender,
of
course,
doesn't
know
it
send
another
fragment,
and
here
we
have
in
the
numbering
we
have
somehow,
and
so
some
bits
are
not.
The
bitmap
is
not
full.
So
in
that
case
the
sender,
the
receiver
may
decide
to
send
the
the
bitmap
and
it
takes
the
first
one
that
is
not
full,
and
so
it's
for
window
one
and
it's
okay.
In
window,
one
I
have
received
with
three
fragment
of
these
three
tiles,
and
then
these
are
missing.
H
The
sender
can
have
different
behavior
and
it's
something
new,
but
we
didn't
take
this
before,
is
that
we
have
now
to
specify
and
that's
why
we
go
to
the
name
of
profile,
because
we
have
to
define
also
the
behavior
when
you
can
send
the
acknowledgment.
So
in
actual
ways
there
is
no
mystery
after
all
or
zeros.
You
have
to
send
an
acknowledgment
here,
since
we
don't
have
this
strong
synchronization
between
the
sender
and
the
receiver.
H
You
can
send
the
acknowledgment
at
some
point
of
time
that
are
known
by
the
sender
and
the
receiver,
but
I'm
not
only
at
the
end
of
a
window.
It
can
be,
for
example,
at
the
end
of
the
packet,
so
you
send
all
your
fragment
and
when
you
are
finished
you
send
all
the
sender
will
wait
for
the
acknowledgment
and
then
we
resent
things
that
are
not
been
received
by
the
receiver
or
you
can
imagine,
are
also
some
over
technology.
H
Like
spotted
technology,
where
you
have
a
channel
that
is
slower
for
acknowledgement
and
then
you
can
send
visa
acknowledgement
during
these
slots.
So
here
we
have
a
lot
of
flexibility
in
the
way
we
are
going
to
do
the
acknowledgement
and
of
course,
the
sender
and
the
receiver
asked
to
agree
on
the
way
at
the
time
where
the
acknowledgement
has
to
be
sent.
So
it
is
specified
in
in
the
profile,
so
the
profile
will
specify
the
size
of
all
fields
on
also
some
parameter
like
the
behavior
of
the
other
state
machine.
H
So
here
what
we
have
so
we
we
know
now
that
things
are
missing,
but
the
MTU
change,
so
them
do
change.
So
now
you
adapt
and
you
retransmit
a
fragment
that
contained
only
three
tires,
so
you
complete
a
little
bit
your
window
is
not
finished,
then
you
send
another
one.
It
finished
the
window.
We
finished
this
window
so
window.
H
One
now
is
full,
so
we
remove
it
from
the
acknowledgement
and
windows
store
is
not
full,
so
we
receive
as
a
receiver
will
send
an
equation
extra
extra
until
all
the
missing
fragment
as
we
transmit
and
we
go
to
the
old
one,
and
then
we
have
an
acknowledgement
for
your
one
that
say
Miko
Kay
and
in
that
case,
of
course
it's
and
we
know
that
the
packet
has
been
sent.
So
that's
the
way
the
protocol
works.
So
it's
quite
it's
very
powerful.
H
H
We
just
send
a
very
small
message:
let's
say:
Mike,
okay,
so
it's
few
bytes,
let's
say
I
have
well
receive
information
and
in
case
your
transmission
is
not
so
good.
Then
you
increase
the
number
of
acknowledgment
you
have
to
resit.
So
we
are,
we
are
going
now
to.
We
are
doing
some
studies,
but
in
fact
the
worst
case
is
when
you
have
one
missing
fragment
in
each
window,
in
which
case
you
have
to
send
an
acknowledgment
for
all
these
window.
H
If
you
have
more
than
one
missing
packet
by
window,
you
are
winning,
because
you
send
only
one
feedback
for
for
this
window,
and
if
you
have
no
misses
in
in
your
window,
then
you
send
nothing.
We
with
that.
We
can
adapt
to
MTU
variation,
which
was
not
so
obvious,
and
the
cons
of
this
is
that
we
have
W.
That
is
a
little
bit
larger,
but
is
not
so
so
bad.
H
For
example,
if
you
have
downlink
fragmentation,
you
need
to
receive
an
uplink
to
send
the
next
darling
message,
of
course,
is
since
we
are
reducing
the
number
of
acknowledgment,
then,
of
course
it
will
not
work.
So
we
we
have
to
impose
a
message
every
time
all
we
have
to
see
we
flare
to
technology
if
there
is
not
some
way
to
send
modern
links
consecutive
without
optics.
So
it
means
that
here
we
have
a
very,
very
nice
fragmentation
protocol
that
works
quite
very,
very
efficiently
for
lp1
networks.
Okay,
if
you
have
question
done.
B
As
a
chair
of
this
working
group,
I'm
very
proud
of
the
work
and
how
it
happened,
and
this
particle
draft
and
the
particular
the
reaction
to
the
group
last
call
crimes
and
the
fragmentation
and
how
all
the
team
has
been
working
hard
to
summer
to
fix
that
and
produce
this
absolutely
excellent
solution
for
what
is
prom.
So
thank
you
very
much
Aloha
and
unique,
and
and
also
one
tell
us
and
all
the
guys.
B
You
think
about
two
things:
you
know
that
loja
is
one
of
our
kind
of
customers
for
this
work
at
the
ATF
and
I've,
attended
meeting
like
a
month
ago,
where
they
were
discussing
how
they
would
what
they
needed
for
fragmentation,
how
it
could
happen,
and
so
there
was
this
technical
proposal.
I
can't
detail
the
proposal,
but
what
struck
me
is
that
it
was
done
completely
in
parallel
to
what
has
happened
here.
B
They
studied
what
they
needed
and
how
it
could
work
and
how
to
make
it
hot
emo,
and
there
was
this
guy
Marc
who
presented
his.
Is
you
on
that
and
solution?
It
was
like
95
percent
exactly
the
same
as
a
Canora.
It
was
incredibly
very
much
the
same
and
it
was
done.
Total
in
polish
was
completely
unaware
of
this
draft,
which
tells
us
that
we
are
very,
very
close.
It's
like
having
to
to
implementation
that
work
together
here.
B
It's
like
two
designs
that
converge
to
pretty
much
the
exact
same
operation,
and
so
I
told
that
to
markings
and,
and
then
I
gave
him.
You
know
the
access
to
the
drafters.
It
was
still
a
draft
and
you
read
it
and
his
conclusion
was
well.
That's
that's
exactly
what
we
need
right,
so
I
hope
I
mean
know
how
we'll
be
discussing
what
they
do
right,
but
but
there
is
this
clear
hope
from
my
standpoint,
that
that
our
solution
and
the
convergence
of
IETF
and
know-how-
one
are
this
particular
subject.
B
That
next,
so
that's
one
thing
and
then,
since
he
did
all
his
thinking
total
parallel
to
what
we
are
doing
here,
I
asked
him
how
he
saw
it
working
in
particular,
when
you
have
the
downlink
that
that
you
are
talking
about.
So
the
data
is
coming
from
the
internet
and
and
the
device
is
as
to
in
class
a
type
of
operation
which
is
also
close
to
to
what
seefox
does
you
have
to
pull
the
data?
B
B
You
was
like
the
device
is
doing
its
own
life,
he's
sending
its
data
like
publishing
its
measurements
or
whatever,
and
each
time
effectively
completely
asynchronous
to
to
to
the
fragmentation,
but
each
time
he
sends
one
data
you
will
receive
one
fragment
and
that
can
last
for
days.
So
his
vision
was
not
like.
Let
me
pull
fragment,
pull
the
fragment
or
the
fragment
so
that
in
the
next
hour,
I
have
the
message:
no
I
would
publish
a
data
like
daily
and
they
will
get
a
fragment
age.
B
You
see
instead
of
for
some
information,
which
you
don't
need
tomorrow,
right
like
the
next
image
that
you
will
refresh
the
mouth.
This
is
you
as
like.
You
will
just
exploit
the
fact
that
your
data
resolve
and
to
get
the
next
fragment,
but
this
fragmentation
process
that
you're
describing
may
last
for
days.
So
it's
just
a
way
of
figuring
that
out
that
just
strike
me
as
as
surprising,
like
Yannick,
that.
C
Yes,
in
terms
so
to
tour
to
to
this
point,
I'm
also
really
glad
to
do
the
whole
work
that
that
was
done
during
the
summer
time
and
after
so
that's
really
some
amazing
job
guys
and
the
last
height.
Yet
there
were
these
discussions
that
okay.
Well,
we
feel
that
everything
is
working
really
well,
but
we
could
do
like
we
can
find
some
way
to
really
improve
the
efficiency,
and
so
that
was
efficient.
C
That
was
essentially
the
work
that
was
done
during
the
summer
and
this
huge
work
of
actually
improving
the
readability
and
applying
all
the
things
that
were
that
were
set
during
the
last
IDF,
so
huge
thanks
for
for
doing
that.
Work
and
I'm,
also
very
so
hopeful
about
actually
getting
this
technology
to
be
in
the
core
of
all
LP
or
all
major
LP.
C
One
technologies
right
so
I
think
that
if
we
really
get
the
adoption
from
the
lower
Alliance
and
sig
Fox
is
here
and
enbe
IOT
and
LTM
to
use
shake
in
the
core
of
the
fragmentation
and
in
the
in
the
compression,
which
was
not
initially
the
the
goal
for
a
fragmentation
right.
But
that
would
be
also
something
really
really
amazing
and
yes,
so
we'll
be
starting
so
to
the
fragmentation.
C
Part
has
is
now
pretty
pretty
pretty
like
really
improved,
so
it
we
feel
that
it's
ready
for
working
group
last
call
to
to
start
after
this
after
the
IGF
after
this
idea-
and
please
do
provide
your
comments,
so
the
compression
part-
it's
we're
clear
on
that,
so
don't
spend
too
much
time.
There
I
mean
you
can
add
some
minor
editorials
or
if
you
find
some
be
no
typos,
but
please
do
focus
on
the
fermentation
and
I
would
be
so.
We
will
be
talking
about
you
chartering.
C
We
were
very
clear
with
with
Suresh
that
we
will
be
able
to
rechart
her
after
we
submit
the
document
to
the
ASG,
so
I
would
really
I
would
love
for
us
to
send
the
document
to
the
energy
before
15th
of
December.
This
way
you
know
it's
like
not
just
before
the
holidays,
so
this
means
that
you
know
if
you
want
to
provide
some
feedback,
please
do
it
it's
now
right.
C
I
Yeah,
so
that's
fine,
like
that,
makes
sense
to
me,
but
nothing's
gonna
happen
to
the
drafts
really
like
before
January.
If
you
send
it
in
15th
of
December,
usually
it's
not
considered
good
form
to
do
a
light.
Ef
last
call
during
the
holidays,
so
I'm
gonna
have
to
hold
off
until
January.
So
if
it
comes
to
me
by
the
1st
of
December,
I
can
probably
get
it
done,
like
the
last
call
done
before
the
end
of
the
year
and
then
put
it
on
a
tell.
I
B
Just
to
yes,
it
really
depends
on
the
amount
of
comments
that
we're
going
to
get
so
we
launched
the
workgroup,
let's
go
unless
somebody
now
comes
to
the
mic
and
say
we're
not
ready.
We
launched
the
workgroup
last
call
right
at
the
end
of
this
meeting
for
like
two
weeks
and
just
depending
on
the
amount
of
work
has
to
be
done
to
resolve
the
issues.
Since
we
already
wants
to.
Let's
go
for
the
compression
and
for
for
most
of
the
fragmentation.
I
don't
expect
that
we'll
get
so
much
concern.
Yeah.
G
I'm
Charlie,
Perkins
and
I'm,
not
meaning
to
complain
or
to
make
big
delay
or
anything,
but
I
just
want
to
mention
that
it's
a
highly
non-trivial
protocol
design
and
fragmentation
in
general
is
known
to
be
a
source
of
aggravating
bugs.
So
you
should
also
solicit
the
detailed
opinions
and
reviews,
as
well
as
trying
to
get
people
to
do
it
in
a
hurry.
B
Certainly,
the
fact
is
Glasgow
with
you
will.
We
are
asked
to
have
a
deep
focus
on
the
fragmentation,
so
the
document
is
huge
enough
and
there
is
many
things
but,
like
you
point
out,
the
the
changes
in
/wel
group
last
call
I'll
hide
the
fragmentation.
So
so,
knowing
that
we
can
focus
on
this
piece,
we
hope
that
in
the
next
2-3
weeks,
people
can
can
actually
give
us
the
review.
The
other
thing
is,
there
are
implementations
around
here,
at
least
two
that
I
know
of
so
that
helps
a
lot
get
some
bugs
out.
J
You
very
much
so
I'm
from
California
from
cheek
Fox
I'm,
presenting
an
update
to
the
Schick
over
seek
Fox
with
the
quarters,
cardless
and
and
Laura
I'm,
pointing
here
to
version
4,
there's
already
a
version
5
that
was
updated
a
couple
of
days
ago,
but
it's
very
minor
clarifications
and
details
anyway.
This
is
this
is
work
in
progress
because,
of
course,
it's
based
on
the
on
the
latest
version
of
the
authorship
craft.
That
was
publishers
at
the
very
end
of
the
of
the
cut
off.
J
J
A
J
Exact,
we
were
having
exact
same
conversation
like
well.
Now
we
can
just
get
downlink
packets
for
ages
and
then
say
by
the
way
the
last
year.
You
send
me
something
and
I
need
this
one
fragment
and
it
will
work.
So
we
need
to
rethink
that
down,
leek
and
and
so
far
the
draft
is
not
reflecting
that
icon
error
possibility
that
it's
opening
up.
So
that's
a
part
that
it
still
needed.
I
guess
but
I
want
to
just
clarify,
because
last
time
I
showed
this.
J
If
you
remember,
the
proposal
at
the
time
was
to
be
able
to
go
back,
not
one
but
two
windows,
but,
as
Lauren
just
explained
with
this
new
possibility
is
not
to,
but
it's
very
much
up
to
the
designer
how
many
windows
you
go
in
the
past,
so
so
the
issue
has
been
not
only
solved
but
actually
improved
a
lot
in
the
the
way.
The
protocol
now
works
again,
opening
up
a
whole
bunch
of
new
possibilities.
J
So,
for
that
reason
right
now,
the
text
is
proposed
to
be
mandating
the
make
for
the
for
the
UDP
transport,
but
leaving
it
open
to
the
to
the
specific
technologies
for
for
non
UDP
traffic,
and
so
actually
this.
This
will
be
perhaps
a
question
for
Suresh
I,
don't
know
so
far.
The
do
you
see
an
issue
if
we
even
mandated
it,
we
mandated
that
they
make
for
for
UDP
traffic,
and
we
leave
it
open
for
the
for
other
type
of
traffic,
because
that
that's
been
a
discussion
with
internally
whether
this
is
acceptable.
Yes,.
I
G
so
description,
so
I
personally,
don't
see
an
issue,
but
if
something
comes
up
in
the
iesg
like
I
would
of
course
like
wanting
to
be
handled
at
the
time
right.
So
I
don't
want
you
to
worry
about
like
pre-empting
stuff
in
the
ESG,
even
though
that
it
might
come
up
as
an
issue,
but
I
personally,
don't
see
it
like
you
know.
If
you
have
UDP
cover
I,
don't
see
an
issue
right
now,
but
it
does
something
does
come
up
like
we
can
handle
it
at
the
time
so
and
I'm
open
to
that.
I
If
the
mouton
group
is
okay
with
that,
so
that's!
So
if
you
see
consensus
here
to
just
say
you
rupees,
like
mandatory
everywhere
else,
like
figure
it
out
right,
that's
okay!
As
long
as
it's
clear
what
somebody
needs
to
do
right
for
a
given
scenario
and
you
can
still
have
Interop
implementations,
that's
pretty
much
like
my
worry,
so
other
than
saying.
Okay,
like
I'll,
do
some
hand
wavy
stuff.
That's
not!
Okay!
Right.
J
So
that'll
be
part
of
the
groove
definition,
but
yeah,
that's
a
good.
That's
a
good
feedback.
The
in
danger
of
variability
I
think
the
it
has
to
be
with
the
profiles
and
and
all
the
discussions
that
women
have
in
so
we
have
to
know
there
are
a
lot
of
optional
parameters,
so
we
have
to
know
precisely
what's
what
the
agreement
between
the
two
the
two
sides
before
before
they
Pascal.
B
I've,
been
we've
been
discussing,
one
pot
plot
and
related
to
UDP
is
the
UDP
checksum.
So
the
real
problem
with
UDP
is
the
UDP
checksum
in
6lowpan.
We
I
was
doing
that
so
I
went
through
the
hassle
of
convincing
the
iesg
that
we
could
alight.
In
some
cases
the
UDP
checksum
before
before
that
there
was
the
case
of
tunnels
and
and
the
SG
understood
that
you
don't
have
to
have
a
UDP
checksum
inside
the
UDP
checksum.
When
you
turn
on
UDP
into
UDP
or
something
right,
6.1
was
a
bit
difference
is
at
the
transport
level.
B
We
know
we
have
an
additional
message:
integrity
check,
which
is
actually
larger
they
and
then
the
UDP
checksum,
and
that
covers
the
the
what
goes
into
the
pseudo
adder
that
is
used
in
the
UDP
checksum
computation.
So,
basically,
with
6lowpan,
we
have
this
capability
to
signal
from
transport
down
to
a
six
weapon
area.
A
guy
I
have
a
make
message
sure
to
check
which
is
encompassing
what
the
UDP
checksum
would
do,
which
is
better
than
what
do
you
do
a
checksum?
You
would
do
so
you
don't
have
to
transmit
the
UDP
checksum.
B
B
Point
being
that
the
UDF
I
do
understand,
my
understanding
of
this
particular
premise
is
about
compressing
the
UDP
checksum,
it's
not
just
which
transporter
use
is.
Can
you
compress
the
UDP
checksum
and
that
will
be
a
fight
because
because
right
now
the
make
is
not
the
transport
light
6lowpan,
it's
an
underneath
layer,
2,
and
so
we
will
have
to
explain
exactly
when
we
think
we
can
reasonably
Enlai
UDP
checksum
and
we
will
have
to
convince
the
instance
is
above
that
we
don't
break
IP
or
UDP
by
alighting.
F
B
B
Technology
document
can
propose
a
way
to
below
for
alighting
the
checksum,
but
it
will
have
to
prove
that
we
are
not
losing
anything
because
otherwise
that
will
be
effect
when
it's
coming
from
transport.
I
mean
it
comes
after
the
UDP
cancellation
and
decapsulation.
So
we
know
we
protect
the
inside
of
the
UDP.
If
you
do
it
underneath
even
for
fragments.
There
is
a
time
in
the
stack
where
you
have
a
UDP
checksum,
which
has
been
recomputed,
and
you
have
lost
already
the
the
protection
of
the
mix.
So
it
is
a
slightly
different
things.
I
Be
prepared
and
let's
have
good
appearance
right
krishnan,
so
Pascal
can
I
said
just
something
so
I
I
see
that
you're
worried
about
something
I,
it's
not
clear
to
me
what
exactly
that
is
right.
So
if
you
can
write
up
like
saying,
okay,
like
you
know,
if
there's
bit
corruption
here
or
like
some
bitter
happening
here
like
what
exactly
happens
right
so
throw
the
scenario
like
you
know,
Juan,
Carlos
and
Dominique,
and
then
we
figure
out
from
there
like
you
know,
is
it
going
to
be
caught
or
not?
It
was
like.
I
We
did
the
same
exercise.
We
did
the
zero
UDP
checksum
in
six-man
right.
We
said.
Okay,
like
you
know
what
happens
like
okay,
let's
say
the
port
gets
corrupted
right,
so
is
it
going
to
be
detected
or
not
right
and
that
kind
of
thing
so
like
we
can
probably
do
like
take
like
a
failure
case,
and
then
we
discuss
it
and
see
where
we
go
from
there.
I
So
if
something
else
is
going
to
catch
it
then,
like
you
know,
everything
started
out
and
then
good
thing
is
like
we
you're
happy
here
and
then
we
have
like
already
a
paper
trail
like
for
the
ESD
saying:
oh,
we
thought
about
it.
This
is
how
it's
gonna
get
caught
and
then
it
helps
us
just
like
think
of,
like
whatever
like
to
throw
all
the
failure
scenarios
that
are
possible
in
there,
like
you,
know,
L,
to
starve,
like
l3
stuff,
anything
right
and
then
we
go
from
there
like
you
know
completely.
B
I
Everybody
reads
it
like
I
read
like
Shepherd
riders
for
every
draft,
I
read
before
I,
read
the
draft
Shepherd
right
up
and
say:
okay
like
what
is
the
Shepherd
think
of
it
like?
Is
there
something
funny
happening
in
the
working
group
right
so
I
do
that
so
just
throw
it
in
the
Shepherd
right
up
and
then
like?
We
can
preamp
a
lot
of
the
fight
right.
Let's.
B
J
No,
no
and
I
think
that's
a
good
practical
to
say:
okay,
well
yeah.
This
is
how
we
thought
about
it,
and
this
is
the
solution
and
and
and
yeah
it's
something
to
keep
in
mind
this
as
Dominic
said
that
there's
two
functionalities
right
now:
the
compression
and
the
fragmentation.
So
one
thing
is
aligning
the
the
checks.
I
mean.
Another
thing
is
adding
a
make
up
the
fragmentation
that
also
that
it's
a
well
addressed.
C
So
there
is
conquer,
risking
just
just
for
a
second,
because
we
had
in
the
program.
I
turned
I
didn't
see
the
slide,
therefore,
about
this,
so
we
currently
have
in
the
charter
to
charter
items,
and
the
first
charter
item
is
the
week
that
we've
done
it.
The
second
one
will
be
expanded
and
one
item
there
is
actually
the
technology
dependent
documents
that
yes,
so
you
know,
we've
been
working
quite
a
lot
for
since
the
beginning
right
now,
you're
a
co-author,
also
the
main
document.
So
that's
about
that.
Thank
you
and
thank
you
very
much.
C
J
Didn't
put
a
slide,
but
I
I
saw
it
in
the
right
choice.
Yes
again
now
that
the
the
baseline
graft
is
is
pretty
solid,
of
course,
there's
always
room
for
improvement
that
we
are
going
to
fine-tune
it,
but
it's
pretty
solid,
so
I
think
we
right
now
where
we
feel
confident
that
that
we
can
work
out
the
the
specific
drafting
and
we
would
like
to
go
for
for
working
group
adoption.
If
that's
okay
with
you
guys
and
I,
also
forgot
to
ask
if
there
was
any
question
specific
about
Seahawks.
B
Well,
the
code
for
adoption
is
just
a
call
for
adoption
right,
but
but
yes,
I
mean
we
want
to
work
reply
scroll.
The
other
thing
to
be.
That
is
good
to
know.
It's
good
to
know
that,
and
usually
the
people
have
already
read
the
draft
and
they
just
say
yes,
it's
it's
right.
I
mean
we
don't
expect
necessary
that
they
do
the
review
now
for
for
just
a
call
for
adoption,
but
yes,
I
mean
I,
understand.
I
B
B
I
B
Yes,
I
mean
reach
out
to
ring,
will
put
all
the
milestones,
because
the
point
is
this
was
more
exploratory.
We
want
it
like
the
technology
to
fit
into
the
shake.
So
we
know
the
shake
is
complete
and
thanks
to
work
like
this
I
mean
one
carries,
for
instance,
has
helped
us
tremendously.
Do
the
do
the
shake
thing
to
the
point
that
he
became
hotter,
and
so
that
was
very
important
for
us
to
start
this
work,
but
not
to
complete
it.
We
could
not.
B
Actually
those
trust
will
depend
on
the
trust
which
does
not
exist
yet,
which
will
be
reach
out
about
the
profiles,
because
they
will
have
to
check
on
the
profiles
what
they
declare
here
and
what
is
left
to
implementation,
and
as
long
as
that
work
is
not
complete.
This
work
cannot
be
complete,
so
I
mean
yes,
we
didn't.
We
couldn't
have
a
milestone
so
far,
but
we
wanted
this
work
start.
I
I
I
I
So
you
get
pushed
out
of
the
working
group.
There's
gonna
be
I,
I,
II,
HD
stuff
like
right,
like
you
know,
sometimes
like
four
I'll,
give
you
an
example.
Like
probably
a
bad
example.
You
probably
won't
be
happy
like
six
days
minimal
right.
It
took
like
quite
a
bit
of
time
after
it
got
of
the
working
group.
Multiple
attempts
at
it
and
like
the
cadence
was
completely
lost
because
people
move
on
to
other
things
right
in
the
working
group.
So
that's
kind
of
something
I
want
to
avoid.
C
Okay,
so
it's
it's
understood,
you
need
milestones
and
these
milestones
are
like
dates
and
they
are
dependent,
I'm
actually
getting
shake
to
the
ASG.
So
that's
that's
pretty
clear.
One
of
the
points
that
we
we
were
thinking
about.
This
adoption
was
also
to
signal
to
other
SDOs
that
okay,
there
is
this
document
now
you
know.
If
you
want
something
done,
please
go
and
that
that's
the
document
that
thinks
that
that
work
has
is
getting
done,
but
of
course
yeah.
C
So
we
finished
the
first
chick
in
the
IP
UDP
and
then
in
the
and
then
we
invite
everyone
here
and
the
people
that
also
are
on
the
mailing
list
to
consider
very
deeply
if
they
have
anything
against
adopting
the
different
documents
that
are
accepting,
and
then
we
can
do
a
pretty
like
a
nominating
list
call
for
adoption.
Okay,.
B
The
point
being
that
this
work
has
mostly
enabled
the
technologies
to
are
passed
on
shake
these
documents
are
not
fake.
There
is
very
light
work
actually
being
done
yet
because
they
need
the
real
to
be
there,
but
it
has
helped
build
shake.
And
if
you
look
at
these
three
and
the
deals
over
the
last
like
six
month,
you'll
see
that
the
attention
was
on,
though
so.
K
I
will
start
by
presenting
the
word
since
the
last
idea
and
then
continue
with
next
steps,
so
we
have
not
published
a
new
version
of
the
chart.
We
are
working
on
it
right
now
and
you
can
see
the
reason
for
that
was
the
addition
of
a
canary.
So
we
wanted
to
consider
it
and
implement
I
mean
provide
the
needed
parameters
for
each
version.
K
C
G
B
G
G
Basically-
and
that's
been
an
interest
group
in
a
study
group
and
now
it's
a
group
to
actually
produce
a
standard
and
there's
been
a
number
of
approaches
that
were
brought
forth.
I
listed
them
here
and
I,
don't
really
have
to
I.
Don't
want
to
go
into
detail
because
Ashley
is
not
my
area
of
expertise,
but
I
just
want
to
mention
that
there's
a
surprising
amount
of
creativity
about
this
for
one,
for
instance,
they
have
proposal
where
you
just
have
a
huge
number
of
error.
Correction
bits.
That's
one
possibility
another
possibility.
G
Is
you
do
kind
of
some
sort
of
repeater
operation
where
you
have
extremely
tight
synchronization
between
the
essentially
the
backbone
notes
and
so
on?
So
it's
an
interesting
set
of
proposals,
but
the
last
very
since
the
last
meeting
and
during
the
interims
it
was
determined.
I
should
point
out
that
there's
interim
meeting
as
there's
three
a
year
or
it's
face-to-face
and
then
they
have
teleconference,
which
are
also
called
inner
meetings.
The
sin
Celeste
face-to-face
intermedia.
G
G
G
J
We're
sorry
this
is
your
last
light
on
the
identity.
If
your
thinks
Juan
Carlos
we're
here
so
I
missed
the
last
meeting,
as
you
probably
noticed
and
I'm
just
curious,
because
here
and
when
you
say
a
merge
approach,
you
have
their
whole
list
of
proposals
right,
including
both
mac
and
phy
options
right.
So
everything
I
didn't
do
that.
No.
G
No,
not
everything
it,
but
it
only
proposals
were
deemed
to
have
some
aspects
that
not
be
worthy
of
inclusion
in
the
overall
document.
I
think
that
the
the
main
thrust
of
it
is
I
have
actually
the
diagram
has
shown,
looks
almost
like
a
Tish
60-ish
diagram,
where
they
have
a
sort
of
very
small
fragments
that
are
spread
over
time
and
frequency.
G
G
B
G
C
G
The
reason
was
is
because
mainly
what
we
have
left
to
do
is
to
decide
about
whether
we're
going
to
have
a
fragmentation,
part
of
the
profile
or
not,
and
since
no
I
wanted
to
wait
until
understanding
the
new
release
of
the
document
before
making
any
changes
to
the
document.
So
so
it
hasn't
changed
and.
G
Reading
this
should
release
number
17,
there's
a
convexity
which
is
extremely
interesting
for
document
authors,
because
it
tells
you
what
you
need
to
put
in
your
document
and
since
I
just
saw
that
that
nice
actually
try
to
include
all
the
suggested
guidelines
in
and
parameter
and
profile
parameters,
and
so
which
will
have
the
effect
of
a
reorganizing.
This
document
and
I
fully
expect
that
we'll
have
Oh
1,
maybe
before
next
year,
but
certainly
before
next
IETF.
But
there
is
a
little
bit
of
organizational
detail
about
this.
First.
A
G
All
this
document
is
not
an
official
later
2.15
document
or
not
a
15.4
w
publication,
but
these
as
I
mentioned
these
folks
who
are
interested
in
this,
because
I
do
want
to
appeal
to
an
ipv6
application
domain.
So
this
has
undergone
some
numbers
of
discussion
and
improvement
within
them.
It's
about
15.4
w,
but
there'd
venusaur
a
little
bit
of
an
organizational
change
and
they
do
it
about
15.
There's
this
thing
called
boots.
G
A
G
So
the
last
thing
I
want
to
mention
is
that
under
current
draft,
I'll
show
the
next
slide
just
briefly.
So
what
has
not
changed
since
the
last
idea
was
this
design,
which
basically
we
had
thought?
We
would
just
use
fragmentation
from
the
editor.
Duct
15.4
already
just
specifies
of
fragmentation
technique,
and
we
can
use
that
and
since,
if
we
did
use
that,
we
don't
have
to
worry
too
much
about
these
profile
parameters.
G
But
it
is
an
open
question
whether
the
Schick
fragmentation
is
better
than
a
talk
about
15.4
fragmentation,
and
it
could
be
because
it's
pretty
good,
and
so
we
I
need
to
actually
do
the
arithmetic
on
some
various
cases
like,
for
instance,
UDP
with
ipv6
and
so
on,
and
that's
a
lot
of
sitting
down
in
front
tedious
work.
But
it
really
needs
to
be
done
and.
A
G
G
Well,
maybe
it's
applicable
to
other
a
talk
about
15.4
documents
in
addition
to
4w
now,
whether
or
not
the
four
other
four
documents
really
applied
to
the
static
context,
as
defined
by
this
group
is
a
you
know
very
first
answer
sub
some
areas
about
15.4
work
that
should
be
applied
to
networks
up
to
ten
thousand
and
many
hops
in
a
mesh.
Well,
that's
probably
not
a
good
candidate
for
this,
but
there
may
be
some
other
ones
that
are-
and
so
that's
another
topic
of
discussion
for
next
week,
and
so
that's
my
presentation.
B
Many
many
thanks,
charlie,
how
you
made
me
like
is
like
Shrieves
reactions
to
what
you
said.
The
first
one
is
you
mentioned
that,
because
of
an
XD,
you
will
have
to
reshuffle.
The
document
and
part
of
the
next
discussion
is
about
probably
having
a
narrow
FC
for
an
agreed
like
then
your
full
description
of
everything
you
need
to
profile
and
the
new
document.
Every
every
protocol
specific
document
will
actually
specify
classes
of
profiles
that
are
matching
this
particular
technique.
B
So
I
expect
I
hope
that
we
will
find
some
similarities
in
the
way
the
documents
are
structured.
So
somebody
who
wants
to
see
Oh
what
our
sick
profiles,
what
kind
of
how
do
they
look
like?
How
do
W
profiles
look
like,
or
how
do
you
know
her
profile?
Look
like
the
just
go
to
the
specific
document,
and
they
see
all
these
parameters
must
be
in
that
range.
B
These
are
not
specified
last
two,
but
but
if
the
structure
like
I
said
the
restructuring
could
be
agreed
upon
between
within
those
documents,
then
they
would
all
become
much
easier
to
read,
for
somebody
wants
to
be
of
the
generic
code.
That
would
work
for
all
of
them.
So
yes,
I
completely
agree
that
that's
nice
to
reshuffle,
I
think
you.
You
will
need
the
data
model,
the
full
data
model
that
we
want
to
reach
out
of
412.
These
work
complete
and
it
is
very
good,
but
we're
not
a
complete
set
of
parameters
to
be
narrow.
B
I've
see
that
you
can
refer
to
so
so
then
that's
pretty
much
where
we
think
we
are
going
with
our
chartering.
So
not
only
yes,
you
need
to
do
it,
but
also
maybe
try
to
work
with
the
other
technology
specific
document
to
have
some
original
ways
of
representing
that
maybe
based
on
data
model.
That's
coming
up
well,.
G
So
I
agree
with
you,
but
in
particular
on
the
after
going
through
the
exercise
of
having
an
interest
group
and
study
group
for
the
15.4
W.
One
of
the
outcomes
of
that
was
a
pretty
good
analysis
of
which
radio
modulation
schemes
were
good
for
various
applications
and
in
particular,
we
know
the
kind
of
applications
that
are
to
be
addressed
by
this
work.
And
so,
since
we
know
the
kind
of
applications
we
might
be
able
to
produce
some
of
the
package
formats
and
if
we
can
predict
some
of
the
packet
formats,
we
can
make
better
compression.
G
G
B
The
second
reaction
is,
and
then
again
it's
appraised,
or
this
working
group
guys
all
those
technologies
we've
been
designing.
We
designed
to
shuttle
to
work
on
started
without
IBM
I'll,
be
honest
right
when
you
start
a
new
technology
like
this,
you
you
have
layer
to
your
application
data
over
it
and
you
think
IP
will
never
work.
There.
B
I've
heard
that
for
everything
which
became
6lowpan
and
I've
heard
that
how
everything
that
became
a
LP
one
IP
will
never
work
there,
and-
and
this
w/e
fault
is
the
first
one
which
starts
with
or
IP
is
almost
a
given.
Let's
see
how
she
works
with
us
right,
it's
an
incredible
twist
of
fate
that
now
we
are
in
the
charter
of
the
working
group
of
the
IDF
piece
in
this
case,
but
on
the
technology
piece
before
they
even
start
and
complete.
Do
the
work
right
and
IP
is
not
a
second
thought
here.
B
It's
included
in
the
very
design,
and
that's
because
we
have
shipped
that's
because
we've
been
there,
so
the
price
mode
is
working.
Group
I
mean
I,
really
love
it,
and
the
third
thing
I
had
in
mind
was
we
were
chartered
for
four
technologies
and
one
of
them
was
I
truthfully.
It
was
well,
you
know
which
one
it
was.
It
was
basically
shooting
for
four
subject:
etcetera
there.
B
Why
some
time-
and
there
was
not
much
activity
related
to
my
son,
but
now
we
have
activity
on
W
instead
and
I
was
just
wondering
that
if,
as
we
do,
the
Charter
should
we
and
that
we
you
in
both.
So
should
we
kind
of
twist
from
focusing
on
my
son
to
focusing
on
W.
So
we
would
still
have
four
technologies,
but
maybe
we
would
charter
for
this
one
instead
of
why's,
that
it
doesn't
make
sense
so
I.
A
I
Like
one
thing
just
to
follow
up
on
what
he
said,
one
of
the
things
is
like
I
would
like
to
happen.
So
let's
say
we
want
to
go
in
this
direction
and
say
like
let's
do
like
15
4w
it'll
be
really
good.
If
we
start
talking
about
like
how
the
technology
is
different
from
what
we
put
in
LP
run
overview,
so
that
I
think
that
will
be
really
helpful.
Okay,
because
do
you
understand
one
thing,
if
you
look
puzzled
well,.
I
Not
we
spin,
but
at
least
like
talk
about
what's
different
because,
like
we
decide
to
go
forward,
and
just
like
say:
okay,
like
from
what's
an
LP
or
an
overview
like
this,
is
what
it's
different
and
then
we
continue
with
the
work.
I
I
don't
want
to
do
a
base
document
just
for
the
sake
of
doing
it,
but
I
want
to
know
the
differences.
If
there's
any
because
I'm
sure
there's
gonna
be
some
differences
here
from
Watson
LP
and
overview
for
a
voice
on
right.
So
that's
just
not
a
question
there.
B
We
may
I
think
we
need
the
text
equivalent
to
the
overview.
That's
why
I
was
already
thinking
about
whistling.
If
we
don't
wisp
in,
we
could
also
say
a
charlie
because
you
are
not
in
the
other
of
you.
Then
please
have
your
own
overview
at
the
beginning
of
your
document,
because
I
don't
know.
That's.
I
Fine
I'm
open
with
the
mechanism
of
doing
it,
I
just
want
this
written
down
somewhere
because
we
we
had
this
like
in
a
beauty
contest
back
in
the
day,
I'd
like
to
figure
out:
okay,
I,
don't
wanna
like
it's
like
a
beauty
contest.
Really
right,
like
you
know,
we
said
I.
Okay,
these
are
the
technologies
we
can
be
interested
in.
We
talked
about
them
before
and
went
on
right.
So
so
I
I,
don't
mind,
reasoning
the
talk
there,
but
we
need
like
an
editor.
Maybe
Charlie
like
you
could
probably
pick
up
the
stuff.
I
I
don't
know
if
Stephen
leicht
is
around
much
here,
but
that's
something
open
to,
but
I
do
want
the
technology
to
be
documented,
because
what
I
don't
want
to
happen
is
like
you
know,
only
people
who
participate
in
I
triply
read
this
document
so
that
the
main
reason
for
me
insisting
on
the
overview,
was
like
people
from
the
IETF
understand
what
the
technology
is
about.
Right,
like
you
know,
like
Juan
Carlos,
is
wrote
about
sick
fox
because
otherwise
I.
I
If
people
don't
know
about
sick
Fox,
so
it
made
it's
gonna
make
life
easier
for
people
who
read
the
technology
documents
coming
from
this
working
group.
If
I
can
point
them
to
somewhere.
That's
an
idea
of
document
rather
than
saying.
Oh,
you
need
to
go
sign
some
agreement
with
some
other
standards
body
which
may
or
may
not
be
compatible
so
that
I
want
to
follow
the
same
kind
of
tradition
going
forward.
G
C
C
Yeah,
actually
that
sounds
really
great,
because
yeah,
there
are
two
points
actually,
and
one
of
the
points
is
I
was
coming
to
this.
Probably
there
we
could
find
other
ways
that
she
could
fit
into
into
the
W
in
into
15.4
W,
for
example,
when
you
say
that
okay,
well,
that
we
maybe
ten
thousand
devices-
and
you
know
with
multi-man
multi-hop
network
and
so
forth.
But
you
know
she
can
be
applied
to
co-op
what
we're
gonna
do.
No.
C
The
point
is
no,
the
point
is
that
you
know
we
can
it's
a
good
thing
to
have
a
document
that
says:
okay,
we
are
doing
chick
for,
for
that
particular
application
fields,
and
actually
that
could
be
a
way
ahead
in
the
future
if
there
are
other
technologies
that
would
like
to
you
know
to
apply
shape
that
this
can
be
like
the
per
the
process.
Okay.
Well,
you
want
to
apply.
She
please
write
the
overview.
C
Then
we
see
that
this
and
we
see
how
it
is,
and
we
you
know
we
we
we
can
include
your
document,
but
it's
it's.
We
can
and
actually
the
overview
document.
It's
super
useful.
It
has.
It
was
the
first
document
that's
publicly
available
and
that
there's
a
there's
an
overview
of
all
these
lp1
technologies
and
it
was
really
heavily
cited.
So
I
think
that
would
be
really
great
also
for
for
the
technology
itself.
So.
B
A
small
remark
here
when
we
started
6lowpan:
it
was
by
the
name
just
for
15
for
right
when
we
started
16,
she
was
just
for
15
for
e.
Lp
ones
was
kind
of
ambitious
trying,
starting
with
four
technologies
in
parla
like
compared
to
the
other.
It
was
never
seen
now.
If
we,
if
we
with
10
years
of
back
off
in
front
of
us,
we
can
see
that
6lowpan
has
evolved
to
multiple
technology,
so
we
have
kind
of
peon.
B
We
spend
the
working
group,
as
opposed
to
15
for
to
ipv6
of
our
food,
for
certain
number
of
foods
and
60s
I'm
saying
is,
is
now
looking
at
sub
gig
and
and
probably
different,
even
the
axe,
or
something
like
that.
So
we
we
can
expect
that
the
Sheik
of
our
foods
will
be
one
of
the
tracks
of
the
future
of
this
document.
So
we
have
to
prepare-
and
this
is
a
good
example
on
how
we'll
reach
outer
of
our
time
to
do
more
food
and-
and
we
can
really
expect
that-
will
be
more
food
right.
B
B
We've
we've
looked
at
how
we
can
refine
this
charter
and
split
it
and
and
reshuffle
it
and
pretty
much.
We
are
going
through
that
discussion
again
and
see
that
what
what
has
changed,
what
has
not
shared
so
since
the
first
charter,
some
individual
submissions
have
come
up
to
us
like
work
and
ICMP,
and
we've
discussed
a
pure
compression
of
ICMP
doesn't
make
any
sense,
but
maybe
some
usage
of
ICMP
could
be
valuable
for
us
and
in
particular
things
like
Oh
am
so
so.
B
The
discussion,
normal
chattering
are
focused
not
on
a
particular
class
of
message,
like
ICMP,
but
a
particular
class
of
few
sages,
like
checking
the
quality
of
the
link
and
and
feeding
back
the
users,
etc.
So
not
ICMP,
but
applications
of
ICP,
and
so
we
will
see
what
makes
sense
follow
for
the
recharter
of
this.
B
So
here
is
the
original
charter,
and
you
will
see
that
the
second
ballot
here
is
kind
of
rich
because
it
talks
about
coops
UDP,
but
it
also
talks
about
definition
of
generic
data
models
and
it
show
it
talks
about
the
definition
of
various
technologies.
So
it's
it's.
It's
one
chatter
item,
but
if
you
look
at
it,
it's
a
multi-step
chartered
item.
B
So
if
we
look
at
what
we
we
are
near
to
have
to
completion
here,
considering
that
chick
is
pretty
much
done,
but
first
the
first
big
item
is
down
and-
and
this
piece
here,
ipv6
UDP
shake-
is
pretty
much
done.
This,
the
rest
of
the
way
is,
is
not
done
so
as
we
as
we
reach
outer.
We
will
have
to
consider
removing
what's
done
and
then
basically,
we
spinning
what
is
in
progress.
Okay,.
B
B
The
data
model.
We
always
knew
that
the
data
model
was
critical.
The
data
model
is
what
you
really
place
on
the
infrastructure
side,
so
that
you
can
dynamically
as
you
deploy
a
new
device,
you
can
dynamically
changed
infrastructure
to
support
this
device.
Shake
is
completely
stateful,
which
means
that
it
doesn't
work.
If
the
network
side,
the
network
entities
are
not
aware
of
how
to
compress
the
particular
packets
for
this
particular
device.
Each
device
may
come
with
a
new
set
of
rules.
If
you
deploy
any
device,
you
must
deploy
the
rules
of
the
infrastructure.
B
B
The
technology
specific
document
highly
depend
on
this
data
model
because
they
have
to
decide
as
part
of
this
data
model.
When
do
they
consider
as
open
to
the
device.
What
do
they
consider
as
being
fixed
for
the
particular
technologies,
or
maybe
some
ranges
of
values
or
some
profile
data
that
they
want
to
support
right?
So
pretty
much
I
see
the
technology
documents
as
at
least
one
piece
of
the
technology
document
as
being
a
way
to
express
a
constraint
on
the
profile.
H
B
B
A
B
Highly
visible,
what
we
are
doing,
everything
is
reopened.
We
are
doing
open
standards
here,
and
so
basically
this
all
these
editing
games
ends
up
with
three
work
items
which
are
really
inherited
from
chapter
1.
It's
just
take
chapter
1
my
move
words
down
and
spit,
what's
not
done
in
the
words
individual
items
that
needs
to
be
produced.
Ok
and
now
the
new
thing
that
we
talked
about
last
time
inherits
from
the
work
that
was
done
on
ICMP,
but,
like
I
said,
we
don't
want
to
just
compress
ICMP
doesn't
make
much
sense.
B
We
want
to
comprise
some
particular
values
of
ICMP,
some
particular
flows
that
are
useful
for
the
LP
one
use
case.
So
now
it's
again
we
have
designed
to
on
technologies.
They
know
what
they
need.
If,
if
the
particular
thing
they
need
to
manage
their
network
like
like
I,
get
too
big
I
don't
know
is,
is
useful.
They
need
to
come
to
work
with
us
on
this
particular
topic,
so
we
can
have
a
compressed
way
of
saying
okay,
and
so
we
have
to
figure
out,
which
kind
of,
for
instance,
ICMP
rose.
B
B
B
I
B
Okay,
we
just
it's
like
just
like
shake
right.
It's
it's!
It's
more
like
co-op,
is
more
dependent
on
the
application
than
the
underneath
technologies.
So
we
are
kind
of
concerned
that
some
people
use
go
up
in
a
way
that
we
did
not
foresee
and
that
we
are
missing
good
rules,
the
go
technique.
You
know
possibilities
to
compress
that
particular
case.
So
so
the
authors
have
gone
through
a
lot
of
work.
We
talked
with
with
Gaston
about
getting
some
some
examples
of
use
of
core
to
see.
B
I
B
On
what
we
expect
like
I
said,
never
mind,
our
discussions
was
mostly
pink
like
how
can
I
emulate
that
do
I
need
to
really
paying
when
I
think
or
can
I
just
use
the
fact
that
I
just
contacted
the
device
to
answer.
Yes,
it's
the
life
of
this
kind
of
game
around
you
know
path
until
discovery
and
what
else?
Okay,.
I
And
for
the
last
item
like
the
ipv4
stuff
right
like
it,
so
one
of
the
things
I
want
to
say
is
like
if
ipv4
works,
that's
fine
and
I'm
really
reluctant
to
spin
up
ipv4
only
work
in
here
just
to
like
take
care
of
before
here,
because
I'm
I'm
not
sure
like
how
applicable
ipv4
is
in
like
the
IOT
space,
very
much
okay.
So
it's
possible
that
somebody
has
use
cases
there.
I
just
want
them
to
come
up
with
it
before
we
think
about
reach
charting
I
want
to
see.
I
B
I
understand
you
and
I'd,
like
that.
It's
even
more
than
that
is
I
still
fail
to
see
that
we
have
anything
to
do.
Yes,
no
harm
will
come
to
the
my
because
my
vision
is
like
the
device
sending
the
exact
same
thing
you
know
could
be
using
v4
and
v6,
and
it
doesn't
even
know
because
I
mean
what
do
you
compress
right?
A
pair
of
IP
address
a
hop
code
which,
which
is
a
TTL,
and
what
do
you
compress
and
so
basically,
based
on
the
same
chick
format
with
different
roles?
I
And
that's
what
I
said
so
if
v4
works,
I'm
really
happy
right,
but
I
don't
want
to
put
in
specific
effort
to
make
just
be
forward.
That's
what
I
was
saying
so
there's
like
a
slight
difference
there
right
so
before
work,
that's
fine
with
the
way
we
specified!
Oh,
we
could
have
an
informational
to
say,
oh
by
the
way
ipv4
works.
Just
put
it
in
other
drafts,
angry
for
what
just
works
right
like
I.
H
J
Thanks
Juan
Carlos,
when
you
get
so
I,
just
want
to
pick
it
up
from
points
three
and
four
after
the
discussion.
So
for
three
there
was
a
small
concern
about
whether
co-op
will
will
work
or
not
and
I
understand
where
it
comes
from,
because
now
we're
writing
specific
documents
and
we're
splitting
basically
in
four.
But
the
whole
idea
here
is
to
make
it
a
kostik
to
higher
layers
right.
So
we
are
just
interfacing
with
lower
layers
technology,
specifically
because
they're
very
different,
but
from
UDP
and
IDP,
should
be
completely
agnostic
and
transparent.
J
That's
the
whole
idea
of
the
interoperability
here.
So
maybe
we
should
do
some
homework
if,
if
this
is
not
clear
for
people,
because
that's
a
part
of
the
big
thing
of
this
group
right
to
make
that
interoperability
work
at
a
higher
layer,
so
I
guess
it's
it's
something
that
we
should
keep
in
mind.
Maybe
we
do
a
little
more
advertisement
of
what
exactly
we
are
achieving
with
these
specifications.
J
J
J
I
Sir,
it
wants
to
make
sure
that
co-op
wasn't
different.
I
didn't
want
like
an
explosion
at
not
the
layer.
So
that's
the
whole
point,
but
the
part
that
worried
me
was
that
if
somebody
is
trying
to
do
like
a
more
okay,
so
the
more
layers
you
put
in
and
combine
them
together,
the
better
compression
you
can
get
right.
So
I
was
like
just
worried
that
some
technology,
like
maybe
sick
pots,
right
I,
don't
know
right.
I
My
decide
do
like
hey,
like
you
know,
if
I
put
in
co-op
together,
then
I
can
do
something
better
than
like.
You
know
doing
that.
I!
Just
don't
didn't
want
that
to
happen.
So
that's
why
I
asked
you
like.
You
know
you
even
proposed
it.
That's
what
I
wanted
to
make
sure
that
you
don't
want
to
propose
it
so
I'm,
fine
it
like
what
Juan
Carlos
said
if
it
has
to
be
written
somewhere,
that's
fine,
but
if
it,
if
I,
don't
get
a
work
item
I'm
happy
to
like.
B
B
I
Fine,
like
that's
also
like
you
know,
tells
me
that
somebody's
using
v4
for
IOT
right,
like
that's
something
I,
will
also
like
to
know
because
I
know
that,
like
for
at
ease
for
IP
wave,
there
was
a
company
doing
vehicular
stuff
and
they
said
they
were
using
IP
before
I.
Don't
know
what
happened
afterwards
right
there
was
peloton
right
and
so
I
don't
know
if
it
went
any
further
or
not,
but
at
least
I
heard
that
somebody's
doing
stuff
I
haven't
heard
anybody
in
this
space
doing
that.
I
C
I
C
I
But
like
if
something
comes
up,
we'll
handle
it
I,
just
don't
want
to
lead
with
that
like
saying
like.
Oh,
it
should
be.
Do
ipv4
something
that
somebody
needs
to
write
up
to
even
consider
it.
Okay
and
I'm.
Happy
with
what
Juan
Carlos
said:
okay,
so
they're,
both
this
co-op
stuff,
that
our
convergence
layer
is
IP
and
I'm
very
happy
with
that.
J
J
So
if,
if
it's
better
to
to
change
the
title
and
make
it
more
focused,
that
would
work
because
we
actually
try
to
to
go
the
other
way
around
and
say:
okay
well,
this
RFC
wants
us
to
consider
all
these
things,
but
only
to
make
sense.
So
we
we
actually
started
writing
that
to
make
sure
we
were
focusing.
But
if
we
can
right
away
focused,
maybe
using.
B
I
Solution,
so
that
makes
sense
in
the
graph,
but
not
in
the
chatter.
So,
like
you
know,
the
draft
could
say
like
hey
I
looked
at
this
like
all
these
things,
and
these
are
to
make
sense,
can
be
in
the
draft,
but
like
I
want
the
Charter
to
be
scoped
to
do
what
we
want
to
do,
not
the
things
we
don't
want
to
do,
how's
it
make
sense.
Well.
B
That's
to
trigger
a
discussion
right,
but
but
you
you
asked
us
to
tighten
the
screw.
So
at
some
point
we
need
maybe
to
list
those
two,
maybe
others
that
would
be
the
discussion
but
but
you
kind
of
told
us
totally
that
did
not
a
bit
that
open
right.
So
so
it's
it's
a
starting
point,
but
we
need
this
discussion
and
then
we
need
to
change
this
text.
That's
what
happens
then,
for
me.
H
Okay,
for
me,
maybe
here
is
one
point
that
is
missing,
is
about
security
and
are
we
dealing
with
security
mechanism
like
the
TLS
of
Oscar,
so
for
Oscar?
We,
we
include
it
in
the
co-op
draft,
but
maybe
we
have
to
look
at
all
the
possibilities
and
and
see
what
is
the
basic
space,
especially
if
we
want
to
go
to
management.
We
need
security,
I'm.
B
B
B
Nobody
can
see
that
we
don't
have
any
detail
s
work.
If
we
chart
all
detail
s,
nobody
shows
up
what
do
I
do
right.
It's
kind
of
we
need
to
show
interest
before
we
triggered
it.
Tell
us
it's
that
I
would
like
it.
Why
not,
but
somebody
needs
to
say,
hey
we
care
for
it.
We
need
it
first
develop
it.
Don't
just.
C
We
charter
I,
think
I
mean
server
ship.
If
we
have
like,
we
see
that
we
advance
pretty
well
and
we
have
some
demand
on
security.
It
could
be
pretty
I
mean
in
an
if
you
see
progress
on
the
other
points.
It's
not
going
to
be
a
huge
discussion.
If
we
say
ok
well,
now,
security
gets
a
pretty
big
point.
Can
we
include
it
in
the
Charter
I.
I
One
of
the
reasons
for
doing
score
is
like
you
know.
The
details
may
not
be
that
efficient
for
the,
like.
You
know
the
use
in
these
environments
right.
So
if
we
have
to
do
duplicate
security
mechanisms,
I
kind
of
wants
to
see
some
kind
of
justification,
but
I
agree
with
like
Laurent
that,
like
you
know,
this
is
like
a
blocking
thing
pretty
much
right.
Like
you
know,
we
don't
want
to
do
like
you
know
some
kind
of
high
level
access
to
the
system
without
like
securing
it.
I
So
I
I
assume
that
it's
going
to
be
dead
like
whenever
this
mechanism
is
there
like
it,
has
proper
security
considerations
how
it's
going
to
be
secured.
So
that's
kind
of
us,
you
know
III,
don't
need
it
as
like
a
chatter
item
or
like
a
milestone,
but
I
expect
it
to
be
there
before
it
hits
the
IAC.
Otherwise,
like
you
know,
you
gonna
get
a
sec
head.
He
discussed
right
away
all.
B
Right,
the
point
being
that
we
have
going
from
his
step
to
another
step
if
the
initial
step
or
the
reactor
technology
with
which
sometimes
that
earlier
to
take
security
and
network
level
security
and
then
write
over
it,
you
had
an
application
which
had
its
own
security.
We
are
inserting
IP
in
the
middle.
We
are
not
removing
the
application
security
that
was
there
and
we
are
not
removing
the
layer,
2
security.
That
was
there
at
some
point.
You
know,
that's
that's
adopting
IP
UDP
cloud
and
then
inside
they
do
what
they
want
to
do.
B
Now
we
are
providing
a
score
and,
and
maybe
in
the
future,
won't
provide
ETLs,
but
but
we
are
going
stepwise
and
each
step
as
its
own
security
and
it
started
with
the
city
or
wealth
and
we
never
lost
the
security
that
was
already
there.
So
it's
I
understand
only
saying
it's
just
that
we
need
to
either
use
case.
We
need
to
have
the
people
in
the
room
were
all
ready
to
do
the
work.
We
cannot
just
put
it
in
the
Charter
and
have
nobody
to
the
work.
B
B
They
understand
the
flow
is
much
better
than
we
do
and
then
from
there
they
can
derive
what
rules
they
need
and
they
can
check
if
they
have
enough
stuff
in
shaped
following
it,
and
if
they
don't,
then
they
can
come
back
to
us
and
say:
oh,
we
need
to
risk
in
check
because
we
cannot
encode
it
tell
us,
but
but
are
we
the
right
guys
to
say
what
that
all
those
flows
are
and
I
mean?
You
know
it's
kind
of
in-between?
If
it
really
requires
a
change,
then
my
stuff
and
here,
but
if
it's
just?
B
H
Another
point
is
about
the
0.54,
so
we
have
ipv6,
but
we
don't
have
ipv6
extension.
So
at
the
beginning
we
thought
it
was
not
good
idea,
but
maybe
member
IP
we
used
over
p1
it's
a
way
to
do
roaming
between
different
provider
or
to
do
between
different
technologies.
So
maybe
it
will
be
good
or
so
to
investigate
some
idealistic
extensions
same.
B
As
DTLS
I
mean,
yes
do
some
personal
submissions
and
we
see
the
interest
where
we
are
and
this
this
shorter
is
already
a
V,
so
we
wouldn't
have
a
milestone
from
a
variety
right,
but
but
why
not
have
a
personal
submission
and
see
them?
Try
stand
start
the
work
yeah
and
then,
if
it's
you
know
if
it
takes
off,
then
why
not
reach
out
or
shut
off
three
on
this
right.
B
So
before
yes,
I'm,
like
Suresh
I,
want
to
see
the
work
and
I
want
to
see
what
you
cannot
do,
because,
yes,
you
cannot
encode
anything
but
but
with
what
you
can
encode,
you
can
already
go
through
ipv4,
so
so
I
mean.
Is
it
a
game
of
doing
the
very
generic
thing
or
is
it
a
practical
game
of?
Is
the
real
case
that
you
can
not
do
that's
very
useful
today?
I
want
to
see
that.
C
So,
just
to
like
just
to
confirm
something
with
Suresh,
so
the
first
three
points
seem
pretty
straightforward.
The
third
point,
if
we
add
produced
under
track
document,
one
per
technology,
so
four
documents,
then
that's
pretty
much.
You
know
like
limits
the
possible
explosion
of
stuff
around
and
and
then
so
the
then,
with
these
the
first
three
seem
pretty
well-defined.
B
C
C
Then
the
fourth
one,
eventually
we
need
some
discussion
on
the
mailing
list
just
to
narrow
down
what
exactly
will
be
done
there
and
for
everything
else.
We
need
some
some
submissions
on
the
mailing
list
and,
like
some
reasons
why
we
would
need
to
do
this
and
I
I
know
that
there
I
mean
there
were
some
requests
for
coming
specifically
on
this
during
the
interim
in
during
the
interim
meetings
or
but
nothing
really
from
what
I
know.
C
C
I
Please,
thank
you,
that'll
be
a
good
time
to
start.
The
chattering
process,
like
you
know,
discuss
this
in
the
proof
like
as
long
as
you
ship
with
the
document
to
me.
Like
you
can
start,
the
recharging
process,
like
so
probably
like
beginning
of
January,
can
start
the
recharging
process
in
the
working
group
itself.
I
B
C
So
these
are
just
a
couple,
thoughts
that
come
from
the
discussions
and
try
to
summarize
what
is
there
and
what
needs
to
get
done
by
the
group
in
the
in
the
following
in
the
following
months
and
basically,
what
he
also
cost
identified
with
with
Pascal.
Is
that
all
the
technology,
the
group
documents
are
waiting
for
this
to
advance?
So
what
we
have
here
is
until
now
we'll
be
talking
quite
a
lot
about
chic
context
and
the
sheet
context
is,
we
may
say
the
set
of
rules
that
are
there.
C
So
we
can
have
the
rules
and
that
are
each
rule,
can
be
either
compression
or
fragmentation
rule.
And
then
you
have
in
the
specific
rule,
in
the
specific
who
we
have
the
behavior
okay.
How
does
the
compression
the
compression
happens
for
that
rule,
or
how
does
the
fragmentation
happen
for
that
rule,
and
since
sometimes
we
identified
that
there
is
some
other
thing
that
could
actually
affect
the
way
he's
working,
so
we
can
call
it
a
chicken
point
metadata
or
she
can
point.
C
It's
kind
of
profit:
oh
she.
She
can
point
some
information
about
it
like
things
about
the
device,
typically
for
a
Laura
device.
That
would
be
easy
to
Class,
A,
Class,
B,
plus
C
or
other
things
that
actually
will
help
you
work
with
that,
the
interoperate
with
that
device
and
what
we
say
is
that
those
things
here
constitute
the
Schick
profile.
So
the
profile
is
the
rules
so
that
you
know
what
happened
there
and
some
more
information
that
you
know
allows
you
to
actually
go
a
step
further
and
really
happen
to
a
probability.
C
So
one
point
was
that
until
you
know
we
did
all
the
work
and
all
the
hackathons
and
all
the
interrupts.
Until
now
we
were
pretty.
We
had
a
pretty
good
idea
what
we
wanted
to
put
here,
but
then
you
know:
how
does
it
look
exactly
it's?
It
was
an
open
question
right
now:
I
get
the
impression
that
people
start
to
understand
pretty
well
what
needs
to
get
there,
and
this
comes
from
all
the
work
that
has
been
done
at
hackathon.
C
I
need
implementations,
so
you'll
have
like
she
profile
that
has
it
she
context
center
section
and
she
can
point
metadata
section
and
there
you
have.
You
know
all
the
parameters
that
go
here
and
here.
So
this
is
a
work
that
needs
to
get
done,
and
one
possibility
is
of
course,
to
use
Yang
and
sir
modeling
language
to
model
to
model
this.
This
thing
I
mean
we
cannot
just
put
that
JSON
file
there
and
we
could.
C
But
you
know
that
would
be
not
that
structured
and
the
the
IDF
way
of
doing
it
would
be
to
have
a
young
model
that
defines
the
structure
and
then
you
know
we
can
just
attack
it
with
the
different
protocols
and
then,
of
course,
this
gets
into
okay.
How
these
different
sections
can
be
can
be
formulated.
C
You
know
with
one
big
file
for
the
profile
and
then
we
have
set
being
files
for
the
difference
like
for
the
context
and
for
the
metadata,
and
then
you
can
ideally
will
have
a
very
common
point
here
between
the
different
l2
technologies.
So
that
would
be
really
really
great.
This
way
a
generic
shake
endpoint.
So,
for
example,
the
network
can
fetch
from
somewhere
or
can
have
the
the
profile
and
can
work
transparently
with
any
device
from
any
technology,
and
that
could
be
a
really
powerful
thing.
C
And
yes,
once
we
have
that,
then
we
have
the
sir
ization.
That
is
there.
We
have
our
FCS.
We
have
drafts
how
we
have
this
data.
How
this
properly
actually
is
actually
going
to
get
so
realized
in
JSON,
C
or
XML
of
your
choice,
and
you
can
then
attack
it
with
different
protocols
like
net
conference
of
or
tokens
in
a
constrained
manner,
and
so
what
we
need
to
get
this
document
out
is
agree
on
the
agree
on
the
structure
and
I
think
that
we're
already
there.