►
From YouTube: IETF110-LPWAN-20210310-1430
Description
LPWAN meeting session at IETF110
2021/03/10 1430
https://datatracker.ietf.org/meeting/110/proceedings/
B
A
A
C
C
C
C
C
A
E
C
A
A
A
So
this
means
that
by
participating
in
the
in
the
itf,
you
agree
to
the
to
follow
the
itf
processes
and
policies,
and
if
you
are
so
all
the
policies
that
of
course
apply
for
ipr
for
for
a
good
behavior,
you
know
code
of
contact,
copyright
patent
participation.
All
of
that
the
bcps
you
should
be
them.
So
no,
it's
and
yes,
just
a
short
reminder.
So,
let's
are
taken.
This
meeting
is
recorded
and
the
pres
your
presence
is
logged.
So
the
minutes
are
taken.
A
I'd
like
to
take
time
just
to
to
thank
our
official
scribes,
laurent,
dominique
bartel
and
carles
gomez.
Who
will
be
taking
the
minutes,
but
please
join
the
code
dmd
and
do
take
the
notes
with
them,
because
you
know
it's
not
all
the
the
weight
should
be
falling
on
them
and
I
hand
the
word
to
you.
Pascal.
C
A
C
So
yeah,
I
just
shared
the
kodi
and
the
link
which
is
which
is
there.
As
alex
said,
we
we
have
laura
taking
the
minutes
for
us
and,
yes,
we
already
uploaded
the
meeting
material
on
the
lp1
session.
So
if
you
want
to
follow
it
from
from
the
agenda
the
atf
agenda,
you
will
find
it
agenda
for
today.
So
we'll
start
with
alexander
presenting
the
lp-1
architecture,
which
is
a
new
draft,
but
that
still
needs
quite
some
work
and-
and
we
hope
we
have
time
soon
to
to
improve
it.
C
Then
anna
will
have
a
little
time
to
tell
us
the
latest
and
greatest
news
about
the
progress
of
the
co-op
static
context
for
which
anna
and
eric
we
have
to.
Thank
you
so
much,
and
I
will
have
a
few
minutes
to
present
you
the
shake
of
our
ppp
work,
which
is
actually
happening
at
the
interior
working
group
and
not
here
and
then
iob.
If
anything
else
needs
to
be
discussed
so
between
last
eight
cf,
and
now
we
had
a
number
of
interims
and
we
actually
updated
our
milestones
and
agreed
with
eric.
C
C
C
So
that
that's
why
you
see
this,
this
review
statement
about
the
young
doctors,
and
so,
as
you
can
see,
there
are
two
documents
which
are
sitting
there
and
waiting
for
adoption,
the
very
new
lp1
architecture
that
that
alexander
has
mostly
edited
for
now
and
dominic's
oem
document,
which
would
deserve
some
more
new
work.
As
soon
as
you
can
dominic
you're
welcome
to
show
us
what's
happening
there
and
with
this
alexander
I
will
leave
you
the
presentation
and
please
thank.
F
A
Yes,
please
so,
yes,
everyone!
This
is,
of
course,
we've
been
waiting
for
for
a
couple
of
years
now,
but
right
now,
we've
had
a
couple
of
major
main
milestones
that
we
closed
and
we're
opening
a
new
new
fields
that
you
know
in
this
architectural
work
really
shows,
and
the
goal
is
to
show
how
all
these
bits
and
pieces
work
together.
So
we
wanted.
A
The
first
thing
to
do
is
to
just
do
a
short
recap
of
you
know
what
the
lp
ones
are
and
how
how
we
are
aiming
at
them.
So
we
actually
look
some
slides
that
we
use
from
the
very
first
buff
that
we
had
so
low
power
power,
wide
area
networks,
so
click
pascal
or
the
canine.
Yes,
so
low
power.
These
are
things
that
are
designed
to
be
working
many
many
years,
20
years
considerable
battery.
A
So
I
click
wide
area.
I
cannot
click
next
next
slide,
please
so
right
there,
it's
not
able
to
communicate
over
very,
very
long
distances
and
next
slide
here
is
actually
the
really
interesting
part.
You
know
star
topology,
huge
densities,
and
we
have
case
where
the
communication
is
device
initiated
with
strongly
asymmetric
links
where
the
uplinks
are
much
cheaper
than
the
downlinks
and
the
throughput
is
very,
very,
very
low
right
and
all
that
combined
and
on
the
next
slide.
Please
all
that
combined.
A
You
know
we
can
have
operation
in
license
free
or
in
license
spectrum
and
and
there
we
have
a
bunch
of
other
questions.
You
know
how
to
handle
about.
You
know
duties
like
cycling,
collisions
and,
and,
and
you
know,
the
mode
of
operation,
so
basically
what
we
are,
what
we
tried.
What
we
done
in
this
working
group
until
now
is
really
to
to
focus
on
all
these
different
and
the
next
slide.
Please,
on
all
these
different
constraints
and
different
considerations.
C
A
A
You
can
find
in
all
types
of
networks
from,
on
the
left
hand,
side.
We
have
devices
that
communicate
over
the
application
of
the
long
distance
to
the
rail
gateways.
Then
the
radiators
are
connected
to
an
element
that
is
called
the
network
gateway.
That
does
the
interconnection
between
the
the
radio
and
the
application
behind,
and
that
also
does
the
the
authentication
of
the
devices
and
this
part
of
the
of
the
security.
A
So
next
slide,
please
that
will
be
17.
yes,
so
this
is
where
we
also
took
the
this
huge
opportunity
to
actually
be
working
with
the
four
major
lp1
technologies,
and
we
did
this
that
that's
really
one
of
the
one
of
the
first
major
rf
documents
that
combines
all
these
technologies.
Rfc,
83
76
and
I'd
really
like
to
to
thank
the
authors
of
the
draft
that
it's
really
showing
you
know.
A
They
took
really
the
time
to
align
the
the
terminology
and
we
decided
you
know
we
need
to
have
the
ihf
terminology.
So
we
have
this
table
like
the
device
in
the
itf
course
and
and
the
corresponding
to
terminology
in
lure
one
and
and
and
in
the
different
in
the
different.
Yes
and
the
different
technologies,
so
what's
the
so
that's
you
know
the
overview
of
the
of
the
work
done
until
now.
What
the
chic
architecture
document
is
doing
is
providing
a
reference
architecture
of
how
the
different
systems
are
working
together.
A
So
for
until
now,
we
have
identified
two
modes
of
operation.
The
the
first
one
is
in
the
classical
chic
device
in
gateway
mode,
where
we
have
the
device
and
the
gateway
working
together,
and
we
also
identified
a
mode
that
we
can
call
the
shake
peer
mode
where
we
have
peers,
shake
peer
peer
devices
or
shake
pure
gateways
talking
to
each
other.
A
So
the
architecture
also
you
know
shows-
and
the
goal
is
to
show
how
to
the
data
model
is
used
and
how
the
device
and
and
how
the
the
rules
are
created
and
updated
and
how
they
are
installed
and
discovered.
Next
slide,
please
1919!
Yes!
So
what
we
have
is,
of
course,
the
end
device
that
needs
to
talk
to
the
network
application
next
slide.
A
The
network
application
is
residing
on
application
server
next
slide.
So
we
have
the
radio
gateways
that
are
around
the
device.
Then
we
have
the
network
gateway
that
you
know
it's
connecting
to
to
this
radio
gateways
and
then
what
we
have
is
like
the
the
full
view,
with
the
element
that
we
call
here,
the
sheet
gateway.
So
we
have
the
sheet
device
and
the
sheet
gateway
that
you
know
so
that
that
corresponds
to
the
to
the
architecture
of
how
the
system
is
working
next
site.
A
Yes,
so,
and
we
have
ip
communication
like
ipdp
code,
but
it
can
be
any
network
protocol
communication
between
the
sheet
device
and
the
application
next
slide.
Please
now,
when
we
zoom
in
in
the
sheet
gateway,
we
have
identified
that
there
are
like
three
functional
blocks:
there.
We
have
the
rule,
monitor
manager,
the
rules
and
the
chic
compression
the
compressor,
the
compressor
and
fragmenter
a
recombiner.
A
So
the
way
the
the
way
the
rules
are
represented
is
by
following
the
yang
data
model
right.
So
that's
when
we
are
talking
about
the
the
chic
device
and
the
sheet
gateway
and
the
same
thing
goes
for
chic
peer
mode
of
operation,
so
these
are
actually
quite
metric
and
we
think
that
in
most
cases
these
will
be
there
will
be
a
lot
of
overlapping
functionality.
It's
just
that.
A
You
know
we'd
like
to
keep
for
a
moment
this
separation,
because
because
the
device
and
she
gateway-
I
mean
there-
is
this
notion
that
you
know
the
chic
device
is
much
less
powerful
than
the
gateway,
for
example,
whereas
in
chic
peer
mode
of
operation
that
could
be
between
two
gateways
and
both
can
be
really
full-fledged,
and
so
here
we
have
this
operation
where
and
yes.
So
what?
A
You
know
so
through
core
coffee
or
score,
but
they
can
actually
be
communicating
through
the
ip
stack
through
the
through
the
ep
stack
and
going
through
the
the
shake
compressing,
the
compressor
and
fragmenter
recombiner,
and
so
the
two
rule
managers
are
communicating
to
each
other.
The
room
manager,
one.
A
On
the
other
hand,
they
can
push
to
other
place
to
to
fetch
the
parts
of
the
rules
and
so
really
they're.
The
build
blocks
of
this
architecture
allows
the
fifth
start
from
the
bootstrap
to
discovery.
To
you
know
the
operation
of
two
chic
levels:
things
if
you
wish
check
device
fit
between
or
shake
peers.
C
Okay,
alex
thanks
so
much
you
are
breaking
up
a
little
bit,
but
I
hope
that
people
could
actually
hear
yeah.
So,
as
eric
says
on
on
the
chat
as
well,
yes,
there
was
the
audio
was
not
perfect,
but
on
my
side
I
could
get
most
of
what
you
were
saying.
I
mean
don't
worry
too
much
and
then
the
next
speaker
will
be
lauren
about
the
young
data
model.
G
G
G
G
We
have
all
the
four
matching
operators
of
eight
compression
decompression
action
and
that's
for
the
compression
and
for
the
fragmentation.
We
have
the
rcs
algorithm,
as
we
saw
in
the
example
and
right
now
we
have
only
one
single
value.
We
have
the
fragmentation
mode.
We
have
on
some
parameter
also
for
icon
error.
Next
slide.
G
So
here
is
an
example
shake
so
I
saw
chic
is
okay,
so
here
we
have
the
identity.
So
here
is
an
example.
Next
slide-
and
here
is
another
example,
including
co-op
options
and
all
that
stuff.
So
it
can
look
long.
Then,
of
course
we
will
not.
We
cannot
send
that
on
the
neon
constraint
network,
so
we
will
have
to
use
qualcomm,
for
example,
to
have
a
value
instead
of
this
long,
ascii
string.
G
Okay,
next
slide
for
the
structure,
so
the
structure
are
quite
common
to
what
we
see
in
the
rfc.
So
we
have
a
rule.
So
rule
is
a
a
chic
set
of
rule
is
a
list
of
rules.
Each
rule
is
identified
by
a
rule
id
and
a
rule
length,
and
then
we
associate
two
of
these
keys
either
a
fragmentation
rule
or
a
compression
rule
that
we
will
see
after
so
for
the
fragmentation
world.
G
We
have
a
part
that
defines
the
chic
header,
so
the
secular
will
start
with
the
tag
window,
size
and
sorry
the
tag
window
on
the
fcn,
and
here
we
indicate
the
size
of
these
of
these
fields.
We
have
the
rcs
algorithm
and
then
we
have
parameters
that
are
used
by
the
state
machine
and
that
are
defined
in
the
annex
of
8724
and
for
icon.
Sorry,
can
you
go
back
and
for
icon
error.
G
We
have
also
some
operation
mode,
mod
tides
in
all
one
or
add
behavior-
that
can
be
defined
for
the
compression
next
slide.
So
a
compression
rule
is
a
list
of
entry.
An
entry
is
identified
by
a
field,
id
a
field
position
and
a
direction
id
indicator,
and
here
you
will,
and
after
that
you
have
the
list
of
all
the
fields
that
you
find
in
ascii
table
in
rfc8724.
G
G
C
D
B
A
A
So
launching
and
working
with
classical
seems
like
a
good
idea
in
the
sense
that
then,
of
course,
we'll
need
to
put
in
copy
networks,
probably
and
and
and
you
know
that
will
put
people
also
in
the
in
the
in
the
sense
that
hey
well,
you
know
we
considered
it
was
done,
and
you
know
if
there
are
any
reviews.
Now
is
the
time
to
do
that.
So.
C
There
are
basically
two
things
in
in
a
document
like
this
right
there
there
is,
do
you
have
all
the
content,
and
for
that
there
is
nothing
better
than
an
implementation.
We
have
a
number
of
implementations,
so
we
can
actually
check
the
content
and
the
content
was
written
based
on
those
implementations,
so
we're
pretty
safe
there,
and
the
second
thing
is,
I
would
say,
the
yankness
of
the
document
I
mean.
C
E
C
But,
like
you
I'm
up
here
with
the
document
assist
if
it
was
not
for
the
young
doctors,
I
would
be
launching
the
one
for
classical
okay.
It's
you
have
you
have
two
more
minutes
than
scheduled
one
colors.
So
the
ball
is
yours.
Do
you
want
to
share
the
your
presentation,
or
should
I
push
the
slides,
as
I
did
so
far.
F
If
you
can
push
this
light,
pascal,
probably
so
that
we
can
keep
going
so
thank
you
very
much
everyone
juan
carlos
suniga
here
and
presenting
an
update
on
the
she
cover
sick
fox,
as
well
as
the
taichik
hardcore
code.
So
we've
been
working
again
on
the
offline
coding
with
help
from
the
university
of
chile
and
university
of
catalonia
for
the
icon,
error
and
noac
parameter
optimizations.
F
We
this
time
were
focusing
on
error
conditions
that
have
been
tested
for
the
last
updates.
We
added
a
long
list
of
message:
sequence,
examples
that
explain
the
different
icon
error
and
no
ack
and
chic
error
scenarios
that
we've
been
testing
and,
very
importantly,
we
have
also
updated
the
the
co-authors
list
because
of
the
strong
contributions
from
work.
F
We
have
now
welcomed
the
sergio
diego
and
sandra
onto
the
authors
list.
So
thank
you
very
much
for
the
help
and
out
of
that.
In
fact,
we
have
also
been
working
on
compound
chicago
message
proposal
with
the
intent
to
save
on
the
on
the
protocol
overhead
number
of
acknowledgement
messages
on
different
situations,
but
still
keeping
the
flexibility
of
the
noack
mode
where
we
can
send
opportunistic
acts
over
a
session.
H
Now
my
name
is
serge
aguilar,
I'm
from
upc,
and
I
will
be
presenting
to
you
the
proposal
regarding
the
compound
act
message
in
account
error
over
sig
fox
when
cheek
fragment
losses
are
present
in
intermediate
windows.
At
least
one
act
is
generated
when
the
cheek
fragment
losses
are
presented.
In
the
last
window,
at
least
two
acts
may
be
generated
and
independently
on
the
cheek
size,
the
sigfox
down,
downlink
payload
size
is
fixed
to
64
bits.
H
Therefore,
when
errors
occurs
over
multiple
windows,
the
number
of
facts
can
be
reduced
by
reporting
losses
of
several
windows
in
a
single
lakh.
Here
we
have
an
example
of
a
14
tiles,
chick
packet
with
with
a
window
size
of
seven
tiles
and
errors
over
multiple
windows.
In
this
case,
we
have
three
act
messages.
H
H
H
H
H
H
In
this
case,
we
can
see
the
example
of
the
compound
knack
of
the
14
tile
sheet
packet
transmission
we
saw
before.
Can
we
go
to
the
next
slide?
Please
other
details
about
the
compound
act
is
that
the
window
number
plus
bitmap
groups,
order
from
the
smallest
window
to
the
largest
and
if
the
window
number
zero
has
error
in
this
case
is
present
in
the
india,
it
must
always
be
between
the
rule
id
and
the
save
it.
To
avoid
confusion
with
the
zero
padding
bits.
H
There
is
also
in
the
presentation
another
another
example
of
a
28
cheek
packet
size
with
also
error,
distributed
in
all
windows,
where
we
use
the
where
you
can
see,
also
the
ag
reduction
and
using
while
using
the
message
the
compound
message,
format
next
slide.
Please
thank
you
very
much
for
your
time,
any
questions
or.
B
B
B
H
F
Okay,
got
it
right,
yeah,
indeed
dominique
just
to
add
that
this
is
let's
make.
It
makes
it
more
predictive,
because
we
know
exactly
how
many
bitmaps
we
can
always
fit,
and
and
also
because
they
can
be
discontinuous
discontinuous.
The
this
gives
us
some
clarity
on
the
on
the
format
adding
the
window
bits
in
the
beginning
of
the
of
the
bitmap.
G
H
F
C
C
G
C
Okay,
as
presented,
it
looks
very,
very
opportunistic
to
the
sigfox
case,
so
I
don't
see
that
we
need
to
define
it
elsewhere
and
if,
if
another
rfc
wants
to
know,
if
I
don't
know
nba
ut,
but
it
won't
need
this.
But
if
another
rs
in
the
future
needs
this,
it
can
always
take
inspiration,
but
probably
they
will.
They
will
tune
it
slightly
differently.
So
I
would
not
make
too
creative
thoughts
to
try
to
generalize
it.
A
F
So
I
I
you
cut
alex,
but
I
think
hearing
hearing
the
inputs
here.
Maybe
what
we
can
do
from
our
side
is
to
to
make
sure
that
we
document
correctly
the
principles,
the
advantages
and
then
that
with
ability
to
seek
help
so
that,
if
ever
other
technologies
want
to
inherit
or
point
to
the
same
principles
and
advantages,
they
can
do
so
without
necessarily
going
to
the
specifics
of
sql.
F
C
C
You
don't
want
the
links
and
you
want
to
compress
them
into
one
message
I
mean
all
this
is
is
sick
folks,
but
it's
nice.
I
mean
you,
you
re-optimize,
that's
why
we
wanted
to
have
those
technology
drafts
right
to
optimize
for
each
given
case,
but
how
do
we
know
that
the
next
case
will
need
exactly
that
or
would
do
its
own
slide
variation?
C
So
now
it's
yes,
you
said
you
make
it
public.
You
explain
how
it
works
and
if
ever
another
technology
needs
something
like
that
similar,
but
maybe
their
own
version
of
it,
they
will
define
it
as
well.
Very
happy
with
this
spending
time
on
trying
to
generalize
this
now.
It
looks
like
overkill
to
me.
Okay,.
F
B
Yeah,
I
would
just
recommend
sorry,
I
didn't
have
time
to
read
the
new
version
of
the
draft
on
this,
but
I
would
just
recommend
that
you
make
it
very
explicit
how
an
implementation
can
distinguish
between
the
the
regular
arc
message
and
the
new
one
and
what
are
the
criteria
and,
of
course,
it's
probably
simpler
than
in
the
general
case
of
8724,
because
you
have
a
bright
alignment
and
we
spend
quite
a
lot
of
time
describing
all
this.
How
ambiguity
is
avoided.
So
I'm
just
hoping
this
will
be
the
same
level
of
description
in
this
draft.
F
Thank
you.
Yes,
thanks
by
the
way
just
to
to
add
on
that.
Thanks
for
the
input
and
we
wanted
to
first
show
the
concept
and
get
feedback,
so
we
have
not
documented
in
the
latest
version
of
the
draft.
Yet
this
this
proposal,
we
wanted
to
first
hear
the
feedback,
so
our
plans
are
now
to
take
all
this
comments
and
information
feedback,
etc
that
you
have
given
us
to
to
make
a
new
version
of
the
drafting
and
then
include
the
details,
but
but
yeah
dominique
to
you.
B
C
B
C
Yes,
to
understand
exactly
the
games
of
the
zeros
and
ambiguity
and
avoiding
ambiguity,
that's
one
of
the
most
tricky
things
in
shake
this,
this
all
zero
arc.
So
having
slides,
which
explain
exactly
how
it
works,
that's
very
useful.
I
thought
you
you
presented
something
like
that
at
180f,
but
okay,
okay,.
C
C
C
So
yes,
please,
let's,
let's
build
this,
the
slides
for
an
intro,
where
we
explain
exactly
how
we
do
the
ambiguity,
how
we
resolve
the
ambiguity
today
and
how
that
that
is
done
in
six
folks
and
make
sure
there
is
no
room
for
any
ambiguity.
Okay,
so
next
will
be
anna.
You
have
five
minutes
and
now
on
the
club
static.
E
E
So
this
is
a
new
part
and
then
for
we
send
it
for
revision
in
version
17
and
18.
I
put
it
together
because
there's
not
so
much
differences,
because
when
I
published
version
17
I
saw
that
I
forgot
an
a
comment
from
benjamin,
so
I
published
version
18
with
this
new
comment
for
the
big
big
big
difference
is
the
section
of
co-op
options
for
variable
land
fields
and
the
security
section
again
and
the
last
not
the
least,
but
as
soon
as
benjamin
verifies
the
version
18
he
accepted,
and
he
give
us
a
present.
E
C
D
E
C
E
C
C
C
This
is
actually
a
document
which
is
being
followed
at
the
interior
working
group,
but
for
which
we
really
need
help
from
the
the
lp1
working
group,
because
it's
dealing
with
shake
and
how
to
use
shake
for
at
least
some
part,
and
it's
not
the
expertise
that
we
can
expect
from
interior,
and
we
really
expect
that
it
expertise
to
be
coming
from
this
group.
So
I
will
keep
keeping
the
group
aware
of
everything
that
happens
on
this
document.
C
So
for
now
it's
chicago
ppp.
But
as
you
know,
we
did
it
because
once
you
have
ppp,
you
are
full
because
ppp
was
initially
designed
for
serial
lines.
But
then
there
is
pppoe
for
how
you
do
ppp
over
point-to-point
ethernet,
even
across
the
switch
fabric,
and
then
once
you
have
ethernet,
you
have
wi-fi,
so
you
can
basically
apply
shake
to
to
a
number
of
technologies
as
soon
as
you
do
shake
over
ppp,
as
alexander
mentioned
in
the
architecture
document.
C
C
What
we
do
in
this
draft
is
we
signal
in
existing
ppp
signaling,
a
new
compression.
There
is
already
a
way
in
ppp
to
signal
which
compression
you're
going
to
use.
You
can
use
from
jacobson,
for
instance,
here
we're
going
to
use
check.
So
we
just
added
in
a
new
a
new
compression,
and
I
guess
the
value
was
2,
meaning
check.
C
Now,
when
you
signal
the
compression
in
in
an
option
of
ppp,
when
you
set
up
the
the
call,
you
can
also
signal
some
parameter
and
the
only
parameter
that
we
signal
here
is
actually
a
url,
where
we
expect
that
the
data
model
based
on
the
young
document
that
that
the
laura
has
just
explained
would
be
located.
So
the
idea
here
is
compared
to
the
normal
old
version,
where
you
ship,
a
chic
device
with
hard-coded
rules
that
may
even
you
know,
always
use
the
compressed
format
and
never
really
operate
in
the
uncompressed
format.
C
So
for
this
effectively
we
have
a
dependency
on
the
chic
document,
so
I
just
placed
here
the
shape
of
a
packet
as
it
would
be
if
the
document
is
implemented,
as
is
right
now,
so
you
can
see
that
the
rule
id
occupies
the
first
two
bytes
aft
after
the
the
ppp
protocol,
signaling
ipv6,
and
so
the
compressed
p
is
the
what
we
call
the
residue
occupies
something
and
the
alignment
is
in.
The
draft
is
done
at
some.
C
You
know
to
align
to
one
byte
at
the
end
of
the
compression
residue,
but
the
expectation
is
that
there
will
be
some
content
in
the
packet
which
will
not
be
compressed.
So
we
we
have
this
extra
thing
that
does
not
appear
and
check
with
the
uncompressed
payload
from
the
original.
So
we
we,
we
expect
to
compress
up
to
some
place,
do
the
padding
there
and
then
add
some
more
bites
all
the
way
to
the
end
of
the
packet.
C
So
it's
not
exactly
matching
what
you
may
expect
from
from
the
chic
document,
but
the
question
is:
is
it
against
the
rule
or
is
it
acceptable
and
it's
back
to
to
the
same
discussion
as
sick
fox
right?
If,
if
that's
how
we
do
it
in
this
environment?
Well,
worst
cases,
we
can
say
that
this
document
updates
at
87.24,
but
I'm
still
not
clear
if
it's
legal
with
8724
not
to
do
it
this
way.
C
So
the
document
is
pretty
old.
I
need
to
refresh
it
by
the
end
of
this
month,
so
the
other
rules-
I
don't
have
much
time
so
I
won't
go
through
these
details.
They
were
presented
at
the
interim.
Basically,
that's
we,
we
now
have
compression
for
the
rules
and
we
do
a
fragmentation
and
the
reason
for
doing
fragmentation
is,
if
you
want
to
use
a
deterministic
network
which
operates
really
really
fast,
and
you
want
to
be
able
to
schedule
it.
C
There
is
not
any
of
the
endpoints
which
we
charge
the
compression
rule,
which
is
what
I
was
saying,
and
we
guarantee
that
they
they
have
the
same
state,
because
both
will
fetch
it
from
the
same
place
and
that's
pretty
much
it.
I
don't
have
much
time
to
go
through
this
flow.
The
real
question
for
today
is
first
thing:
I'm
a
bit
alone
on
this.
One
is
there
somebody
who's
willing
to
work
with
me
on
this,
so
feel,
free
to
raise
hands
now
or
contact
me
on
email.
C
C
G
G
C
Oh
basically,
I
also
answered
you
maybe
to
nobody
that
this
is
an
option
to
have
some
uncompressed
data
at
the
end
of
the
packet.
Now,
if
you
want
to
fragment-
probably
you
would
not
be
doing
this,
but
it's
it's
an
additional
capability
that
I
have,
if
you,
if
you're,
not
doing
compression
so
yes,
maybe
we
can
explain
that.
That's.
That
would
be
a
good
thing
to
explain,
but
you
don't
have
to
put
uncompressed
data
after
after
the
padding
you
you
may.
C
D
D
Yes,
go
ahead,
just
want
to
enforce,
and
second
your
comment
about
this
working
group
following
the
discussion
on
the
interarrier
working
group,
you
know
that
subscribing
to
a
milling
list
is
easy
and
the
interior
is
on
friday.
So
please
go
review
and
have
pascal
as
a
co-author
on
this
draft.
That's
very
important.
C
So
if
you
think
about
extensions,
if
you
want
to
contribute
with
me
on
this
draft,
if
you
have
ideas
about
the
applicability
statement
and
and
things
that
I
may
have
missed
about,
where
it
can
work,
why
cannot
work
and
everything
is
welcome
on
the
mailing
list.
Please
come
back
to
me
on
anything
like
that
and
with
this
we
we
are
getting
to
the
end
of
this
meeting,
so
we
have
just
a
minute
or
two
if
there
is
any
aob.