►
From YouTube: IETF96-LWIG-20160722-1220
Description
LWIG meeting session at IETF96
2016/07/22 1220
A
A
B
A
A
A
And
we
have
not
document
related
to
co-op
in
plantation,
which
half
has
been
discussed
many
times
over
the
years.
But
now
the
state
has
has
been
inspired.
I
talked
with
materials
yesterday
and
he
said
he
some
plan
about
some
update
of
this
document
recently
and
we
have
done
a
document
about
energy
efficient
invitation
guidance
which
he
has
has
gone
through.
The
walking
group
last
core,
but
there
was
a
silence
during
the
last
call.
A
So
I
cannot
say
that
they
are
saying
consensus
about
this
document
right
now,
so
we
are
still
waiting
for
more
views
and
probably
we
can
click
OH,
but
the
other
walking
the
blast
call
for
this
document.
If
we
really
laid
it-
and
we
can
have
the
sufficient
view
of
this
document
here
in
the
process-
and
we
have
another
good
document
about
the
POS
implementation
and
we
can
speak
spout
waiting
for
the
authors
to
if
they
have
interest
or
they
still
sink
this
useful
to
continue.
A
So
that's
pretty
much
on
my
side,
and
so
we
have
four
for
talks
today,
lister
hill
and
also
in
the
agenda,
so
because
it's
friday
I
really
hope
every
presenters
to
be
on
time,
precisely
because
otherwise
people
we
are
playing
me
so
yeah,
that's
kind
of
on
to
the
next.
The
first
presentation
callous.
C
Ok,
hello,
my
name
is
carlos
gomez
and
I'm
going
to
present
this
initial
version
of
the
draft
and
title
tcp
of
a
constraint,
node
networks
and
from
UPC
and
I
took
at
and
my
coiffeur
is
don't
cook
off
from
the
University
of
Cambridge.
So,
first
of
all,
let's
take
a
look
at
the
motivation
for
this
draft.
At
this
moment
we
have
a
situation
where
several
application
layer
protocols
are
being
used
for
the
Internet
of
Things.
For
instance,
we
have
the
coop
the
constraint
application
protocol
was
originally
designed,
/
UDP.
C
However,
there
is
currently
a
co-op
over
TCP
specification
being
developed
and
then
actually
the
main
reason
for
this
copper
over
TCP
draft
is
the
need
to
overcome
middle
box
problems.
Then,
on
the
other
hand,
we
have
HTTP
two
and
even
HTTP
one
that
one
which
are
also
being
used
or
considered
for
the
IOT
and
other
application
layer.
Protocols
such
as
MQTT
are
also
being
are
also
in
fact
deployed
in
the
IOT,
and
all
of
these
are
using
TCP
as
the
transport
layer
protocol,
so
TCP
is
being
aureus
or
will
be
used
in
many
IOT
scenarios.
C
Well,
this
work
actually
is
related
with
more
than
one
working
group.
For
instance,
this
is
related
with
core,
which
is
the
working
group
which
specifies
co-op
and
its
related
framework,
also
TC
p.m.
which
defines
the
DCP
maintenance
and
minor
extensions,
and
also
this
working
group,
which
has
been
actually
suggested
as
the
home
for
this
draft
I
understand
that
at
some
point
we'll
have
some
discussion
or
confirmation
about
this.
C
First
of
all,
we
should
take
into
account
each
other
typical
characteristics
of
constraint,
node
networks,
which
is
something
that
is
well
known
in
this
working
group,
and
actually
it's
defined
in
RFC
7228,
so
constrained
nodes
are
devices
which
typically
exhibit
significant
limitations
on
processing
and
memory,
which
limits
the
complexity
and
the
implementation
footprint
of
the
protocols
being
used.
Then
there
may
be
also
significant
limitations
on
energy
resources,
which
means
that
the
messages
involved
in
communication
and
the
size
of
those
messages
should
be
reduced
as
much
as
possible.
C
Then
these
devices
typically
use
low
ceilings,
which
means
links
with
high
bit
error
rate.
That's
mostly
because
typically
wireless
technologies
are
used,
but
also
sometimes
there
are
other
wired
technology
is
quite
common
in
some
IOT
scenarios,
which,
however,
are
also
harsh
and
offer
some
high
bit
error
rate,
such
as
power
line
communications.
C
C
So,
let's
take
a
look
at
the
several
recommendations
about
how
to
use
TCP
in
these
environments
as
per
the
current
version
of
the
draft
so
about
the
maximum
segment
size.
We
have
that
ipv6
requires
support
for
280
byte
packets.
However,
many
of
the
link
layers,
which
are
used
typically
in
constrained,
not
networks,
offer
very
reduced
linklater
payloads
such
as
tens
or
hundreds
and
red
lights.
So
this
means
that
in
these
cases
another
tation
layer,
such
as
six
lo
pan
or
six
law,
is
used.
C
However,
these
ensures
that
package
of
a
size
of
180
bites
can
be
actually
transmitted
or
received
through
these
links.
However,
it
is
not
so
clear
that
support
for
packets
of
a
greater
size
than
this
is
still
allowed
still
a
nibble.
So
the
idea
is
that,
in
order
to
avoid
IP
layer
fragmentation,
this
document
indicates
that
the
maximum
segment
size
cannot
be
greater
than
12
hundred
and
twenty
bytes
and
in
any
case
it
shouldn't
lead
to
an
ipv6
Datagram
size
exceeding
180
bytes.
For
these
kind
of
links,
then
about
the
window
size.
C
This
is
because,
quite
often,
they
have
been
comments,
for
instance
in
remember
in
the
coil
working
group
that
for
the
end-to-end
reliability
mechanism
for
co-op,
we
shouldn't
reproduce-
let's
say
the
complexity
of
of
tcp.
However,
the
result
has
been
a
stocking
wait
operation
by
default
in
coop,
so
this
seems
to
be
accepted
by
the
community,
which
is
dealing
with
this
protocol
and
the
related
environments.
C
So
the
idea
was
to
say:
well,
possibly
the
same
can
be
achieved
with
with
tcd
so
based
on
the
feedback
that
we've
received
so
far,
it
seems
like
okay,
maybe
it's
better
to
maybe
recommend
or
explain
which
are
the
benefits
of
stopping
wait,
but
maybe
not
forbid
other
options.
So
then
another
matter
is
how
we
can
enable
the
stop
and
wait
operation
if
we
really
want
to
use
it.
C
Actually,
that's
because
we
have
experimentally
evaluated,
which
is
the
performance
of
this
new
algorithm,
which
is
called
Coco,
and
we
have
compared
it
with
other
algorithms,
such
as
the
one
in
RFC,
62,
98
and
many
others,
and
we
believe
that
it
performs
very
well
in
this
kind
of
environments.
So
this
is
why
we
are
actually
recommending
its
use.
C
Some
of
the
features
of
this
mechanism
include
her
in
addition
that
this
is
based
actually
on
RC
62
98.
It
also
includes
using
with
our
titties
a
variable
back
of
factor
and
eating
mechanism
and
deterring.
So
this
has
shown
to
lead
to
good
performance
in
terms
of
pd
are
settling
time
after
a
burst
of
messages
and
fairness,.
C
Another
aspect
is
about
the
lifetime
of
TCP
connection,
so
in
the
draft
we
currently
state
that
the
TCP
connection
should
be
kept
open
as
long
as
possible.
Well,
actually
there's
some
indication
in
a
quantified
terms,
which
is
that
if
data
is
going
to
be
sending
out
in
the
next
two
hours,
then
the
connection
should
be
kept
open.
The
idea
is
to
minimize
the
overhead
of
establishing
new
connections,
then
the
other
hand
we
have
that
keep-alive
messages.
Lady
use
may
be
supported
by
a
server
and
in
in
the
scope
of
constrained
scenarios.
C
This
may
be
useful
to
clean
inactive
state
for
ya
in
active
connections
state
for
devices
which
have
memory
limitations.
However,
the
keepalive
timer
cannot
be
set
to
a
value
lower
than
two
hours,
so
this
actually
some
issues
such
as
it
doesn't
guarantee
avoiding
middle
box
problems
because
sometimes
the
bindings
and
the
state
kept.
The
middle
boxes
is
released
earlier
than
two
hours,
so
the
alternatives
might
be
okay.
Maybe
we
have
to
anyway
establish
TCP
connections,
frequently
or
maybe
application
layer.
Heartbeat
messages
can
be
used
also
based
on
the
feedback
that
we
have
received.
C
Something
you
should
take
into
consideration
is
TCP
first
open.
This
would
have
the
benefit
of
embedding
data
already
in
the
syn
packets,
when
a
new
connection
is
established.
However,
we
have
to
make
some
detailed
analysis
here,
because
this
week
a
fast
open
involves
negotiating
a
cookie
which
has
to
be
updated
relatively
frequently
and
then
also
the
cookie
has
to
be
included
in
the
same
packet,
which
also
increases
message
size.
So
we
really
need
some
detailed
analysis
here.
C
Okay,
then
there
is
the
mechanism
of
explicit
congestion
notification,
which
we
understand
that
may
be
used
in
constrained
node
networks.
At
this
moment,
the
draft
was
only
allowing
stopping
wait
operation.
However,
as
I
mentioned
before,
probably
in
the
next
version,
this
constraint
will
be
released
or
relaxed.
C
C
However,
we
have
that
for
the
the
next
revision
of
the
draft,
based
on
the
feedback
we
have
received,
probably
since
options
0,
1
and
2
have
to
anyway
be
parsed,
then
we
may
phrase
in
a
different
way.
The
approaching
in
this
regard,
saying
that
we
may
ignore,
or
an
implementation
may
ignore
options
that
are
not
really
wanted,
and
if
any
way
stopping
weight
is
not
going
to
be
the
only
option,
then
maybe
some
of
these
options
might
be
relevant,
such
as,
for
instance,
selective
acknowledgement.
C
Finally,
are
with
regard
to
explicit
loss
notifications.
This
is
something
which
could
be
useful
to
distinguish
whether
loss
is
due
to
congestion
in
the
network
or
whether
it
is
due
to
corruption.
This
would
be
useful
here
because
we
are
dealing
with
low
ceilings
in
constraint,
node
networks.
However,
this
remains
mostly
as
experimental
work.
It
hasn't
actually
been
widely
deployed
and
hasn't
been
really
standardized,
maybe
80
f.
C
So
there
are
several
other
items
we
should
take
into
consideration
for
future
revisions
of
the
draft.
One
thing
is
to
clarify
the
scenarios
we
are
considering,
for
instance,
a
major
scenario
coming
actually
from
one
of
the
main
motivation
items
for
the
draft
is
to
explain
that
we
have
sometimes
a
constraint
device
which
may
want
to
communicate
with
some
unconstrained
device
on
the
internet.
So
we
need
to
detail
which
other
implications
of
this
scenario,
then
something
which
has
been
suggested
is
to
consider
delayed
acknowledgments,
which
is
the
role
of
this
mechanism.
C
In
this
kind
of
scenarios,
we
need
to
analyze
whether
we
can
benefit
from
this
mechanism
in
which
way
and
I
think
that,
especially
in
the
context
of
the
L
week
working
group,
this
document,
we
understand
that
it
should
collect
experience
from
implementation
and
deployment
of
TCP
in
constrained
node
networks.
It
would
be
great
to
know
if
people
have
had
experience
if
something
has
been
has
been
wrong.
What
has
happened
so
what
is
working
well?
C
D
Bolin,
that's
all
I
think
it's
really
good
thing
to
have
a
document
like
this,
so
I
think
it's
good
that
this
work
has
been
started.
I
think
that
the
document
could
be
a
little
bit
more
explicit
with
respect
to
the
situation
that
we
often
have
a
very
asymmetric
situation.
Yet
I
mean
it's
not
the
links
that
are
asymmetric.
It's
the
implementations
that
the
twins
are
asymmetric,
so
one
question,
for
instance,
that
comes
up
is:
is
there
anything
that
a
less
constrained
implementation
can
do
to
help
the
constraint
implementation.
D
E
Alabama
inria
aqueous
customer
I
think
it's
very
interesting
and
required
to
work,
and
I
was
wondering
like
a
couple
of
years
ago,
there
was
a
draft
about
TCP
header
compression.
I
think
it
was
into
a
6lowpan
group
and
I
was
wondering
if
you
have
considered
like
you,
look
at
this
old
draft
or,
if
you've
considered
some
other
mechanism
for
header
compression.
Well,
it.
C
Is
that
if
the
tcp
had
a
compression
document
was
let's
see
in
progress
or
alive?
Probably
this
document
would
report
that
I
don't
know
if
the
approach
should
be
different.
I
know
that
there's
this
draft
relatively
yeah,
which
has
been
inactive
for
a
while,
and
I
know
that
there
are
people
who
are
interested
in
maybe
reviving
this
kind
of
work.
So
then
I
don't
know
which
should
be
exactly
the
relationship
between
this
document
on
that
document.
But
yeah
I
agree
that
having
TCP
header
compression
would
be
absolutely
beneficial
and.
E
C
F
Carolyn
I
think
this
is
great
work
too.
I
had
comment
a
question.
First,
my
understanding
of
RFC
2460-
and
this
remains
in
the
best
version-
is
that
nodes.
This
is
not
something.
We've
talked
about
a
lot,
but
it
says
that
nodes
have
to
be
able
to
assemble
an
MTU
of
1500
octets
after
fragmentation.
So
I
just
wanted
to
point
out
that
there
may
be
some
constrained
implementations
that
actually
support
an
empty
of
that
size.
So
please
don't
limit
yourself
to
1280.
You
know
keep
that
1500
number
in
mind.
F
My
question
was
going
to
be
about
running
code.
I
just
heard
the
gentleman
from
riot
speak.
I
would
mention
that
there's
already
TCP
implementation
in
kontiki
I,
don't
know
if
it
could
be
lightened
up.
You
know
using
this.
You
know
using
your
technique,
but
you'd
be
really
interesting.
To
take
a
look
at
that
ya.
G
My
name
is
Michael
Scharf
I'm
speaking
here
is
share
of
TC
p.m.
but
in
general,
I
think
that
is
an
interesting
document.
Probably
this
is
the
right
working
group
to
document
how
to
implement
a
subpoena
lightweight
way
and
see
value
in
doing
that.
I,
don't
see
any
value
in
changing
the
TCPS
back
in
this
working
group
here,
you're
invited
if
you
see,
see
a
need
to
change
anything
with
beyond
what
the
TCP
specifications
low.
Then
I
think
this
has
to
be
home
in
TC
p.m.
G
H
Suresh
krisshnan
Eddie
had
so
I'm
skipping
the
mic
cutting
so
so
like
specifically
like
slide
12
like
doesn't
belong
here,
so
there's
something
you
need
to
do
and
as
logistics
right
stuff
and
slide
12
but,
for
example,
right
like
so,
it
doesn't
belong
here.
So
it
needs
to
go,
but
as
logistics
point.
So
if
the
working
group
decides
about
this
document
and
we're
going
to
get
a
shepherd
from
like
transport
somewhere
so
media
here,
they
promised
to
get
us
a
stripper
from
transport
to
get
this
true.
H
So
it
gets
the
kind
of
review
and
one
more
thing
that
would
be
nice
to
do
is
like
do
frequent
sing
cups
of
tea
CPM.
So
probably
like
every
other
meeting
cycle
or
something
like
go
back
to
tease
p.m.
show.
What's
the
stakes
and
if
there's
anything
open,
just
keep
the
stuff
sing.
So
we
don't
get
a
late
surprise
in
the
iesg.
At
the
end,.
A
H
I
J
Thanks
n,
so
I
have
a
lot
of
slides.
I
will
try
to
go
through
them
quickly.
This
was
our
trough
documenting
our
experiences
with
public
key
cryptography
on
small
devices.
So
by
small
devices
I
mean
really
small
devices
devices
that
have
8-bit
microprocessor
and
three
to
five
kilobytes
of
RAM.
We
basically
wanted
to
see
three
things.
First,
what
kind
of
libraries
are
available
for
me
as
a
developer,
so
what
kind
of
trip
to
libraries
I
can
use?
Second
thing
that
we
wanted
to
see
was
how
hard
was:
was
it
to
actually
use
this
library?
J
So
the
first,
the
first
thing
that
we
did
was
use
RSA
and
no
surprises
there
for
a
reasonable
key
length.
The
performance
was
pretty
undesirable
and
it
was,
it
was
very
slow.
So
if
you
look
at
a
key
size
of
20
48
bits,
which
is
what
you
would
assume
or
probably
even
bigger
the
execution
time
for
for
modular
exponentiation
and
signing
with
the
private
key,
was
actually
pretty
slope.
J
So
then,
then
we
looked
at
libraries
that
support
elliptic
curve.
Digital
signature
algorithm
bear
with
me
for
a
couple
of
slides
and
I'll,
explain
why
we
were
focusing
on
ecdsa
and
not
some
of
the
other
other
algorithms.
We
found
for
libraries
that
that
support
ecdsa
for
small
devices
so
relic
my
Chronicle
wisely,
when
tiny
CC
there's
also
matrix
SSL
and
polar
SSL,
but
there
are
more
focused
for
32-bit
devices
and
we
wanted
to
run
our
code
on
8-bit
devices.
So
so
we
didn't
get
any
numbers
from
from
those
libraries.
J
This
is
a
off
to
give
you
overview
of
some
of
the
numbers
that
we
measured.
I,
don't
know.
If
all
of
you
can
read
back
there,
but
the
important
takeaway
is
that
in
less
than
3
kilobytes
of
RAM,
you
can
actually
do
signing
operation
in
less
than
a
second
and
for
one
of
the
course
which
is
Sir
curve.
You
could
actually
do
ecdsa
signing
in
in
less
than
300
milliseconds,
so
it
was
actually
261.
Milliseconds
at
the
library
had
actually
implemented
some
some
mathematical
optimizations
directly
in
assembly.
J
J
We
found
some
numbers
for
the
same
Arduino
mega
bored
for
signing.
It
was
1.4
seconds
and
for
verification
it
was
two
seconds
which
may
not
be
ideal
in
all
scenarios,
but
bear
in
mind
this
was
on
a
8-bit
processor.
So
we
had
the
discussion
in
the
ACE
working
group
about
the
lighting
use
case
and
it
might
make
sense
to
just
use
a
32-bit
processor
because
it's
cheaper
to
actually
get
them
and
in
the
lighting
use
case
you
you
don't
actually
have
the
problem
of
energy
harvesting
or
low
power
supply.
J
J
So
we
implemented
the
co-op
client
and
all
the
crypto
stuff
we
did
JSON
web
signatures,
we
represented
the
keys,
has
JSON
web
keys,
we
implemented
the
proxy
and
the
resource
directory
on
x86,
machine
and
I'll
just
show.
The
important
numbers
is
like
it
was
possible
to
do
all
of
this,
including
sorry,
the
network
layer,
UDP
everything
in
less
than
five
thousand
bytes
of
RAM.
So
this
goes
to
show
that
if
you
really
put
some
effort
into
it,
you
can
get
the
numbers
actually
quite
quite
minimal
implementation.
J
So
what
we
learned
from
this
is,
of
course,
our
platform
was
unnecessarily
restrictive.
So
normally
you
would
choose
something
like
a
32-bit,
ARM
processor
or
something
more
powerful.
But
our
point
was
that
if
you
can
do
on
such
a
small
device,
of
course,
you
can
do
it
on
16-bit
and
32-bit
processors
faster
and,
as
is
now
well-known,
it
actually
costs
you
more
to
turn
on
the
radio
and
send
and
receive
messages
than
it
costs
you
to
do
the
crypto.
J
J
So
what
we
implemented
the
whole
application,
the
client
and
everything,
and
then
we
have
the
guidance
part
or
so
to
say
we
discuss
some
of
the
trade-offs
and
in
the
in
the
draft,
we
currently
have
discussion
about
symmetric,
key
vs,
asymmetric
key
and,
of
course,
a
lot
of
people
have
this
belief
that
symmetric
key
crypto
doesn't
scale,
which
is
somehow
a
misconception,
because
cellular
network
authentication,
which
is
one
of
the
largest
deployed
cryptographic
security
deployments.
Actually
does
use
symmetric
keys,
however,
we
don't
believe
that
scale
should
be
the
important
deciding
factor.
J
It's
actually
what
you
want
to
do
in
your
application.
So
if
it's,
it
might
make
sense
to
do
this
asymmetric,
crypto
prescience
at
the
beginning
to
do
the
key
exchange
then
derive
a
symmetric
key
and
use
that.
However,
if
there
are
proxies
and
intermediaries-
or
the
connection
is
very
shortly
so
think
of,
if
you
are
using
a
phone
to
open
a
door
lock,
you
might
actually
want
to
use
something
like
data
object
security.
J
So
we
have
some
discussion
on
trade-offs
of
doing
security
at
the
different
layers.
Of
course,
link
layer
is
good
and
useful,
but
it
can
be
problematic
because
it's
it
only
protects
the
first
hop
and
many
of
them
use
group
keys.
So
if,
if
the
key
gets
compromised,
you
can
have
all
sorts
of
problems,
then
we
have
IP
2nd
Para
the
network
layer
and
our
favorite
TLS
and
dtls
at
the
at
the
transport
layer,
and
they
see
they
work
fine
as
long
as
you
don't
have
middleboxes
in
between.
J
And
of
course,
if
you
do
this,
you
need
erection
communication
where
the
sensor
only
wakes
up
once
in
a
while
and
sends
signed
updates,
you
need
to
ensure
that
that
there
is
freshness.
So
you
need
some
some
way
of
protecting
replay
attacks
and
we
have
some
guidelines
on
how
you
can
do
that.
So,
of
course,
there
is
sequence
numbers
and
time
stamps
and
if
you
have
too
long
to
short
sequence
numbers
they
can
wrap
around.
J
If
you
have
too
long
sequence
numbers
your
packet
size
grows
and
how
you
can
get
around
that,
and
even
then,
if,
if
some
entities
get
out
of
sync,
how
you
can
recover
from
that,
so
we
have
some
text
on
on
on
basically
how
to
ensure
freshness,
yeah.
So
I
went
through
it
quickly
because
I
wanted
to
have
time
to
ask
the
group
I.
Think
the
authors
believe
it's
it's
fairly
stable
document.
It
serves
as
a
good
data
point.
B
K
J
J
L
A
N
A
O
O
O
Sorry
Stefan
tree
yeah
yeah.
So
there
are
a
few
problems
with
that.
There
are
a
few
privacy
issues
because
you
always
send
the
IP
address
of
the
device
you're
actually
using.
So
someone
could
track.
You
even
could
track
your
health
sensor
and
therefore
could
derive
diseases
or
whatever
just
because
of
addresses,
and
it's
also
difficult
to
manage,
like
if
you're
the
owner
of
such
a
domain,
it's
very
difficult
to
manage
and
to
update.
O
O
So
we
believe
that
ESP
or
ipsec
ESP
complements
the
toolbox
of
IOT
towards
dtls,
enticed
it
has
some
significant
features
to
security
IT.
First,
you
can
provide
the
main
security.
What
I
just
showed-
and
it's
also
capable
of
to
make
a
multicast
security-
you
can
secure
any
transport
layer
you
want
and
it
avoids
like
privacy
issues,
but
it
just
said
like
if
you
or
a
specific
application
apart,
it's
also
very
flexible
because
you're
in
the
back,
not
like
dtls
you're,
independent
of
an
key
exchange,
you
can
use
any
key
exchange
protocol.
O
You
on
the
obvious
one
is
ike
and
we
already
have
minimal
iq2
as
an
RC
of
this
working
group,
but
you
can
also
use
with
like
radio
key
exchange
protocol
slagged
x,
which
is
very
common
in
IOT
devices.
In
the
moment,
there
is
a
RFC
for
multicast
key
exchange
and
you
can
use
it
with
any
other
of
you
can
even
set
up
it
manually
to
establish
the
keys.
O
The
goal
of
minimal
ESP
is
to
provide
guidelines
for
an
implementer
to
remain
fully.
I
could
be
comfortable
to
the
RFC
how
to
build
the
truck,
how
to
build
the
ESP
fields
without
a
lot
of
computation
and
also
which
ciphers
should
be
implemented.
This
is
already
part
of
a
working
document
in
the
IP
second
d,
which
points
out
some
IOT
specific
ciphers.
So
in
the
next
version
of
minimal
ESP,
we
would
probably
at
over
now
a
reference
to
this
RFC
once
it
comes
out
how
to
read
it.
O
Just
to
show
you
the
basic
idea:
that's
the
ESP
packet.
You
have
the
sequence
number
to
identify
the
security
Association
on
the
endpoint,
so
on
the
point
which
receives
two
encrypted
packet,
if
a
sequence
number,
and
in
your
payload,
which
is
headed
to
the
IP
alignment
with
the
pad
lengths
and
the
next
terror
which
points
to
the,
for
example,
UDP
packet
in
the
payload,
and
then
we
have
an
integrity
check.
So
what
we
want
to
say
in
minimal
ESP
how
to
use
this
fields
as
a
developer,
for
example,
for
SBI.
O
O
O
Ipsec
working
group
just
broke
down
the
field
raft,
for
example,
implicit.
I
leave
was
just
adopted
as
the
IP
second
to
develop.
You
second
me
working
group
that
you
don't
have
to
send
an
implicit
IV
for
counter
ciphers
and,
like
the
one
I
mentioned,
decipher,
supports
yeah
for
specific
IOT
requirements,
and
we
already
have
minimal
iq2.
So
we
think
that
we
should
have
an
ESP,
minimal
ESP
also
in
the
working
group.
H
L
O
L
H
A
P
A
A
D
This
has
been
out
for
three
years
on,
and
the
question
came
up.
Is
it
may
be
time
for
an
update
after
two
years?
This
may
be
a
little
bit
surprising,
but
turned
out
that
the
draft
actually
was.
The
RFC
actually
was
quite
useful,
and
there
are
two
things
that
that
could
have
happened.
Whether
the
word
has
moved
since,
of
course,
so
is
there
may
be
something
new
that
we
want
to
take
account
of,
like
the
other.
One
is
that
we
might
simply
find
that
there
is
terminology
missing
we've
run
into
terminology
every
day.
D
That
is
not
clearly
defined,
where
we
have
different
words
for
the
same
thing
or
the
same
word
for
different
things.
So
it
might
be
an
idea
to
update
the
raft
pizzette
so
even
that
it's
probably
going
to
take
a
year
or
two
to
do
this.
The
next
version,
what
we
maybe
2017
2018.
So
it's
not
that
bad.
So,
let's
talk
about
two
areas
of
potential
work.
D
One
is
terminology
for
platforms,
so
most
people
know
seven
to
twenty
84
+
0,
+,
1,
+,
2
+,
and
one
thing
we
noticed
is
that
people
have
big
trouble,
distinguishing
big
computers
from
small
computers.
Big
computers
are
sometimes
also
very
small,
they're
called
fast
berry,
pies
and
so
on.
So
we
probably
need
some
terminology
that
distinguishes
between
the
microcontrollers
that
7228
really
is
about
and
the
big
computers,
the
computers
that
run
linux
and
which
also
may
be
pretty
small
in
the
end,
but
they
have
quite
different
characteristics.
D
So,
in
the
software
update
workshop,
we
seem
to
pick
up
the
antenna
terminology
on
this.
So
with
an
arm.
You
know
they
have
these
contexts,
a
processors
and
their
context,
n
processors,
and
we
started
talking
about
a
class
in
m-class
devices
and
of
course,
every
tricky
knows
that
we
are
living
on
an
m-class
planet.
So
this
is
very
good
and
we
can
now
decide
whether
maybe,
according
this
to
this
terminology,
the
big
processor
should
be
j-class
processors,
but
ok.
So
this
is
one
one
point
where
we
definitely
need
additional
feminine.
D
We
also
have
found
that
the
two
classes,
the
two
useful
classes
last
one
in
class
we
identified
sometimes
artoo
cause-
sometimes
there's-
maybe
a
use
for
a
class
3
or
class
4.
So,
for
instance,
that
would
be
useful
to
identify
a
class
that
actually
is
powerful
enough
to
run
something
like
JavaScript
by
name.
You
might
want
to
introduce
subclasses.
So
this
this
might
be
another
place
where
it
might
be
used
for
to
do
some
graph.
Then
we
have
discussed
crypto
capabilities.
So
simple
things
like
we
had
access
to
an
Aes
accelerator
may
be
interesting
odd.
D
Finally,
we
are
seeing
more
and
more
micro
controller
class
platforms
that
actually
do
have
some
protection
capabilities,
memory,
protection
units
memory,
mapping
units.
Even
some
have
city,
you'll
flags.
Like
cannabis
users.
We
have
trust
zone
or
secure
element
elements.
We
have
10
/
proof
capabilities
in
very
many
platforms,
because
people
just
don't
don't
want
their
source
code,
truly
their
limitation
code
to
leak
out
and
so
on.
So
maybe
it's
worth
looking
at
those
probabilities
and
defining
classes
for
that
we
have
a
Java
code
and.
I
Now
me,
you
have
record,
do
you
want
me
to
fight
to
you
finish
their
presentation
or
not?
Really?
Okay
brain?
So
we
are
also
in
ace
having
problems,
defining
clock
capabilities
of
the
devices.
Some
don't
have
time,
awareness
at
all,
so
fresh,
a
token
validation
cannot
be
done.
The
way
you
do
normal
you
out,
so
you
need
non-space
methods.
Some
devices
have
relative
time
capabilities
and
some
devices
might
be
clogged
or
synchronized
so
to
express
the
problems
we
are
facing.
I
D
We
could
maybe
talk
about
power
constraints
some
more
so
we
have
some
basic
general
terminology
in
there.
I'm,
not
sure
how
successful
that
terminology
has
been
I'm,
not
hearing
it
in
everyday
exchange,
but
that
may
be
just
because
people
another
way
of
it,
and
maybe
we
also
can
look
at
these
sustainable
power
and
energy
total
parameters
and
maybe
build
something
like
classes.
So
we
all
know
that
there
is
a
watch
class,
I,
OGE
and
a
micro
wat
class
IOT,
and
they
are
very
different
in
many
aspects.
D
Finally,
we
could
look
at
terminal
e
front
terminology
from
networks,
some
more
so
I
found
out
that
we
often
have
difficulty
grasping
the
different
mpu
properties
of
networks,
in
particular
with
AP,
when
coming
in.
We
have
network
to
it
with
ridiculous
and
key
youth
and
sure,
so
we
should
have
classes
of
ridiculousness
hear
something
like
that.
Also,
maybe
the
fact
that
these
have
sustainable
bit
rates
in
the
military
or
second
range
also
gives
rise
to
some
classes.
D
So,
as
you
can
see
that
there
are
a
number
of
areas
where
we
could
start
defining
things
and
I
already
have
one
volunteer
fall
for
the
the
clock
or
time-based
issue
where
which
has
already
done
some
work
at
so
I
know
that
she
is
interested
in
this
and
what
I
really
would
like
to
assemble
is
a
group
of
people
who
would
like
to
contribute
to
that.
So
I
will
be
pushing
out
a
draft
blah
blah
blah
73
72
28
bits,
and
then
I
will
stop
collecting.
F
Lynn
yeah
Karsten
I
agree
with
your
initial
comment
that
this
has
been
extremely
useful
because
I
remember
in
the
early
days
of
discussions
you
know
people
were
thinking
that
raspberry
pi
was
a
constrained
device,
and
you
know,
of
course
to
us.
It's
a
super
computer,
but
just
to
follow
up
on
your
point
about
memory
consumption,
an
example
of
the
world
changing
would
be
if
somebody
has
perfected
a
small
fuel
cell.
You
know
the
size
of
a
watch
battery
and
those
things
where's
law
is
not
going
to
save,
as
here
somebody
has
already
made.
F
You
know
the
point
in
one
of
the
earlier
conversations
that
there's
no
reason
not
to
pick
a
cpu,
that's
capable
of
doing
the
work
you
need
unless
you're
powered
by
battery.
So
I
think
I
agree
with
you.
Maybe
the
point
is:
is
that
there's
not
enough
awareness
of
the
power
constraint
and
I
plug
on
electrical
power
not
to
keep
our
be
good
if
the
next
version
could
take
them
yeah.
F
Q
R
S
When
you're
bajillion
ram
I
fully
support
this
work,
I
think
Marcy,
7228
was
already
very
useful
and
refrigerant
could
be
well
could
extend
this
usefulness.
However,
I
think
that
we,
you
know
if
we
want
this
talking
to
be
really
useful.
We
there's
a
trade-off
between
you
know
describing
like
so
many
classes
and
I
things.
I
mean
obviously
extreme
cases
like
one
class
per
device
right,
so
we
don't
want
to
get
there.
So
I
think
there
should
be
two
phases
in
the
club
in
this
document
really.
S
D
H
Id
had
so
just
just
an
industry
description
as
an
individual
I'm,
just
wondering
right
like
if
RFC
is
the
right
format
for
this
right
like
since
it's
something
that's
like
evolving
pretty
quickly,
I
would
say
right
like
so.
7228
is
like
like,
if
you
look
at
the
number,
its
too
young
to
be
obsoleted,
right
and
and
I'm
just
thinking
like.
H
So
this,
like
a
couple
of
ways
of
doing
this,
like
one
of
them
is
like
probably
like
some
kind
of
Vicky
somebody
maintains
another
one
is
like
probably
keep
it
as
a
draft
right
like
keep
it
as
a
working
group
graph
for
a
bit
and
give
it
some
time,
maybe
like
a
year
or
two
like
just
hold
onto
it,
and
then
do
it
like
I.
I
just
want,
like
the
wasn't,
really
think
about
that
as
well.
Yes,.
D
So
not
my
quick
answer
to
this
would
be
a
terminology
is
most
useful
when
we
have
consensus
on
it,
so
this
is
really
a
place
where
Ricky
is
not
sufficient.
You
two
need
some
to
build
something
senses,
but
but
keeping
the
draft
active
for
some
while
and
then
collecting
things
they're
competing
with
yeah.