►
From YouTube: IETF99-LWIG-20170720-1810
Description
LWIG meeting session at IETF99
2017/07/20 1810
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
B
B
B
Crypto
draft
and
the
Co
app
drop
so
but
yes,
I
I,
think
we
do
need
some
good
pushers
of
this
draft
in
order
to
get
it
down
to
be
some
into
to
the
iesg
I
personally
read
the
cooperator
again
I
think
it's
pretty
good
draft
and
but
anyway,
release
some
somebody
to
make
some
edits
before
I
can
ship
it
to
the
ISD,
and
we
have
some
green
ones
which
will
be
discussed
today,
which
is
the
TCP
draft
and
also
TCP
guidance
raft
and
also
the
ESP
garden
draft.
So.
C
Suresh
krisshnan
has
ad
so
the
energy
efficient
stuff
just
came
in
to
me.
Like
couple
of
weeks
ago.
It's
been
a
request
at
I/o
to
do
review
of
this
so
they're
taking
a
look
at
it.
So
hopefully
we'll
get
a
review
for
that
and
there's
also
in
the
review
going
out
so
like
once
that
is
done.
I'll
do
my
eval
and
send
it
to
ITF
class
cough
so
hopefully
like
in
a
month
month
and
a
half
it'll
be
in
front
of
the
IES.
You.
B
Here's
our
agenda,
so
so
we
all
talked
about
basically,
so
the
first
three
drafts
will
be
wheezing
our
count,
walking
charter
and
we
are
going
to
discuss
it
and
the
main
object
of
the
meeting
today
will
be
asked
for
the
option
and
for
further
steps
of
this
draft
and
the
forest
for
the
last
one
on
the
agenda
is
going
to
be
asked
for
the
interest
of
the
draft
so
how
to
get
impulse
for
our
group.
So
any
question
regarding
the
chain:
okay,
pretty
good,
so
I
can
move
to
the
first
prison
thing.
E
The
presentation
has
already
already
be
made
in
Berlin
in
the
ITF
96
during
the
six
low
motivation
remains
the
same,
and
so
the
problem
is
that
the
standards
face
standard
espy
is
likely
to
be
implemented
by
many
different
small
devices
and
well.
This
document
is
intended
to
make
sure
that
these
new
implementation
light
implementation
still
be
compatible
with
the
standard
one.
E
So
basically
we
described
how
can
what
are
the
mandatory
features
as
well
as
where
other
feeders
have
they
can
be
implemented
in
light
waste,
depending
on
the
context
and
the
the
use
of
those.
So
overall,
these,
though
we
already
have
an
IKE,
a
minimal
Ike
v2
in
this
working
group,
so
this
document
is
continuing
the
effort
for
ESP.
E
E
So
now
we
think
we
it's
relatively
mature,
which
doesn't
mean
that
we
well.
We
expect
a
few
more
reviews
and
process
and
back
and
forth.
The
document
is
clearly
handled
between
the
two
groups.
So
it's
not
that
we're
trying
to
hide
the
document
and
the
the
updates
from
IPSec
Amy.
There
are
still
heavily
involved
and
we're
going
to
require
them
to
review
in
detail
to
the
document.
E
E
So
it
is
the
two
bits,
so
we
clarified
the
text
on
the
SPI,
so
we
detailed
on
how
it
can
be
handled
with
multicast
or
anycast
communications.
We
detailed
in
detail
how
we
can
use
a
fixed
value
for
a
spi
or
limited
number
of
values
for
SPR
in
case
of
some
devices
would
not.
We
could
hardly
generate
a
random
divider,
andum
SP
all
right.
E
We
also
clarified
that
it
doesn't
mean
that
you
don't
need
randomness,
because
for
crypto
you
need
randomness,
so
it's
just
a
way
to
avoid
generating
new
SPI.
We
clarify
the
padding,
so
our
padding
was
correct.
I
mean
it
was
I
think
it
was
wrong
statement
and
we
clearly
mentioned
it
as
mandatory
and
we
also
clarify
with
well
ESP
got
some
mechanisms
so
that
you,
you
can
provide
some
additional
padding
so
that
you
don't
leak
any
information
about
the
size
of
the
packet
so
well
for
a
minimal
version.
E
We
clearly
mentioned
that
these
kind
of
features
are
not
mandatory
or
not
expected
to
be
part
of
such
implementation.
Next
header.
Well,
we
clarified
the
meaning
of
the
next
header
and
also
define
that
that
was
a
missing
part
in
the
last
version
that
you
you
have
to
remove
to
to
be
able
to
disk
out
some
dummy
packets
ICV.
E
While
it
was
mostly
a
clarification
because
the
text
was
suggesting,
you
can
cut
some
part
of
the
ICV
or
make
some
ICD
optional,
which
was
really
not
the
case.
So
that
has
been
clarified
in
the
current
version
and
that's
about
all,
would
you
eat?
We
received
some
additional
comments.
We
will
address
in
a
further
version
and
we
would
like
to
continue
this
draft
I
mean
in
this
working
group,
but
in
collaboration
with
IPSec
I
mean
we
have
well.
E
A
G
F
So
Hannes
again
so
I
think
we
should
not
do
that
work.
It's
a
terrible
idea.
We
IPSec
provides
no
benefits.
The
motivation
that
you
a
percentage
is
just
nonsense.
It
will
it
will.
If
people
actually
use
it,
it
will
actually
add
another
security
mechanisms
that
people
don't
have
to
support,
which
adds
fragmentation.
It
I
think
it's
a
terrible
idea.
It
doesn't
do
as
a
service.
H
The
eternal
communion
one
of
the
good
things
about
you
know
losing
IPSec.
We
said
you
can
ask,
use,
also
use
the
I
curse
and
to
to
generate
the
keys
for
the
15
for
layer
which
you
can't
use
the
TLS,
because
15
9
doesn't
support
TLS,
because
there
was
nobody
to
write
the
traps
for
that,
so
that
for
for,
if
you
want
to
have
one
crypto
algorithm
you
and
one
encrypted
protocol,
you
can
have
I
person
to
an
ESP
and
nothing
else.
H
You
don't
need
to
Ellis
at
that
point
so,
but
actually
I
guess
in
most
of
the
cases
in
this
kind
of
confronting
basis,
you
pick
one
and
you
talk
to
whatever
is
your.
You
know
cloud
or
whatever
service
you
have
there.
So
if
you
use
TLS
use
TLS
everywhere
that
you
don't
support
this,
if
you
use
IPSec
use
IPSec
everywhere
and
you
got
super
TLS,
so
it's
you
know
whatever
you
pick
and
you
pick
what
what
is
suitable
for
your
there.
Your
needs.
I
E
D
F
J
F
C
Krisshnan
so
Hannes
just
hold
on
a
second.
The
thing
is
like
it's
like
an
early
individual
draft
right
at
some
point,
he's
gonna
go
for
an
implementation.
I
understand
right,
like
nobody's
requiring
implementation
for
adoption.
It's
a
good
thing
to
have
right
so
yeah.
So
if
I
understand
you
correctly,
your
questions
should
be
right,
maybe
I'm
paraphrasing
it's
like.
Why
do
you
see
a
need
for
this?
C
Is
that
the
right
way
to
put
it
okay,
so
he's
saying
he
has
a
need
for
it
right
like
and
we're
trying
to
figure
out
if
somebody
else
has
a
need
for
it,
I
think
that's
where
he's
at
so
if,
if
somebody's
trying
to
see
need
for
it,
then
we'll
go
forward.
If
not
like
this
whole
discussion
is
moot
right.
We
just
move
on
right,
say:
Daniel
go
away
and
that's
it
right.
So
I
I
fully
agree
with
your
point.
At
some
point.
We
need
an
implementation
like
as
a
personal
draft.
H
Anyway,
they
recognize
he's
not
going
to
try
trying
to
standardize
anything
new.
This
is
standard
ESP,
it's
going
to
it's
already
standardized.
It
has
been
out
there
for
a
long
time.
He
starts
describing
what
kind
of
tricks
and
things
you
can
do
to
make.
It's
very
small.
So
you
don't
have
to
implement
that
you
don't
have
to
read
the
whole
OSP,
and
this
is
same
thing
made.
H
It
mean
minute
amount
in
a
more
like
I
mean
there
is
Ike
is
almost
already
at
what
is
at
that
point,
but
the
problem
was,
it
was
you
know,
150,
page
100,
100
pages
and
had
all
kind
of
feature
that
you
don't
need.
You
don't
need
not
trouble
or
something
you
don't
need
that
kind
of
things,
and
so
on.
In
most
of
the
minimal
cases
you
don't
need
those
we
were
actually
documenting,
just
what
we
don't
need.
This
is
the
same
thing
in
ESP,
I.
F
Hannes
again,
I
think
also
it
was
a
bad
idea
to
standardize
this
minimal
Ikey,
since
the
reason
is
what,
as
some
feature,
is
really
useful
or
not
depends
on
what
your
environment
is
like
the
natural
bristle.
If
you
talk
to
like
previously
mentioned,
you
talk
to
some
cloud,
a
service,
probably
you
will
have
naturalism
and
so
on.
So
you
just
stripped
out
up
sort
of
random
things
and
busy
I
bring
if
I.
Remember
correctly,
it
was
you
focus
on
the
BSK
version.
F
H
Example,
the
15
459
I
question
2
is
using
the
minimal
one
because
it
does,
it
doesn't
need
not
reverse
or
because
it's
perverse
keys
between
two
devices.
It
actually
doesn't
know
most
of
the
features
of
a
person.
It
just
uses
the
key
generation
given
it
said
so
so.
Yes,
there
is
you.
She
said.
Yes,
this
will
of
fragment
no
environment,
but
that
will
happen
anyway,
and
it's
actually
already
happening
because
I
mean
there
is.
H
Thousands
of
you
know,
implementations
using
their
own
proprietary
stuff
and
as
long
as
they
use
anything
from
here,
it's
much
much
better
than
10
proprietary
and
if
they're
prepared
the
requirements
are
that
they
need
to
be.
You
know
sending
IP
packet,
they
don't
want
to
do
TLS.
They
don't
do
anything
like
that.
This
might
be
shooting
better
for
them
than
10
the
TLS.
If
it
doesn't,
they
used
to
tell
us
it's
it's
you
know,
they've
been,
they
are
breaking
their
product
table,
decide
what
they
are
going
to
use.
I.
H
B
B
B
And
the
secondly,
and
secondly,
currently
even
for
the
FC
for
the
78th
25
25,
so
for
the
minimum
item
is,
is
nothing
normative
right?
This
national
team
is
informational,
so
it
tells
people
how
to
implement
a
minimal
client
of
the
IKE.
You
know
you
know
your
protocol,
you
know,
protocol
compliance
way.
J
So
I
don't
want
to
continue
this
discussion.
I
just
started
suggestions,
RFC
7,
9
mm
son,
how
to
improve
awareness
of
implementation.
So,
since
you
do
have
some
some
implementations,
it
would
be
good
to
have
a
section
documenting
them
which
of
them
are
open
source
where
I
can
get
them
and
so
on
that
working.
B
B
B
B
C
A
K
I
I
L
Ok,
hello
good
afternoon,
my
name
is
Carlos
Gomez
and
I'm,
going
to
present
the
last
update
of
the
draft
entitled
TCP
over
constrain
node
networks.
By
the
way
we
are
pleased
to
have
Michael
sharp
as
a
new
member
of
the
author
team
and
would
like
to
help
him
Troy.
Well,
thank
you
for
the
contributions
that
he
has
already
made
so
far.
So,
first
of
all,
a
quick
reminder
on
the
motivation
for
this
document.
So
nowadays
we
have
several
application
layer
protocols
that
are
being
used
for
IOT
scenarios.
L
However,
there's
also
an
ongoing
co-op
over
TCP
specification
in
progress,
that's
mostly
motivated
by
the
need
to
overcome
problems
with
middle
boxes
that
appear
not
to
be
very
friendly
to
UDP
traffic.
Also,
we
have
that
HTTP,
2
and
even
HTTP
1.1
have
been
used
and
are
being
used
in
some
IOT
scenarios,
and
then
we
have
other
application
layer.
Protocol
such
as
XMPP
or
MQTT,
especially
the
last
one,
is
very
popular
which
rely
also
on
TCP
at
the
transport
layer.
L
So
we
have
that,
despite
that,
TCP
has
been
quite
neglected
and
even
unfairly
criticized
as
a
protocol
for
the
IOT
TCP
is
being
used
and
will
be
used
in
many
IATA
scenarios.
So
the
purpose
of
this
document
is
to
offer
simple
measures
for
suitable
TCP
implementation
and
operation
over
constrain
node
networks.
L
So
let's
look
at
the
status
of
the
draft.
The
initial
version
was
presented
in
Berlin
one
year
ago
in
both
elegant
eCPM
sessions,
then
the
document
was
subsequently
updated.
The
was
0
1
&
0
2,
which
represented
in
Seoul
and
in
Chicago
respectively,
and
today
I'm
presenting
the
last
update,
which
is
0
3,
where
we
have
addressed
comments
received
in
Chicago
and
also
we
provide
details
on
the
riot
and
open
WS
n
TCP
implementations
by
the
way,
thanks
to
Simon,
rumor
and
avi
village
asana
for
kindly
providing
details
on
these
two
implementations.
L
L
So
let's
go
through
the
updates
in
this
last
revision
of
the
draft.
The
first
update
is
in
the
subsection
titled
maximum
segment
size.
There
was
a
related
discussion
in
Chicago
about
nodes
that
use
technologies
that
support
an
MTU
which
is
greater
than
280
bytes
according
to
RFC
1981.
Those
nodes
should
support
path,
MTU
discovery
by
the
way.
L
There's
a
note
in
that
RFC
that
states
that
a
minimal
ipv6
implementation
may
choose
to
omit
implementing
path,
MTU
discovery
and
the
date
in
the
document,
also
based
in
the
based
on
the
comments
received
in
Chicago,
is
that
unless
applications
require
handling
large
data
units
that
meaning
leading
to
an
ipv6
Datagram
size
greater
than
280
bytes,
it
is
desirable
to
limit
the
MTU
to
1280
bytes.
By
doing
this,
we
avoid
MTU
issues
along
the
end-to-end
path
and
also
we
avoid
the
need
to
support
path.
Mtu
discovery.
L
So
another
update
is
in
subsection
4.8,
which
is
about
delayed
acknowledgments,
so
we
have
that
constrained
device
will
be
in
some
scenario,
sending
data
to
some
peer
and
the
peer
may
not
be
a
constrained
device.
So
we
may
recommend
we
can
be
giving
guidance
for
constrained
devices,
but
a
problem
is
that
sometimes
the
peer
device
will
not
be
a
constraint
device
and
usually
those
unconstrained
devices
have
delayed
acknowledgments
enabled.
So
that
means
that
acknowledgments
may
be
delayed
by
typically
200
milliseconds.
L
It
could
be
even
up
to
500
milliseconds
and
if
traffic
is
of
transactional
type,
which
is
quite
common
in
constrained
known
networks,
that
would
contribute
a
necessary
delay.
So
if
that's
possible
at
all
disabling
delayed
acknowledgments
would
be
recommended,
for
example,
that
might
be
possible
if
the
peer
is
administered
by
the
same
entity
managing
the
constraint
on
network.
However,
in
some
scenarios
that
may
not
be
possible.
Yes,.
M
It
confusion
if
the
traffic's
is
transactional
type
and
if
the
server
is
not
responding
very
slowly,
then
you
don't
the
the
delay
that
doesn't
matter
at
all,
because
then
the
acknowledgment
acknowledgment
transmit
the
response
as
piggybacked.
So
if
the
server,
for
example,
replies
between
200
milliseconds
to
read
or
acknowledgements
that
don't
have
any
meaning
yeah.
L
L
L
So
another
update
is
in
the
annex
of
the
document.
So
if
you
remember,
there's
design
acts
where
we
are
collecting
details.
The
main
features
of
constraint,
TCP
implementations.
So
now
we
have
other
details
on
the
riot
disappea
implementation.
So
this
is
an
implementation
design
for
class.
One
devices
targets
are
8
and
16-bit
microcontrollers.
L
The
implementation
is
based
on
single
MSS
window,
so
this
simplifies
the
implementation
and
by
default
there's
only
enough
memory
for
single
TCP
connection.
So
at
this
point
so
far
it
might
seem
like
riot
TCP.
Implementation
is
quite
similar
to
my
creepy.
However,
it
is
not
as
minimalistic
as
my
creepy
because,
for
example,
the
memory
locate
that
can
be
increased
to
support
multiple
parallel
connections
and
then
there's
an
independent
buffer
provided
for
each
connection
and
also
retransmission
is
handled
by
TCP
itself,
as
opposed
to
what
happens
in
micro
IP,
where
it
is
the
application
developer.
N
Rather,
I
mean
I
beg
to
differ
here,
even
in
case
of
you
IP,
even
in
case
of
micro
IP.
The
TCP
buffers
are
handled
by
the
TC
I
mean
it's
not
application
handles
only
for
UDP.
It
works
that
way.
Participate
won't
work
that
way,
because
there
are
other
sequence,
I
mean
I
mentioned
this
in
my
review
comments
as
well.
Yes,.
L
L
Yeah
yeah,
so
I
agree
with
you
and
the
point
is
then:
the
application
needs
to
have
some
reliability,
so
the
application
layer
cannot
rely
on
TCP
in
this
case,
for
retransmissions
I
mean
I,
agree
that
you
cannot
create,
like
the
whole
TCP
segment
with
the
header
and
so
on.
So
I
definitely
agree,
but
that
means
also
that
the
application
cannot
rely
on
TCP
for
retries.
In
this
case,
I
just.
N
L
L
Okay.
Then,
we
have
also
added
details
on
the
open,
wsn
discipline
tation,
although
this
subsection
is
fairly
shorter
than
the
previous
one.
Overall,
it
is
that
open
wzn
is,
according
to
the
details
we
have
received
is
mostly
equivalent
to
my
crappy
implementation.
It
is
really
minimal
and
as
in
micro
P,
there
is
a
problem
with
not
performing
retransmission,
so
the
application
developer
needs
to
take
care
of
of
this.
L
So
this
is
the
summary
table
where
we
are
trying
to
summarize
the
main
features
and
mechanisms
of
the
different
TCP
implementations
for
constrained
devices.
So,
as
you
can
see,
we
have
filled
in
most
of
the
details
for
the
riot
and
open
WSM
implementations,
and
we
have
also
added
the
rightmost
column
for
tiny
OS.
This
is
currently
just
a
placeholder,
so
tiny
OS
has
been
relevant
in
several
IOT
scenarios,
so
we
plan
to
add
details
on
the
TCP
implementation
of
tiny
OS
as
well
in
future
updates
of
the
document.
L
O
Of
Agincourt
Acharya,
actually
I
have
a
very
generic
question.
The
matter
is
that
closer
to
mic,
I
have
a
very
generic
question.
That
is,
when
the
www
this
worldwide
wave
that
came
into
picture,
then
a
classical
problem
emerged
for
TCP,
which
is
short
flow
on
TCP,
and
there
has
been
several
work
that
has
gone
through
it.
So
it
is
I
mean
only
a
few
segments,
maybe
few
kilobytes
of
data
that
has
to
be
transmitted
and
one
problem.
That
is
the
slow
start
and
the
condition
control
that
actually
created.
O
That
was
actually
not
giving
the
optimal
performance,
both
in
terms
of
utilizing
the
increasing
bandwidth
that
the
the
the
network
was
offering.
So
will
it
be
a
dimension
that
also
needs
to
be
considered
here,
because
there
has
been
work
like
limited
transmit
and
this
kind
of
work,
limited
transmit
was
actually
dedicated
for
I
think
it
was
arrested
three
four
zero
two,
so
it
was
very
old
RFC,
but
these
works
were
a
limit
actually
for
performing
these
or
improving
TCP
performance
for
these
things.
O
O
B
L
Very
good,
yes,
so
I
understand.
We
can
consider
this.
So
in
a
way
we
are
considering
that,
for
example,
in
many
applications
that
would
be
a
sensor
that
is
going
to
be
maybe
trying
to
send
one
data
message
per
hour
for
us
as
long
as
possible.
So
that's
different
from
the
use
case
you
are
explaining
then
I'm
wondering
if
maybe
TCP
first
open
might
be
a
good
solution
here
for
the
use
case,
you
are
yeah.
L
P
So
my
name
is
Michael
Shara
from
a
course
or
row,
but
I'm,
actually
speaking
yours,
ttpm
culture,
I
would
suggest
this
work
and
hope
to
adopt
the
document.
It's
very
clearly
understood
that
work
is
needed
and
but
I
think
it's
heading
into
the
right
direction.
I'm
not
sure
if
the
milestone
day
that
I've
seen
earlier
in
the
chart
is
realistic
because
at
least
in
TCP
n/bar
a
little
bit
slow.
This
reviews,
but
in
general
I
think
this
should
be
adopted
by
this
working
group.
B
A
N
N
So
some
background
the
note,
so
why
is
this
this
kind
of
worker
actually
required
so
in
case
of
multi-hop
networks,
the
node
density
is,
it
can
be
anything
it's
it's
hard,
it's
hard
to
pry
it.
What
the
node
density
can
be
and
the
neighbor
cache
size
in
case
of
a
constraint.
Node
can
be
really
really
small.
It
can
be
small.
Even
if
you
can
allocate
more
in
F
memory,
it
would
be
suboptimal.
So
the
point
is
no
density
is
high.
What
to
do
the
neighbour
cache
is
going
to
be
really
small.
N
So
how
do
you
prioritize
the
entries
here?
How
do
you
prioritize
the
entries
here
and
ensure
which
ensure
the
entries
that
remain
in
the
neighbor
cache
would
result
in
least
churn
of
the
network,
so
when
I
say
churn,
what
I
mean
is
that
it
should
be
possible
to
to
enable
proper
routing
adjacency
so
that
such
that
the
network
paths
don't
keep
on
changing
now.
The
reason
why
this
this
this
work
is
important
is
because
and
if
you're
playing
with
two
or
five
or
ten
nodes
on
a
table
till
that
point
everything
works
out.
N
N
So
there's
one
typical
example
mentioned
by
yo
Keem
on
the
this
was
mentioned
on
the
mailing
list,
but
from
my
perspective,
I
work
for
a
metering
solution
and
the
node
density
can
easily
run
up
to
hundreds
of
nodes
in
the
same
vicinity,
it's
in
sub
gigahertz
mode,
and
it
can
easily
cross
hundreds
of
nodes
this.
So
how
do
you
manage
them?
Neighbor
cache
entry,
so
that
is
what
this
draft
tries
to
solve
the
problem.
N
So
the
considerations
here
are:
it's
a
security,
enable
6lowpan
ripple
Network
for
the
sake
of
explanation.
I
have
used
ripple
as
the
routing
protocol
pana
as
the
access
protocol
and,
of
course,
neighbor
disk
out.
Is
there
so
three
places
where
primarily
the
neighbor
table
update
happens?
Is
the
initial
to
really
be
signaling.
So
before
the
network
formation
comes
into
picture,
you
have
to
authenticate
the
node
to
the
network
and
that's
where
panic
amps
into
picture.
Second,
is
the
repose
parent
selection.
N
Algorithm
third
is
when
the
check,
when
the
routing
child
load
advertises
itself
to
the
network.
Now
there's
one
thing:
I
have
to
mention
here
that
even
though
I've
mentioned
pana
because
I
have
used
banner,
but
the
the
problem
is
also
present
in
case
of
six
stitch
we're.
Currently
there
is
the
PRI
element,
the
prev.
The
panel
element
is
called
as
a
join
proxy.
There
I
mean
the
same
problem.
N
Statement
exists
in
60
shell
as
well,
so
these
are
the
terms
that
are
used
in
case
of
six
station
animal
working
group,
so
the
neighbor
management
operation
I,
will
be
real
quick
here.
It's
the
three
operations,
broadly
insertion
eviction
and
reinforcement
and
the
primary
problem
with
any
insertion
is
you
have
you
will
have
so
the
way
routing
protocol
works?
Is
you.
You
have
a
storm
going
down
spiraling
downwards
downstream,
and
then
you
have
a
Down
messaging
which
comes
upwards.
So
this
is
how
the
downstream
and
upstream
paths
are
established.
N
So
if
all
the
d
io
messages
are
accepted
by
a
child
gets
like
10
euros
from
ten
different
parents,
then
the
table
is
going
to
be
full
in
the
first
place,
so
there
is
no
space
left
for
the
child
entries.
So
how
do
you
handle
this
case?
Eviction
in
case
of
eviction,
if
you
end
up
everything
a
childhood
entry,
it
will
have
a
ripple
effect
on
all
the
other
child
sub
charts
as
well.
So
it's
it's.
It's
not
very
easy
to
evict
a
child
entry.
N
Well,
this
is
true
for
storing
mode
of
operation
only,
but
the
good
news
in
case
of
eviction
for
eviction
for
parent
entries
is
that
you
can
actually
evict
a
non-preferred
parent
now
this
I'm
talking
in
I'm
using
very
specific
terms,
to
ripple
all
right.
So
if
you
have
it
the
non-preferred
parent,
it
is
possible
to
evict
it
without
much
implications
and
I'm
going
to.
N
We
are
going
to
make
use
of
this
particular
intelligence
in
in
the
routing
policy
in
the
neighbor
management
policy
as
well
the
reinforcements
the
link
quality
estimation
has
to
be
updated
over
a
period
of
time.
If
you
can
use
an
active
or
passive
mechanism,
quantity
has
an
active
mechanism
in
the
form
of
active
probing
of
neighbors.
N
Passive
mechanism
can
be
you
over
here,
the
D
IOT's
or
the
other
messages
in
the
network,
and
you
can
update
the
link
estimation
clearing
unused
entries
now.
This
is
also
very
important
because
you
want
to
release
the
neighbor
cache
entry
as
soon
as
possible,
so
as
to
so
that
it
can
be
allocate
to
something
else.
So
in
case
of
storing
mode
of
operation,
route
invalidation
is
is
important
because
routing
entries
are
directly
mapped
to
the
neighbor
cache
entries
in
case
of
knowledge.
Non
storing
mode
of
implementation.
N
You've
got
to
deregister
using
NS
with
lifetime
of
0,
while
not
many
implementations
do
that
currently
and
in
case
of
PRA
neighbors.
There
is
an
interesting
question,
actually
I'm,
not
sure
whether
whether
six
station
has
a
way
to
handle
this,
but
there
is
no
way
currently
in
Penner
to
know
for
the
relay
element
to
know
whether
the
authentication
has
been
completed
so
that
it
can
ever
or
it
can.
It
can
just
delete
the
neighbor
cache
entry
so
that
it
can
be
used
for
something
else.
N
So
what
we
propose
is
a
reservation
based
policy
where
few
few
amount
of
so
the
reservation
is
done
for
routing
child
entries,
the
parent
entries
and
the
PRU
are
sessions,
or
otherwise
we
call
it
other
other
sessions.
Basically,
one
good
thing
about
this
reservation
policy
is
that
if,
if
the
routing
child
entries
are
unavailable
or
not
present,
then
the
parent
and
seats
can
still
occupy
the
whole
table
because,
like
I
mentioned
before,
non-preferred
parent
eviction
can
be
done.
N
Well,
whatever
mechanism
I've
mentioned
just
now
is
or
reactive
what
I
mean
by
reactive
is
that
if
the
table
space
is
actually
not
available,
you
send
a
message.
For
example,
you
send
a
down
message:
the
parent
is
going
to
reply
back,
saying
that
I
don't
have
a
space
just
check
on
with
some
other
parent,
a
parent
node,
and
it's
going
to
fail
the
problem
with
this
kind
of
approaches.
N
After
some
time,
the
same
previous
parent
is
going
to
send
this
d
io
message
and
since
the
child
has
lost
its
taste
information,
there's
no
way
for
it
to
know
that
you
know
it
can't
go
to
that
parent.
So
in
case
of
ripple
right
now,
there
is
no
way
to
know
that
the
table
space
is
all
utilized.
So
as
of
now,
whatever
we
have
mentioned
in
the
draft
is
all
reactive,
but
it
has
its
limitations
that
that's
what
the
slide
talks
about.
N
So
in
a
way,
what
we
want
is
want
is
a
parent
node
to
signal
in
some
form
to
the
child,
node
saying
that
I
still
have
table
space
available
now
six-stage.
Does
this
there's
an
ask
beacons
which
has
this
bit,
which
says
that
I'm
still
the
join
proxy
I'm?
Still
the
router?
You
can
connect
through
me,
but
this
kind
of
information
is
missing
in
in
the
ripple
and
I
feel
it
might
be
useful
there
as
well.
So
this
is
what
I
mean
by
the
proactive
wave.
Q
Q
So
it'd
be
really
nice
if
that
was
actually
in
there
at
that
level
too,
and
maybe
we
have
to
put
it
in
both
in
the
DI,
oh
and
in
the
name
in
the
router
advertisement
and
of
Carson
has
an
opinion
of
it
where
it
goes.
But
it
mean
there's
a
protocol
action
here
about
this
and
if
you
pick
wrong,
then
you
know
poor
little
unpowered
devices
that
turn
on
once
a
week
are
screwed
because
they're
never
in
they're,
never
LR
you'd
into
the
cache.
So.
N
R
Q
R
Okay,
well,
if
it's
needed
by
both
and
then
it's
enable
discovery,
because
Deborah
discovery
is
received
by
both.
R
B
B
R
Q
Q
Great
yeah,
Michael,
Richardson,
II
and
I
think
I
would
agree.
So
I
would
suggest
all
of
the
advice.
Okay
in
this
document,
be
it
maybe
needs
to
update
six
seven,
seven,
five,
okay,
I,
don't
know
I,
don't
know
you
guys.
Let's
say
that's
the
list,
maybe
but
that,
but
that
the
proposal
for
it
for
for
the
additional
metrics
that
we
need
should
be
a
new
document
in
six
low
and
four
or
a
a
proposed
text.
265
775.
This
should
be
working.
N
B
I
G
Hello,
can
you
hear
me?
Okay,
okay,
so
I'm
here
to
present
a
bit
more
of
a
research
work?
It's
not
really
an
ITF
document,
but
I'm
presenting
here
it's
about
an
implementation.
We
did
on
a
group,
I
client.
The
group
Ike
is
another
draft
which
is
going
to
be
standardized
I,
guess
quite
soon.
The
authors
are
here
so
yeah.
F
G
Channel
between
client
and
server,
this
is
completely
standard
Ike
and
it's
also
minimal
Ike,
so
minimal
I
really
helped
in
this
implementation.
The
second
part
is
actually
just
to
request
secure
keys
from
the
group
server,
which
is
also
mostly
the
same
as
to
I.
Guess
a
I
calls
in
with
you.
It's
just
that
you
don't
negotiate
a
key
because
you
get
from
the
server,
that's
the
main
difference,
so
you
ask
for
a
group
key
and
you
get
one.
It's
not
a
negotiation
of
a
key
and
three
King
is
basically
the
same.
G
We
implemented
this
in
riot.
We
figured
out
that
we
need
around
six
kilobyte
of
memory
to
run
this,
including
yeah
the
ciphers
to
be
stored
for
them
actually
doing.
Group
message
like
securing
group
messages,
for
example,
with
est
or
Aeterna
to
15.4
or
whatever,
and
we
tested
this
on
three
different
devices
with
jars
three
Arduinos,
so
it
works
on
every
m0
device
which
has
the
arm
in
Syria.
G
Q
G
Yeah
we
we
run
this
code
again
still
names
and
implementation.
We
found
it's
just
a
Cisco
Rooter.
The
results
I
think
are
pretty
good.
The
big
chart
here
is
the
diffie-hellman
which
the
elliptic
curse
to
mention
that
so
the
crypto.
We
use
this
a
s
for
encryption
to
hot
hmx,
for
integrity
and
PRF,
and
what,
if
you
have,
we
use
a
elliptic
curve?
You.
F
Know
that's
what
I
was
wondering
which
is
missing
in
the
table
of
paths,
and
it
relates
to
the
comment
that
Mikey
had
or
a
question
mark
yet
because
if
you
use
it,
if
you
ham-
and
you
need
the
big
lamb,
bignum
library,
that
typically
were,
if
you
want
to
have
any
reasonable
performance
that
will
require
a
fair
amount
of
RAM,
which
is
only
temporarily,
but
you
did
needs
to
be
there.
Otherwise
stuff
would
not
end
that's
sort
of
missing,
so
you
need
that's
why
the
32
kilobyte
brand
device
was
able
to
handle
this.
F
G
So
yeah
that's
and
what
I
want.
So
this
thing
only
happens
once
at
the
beginning
of
the
session.
So
yeah,
that's
reasonable
amount
of
time,
I
guess
for
establishing
your
group
communication
so
yeah.
What
could
we
do
for
minimal,
minimal
ization
for
this
I
think
pretty
much
everything
is
done
by
minimal
Ike
already,
except
that
there
is
a
bit
of
modification
from
the
I
cost
to
the
GSA
arson.
G
Tegu
cheers
Araki
just
because
it
has
another
meaning
here
and
what
would
be
also
helpful
to
have
recommendations
on
like
how
to
configure
the
server
so
that
the
actual
group
sa
auth
message
is
kind
of
minimal
as
well
so
yeah.
The
question,
though
we
have
an
implementation
available
for
iOS
I
know
that
there
is
an
implementation
or
I
heard
that
there
is
an
implementation
for
Kentucky,
which
is
going
to
be
Lee's
released
soon.
I,
don't
I've
not
seen
it
and
yeah.
G
G
B
B
G
F
Wish
you
have
come
earlier
because
we
actually
have
work
on
going
and
group
communication
security
in
the
ACE
working
group,
an
extremely
painful
process,
and
they
are
we
had
you
if
you
could
have
implemented
that
one.
It
would
have
been
such
a
great
sort
of
benefit
for
the
community
and
unfortunately
been
for
the
wrong
thing,
I
think
for
foot
for
a
couple
of
reasons.
The
first
one
is.
It
refers
to
a
document
that
apparently
is
an
individual
document.
F
I,
don't
know
what
the
status
of
that
other
document
is,
whether
that
will
actually
be
adopted
in
the
idea
of,
and
then
the
minimum
actually
doesn't.
Do
you
a
favor
here
if
you
look
at
the
discussion
that
we
had
in
is
there's
a
fair
amount
of
interest
to
also
add
the
authorization
capabilities
and
to
add
public
key
cryptography
to
the
whole
equation,
to
make
it
resistance
against
certain
certain
attacks.