►
From YouTube: IETF102-LPWAN-20180719-0930
Description
LPWAN meeting session at IETF102
2018/07/19 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
Hello,
everyone.
This
is
the
meeting
of
the
on
working
group
and
the
idea-
and
we
are
here
together
with
Pascal
as
okay.
Let
me
just
call
this
down
so
as
for
so
you
as
with
any
IETF
meeting,
please
read
the
note
well
before
coming
and
in
the
note
well
we
say
that
in
case
you
have
any
knowledge
of
you
know
that
this
is
your
participation
here
and
everything
that
you
say
is
considered
as
an
ITF
contribution.
A
A
Please
do
it
all
the
other
basic
piece
about
anti-harassment
and
code
of
code
of
conduct
and
all
this
part
as
a
reminder,
everything
that
that
so
that
the
meeting
it
has
will
be
recorded
and
it
is
actually
transmitted
alive
for
the
internet
minutes
will
be
taken
and
presence
will
be
logged.
Please
will
be
running
the
blue
sheets
in
couple
of
minutes.
Please
sign
the
blue
sheets
and
also
you
have
the
link
over
the
ether
pad
for
40
minutes
as
I
said
well.
A
B
B
Good
practice
to
log
in
the
ether
pad
for
two
reasons:
one
years,
if
you
miss
something,
you
can
always
read
what
was
just
said
because
they
just
took
the
minute
and
if
she
said
something,
then
you
can
check
that
your
words
are
in
your
name
were
captured
correctly.
So
even
if
you
don't
intend
to
actively
participate
in
a
minute,
it's
still
a
very
good
practice
to
log
in
detail.
But.
A
Yes,
thanks
Bhaskar.
Actually,
that's
really
really
important
because
I
we
as
a
working
group
that
attacked
that
attracts
people
that
come
from
industry
that
are
first-time
participants
or
don't
have
the
IGF
experience.
I
don't
have
this,
this
IGF
knowledge.
So
that's
that's
really
important.
Please
go
to
this
to
this
link
and
check
what
is
what
has
been
said
so
on
our
agenda.
Today
we
have
12
12
hours
and
30
minutes
slot,
which
is
pretty
tightly
packed
so
we'll
be
following
that
everyone
keeps
in
their
time
zone.
A
So
we
have
fulfilled
our
charter
in
one
and
we're
happy
to
have
our
arts,
who
are
our
first
RFC
as
a
group
out
there,
which
is
splendid,
because
it
is
one
of
the
first,
if
not
the
first
document,
that
is
out
there
from
more
official
standardization
body
like
informational,
that
gets
all
the
different
technologies
on
the
same
in
the
same
document
that
so
that
it
gets
really
used.
We
see
this
and
we're
very
happy
about
this
on
the
second
charter
item,
which
is
enable
the
compression
of
fragmentation.
A
Well,
we
are
advancing
really
well,
and
today
this
is
going
to
be.
One
of
the
main
topics
is
the
ongoing
working
with
plastic.
All
of
the
UDP
IP
shake
their
last
at
last
IDF
we
were
talking
about
which
are
Turing,
of
course,
and
what
one
of
the
points
that
we
we
saw
with
our
80s
and
with
with
Suresh.
A
So,
basically,
we'll
have
three
charter
items
that
are
taken
from
the
Charter
item
number
two,
so
continuing
with
the
color
chip
or
go
up
and
then
go
go
with
data
model
for
concert,
representation
and
documents
for
each
baseline
technology,
and
we
identified
also
a
new
potential
working
document
working
working
item
that
actually
comes
from
submissions
of
of
two
drafts
that
were
merged
and
it's
about
enabling
operation,
administration
and
maintenance
of
LP
on
devices.
So
you
know
it,
which
includes
also
being
the
lake
proxies,
liveliness
and
so
forth.
A
So
these
things
will
happen,
I
mean
they
have
been
discussed
and
we'll
continue
with
that.
Once
we
get
our
work,
you
know
once
we
get
the
IP
UDP
submitted
to
the
IH,
and
these
are
the
milestones
that
we
have
fir
for
the
moment.
We
clear
out
most
of
what
we
what
we
wanted
to
achieve
and
today,
as
I
said,
we
are
going
to
be
diving
into
impunity.
A
I
would
like
to
go
over
in
just
one
minute
to
to
show
us
a
short
history
of
what
we
have
managed
to
achieve
in
the
past
a
little
bit
more
than
a
little
less
than
two
years.
The
first
thing
is
that
there
have
been
a
successive
hackathons
for
the
past
four
80s
and
they
produced
a
really
important,
a
really
important
open-source
implementation
of
shake.
So
that's
really
something
really
important.
Also
the
scale
of
dhf
and
also
there
have
been
really
regular
meetings,
virtual
interims,
so
around
six
or
five
or
six
between
each
ITF.
A
So
in
case
you
have
been
there.
Thank
you
very
much
and
in
case
you
did
not
actually
participate
in
any
of
these
virtual
interims.
Please
try
to
follow
it.
It's
over
the
WebEx
and
there
is
really
very
good
work
happening
there
and,
as
I
said,
we
have
our
first
RFC
83-70,
76,
so
congrats
to
realtors,
and
with
this
we
are
giving
the
hand
to
Dominic
for
a
short
presentation
of
two
to
tell
us
what
happened
at
the
last
hackathon.
C
So
the
long
term
plan
on
those
hackathons
is
to
provide
an
open
source
implementation
of
check
that
allows
newcomers
to
try
it
out
and
then,
after
that,
maybe
go
and
implement
their
own,
but
at
least
provide
a
something
for
people
to
play
with
provided
a
reference
and
also
to
me,
it's
very
important
to
be
able
to
debug
the
draft.
Our
understanding
of
the
draft
and
implementing
it
is
a
good
way,
and
we
had
yet
another
case
this
weekend
of
something
that
happened
during
the
implementation,
so
get
feedback
on
the
draft.
C
C
So
please
do
come,
and
so
our
goal
for
this
one
was
to
advance
the
state
of
the
code
to
reflect
the
last
version
of
the
draft,
and
we
also
had
a
second
goal,
which
was
to
merge
several
pieces,
but
we
have
in
which,
if
that,
this
time,
so
what
got
done?
Yeah,
apart
from
having
the
soccer
game,
have
been
displayed
in
a
huge
screen
in
the
back
of
the
room,
which
kind
of
distracted
the
focus,
so
we
had
two
newcomers
come
and
actually
one
may
be
sitting
in
just
came
in
said:
hey.
C
This
looks
cool
your
little
devices
on
there
on
the
desk.
What
are
you
doing,
and
so
he
had
no
idea
what
chick
was
with
LP
on
one
was.
He
was
from
a
totally
different
environment
and
he
said
yeah
and
that
looks
cool
can
I,
see
it
and
play
with
you,
and
we
said
yes,
I
must
say
to
start
with.
I
said
I'm
going
to
spend
quite
a
lot
of
time,
educating
this
guy
but
further.
C
In
fact,
he
was
very
good
and
he
learned
very
quickly
provided
feedback,
and
then
he
started
coding
and
provided
very
good
expertise.
So
that
was
a
well
spent.
You
know
half
hour
or
hour,
okay,
and
then
we
updated
the
the
season
contributors.
We
always
have
some
half-dozen
contributors
on
the
recent
draft
adventures,
because
not
everybody
has
followed
a
very
last
update
and
overall
we
got
it
doesn't
notes
for
draft
improvement,
mostly
editorial.
C
You
know
this
is
not
well
explained
and
one
functional
which
I'm
going
to
talk
about
later
in
the
other
presentation,
so
we
updated
our
code.
The
fragmentation
code,
we
still
have
two
repositories-
will
do
better
next
time
and
we
also
improved
the
network
side.
Implementation
of
the
compression
version
in
the
repose
are
shown
here.
C
Lessons
learned
when
you
already
from
last
time.
It
takes
a
lot
of
time
to
get
started
with
the
embedded
devices,
the
lower
gateway.
We
try
to
have
a
live
network
running
and
so
several
suggested
that
we
we
set
up
micro,
passion,
environment
on
computers,
so
that
people
who
don't
have
the
devices
there
was
one
guy
sitting
in
Japan
working
with
us.
C
A
D
A
C
Okay,
that's
the
agenda
for
today,
so
we
kind
of
split
the
time
in
sections,
so
we
can
keep
track
of
time.
So
Anna
is
going
to
talk
about
what
has
happened
since
one
the
interim
meetings
and
the
diversions
we've
published.
What's
coming
up
next
ticket
status,
it
was
the
last
time
suresh
mentioned
that
he
wasn't
able
to
track.
You
know
where
all
these
tickets
had
been
resolved
in
which
version
etc.
E
It
will
be
a
little
bit
different
from
last
time.
There
were
no,
we
attack
show
she
don't
want
to
do
it.
This
time,
I
will
present
part
of
what
we
have
done
in
this
period.
So
there
has
been
five
inter
meetings
since
the
last
idea
how
we
publish
from
version
10
version
16.
So
we
have
made
a
lot
of
changes
in
the
document,
so
the
first
version
10
includes
almost
that
10
first
tickets.
E
We
have
discussed
from
the
couplet
fragmentation
and
compression
the
role
ID,
all
the
terminology
from
Poquette
chick
fragment,
and
so
for
that
we
don't
have
before
than
way.
We
start
working
in
completed
this
terminology
and
improved
the
figure
tree.
That
shows
where
fragmentation
and
compression
is
done.
We
take
ticket
15.
That
is
a
list
of
things
that
we
need
to
define
in
Dec
technology
documents.
For
the
appendix
t.
E
We
answer
more
questions
or
comment.
We
receive
in
the
tickets
about
the
detect
and
we
delete
the
are
size
in
the
all.
The
figures
of
the
fragment
part
to
be
more
clear
and
in
version
12
way
to
be
consistent
with
compression
decompression.
We
add
fragmentation
and
reassembly
in
order
to
have
both
size
in
both
part
of
the
document.
E
E
We
decide
to
pass
the
once,
then
is
the
presentation
that
the
meaning
will
make,
just
after
instead
of
parting,
twice
who
you
are
only
using
a
single
padding,
we
decide
to
put
her
role
ID
and
the
same
role
ID
in
the
act
from
the
raw
ID.
Will
you
use
in
the
fragments
we
change
the
UDP
checksum
thanks
to
Pascal
for
this
input
in
order
to
to
get
a
best
make.
E
Udp
checksum
compression,
we
fix
some
inputs,
we
get
from
the
middle
east
of
the
state
machine
of
always
and
will
leave
even
if
it
was
not
agree.
The
cbiit
without
explanation
he
put
a
bump
in
the
last
intermitting
we
we
run.
The
second
last
call
for
this
draft
that
we
hope
we
can
close
today.
I
have
but
I
will
see.
E
E
B
That
can
be
very
understandable
because
DTF
is
not
you
lot
two
weeks
before
they
achieve
pretty
much,
so
my
white
guess
is
based
on
discussion,
will
probably
extend
the
let's
call
like
a
week.
Give
people
like
Juan,
Carlos
and
Charlie
time
to
fully
give
us
all
the
details.
De
Marco
Charlie
was
filmed
at
when
Carla
was
the
two
hundred
wasn't
sure,
but
they
think
you
still
have
things
to
tell
us
right.
Oh
thank.
E
What's
coming
up
next,
so
we
will
not
close.
Second,
let's
go
as
you
have
now
we
can.
We
have
to
process
the
the
comments
will
receive
from
Pascal
Soichi
Charlie
Juan
Carlos
that
we
will
present
and
we
hope
we
can
publish
version
17
as
soon
as
possible
after
my
vacations
and
we
drafted
a
yes,
this
is
Hannah
okay
ticket
status.
C
E
C
If
you
are
interested
in
following
the
tickets,
what
happen
which
version
where
they
implemented
the
at
the
back
of
the
presentation,
I,
don't
think
we
to
have
time
to
go
through
that
we
have
a
full
table
with
the
29
tickets
version.
Bla
first
appeared
section
blah
blah,
and
so,
if
you're
worried
that
we
may
have,
you
know,
missed
a
ticket,
then
you
can
track
where
it
went
and
see.
If
the
outcome
is
appropriate
and
I.
C
C
This
was
extensively
discussed
at
the
interim
meeting,
but
I
understand
that
everybody
is
on
the
interim
meetings,
so
the
the
idea
was
floated
actually
by
Laura
I.
Remember
at
one
of
the
intra
meeting
she
said
gee,
you
know
what
I
think
we
could
make
it
work
with
single
padding,
and
so
this
got
me
excited
and
say:
oh
I'm,
going
to
look
into
that,
and
we
had
a
little
meeting
between
us
and
then
I
presented.
C
The
proposal
said
yeah
I
think
it
works
proposed
that
the
next
entry
meeting,
then
mail,
went
out
to
the
mailing
list
asking
for
opinions
and
we've
got
six
positive
responses,
no
objection!
So,
at
the
next
entry
meeting
again
we
decided
to
integrate
that
proposals
who
made
a
change
to
shake
Frank
Wesley
fragmentation.
C
C
Yep,
okay.
Before
that,
so
sorry
to
recap:
we
have
compression
on
the
top
fragmentation
at
the
bottom,
this
out
to
kind
of
sub
layers
within
shake
and
before
that
with
we
had
this,
we
do
shake
compression
so
ahead
of
compression,
which
turns
a
ipv6
packet,
typically
into
a
bunch
of
bits
which
are
the
compression
residue
and
the
rule
ID,
and
then
either
we
send
it.
C
So
because
this
is
just
a
bunch
of
bits,
chick
is
totally
bit
oriented,
not
byte
oriented
then
before
we
send
it,
we
maybe
most
often
on
most
layer
tools.
We
have
to
do
some
kind
of
padding
to
adjust
to
the
next
byte
and
so
until
14.
This
is
this
was
done
here.
The
the
compressed
forget
that
we
called
a
shake
packet
was
parried
to
a
bite
before
it
was
turned
to
fragmentation,
and
then
fragmentation
would
send
fragments,
mostly
most
of
them,
without
requiring
any
padding,
because
they
are
inherently
byte
or
aligned.
C
I'll
show
you
why
and
except
the
last
one,
which
has
so
many
bits
to
send
that
it
cannot
be
naturally
right
to
a
bite,
so
we
would
have
padding
on
that
last
fragment.
So
this
meant
we
had
two
patties
one
here
when
they're
looking
at
the
same
thing.
Another
way,
this
is
a
shake
packet
which
has
it's
compressed
header,
the
original
payload
of
the
ipv6
packet,
that
we
don't
compress
and
then
the
padding
to
avoid
to
make
this
an
integer
number
of
bytes,
and
then
we
take
this
shake
packet
and
cut
it
into
fragments.
C
First
fragment
has
a
header
in
fragment
payload,
which
is
part
of
that
second
fragment
fault,
fragment,
etc,
etc.
Last
fragment
takes
a
reminder
of
these
she
Akkad
and
because
this
one
is
not
bad
like
it
would
be
aligned
to
a
bite
with
padding
to
second
value.
So
this
is
only
in
the
case.
We
do
need
padding,
no
mercy.
This
is
entirely
optional,
but
if
we
do
need
padding,
we
would
do
padding
twice.
So
we
would
add
at
most
seven
extra
bits
here
for
byte
oriented
technologies
in
at
most
seven
extra
bits.
C
So,
overall,
at
most
14
extra
bits,
so
you
may
wonder
why
is
this
inherently
aligned
to
bytes?
Why
don't
I
need
padding
here,
and
this
has
been
often
raised
as
a
question
either
at
the
hackathon
or
mailing
list?
People
would
usually
do
padding
here
because
it
didn't
quite
understand
the
way
this
works.
So
fragment
header
is
a
bunch
of
bit.
It's
a
weird
number
of
bits
or
weird
sites,
not
quite
aligned,
nothing.
So
what
we
mandate
in
the
draft
is
that
as
a
payload
for
that
fragment
you
take
from
what
you
have
to
fragment.
C
You
take
a
number
of
bits.
That
is
also
a
weird
number.
It's
actually
complementarily,
weird
such
that
overall,
it's
a
multiple
of
bytes,
so
conceptually
it's
easy
yeah.
It
involves
a
little
bit
of
shifting.
You
know
to
get
that
number
of
bits
out,
but
all
the
fragments,
but
the
last
one
are
naturally
aligned
bytes
by
this
mechanism.
C
So
this
is
again
the
sending
part-
and
this
was
until
14,
the
receiving
part,
and
so
here
we
assembly
gets
all
the
fragments
puts
him
back
into
a
reassembly
before
yeah
and
and
then
what
happens
to
the
extra
bits
p2.
Well,
because
it
was
known
that
shake
packet
originally
was
byte
oriented,
then
those
extra
bits
could
be
removed
just
because
it
the
dangle
off
the
end
of
the
last
byte,
and
so
that's
about
trimming
stuff.
And
then
things
go
up
into
decompression
and
extra
here.
C
C
So
what
we've
proposed
is
save
this
seven
bits
so
go
from
up
to
14
bits
to
up
to
7
bits,
and
actually
you
only
need
padding
when
you
send
things
over
the
layer
to
so
we
don't
need
padding
here,
but
only
on
the
horizontal
lines.
So
what
we've
said
is
we
get
this
packet,
which
is
a
bunch
of
bits?
And
if
we
transmitted
here,
we
Pat
it.
C
A
C
So
now
the
question
which
is
tricky
to
understand
is
how
do
this
padding
get
removed,
and
so
what
we're
saying
is
that
a
decompression
anything
that's
left
in
the
before
once
the
packet
has
been
decompressed
is
dropped
anyway.
We
don't
care
whether
it's
bad
one
about
pad
two.
It
works
the
same
way
if
it's
extra,
it's
it
gets
robbed.
Naturally,
when
you
decompress
the
packet,
so
these
bits
that
we
introduced
here
will
be
removed
there.
So
that
may
be
a
philosophical
question
terms
of
layering
api's.
We
get
these
questions.
C
C
C
E
E
The
one
question
we
have
is
if
it's
in
the
appendix
is
its
normative
content.
So
it's
an
informational
part
for
the
technology
specific
documents,
what
we
were
thinking
with
the
mini
keys.
Perhaps
we
can
structure
this
list
because
we
received
some
comments
about
what
happened
if
I
don't
use,
fragmentation
do
I
need
to
specify,
in
my
specific
technology
document
the
fragmented
fragmentation
parameters,
even
if
I
don't
use
them
and
I
say
no,
normally
so
list.
E
So
if
you
don't
use
it
you,
don't
you
don't
specify
it
so,
in
order
to
perhaps
give
more
clarity
to
this
list,
we
can
structure
it
in
the
uses
case
in
map
in
architectural
elements.
There
are
two
integrity
checking
providing
numbering
on
format
there
toward
type
if
it's
bit
spikes
or
something
else,
all
the
fragmentation
parameters,
part
but
again,
I,
don't
know
if
this
will
help.
Sir
or
not
it's
a
question.
I
do
want
that.
We
structure
this
role
list
Oh,
we'll
leave
it
as
it
is.
C
I
think
that
was
a
comment.
We
got
at
least
from
Charlie
that
this
was
a
bit
like
a
laundry
list,
not
sure
everything
was
needed,
especially
if
we
didn't
implement
fragmentation,
so
we
will
restructure.
Let's
make
it
hierarchy,
Hong!
That's
your
lair
to
have
fragmentation.
Yes,
now
that's
your
lair
to
need
to
use
fragmentation
from
shake.
Yes!
No!
If,
yes,
these
are
the
parameters
that
you
need
to
define.
If
not,
you
can
just
ignore
that
subsection.
So
it's
in
it,
even
it's.
B
C
I
wasn't
sure,
because
the
last
time
we
said
again
that
was
a
comment
from
Suresh,
a
feeling
that
I
created
to
get
15
with
that
you
have
to
make
sure
that
you
list,
you
spelled
out
all
the
parameters
that
the
technology-specific
in
document
needs
to
define.
So
don't
define
the
parameter,
but
list
said
you
know,
make
a
note
that
these
parameters
have
to
be
different
by
somebody
else.
So
is
that
normative,
or
is
that
not
normative?
If
it
is
it
can't
stain
in
the
appendix
right,
yeah.
A
The
thing
is
that
right,
I
mean
if
there
is
a
technology
specific
document
that
doesn't
specify
some
I
mean
one
parameter
is
left
out.
Well,
it's
not
possible
right.
They
need
to
specify
all
the
parameters
so
that
it
works
on
the
technology.
So
what
you
put
here
is
basically
a
guide,
not
something
that
helps
them
to
say.
Well,
ok,
well,
I
need
to
go.
B
B
B
C
H
C
So
it's
not
about
the
generic
shakin
consuming
this
one's
specifically
about
the
section
that
says
how
UDP
and
IP
v6
are
compressed
using
shake
and
so
right
now
we
said
traffic
last
can
will
be
ignored
and
reconstruct
we
reconstructed
from
a
constant
on
the
other
side
and
loss
at
this
is
traffic.
Lassie
is
the
field
where
sen
bits
are
stored.
It's
a
overwritten
with
variation
bit,
and
so,
if
you
use
the
ignore
matching
operator,
you
bleach
the
amount
that
was
the
expression
so
good
make
this
n
bits
disappear
so
yeah
in
principle.
C
This
is
a
good
point,
it's
right,
but
the
question
was
in
you
know:
the
kind
of
devices
we
were
talking
about
on
everyone's
Tuesday
actually
need
engine
bits,
all
the
sensitive
to
them.
As
far
as
we
know
no
earlier
for
that,
we're
using
the
LP
one
space
uses
this
yen,
so
I
don't
fit.
We
miss
a
lot
by
ignoring
the
Chien
bits,
but
in
any
case,
if
we
had
to
take
in
bits
into
account
and
yeah,
we
should
either
transmitted
traffic
glass
filled
in
form.
C
B
As
long
as
you
provide
a
way
for
the
guy,
who
will
need
it
one
day
to
transport
it,
so
you
don't
force
that
the
matching
operator
is
ignored,
but
you
also
say
hey.
You
can
use
this
as
a
machine
operator
if
it
makes
sense
for
you
right,
you're,
okay,
because
people
won't
use
it,
but
at
least
is
possible
right.
C
B
The
point
is
right:
now
we
are
doing
IP
UDP,
so
we
could
get
the
seein
bit
in,
but
we
could
not
reflect
it
out
because
we
don't
have
a
transport
that
carries
it
right
and
so,
unless
go
up
later
carries
the
ecn
at
the
co-op
layer.
It's
not
transported,
we
don't
have
to
CP
run,
but
in
the
future,
if
you
do
TCP,
then
you
will
have
to
make
sure
that
you
can,
if
you
wish
transport
this
en
bit
so.
B
I
Of
town,
so
we
we
have
a
tool
button
toolbox
to
do
compression
and
it
works
with
the
toolbox.
Then
we
have
example
how
to
compress
the
ipv6
peon.
We
cannot
go
on
all
the
cases,
so
maybe
just
to
add
the
things
that
say:
okay,
you
can
send
it
easy
and
with
less
be
in
that
section,
but
that's
all
if
we
do
not
mandate
ignore.
C
B
C
B
C
A
So
yeah
I
wrote
this
and
I
actually
looked
at
this,
so
it
starts
with.
If
the
diff
surfer
does
not
vary,
and
it's
known
by
both
sides,
the
field
is
blah
blah
blah,
so
it
starts
with
if
the
surf
field
does
not
vary.
So
for
me,
that's
like
a
generic
framework
and
you
say:
okay.
Well,
it's
it's
upright
like
this,
but
in
case
it
varies.
Well
then
you
can
use
some
of
the
other
things
that
you
know
in
the
tool
set.
But
actually
this
brings
may
be.
A
A
good
question
is
to
to
to
may
provide
some
some
sentence,
but
I
think
it's
already
pretty
reasonable.
It's
clear
that
okay,
well
here,
are
some
recommendations
and
general
recommendations
that
works
in
case
you
you're
able
to
use
the
standard
framework,
and
you
want
to
do
something
that
it's
not
here.
What
just
use
it
so.
C
I,
like
that,
okay,
we
had
a
comment
from
Edgar
regarding
your
data
unit
and
use.
Oh
yeah
will
will
come
to
you
in
updated
text
the
best
we
can
yeah,
so
that
was
the
technical
outcome,
one
of
the
technical
outcomes
of
the
so
it
she
was
working
on
the
implementation
of
especially
of
the
new
single
padding
technical
solution
that
I
just
described,
and
so
we
have
this
big
computation.
I
didn't
go
through
it
in.
J
C
But
you
complete
to
make
all
the
shake
packet
that
was
fragmented
and
so,
as
we
said,
it's
a
bunch
of
bits
and
it's
no
longer
a
byte
online
stuff
and
and
so
which
he
or
over
Skype
from
Japan
said
he.
So
he
hadn't
fully
understood
this
single
padding,
McKenna
and
once
I
got
the
explanation
to
him.
He
said
yeah,
but
I
can't
compute
this
year.
C
See
on
that,
because
it's
that
by
tonight
and
I
said
yeah,
you
don't
need
white
alignment,
computer
COC
COC,
it's
just
a
linear
feedback
register,
but
I
said
name,
but
all
the
libraries
that
I
can
use
our
byte-oriented
do
I
have
to
write
my
own
COC
code.
So
that's
a
good
point,
implementation
point.
So
do
we
do
we
just
say
find
a
way
of
computing
it?
C
Yes,
you
on
a
bunch
of
bits
and
don't
bother,
don't
bother
us
with
byte
alignment
or
do
we
specify
that
we'll
take
the
bits
and
fill
up
the
last
byte,
so
we
can
use
a
standard
library
or
leave
it
to
the
technology
specifically
draft
to
specify
how
the
one
computer
make,
because
the
CRC
is
left
to
them
as
anyway.
So.
B
H
C
C
C
As
okay,
so
what's
the
situation?
If
you
haven't
followed
that
conversation
so
right
now,
we
don't
mandate
that
the
windows
are
fully
utilized.
So,
let's
suppose
we
have
window
numbered
zero,
which
starts
sending
fragments
with
FCN
decrementing.
So
now
we
at
this
point
in
time
we
mandate
that
the
Sen,
the
counter
decrements
from
the
maximum
value-
that's
known,
max
wind,
max
n,
cfcn
in
a
sequence,
D
commenting
down
and
then
the
last
one
must
be
zero
and
doesn't
have
to
be
continuous.
C
So
a
sequence
like
four
three
two
is
zero
is
legal
at
this
time,
and
so
the
issue
is,
if
you,
if
F
scene,
number,
two
gets
lost
the
way
the
mechanism
is
described
today.
Is
that
the
because
of
the
zero
here
the
receiver
will
send
an
AK
with
a
bitmap
telling
the
sender
what
fragments
it
has
received.
C
It's
not
a
very
long
time,
but
it's
still
some
time
and
then
because
this
time
expires
the
sender
we
now
send
an
empty
or
zero,
which
is
kind
of
an
AK
request.
We'll
get
the
AG
from
the
receiver
and
from
that
it
knows
that
F
ciento
got
through
and
and
it
will
start
sending
the
next
window,
W
equals
one.
So
we
have
this
extra
time
here,
an
extra
round
trip.
C
So
if
we
there
are
three
options:
either
we
you
say
yeah,
it
works
even
though
it's
a
bit
longer.
We
have
a
timer
and
explanation
is
a
bit
harder.
We
could
leave
it
like
this
and
educate
people
on
as
to
how
this
is
supposed
to
work,
or
we
could
non-date
that
wind
before
I
you're
not
allowed
to
send
for
three
to
zero.
C
You
have
to
send
four
three
two
one
zero
or
we
could
also
mandate
that
when
you
do
a
retransmission
like
this
ft
and
two,
you
have
to
send
FC
and
zero
again,
which
serves
as
a
neck
request.
So
these
are
the
three
options
and
after
discussing
with
the
offers
and
with
Pascal,
we
were
in
favor
of
option.
2
mandating
that
the
windows
before
in
part,
because
it
makes
it
simpler
to
understand,
leaves
less
open
to
interpretation
so
in,
in
which
case
it
works
like
this
FC
and
who
gets
lost.
A
C
C
M
One
Carlos
in
here
no
I
support
the
option
2
and
in
fact,
looking
at
the
detailed
text.
I
think
that
that
is
fine
for
the
sender
for
the
receiver.
I
think
we
might
need
to
specify
that
the
the
shikaka
mas
be
sent
after
I,
either
an
all
zero,
all
one
or
the
last
fragment,
because
at
this
point
we
know
which
one
is
the
last
fragment
that
was
retransmitted
I.
C
C
Pascal
had
another
comment:
the
texts
sometime
talks
about
the
expected
window
and
I'm
going
to
use
that
drawing,
for
example,
here
we
are
oops
yeah
we're
sending
FC
info
I've,
seen
three.
They
have
the
W
bit
0.
So
at
this
point
we
are
expecting
more
fragments
from
windows
0.
This
is
the
expected
window
in
the
text
says.
If
we
get
a
message
with
a
that
looks
like
a
fragment
with
W
bit
equals
to
1,
we
reject
it
because
this
is
not
the
expected
window.
So
in
this
example,
it's
easy
with
Pascal
commented
on
with
that.
C
At
some
point
there
is
a
point
where
receiver
doesn't
know
what
it
expects
and
the
text
looks
like.
We
always
know
what
we
expect
in,
for
example,
again
in
this
document.
In
this
sequence,
after
the
egg
has
been
sent
out,
the
the
receiver
could
legally
receive
either
the
next
fragment
for
the
next
window,
so
the
window
bit
has
has
been
flipped
or
the
egg
has
been
lost
and
the
receiver
at
the
center
would
send
an
act
request,
another
form
of
an
all-zero,
and
this
one
will
have
the
window
bit
0
and
both
situation
perfectly
legal.
B
There
is
another
side
effect
of
this
expected
window,
which
is
should
just
silently
drop
the
wrong
window.
Then
you'll
come
back
to
the
right
window,
but
it's
actually
window
plus
2
and
so
I'm.
Just
wondering
if
we
read
don't
agree
and
that's
the
text
is
very
clear
on
that,
and
there
are
good
reasons
for
that:
to
get
packets
out
of
order
seems
to
be
that
if
you
end
start
being
in
the
wrong
window,
the
only
thing
you
can
do
is
aboard
with
maybe
I'm
wrong.
B
B
B
B
The
receiver
discards
blindly
now,
when
we
go
back
sender,
goes
back
to
window
0.
It
looks
like
oh,
we
just
dropped.
Those
things
were
back
on
the
windows,
your
own
web,
but
no,
we
flipped
from
0
to
1
and
to
send
us
with
0
12
back
to
0,
then
we're
completely
out
of
sync.
So
the
only
thing
that
can
really
done
is
to
I
think
if
we
get
the
wrong
window
is
not
just
to
drop
the
packet,
but
probably
to
abort,
but
that's
ok,.
B
I
To
come
back
to
your
comment
of
a
broad
thing,
I
think
it's
very
dangerous,
because
if
you
have
a
queue
where
you
have
a
delay,
maybe
you
have
a
packet
that
stained
the
queue
because
our
transmission
error,
you
may
receive
twice
the
sampling,
and
so
it's
better
to
ignore
it
than
cutting
all
the
connections.
There
is
some
very
strange
behavior.
Sometimes,
let's.
B
Let's
look
at
the
flows
very
carefully
because
I
think
this
this
room,
that
we
can't
receive
things
out
of
order
and
because
the
sender
is
always
the
one
which
decides
when
the
window
is,
if
we
climb,
if
we
are
very
clear
on
when
we
do
not
expect
anything
right-
and
this
was
the
mistake
we
are
fixing
here.
If
we
know
exactly
when
we
can
expect
something-
and
we
know
what
that
thing
is
with
the
out
of
order.
Rule
I,
don't
think
it's
possible.
It's
not
out
of
further.
B
If
things
arrive
in
the
order
that
the
sender
sent
them,
but
you
kill
everything,
so
yeah
I'm
not,
but
if
you
don't
I
mean
you,
you
will
start
taking
the
you
will
send
I
mean
if
it's
a
big
thing
with
five
windows
you
will,
you
will
receive
part
of
the
first
window,
drop
the
second
window
because
you're
out
of
sync
except
the
third
window
as
the
first
one
and
then
the
fourth
and
then
the
fifth
and
then
you
go
to
the
make
and
you
discover
you're
screwed.
So.
B
C
Know
what
we've
been
banging
our
heads
on
that
for
years
now,
I
can
remember
a
design
session,
whether
it
in
Dallas,
where
raining
I,
would
recommend.
My
feeling
is
that
we
should
make
this
simpler
so
that
we
at
least
agree
what
works
and
what
doesn't
and
we
don't
need
half
now
to
just
describe
the
potential
issue.
C
So
the
four
windows
is
one
thing,
I
think
another
one
just
dropped
my
head
anyway,
oh
yeah,
Kyle
Connor,
whom,
in
my
opinion,
is
one
dangerous
situation
where
we
create
this
misalignment
between
the
receiver
and
transmitter
very
easily
and
and
the
last
common
that
yeah
that
Anna
mentioned
is
another
one
Pascal
you
had
that
comment
as
well,
seeing
the
text
and
fragmentation
still
hard
to
pass
and
I
did.
The
second
line
is
mine.
Actually
I
agrees
as
many
ifs,
many
otherwise,
which
you
don't
quite
know.
What?
If
there
relate
to.
B
C
Also
means
okay,
so
this
text
is
hard
to
read.
I
totally
agree:
I
would
be
in
favor
using
pseudo
code,
so
that
we've,
you
know,
parentheses
braces.
So
you
know
what
what
otherwise,
but
if
otherwise
we
relates
to
etc
and
when
I
told
told
that
too
long
he
said
yeah.
That's
a
very
reason
why
we
drew
state
machines
because
we
were
banging
Heights
on
on
the
text
and
could
make
a
sense
of
it.
So
we
drew
the
state
machine.
C
So
this
is
what
is
in
appendix,
and
this
is
a
formal
description
of
the
algorithm
except
right.
Now,
it's
not
knowledge
if
it's
in
appendix
and
the
text
is
normative
and
the
text
is
hard
to
read
so,
hence
the
Anna's
proposal
that
she
disclosed
before
my
slide,
which
is
why
don't
we
make
this
normative
and
it
takes
being
a
read
out
an
illustration
of
space.
E
C
E
B
N
N
Basically,
the
reviews
have
been
on
the
text
of
fragmentation,
so
we
may
need
to
to
make
sure
if
we
want
to
use
state
machines
as
normative
content,
that
they
are
not
alike
like
hidden
surprises
and
also
something
else
is
whether
the
state
machines
by
themselves
are
like
self
containing
contain,
let's
say
or
then
we
need
some
text
that
describes
the
distinct
machines,
which
is
new
text
and
so
on.
So
I
hope
we
don't
have
conversion
issues
here.
This.
A
Yes
and
I
can
second,
that
I
think
that
we
need
to
build
a
good
standards
and
a
blue
technology
and
I
think
that
having
the
state
machines
makes
things
more
readable
and
more
more
understandable.
So
in
case
we
can
open,
we
can
have
exactly
like
a
like.
We
opened
the
last
call
but
same
people.
Okay,
we've
got
people,
you
have
previewed
the
other
parts
of
the
text.
A
This
is
this
was
the
change
and
you
know
there
is
the
potentiality
of
some
mismatch
between
what
you
have
read
in
the
text
and
what
is
here
in
the
state
machine,
even
though
I
actually
in
I
would
be.
Supposing
I
would
imagine
that
most
of
the
people
that
actually
read
did
already
review
the
text.
They
actually
also
reviewed
the
state
machine.
So
I
would
imagine
that
the
the
the
load
on
the
reviewers
will
not
be
that
great
in
that
aspect,
but
we
need
to
produce
good
quality
standards
right.
A
B
B
We
are
talking
about
reopening
the
work
of
let's
go
because
we
are
to
close
it
today
and
I
mentioned
that
to
told
me
on
the
personal
discussion
that
you,
you
did
not
complete
your
review
and
you
got
in
more
time
and
the
question
to
you
that
justice
falls
in
the
nick
of
time
is
whether
what
you,
the
time
you
need,
is
on
the
whole
document
or
more
specifically,
on
the
fragmentation
piece,
because
the
discussions
we
are
having
now
are
on
the
fragmentation.
Piece
and
I
was
thinking
that
we
could
have
closed
the
workgroup.
B
Let's
go
and
say
shake
IP
UDP
is
all
set.
What
still
open
is
the
fragmentation?
Let's
reopen
the
welcome
press
call
for
the
fragmentation
piece,
including
this
as
partisan,
normative
text.
So
that's
that's
pretty
much
the
proposal
that's
on
the
table,
but
that's
it
does
it
work
for
you
I
mean.
Do
you
think
that
you
were
you're
happy
with
shake
I
supposed
to
oh.
F
This
is
I'm
Charlie
Perkins
and
thank
you
for
for
asking
I'll
I
see
that
it's
high-priority
I
think
that
this
solution
is
nearly
in
hand.
I
saw
the
comments
from
JC
that
I
think
I
deserve
to
beacon
to
consider
them
worked
out
and
when
that's
done,
I
will
try
to
finish
the
review
all
of
the
three
weeks
or
so
would
that
be
okay,
yeah.
B
F
The
fragmentation
is
by
far
the
most
complicated
part
of
the
document,
so
once
that's
worked
out,
the
rest
will
see
pretty.
Naturally
the
comments
that
I've
made
about
the
compression,
decompression
I
think
er
are
fairly
easily
resolved
and
then
I
think
that
the
examples
in
the
appendix
should
be
proof
read,
but
that's
a
lot
of
reading
a
lot
of
pages.
So
the
question
is:
how
close
of
a
review
do
you
want?
F
B
Particular
points
you
can
discuss
with
a
guard
right
next
to
you.
Yes,
that's
something
that
has
raised
anyway
and
I
think
we
have
a
resolution
for
that,
so
I'm
not
too
anxious.
So
right
now
the
table.
The
purpose
of
the
proposal
will
be
that
we
reopen
the
workgroup,
let's
go
underneath
for
the
fragmentation
piece
for
the
NX
if
they
come
right
out
of
the
implementation
running
on
the
air,
so
I'm
not
too
anxious
either
it's
more
like
for
the
education
of
the
reader,
because
the
bytes
are
correct.
J
B
F
I
agree
with
your
priorities,
but
I
also
know
that
are
people
who
can
read
certain
formulations
of
the
mandates
in
different
ways
and
I'm
quite
sure
that
it
can
be
sharpened
and
some
people
America
how
many
times
you
tell
them
they'll
point
to
an
example
in
appendix
to
validate
their
point
of
view.
And
yes,
this
is
why
we
have
interrupts.
Also
I
do
think
that.
B
F
M
Juan
Carlos
Amiga
secrets
again
the
so
I
would
be
ok
with
opening
further
for
the
fragmentation
part.
In
fact,
the
comments
I
sent
last
night
focused
only
on
the
only
fragmentation
so
depending
on
the
discussion
of
today
that
for
me
that
could
be
like
ok
on
the
on
the
state
machine
side,
though
I
think
that
there
there
could
be
some
mismatches
and
I
I,
wouldn't
mind,
seeing
the
state
machine
as
one
example
of
the
normative
test
text,
but
having
both
in
the
normative
side.
M
I
would
be
not
so
easy
about
potential
mismatches
or
or
duplications
I,
for
instance.
One
one
example
that
I
was
I
was
suggesting
in
the
text
to
clearly
separate
that
the
sender
and
the
receiver
behaviors,
because
right
now
they
were
all
mingled.
So
to
me
that
was
a
very
good
way
to
explain
how
the
standard
words,
but
for
the
state
machine
I
think
it's
it's
a
little
more
complicated
to
understand
what
it
is.
I
wouldn't
mind
again
having
it
as
an
example
for
an
implementer
on
once.
You
understand
the
the
specification.
M
Ok,
this
is
a
way
how
you
could
implement
it
and
actually
I,
don't
mind
where
it
is
in
the
in
the
in
the
spec.
But
I
would
rather
have
the
text
being
the
normative
side
and
this
being
an
example
in
whichever
part
of
the
of
the
standard.
In
one
last
comment,
the
the
the
comments
I
sent
to
not
include
yet
the
state
machine.
There
were
a
lot
of
ambiguities
in
the
industry
and
specification
that
I
try
to
clear
out
with
my
comments
last
night,
but
that
still
not
covers
the
state
machine
for
sure.
Oh.
B
Sure
the
point
was
I
mean
if
we
move
this
tech
machine
to
no
matter.
If
we
are
asking
the
group
to
review
it
and
yes,
it
should
be
reopened.
I'm,
saying
things
like
wait
for
next
window.
We
just
said
it
says
you
know.
The
point
is
this
is
very
concise
and
sorry
I
mean
it
works,
but
it's
it's
hard
to
understand
by
itself
without
text,
I
mean
there's
no
way
to
do
code
out
of
this
right
to
document
know
what
do
all
those
acronyms
are
for.
So
certainly
this
needs
to
be
sustained
with
text
yeah.
C
That
was
my
suggestion,
but
this
penomet,
if
in
the
text,
is
a
but
specifically
as
an
and
help
to
rate
the
state
machine.
Otherwise
to
make
the
text
crystal
clear,
we'll
need
to
have
States
named
Stacey
in
this
condition.
The
receiver
enters
this
state
and
in
this
state.
If
it
gets
this,
it
goes
there
and
basically
Weber
phrasing
state
machine.
O
C
O
The
Ramos
Erickson
I
actually
totally
support
what
Carlos
on
and
one
it
has
has
also
say
about
the
state
machine
I
mean
for
an
implement,
or
it
is
very
nice
I
think
you
see
the
state
machine.
You
know,
okay,
where
I
put
the
things
and
then
I
just
kind
of
mirror
it
in
my
coat,
but
from
understanding
the
stander.
O
It
makes
it
quite
hard
like,
at
least
in
my
opinion,
knowing
what
flows
to
follow
and
knowing
where
the
things
might
end
up,
and
why
and
so
on
it
is
not
intuitive
and
I
would
prefer
pseudocode
actually
type
of
text
that
that
the
estimate
is
that
they
are.
There
is
another
reason
for
this,
and
is
that
if
it
becomes
mandatory,
it
means
that
I
have
to
basically
mirror
the
same
thing
in
a
norm.
A
C
So
yes
can
I
suggest
something.
It
seems
to
me
from
what
I
hear
from
the
room
that
we
have
a
free
free
weight
choice
when
first
choice
is
keep
the
technology.
If
you
improve
it
and
the
state
machine
stays
other
as
an
appendix
and
yes,
it
needs
to
be
consistent.
It
would
be
nice
if
it
were
consistent.
Second
choice
is
create
new
pseudocode
that
becomes
normative
and
pretty
much
the
text
disappears
or
maybe
stays
as
comment
for.
C
The
pseudocode
third
option
is
bringing
the
state
machine
as
a
normative
part
and
use
the
text
as
an
explanation
for
people
to
be
able
to
read
to
pass
a
state
machine
and
in
the
first
case
it's
pretty
much
in
continuity
with
what
we
have.
So
maybe
we
don't
need
to
open
a
new
working
group
last
call.
We
could
just
extend
this
one
and
second
and
third
case
it's
totally
new
text
and
it's
a
new
working
group
class
code.
I
think
that's
a
situation.
B
Basically,
if
we,
if
we
extend
a
work
group
last
call
and
thinking
about
what
one
calais
told
us,
we
need
to
ask
people
when
you
review
this
text.
Please
have
the
this
time
thing
in
front
of
you
and
shake
that
what
you're
reading
matches
that.
So,
if
it
does
not,
then
that's
an
indication
that
maybe
the
text
has
something
wrong
or
something,
and
now
we
fix
the
text.
So
the
text
days
the
normative
piece,
but
at
least
we
mean
with
the
review,
is
ritu
to
look
at
that
text
in
front
of
that
funny
state
machine.
M
Here
again,
yes,
in
fact,
I
would
agree
what
you
just
said:
I
would
extend
it
to
saying.
Maybe
the
text
is
wrong,
or
maybe
the
state
machine
is
wrong,
because
that
that
could
also
be
the
case.
I
would
actually
go
for
for
option
one
to
me
that
doesn't
mean
that
we
don't
have
to
clean
the
state
machine.
We
still
have
to
look
at
it,
the
again
again
like
what.
M
It's
not
because
it's
an
an
annex,
it
will
be
wrong
because
it
still
will
be
a
would
create
a
lot
of
confusion
in
the
specification
so
I'm
all
for
for
reviewing
it
and
to
me
the
best
way
is,
is
just
to
make
sure
that
the
text
is
clean
and
and
then
the
state
machine
supports
the
text
that
that
will
be
my
prefer
option
and
again.
I
think
that's
also
time
wise,
perhaps
the
most
convenient
one.
B
So
since
we
are
not
changing
anything,
there
is
no
confirmation
to
do
it.
No
mailing
list,
I
was
just
proceeding
like
we
are
we'll
just
extend
a
welcome
last
call,
which
is
something
wanted
to,
but
we'll
world
it
very
carefully
that
the
extension
applies
only
to
the
fragmentation
and
that
part
of
doing
that
review
includes
validating
that
which
already
feels
the
final
state
machine
appendix
and
that's
what
to
do
for
the
chairs
works.
What's
not?
Okay,.
B
C
Free
yeah,
because
it's
already
so
it's
less
editing
that
inventing
the
new
pseudo
code
because
to
me
making
the
text
crystal
clear,
is
kind
of
writing.
Pseudo
code
will
have
to
name
the
states
and
in
the
text
I
currently
and
say,
if
receiver
and
in
that
state
and
it
receives
this,
then
it
does
that
so
basically,
paraphrasing
the
state
machine.
C
P
B
C
C
C
A
C
Yeah,
because
you
know
we
want
this
text
to
be
clear
and
me
such
a
thing,
which
has
all
these
intricate
all
these
loop
bags
all
these
states.
The
only
way
you
make
it
clear
to
me,
as
an
engineer
with
my
mindset,
is
to
name
those
states,
because
otherwise
we
end
up.
You
know
the
otherwise,
on
the
other
hand
that
we
have
currently
in
the
text,
we
never
know
what
they
refer
to
and
I'm
following.
If,
if,
if
and
then
the
text
says
else,
but
what
are
we
talking
about?
Is
it's
this
else
or
this
MS?
C
C
C
B
F
I
know
I'm
Charlie,
Perkins
I
just
want
to
a
strongly
agree
with
what
you
just
said,
because
we
can't
tell
if
the
state
machine
is
right
or
not.
If
we
don't
understand
it
and
the
understanding
comes
from
the
intuition,
we
get
from
the
names
of
the
arcs
and
the
actions
and
so
on.
Yeah
and
also
I
would
not
like
to
see
it
be
normative,
but
that's
part
of
the
vote.
You.
O
O
Maybe
that
makes
like
it
is
at
the
moment,
maybe
that
everything
is
analyzed
like
one
case,
but
maybe
there
should
be
some
kind
of
okay
initialization
and
then
there
should
be
one
part
of
the
sequence,
then
sending
packet.
That's
another
part
of
the
secret
that
an
error
case,
and
then
maybe
there
is
something
that
is
more
specific
for
the
other
case,
I
think
the
text
could
be
a
bit
much
better
structure
so
that
actually
depict
the
description
of
the
state
machine
in
a
much
clearer
way.
O
So
the
problem
with
I
have
now
with
the
two
options
that
you
are
given
are
three
options
actually
you're
given?
Is
that
it
doesn't
really
reflect
what
I'm
saying
because
I
don't
know?
Is
it
number
one,
meaning
that
this
restructuring
can
happen,
or
is
it
that
number
two
and
it's
not
necessarily
that
it
has
to
be
exactly
pseudocode,
but
when
I
mean
see
what
the
code
is,
if
then,
whatever
else
so
then
I
don't
know
about
these
options
aborting,
then
it's
a
bit
conflicting
for
me.
B
Know
in
my
in
my
mind,
if
you
want
to
be
able
to
track
this
with
the
text
and
the
text
should
be
structured
like
a
section
prostate
or
something
like
that
yeah
and
then
in
that
stage
you
going
to
explore
all
the
branches.
That's
that
start
from
there.
That's
text
font!
That's
how
I
see
it.
If
you
don't
do
that,
there's
no
way
to
match
one
with
the
other.
P
B
M
Just
responding
quickly
to
to
a
PRI
a
lot
of
the
comments
that
I
sent
last
night
were
structuring.
Actually,
the
text
is,
of
course,
moving
left
and
right,
but
in
fact
I
was
asking
to
put
carriage,
returns
and
and
separate
paragraphs
so
that
it's
clearly
one
action
in
one
paragraph
and
not
in
a
huge
paragraph,
mixed
between
sender
and
receiver.
So
it
was
in
line
with
with
that
thought,
and
that's.
A
M
A
With
it,
so
if
we
need
to
go
with
the
hum
now
option,
one
the
way
I
hear
it,
it
goes
with.
We
have
the
text
that
is
restructure
in
a
way
that
Edgar
I
mean
that
Elgar
yes,
but
but
we
have
the
the
state
machine
next
to
it,
and
you
know
we're
able
to
attune
it,
but
the
state
machine
remains
in
the
appendix,
so
it
is
non
normative.
A
So
that
is
option
one
option
two
is
we
say:
well,
we
have
some
text,
but
we
need
to
rewrite
some
pseudo
code
around
it
and
then
I'm
not
sure.
If
we
and
then
we
can
put
the
the
state
machine
or
not
I
mean
you
see
an
option
three
is
we
put
the
state
machine
as
normative
and
we
put
some
illustrative
text.
A
A
A
J
C
B
I
A
So
we
need
to
take
this
to
the
menu
list.
That's
that's
for
sure.
I
I
do
here
the
the
point
of
so
what
Edgar
mentioned
actually
was
pretty
a
good
indication
for
me
that
if
we
make
the
the
the
state
machine
normative
thanks,
then
that
could
pose
some
issues
with
other
ratios.
Actually,
you
know
getting
the
adopting
the
technology,
but
let's
get
this
to
the
mat.
Let's
get
this
to
the
mailing
list.
In
both
cases
we
will
continue
the
working
group
last
call
and
we'll
take
the
decision.
A
How
we
move
the
things
around
I
do
feel
that
in
any
case,
we
need
to
improve
the
text
a
little
bit.
So
that's
that's
happening.
That's
not
that!
There's
no
question
about
it
and
we
have
we.
We
do
need
input.
So
in
both
options
that
were
priority,
we
do
need
to
see
how
the
that
state
machine
matches
to
texts,
so
the
work
remains
generally
the
same,
so
people
can
start
people
can
start
working
on
it
and
then
we
can
start
a
question
on
the
mailing
list.
A
B
Say
I
fully
agree
with
Alex
I
mean
most
of
the
work
that
has
to
be
done
is
actually
exactly
the
same,
whether
we
at
the
end
of
this
today
we
take
this
fine
estate
machine
but
or
not
because
anyway
the
text
us
to
match
it.
The
text
has
to
be
understandable
and
has
to
be
restructured
so
as
to
match
it
right.
B
The
only
thing
which
which
I'm
a
bit
afraid
of
and
committee
will
be
that
God.
If
some
technology
just
meet
this
needs
a
subset
of
this
I'll
need
a
superset
of
this.
Then
then
officer,
then
the
normative
FSM
is
a
problem,
and
so,
let's
do
as
if
we
took
option
three
and
we
decided
the
last
minute
quote:
unquote
whether
we
actually
effectively
make
it
normative.
B
M
B
C
C
Udp
illusion,
if
you
use
fragmentation
for
something,
oh
sorry,
if
we
got
fragment,
can
we
still
alight
UDP
checksum,
so
yeah
we
could
rely
on
l2
is
just
see
if
it's
wrong
enough
and
the
technology
specific
documents
should
tell
that
or
we
we
could
fragment
the
packet
into
one
fragment
just
to
have
the
benefit
of
the
make.
If
we
want
to.
B
C
B
B
Other
layer
to
see
oh
well,
no
more
IP
packet
as
earlier
CO,
CO,
2
bytes
and
then
the
UDP
checksum
2
bytes.
So
the
strength
is
4
bytes.
Now,
if
you
say
I
I,
don't
I
just
use
my
layer
to
see
or
seen
you
just
get
rid
of.
Do
you
need
to
check
sum
which
which
ipv6
mandates?
So
so
you
will
have
to
fight
the
whole
world?
If
you
just
to
say,
I
have
a
two
bytes
yours
yeah,
that's
good
enough
and.
C
C
B
C
Okay,
so
making
sure
people
understand
that
fragmentation
reassembly
is
optional.
Yes,
this
is
intention
we
will
try
to
better
and
especially
in
appendix
G
has
been
said
and
I
said
before
you
came
in
it's
currently
just
a
laundry
list
and
it's
not
structured,
but
just
the
first
question
to
be:
shall
you
use
fragmentation
or
not?
And
if
you
don't
and
you
don't
care,
defining
the
parameters
for
fragmentation
well,
we
agree
that
Appendix.
C
is
a
very
rough.
C
Whether
it
is
right
now
of
target
values,
type,
nothing
will
I,
don't
know
if
it
just
want
to
talk
about
it.
Now,
if
we
talk
about
it
on
the
mailing
list,
I
don't
know
out
of
implication
about
all
the
computation
I
think
we'll
discuss
that
is
well
meanest
and
one
colors.
You
have
Jones
lot
to
discuss
this
and
just
keep
them
that
that's
okay!
C
Is
there
one
more
that
you
don't
this
one,
oh
yeah,
so
you
suggested
you
want
more
than
one
bit
for
FCN,
even
in
no
arc
mode
right
now
the
draft
says
and
is
equal
to
one
in
Newark,
so
well,
yeah,
that's
mostly
for
alignment
purposes,
I
understand,
because
when
we
talked
in
the
corridor
you
said
you
wanted
to
convey
some
information
to
the
receivers
as
to
how
many
fragments
will
be
coming
next.
But
now,
especially
in
your
when
sorry
yeah.
C
F
M
So
the
case
what
I'm
saying
would
be
if,
if
we
don't
indeed
start
with
max
win
FCN
as
at
the
start
value,
we
would
semantically
convey
information
about
the
number
of
fragments,
especially
in
the
case
that
that
we
transmit
in
the
knock
mode
less
than
a
window.
So
let's
say
that
less
than
a
full
window,
let's
so
yeah,
not
full
window,
meaning
that,
let's
say
you
have
a
window
of
eight
fragments,
but
you
would
you
just
want
to
transmit
five
five
fragments
in
Nowak
mode.
C
B
A
A
Okay,
thanks
so
homework,
but
we're
in
good
shape.
So
just
so
for
the
presentation
for
next
presentation,
we
are
running
20
minutes
behind
schedule.
So
we
would
like
to
ask
some
of
our
presenters
to
reduce
a
little
bit
so
Juan
Carlos
from
15
to
10
minutes.
So
if
you
can
shorten
it
a
little
bit
the
presentation
and
the
whole
sale,
because
there
are
two
parts
there
is
the
coop
part
and
the
core
part.
So
we
had
a
45
minute
slot
if
you
can
get
down
to
30
minutes,
not
very
great,
so.
A
I
Okay,
so
I'm
going
to
talk
about
coop.
So
in
fact,
just
to
give
you
a
story
at
the
beginning,
we
need
we
wanted
to
have
two
documents,
one
that
described
IP,
UDP
compression
and
the
other
one
will
be
co-op
compression
and
we
move
all
the
good
tools
in
the
first
document.
So
in
this
document
we
describe
more
how
to
do
the
compression
of
coop.
So
first
we
explain
we
explain
what
is
the
difference
between
UDP,
IP
and
co-op,
because
you
don't
manage
the
compression
in
the
same
way.
In
coop,
you
have
asymmetry
in
fields.
I
They
are
not
the
same
in
different
way.
The
fields
are
variable,
so
you
have
different
lengths
on
all
that
things
make
that
co-op
is
a
little
bit
different
than
what
we
do
with
UDP
on
a
PC.
So
we
have
the
first
section.
That
explains
that,
and
we
have
also
add
recently
a
new
section
about
Oscar.
That
is
a
way
to
secure
co-op
and
we
can
have
very
efficient
result
with
that
and
I
will
not
go
into
detail
because
Rick
ado,
we
present
it.
I
So
the
scope
of
the
coop
document
is
in
can
be
seen
in
3-way.
Ever
we
compress
coop
UDP
ipv6
in
a
single
rule,
or
we
have
a
specific
rule
for
coop
on.
We
have
maybe
other
rules
for
the
rest
of
a
stack
or
for
a
case
of
Oscar.
We
have
two
rules,
one
we
will
focus
on
the
inner
either
and
the
other
one
on
the
outer
reader.
So
I
will
go
very
quickly
in
all
the
fields
because
I
don't
have
too
much
time.
I
But
let's
say
that
it's
regular
mechanism,
but
we
have
defined
in
in
shake.
So
it's
not
not
very
complex
and
we
go
in
for
all
the
fields
that
we
have
in
coop
and
all
the
options.
So
what
is
important,
for
example,
for
type
or
code?
This
is
a
symmetric
field
because
you
find
it
in
request
and
answer.
But
since
the
you
is
not
the
same
in
requests
on
answer,
you
can
use
that
to
have
a
bigger,
better
compression,
so
it
what
we
we
say
for
a
message:
ID.
I
We
have
a
message
ID
in
coop,
that
is
in
16
bits,
but
it
looks
too
big
or
very
big
for
LP
1,
because
we
will
have
less
traffic.
So
there
is
some
way
to
reduce
this
side.
So
it's
a
user
MSB,
for
example,
for
message
ID.
So
we
explain
how
to
do
it
and
we
can
recommend
to
use
a
proxy
when
the
client
is
outside
the
VLP
one
network
to
shorten
to
put
message
ID
in
some
short
value,
to
be
able
to
do
the
compression
same
thing.
I
For
the
token,
and
for
the
token
we
add-
or
so
something
that
talked
about
the
length
of
the
token,
because
a
token
has
a
variable
length,
we
have
to
worry
to
carry
this
variable
length.
It
will
be
to
to
send
directly
the
token
value
and
a
length
done
by
chick,
but
it
can
be
a
contradiction
with
the
length
given
by
coop.
So
we
say
you
have
to
use
the
length
given
by
the
token
length
fulfilled
of
coop,
and
so
it
imposed
to
create
a
new
variable
or
new
function
for
fatherland's
for
except
on
content.
I
So
we
we
have
the
regular
way
to
do
it,
for
this
field
is
the
same
thing
you
can
suppress
them,
use,
mac,
pin
lists
MSB
or
you
can
ignore
them
yuri
person.
Your
queries
are
a
little
bit
more
tricky
because
we,
we
are
variable
length,
compression
and
also
we
have
the
position,
so
this
field
can
be
repeated
several
time
in
coop.
So
that's
why
we
need
the
position
and
it
exists
in
or
less
than
that
way,
but
there
is
some
case
where
we
can
have
a
better
compression.
I
It's,
for
example,
if
you
have
a
field
that
his
slash
a
slash,
be
such
excellence
in
/this
Irish.
Why
so?
The
first
position
can
be
air
or
sea.
The
second
position
can
be
B
or
D.
So
if
we
use
a
regular
way
to
do
it,
we
will
have
one
bit
that
will
be
used
to
compress
and
say
if
it's
a
or
C
on
one
of
a
bit,
but
we'll
say
if
it's
B
or
D,
and
what
we
propose
is
to
have
a
way
to
put
in
a
matching
list.
I
I
I
Okay.
So
we
continue
with
all
the
fields.
Over
is
nothing
to
say
here.
There
is
a
comment
here
from
Evo,
and
the
many
missed
is
that
we
say
that
we
have
always
to
send
this
value.
It's
because
in
fact
this
value
are
generated
dynamically
during
by
the
system
ever
because
it's
a
tag
for
for
caching
or
it's
something
that
is
written
by
a
post
on.
So
we
cannot
focus
the
value.
So
we
we
have
to
send
it,
we
we
cannot
compress
it.
We
talked
about
the
over
RFC
so
but
define
options.
I
So
we
are
discussion
in
the
mailing
list
to
say:
do
we
allow
blocks,
or
we
say
that
blocks
is
not
usable,
because
we
have
fragmentation
and
in
fact
we
can
use
both
of
these
mechanisms.
So
we
allow
blocks
and
fragmentation
observe
is
something
that
is
quite
easy
to
manage,
no
response
or
so
on.
We
are
door
so
timescale.
Its
I
will
talk
about
it
after
it's
something
that
allows
ever
to
be
aware
about
the
time
you
have
to
kept
a
message
in
their
memory.
I
What
was
to
do
next
is,
for
example,
to
oughta,
make
the
text
more
clear.
In
fact,
we
put
a
lot
of
most
in
what
we
have
to
do
in
a
rule
and
it's
not
a
good
choice,
because
in
fact
people
can
have
more
more
liberty
to
do
what
they
want
with
the
rule
and
to
adapt
to
vary
behavior.
So
we
have
to
rewrite
the
text
to
make
it
more
liberal,
and
we
have
to
add
maybe
some
example
right
now.
We
have
a
very
simple
example
of
coop.
I
A
A
Yes,
we
hear
so
Ricardo
if
you
are
able
to,
because
we
already
presented
some
parts
of
these
slides
and
it,
of
course,
a
very
good
application,
but
we
are
running
a
little
bit
short
on
time.
So,
if
you're
able
to
thing
to
make
your
presentation
in
five
five
minutes
to
10
minutes,
that's
really
perfect.
Okay,.
Q
Q
Okay,
so
basically
our
score
has
a
main
mechanism.
What
it
aims
to
do
is
protect
as
much
of
the
message
as
it
can,
while
leaving
the
fields
of
coop
or
the
co-op
message
that
are
necessary
for
for
Prop
C
operation
out
in
the
open.
So
what
we
identify
is
that
inside
of
how
it
works,
it
splits
the
message
into
a
plaintext
and
is
sort
of
a
Prada
out
or
Heather,
which
will
contain
the
encrypted
message,
and
so
what
we
say
in
order
to
compress
this
effectively
to
get
everywhere
like
we
go
to
the
next
slide.
Q
So
this
is
the
basic
mechanism
that
we
will
be
operating
with,
so
if
we
can
go
to
the
next
slide,
okay,
so
if
we
look
at
the
inner
compression
as
we
call
it,
this
is
when
we
compress
the
plain
text.
This
looks
basically
like
a
regular
co-opt
message.
I
mean
it
has
basically
the
same
syntax.
It
has
the
color
code
options
and
then
an
optional
payload,
so
we
can
compress
this
pretty
much
the
same
way.
We
can
press
a
regular
co-opt
message,
there's
no
additional
rules
or
different
treatment
that
you
need
to
do.
Q
We
can
go
to
the
next
slide,
so
the
outer
compression
this
one
will
have
more
of
the
it
will
have
most
of
the
fields.
Actually
it
will
have
to
do
with
type
the
token
and
so,
and
so
what
pops
up
that
is
different
from
a
regular
co-op
message
is
that
we
now
have
to
handle
the
oscar
option,
which
is
the
new
option
that
defines
the
behavior
of
up
to
draft,
and
so
what
we
propose
is
going
to
be
to
divide
this
option
into
three.
Q
We
send
and
then
there's
also
the
key
ID
ID,
which
identifies
the
server.
These
are
our
most
important
parameters
that
can
sort
of
change
and
the
rest.
We
can
usually
mask
off.
We
have
found
out,
we
can
and
well
okay.
So
here
we
can
see
the
results
we
traded
with.
This
is
a
get
request,
and
so
we
compared
the
result
of
compressing
with
shake
the
get
request
without
protection
and
with
Oscar
protection,
and
we
see
a
cost
of
10
bytes
for
for
the
encryption,
and
we
can
see
these.
Q
These
additional
bits
are
they're
shared,
mostly
from
the
pin
and
the
kid,
and
then
there's
also
a
token
that
is
added
because
of
the
encryption.
And
then,
if
we
go
to
the
next
slide,
we
have
the
same
thing
with
a
Content
response.
There's
a
bit
of
a
difference
in
how
requests
and
responses
are
handled
by
your
score,
but
we
see
the
same
cost
of
10
bytes,
and
this
has
been
fairly
consistent
with
the
examples
that
we
tried.
H
London
from
Ericsson
well
I'd
like
to
thank
the
authors
very
much
for
including
a
score
in
these
documents.
Very
very
nice,
since
oscar
has
it's
in
an
outer
part,
you
could
use
chicken
on
applied
twice
and
I.
Think
that's
very
well
described
in
the
draft.
I
have
a
chance
to
talk
with
Lauren
and
Donna
yesterday.
H
Comments
I,
don't
have
them
at
the
moment,
but
we
noted
the
one
thing
about
my
confusion
about
term
ciphertexts,
so
we
are
we're
using
in
a
score
and
the
same
definition
as
in
in
RFC
51
16.
So
that's
the
standard
reference
for
authenticated,
encryption
and
cipher
text.
There
includes
the
authentication
tags,
so
there
is
a
single
output
and
the
identification
tag.
We
obviously
can't
compress.
So
that's
that's
something
that
we
have
to
add,
but
otherwise
it
looks,
looks
very
nice
and
I'll
come
back
with
more
specific
comments.
H
P
Good
so
I
also
read
the
draft
very
quickly
and
in
particular
the
oscar
part.
I.
Don't
have
the
coop
part
comments
yet
I
have
a
couple
of
comments
and
try
to
be
quick.
So
a
couple
of
minor
comments.
I
thought
in
the
example
would
be
actually
good
to
show
the
the
inner
compression
as
well
like
the
actual,
how
the
inner
compression
works,
because
right
now
it's
only
the
outer
compression
that
it
showed.
P
Then
I
think
I
understand
from
from
the
draft
that
when
you
saw
score,
you
have
to
Monday
to
set
of
rules
for
inner
and
for
outer
yes
and
I,
see
not
a
yes
and
I.
Think
that
would
be
good
to
have
it
explicit
for
people
who
do
not
understand
that
right.
Just
to
clarify
that
okay,
another
saying
India
example
I
thought
that
there
is
no
field
for
kinetic
context.
P
P
P
P
Yes,
of
course,
ok,
let
me
just
take
the
most
important
I
think
this
one
is
a
good
one,
so
we
reuse
sequence
numbers
you
know
score
and
we
define
that
we
have
5
bytes
for
sequence
numbers
and
when
you,
when
you
see
compression
that
gets
reduced
a
lot
depending
on
how
much
you
compress
it
and
what
happens
when
like
when
in
Oscar,
when
you
finish
the
sequence
numbers
you're
supposed
to
rekey.
So
what
do
you
do
when
you
shake-
and
you
finish
your
very
short
number
of
bits
for
sequence-
numbers
either?
P
You
add
something
in
the
text
to
say:
listen,
you
have
to
Ricky
like
5.
Bytes
is
not
the
maximum
that
you
can
send
any
more
or
you
specify
like
how
to
change
a
shake
context
or
something
like
that.
I,
don't
really
have
a
response
like
proposal
for
this,
but
something
to
think
about.
Ok,
that's
interesting!
I'm,
a
new
list.
A
Ok,
so
thank
you
very
much.
Francesca
I
think
you
going
I
think
thanks
for
gathering
their
own
text
for
this
work
and
that's
actually
a
really
what
is
going
to
be
driving.
Also
the
Chicago
co-op
right
now,
because
there
is,
we
were
waiting
for
some
time
to
to
have
reviews
for
people
that
come
more
from
the
co-op
world
and
right
now,
I
think
that's
what
would
this
work?
It's
really
we're
getting
where
we
or
we
need
it
to
be
so
with
this
I'm
getting
the
line,
because
we
need
to
move
with
the
next
presentation.
A
A
L
This
is
the
first
prevent
presentation
of
the
Sheikh
of
Aloha.
One
draft
I'll,
first,
very
briefly,
introduce
low
Hawaiian
for
those
that
don't
know
it
in
loja,
one
which
is
a
lp1
technology.
We
have
three
classes
of
devices,
so
they
are
representing
from
the
you
know,
lowest
power
to
iOS
power
class
here
class.
A
is
really
the
lowest
power
class,
the
device
transmits
whenever
it
wants
and
then
opens
tiny
receive
Windows
following
every
uplink.
So
the
only
time
the
server
or
the
network
has
an
opportunity
to
talk
to
a
device
is
following
an
uplink.
L
Class
B
devices
behave
exactly
like
class.
A
device
I
can
talk
whenever
they
want.
They
opened
our
x1
and
rx
2
slot,
but
on
top
of
that
they
also
open
synchronous,
listen
window
or
reception
windows
at
the
river
with
a
programmable
periodicity.
So
in
that
case
the
network
can
send
can
initiate
a
downlink
to
a
device
in
any
of
those
scheduled,
listen
windows.
You
have
a
latency
which
is
previously
in
Windows,
but
you
can
initiate
downlink
from
the
network
and
in
Class
C.
L
The
device
is
basically
listening
all
the
time
when
it's
not
transmitting
so
clearly,
Class
C
is
not
for
continuously
battery-powered
device,
but
it
can
be
used
temporarily
and
it
has
lowest
latency
because
basically,
the
network
and
talk
to
the
device
whenever
it
wants,
so
the
three
classes
of
device
come
with
different,
will
have
different
an
impact
on
the
way
we
perform,
for
example,
fragmentation
on
cheeky.
So
we
can
have
to
describe
the
cheek
augmentation
with
some
parameters
that
are
different
for
those
three
types
of
devices.
This
is
just
what
I
wanted
to
introduce.
L
Thank
you,
the
document
status.
For
the
moment
we
have
mapped
the
aloha
one
architecture
to
the
component
of
the
of
the
sheikah
framework
we
have
also
described
we
have
given
the
technology
specific
parameters
for
fragmentation
on
Aloha
100
artists
we
have
proposed
the
first
set
of
parameters,
follows
the
three
classes
of
devices
and
I
will
be
seeking
some
for
this.
We
have
made
some
trade
off
and
I
will
be
seeking
feedback
from
the
audience
on
the
some
of
the
trade-offs.
L
The
fragmentation
works
differently
on
the
uplink,
so
from
device
to
sheet
gateway
and
in
downlink
from
she
picked
gateway
to
device,
and
that's
actually
linked
to
the
asymmetry
of
the
network.
We
have
far
more
uplink
capacities
and
we
have
downlink,
we
cantle
item
or
a
lot
more
uplink
messages
and
downlink
messages.
So
keeping
the
number
of
downlink
messages
to
a
minimum
is
really
paramount
for
us,
so
on
the
uplink
we
using
a
window
of
eight
fragments.
So
this
is
why
FCN
is
actually
encoding
on
three
bits:
rule
ID
isn't
ribbet.
We
have
one
bit
detail.
L
L
The
payload
might
be
any
number
of
bites,
as,
of
course,
it
has
to
fit
into
the
limitation
of
the
l2
layer.
So
this
was
designed
to
get
an
exactly
one
byte
header,
because
no
one
is
byte
oriented,
so
L
toward
is
one
byte,
so
these
uplink
fragments
is
actually
the
selection
of
the
rule.
Id
field,
as
three
bits
was
actually
really
designed
to
to
end
up
with
an
8-bit
header.
On
the
downlink
side,
we
can
basically
acknowledge
every
single
message.
L
So
f
count
is
now
only
one
bit
alt,
so
all
messages
have
a
zero
bit
F
count
except
the
last
one,
which
is
an
all
one
fragment
which
is
actually.
Therefore,
as
the
one
in
the
FCN
field,
every
single
downlink
from
the
network
is
actually
acknowledged
by
the
device
and
retransmitted.
If
it's
not
acknowledged
peculiarity
here,
because
a
header
is
now
six
bit,
the
payload
of
each
fragment
is
actually
X,
bytes
plus
two
bits
each
time
and
we
apply
the
appropriate
padding
in
the
last
message
or
in
the
last
fragment
of
the
fragmentation
session.
L
L
We
think
that
is
enough,
because
we
have
worked
out
typical
coop
example,
and
they
only
request
required
basically,
three
rules.
So
what
we
have
implemented
are
an
unconfirmed
post,
confirm,
post
and
confirm
guest
message,
both
uplink
and
downlink,
and
we
can
do
that
with
three
rules.
But
basically
we
are
very
you
still
a
very
naive
and
in
this
in
this
field
we
have
newcomers.
So
basically
I
would
like
to
understand
if,
from
the
experience
of
the
people,
what
is
the
number
of
what
is
a
minimum
number
of
rules
that
people
are
actually
working
with
it's?
A
A
So
maybe
wait:
okay,
I'm
not
going
to
church
or
head
off.
You
know
just
to
share
a
couple
of
thoughts
and
on
that
point,
I
think
that
it
will
be
good
to
have
a
couple
of
default
rules
that
will
be
used.
You
know
by
by
any
device,
I
mean
that
that
can
that
can
be
applied
to
all
devices
and
and
they're
having
a
limited
set
of
rules
would
be
good
and
then
proudly
use
some
of
these
rules
as
a
some
kind
of
a
prefix
for
extended
rules
that
can
be
used
in
in
future
deployments.
L
A
L
Exactly
so
and
another
question,
there
is
basically
to
simplify
the
implementers
life
and
make
implementation
more
consistent
across
different
platform.
I
think
it
is
good
to
actually
specify
a
common
rule.
So
do
you
think
that,
in
a
technology
specific
document,
it
would
be
a
good
idea
to
say,
for
example,
rule
0
is
reserved
for
fragmentation,
because
actually
in
loja
1,
we
know
we
have
to
implement
fragmentation
in
some
cases,
or
should
we
actually
leave
the
maximum
possible
flexibility?
What
is
the
spirit
anxiety
of
group.
A
So
that's
a
definitely
a
discussion
that
we
would
like
to
happen
on
the
mailing
list.
I
would
feel
that
it
would
be
good
to
have
some
initial
set
of
bootstrap
methods.
That
is,
you
know
that
that
could
be
common
for
all
the
devices
so
that
things
can
start
up.
You
know
it
can
be
something
pretty
basic,
as
you
said,
maybe
zero
is
going
to
be
for
fragmentation
and
then
you
know
people
can
can
start
working
without
you
know
needing
any
complexity.
And
again
can
you.
L
I
L
B
L
L
Nearly
finished,
thank
you
so
still
to
be
done.
We
have
to
describe
loja
one
security
model
Aloha
one.
The
alto
layer
has
a
strong
security
implementation,
but
we
have
to
describe
what
this,
what
security
is
actually
provided
by
loja
one
and
and
to
to
this
chic
layer
describe
specificity,
those
three
device
classes.
L
So,
typically
in
time
of
downlink
latency,
you
cannot
ping
Aloha
one
device
if
it's
not
a
Class,
B
or
Class
C
device,
for
example,
and
I
would
like
also
to
provide
a
detailed
numerical
frame
exchange
examples
in
particular
fragmentation
to
make
sure
Elementary
getting
right.
So
maybe
that
will
be
redundant
with
the
mainsheet
documents.
I
have
to
understand
this.
If
it's
not
redundant,
I
will
provide
technology,
specific
examples
and
last
I'd
like
to
just
orb
our
feedback
on
shake.
We
have
studied
implementing
things.
L
L
Actually,
it's
a
food
for
thought
and
what
I
call
implicit
introduction
and
conclusion
rules
so
rules
that
would
always
be
applied
at
you
know
when
the
new
packet
is
received
or
at
the
end
of
a
new
packet
that,
because
those
rules
with
a
law
actually
using
a
shake
even
on
Nunchuk,
very
simple
legacy
devices,
so
basically
introducing
a
header
in
front
of
a
payload
and
concluding
it
by
some
trailing
stuff,
for
example,
and
also
of
course
it
will
be.
The
provisioning
of
device
and
gateway
is
going
to
be
a
nightmare.
L
F
B
A
L
B
Well,
Nicola
will
will
call
for
adoption,
and
if
it's
chartered
we
can
go
for
adoption,
we
can
do
it.
Do
that
now
and
confirm
on
the
mailing
list
and
then
we'll
ask
you
to
do
some
some
operation
and
document,
because
it
it
officially
becomes
ours
and
not
yours
anymore.
As
long
as
there
is
your
name
on
it,
you
can
write
whatever
you
like
right
as
soon
as
it's
a
workgroup
document,
then
we
need
to
talk
on
the
mailing
list
and.
B
J
M
Thank
you.
Okay,
thanks
so
Juan
Carlos
Antigua
I'm,
going
to
talk
about
the
Sheikh
over,
seek
Fox
draft,
but
I'm
also
going
to
focus
on
on
the
discussion
on
a
corner
or
mould
and
actually
Nowak
as
well.
Next
slide,
please
so
I'm
going
to
be
briefing
on
the
on
the
update
to
the
draft.
Now
we
have
revision
three
again
talking
about
the
network
architecture
equivalences.
M
We
added
for
this
version,
some
rules,
parameters
and
usage,
specifically
talking
about
values
and
timers,
and,
like
the
previous
presentation,
we're
focusing
on
a
byte
oriented,
so
we're
suggesting
having
an
8-bit
header
or
Sheik
header
that
we
think
it's
very
useful
for
for
implementation.
However,
we
saw
that
there
were
some
clarifications
needed
on
the
draft,
specifically
for
the
for
the
Nowak
and
the
akan
error
mode,
and
therefore
the
the
discussion
that
we
had
in
in
the
next
life
that
I'm
going
to
present
so
starting
from
the
north
mode.
Minik
touch
briefly
on
this.
M
1
I've
seen
is
one
bit
for
their
Nowak
mode,
so
basically
we
can
only
send
0,
0
or
n
dents
and
they're
all
one
at
the
very
end,
without
conveying
information
about
in
the
number
of
fragments
that
are
going
to
be
sent
when
there's
no
acknowledgment,
what
we're
proposing
is
to
clarify
or
relax
the
specification
so
that
the
N
higher
than
one
can
clearly
be
allowed
in
this
case.
For
us,
we
see
value
because
we
would
like
to
convey
information
as
we
were
discussing
before
semantically.
M
What
we
saw,
though,
is
that
if
we
allow,
in
the
icon
error
mode
to
keep
track
of
the
last
two
windows,
the
receiver
can
request
retransmission
of
any
lost
packets
and
therefore
come
back
to
sync
and
recover
the
session
from
what
we
saw.
The
probability
of
well
there's
a
little
risk
here,
of
course,
because
we
are
playing
with
the
W
bit
and
if
we,
if
we
move
over
several
windows,
there's
a
probability
of
overlapping
onto
two
windows
past.
M
M
So
basically,
what
we
see
here
is
it:
we
have
a
sender
sending
let's
say
four
fragments
and
the
receiver
either
losing
that
the
last
fragment,
meaning
they
all
0
or
the
the
sender
receiving
the
ACK
from
the
receiver
would
create
a
complete
loss
of
co-op
session.
Why?
Because,
in
our
con
arrow,
we
we
are
not
expecting
the
ACK
if
the
if
the
transmissions
went
through
correctly.
M
So
basically,
the
sender
would
interpret
the
the
lack
of
response
as
if
everything
went
fine
and
it
would
keep
sending
at
this
point,
W,
1
or
window
1,
and
then
the
receiver
would
see
a
window
that
is
not
expected
and
it
would
for
necessarily
abort.
This
is
this
is
a
very
bad
situation
again
because
it
could
be
created
either
from
losing
message
from
left
to
right
or
a
message
from
right
to
left.
M
If
we
move
to
the
next
slide,
please
what
we
are
proposing
here
is
that
we
allow
to
keeping
track
keeping
track
of
the
last
two
to
two
windows,
meaning
we
go
through
the
same
situation.
We
can
get
there
either
from
losing
the
old,
0
or
or
or
the
ACK.
The
first
stack
for
windows
0.
We
then,
if
we
put
ourselves
in
the
sender
position,
we
believe
everything
went
fine,
so
we
we
transmit
the
whole
the
whole
w1
window
at
the
end
of
the
window.
M
We
wait
to
see
if
there's
there's
any
ACK
and
there's
an
ACK,
but
in
fact
that
goes
for
the
for
the
previous
window,
not
the
current
window.
In
this
previous
window,
we
we
can
say
which
were
the
the
the
missing.
In
this
example,
let's
say
it's
all
0
just
for
for
easy
explanation:
weary
transmitted,
the
fragment
all
0
and
we
would
expect
a
chic
AK
for
again
windows,
0,
saying:
okay,
now
we're
fine
with
windows
0.
M
At
this
point,
what
we
can
use
is
the
MTO
0
message
that
Lauren
had
proposed,
which
forces
a
chic
AK
response,
but
we
would
do
it
for
the
current
window
so
that
in
the
next
window
we
are
fine
with
windows
0.
We
force
now
a
second
act,
but
for
window
1,
and
this
this
act
again
could
inform
if
there
were
any
missing
packets.
In
this
example,
just
for
for
simplification,
we
say
there
were
no
missing
packets,
so
we
get
back
to
sync
and
we
move
to
the
to
the
we
resume.
The
normal
operation,
I.
B
Have
two
reactions
here,
depending
on
the
technology,
the
back
window
0
could
be
sent
earlier,
that's
one
because
actually
she
Frances,
we
talked
about
no
hard
and
then
the
first
W
1,
you
can
say
Oh
missing,
like
W
0,
the
other
one
is,
is
I'm
just
thinking
about
Aloha's
finest
tech
machine
and
wondering
if
the
discussion
we
had
during
all
this
meeting
about
not
making
it
no
matter
is
quite
compatible
with
adding
this
to
it
because
it
seems
like
now.
You
would
have
3
dimensions
of
difference
that
machine.
M
A
A
C
F
E
A
A
A
M
I
A
We
saw
we
need
to
move
on
please
so
so
we
continue
with
discussion
and
yes,
one
of
the
things
is.
These
are
changes
that
seem.
Yes,
we
changes,
so
we
need
to
see
if,
yes,
if
we
do
want
to
make
these
changes.
So
what
is
the
reason
to
make
them
right?
It
is
certainly
an
improvement,
but
there
is
a
cost
for
the
center.
There
is
a
cost
for
the
for
the
even
for
for
describing
this,
so
we
need
to
see.
Do
we
really
want
to
do
it.
D
O
Yep
I'm
gonna
talk,
America,
Ramos
and
I'm
gonna
talk
about
marijuana
at
the
Chico
burner,
oh
man,
IOT
and
the
traffic
we
are
writing
about,
and
today
is
mainly
a
little
bit
describing
why
it's
a
little
bit
similar
than
last
session.
Why
it's
a
bit
special
and
also
what
are
the
possibilities
for
continuing
with
the
draft?
So
if
there
is
any
comments
from
the
group
about
this,
I
would
be
happy
to
to
to
get
them.
This
is
a
little
bit
to
remind
you
that
the
nerve,
an
IOT.
Basically
we
have
to
waste
of
transmitting
data.
O
When
is
using
what
you
could
say,
the
control
plane.
So
we
we
have
actually
basically
a
stack
that
that
includes
control
control,
plane
protocols
which
are
RC
and
nos,
and
then
we
have
the
kind
of
the
normal
operation
mode
that
also
that
all
their
mobile
phones
use,
which
is
the
user
plane
where
you
can
see,
basically
the
application
IP
and
then
they
access
stratum
which
is
P
DCP,
are
also
a
Mac
and
the
physical
layer.
O
So
basically
we
could
either
use
it
in
3gpp,
standardized
interface
or
we
can
have
some
kind
of
over-the-top
use
of
Sheik,
which
it
would
be
basically
like
the
same
thing
that
if
would
not
be
IP
traffic,
so
it's
non
IP
traffic
for
the
3gpp
network
perspective
so
from
the
previous
turn
arise.
Interface
I
think,
is
good
that
we
have
to
and
is
because
rock
was
also
standardized
in
her
80s
and
it
was
adopted
by
three
and
then,
if
you,
after
my
analysis,
I
I
thought
that
basically
you
can
replace
it.
O
You
can
take
rock
in
all
the
places
where
it
says
rock
and
you
can
have
an
alternative
which
could
be
chic.
There
is
not
really
very
much
to
be
done
in
the
standard
other
than
that
and
it's
more
about.
Well,
then,
there
is
something
about
the
provisioning
of
parameters
and
so
on,
but
that's
another
thing,
but
basically
from
the
from
functional
perspective.
It's
pretty
much
the
same
thing.
O
So
that's
not
a
problem,
but
I
think
that's
one
way
to
go,
but
it's
not
to
us,
of
course,
at
the
end
of
the
day,
is
up
to
three
beep.
If
they
want
adopted
what
I
have
here
from
feedback
from
people
that
are
working
in
3
PP
in
standardization
of
Nirvana
RT
on
5,
ye
MTC,
so
much
intercommunication
is
that
they
are
really
interested
in
this
and
they
would
like
to
see
if
it's
a
good
standard,
how
to
introduce
it.
So
there
is
an
interest
for
it.
O
What
would
happen
is
that
basically,
there
would
be
two
places
where
there
would
be
chic
entities.
If
that's
the
case,
so
one
place
would
be
the
nos.
Basically
you
could
say
Mme,
but
now
for
for
Nirvana
it
is
the
CSG
N,
which
is
a
note
that
has
many
many
things
and
then
in
the
NASA
in
the
Nast
label
that
you
you
would
have
for
this
kind
of
control
playing
operation.
Then
there
you
could
have
the
chic
compressor
and
the
compressor,
then,
in
the
other
case,
when
you
have
the
actual
connected
mo.
O
So
basically
the
difference
between
these
two
is
having
one.
You
have
security.
The
security
has
been
established
in
the
access
stratum
in
sorry
in
one
it
happened
being
establishes
in
the
other.
One
has
been
established
and
then
then
the
compression
change
to
be
done
in
PD
CP,
instead
of
be
done
in
a
so
then
this
has
to
be
considered
as
well.
So
how
we
do
this
change
so
does
it
work
straight
away?
So
if
you
have
context
from
Nass,
then
can
you
reuse
them
in
PD?
Cps
is
totally
different
set
of
rules
and
so
on.
O
Over
the
top,
basically
so
the
application
layer-
and
it
would
means
that
you
don't
require
to
EBP
standardization.
Anyone
can
use
it,
and
even
if
we
have
three
BP
standardization
still,
you
could
use
it.
So
it
doesn't
preclude
that
that
you
can
have
both
and
but
then
they
are
the
only.
The
only
trick
of
this
is
that
well,
it
will
be
treated
as
non
IP
traffic
by
three
EPP,
and
then
there
are
two
ways
of
handling
non
IP
traffic.
O
I
will
show
a
little
bit
about
that
in
the
next
slide,
but
then
the
main
consequence
is
that
intermediate
hopes
cannot
directly
understand
those
compress
headers.
So
it
means
that
if
you
want
to
do
something
on
appeal
ayres
before
the
packet
reached
the
terminal,
then
that
is
not
possible.
Unless
there
is
some
mechanism
to
get
access
to
their
to
the
context.
O
O
Could
be
yeah?
That's
a
good
point
is
something
to
check
actually
but
well.
These
are
the
two
options.
Basically,
so
one
option
is
that
goes
over
a
tunnel
and
then
how
the
tunnel
is
done
and
is
implemented
and
what
protocol
seats
are
used,
that
that
is
pretty
much
up
to
the
operator.
It
could
be
even
TCP
it'd
be
use
to
do
the
transport.
O
B
O
Yeah,
that's
my
last
night,
so
that
is
basically
the
options
and
well
then,
basically,
this
is
the
type
of
feedback.
I
was
expecting,
so
we
we
expect
now
to
work
with
this
and
then
half
I
think
we
are
going
to
improve
the
document.
Unfortunately,
we
miss
the
deadline
for
the
document
for
this
session,
but
we
have
actually
in
github
a
newer
version.
Yeah.
A
Okay,
Charlie
a
couple
of
minutes,
so
you'll
have
three
minutes
to
finish
your
site,
but
I
would
like
to
thank
you
very
much.
Thank
you
very
much.
Edgar
I
am
reading
very,
very
happy
with
the
progress
I
see
on
the
MDI
ot
site,
and
it's
really
also
this
positive
feedback
that
you
see
that
you
give
us
it's
also
very,
very
promising
to
see
that
the
technology
is
actually
going
to
get
used.
So
thank
you
and
Charlie.
We
are
going
to
give
us
the
pleasure
causing
the
session.
A
F
You
hear
me
I'm
Charlie
Perkins,
and
this
is
a
very
short
presentation.
We
made
a
draft
and
put
it
out
earlier
this
week,
so
I
don't
expect
anybody
much
chance
to
look
at
it
and,
besides
that,
it's
a
quite
simple
draft,
just
not
really
complete,
but
it
leads
it's
a
start
and
if
you
take
a
look
at
it,
your
comments
will
be
appreciated.
F
So
I'm
here,
basically
to
tell
you
about:
what's
going
on
in
802
dot,
15.4
W,
which
is
the
ITER
215
task
group,
that's
dealing
with
low-power
wide-area
things
they.
They
are
chartered
to
basically
extend
the
some
of
the
file
layer
parameters
to
deal
with
a
wider
set
of
use
cases
which
have
been
extensively
discussed
during
the
interest
group
and
study
group
formation.
So
now
we
have
the
task
group
that
has
the
Charter
basically
to
produce
revisions
to
later
throughout
15.4
for
the
purposes
of
a
low-power
wide
area.
F
Now
this
shook
for
a
282
15.4
W
is
not
an
official
on
Tripoli
contribution,
but
it's
done
by
people
and
attitude
on
15.4,
W
and
so
I'm,
not
exactly
sure
how
the
authorship
would
be
represented,
but
it
won't
be
an
official
thing.
However,
I
think
laterally
attitude
at
802
and
I
ITF,
Coordination
Committee
will
know
about
it.
F
Okay,
so,
like
the
document
is
relatively
short,
just
a
goes
through,
but
there
was
a
nice
C.
This
mailing
list
think
from
from
honor,
said
about
how
you
go
about
specifying
the
parameters
in
such
a
document.
Is
this
so
we
basically
followed
those
recommendations.
We
think
that
the
size
of
the
ruled
ID
should
be
three
with
a
tour
through
dot
15.
F
On
the
other
hand,
it
needs
to
be
considered
whether
this
the
shipwreck,
fragmentation
is
better
than
ADA
doc
15.4,
because
it's
specialized
to
a
single
hub,
and
that
has
not
been
done
yet
and
I
will
definitely
urge
people
in
the
4w2
to
analyze.
That,
aside
from
that,
just
since
I
am
up
here,
I'll
tell
you
that
we've
made
good
progress
in
4w
that,
as
I
mentioned,
that
was
chartered
to
produce
some
new
file
layer
parameters.
And
this
is
not
my
strength.
F
I
know
sort
of
what
a
convolutional
code
is,
but
I
don't
know
how
to
design
them,
and
so,
but
we
had
six
proposals
and
I
had
to
say
that
they
are
really
quite
creative.
So
I
think
that
it's
going
to
be
a
good
while
before
we
go
through
all
of
this
and
probably
next
year,
we'll
have
a
either
a
combined
candidate
or
something
that
has
supported
the
working
group
to
go
forward,
because
we
know
this
timely
work.
So
I
think
that's
my
last
slide
and.
F
A
You
very
much
charlie.
We
are
only
two
minutes
past
the
hour,
which
is
really
exceptional
work
from
everyone.
Thank
you
very
much
and
thank
you
for
submitting
the
draft.
We're
really
happy
to
have
also
that
802,
the
15.4
draft,
so
right
now
we're
on
good
track
with
all
this.
So
that's
the
end
of
the
group
have
a
good
afternoon
or
evening
or
night
wherever
you
are.
Thank
you.