►
From YouTube: IETF115-LPWAN-20221111-1200
Description
LPWAN meeting session at IETF115
2022/11/11 1200
https://datatracker.ietf.org/meeting/115/proceedings/
A
C
B
So
hello,
everyone
we're
ready
to
start
so
this
is
the
fans
are
here.
So
this
is
the
the
meeting
of
the
lp1
working
group
and
we're
very
happy
to
be
here
for
the
first
time
for
since
a
couple
of
years,
yeah,
since
a
couple
of
years
now
and
we're
very
happy
to
see
everyone
that
is
here
in
the
room
and
also
the
people
that
are
remote.
B
B
C
C
B
D
B
B
So
this
is
the
agenda
for
today,
so
we
we
start,
of
course,
with
the
with
the
opening.
Then
we're
going
to
have
a
discussion
about
the
chartering
that
we
have
been
talking
about
in.
We
have
been
discussing
a
little
bit
in
in
the
past.
Then
we
have
a
new
work
to
be
presented
so
Chic
convergence
profile
from
Sergio
and
a
discussion
about
IDs
that
is
going
to
be
led
by
Lauren,
and
so
we
have
about
an
hour
and
a
half
for
today's
meeting.
B
B
D
A
E
A
C
C
B
You
know
how
things
are
going
to
evolve
from
here
on,
so
here
the
the
on
the
shake
shakeover
sigfox
and
the
compound
deck.
So
we
are
almost
there.
We
are
only
waiting
for
the
final
touches.
I
think
there
is
the
the
shepherd.
So
Anna
is
The
Shepherd
of
the
Chic
over
sick
Fox
and
is
to
to
push
the
button
I.
Think
that's
the
only
thing
that
is
remaining
and
on
the
compound
deck
I'm.
B
Just
waiting
for
the
latest
revision
to
be
published
with
the
there
was
there
were
some
nits
I
think
they
were
fixed
in
the
GitHub
version,
but
I
just
wait
for
them
to
be
published
as
a
in
the
data
tracker
and
it's
it's
good
for
me.
So
I'll
push
the
button
and
it
will
be
sent
off
to
the
LSG.
So
yes,
Sergio.
F
B
B
Then
yes,
okay,
please
double
check
and
it's
good
for
me.
I'll
push
the
button
later,
just
just
right
after
yes
and
Anna
I'm,
not
sure.
If
you're
hearing
me
about
the
the
yes,
so
Anna
is
in
the
queue.
If
you
can
say
if,
if
she
covers
see,
foxy
is
good
for
you
and,
if
you're
ready
to
push
the
button.
D
B
Okay,
so
so
that's
that's
good!
That's
that's
excellent!
Now
on
the
document
advancement,
so
we
have
the
young
data
model.
So
the
work
has
it's.
It's
done
right
right
now.
It's
in
the
editor's
queue
and
I
think
that
was
a
huge
amount
of
work
and
with
Pascal.
We
would
like
to
thank
everyone
that
has
been
working
very
actively
the
whole
working
group
and
Laurent
Anna
for
for
really
taking
the
pain
and
taking
the
like
the
the
effort
to
to
making
sure
that
we
have
this
good
young
data
model.
That
was,
you
know.
B
We
were
waiting
for
that
document,
and
so
thank
you.
Both
it's
really
an
amazing
work,
so
we're
just
waiting
for
the
number
I.
Don't
think
we
have
the
number
yet
of
the
the
RFC,
but
it's
coming
so
excellent
work
there
nbiut
mostly,
so
it's
also
very
well
Advanced
the
shakeover
nbiut.
So
there
are
the
the
exchanges
with
the,
of
course,
the
liaison
with
the
3gpp
that
is
currently
again
being
being
discussed,
but
the
work
is
done.
B
A
Yeah
I'm,
sorry
for
the
interrupt
I
just
want
to
say
that
I've
never
seen
the
document
going
so
smoothly
through
the
asgq.
So
don't
ask
me,
but
I
think
it
means
it's
an
excellent
document
and
lyric.
If
you
want
to
chime
in,
but
no
I,
don't
think
there
is
even
a
discuss.
I
mean
you
think
it's
just
gonna
fly.
D
D
But
of
course
it's
not
the
ITF
to
do
it
right.
So
if
you
really
want
to
get
the
work
done
there
into
the
3gpp
standards,
the
door
is
open.
Now,
regarding
the
document
itself,
it
will
be
reviewed
by
3gpp
in
next
week.
We
may
expect
maybe
a
review
the
week
after
so
I
would
wait
until
end
of
November
to
reassess
last
discuss
about
how
we
do
the
informative
part
versus
the
normative
part.
So
don't
touch
now
put
in
sleep
mode
for
two
with
two
three
weeks.
B
Thank
you
very
much
thanks
Eric
for
for
that
clarification.
So
again,
a
really
amazing
work.
I
think
it's
I
mean
we're
very
happy
with
how
things
are
are
moving,
so
we
discussed
the
compound
deck
in
the
shake
of
our
sigfox,
so
they're
going
to
be
submitted
in
the
in
the
in
the
next
week.
We
could
shoot
so
there
is
the
document
of
the
oam,
and
the
question
is,
of
course,
if
there
is
still
interest
in
continuing
that
work
of
the
current
authors.
E
B
B
A
The
architecture
has
progressed
with
regard
to
the
description
of
how
Chic
works
on
any
type
of
connectivity,
meaning
that
we
recognize
that
there
is
a
session
between
a
device
and
an
application
core,
and
that
session
was
implicit
in
the
case
of
classical
lp1
networks.
So
all
the
provinces
were
well
known.
There
was
no
really
negotiation,
but
we
figure
that
on
more
diverse
type
of
networks,
then
there
will
be
a
need
for
something
more
and
so
the
architecture
is
preparing
for
that
and
the
Reach
Out
frame
will
prepare
for
that
as
well.
A
As
we
take
that
path,
we
will
have
to
work
on
how
we
identify
the
session,
what
what
kind
of
data
is
maintained
together
with
the
session.
So
that's
also
part
of
the
discussions
that
we
hope
we
will
have
today
and
that
we
have
started
in
an
informal
meeting
between
between
the
usual
to
authors,
but
basically
that
will
be
the
course
subject
of
the
end
of
this
meeting
today.
G
Bob
Moskowitz
I
made
a
comment
on
this
draft
back
when
I
think
this.
This
version
came
out
that
the
security
section
is
incomplete.
It
only
has
security
security
above
transport.
It
does
not
have
security
below
transport,
I.E,
ESP
ipsec,
it's
not
in
there
at
all
and
the
implications
when
security
is
below
transport
and
what
you
do
for
for
within
that
security
envelope
compression
the
higher
levels,
particularly
if
you're
running
a
tunnel
and
the
rest
of
that
that
is
not
in
the
architecture
and
should
be
added
to
the
architecture.
Sure.
A
At
the
same
time
that
we
ex,
we
discover
the
fact
that
we
are
not
working
on
a
closed
link
like
loja
or
sigfox
and
we
go
over
full.
Then
we
need
to
to
look
at
all
this
before
that
it
was
the
layer,
2
security.
It
was
just
a
direct
layer
of
two
connectivity.
So
again
it
was
all
implicit
and
and
now
we
have
to
make
it
explicit
and
we
have
to
discuss
it.
A
A
B
Okay,
so
thank
you.
Thank
you.
Thank
you
Bob,
and
we
will
have
a
new
work
presented
today
or
some
convergence,
so
this
is
where
we
will
be
entering
the
discussion
about
the
rechartering,
so
Pascal
you
can
lead
the
discussion
we'll
try
to
have
it
like.
We
have
a
15
minutes,
I
think
to
to
assign
this
one.
A
So
I
think
a
chair
that
it's
really
time
that
we
work
on
this
free
chart
ring
and
we
start
proposing
text
to
to
the
ad.
If
you
don't
mind
the
rig
and
the
the
the
subjects
that
are
that
are
listed
here
are
basically
you
know,
taking
the
the
the
feel
of
the
group,
whether
we
want
to
work
on
those
items.
So
these
are
the
items
that
we
have
kind
of
found.
A
We
could
be
working
on
first
one
is
so,
please
feel
free
to
come
to
the
mic
and
say:
oh,
we
can't
work
on
this
or
yes,
I
would
like
to
work
on
that
or
just
raise
sales.
Maybe
we
can
do
some
sure,
for
instance,
if
people
are
interested
in
subjects
if
you
can
rapidly
go
through,
for
instance,
so
first
thing
is,
as
you
know,
we
are
chartered
for
four
Technologies.
A
One
of
them
is
actually
being
processed
a
different
group,
because
careless
work
is
done
at
six
low
on
15
4.
and
the
other
Technologies
we
have
done
at
home.
Now
we
discovered
a
lot
of
new
fools.
There
is
PPP.
We
tried
to
to
push
the
work
on
PPP
at
the
interior,
but
the
skills
and
interests
were
not
there.
So
probably
would
like
to
to
take
it
back
here.
A
H
A
C
H
So
as
much
as
I
support
the
the
work
of
these
topics.
I
wonder
if
this
recharging
should
also
consider
changing
the
name
of
the
group
or
the
scope
so
that
it's
clear
that
it's
not
focusing
only
on
lp1
or
if,
if
what?
What
is
to
do
because
Chic
is
definitely
a
generic
technology
that
can
be
applied
over
multiple
areas,
it
was
created
with
the
purpose
of
lp1.
A
D
Yeah
I
mean
what
you
propose.
One
callous
is
indeed
logical
and
sensible.
The
only
thing
if
I
remember
correctly,
another
working
group
wanted
to
change
its
name
as
well.
That
was
no
way
right.
It's
simply
a
tooling
system
in
data
tracker
that
makes
things
complex,
so
I
can
ask
again,
but
in
it
is
normal
lp1,
so
we
should
create
the
sheet
Group,
which
is
kind
of
cool
as
well,
but
that.
A
Would
be
neat
yes,
so
second
item
is:
is
fake
fragment,
so
this
one
does
not
really
take
re-chartering.
It's
about
providing
a
new
method
within
chic
for
handling
fragments
loss
and
basically,
instead
of
doing
an
arc
or
Knack
type
of
arq
Technology,
we
would
use
for
their
correction
instead,
meaning
that
we
sent
more
bits
than
we
need
to
in
case
some
of
them
are
lost.
So
that's
that
item
we
can
take
within
the
current
Charter.
A
A
G
I'll
just
make
a
quick
report
of
that
we
did
get
the
the
int
area
chair
and
interior
A.D
interesting
that
we
had
the
same
ad
has
agreed
to
expand
beyond
that.
They
accepted
my
my
proposal
for
a
protocol
number
for
awesome
ether
type
and
for
a
of
UDP
Port,
udb
Port
is
actually
transport
area
and
the
80
over
there
David
black
says
that
it's
fairly
straightforward
in
the
wording.
He
doesn't
see
that
and
if
we
word
it
properly,
they'll
just
go
through
straight
through
for
The
Ether
type.
G
We
are
the
ram
lats.
There
is
a
new
draft
coming
out
for
how
to
interact
between
ITF
and
IEEE,
and
we
will
be
the
ones
who
will
figure
out
whether
it's
just
so
that
they
got
that
right
or
it
needs
more
work.
So
for
those
who
have
been
working
with
me,
who
want
it
as
an
ether
type
I,
don't
want
it
as
an
ether
type
but
I'm
willing
to
do
the
work.
For
that
we're
going
to
be
the
lab
rats
for
that
liaison
between
ietf
and
IEEE.
Yes,.
A
And
we
thank
donix
East
Lake
was
proposed
to
help
us
on
that
and
writing
this
document,
and
a
number
of
us
are
participating
to
the
IEEE
ITF
coordination
meeting
and
so
we'll
raise
that
question
at
the
coordination
meeting
as
well.
So
we
need
to
talk
to
Russell
I.
Think
he's
already
aware
that
we
probably
need
to
just
ping
him
to
say
Hey.
You
would
like
this
topic
at
the
next
IEEE
coordination
meeting.
A
There
comes
as
a
natural
extension
to
that
work.
I
mean
having
a
protocol
type
is
good.
We
did
a
protocol
either
to
go
with
it
and
we
probably
need
to
figure
if
this
is
always
seen
as
nepalier
protocol
or
if
there
are
cases
for
making
it
a
IPv6
extension
header
as
well.
I
was
kind
of
the
only
one
on
the
mailing
list,
trying
to
say
hey.
We
might
need
it
as
an
extension
header
as
well.
A
A
I
So
for
to
have
a
protocol
number
of
the
advantage
is
that
it
can
work
on
ipv4
and
IPv6.
If
we
have
an
extension
either
it
will
work
only
on
IPv6,
but
if
now
we
have
a
port
number,
so
I
think
we
don't
have
any
more
problem
of
interpretability
between
these
two
version.
Fip
and
we
can
go
on
extension
for
IPv6
and
CIP
before
we'll
use,
UDP
and
Port,
which
so.
G
G
Extension
headers
for
this.
They
are
very
much
for
the
protocol
number,
but
you'd
have
to
go
back
in
the
archive
to
see
all
the
points
they
raised
up
against
extensions
header,
and
it
would
have
to
be
somebody
here
who
knows
an
awful
lot
more
than
me
about
this
area,
to
try
to
to
bring
it
up
again
in
interior.
D
It's
irrigating
again,
so
we
can
discuss
here
right,
I
have
no
problem
with
it,
but
it's
interior
draft,
but
it
will
be
adopted
shortly.
Yeah
right
as
soon
as
Bob
will
add
the
text
for
the
UDP
port
and
data
type,
even
a
couple
of
link.
It
will
mostly
be
adopted
in
Terraria.
So
please
comment
on
this
interior.
A
Yeah
we
we
need
to
figure
out
if
we
want
it
inside
before
we
bother
anybody
I
guess,
but
if
we
could
do
a
quick
round
on
the
mailing
list,
just
to
figure
whether
I
want
it.
If
we
want
it,
we
need
to
discuss
with
interior.
Maybe
they
say
yes,
they
say
no,
but
we
don't
even
know
if
we
want
it
before
we
buy
our
Interior.
G
A
D
A
A
A
G
I'm
being
naive,
but
the
the
Chic
header
that
I
might
carry
over
was
Sheikh
being
the
protocol
number
will
quite
depend
on
the
particular
use
case,
whether
that
header
basically
doesn't
really
even
exist.
I've
just
said
this
that
the
rule
tells
you
what
it
is
or
I
have
to
have
some
sort
of
compressed
content.
So
I
don't
think
that
there's
any
work
to
do
around
that
you
already
have
the
basic
concept
and
it
is
basically
going
to
be
on
a
a
usage
case
basis.
C
A
A
B
A
What
we
would
Define
probably
is
the
list
of
things
that,
in
the
worst
case,
must
be
passed
and
how
you
pass
only
what
you
need
to
pass,
depending
on
the
use
case
boiling
down
to
zero.
If
you
need
nothing
and
probably
the
right
way
of
saying
that
of
other
way,
here
is
sick
again
right,
it's
the
rest.
Simplicity
is
compressed,
but
it's
the
same
header
which
can
be
fully
compressed.
So
that's
how
I
figure
out
OEM
is.
We
have
started
the
work
that
was
interest.
A
We
saw
that
the
student
trust,
but
we
don't
have
a
charter
item
for
it.
So
it's
kind
of
an
obvious
Charter
attempt
for
us
session
setup
that
one
is
a
big
one
as
soon
as
we
are
not
anymore
in
a
completely
controlled
loja
environments
or
type
a
stick,
facts
environment.
Where
we
program
both
ends
manually
Etc,
then
there
is
a
need
for
a
device
and
an
application
to
agree
on
a
set
of
rules,
make
sure
that
they
download
the
same
set
of
rows
that
it
is
protected
against
impersonation
or
any
episodes
of
attacks.
A
B
Yes,
and
so
I
I
just
wanted
to
to
add
a
point
here
throughout
the
the
lifetime
of
the
different
drafts
that
became
rfcs.
We
got
a
lot
oftentimes
to
get
reviews
from
the
iesg
and
they
were
asking
okay.
How
are
what
about
you
know
setting
up
these
rules?
How
are
you
going
to
like
all
this
that
is
put
here
about
the
session
setup,
rule
Discovery
and
all
that
in
the
security
of
it?
We
had
that
questions
in
the
past,
like
people
from
the
SG
were
asking.
B
How
are
you
going
to
do
that
in
a
generic
setup,
and
we
until
now,
I
was
like
okay?
Well,
we
configure
it's
a
problem
for
later
right
now
we
have
solved
that,
like
we
have
the
shake
the
foundation
and
I
think
it's
really
the
time
to
you
know
we
have
the
the
the
the
background,
the
knowledge,
the
foundation
to
be
actually
able
to
address
these
specific
questions
right
now,
right,
I
think
before
that
it
would
have
been
premature,
it
would
have
been
trying
to
solve
it.
B
B
Yes,
and
and
about
the
the
Yang,
the
optimizations
for
for
core
conf,
so
Luhan
is
going
to
be
talking
also
about
this,
but
that's
that's
really
important,
like
core
confidence,
advancing
really
well
at
at
the
core
working
group
and
the
way
both
are
going
to
be
working
together.
That's
also
an
important
Point.
I
A
We
don't
need
to
reach
out,
for
that
I
mean
that's
missing
in
our
existing
architecture
and
then
Bob
mentioned
it.
So
we
we
love,
we
we
need
to
beef
up
the
security
section
of
the
architecture,
but
we
don't
need
to
reach
out
to
for
that.
I
guess.
But
yes,
I
mean
it's
an
obvious
I
mean
nothing
would
pass
without
it
and
certainly.
G
With
regard
to
the
negotiation
of
the
street
group,
functions
for
the
rule
between
parties
I'll
point
out
that
Daniel
Miguel
already
has
a
draft
for
for
running
over
Ike
for
how
to
compress
ESP.
So
that
is
a
good
starting
point.
Taking
Daniel's
draft
and
my
highly
biased
opinion
is
that
we
only
want
to
do
this
over
a
peer-to-peer
control,
a
secure
control
Channel,
not
a
client
server,
which
pretty
much
limits
us
to
Ike
and
hip
as
the
only
two
peer-to-peer
secure
control
channels
here.
G
I
have
had
comments
that
maybe
TLS
kind
of
can
be
tricked
into
this.
Thus
maybe
dtls,
but
it
is
problematic
unless
you
really
know
who's.
So
when
we
get
into
this
draft,
there's
going
to
be
the
basic
question:
is
it
only
a
peer-to-peer,
a
control
Channel
or
can
it
be
also
client
server,
control,
Channel,
and
that's
one
that
we're
going
to
have
to
look
into,
and
also
talk
to
other
security
people?
To
answer
that
question.
A
B
So
I
I,
that's
actually
a
very,
very
good
point.
Bob
and
the
point
here
is
also,
for
example,
coreconf.
It's
working
in
a
client
server
way
and
typically
is
the
same
thing.
So
typically
you
can
have.
If
you
have
a
peer-to-peer
relation,
you
can
have
both
peers
to
have
both
the
server
and
the
client.
So
they
can
have
this,
like
peering
yeah,
to
be
like
peer-to-peer.
G
A
B
I
C
A
C
D
C
F
F
So
well,
hello,
I'm,
Sergio
Aguilar
from
UPC
I'm,
going
to
present
the
the
update
on
the
work
that
I've
been
we've
been
working
on
on
the
check
convergence
profile.
This
is
an
update
from
previous
entry
and
meeting
presentation.
We
did
the
individual
submission
of
the
of
the
draft.
We
added
motivation
and
use
cases
and
well.
We
also
had
the
the
comparison
between
Chicago
one
and
Chicora
sigfox
opening
aquanero
mode.
In
this
case
the
comparison
was
already
discussed
in
the
in
the
interim
presentation,
but
we
added
to
the
to
the
draft
next
slide.
F
Please
I
go
into
that
to
the
motivation.
Well,
we
see
that
iot
applications
normally
I
are
tired
to
to
the
lp1
technology.
They
choose
this
lp1
lp1
technology
constraints
are
influence.
The
design
of
the
iot
application
itself
does.
Therefore,
when
you
try
to
migrate
from
one
lp1
technology
to
another,
you
probably
need
to
redesign
a
complete
solution
from
a
device
code
to
to
backend
code.
So,
from
our
point
of
view,
the
lp1
should
be
as
an
L2
layer
should
be
transparent
to
the
application
as
it
is
in
the
IAP
domain.
F
Next
slide,
what
we
see
in
currency
implementation,
we
see
that
we
have
a
single
compression,
the
compression
sub
layer,
but
we
see
that
we
have
multiple,
cheek
fragmentation,
reassembly
sub
layers.
Actually
we
have
one
draft
pair
lp1
technology,
but
once
you
analyze
the
different
modes,
there
are
actually
really
similar
fermentation
modes.
Therefore,
we
we
think
that
to
reduce
code,
complexity
and
maintenance
will
be
better
to
have
a
single
convergent,
cheek
fragmentation
and
reassembly
Supply.
F
Here
we
see
Korean
architecture
that
we
have.
In
this
case
we
have
multiple
implementation
of
the
cheek
fermentation
supplier,
it's
better
technology
that
that
is
being
used
in
in
this
case.
Well,
you
can
actually
send
chick
fragments
in
different
lp1
Technologies,
but
you
are
not
able
well
check
packets,
I'm,
sorry
between
different
lp1
Technologies,
but
you
need
to
have
the
different
codes
to
to
be
able
to
to
manage
them.
F
In
in
the
case,
we
have
a
single
cheek
fermentation,
reassemblyism
layer.
We
will
have,
we
call
it
Chic
overall
profile
that
in
this
case,
will
be
the
same
regardless
or
of
of
the
lp1
technology.
In
this
case,
you
can
actually
receive
cheek
fragments
through
different
networks
and
actually
reassemble
the
packet
at
the
at
the
check,
reassembly
layer.
F
True,
the
use
cases
that
we
have
identified
are
for
multi-radio
devices
devices
that
Implement
more
than
one
lp1
radio.
We
also
saw
multi-network
applications
in
this
case
our
applications
that
are
used
over
several
LP
or
more
than
one
lp1
technology
from
there.
We
also
see
a
use
case
that
this
can
be
a
generic
fragmentation
reassembly
profile.
F
If
you
want
to
test
it
over
a
new
technology
like
to
have
a
an
out
of
the
box
fragmentation
reassembly
mode,
oh
yeah,
we
also
see
use
cases
in
network
redundancy
where
you
can
use
another
lp1
Network
as
backup
you
can
send
the
same,
fragment
or
different
cheek
fragments
through
different
networks,
to
increase
the
probability
of
success.
For
example,
you
can
also
increase
the
device
to
recycle,
as
the
device
has
more
networks
to
send.
F
You
can
use
another
network
instead
of
the
one
that
you
are
waiting
for
the
duty
cycle
time
and
you
can
also
check
coverage
of
one
network
sending
messages
in
one
network
receiving
the
app
in
other
networks
or
you're
able
to
see.
If
you
have
coverage
of
of
any
lp1
network
that
that
you
have
here,
we
we
propose
to
to
simplify
the
access
to
the
rules
like
this
to
converge,
all
the
devices
IDs
into
a
single
chick
ID.
F
F
We
we
said
that
this
can
be
done
through
a
table
that
actually
Maps
the
networks,
devices
ID
to
the
chick
ID,
and
then
we
can
go
on
and
find
the
rules
this
table
can
be
actually
extended
to
have
IP
addresses
IP
ports
to
identify
the
packets
that
are
also
arriving
from
from
the
internet
approaches
in
this
case
the
the
comparison
that
we
did
about
opening
fragmentation.
We
actually
evaluated
that
Chico,
where
Laura
one
draft
with
well
a
standard
with
the
chick
over
the
sigfox
option.
F
F
Foreign.
Therefore,
we
see
that
that,
since
there
is
a
lot
of
similarities,
we
can
actually
converge
both
profiles
with
a
rule
ID
of
8
Bits,
for
example,
and
in
this
case
we
chose
to
have
more
windows
than
more
tiles
per
window,
since
we
can
have
more
opportunities
to
to
actually
send
the
ACT
to
the
device.
Now,
with
the
compound
nag,
you
can
actually
send
and
a
larger
Arc
if
needed.
F
Therefore,
you
can
have,
for
example,
if,
before
you
have
a
larger
window
now
you
can
have
the
same
amount
of
information
in
the
in
the
compound
neck
as
as
before.
Next
and
finally,
well,
we
for
for
this
draft,
we
plan
to
to
do
a
new,
open
source
project.
In
this
case,
we
call
it
chigduino.
The
idea
is
to
implement
chick
over
for
Arduino.
We
think
that
this
can
help
actually
the
adoption
of
chick,
in
a
larger
extent,
with
a
single
code
code
base.
F
In
this
case
this
this
convergent
profile,
you
can
only
have
to
manage
as
a
one
code,
and
this
can
simplify
applications
that
want
to
migrate
between
LP
ones
for
multi-network
applications.
For
example,
you
have
a
application
already.
Well,
you
are
building
the
application
for
for
an
lp1
you're
using
cheek.
Then
you
can
migrate
the
application
to
another
P1,
let's
say
You
by
Chain,
not
changing
the
application
code,
but
by
changing
the
network
connector
at
the
end,
that
is,
between
the
cheek
and
the
network,
but
you
will
have
the
same
code.
F
F
C
F
I
Yes,
thank
you
for
this
initiative.
It's
very
interesting
to
to
have
different
implementation
of
chic
for
interoperability,
but
I
was
wondering
more
for
very
constrained
devices.
If
we
need
really
to
do
compression
decompress
compression
on
the
device
and
not
manipulate
directly
the
sheet
rules,
which
makes
that
the
code
will
be
lighter,
you
just
have
to
generate
things.
For
example,
Co-op
can
be
done
in
in
shoe
line
of
code
because
you
just
send
the
residues,
and
so
this
way
you
can
have
something
very
Compact
and
that's
why.
I
A
F
Yes,
actually,
the
idea
of
having
the
out
of
the
box
cheek
profile
is
to
to
enable
that
that
kind
of
interoperability
that
you
can
actually
test
it
over
any
kind
of
of
network.
And
this
way
you
have
like
already
a
a
profile
that
has
been
tested,
actually
that
we've
been
working
on
it
since
a
while
both
Laura
one
and
six
folks.
Now
that
the
conversion
of
both
it's
already
been
tested
in
a
sense,
so
yeah
I
think
that
this
this
profile
can
help
actually
help
over
other
other
radio.
F
Has
to
be
an
adaptation
in
in
between
the
fragmentation,
layer
and
the
actual
Network.
That's
been
sent
I
added
a
section
in
the
draft
that
is
called
downlink
considerations
that
that's,
where
I
see
that
we
have
to
take
that
the
actual
considerations
of
each
technology,
for
example,
is
different
to
send.
Well,
it's
really
similar
in
order
one
and
six
folks.
Let's
say
you
have
to
send
first
the
message
to
receive
a
down
link,
but
maybe
in
other
technology
you
can
receive
the
downlink
directly.
C
G
There
some
aggressive
examples
of
those
full
Technologies
consider
802.16
h.11ah,
but
long
range
and
high
capacity
usage.
So
the
frames
are
not
so
small
but
there's
just
potentially
so
much
traffic
that
the
the
the
driver
for
Chic
is
to
reduce
collisions
because
of
the
the
capacity
usage.
So
that
would
be
the
example
of
the
of
the
the
foo
use
case.
F
B
B
If
you
want
to
carry
the
convergence
profile
like
to
say,
okay
well,
I
have
this
a
set
of
of
rules
which
are
like
Universal
and
I
can
at
least
bootstrap
my
communication
over
that
right,
so
I
feel
that
your
work
gets
in
the
in
that
in
that
direction
right.
The
points
I'm
I'm,
not
sure,
is
how
it's
going
to
be
working,
because
there
is
already
the
Laura
one
profile
out
there.
D
B
That
they're
different,
so
I'll
need
I
mean
we'll
need
to
figure
out.
So
today
you
have
like
a
lower
one
device
and
you
will
know
the
shake
profile
to
that
device.
Just
because
it's
lower
one-
and
you
know:
okay,
it's
RFC
19911
right.
So
then
we'll
need
to
distinguish.
Maybe
okay,
there
is
the
RFC
9011
and
there
is
maybe
this
convergence
profile.
So
there
is
this
thing
of
how
would
that
work
and
and
how
you
apply
your
work
to
to
the
Chic
over
Foo
right,
so
I
think
maybe
during
the
rechargering
we'll
need.
B
You
will
need
to
look
at
your
draft
through
that
angle,
right,
okay,
how
does
it
enter
in
the
new
Charter
items
and
to
see
what
will
be
the
require
I
mean?
Does
it
fit
there?
What
what's
the
requirement
on
that
convergence
profile
there?
So
I'm
I,
don't
have
an
answer
to
that.
I
find
your
work.
Super
interesting
and
I
think
that
there
is
a
big
potential
in
that
in
that
aspect
right,
but
we
will
need
to
to
look
exactly.
You
know
how
how
will
how
it
will
evolve.
C
F
F
You
have
to
have
a
device
ID
there
that
with
a
single
device
ID,
you
are
able
to
come
to
know
which
rules
you
go
and
then
you
will
be
able
to
let's
say,
identify
that
packet
at
that
session,
the
instance
of
that
packet
or
that
fragment
I
will
say
so
you
will
be
able
to
to
complete
the
the
packet
the
cheap
packet
I.
Don't
know
if
I
made
myself
clear
so
yeah.
The
idea
actually
is
that
you
can
send
a
fragment
through
any
network.
F
F
B
Just
one
question
on
what
you
said:
probably
a
more
interesting
or
applicable
thing
would
be
if
you
have
both
Technologies
and
two
technologies
or
some
kind
of
network
coding,
so
you
can
send
the
same
fragment
on
two
networks.
Technologies
and
you
know,
because
you're
having
the
same
parameters,
you
don't
care
which
one
goes
through
right,
but
I
think
we
need
to
look
at
your
draft
as
well
from
the
point
of
view
of
this
session
establishment
thing
right.
So
yes,
it's
good
thing
about
401,
it's
good
thing
about
sick
Fox.
B
B
A
B
A
C
E
E
So
what
we
did
is
Yvonne
and
Lohan
worked
mostly
then
worked
on
cleaning
up
the
open,
cheek
GitHub,
repo
emerging
branches,
cleaning
up
Etc.
We
had
the
Contour
over
there
developing
a
clean
slate
implementation
using
micro
passion.
If
you
remember,
we
originally
said
we
would
use
micro
python
for
embedded
devices
and
then
diverge
to
full
python.
So
now
we
have
another
new
implementation.
In
micro,
python
I
worked
on
the
documentation.
H
E
And
so
we
were
successful
in
exchanging
a
few
compressed
packets
in
both
directions:
UDP
IPv6
compressed
between
open
check
on
one
side
and
right
slip
check
on
the
other
side.
So
not
everything
works
Etc,
but
that's
a
good
start
and
we
also
exchanged.
Now
we
worked
on
but
did
not
complete
that
but
working
on
the
interrupt
between
the
micro
sheet
and
the
open
check,
implementations
and
yeah.
What
what
we
learned
is
from
the
Clinton
implementation
content
came
up
with
lots
of
good
questions.
C
E
E
B
We'd,
like
also
to
to
to
to
underline
that
it's
really
amazing
all
the
work
that
everyone
is
doing
at
the
hackathon,
so
there
has
been
a
hackathon
on
Chic
for
since
I,
don't
know
how
many
years
I
think
for
Five
Years
on
every
hackathon
and
and
that's
really
an
amazing
thing
to
have
like
the
running
code
and
right
now
we
see
all
these
implementations
coming.
So
it's
really
an
amazing
work.
So
we'd
like
to
really
really
thank
the
all
participants
in
the
hackathon.
B
A
So
we
we
actually
consciously
let
this
discussion
fly
a
little
bit
longer
than
initially
in
the
agenda,
because
we
thought
that
the
discussion
on
the
convergence
was
really
really
good
and
and
constructive.
We
still
have
half
an
hour
on
the
architecture
proposal.
It
doesn't
work,
no
also
right,
and
so
there
we
go
it's
a
bit
less
than
we
thought,
but
you
have
one
alpha
or
two.
I
Okay,
so
I
I,
don't
know
I,
don't
think
I
will
have
Alpha
network,
but
we
we
can
have
discussion
on
that,
because
also
I
will
summarize
what
we
say
yesterday
in
a
side
meeting
like
if
you
want
in
the
same,
we
think
about
Sheikh
and
what
has
been
done
and
all
the
good
question
you
are.
We
were
we
got
when
we
published
The
Young
data
model
and
specially
about
security.
I
I
So
here
we
let
people
to
implement
Chic
as
they
want.
We
just
focus
on
the
interoperability
and
this
Enterprise.
If
we
go
to
some
constraint,
Network
should
use
kokov,
because
here
we
have
a
compact
way
to
represent
the
information
we
we
want
to
exchange.
So
from
that,
we
add
good
question
when
we
about
the
young,
modern
security.
So
we
had
good
question
during
the
the
review
of
the
document.
So
next
slides,
please
and
one
other
question-
was
how
to
protect
element
of
the
rule.
I
To
avoid
that,
someone
can
modify
some
some
element
in
the
root
Rule
and
it's
not.
It
was
not
allowed
to
do
that.
So
the
first
reflection
we
we
had
is
that
in
our
views-
and
maybe
we
are
wrong-
we
have-
we
are
not
full
Specialists
of
of
young-
is
that
currently
you
have
some
protections
that
are
given
in
young
to
access
to
a
specific
field,
so
here,
for
example,
we
have
an
abstract
representation
of
the
of
the
rule.
I
So
each
field
will
have
a
specific
ID
in
young
which
will
be
on
URL
or
if
we
are
going
to
go
conf,
it
will
be
a
number.
So
all
these
ID
will
have
the
same
all
these
columns.
We
have
the
same
ID,
which
has
some
ID
or
the
same
number,
and
so
what
we
can
do
right
now
in
protecting,
even
in
writing
in
a
model
that
we
can
say
that
a
column
is
right,
only
or
read
and
write
or
with
the
viewer
model.
I
think
it's
cacm.
I
We
can
add
to
this
list
some
property
and
say
this
guy
can
modify
this
line
and
this
guy
is
not
a
lot.
But
when
we
look
at
what
we
want
to
do
with
Chic,
it's
with
something
more
precise
because,
for
example,
we
can
have
a
can
imagine
an
attack
where
someone
take
control
of
the
device
and
send
a
management
request
to
the
core
and
say
change.
This
parameter,
for
example,
change
my
destination
address,
because
this
way
I
will
do
a
DDOS
on
the
specific
site.
I
I
So
we
have
to
to
protect
that
and
to
do
this
protection
is
not
something
that
is
in
columns,
but
we
need
to
have
access
to
one
field
and
say,
for
example,
if
we
want
to
change
the
source
address
right,
it
means
that
we
need
that
the
id1
is
Source
address
and
this
element
is
only
write
only
on
cannot
be
modified
by
the
device.
So
it
means
that
here
we
have
to
get
an
effort
to
improve
augment
the
access
control
that
we
have
already
in
young.
I
Maybe
we
are
wrong,
but
if
the
case,
then
you
can
contact
us
to
to
say
so.
That's
the
first
point,
so
the
next
Point
next
slide.
Please.
So
here
is
resume.
What
I
say
so
first
thing
is
that
we,
but
we
saw
that
it's
not
enough.
We
have
to
say
that
a
device
can
only
manipulate
its
own
information
and
cannot
change
the
information
of
other
devices
in
a
car.
So
this
can
be
done,
for
example,
with.
It
must
be
explicit
in
what
we
wrote.
C
D
C
B
Just
just
one
one
point
here
and
I
think
that's.
That
was
a
very
interesting,
let's
say
Discovery.
The
point
here
is
that
we
can
have
the
we
want
to
have
basically
the
same
level
of
security
as
if
the
device
is
running
the
full
IP
stack
natively.
So
if
someone
goes
and
compromises
the
device,
this
is
the
only
thing
that
gets
compromised
so
that
that's
that's
the
idea
right
and
the
point
is
that
so
what
lahoe
is
saying
is
right.
B
Now
we
are
talking
about
having
more
dynamicity,
you
know
having
the
session
setup,
updating
the
rules
and
all
that
which
is
really
necessary
for
to
get
the
full
power
of
the
of
the
shake
technology.
But
the
point
is
that
if
the
device
gets
compromised,
you
could
imagine
that
the
device
can
push
some
rules
to
the
to
the
core
Network
to
the
application,
and
these
rules
can
actually
match.
B
For
example,
any
packet
that's
coming
from
the
internet,
so
you
can,
it
can
divert,
let's
say
all
the
the
information
that
could
come
to
the
core
Network
and
it
can
get
all
that
information
by
just
modifying
its
own
rules
right
and
then
that
that's
a
problem.
So
that's
something
that
we
don't
want
to
to
to
allow,
and
this
is
something
that
we'll
need
to
describe
like
the
the
types
of
threads
that
that
can
that
can
arise.
So
we
need
to
Define
that,
and
we
need
to
add
this.
B
A
A
We
have
understood
clarified
that
Sheikh
operates
between
two
devices
and
there
is
a
form
of
session
that
happens
between
those
two
devices
and
during
this
discussion,
let's,
in
my
view,
appeared
is
that
you
need
to
identify
the
session
before
you
start
applying
the
rules,
because
that's
the
session,
which
will
tell
you
which
rules
there
are,
if
you
do
it
in
the
wrong
order,
a
new
match
based
on
some
rules
you
have,
and
then
you
think,
oh,
that
must
be
the
session.
Then
you
might
have
this
sort
of
attack
coming
in.
A
If
you
identify
the
session
say
for
five
Topo,
which
basically
says
this
Source
this
destination
packet
coming
from
the
internet,
to
the
compressor
will
match
this
session,
then
only
packets
to
that
destination
which
match
these
are
called,
is
this
filter
will
be
passed
through
the
the
rules,
meaning
that
there
is
no
way
through
check
to
intercept
the
whole
internet
to
your
point?
Okay,
so
so
we,
the
architecture,
is
missing
text
on
how
you
identify
the
session.
A
We
are
kind
of
clear
for
the
most
peace
when
the
packet
arrives
in
the
compressed
form,
but
when
the
packets
arrives
from
the
internet
to
the
compressor,
we
need
to
be
very
specific
that
first,
you
must
isolate
the
session
say
from
the
five
Topo
and
what
can
whatever
filter
and
then
once
you
have
isolated
the
session,
then
you're
within
the
small
world
of
the
target
device.
That's
when
you
look
at
these
rules.
I
Okay,
yes,
so
something
that
is
very
important
because
for
the
moment,
if
we
don't
do
that,
for
example,
we
can
use
the
floor
label
as
a
way
to
select
different
devices
that
will
share
the
same
IPv6
address
and
we
don't
want
that.
We
want
to
keep
what
is
used
on
on
the
internet,
so
we
don't
want
to
to
add
new
feature
but
very
be
very
close
to
the
IP
model.
So
the
the
other
element
is,
but
it's
more.
Something
that
has
to
describe
in
the
architecture.
I
Architecture
document
is
how
we
install
risk
management
between
two
devices
so
ever
to
get
all
the
rules
to
modify
partially
in
a
rule
on
in
both
the
buff
directions.
So
we
have
different
scenario:
for
example,
a
device
arrive
and
ask
for
its
rules
or
ask
for
certain
parameters
on
the
rule
or
push
the
rule
in
the
core
and
set
up
some
parameters
in
in
the
core.
So
we
have
all
the
these
things.
I
I
Next
point.
Please.
So
here
is
the
last
one.
So
it's
start
from
a
discussion
with
what
colors
pushing
some
interim
meetings
and
we
add
a
lot
of
the
description
on
that
and
now
I
think
the
model
is
a
little
bit
more
clear
and
Sergio
add,
or
maybe
new
arrowsing
in
in
this.
But
in
fact,
when
we
we
are
based
at
the
beginning
of
the
group
on
lp1
architecture,
it
means
that
we
have
a
start.
Apology
on
this
was
quite
easy
to
to
manipulate,
because
we
have
a
central
point.
I
I
The
thing
is
that
you
can
have
several
core,
but
we
have
also
some
dependency
and
we
have
a
kind
of
circle
dependency,
as
it
is
shown
on
this
graphic
because,
for
example,
if
you
say
a
is
a
device
and
B
is
a
core,
then
C
will
have
problem
because
c
will
be
act
as
a
device
or
a
core
for
the
other
one.
So
we
cannot
say
in
a
mesh
Network
that
some
elements
are
core
on.
Some
elements
are
devices,
but
it
depends
really
of
the
the
context
or
what
you
you
call
the
the
session.
I
Of
instance,
so
here
we
represent
that
in
this
schema,
so
you
you
have,
of
course
this
circle
this
dependencies,
but
we
have
also
some
elements
that
can
be
both
core
and
device
at
the
same
time
regarding
the
rule,
so
the
only
constraint
we
we
haven't
has
been
published
in
events
drafts
is
that
we
need
to.
If
we
have
this
case
with
the
two
red
arrows,
then
we
cannot
share
the
same
rule
ID
on
both
sessions.
I
So
now,
but
it's
a
little
bit
more
clear
for
for
us.
So
we
have
to
implement
that
in
the
architecture
document
and
Define
this
notion
of
session,
or
instance
that
will
ever
be
static.
It
means
that
it
depends
only
on
information
on
the
rules
or
can
be
dynamic,
and
then
we
will
have
to
develop
a
protocol
for
our
tier.
I
A
tie
breaker
to
find
with
with
the
device
with
the
core
with
some
problem
is
that,
for
example,
if
you
look
at
the
MAC
address
for
some
time,
not
be
something
enough,
because
you
need
to
have
a
server
or
client
and
the
role
doesn't
depend
on
the
Mac
address.
So
here
we
have
to
be
very,
very
careful
for
doing
that
and
we
have
to
to
look
at
solution
in
the
architecture
document.
A
So
the
exact
language
in
the
architecture
document
at
this
point
is
that
shake
defines
a
session.
So
that's
the
lowercase
session.
It's
just
a
word,
meaning
that
there
is
this
relationship
between
two
nodes
and
we
give
it
a
name.
We
call
it
the
Chic
instance.
That's
why
you
see
instances
in
that
slide.
A
So
that's
the
name
we
give
to
to
that
session
between
a
device
and
an
application,
and
we
say
that
there
are
a
number
of
cases
that
we
list
where
the
session
identification
is
implicit
and
the
parameters
are
implicit
as
well
and
know
how
and
six
blocks.
No,
it's
clearly
the
case.
There
is
no
session
negotiation.
There
is
never
a
need
to
say
which
session
between
you
and
me
there
is
only
one
and
which
is
the
role
there.
Is
anyone
set
Etc?
A
Everything
is
pre-programmed
coded,
so
there
is
no
negotiation
at
all
and
no
social
notification.
Apart
from
you
know,
the
Gateway
looks
at
which
Laura
device
it
comes
from
or
something,
and
that
gives
him
a
session
for
a
Bluetooth
low
energy.
Where
you
have
a
central,
node
and
peripheral
node,
then
same
thing,
I
mean
the
central
node.
Is
the
server
and
and
that's
it
so
there
are
a
lot
of
cases
like
this.
A
Why
it's
implicit
when
we
start
a
transport
like
a
PPP
connection,
we
also
say
hey
the
guy
who
starts
the
PPP
connection
is
the
device.
So
it's
also
implicit
the
other
things
which
might
not
be
implicit
that
the
need
for
this
header,
but
at
least
the
architecture
say
there
are
cases
why
it's
implicit
and
here
is
what
it's
going
to
be,
and
then
there
are
cases
like
the
mesh
where
it
cannot
be
implicit.
There
are
tons
of
reasons
why
it
could
be
either
one
and
from
multiple
instances.
A
It
could
be
not
the
same
like
represented
in
red
here.
In
this
case
effectively,
there
is
a
need
of
a
secure
negotiation
protocol
to
make
sure
both
parties
agree
on
what
is
what
and
we
in
the
architecture
we
don't
go
further
than
that.
We
don't
say
what
that
negotiation
could
be
or
anything
we
leave
it
to
the
further
work
at
the
reach
out
after
reach
out
there.
If
we
reach
out
there
for
that.
A
A
Well,
that's
good
for
the
trains
for
those
who
are
waiting
for
the
trends
then
and
I
know
a
few
of
them
which
will
scramble.
So
we
thank
you
for
staying
to
the
last
minute
at
this
ATF
and
we'll
organize
very
soon.
The
next
round
of
intro
meeting
we
start
producing
text
on
the
recharge
ring,
we'll
see
what
we
can
write
right
away
on
the
architecture
not
match,
but
because
we
need
those
those
work
items
to
progress
before
the
architecture
can
reflect
the
work
of
decisions.