►
From YouTube: LPWAN WG Interim Meeting, 2020-04-21
Description
LPWAN WG Interim Meeting, 2020-04-21
B
A
B
B
B
B
B
B
So
if
you
get
aware
of
any
of
these,
please
come
to,
you
know,
say
to
the
mailing
list
or
come
to
the
chairs
after
the
meeting,
and
yes,
you
need
also
to
obey
to
the
code
of
conduct
and
anti-harassment
procedures
and
all
the
good
recipes
that
are
listed
out
here.
So
please
read
them
in
detail
if
you
have
not
done
so
yet,
but
you
are
any
any
in
any
case
you're
bound
by
them.
D
B
B
Okay,
thank
you
olivia.
Thank
you.
It's
really
appreciated.
So,
yes,
the
presence
is
locked,
we'll
be
keeping
a
a
blue
sheet
that
will
be
recorded
and
the
the
whole
session
is
recorded.
So
please
take
note
of
this,
so
I
will
be
the
jabber
scribe
for
this
session.
In
case
you
need
to
to
say
anything
I'll
be
on
the
jabber
also
for
for
and
yes
I'm
that's
that's
on
the
reminder
and
I'm
giving
the
the
the
the
head
the
hand
over
to
my.
A
Co-Chair
thank
you
alex,
so
we've
got
a
longer
wrench
on
that
than
usual,
because
it's
not
just
a
virtual
entry
mess.
We
do
every
other
week,
but
it
is
actually
the
replacement
for
the
atf-107.
As
we
said
so
we'll
we
have
two
pages
of
agenda
we'll
go
through
the
usual
ash
on
the
bashing
work
of
status.
Alex
will
tell
us
about
the
next
entrance
at
the
new
charter,
we'll
have
a
status
of
the
draft
and
then
we'll
we'll
go
through
the
two
different
drafts.
So
first
will
be
the
data
model.
A
Okay,
so
I
speak
louder
as
well,
so
we
will
go
through
the
technologies
follower,
one
and
six
fox
and
then
we'll
discuss
the
case
of
ppp.
We
already
discussed
that
at
interim,
but
I
want
to
confirm
on
this
group
and
then
dominic
will
tell
us
about
the
remote
hackathon,
which
replaces
the
architecture
that
should
have
taken
place
at
the
itf
dominic
and
the
oam
we
get
from
far
olivier
on
multicast.
A
A
I'm
hearing
nothing,
so
I
guess
the
agenda
was
just
bashed
and
if
it
could
scroll
pages,
that
would
be
even
better
okay.
So,
as
I
presented
at
the
last
interim,
we
have
negotiated
actually
with
surash
the
the
milestones
for
the
working
group.
You'll
find
that
we
have
a
single
milestone
for
all
the
technology
documents
and
probably
we'll
split
them
as
we
go.
We
we
have
a
hope
that
very
soon
and
we'll
discuss
that
today
we
can
go
for
worker
plus
call
for
the
lord
document.
B
Yes,
yes,
so
thanks
thanks
a
lot
context
for
everyone.
So,
after
four
years,
three
years,
four
years
of
work,
we
actually
delivered
everything
that
we
initially
set
for,
and
we
got
to
our
new
chapter
charter
2.0
new
and
improved.
So
basically,
as
we
said
from
the
last
time,
we
have
the
I
do.
The
we
have
expanded
the
charter
items
that
we
had
before.
B
So,
first
of
all,
it's
perform
sheet
maintenance
and
that
will
include
enabling
sheet
mechanisms
for
parallel
protocols
produce
the
standard
track
documents
for
chic
over
foo,
cheap,
ipv6
udp
over
full,
and
here
we
have
at
least
two
or
three
documents
that
will
be
presented
today.
On
that
four.
In
this
charter
item
we
have
the
document
for
generic
data
models
for
the
context.
That
will
be
really.
B
So
in
all
of
these
four
points
we,
when
we
have
work
so
behind
each
of
these
work,
points
and
work
items,
we
have,
we
have
actually
actual
documents
and
we
have
teams
that
have
already
started
working
and
that
have
advanced
really
well
in
the
world.
So
that's
really
great,
and
this
is
really
the
way
that
we
would
like
to
see.
B
So
that's
the
point
with
multicast,
we
had
an
item
on
multicast
that
we
had
that
was
initially
in
in
the
charter
proposal,
but
when
we
actually
needed
to
clarify
with
the
isg
what
exactly
needs
to
go
there?
Well,
we
didn't
have
a
document.
We
didn't
have
a
clear
idea
of
what
we
want
to
achieve
what
the
working
group
wants
to
achieve.
So
we
decided
to
postpone
that
for
the
next
charter.
So
what
we
would
like
to
do
is
keep
this
way
of
working.
B
So
whenever
we
have
a
new
work
to
to
be
done,
you
know
to
have
a
draft
to
describe
what's
what
what
you
would
like
to
achieve
have
the
discussion
and
then,
when
we're
fairly
confident
that
we
know
the
working
group
is
fairly
confident
that
we
actually
know
what's
going
there,
then
we
can
recharge
them.
There
is
no
problem
about
that,
but
to
have
like
a
work
based
on
a
clear
objective.
A
You,
okay,
so
we
said
it
once
we
said
it
twice.
Congratulations
the
authors
of
at
7
24,
and
I
believe
that
I
actually
won
the
game
because
we
had
a
bad
about
the
rfc
number
and
I
was
the
closest,
but
somebody
has
to
remember
what
the
bet
was
about,
because
I
don't
know
what
I
win
now
and
that's
that's
sad.
A
A
B
A
Yes,
I
tried
to
change
the
gain.
I
just
need
feedback
to
know
what
gain
is
correct,
because
I
heard
it
was
too
bad.
I
moved
again
to
the
max,
I
moved
it
closer
to
my
mouth
and
then
I
got
from
cast
and
that
I
was
bringing
it
to
the
mic.
So,
yes,
I
mean
there's
something
wrong.
So
so
is
it
someone
that
does
not
hear
me?
Is
it
everybody.
D
The
most
important
thing
is
you
don't
breathe
into
the
microphone
and
the
second
most
important
thing
is
that
you
switch
off
any
automatic
gain
control,
because
if
you
get
noises
like
the
crackling
from
your
your
broken
cable
or
the
breathing
in
your
microphone,
then
the
agc
will
turn
you
back
to
quiet,
so
switch
off.
Adc.
A
Because
you
know
normally,
I
pushed
I
put
it
pretty
much
in
this
situation,
but
then
somebody
said
he
could
not
hear
me.
So,
okay,
if
it
looks
okay,
let
me
continue
so
I
was
saying
sores
many
many
thanks
for
all
your
help,
so
he's
not
there,
but
we
should
have
had
suresh
again,
yes
and-
and
we
had
a
plan
to
to
to
make
a
party
for
him
and
thank
him
for
all
the
great
work
he
did
with
these
groups
and
this
group
and
all
the
other
groups
at
the
interior.
B
B
A
H
A
Okay,
thank
you
very
much
anna.
So
we
look
forward
for
seeing
the
draft.
It
seems
from
from
these
four
use
cases
that
it's
like
four
documents
in
one,
so
that
can
explain
why
it
takes
longer
to
actually
achieve
this
work.
So
many
many
thanks
anna,
so
the
other
four
drafts
will
be
presented
today,
so
I
don't
spend
too
much
time
on
it.
A
So
right
now
it's
not
clear,
so
this
document
won't
be
discussed
today,
it's
just
there
if,
if
people
want
to
to
use
to
have
a
hana
registry,
we'll
just
need
to
revive
this
draft
for
the
time
being,
I
just
let
it
be,
and
dominic
will
present
the
oam
and
I
will
discuss
a
little
bit
the
future
of
the
ppp
draft.
So
all
this
will
be
covered
later
today.
B
Yes,
thank
you
very
much
pascal,
and
we
actually
managed
to
get
your
to
distract
you
so
that
you
forget
what
you
actually
got,
because
you
correct
you
correctly
guessed
the
rfc
number
of
ship
and
you
are
actually
you.
You
had
the
one
round
of
beer
from
every
one
of
the
participants,
but
hopefully
we'll
be
able
to
deliver
this
on
the
next
atf
and
until
then,
so
I
we
wanted
so
with
pascal.
B
B
A
Alex
yes,
if
I
must
say,
because
eric
is
new
with
us,
we
also
have
been
heavy
users
of
the
rooms
that
the
atf
lets
us
use
in
between
meetings.
You
know
those
of
the
meeting
rooms
like
what
is
the
they
call
this
well
non-regular
meeting
rooms
that
we
can
book.
We
had
a
number
of
design
sessions
for
chic
in
those
rooms,
so
we
really
appreciate
that
the
asg
makes
this
room
viable
to
people.
It
has
been
very
useful
to
us.
A
H
I
So
what
have
changed
in
in
the
model?
Or
what,
from
the
discussion
from
previous
presentation
is
that
now
this
model
focus
only
on
young
and
don't
include
some
tricks.
We
can
have
for
core
conf
those
to
have
a
very
clear
and
young
model,
and
then,
of
course,
we
and
of
course
we
have
in
mind
also
what
we
can
do
with
core
conf
to
optimize
things.
But
that's
not.
I
The
goal
of
this
model
is
just
to
define
things
in
young,
so
normally
it
will
be
only
one
file,
but
currently
for
simplicity,
for
it
easiest
to
develop,
at
least
for
for
us.
It
has
been
split
in
two
parts.
One
file
is
chic
id,
and
here
you
have
the
definition
of
all
the
types
and
identifiers
that
are
used
in
chick.
I
I
I
So
we
have
this
base
identity,
identity
and
then
we
derive
all
the
fields
from
we
can
find
in
check
from
this
basic
identity,
and
so
we
have,
for
example,
a
field
id
for
ipv6
version
for
traffic
class
6
directorate,
and
when
we
have
once
we
have
defined
these
things,
we
create
a
class
that
is
called
field
id
type
and
will
base
on
this
my
main
identity
and
so
in
the
rest
of
the
model.
When
we
want
to
define
field
id,
then
we
will
use
this
type.
I
So
what
have
changed
since
the
previous
version
is
that
we
go
a
little
bit
deeper.
So,
for
example,
here
we
have
a
traffic
class
identifier,
but
it
can
be
also
divided
in
two
parts,
so
to
have
access
if
we
want
more
precision
into
the
this
serve
or
the
ecn
class.
So
this
is
splitting
and
we
can
do
also
the
same
spitting
in
for
for
co-op,
for
example,
for
code
code
can
be
cut
in
two
classes,
so
it's
on
two
parts,
one
for
class
and
the
other
for
for
details.
I
I
So
here
we
have
these.
So
it's
a
list
of
all
the
fields
we
have
in.
We
have
defined
for
compression.
So,
as
I
say,
we
have
class
traffic
class
that
has
been
defined
in
subclasses
same
thing
for
code,
and
we
have
also
something
that
has
been
added
for
co-op.
That
is
end
option,
which
is
not
really
an
option,
but
it's
a
fixed
value
that
we
can
find
in.
In
the
leader
so
for
co-op,
I
have
some
some
question
of
the
group
on
how
to
to
do
it.
I
So
captain
has
proposed,
for
example,
to
reserve
the
world
options
space
to
put
in
in
young,
so
that
could
be
a
good
way,
because
if
you
create
a
new
option,
then
we
don't
have
to
redefine
something
new
for
for
chick,
but
it
can
also
lead
to
something
very
huge.
If
we
take
all
the
space
for
options,
then
we
we
have
16
bits
that
are
with
there
or
65
555
value
that
are
reserved,
and
maybe
we
can
do
it
just
reserve
it
for
the
value
between
0
and
255.
I
D
I
D
I
D
I
Okay,
so
for
the
chic
model
by
itself,
there
is
few
changing
since
the
last
version,
so
the
main
changing
is
that
we
add
a
version
number
in
the
rule
and
maybe
it's
quite
useful,
for
example,
for
a
device
to
check
if
the
core
has
the
same
rule
version
so
right
now,
it's
just
a
value
and
it's
not
used
to
make
something
hierarchical
enough.
In
a
rule,
several
several
versions
is
just
we
didn't
identify
a
rule
and
see
if
both
ends
agree
on
on
the
number.
I
I
The
first
one
is
act
behavior,
it
means
when
the
receiver
or
the
reassembler
has
to
send
an
acknowledgement.
So
we
have
three
choices
after
all:
zero,
after
all
one
or
when
you
want
so
at
any
time
the
layer
two
will
decide,
and
we
have
also
another
part.
But
currently
the
view
has
a
boolean
which
says
tile
in
all
one.
We
have
two
behaviors
that
are
compatible
each
other,
but
the
sender
may
decide
just
to
send
the
slcs
in
the
old
one
or
can
send
a
tile
on
the
rcs.
I
So
here
it's
a
way
to
describe
what
we
can
do
so
currently
it's
true
or
false,
but
we
will
move
through
something
that
is
yes,
no
or
optional.
So,
yes,
it
means
that
the
sender
has
to
put
a
tile
in
all
one.
No,
it
doesn't
have
to
do
it
or
optional,
he
do
what
he
wants
and
the
receiver
will
be
able
to
to
determine.
If
there
is
data
on
it
and
it's
the
standard,
I
love
it.
I
So,
to
conclude,
I
think
we
have
something
right
now
that
is
quite
stable,
but
have
to
be
improved
in
terms
of
description,
but
we
think
that
it's
quite
good
for
for
young.
So
now
we
we
have
to
see
if
we
can
go
to
young
young
doctor
review
and
of
course,
what
we
have
to
do
also
is
to
put
more
description
into
the
young
model
to
explain
without
any
ambiguity.
C
I
just
write
in
the
document
that
you
can
have
a
rule
id
of
length
zero.
So
with
no
rule
id-
and
you
said
this
can
be
used
for
the
default
rule.
Can
you
explain
how
you
plan
on
using
that
in
especially
how
do
you
transmit
such
a
rule
packet
that
is
processed
by
such
a
rule
over
the
air?
If
you
have
a
zero
length
rule
id.
I
So
if
you
want
to
send
a
rule,
if
you
want
to
describe
a
rule
from
zero
length
and
you
put
zero
in
this
rule
length
and
then
it's
defined
in
the
young
model,
so
the
rule
zero
or
zero
the
length
zero
can
be
used
to
be
a
view
as
an
implicit
route.
For
example,
you
have
a
device
that
is
not
cheek,
so
we'll
send
data
and
it
goes
to
a
core
chic
decompressor,
and
then
it
just
has
one
rule
that
describes
how
to
process
information.
I
E
I
C
H
H
H
H
H
H
H
H
H
Because
in
section
2
of
draft,
we
showed
that
we
can
make
a
quad
compression
in
different
stacks
and
in
the
first
point
we
have
application
to
applications.
We
only
compress
co-op
without
compressing
all
the
stack
so
his
his
problem.
Her
his
question
here
is
to
to
know
where
we
are
going
to
do
this
context,
initialization,
because
normally,
when
we
compress
all
the
stack
here.
C
H
H
H
I,
as
I
tell
him
that
for
the
moment,
it
was
out
of
the
scope
of
the
document
to
explain
exactly
how
to
make
context
initialization,
but
we
can
add
a
note
saying
that
when
this
part
of
the
architecture
will
be
done,
we
have
to
take
care
about
how
to
make
the
the
negotiate.
The
context
initialization,
when
we
are
only
compressing
layer,
7
or
co-op
only
and
the
compression
is
done,
end-to-end
between
two
applications.
I
B
B
B
B
Yes,
so
I
completely
agree
with
with
pascal,
so
this
also
brings
the
importance
of
the
the
previous
presentation
is
to
say:
okay.
Well,
we
need
to
get
the
I
mean
it
seems
to
me
to
to
that.
The
work
has
been
investing
really
well.
So
as
the
moment
that
we
have
the
data
model,
then
we
can
have
everything
else
that
comes
out
of
it.
H
H
H
E
H
C
C
H
C
Length,
header
fields:
if
a
corrupted
packet
comes
to
the
decompressor,
which
reconstructs
with
a
length
that
is
different
from
that
in
the
original
header,
then
the
arrow
would
be
detected
and
the
packet
be
dropped.
I'm
curious
how
you
do
that,
because
how
do
you
know
the
the
length
of
the
head
of
the
header
in
the
original
packet?
If
you
knew
that,
then
you
would
not
need
to
send
it.
So
how
can
you
compare
the
reconstituted
length
with
the
length
of
the
original
packet.
H
H
I
I
So,
for
example,
if
you
say
my
because
we
have
already
this
zip
explosion
on
people
when
they
read
it,
they
think
about
the
zip
explosion.
I
don't
remember
how
it's
called,
but
you
say
I
have
a
ten
thousand
of
zeros
and
then,
when
you
reconstruct
things,
then
you
put
ten
thousand
of
zeros
and
then
you
send
something
very,
very
huge.
In
fact,
the
opposite
is
what
we
are
sending
is
the
length
of
what
we
send
not
the
length
of
what
we
cut.
I
So
if
you
put
a
very
high
value,
then
you
have
to
send
data
the
same
amount
of
data
to
be
believed
by
the
receiver.
It's
not
an
attack!
Okay,
so
it's
already
said
in
rfc
8724.
I
think,
but
it's
the
place
where
we
are
using
variable
length
residue.
So
but
as
we
say,
this
section
is
very
hard
to
write
because
we
don't
put
new
things
compared
to
the
basic
chic
compression.
We
just
apply
it
to
to
co-op.
H
K
K
C
K
K
K
The
concern
was
that
it
says
here
that
end-to-end
authentication
may
detect
such
a
corruption,
but,
as
I
understand,
if
the
sender
and
the
receiver
disagree
about
the
com
about
the
compression
that
is
used
about
in
ins
for
the
for
the
compressed
message
that
might
not
show
up
in
the
checks-
and
it
would
not-
and
nothing
about
the
nothing
about
the
compression
is
fed
into
the
authenticated
data.
So
there
is
a
proposal
on
the
I've
sent
a
proposal
back
a
year
ago,
or
so
that's
also
filed
in
a
github
issue.
K
H
I
E
B
Yes,
I'm
sorry
why,
while
while
olivia
is
starting
just
thinking
so
christian,
he
used
the
plus
q
on
the
chat.
So
in
case
you
would
like
to
ask
questions
or
you
would
like
to
you
know,
to
get
the
mic.
Please
do
a
plus
q
on
the
chat,
and
you
know
it's
like
a
virtual
cue
and
if
you
want
to
get
removed,
you
type
a
minus
q.
This
way
you
know
we
can.
B
C
B
E
E
E
So
in
change
size
in
website
sorry,
we
added
the
id
proposition
on
how
to
compute
the
id
a
lot
of
edits.
Following
thanks
to
dominic
reviews
for
releasing
hilda
munich,
we
updated
the
acknowledgements
with
all
the
or
the
feedback
I
got.
Maybe
there
was
some
some
feedback
before
I
was
involved
in
the
document,
so
if
you're
not
listed
in
here-
or
you
think,
somebody
should
be
listed
in
here-
please
status
and
we
change
the
acknowledgement
behavior
from
the
end
of
each
window
to
optional
for
clicking
fragmentation.
E
E
E
E
E
E
A
A
I'm
hearing
nothing
apart,
yes,
so,
okay,
so
we'll
we'll
we'll
issue
a
good
plus
call
with
a
three
weeks
review
time
so
asking
you
guys
to
actually
look
at
this
document.
It
is
the
first
technology
document
that
we
will
issue,
which
means
that
it
will
be
kind
of
a
reference
for
the
the
type
of
content
and
the
layout
of
the
technology
document
for
shake.
So
it's
very
important
that
this
first
document
is
done
right
and
the
more
document,
the
more
reviews
we
get
the
better
for
this
document.
F
Thanks
for
asking
yes,
I
want
to
give
an
update
about
the
the
draft,
the
shakeover
six
box.
I
can
move
this
right
here,
yes,
perfect,
so
on
the
status
we
haven't
done
any
any
revision,
because
we
were
relying
on
on
on
testing
some
parameters
and
some
changes
at
the
hackathon
in
vancouver,
which
of
course,
got
cancelled
together
with
the
with
the
meeting.
Since
then,
we've
been
working
on
on
the
new
remote
setup
to
continue
advancing.
F
It's
been
a
little
challenging
just
to
make
sure
that
we
get
the
equipment
in
place,
recuperating
equipment
from
lads
and
stuff.
It
was
a
challenge,
but
so
far
seems
like
we
are
getting
back
on
track.
Just
as
a
reminder.
The
last
draft
update
we're
about
adding
parameters
for
the
icon,
error,
data,
fragmentation,
integrity
mode
and
also
we
tested
the
parameters
on
on
the
university
of
chile's
five
sheet
implementation,
notably
to
send
text
files
about
53,
bytes
and
small
images
like
356.
F
F
The
architecture
again
as
a
reminder
of
the
software
that
the
guys
at
university
of
chile
are
developing,
it's
meant
to
be
is
meant
to
be
unique
for
both
sigfox
and
laura
one.
So
there's
a
common
fragmenter
and
parser
message,
then
there's
also
a
chic
session
engine
and
then
below.
There
are
specific
functions
for
either
sig
fox
or
laura
one
right
now,
of
course,
the
the
one
we
are
working
on
is
the
profile
for
sig
figs,
but
the
idea
is
to
make
it
generic
and
also
test
for
interoperability
in
the
future.
F
H
F
Again,
to
use
the
sequel
sequence
numbering
to
to
optimize
chicag
transmissions,
for
instance,
they're
all
one
fragment,
fine-tuned,
timers
and
header
fields,
etc,
and
also
the
for
the
interoperability
test.
We
had
already
made
a
proposal
to
do
a
an
inter,
interrupt
test
at
the
hackathon
in
vancouver
and
right
now.
I
guess
the
question
mark
is
whether
we
should
plan
for
something
madrid,
bangkok,
which
are
pretty
much
up
in
the
air
or
we
sh.
If
we
should
start
thinking
about
doing
something
virtual
and
remote.
A
F
C
F
A
F
A
For
isg,
right
and
past
world
group,
let's
go
yes:
okay,
we
will
we'll
have
a
milestone.
Helix,
so
don't
be
surprised
if
you
get
two
milestones,
one
milestone
will
be
less
than
two
months
from
now.
It's
gonna
be
the
lora
document
thanks
to
isg
and
so
we're
in
april.
So
somewhere
in,
like
early
june
and
early
september,
we
left
the
six
fox
document
and
then
in
december
we
have
nbiot.
I
guess.
A
A
We've
discussed
already
at
the
interim,
but
for
those
of
you
who
are
not
at
the
interim,
we
have
a
document
which
is
a
bit
borderline
for
this
working
group,
which
is
shake
over
ppp
and
the
reason
for
defining
shape
compression
over
ppp
is
as
soon
as
you
have
pvp.
Then.
Obviously
you
get
serial
links.
A
You
know
all
the
usual
phone
mobile
phone
serial,
cable
rs,
whatever
you
also
get
xg
like
if
you
use
a
standard
data,
your
phone,
you,
since
there
is
ethernet
pp
or
is
on
that
as
soon
as
you
have
shake
over
ppp,
you've
got
shake
shakeover
ethernet
and
since
there
is
the
wi-fi
emulated
ethernet,
you
also
have
wi-fi.
So
it
seems
that
enabling
shakeover
ppp
opens
a
broad
range
of
applications
on
a
broad
range
of
networks.
A
So
it
looks
like
you
know,
a
simple
enabler,
so
we
already
have
rfc
5172,
which
explains
how
you
can
do
other
modes
of
compression.
There
is
about
zero
mod.
One
so
we'll
be
basically
doing
a
mode
two,
and
so
you
just
signal
in
this
little
header
in
the
ipcp
I'm
doing
what
two
which
is
check
and
then
you
can
provide
data
and
the
idea
is
as
data.
A
A
Obviously,
if
you
have
another
idea,
it's
still
time
to
tell
me
my
intention
is
to
actually
republish
this
draft
as
a
need
area
document
as
soon
as
they
have
enough
and
one
galaxy
is
there
to
see
it
enough
support
for
doing
this
work.
If
sheik
is
saying
yes,
it's
something
we
want.
If
help
you
up,
then
basically
we'll
definitely
get
enough
support
to
go
and
progress.
This
work,
since
it's
ppp,
it's
not
really
scoped
for
us,
so
interior
looks,
as
we
said
in
earlier
meetings
into
meetings.
A
J
A
So
clearly
we
have
a
dependency
on
the
data
model
document
and
once
we
we
can
effectively
provide
the
binary
of
of
the
the
all
the
rules
for
a
particular
device.
Then
we
can
test
this
document
right
now.
It's
hung
quote
unquote
because
we
are
missing.
You
know
the
the
representation
of
the
rules,
and
I
see
that
anna
is
queuing
up.
H
A
A
B
On
on
that
point,
so
we
of
course
you
can
keep
the
work
here
at
nlp.
One
and
I'll
be
sharing
the
the
the
work
on
this
particular
item.
Then
the
point
would
be
also.
How
would
the
the
link
with
interior
would
happen
or
with
the
six
man
about
the
you
know,
the
registration
of
the
new
number
in
ppp
and
you
know
the
necessary
changes
that
will
be
there.
B
A
Just
like
you
know
the
lp1
document,
which
is
a
technology
document
or
the
sigfugs
accurate.
They
profile
check.
They
give
you
values,
you
can
use
and
methods
that
you
can
use
out
of
all
the
paraphernalia
of
methods
that
the
rfc8724
actually
provide,
and
so,
if
most
of
this
document
is
chic
profiling,
you
see
that
the
interior
people
will
have
a
hard
time
figure
if
we
have
all
the
right
profile
elements
and
if
we
have
the
right
values
for
them.
G
A
G
G
A
Yeah
and
that
works
for
me,
we
are
taking
the
path
of
actually
saying
hey.
We
need
to
put
at
least
one
new
section
of
profiling,
a
shake
for
high
speed
links,
and
if
we
do
that,
then
that
makes
this
document
a
shake
lp1
document-
and
now
it's
about
you
know,
which
is
the
path
through
asg
through
either
ad
sponsor
or
register,
and
the
chairs
and
ad
will
take
that
offline.
E
G
A
Yeah,
that's
why
I
said
applicability
statement,
because
there
are
actually
some
some
domains
of
application.
We
are
talking
about
just
a
compression
mechanism,
we're
not
talking
about
a
particular
protocol,
we're
just
enabling
compression.
So
the
question
is
really:
do
we
see
places
where
this
particular
compression
has
specific
advantages?
C
B
B
Pascal,
thank
you
thanks
thanks
a
lot
for
for
the
presentation.
The
time
is
running
is
it's.
We
are
a
little
bit
behind
the
schedule
now.
So
yes,
thanks
for
submitting
the
draft
and
thanks
eric
for
the
for
the
input,
and
it
would
be
really
exciting
to
see
this
draft
advancing,
and
we
already
know
that
it
will
have
some
requirements.
The
data
model,
and
you
know
it
will
put
some
time.
B
C
Hello,
thank
you.
So
this
is
just
an
informal
account
of
interrupt
testing
for
check
the
the
people
doing.
The
work
are
lauren
cedric,
olivier
and
myself.
I'm
just
writing
the
powerpoint.
It
was
meant
to
be
done
at
the
hackathon
at
hf107,
but
many
offers
said
they
would
not
fly
to
vancouver.
Anyway
long
before
the
team
was
confirmed,
it
was
going
to
be
mostly
virtual,
so
we
started
earlier
early
on
thinking
what
we
would
do
if
we
were
not
at
the
same
time
in
the
same
place.
C
We
use
open
check
to
generate
them,
but,
of
course,
we're
ready
to
discuss
without
any
disagreement.
The
four
cases
we
have
is
only
compression
and
we
started
by.
You
know
the
obvious
ones:
the
compression
where
the
compression
rule
does
not
match.
So
it's
a
low
compression
compression
we've
aligned
headers
everything
by
the
line.
So
this
is
very
simple:
it
checks
the
the
matching
project.
C
Then
the
segment
is
slightly
more
elaborate,
but
we
have
underline
headers
and
not
by
the
line.
So
it
checks
the
bit
shifting
ability
of
the
implementation
a
little
bit.
Then
we
have
a
real
compression
where
we
do
apply
compression
and
we
highlight
some
fields
and
re-compute
some
fields
at
the
third
case.
C
So
the
next
steps
are
provide
more
pest
factors
in
terms
of
things
that
can
be
applied
offline
and
going
into
fragmentation.
The
no
arc
fragmentation
mode
does
not
have
a
feedback
path,
so
it's
obvious
to
generate
golden
vectors
for
this
mode
as
well.
So
we
want
to
do
that.
I
think
lauren
just
did
that
or
generated
some
yesterday.
So
it's
very
recent
and
we
also
want
to
implement
the
online
testing
where
we
have
multiple
infinity
implementation
running
against
one
another,
each
other
in
real
time,
and
we
have
a
little
bit
on
that.
C
Olivier
has
written
an
mqtt
connector
on
ttn
the
finx
network
for
lower
one,
and
he
was
able
to
check
lip
check
implementation
on
a
board
microcontroller
board
against
another
implementation.
I
think
it
was
openshift
on
the
cloud
side
and
lauren
also
is
working
on
the
server
by
which
you
could
run
implementations
via
udp
against
one
another.
C
E
I
I
A
C
C
C
C
H
C
And,
of
course
we
have
to
discuss
security
considerations,
as
always,
so
quite
a
lot
of
work
ahead
of
us,
and
so
yes,
we've
been
discussing
that
between
the
co-fours.
I
think
in
february
last
time,
and
we
said
we
would
bring
that
to
the
open
on
the
mailing
list,
so
get
input
from
the
working
group.
So
I
still
have
to
do
that
and
that's
it
for.
A
A
F
So
the
purpose
of
this
presentation
is
to
do
a
recap
of
that
discussion
and
to
to
have
a
common
understanding
on
on
our
mindset.
When
we
talk
about
multicast,
so,
basically
that
they,
the
thing
is,
we
believe
and
there's
people
that
believe
that
there's
a
great
benefit
for
multicast
services,
for
several
reasons
in
low
power,
wide
area
networks
and
the
reasons
could
be
software,
firmware,
updates,
network
policies
or
a
simple
traffic
broadcast
or
multicast
etc.
F
F
F
There
could
be
also
some
options
to
have
reliable,
multicast
fragmentation
support,
in
which
case
we
can
think
of
arque
over
chic,
for
instance,
doing
some
unicast
hack
on
error
response
to
the
multicast
transmissions
there.
We
can
also
think
of
forwarder
correction
in
lower
layers
or
some
other
mechanisms
at
the
application
layer
at
the
at
the
last
interim,
when
we
discuss
this
topic,
pascal
also
mentioned
the
trickle
algorithm,
which,
potentially
with
some
variant,
could
be
considered
as
a
as
an
option.
F
And
then
we
talk
about
considering
this
ietf
working
group.
If
this
is
really
a
potential
work
item,
so
the
baseline
is
that
right
now
we
we
understand-
and
we
agree
that
there
are
several
solutions
for
providing
multiple
services,
some
of
them
at
the
lower
layers,
either
layer,
one
layer,
two,
there
could
be
also
solutions
on
layer,
three
or
even
at
higher
layers.
F
Likewise,
there
could
be
centralized
or
distributed
solutions
to
provide
this
multicast
services
and,
of
course
not
all
of
these
solutions
would
be
in
scope
for
the
ietflp1
working
group.
So
right
now
where
we
stand-
and
it's
proposed
to
to
document
at
least
here,
what
are
the
needs,
identify
the
potential
solutions
and
then,
with
some
draft,
discuss,
discuss
if
there's
some
solutions
that
would
be
in
indeed
in
scope.
For
this.
H
A
I
mean
a
set
of
antennas
that
globally
cover
the
whole
area,
so
each
device
being
capable
to
receive
from
at
least
one
member
of
the
dominating
set
and
having
more
than
one
dominating
set.
That's
where
trickle
comes
into
play,
so
what
you
would
be
doing
is
initially
you
would
schedule
for
the
first
fragment
of
your
reliable
distribution.
A
Third
from
the
third
gateway,
knowing
that
those
gateways
each
time
you
you
send
your
trickle
copies
of
the
same
fragment
of
same
portion
of
your
multicast,
the
station
would
have
multiple
chances
to
receive
this
thing
with
the
exponential
back
off
now
it
still
means
that
there
needs
to
be
either
a
schedule
at
which
the
device
wake
up
or
that
the
device
must
be
always
listening
in
order
terms.
That
means
brc.
A
This
model
would
not
work
for
devices
which
live
on
their
own
schedule
like
class
a
but
for
brc.
You
could
actually
make
it
so
that
this
dominating
set
of
antennas
covers
the
whole
area.
That's
the
game,
I'm
not
talking
about
just
one
antenna
talking
to
a
set
of
devices
around
that
antenna
like
a
wi-fi,
ap
and
more
looking
at
a
very
large
distribution
over
a
wide
area
which
is
covered
by
multiple
antennas.
That's
more
like
that!
F
And
I-
and
I
I
yeah-
I
remember
you-
you
mentioned
that
and
and
of
course
I
was
less
aware
of
how
trickle
worked
and
when,
when
reading
the
the
document,
what
I
understood
the
about
the
algorithm
is
that
it
relies
on
nodes
that
have
already
received
the
information
to
to
synchronize
or
basically
to
avoid
flooding
information
several
times
and
that's
that's
the
part.
What
I
was
confused,
because
I
couldn't
really
map
on
how
how
to
communicate,
which
nodes
have
received.
What
to
the
network?
A
A
It's
more
like
exponential
backup
for
the
fact
for
the
retries,
without
ever
an
acknowledgement,
and
now
the
fact
that
it
actually
spreads
in
a
mesh
is
a
particular
property
when
you
use
it
on
the
mesh,
meaning
that
you
hear
it,
and
then
you
repeat
it,
but
it's
just
an
option.
In
our
case
there
would
never
be
a
repeat:
it
would
just
be
a
dominating
set
of
gateways
which
would
certain
copy
and
then
possibly
the
same
or
possibly
another
dominating
set
which
might
which
repeat
and
then
another
and
then
another.
B
G
A
I
was
thinking
about
using
really
trickle,
meaning
that
the
gateways
who
could
not
hear
another
gateway
speak.
He
would
also
speak,
but
then
it
doesn't
appear
to
be
the
right
idea.
It's
probably
much
better
that
the
central
decision,
the
network
server
quote-unquote,
decides
which
gateways
are
going
to
turn
the
first
round
and
then
which
gateways
are
going
to
send
the
second
round
because
they
have
network
servers,
know
which
gateways
form
a
dominating
set
and
they
can
design
one
or
more
dominating
sets.
A
So
it's
much
more
powerful
to
actually
do
the
computation
of
who
gets
to
repeat
from
the
central
point.
I
mean
that's.
What's
really
what
nicolas
sarna
told
me
when
we
discussed
this
idea,
I
think
he
was
right.
It's
much
more
elegant
applied
to
lp1
to
let
the
central
server
decide
what
the
dominating
sets
are.
B
F
Yeah,
so
thanks
alex
well
all
in
all.
As
I
said
there,
there
are
several
alternatives.
Some
some
are,
I
guess
straightforward.
If
we
did
some
some
variation
of
chic,
we
could
for
sure
say
this
is
something
that
isn't
scoped
for
for
the
working
group.
If,
if
there's
a
solution
that
is
on
a
different
layer,
then
probably
out
of
scope
and
there
could
be
some
other
variants
as
the
trickle
one.
F
That
pascal
is
saying
that
relies
on
on
this
distribution
of
information
algorithm
to
provide
some
reliable,
multi-cut
distribution.
But
anyway,
at
this
point
we
have
no
drop
yet.
So
the
idea
is
to
document
knowing
whether
the
problem
statement,
the
the
needs
and
and
then
the
potential
solutions,
so
that
we
can
have
a
constructed
discussion
on
on
what
to
do
in
terms
of
watching
scope
for
this
working
group.
B
J
B
I
mean
I
would
like
to
see
for
us
providing
solutions
that
are
actually
demanded
by
someone
you
know
and
not
have
something
really
beautiful
and
really
abstract,
but
that
has
no
practical
use.
I
mean
I'm
not
going
to
say
practical
use,
but
you
know
that's
a
little
bit,
maybe
not
yeah,
not
not
used
directly.
B
So
it's
really
great
to
have
you
guys,
juan
carlos
and
olivia
as
co-authors
of
this
one,
and
we
think
with
pascal's
input,
and
I
think
that
we
can
have
a
very
good
baseline
and
then
we
can
actually
go
and
and
develop
the.
If,
if
lp1
is
the
place,
we
can
actually
go
and
work
on
the
documents.
So
I
really
like
your
presentation
to
thank
you
for,
for
the.
A
A
A
B
F
A
Normally
it's
a
flooding
mechanism
right,
so
people
hear
and
then
they
may
repeat,
unless
there
is
already
a
density
of
repeat
in
their
environment,
so
we
for
lp1.
We
would
take
the
repeat
thing
off.
We
don't
repeat
anything,
so
you
can
see
it
as
selecting
a
subset
of
the
gateways
of
the
antennas
that
cover
a
certain
area,
and
so
that's
why
that's
what
I
call
a
dominating
set,
meaning
that
each
device
is
covered
by
at
least
one
antenna
in
this
dominating
set
and
having
those
selected
antennas
turned
fragment.
A
A
A
A
A
Please
unicast
it
to
me,
but
it
would
be
done
only
after
an
exponential
back
off
of
retries
by
various
gateways.
The
idea
of
changing
dominating
set
of
gateways
for
every
transmission
is
to
add
diversity
and
that's
actually
a
key
point
in
lp1
to
have
multiple
gateways
that
can
actually
be
in
range
for
a
particular
device.
So
if
the
first
try
is
done
by
one
gateway,
a
second
try
is
done
by
another
gateway.
B
B
Do
you
think
that
we,
you
know
the
question
that
the
way
it
is
asked
you
know
to
have
this
document
that
outlines
the
the
the
the
problem
statement
of
what
we
want
to
of
what
the
group
would
like
to
achieve
as
our
multicast?
Do
you
think
that
this
is
something
that
is
of
interest
of
you
know
that's
of
interest.
B
B
B
B
Okay,
so
I
see
a
lot
of
plus
ones
in
the
whoa
lots
of
plus
ones.
So,
okay,
I
think
that
this
means
that
we
have
quite
a
lot
of
interest
in
the
in
the
working
work,
so
that
would
be
for
me
an
excellent
indication
that
we
need
to
go
forward
with
this
document,
and
so
I
think
that
that
could
be
also
very
reassuring
for
you
on
carlos
and
olivier.
You
know
that
you'll
have
support
for
for
your
document
and
and
yeah.