►
From YouTube: IETF102-LWIG-20180720-1150
Description
LWIG meeting session at IETF102
2018/07/20 1150
https://datatracker.ietf.org/meeting/102/proceedings/
A
Please
note
the
note
well
still
applies.
Is
there
anyone
who
hasn't
read
the
note
well
yet
now
so
some
status
update
since
the
last
IDF,
83,
87
or
SC
83
87
was
published
in
May,
so
and
83
80
83
52
was
published
in
April,
so
we
can
part
on
our
backs.
We
we
have
stuff
moving
forward.
We
adopted
also
to
working
group
documents,
so
we
have
the
6lowpan
virtual
reassembly
and
also
the
l,
big
security
protocol.
Comparison.
A
So
we
have
quite
a
packed
agenda.
We
don't
get
paid
to
work
overtime.
So
if
we
finish
early,
that's
the
bonus
we'll
try
to
follow
this
agenda
as
much
as
possible.
One
quick
note
for
presentation,
3,
I,
guess
caution.
We
are
not
going
to
have
any
presentation
on
the
word
should
reassembly,
because
the
draft
is
more
or
less
ready.
We
are
looking
for
feedback
comments,
reviews
and
I
guess
Rahul.
You
promise
that
you
are
implementing
this
in
production
code,
so
you
will
be
giving
some
feedback
on
the
list.
A
A
B
Yeah,
okay,
so
I've
already
presented
this
draft
the
technical
details
of
this
after
more
than
three
times,
maybe
three
times
before
so
this
time,
I'm
going
to
only
give
the
details
about
why
why
we
really
want
to
see
this
going
forward
as
in
what
our
primary
motivations
are
and
some
of
the
updates
that
have
happened
in
the
context
of
this
work,
which
might
also
relate
to
this,
which
has
direct
implications
of
this
work
and
give
the
implementation
status,
of
course.
So
with
regards
to
so
to
set
the
context.
B
So
we
started
working
on
this
issue
because
when
we
try
to
see
that
when
we
try
to
use
1802
to
15.4
networks
and
if
the
node
density
or
if
the,
if
you
are
trying
to
play
with
ten
number
less
number
of
nodes
like,
for
example,
ten
everything
works.
Okay,
but
the
moment
you
try
to
scale
that's
when
all
the
problem
begins.
So
this
is
one
of
the
first
problems
that
we
had
to
solve
to
move
any
further.
B
The
typical
use
case
that
we
had
was,
we
were
using
8,
node,
2
or
15.4
in
sub
gigahertz
mood
and
the
node
density
was
quite
high,
so
it
was.
It
so
happened
that
we
had
hundreds
of
nodes
connecting
on
the
same
hop
and
how
to
manage
the
neighbor
cache
entries
was
particularly
challenging
because
of
certain
because
of
certain
issues.
So
one
of
the
primary
issues
that
we
faced
was
the
neighbor
cache
entry
size
is
very
limited
and
you
have
such
a
huge
node
density
at
a
given
hop.
So
how
do
you?
B
What
are
the
new
occasion,
trees
that
you
that
a
node
should
entertain?
So
the
primary
considerations
are
the
neighbor
cache
entries
which
have
direct
implications
on
the
on
the
routing
stability.
So
if
the
routes
are
stable,
if
the
neighbor
cache
is
stable,
you
have
less
churn
in
the
network.
You
will
have
more
stable
Network,
so
that
was
the
primary
it
for
this
particular
work.
B
So
this
is
the
primary
motivation
to
use
to
work
it
out
to
work
out
the
15.4
sub-q
guards
range
network
on
a
constrained
unconstrained
devices
with
only
one
node
densities,
so
the
primary
purpose
of
the
draft.
What
does
it
rob
do
today?
It
tells
you
what
it?
How
do
you
manage
the
neighbor
cash
entries?
B
There
is
a
reservation
based
policy
that
is
explained
in
the
draft
which
says
that
if
you
have
an
authentication
phase,
you
feel
how
routing
routing
phase
where
the
network
HSN
cesare
getting
established,
and
then
you
ensure
you
have
a
traffic
flow
application
traffic
flow.
So
you
have
to
deal
with
neighbor
k
cash
interest
during
all
these
phases
and
which
are
the
navigation
trees
that
a
node
should
entertain.
B
The
draft
also
specifies
NDP
signaling,
but
it
merely
gives
some
guidelines.
It
is
not
about
actually
standardizing
the
or
making
any
changes
to
the
protocol
formats.
It
also
talks
about
handling,
secured
and
unsecured
entries.
So
before
the
authentication
or
during
the
pre
authentication
phase,
the
unsecured
neighbor
cash
in
trees
have
to
be
managed.
Now
this
is
the
problem
that
even
sixty
she
is
trying
to
solve.
We
are
putting
some
guidelines
in
place
for
this
particular
issue.
B
The
implementation
status
we
want
a
queue
already
has
a
basic
neighborhood
cash
I
mean
neighbor
policy,
neighbor
management
policy
implementation,
but
there
are
many
pitfalls.
There
are
many,
it's
it's,
it's
not
an
implementation
which
can
be
used
in
production
today,
the
primary
problem
being
that
Connecticut
doesn't
have
a
key
management
protocol
as
of
now,
and
it
doesn't
have
any
handling
of
unsecured
in
C's.
So
that
is
something
that
we
have
built
in
our
private
implementation.
We
want
to
eventually
bring
it
back
to
quantity
and
make
it
available.
B
So
one
of
the
things
that
we
have
been
thinking
is
to
make
it
as
an
or
as
an
open
source
library
which
can
be
integrated
with
Riot
kontiki
WIP
in
the
future,
for
example.
So
this
is
so.
We
have
already
started
the
work,
so
we
already
have
a
private
implementation.
Without
this,
without
this
labor
management
policy,
it
was
impossible
for
us
to
scale
to
that
kind
of
network.
So
this
we
also
received
some
feedback
on
the
Wyson
mailing
list.
Regarding
the
same
issue
that
how
do
we
handle
this?
B
How
do
you
handle
this
onion
load
densities?
So
so
this
is
a
problem
that
lot
of
people
are
facing
once
they
start
scaling
the
network
at
the
working
ID.
So
one
of
the
one
of
the
thing
that
the
graph
talks
about
is
most
of
the
most
of
the
guidelines
given
are
you
know
a
reactive
policy?
What
it
means
is
the
neighbor
cash
entries
are
getting
established
and
then,
if
the
table
is
full,
it
gets
a
negative
acknowledgment.
But
what
happens
so?
What
happens
if
a
neighbor
the
evicted
neighbor
keeps
coming
back?
B
There
is
no
way
for
the
neighbor
to
signal
that
in
in
a
message
saying
that
okay
I
don't
have
any
resource
anymore.
Please
don't
come
back
to
me
again,
so
this
is
something
that
this
draft
cannot
have
any
control
over,
because
it
requires
some
changes
to
the
protocol
specification
and
we
believe
that
there
is
some
work
happening
in
this
context,
especially
the
draft
from
Richards
micro
Richardson's,
which
we
feel,
even
though
those
drafts
currently
do
not
have
any
specific
text
in
this
particular
context.
B
We
definitely
think
that
those
particular
drafts,
or
those
particular
that
particular
information
can
be
made
use
of,
even
in
this
case,
to
make
it
proactively
react
to
the
neighbor
cash
shown.
That's
all
we
had
a
good
review
from
Mohit.
We
will
be
changing
and
incorporating
most
of
his
comments
and
we
really
seek
more
implementers
feedback.
That's
all
happy
to
take
any
questions.
A
A
B
C
C
C
So
let's
go
through
the
updates
in
this
last
revision,
so
a
first
set
of
a
date
is
in
the
section
that
focuses
on
ecn.
So
we
have
added
some
details
here
and
we
have
also
rewarded
a
little
bit
the
section.
So
we
now
state
that
ECM
can
be
incrementally
deployed
and
we
provide
a
couple
of
pointers
to
useful
documents
in
this
area.
One
is
RFC
75-67,
which
provides
guidance
on
usage
of
ECM
and
RFC
8087,
which
discusses
benefits
in
terms
of
throughput
delay
and
so
on
of
ecn.
C
Also,
we
stayed
that
the
number
of
TCP
stacks
supporting
ECM
is
increasing
and
then
because
this
en
allows
applying
congestion
control
measures
earlier
than
otherwise
it
helps
decreasing
packet
losses
and
retries.
So
this
is
beneficial
for
constrained
node
networks
in
general,
because
it
helps
avoiding
unnecessary
retrace,
which
means
unnecessary
consumption
of
energy
or
bandwidth
resources,
and
also
it
can
be
useful
in
some
particular
scenarios.
C
Also
for
additional
reasons
like,
for
example,
when
there
is
transactional
traffic
with
small
data
size
and
if
small
windows
are
being
used,
then
it
may
be
difficult
or
even
impossible
to
get
three
duplicate
acknowledgement.
That
means
that
a
packet
loss
will
translate
into
an
RTO
expression,
which
will
just
add
some
latency,
so
using
ECM
may
help
also
avoiding
this
additional
latency
which
might
just
slow
down
the
transfer
and
seralini.
C
So
we
have
also
added
text
in
the
security
consideration
section.
We
have
in
particular
added
text
on
the
so-called
shrew
gos
attacks,
whereby
one
or
more
sources
generate
packets
to
coincide
with
consecutive
retry
atoms
of
a
victim
note
triggered
by
RTO
expiration.
So
in
constrained
networks,
as
mentioned
before,
small
window
sizes
may
be
relatively
frequent
and
therefore
we
may
have
also
relatively
frequent
RTO
explorations,
so
it
means
that
constraint
nodes
might
appear
as
appealing
victims
of
this
kind
of
attack.
So
there
are
some
described
mitigation
techniques
in
the
literature.
C
One
is
RTO
randomization
in
order
to
try
confuse
a
little
bit.
The
the
attackers
by
using
an
unexpected
pattern
of
retries
for
the
moments
of
retries
and
also
another
solution,
is
blocking
the
attack
by
routers,
for
example,
when
there's
incoming
traffic
with
some
pattern
that
might
correlate
with
this
kind
of
attack,
then
the
router
might
just
block
the
attack.
C
Okay,
we
have
also
updated
the
annex
recall.
This
is
the
section
where
we
collect
details
on
disappear
plantations
for
constrain
devices.
First
of
all,
we
have
added
few
introductory
nodes,
such
as
the
the
surveyed
on
in
this
section
is
limited
to
open
source
stacks.
Then
also,
we
state
that
this
is
not
intended
to
be
all-encompassing
and
on
the
other
hand,
we
stayed
that
the
information
contained
here
is
based
on
what
is
available.
C
Basically,
this
is
the
details
that
are
highlighted
in
red
and,
however,
as
explained
in
on
the
mailing
list,
we
have
removed
the
role
that
focuses
provided
or
was
intended
for
memory
requirements
in
terms
of
data
size
because
it
was
getting
difficult
to
obtain
those
numbers.
Nevertheless,
we
have
a
couple
of
interesting
additions
in
this
update,
which
are
highlighted
in
orange
that
basically
for
riot
disappear
plantation.
C
We,
we
were
fortunate
enough
that
Simon
boomer
who's,
the
main
developer
of
the
TCP
implementation
for
riot
made
some
measurements
of
both
Rome
and
Rome
consumption
of
his
TCP
implementation,
and
they
are
both
included
here.
So
for
the
RAM
details,
they
are
included
in
the
table,
caption
part,
and
in
particular
we
have
that
for
that
implementation.
One
TCP
connection
consumes
around
2.5
kilobyte
of
of
RAM
and
then
for
each
additional
connection.
It
one
will
consume
one
that
two
kilobytes.
C
B
C
B
What
is
mentioned
in
the
draft
as
well
yeah
and
it
is
not
really
possible
to
have
a
bsd-style
socket
interface
on
whatever
micro
IP
really
provides.
So
I
am
wondering
more
where
that
information
came
from
and
it's
mentioned
in
red.
So
why
is
it
in
red
now?
It's
it
red,
because
it's
other
now
I
did
now.
Okay,
okay,
I,
think
that
information
is
incorrect.
I
believe.
C
Okay,
so
we
will
double
check
thanks
for
that.
It
is
based
on
the
information
we
have,
which
is
quite
quite
limited,
actually
for
open
vm,
especially
it
appeared
that
there
was
that
kind
of
support,
but
we
can
double
check
and
maybe
keep
in
touch
with
you
to
make
sure
we
have
the
right
information
here.
Okay,.
B
And
the
draft
right
now
I
mean
again.
The
second
question
would
be
the
top
right.
Note
says
that
WSN
open
wsn
is
a
directive,
has
a
direct
implementation
of
micro
IP
in
its
stack.
So
my
question
is:
is
it
really
needed
to
then
basically
how
to
open
this
in
this
table
yeah?
It
basically
adds
no
value
I.
As
far
as
I
see
yeah.
C
D
Yes,
thank
you
for
doing
this.
I
think
this
usual
work,
but
I
think
it
still
in
parts.
It
requires
some
work,
so
it
needs
to
be.
For
example,
it
needs
to
be
more
specific.
With
the
turning
of
the
delayed
action
on
back-end
servers,
it
was
mean,
for
example,
in
many
stacks
is
a
system-wide
parameter,
so
you
turn
it
off
for
all
Connexus
yeah,
that's
not
advisable
in
some
stacks.
You
may
be
able
to
do
per
interface,
but
that's
not
even
not
in
half,
because
you
make
communicate
with
other
than
IOT
devices
over
the
same
interface.
D
C
D
A
Probably
you're
already
doing
this
produced
recession.
I
know
some
of
you
are
active
in
different
mailing
list
of
kontiki
prior
to
us
and
so
on.
Could
you
post
this
draft
to
them?
I
think
it
will
make
sense
and
they
would
be
happy
to
provide
more
numbers,
so
I
guess
you
are
active
and
Rahul
is
active
in
some
of
the
the
forums
it
would
be
useful.
Thank.
B
E
E
C
B
C
Or
any
No,
however
yeah
we
just
had
some
discussion
a
couple
of
hours
ago.
It
appears
that
ASEAN
might
be
useful,
so
the
current
situation
is
that
no
right
now
it
is
not
being
used.
That
might
be
helpful.
So
maybe
this
was
good
to
at
least
explain
which
can
be
the
benefits
and
then
well.
We
will
see
what
happens
in
the
future.
Thank
you.
F
The
we
moved
it
to
the
usual
working
group,
github
repository
and
just
to
to
give
you
a
quick
update.
What
were
the
goals
of
this
draft
so
what
we
started
it
to
document
the
lessons
that
we
have
learned
so
from
from
implementing
web
and
Lipka
web
and
the
erbium
and
contiki,
and
most
of
this
was
focused
on
class
one
devices.
F
According
to
our
c
72
28
and
a
large
number
of
sections
now
deals
with
the
message,
processing
and
the
handling
and
certain
optimizations
that
you
can
do
for
checking
of
sequence,
numbers
and
deduplication
and
so
on,
and
we've
also
covered
the
core
extensions,
for
example,
observe
and
block
voice
transfer
that
have
been
developed
together
with
co-op.
What
we
didn't
do
was
that
we
didn't
try
to
start
documenting
any
extension
that
you
can
think
of,
and
that
has
been
over
evolved
since
then,
and
what
we
didn't
do
is
to
try
to
cover
the
special
topics.
F
F
There
are
some
key
biddies
that
need
to
be
fixed
and
there's
one
open
issue
in
the
tracker
for
Matias,
where
we
need
to
just
put
in
some
text
that
says
that
your
eye
fragments
usually
aren't
transfer
CH
in
co-op
messages
but
handle
locally
by
the
client.
And
then
there
are
two
sections
that
are
empty
or
almost
empty
stubs
right
now,
which
is
the
section
about
DTLS,
where,
specifically
the
reference
to
our
c
7925
should
be
put
in
there
and
probably
some
text
about
the
the
TLS.
F
I
did
a
session
handling
with
co-op
and
the
security
considerations.
If
we
see
see
see
the
need
to
true
yeah
fin
that
appropriately,
then
we
should
do
something
there.
Currently,
it's
just
an
empty
TBD.
So
next
slide,
please,
which
is
the
final
slide.
So
the
big
question
that
I
have
for
you
folks,
is
what
is
currently
missing,
and
what
do
you
think
that
should
also
go
in
there
or
even
should
be
removed
from
the
document
as
is,
and
then
we
need
people
to
review
it
to
move
that
forward.
F
G
G
We
had
running
document
that
was
a
bit
like
this
that
actually
was
kept
active
for,
like
five
years
before
we
decided
to
finally
publish
it,
because
there
was
always
new
stuff
coming
in
and
there
was
never
a
point
in
time
where
we
said:
okay,
we
we
are
done
because
people
implemented
stuff
and
and
found
new
things.
So
is
this
the
style
in
which
we
should
run
this
or
do
we
believe
having
this
document
published
and
then
start
work
on?
A
second
version
is
the
right
approach.
H
Matias
Kovich
Siemens,
so
I'm
also
co-author
on
this
document.
A
reason
why
I
wasn't
too
active
in
the
past
years,
let's
say
is
that
no
reviews
are
coming
in
so
I.
Think
generally,
what
Carson
proposes
is
a
good
idea
to
have
something
to
cover
all
these
issues
that
keep
coming
up,
but
I
have
two
feeling
about
deadlines.
Log
lies
like
working
group
last
call
and
so
on.
People
never
get
those
reviews.
A
With
no
heart
I
mean
it's,
it's
it's
nice.
What
you
said.
Yes,
caution
would
make
sense
to
have
this
document
that
that
possibly
also
provides
guidelines
or
new
extensions
that
are
coming
up
and
new
things
of
this
go
up
over
TCP
ETLs.
And
how
do
you
optimize
those
things
but
I
guess
we
need
some
some
editor
or
someone
with
the
energy
to
make
sure
that
you
know
it's
in
one
document.
So.
G
E
Think
the
reason
of
the
lack
of
you
probably
is
in
you
know,
most
important
implementers
of
our
co-op
has
been
the
all
sorts
of
the
drought
right.
I
think
that
you
should
be
fully
responsible
with
the
taxes
they
owe
and
once
it's
down
and
also
the
capacity
just
the
custon
ask.
It
should
be
also
depends
on
you,
I'm
I
think
the
walking
will
be
at
your
disposal
to
either
to
publish
it
as
slow
as
possible,
or
we
can
defer
it
after
more
impulse
from
the
coop
inventors,
because
the
coop
specification
is
also
involving.
H
Sorry
I
have
a
comment
under
the
previous
statement,
so
pluck
tests,
maybe
a
comment
here
or
a
pointer,
so
we
got
some
inquiry
from
the
people
from
F
in
top
if
he
wouldn't
revive
the
practice.
So
it's
kind
of
a
continuation
of
the
former
probe.
It's
you
project
that
actually
led
to
the
Etsy
practice,
and
now
it's
a
bit
easier
because
it's
not
necessary
to
travel
to
these
practice
because
they
have
this
online
infrastructure.
H
But
definitely
there
needs
to
be
someone
who
organizes
like
a
test
week
or
a
few
days
where
people
would
at
least
travel
in
time
zone
to
to
do
this
and
I
think
it
would
be
worthwhile
because
some
more
advanced
issues,
let's
say
came
up
so
something
that
has
been
discussed
for
way
over
a
year
is,
for
instance
in
California.
If
you
run
it
in
a
cluster
mode
in
the
backend.
So
you
have
many
nodes,
you
have
redundancy
you
have
failover
and
so
on.
H
I
I'm
I'm
wondering
whether
you
guys
are
the
chairs
may
be
issued
to
organize
an
intro
up
on
some
of
the
coop
features,
including
co-op
or
DCB,
because
that
could
the
feedback
that
you
get
on
on
doing
those
interrupts
could
actually
be
fed
directly
back
into
this
document,
because
many
of
the
things
that
we
see
also
the
OMA
black
versus,
is
not
necessarily
specification
issues
but
more
clarifications
that
people
want
and
and
that
document
could
could
be
the
destination
where
those
recommendations
go.
Ultimately.
G
I
Once
again,
I'm
not
like
the
guys
who
do
the
F
in
truck
work,
but
I
think
they
have
slightly
different
goals
as
well,
because
their
idea
is
to
to
come
up
with
some
automated
tests,
which
is
a
great
thing
I'm
all
in
for
automated
tests,
but
they
have
specific
architecture
and
you.
You
obviously
then
have
to
write
all
the
tests
to
work
in
that
specific
architecture
for
the
automated
test
cases
which
you
may
or
may
not
like,
and
it
also
has
certain
limitations
specifically
when
it
comes
to
testing
of
security
for
the
course.
I
So,
for
example,
non-constant
and
a
couple
of
others,
you
have
tried
to
do
in
the
interrupts
for
the
coop
or
the
testing
for
a
coop
over
TCP
on
online,
essentially
and
I.
Think
that
even
that
at
that
level
was
extremely
useful
as
input
for
the
specification.
So
I,
don't
think
it
needs
to
be
needs
to
go
as
far
as
really
working
out
sort
of
the
scripts
to
do
things
automatically.
In
the
first
place.
A
G
Right
so
I
think
we
need
to
do
more
of
those,
but
one
of
the
nice
things
about
interrupts
is
that
that
people,
what
really
interrupts
us
that
people
are
sitting
together
and
talking
to
each
other,
and
sometimes
you
find
out
things
that
way
that
you
wouldn't
find
out
if
everybody
tests
on
their
own,
so
maybe
organizing
something
again
like
in
the
prog
timeframe,
would
be
a
good
thing
and
yeah.
We
would
have
to
tell
implementers
approximately
six
months
ahead,
so
they
they
can
start
getting
the
travel
budget
and
so
on
sounds.
A
G
Thank
you
so
terminology
for
constraint,
node
networks.
There
is
an
RFC
that
was
published
in
2014
that
actually
has
turned
to
out
to
be
extremely
useful,
because
before
we
had
that
RFC
people
didn't
understand
what
we
were
trying
to
work
on,
so
that
was
published
in
2014
in
2016
two
years,
two
days
ago,
I
presented
a
first
version
of
a
beast
document
to
capture
more
an
adapted
terminology
and
the
the
the
base
document
draft
is
out
there.
G
G
G
So,
for
instance,
one
thing
we
discussed
was
further
developing
the
terminology
for
power
constraint,
Ness,
finding
out
good
terms
or
clusters
for
Network
constraints,
so
one
constraint
is,
we
find
is
on
the
MTU
side,
where
we
have
pretty
radical
until
you
is
like,
like
8
bytes,
we
have
milli
bit
networks,
we
have
asymmetry
which
may
be
technical
or
may
also
be
regulatory
and
of
course
we
have
different
kinds
of
mobility.
Not
all
of
these
things
are
in
the
current
draft.
G
G
What
we
did
not
do
is
add
sub
classes,
so
for
why
people
wanted
to
have
different
terms
for
128
Age
and
128
16
and
256,
16
and
so
on.
But
maybe
that's
not
that
in
and
of
course,
there
are
other
things
then
Raymond
wrong
size
like
crypto
capabilities,
protection
capabilities
and
so
on.
We
don't
have
good
terms
for
those
yet,
but
I
think
we
are
seeing
clusters
of
chips
with
certain
capabilities
in
certain
places
here,
and
maybe
it's
worth
defining
terms
for
that,
so
a
chip
with
a
secure
and
clave.
G
G
Well,
you
have
to
remember
these
are
orders
of
magnitude,
so
there
are
very
few
chips
with
10
kilobytes
of
RAM.
They
actually
are
some,
but
usually
they
have
16
these
days.
So
that's
it's
an
order
of
magnitude
class
moment,
customs
still
kind
of
work
and
there's
also
a
one
and
a
half
in
between
which
with
something
like
32
kilobytes.
So
we
tried
to
come
up
with
clusters
for
the
higher
capabilities
and
I'm,
seeing
a
pretty
clear
cluster
that
I
have
called
class
3
in
the
draft.
G
So
there
are
a
lot
of
chips
with
that
set
of
capability
out
there,
and
there
are
also
quite
a
few
chips
now
which
are
generally
called
luxury
microcontrollers
that
that
might
have
a
megabyte
of
RAM
and
a
couple
of
megabytes
of
flesh
and
so
on.
These
these
are
much
less
very
defined,
because
the
luxury
is
the
luxuries
that
people
actually
need
are
just
very
different
depending
on
their
requirements.
G
Micro
Python
on
these
things.
Now,
of
course,
you
can
run
micro,
Python
or
JavaScript
on
a
classroom
system,
but
then
you
cannot
do
anything
else,
so
it's
really
something
that
that
class,
3
and
class
4
systems
are
being
used
for
and
then,
depending
on
how
much
you
want
to
do
in
these
language
environments,
you,
you
need
a
class
3
or
address
for
device,
so
these
are
two
two
trends
that
I
have
tried
to
put
into
the
state
the
table.
G
But
let
me
just
pull
forward
here
so
plus
3
is
pretty
recognizable
class
for
is
pretty
fuzzy.
All
these
classes
are
essentially
describing
execute
in
place
platforms,
and
that's,
of
course,
not
the
only
thing
out
there.
So
we
have
a
lot
of
load
flow
from
flesh
architectures
and
they
have
tried
different
shape
because
you
no
longer
have
a
clear.
G
Partitioning
between
grid
code
and
data,
so
you
can
put
much
more
data
into
a
load
from
a
flash
machine
in
many
cases.
But
then
you
don't
have
much
code.
So
I
haven't
played
enough
with
those
architectures
to
really
be
able
to
make
it
proposal
here.
But
people
who
are
using
these
architectures
please
think
about
what
what
you
are
interesting
classes
are
and
whether
we
should
be
adding
them
to
the
mixer.
G
So
there
seems
to
be
kind
of
standard
that
that
most
load
from
flesh
microcontrollers
have
about
half
a
megabyte
of
RAM,
and
this
half
of
megabyte
is
often
partitioned
to
various
jobs.
So,
for
instance,
some
may
actually
be
meant
to
be
run
as
data,
but
some
may
be
meant
to
be
run
as
code
ran
and
some
may
be.
Cache
Ram,
where
we're
actually
pages
are
dynamically
loaded
from
the
flesh,
and
this
is
pretty
interesting
because
it
has
a
lot
of
implications
on
the
rear
time
nature
of
these
things.
G
But
if
you
have
a
demand,
paging
loader,
flash
architecture
load
from
flash
architecture,
then
of
course
you
set
up
code
tons
of
setup
code,
no
longer
bother
you
because
you
can
get
all
that
stuff
and
also
having
a
giant
flesh
available
is
very
useful
for
storing
long
term
stage.
So
that
changes
little
bit
what
you
would
be
doing
so.
The
other
half
here
is
the
Jade
group,
where
we
have
something
that
I
called
class
10
class
19,
but
these
are
now
getting
a
little
bit
on
the
arbitrary
side.
G
So
I'm
already
pretty
cool,
pretty
sure
that
these
numbers
here
are
no
longer
right.
So
there
are
recognizable
classes.
So
there
is
a
class
of
devices
that
most
of
new
have
MIPS
CPUs,
that
have
quite
limited
environments,
but
good
enough
to
run
Linux
and
open
wrt
other
router
operating
systems-
and
these
are
really
cheap.
I
mean
cheaper.
If
you
look
at
them,
so
that's
and
they
also
have
pretty
reasonable
power
requirements.
G
So
that's
one
interesting
class
that
that
I'm,
seeing
and
of
course,
that
tenure,
then
we
have
the
Raspberry
Pi
class,
which
was
I
think
pretty
recognizable.
We
have
a
class
that
maybe
is
typical
for
smartphones
these
days,
which
would
be
export
controlled,
supercomputers
in
the
90s,
and
we
have
the
laptop
class
and
the
server
class.
G
G
Starved,
so
flesh
is
really
the
limiting
factor
to
what
you
can
do
with
them,
and
they
only
have
a
few
megabytes
of
RAM
and
these
classes
here
are
all
in
the
gigabyte
plus
space
Ram
wise
and
no
longer
really
is
useful
to
talk
about
flesh
size
because
they
all
have
demand
paging
and
they
are
not
are
using
given
paging,
but
they
hit.
They
have
it
at
least
architectural
II.
They
usually
have
very
large
flash
or
SSD
environments.
I.
Think.
I
One
important
difference
is
also
like
you
said
there:
they
have
a
memory
management
unit
can
run
it
generic
operating
system
and
they
they
typically
use
DDR
Ram,
and
so
this
off
chip.
Typically,
yes,
that
obviously
gives
you
a
lot
of
possibilities
to
change
the
size
of
the
RAM
quite
easily,
because
it's
sitting
next
to
the
shape,
rather
than
swapping
out
the
whole
chip
tour
together
and
also
like
you
had
before
some
of
the
more
advanced
security
features
like
if
you
think
of
security
features,
but
compartmentalization
features
like
if
you
think
of
virtualization.
I
It's
also
like,
since
we
have
focused
more
on
the
IOT
use
case.
Virtualization
in
my
opinion,
doesn't
necessarily
mean
like
the
way
that
we
use
it
on
a
desktop
PC,
but
it
it
provides
another
layer
of
protection
because
you
can
put
code
some
code
in
a
different
layer
that
has
more
privileges.
So
at
least
though,
it's
from
a
sense
of
security,
enhanced
security
capabilities,
I.
I
J
G
Which
usually
use
of
Chevrolet
sure
yeah
yeah
I,
don't
have
much
experience
from
so.
Basically,
the
reason
to
do
lot
from
flesh
is
that
the
actual
of
chip,
flash
chips
are
incredibly
cheap
and
you
don't
have
to
load
the
process
for
creating
the
cpu
with
the
complexities
of
creating
fresh
cells,
so
in
total
the
the
cost
may
be
low,
even
though
you
need
to
have
two
chips.
G
Ok
yeah,
so
what
I
would
like
to
do
is
get
lots
of
feedback
from
you
like
what
has
just
did,
and
we
want
to
use
this
terminology
mainly
for
classes
that
we
actually
find
out
there
at
the
wild.
Now,
of
course,
we
know
some
some
emerging
things
like
like
secure
enclaves
and
so
on,
where,
where
may
not
yet
be
possible
to
capture
real
clusters
of
project
products,
so
those
are
also
fine,
but
things
that
are
more
established.
We
should
actually
do
surveys
of
what
we
find
out
there.
G
What
what
combinations
are
actually
induce
and
also
the
class
boundaries
should
be
somewhat
indicator
of
capability
boundaries
and
so,
for
instance,
the
only
real
problem,
with
the
only
difference
between
the
laptop
and
the
server
category
is:
do
you
care
about
power
or
not,
and
even
with
service,
we're
starting
to
care
about
power?
So
maybe
that
is
even
not
such
a
great
separation,
but
I
think
it's
still
it's
still
quite
tangible
in
the
market,
so
yeah,
and
it
would
be
really
great.
G
If
for
each
class
we
had
a
few
examples
of
of
people
using
the
class
in
in
a
specific
conversation,
so
yeah
just
just
yesterday,
somebody
asked
me
what
is
the
definition
of
an
and
I
said.
There
is
no
definition
of
millennion,
but
if
you
mean
constrain
node
networks,
there's
there's
a
definition
here,
and
that
was
for
a
specific
document
which
I
already
have
forgotten,
but
we
shall
try
to
collect
these
things,
so
that
would
also
be
really
useful
input
for
the
authors,
I
think
I.
I
You
also
planning
to
talk
a
little
bit
about
the
like.
We
did
for
the
DCP
document
on
a
code,
size,
backgrounds
or
and
requirements
to
then
actually
speak
about.
What
are
the
different
components
that
we
developed
on
how
much
it
would
actually
consume.
So
you
could,
you
could
make
it
I
think
that
would
be
tremendously
used
for
it.
Doesn't
it
won't,
be
super
accurate,
but
it
give
a
rough
idea
on
how
much
one
has
to
actually
take
into
account
RAM
and
flash
twice.
This.
G
Is
kind
of
the
socket
document
and
you
you're
talking
about
a
plug
document,
so
we
we
have
one
of
these
with
the
crypto
sensors
it
was
in
for
but
that's
they're,
very
narrow,
very
specific
and
maybe
also
not
not
covering
the
whole
space
right.
The
end
I
think
it's
a
good
idea
to
start
collecting
something
like
expected
burdens
that
specific
protocols
are
classes
of
particles
of
sticks
are
creating,
and
that
would
then
fit
very
well
with
this
kind
of
document.
I
G
G
In
the
US
lawmaking,
from
for
each
law
you
make
there
is
a
mandatory
piece,
which
is
you
have
to
survey
the
paperwork
requirements?
How
much
paperwork
does
this
add
to
to
the
life
of
a
citizen?
And
maybe
we
should
do
something
similar,
then
not
call
it
paperwork
requirements
for
pottekkatt,
so
we
are
only
standardizing
it
if
we
know
what
kind
of
burden
it
puts
on
on
devices
that
use.
K
K
The
inclusion
of
all
these
options
is
perform
at
the
expense
of
poor
souls
and,
in
some
cases,
the
lack
of
performance
and
with
constraints
device.
They
are
likely
to
only
consider
a
subset
of
these
options
and
then
to
end
up
with
a
very
optimized
ESP
of
implementation
that
adapted
to
one
specific
usage.
K
So
with
the
adoption
of
IPSec
by
a
lot
of
IOT
device
and
a
MIMO,
Ike,
v2
or
ESB
header
compression.
It
become
crucial
for
ESP
implementation
to
be
desired,
to
be
able
to
interoperate
with
the
constraint
device
and
also
to
for
this
constraint
device
to
interoperate
with
them
the
standard
ESP.
So
the
main
motivation
is
to
enable
interoperability
between.
K
A
minimal
implementation
of
ESB
with
the
standard
implementation
of
ESP,
so
the
scope
of
the
document
is
to
provide
a
minimum
set
of
properties
that
an
ESP
implementation
needs
to
meet
to
provide
such
interoperability.
So
the
document
provide
guidance
on
implementation
and
implementation
experiences.
K
So
here
is
the
IPSec
ESP
packet,
that's
the
standard
one,
and
so
we
review
all
the
different
parameters
and
define
how
they
can
be
implemented.
So,
for
example,
the
spi
we
defined
how
we
can
reuse
a
predefined
number,
because
that
necessarily
need
to
be
random.
One
sequence
number:
we
defined
that
okay,
you
can
have
an
increment
ation,
but
you
could
also
use
at
a
time
because
it's
only
an
increasing
function.
K
Yeah.
We
described
various
ways
to
implement
it
so
that
well
to
reduce
the
overhead
next
header.
What
know
much
to
say
about
this
felt
so
the
the
document
has
been
reviewed
and
will
continue
to
be
reviewed
by
the
IPSec
Emme
working
group.
It's
already
well,
we
we
already
had
significant
review
and
presentation,
so
it's
already
in
a
good
shape
to
reach
them
lwg
milestone,
which
is
for
November,
and
it's
aligned
to
adapt
IPSec
to
constraint
devices
in
IPSec
Ameri
and
as
well
as
in
this
working
group,
where
we
had
the
Mimi
alike
v2.
K
E
E
L
L
I
have
not
yet
to
read
it,
but
I
was
just
wondering
better.
You
fixed
the
algorithm
options,
or
is
it
it's
changeable,
so.
K
Is
the
question
if
we
recommend
one
specific
algorithm?
Yes,
no,
we
described
how
to
select
the
algorithms
and
the
recommended
algorithm
described
in
another
document,
which
is
the
recommended
suite
for
ESPE,
and
this
because
this
crypto
algorithms
are
likely
to
evolve
over
time.
But
some
of
the
considerations
on
how
to
choose
them
remains
the
same.
L
L
So
what's
the
crusts,
the
crust
is
that
I
get
uses
various
elliptic
curves,
the
well-known
nist
curves,
and
also
curves
that
have
been
endorsed
by
Sivaji
and
they
seem
to
be
entirely
different
beasts.
So
the
draft
actually
describes
how
to
morph
the
reputation
of
the
CVD
curves
in
the
shape
that
can
reuse
existing,
for
example,
hardware,
implementation
of
mist-like
implementations,
thereby
allowing
essentially
two
implementations
for
price
of
one
and
I
also
think
it
can
be
used
if
people
want
to
design
another.
L
Let's
say
key
grimm
scheme
using
curve
255
online
or
what
have
you
to
describe
it
using
existing
standards
because
you
can
just
transfer
whatever
you
coop
up
into
things
that
get
cross
reference.
For
example,
nist
SP
1
856
a
so
what
is
new
in
version
1,
which
actually
is
now
version
2
since
last
night,
so
in
March
I
had
to
draft
that
allows
you
to
pick
an
existing
implementation
for
ECC,
using,
for
example,
mr.
L
phh's,
just
plug
in
parameters
for
let's
say
curve,
2,
5,
9
and
you're
done,
but
some
existing
implementations
actually
they're
hard
code,
some
parameters,
so
this
slightly
less
generic,
then
maybe
Yvonne
would
wish
for
so
now
in
a
new
draft.
I
actually
accommodated
that.
So,
if
you
have
something
that
does
something
that's
known
to
cryptography
and
probably
not
too
many
people
in
this
room
cult
using
the
Cobian
coordinates
implementation.
Using
some
particular
fancy
parameter
a
equals
-3.
L
Then
you
can
still
grab
that
existing
implementation
use
your
CVT
curves
and
run
with
it
without
having
to
redo
work,
provided,
of
course,
the
implementation
is
secure,
so
I
provided
that
one
and
another
bonus
for
people
who
don't
have
to
deal
with
that
constraint.
I
also
optimized
one
of
these
mappings
so
that
you
could
still
get
basically
something
called
one
multiply
for
free
per
bit
of
your
scalar
of
the
elliptic
curve.
L
L
The
question
is
whether
this
will
be
useful
for
this
audience
and
if
so,
she
could
make
use
a
draft,
so
it
just
has
been
gathering
dust
on
my
machine,
so
we
could
either
do
something
with
it
or
I
could
move
on
to
something
else,
and
the
other
question
I
had
as
a
site
is,
are
any
other
kind
of
like
implementation.
Mysteries
of
ECC
debts
could
benefit
from
some
kind
of
write-up.
G
Because
women
I'm
sure
the
answer
to
your
last
question
is
yes
and
I
generally
like
this
work,
because
it's
really
hard
to
do
a
crypto
agility
on
a
very
small
device
and
if
we
find
find
ways
to
to
build
several
different
algorithms
based
on
the
same
infrastructure
that
really
aids,
crypto
agility.
So
I
think
this
can
really
be
used
to
increase
the
security
that
we
are
getting,
and
also
to
increase
the
interoperability
between
different
ecosystems,
who
may
be
making
choices
that
require
different
I.
Think
so.
G
G
M
My
name
hi,
my
name
is
Sean
Trainor
I'm,
not
a
cryptographer
and
I
also
didn't
make
this
session
in
London.
So
too
talked
about
this.
There
just
tell
me
to
sit
down
one
of
the
more
interesting
paragraph.
One
of
the
more
interesting
sections
in
this
draft
is
section
5,
which
is
the
shortest
draft
which
says:
if
you
do
this,
you
might
need
some
new
identifiers
right.
M
That's
just
kind
of
a
meta
discussion
question
that
you
guys
have
to
think
about,
and
the
other
one
is
this
is.
This
is
primarily
because
it's
just
math
right,
you
can
just
kind
of
change
some
things
it's
all
over
here
using
transformations,
but
it
really
gets
down
to
the
identifiers
that
you're
using
in
the
protocols
right
so
that
the
chip
that's
already
got
the
NIST
stuff
building
can
do
the
transformations
to
just
use
the
code.
That's
already
there
right,
yes,
Oh.
L
I
M
L
L
K
G
A
Know
so
I
think
we
started
discussing
this
with
Rene
in
6
low
context
in
in
the
context
of
secure
neighbor
discovery.
We
were
coming
up
with
some
protocol
discussing
crypto
agility
and
that's
that's
when
we
started
discussing
this
and
he
told
me
that
you
can
use
the
same
implementation
to
actually
support
both
cores
and
I
was
like
okay,
I
didn't
know,
you
could
do
that,
so
that
will
be
interesting.
I
think
there's
there's
still
some
some
protocols
that
mandate,
P,
2,
5,
6
and
most
of
the
new
ones-
mandate
255,
1
9.
A
A
K
I'm
fine,
so
then
yummy
go
Ericsson
and
the
chair
co-chair
of
Colonel
I'm,
fine,
you
sent.
We
asked
for
a
review
at
curdle
I.
Think
that's
a
great
thing
that
say
you
should
be.
You
should
do
that
really
fast,
because
we're
about
to
the
working
group
is
not
very
active
currently.
So
it
gives
its
time
to
review
that,
but
I
mean
don't
wait
too
long.
K
K
L
N
Last
presentation:
for
the
last
session
we
made
it
hi
everybody,
I'm
Francesca
I'm,
presenting
the
update
to
the
protocol
comparison
draft,
which
was
adopted
between
last
meeting
and
this
meeting.
It's
a
very
quick
presentation,
so
the
update
in
the
next
version
we
have
just
fixed
on
editorials
and
typos.
Nothing
major
has
happened,
and
so
right
now
the
draft
is
updated
according
to
version
26
of
DTLS
1.3
and
the
latest
version
of
a
score
which
is
version
13.