►
From YouTube: IETF104-6TISCH-20190325-1120
Description
6TISCH meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
Right
good
morning,
let's
get
started,
we
we
have
a
very
short
one-hour
meeting,
so
we're
a
little
bit
little
bit.
We
have
a
packed
agenda
before
we
get
started.
I
need
to
remind
everybody
of
the
note.
Well,
the
motel
applies
to
this
meeting
at
applies
to
any
ITF
meeting.
If
you
know
of
any
IPR
that
we're
discussing
you
have
to
disclose
it,
whether
it
is
yours
or
not,
read
the
slides
read
the
documents
that
are
listed
here.
If
you
have
any
questions,
ask
your
favorite,
ad
or
workgroup
chair
reminder
we're
taking
minutes.
B
So
thank
you
very
much.
Dominique
Farris
and
Charlie,
who
are
taking
minutes.
I,
believe
that
charlie
is
also
the
mythical
scribe.
You're
not
can
take
away.
Can
you
be
the
mythical
okay
you
just
have
to
connect
to
me.
Take
one
just
in
case
there's
a
question
related
to
the
to
the
microphone
we're
taking
we're
recording
this
meeting
and
presence
is
logged.
All
of
that
will
be
published
to
the
mailing
list.
After
so
more
participation
mailing
list
reading
materials.
These
are
links
that
you
can
consult
offline.
B
The
slides
are
online
they've
been
online
for
a
couple
of
hours.
We've
just
started
two
slides:
they
should
appear
with
little
bells
next
to
the
meeting
materials,
and
that
was
three
hours
ago.
So
this
is
the
agenda
that
we
have
prepared.
We're
now
in
the
intro
on
status,
will
then
go
into
a
quick
presentation
about
the
architecture
draft
the
table
will
give
militia
will
have
a
ten
minute
slot,
then
to
talk
about
minimal
security
and
and
in
particular,
I
think,
you'll
focus
on
some
comments
that
you
haven't
made
recently
on
the
mailing
list.
B
We
didn't
have
a
section
on
dynamic
scheduling
with
thing
Fay
talking
about
MSF
MSF,
who
was
published
on
the
11:00
of
March,
and
then
we
have
Marco,
whose
is
Michael
around
Thank
You
Marcos
they're
talking
to
us
about
an
individual
submission
called
robot
scheduling.
We
didn't
have
two
other
drafts
from
Michael
Richardson
I'm.
Sorry
before
that.
B
Yeah
one
draft
for
Michael
Richardson
on
enhanced
beacon,
and
then
we
have
two
updates
one
on
the
open
benchmark.
That
border
will
give
us
this
border
around.
Yes
right
there
and
then
I'll
come
up
the
hackathon.
That
thing
say
will
give
us
at
the
very
very
end.
This
should
bring
us
to
twelve
twenty,
which
is
the
end
of
the
the
end
of
the
meeting
you
wanna
take
over
back
up.
C
Yes,
I
realized
I
did
not
update
this
agenda.
We
had
some
agenda
bashing
and
if
you
look
at
the
other
night
agenda,
so
maybe
tomorrow,
when
you
come
back
agenda,
we
actually
moved
Michael
Richardson's
presentation
down
to
the
very
end
of
the
of
the
meeting,
because
he's
I
think
an
ISO
meeting
and
he
well,
he
promised
it
would
be
here
around
noon,
so
Michael
will
will
be
in
the
last
ten
minutes.
C
C
As
you
know,
six
dish
is,
is
building
this
all
stack
of
RFC's
and
I
Triple
E
standards,
so
that
we
can
prove
that
the
stack
works
using
real
devices
in
drop
tests
with
the
Etsy,
and
so
we
as
we
as
we
do,
that
we
mostly
push
work
to
external
bodies,
I
Triple,
E
and
six
lower
row,
etc
and
part
of
those
things
that
six
dish
kind
of
promote
it
pushed
into
other
working
group.
Is
this
six
lower
RFC
66
67
25
had
eight
draft,
which
is
now
published
as
RFC
age
505.
C
So
that's
what
that
kind
of
an
outcome
for
60s.
Well,
then
militia
will
tell
us,
but
they
were
meeting
about
a
score
on
which
we
have
a
dependency
for
the
minimal
security
and
well,
this
progressed
well
in
the
recent
there
is
actually
weeks
and
days
so
very
good.
On
that
side
we
also
have
a
dependency
on
a
doc.
C
C
It
goes
to
proof
yeah,
so
we
have
done
with
with
her
score,
and
so
our
dependency
on
the
score
is
kind
of
done.
A
doc
is
not
such
good
news
for
I
know,
it's
told
we
don't
have
a
dependency
form
anymore,
but
we
have
a
dependency
for
zero-touch.
That's
how
I
understand
it
and
you're
a
list
of
the
case.
Adele
said
505
was
published,
but
there
are
many
others
that
you
know
the
document
that
kind
of
inherit
from
work.
C
That
was
the
net
six
dish
to
make
the
whole
story
work,
and
so
there
is
a
status.
We
don't
have
much
time.
We
have
onion
our.
So
one
goes
with
that,
but
the
work
at
six
low
is
progressing
very
rapidly
AP
and
D
and
backbone.
Router,
past
work
or
class
cause
that's
very
good
result
and
the
fragmentation
work
is
very
close
to
worker
Pascal
as
well.
I
guess
for
the
milestones
relate,
but
we
are
not
that
late.
We
decided
to
merge
the
terminology
into
the
architecture.
We
actually
pushed
the
architecture
of
a
publication.
C
We
had
only
reviews,
pre
is
you
reviews,
I
would
say,
and
they
were
addressed
so
now
we
are
waiting
for
the
for
iesg
set
of
reduced
or
the
architecture.
Zero
touch
is
definitely
light.
We
are
looking
for
co-authors
and
Michael
will
tell
us
about
that
and
we
more
security
pass.
The
subsequent
walk
up
last
call:
we
got
some
interesting
commands.
Many
shall
tell
us,
we
have
a
question.
Oh
Suresh,.
C
A
D
E
I
think
the
the
the
key
here
the
content
of
the
document
is
very
good.
The
only
issue
is
whether
you
there
were
a
couple
of
issues
around.
Do
you
need
a
glossary
of
terms?
You
have
like
three
separate.
You
know
you
got
a
reference
section
in
the
front:
a
glossary
of
partial
glossary
from
other
places
and
and
another
velocity
like
there's
a
certain
amount
of
editorial.
E
C
C
D
C
Okay,
she
want
to
talk
about
that
piece.
The
the
initially
document
was
intended
for
informational
and
then
we
did
that
net
deterministic
networking
architecture
and
Lou
Berger
insisted
that
this
one
goes
into
standard
truck
and
the
reason
was
because
it
impacts
other
bodies
like
the
I
Triple
E,
and
he
said
we'll
get
a
better
set
of
reviews
if
we
go
faster
on
a
track,
so
he
pushed
for
that
and
I
said
hey.
C
D
The
reason
I'm
asking
is
because
they
did
net
dark
stocking
for
the
exact
same
reason
in
the
iesg
valve,
and
that's
why
I'm
bringing
this
up.
So
if
you
look
at
it,
it's
been
stuck
for
like
more
than
a
month
now
and
if
you
see
a
lot
of
the
is
position,
that's
like
EE
criticisms
of
the
draft,
so
that
let's
have
a
longer
discussion
about
this
Pascal
and
I
will
try
to
do
a
resolution
of
that.
Okay,
okay,.
C
C
We
need
to
discuss
whether
it
star
Trak
of
informational,
so
the
gold,
this
particular
document,
is
to
provide
another
view
of
what
the
worker
group
has
been
doing
of
other
years.
So
we
maintain
this
document
each
time
where
the
decision
is
time.
We
added
some
mortgage
that
we
did
something.
We
actually
wrote
it
in
the
architecture.
So
if
you
follow
the
architecture,
sense
assumption
of
the
working
groups,
you
will
find
everything
we
did
and
how
we
progressed.
C
It
is
really
catching
two
pieces,
the
eye
level
architecture
for
people
who
just
need
that
level,
and
then
you
can
go
deeper
into
how
we
do
and
what
we
wanna
do
in
Section,
four
and
part
of
the
review
I
got
home.
Colors
actually
was
to
Anne
Elliot
was
to
reorganize
that,
because
some
pieces,
maybe
which
Ryan
sections
we
belong
to
for
and
and
the
other
way
around,
so
there
was
a
bit
of
reshuffling
after
the
work
replace
go
into
what
goes
in
three
and
four,
but
the
text
itself
was
mostly
unchanged.
C
So
thanks
Carol
else,
thanks
Elliott
the
big
question
that
we
have
now
a
deal
yacht
alluded
to.
It
is
the
fact
Suresh
that
we
decided
to
merge
the
terminology
document,
which
was
a
separator
of
C
button
called
into
the
architecture,
and,
as
we
did
that
this,
the
section
you
know
that
gives
basically
the
terminology,
references
and
the
acronyms
for
six
low
things
like
six
are
etcetera
as
a
big
section,
which
you
know
surprised
idiot,
because
it
has
all
the
sixties
terms,
also
as
a
subsection
of
the
term
energy
section.
C
D
E
E
They
were
being,
in
some
cases
redefined
in
line
in
the
text,
meaning
to
slight
conflicts
and
Pascal
cleaned
that
up
in
the
review,
by
the
way
which
was
good,
and
then
there
was
there
was
document
there
was
information
pulled
in
from
one
from
another
document
which
was
in
a
separate
section.
Oh,
it
was
finis
Agustin
see
so
kto
lied
this
section.
The
other
point
I
was
going
to
make
was
the
references
that
were
listed
up
front
is
ink.
That's
in
congruent
with
how
we
do
RFC's
references
go
on
the
back.
C
The
reference
that
are
on
the
top
of
the
Tommy
areaa
reference
I
mean,
if
you
want
to
understand
the
text
below
you
need
to
read
this
terminology
document.
So
it's
not.
The
full
set
of
reference
was
just
the
terminology:
dogs
like
the
one
from
Caston,
etc,
other
ones
from
6lo.
So
it
was
external
terminology.
It
was
not
the
rest
of
the
references,
people.
E
Our
series
so
I
mean
I
view
that,
as
just
a
consistency,
thing
and
and
truth
be
told,
I'm
not
gonna
stand
on
my
head
on
any
of
this
right.
It's
you
know.
The
working
group
can
just
go
whichever
whatever
direction
it's
going
to
go
as
an
external
person
who's
just
reading
the
document
for
the
first
time
that
I
found
I
was
immediately
synchronize.
E
C
The
goal
was
to
say
there
is
terminology
in
those
documents
that
I
won't
repeat
in
my
documents,
so
the
links
are
there,
but
usually
you
don't
read
but
I
mean
I
would
like
other
feedback
from
other
readers.
That
would
be
perfect
because
I
understand
the
question,
but
I
don't
know
really
how
to
resolve
it.
C
D
A
suggestion
Pascal
and
Elliot
right,
so
what
you
can
do
is
like
you,
you
have
the
list
of
terms
right.
So
as
long
as
all
the
references
are
covered
in
the
nominative
references,
I,
don't
think
you
have
to
do
anything
more,
so
I
expect
fusion
and
I
kind
of
agree
with
them.
So
if
you
just
make
sure
that,
like
the
terms
that
you're
using
from
the
other
documents
are
listed
in
the
terminology,
I
think
we
should
be
okay.
C
Understand
from
Suraj,
if
I
understand
what
Suresh
told
me
because
I'm
not
100%
sure,
so,
if
I
may
quote,
I'm
gonna
remove
the
external
references
from
the
terminology
section
and
try
to
extract
the
terms
that
are
needed
from
there
and
include
them
in
our
terminology.
Is
it
the
solution
so
Russia?
Is
it
like.
D
And
with
the
reference
with
the
actual
reference,
it's
like,
you
should
say
like
okay,
like
be,
for
example,
if
you
want
to
say
Pio,
Pio
s
define
as
defined
in
RFC
48
61
directly
in
the
terminology
section,
instead
of
putting
in
another
reference
section,
because
that's
what
threw
off
Elliot
okay.
So
we
can
discuss
this
on
the
ship,
Thanks
yeah.
E
B
F
Alright,
ok,
so
I
have
a
$10,
so
slides,
but
I'll
focus
in
the
major
issue
that
was
focused
that
was
brought
up
by
your
on
last
night
on
the
on
the
list.
Essentially,
we
published
oh
9
after
the
ITF
103
meeting
in
Bangkok
the
meet,
then
we
had
a
second
working
group
last
call
some
sometime
early
March,
which
ended,
and
we
received
one
review
from
your
own
so
under
which
I
ride
yesterday
outlining
one
more
issue
that
seems
to
be
pending.
F
So
this
will
be
the
mayor.
The
goal
of
my
presentation
to
today
be
essentially
to
just
give
a
quick
summary
of
the
changes
in
online
and
this
issue
that
that
you're
on
brought
up
as
a
side
note
I
usually
finally
approved
the
score.
So
we
are
good
to
go
in
terms
of
minimal
security
as
we
have
a
heavy
dependency
there.
F
So,
in
terms
of
updates,
you
know
9,
we,
we
removed
their
network
identifiers
from
drawing
response
in
order
to
simplify
the
structure.
Now
we
required
that
the
6lb
our
pledge
be
provisioned
by
the
network
identifier
before
it
attempts
to
join
using
concern
joint
protocol
with
the.
So
essentially,
this
is
just
the
deployment
requirement.
F
F
So
now
I'll
go
through
the
working
group
last
comment,
so
the
first
two
slides
are
just
a
minor
comments
that
I
will
really
quickly
cover
essentially
you're
an
outlined
some
well
some
myths
in
the
in
the
text.
The
first
one
was
on
on
one
sentence
that
was
regarding
the
increment
of
the
sequence
numbers
when
given
pledge
joins
two
different
networks.
So
essentially,
there
were
used
to
be
a
sentence
saying
that
the
sequence
numbers
obviously
should
must
be
incremented
as
we
want
to
avoid
nonce
reuse.
F
So
we
were
just
going
to
rephrase
this
to
make
it
more
general
and
just
to
adhere
to
to
do
our
hearts
back
then.
The
second
comment
was
on
also
some
also
the
myth
on
the
on
the
ask
on
the
user
for
score.
So
we
have
a
proposed
resolution
that
was
here
brought
by
your
on
which
I
will
take
into
consideration
for
the
next
version.
F
And
yes,
the
no
score
had
an
update
regarding
the
the
update
of
sequence
numbers
in
their
storage
in
persistent
memory.
So
right
now
we
need
to
update
the
reference
and
also
to
essentially
in
in
terms
of
minimal
security,
we're
just
we're
just
piggybacking
on
Oh
score
spec,
relying
one
on
this
on
section
on
appendix
B,
1
1.
F
So
now
I'll
go
with
the
issue
that
you're
on
outlined.
This
is
this:
is
this
issue
was
originally
brought
up
by
Jim
shot
during
the
first
working
group?
Last
call
and
the
scenario
that
we
are
considering
is
that
there
is
a
failure
event
of
the
jrc,
in
which
case
the
jrc
loses
all
the
mutable
parameters
that
can
be
stored
on
this.
That
can
be
stored
in
in
in
data
memory,
but
it
still
has
access
to
the
database
containing
the
pre-shared
keys
of
the
different
plunges.
F
F
The
new
nodes
had
preserved
the
mutable
context
parameters.
So
there
are
no
known.
There
is
no
known
CPUs,
but
you're
an
outlined,
a
problem
with
this
procedure
in
terms
of
a
possible
replay
attack
on
the
jrc,
where
the
attacker
could
essentially
replay
one
on
the
of
the
early
drawings.
So
this
is
what
I
will
show
in
the
in
the
following.
So
essentially,
what
you
see,
which
is
in
the
top
spy
during
the
day,
are
see
the.
F
Essentially,
the
knowns
that
is
used
here
is
an,
and
the
key
used
for
encryption
is
the
key
of
the
pledge.
The
response
is
sent
using
the
same
sig
using
the
same
sequence,
number
button.
There
are
different
keys.
All
of
this
is
fine,
and
then,
after
that,
after
the
drawing
the
plot
becomes
a
drawing
node
that
are
covered,
there
are
several
possible
parameter.
Update
requests
coming
from
the
jrc
to
the
pledged
incrementing,
the
sequence
number
m
on
the
side
of
the
jrc.
That
pledge
keeps
track
in
order
to
detect
replace.
F
So
now
there
is
this
event
of
the
jrc
failure
that
you
see
on
the
right
and
essentially,
as
I
said
PSK.
The
assumption
is
that
fresh
artis,
the
database,
the
free
Sharky's,
is
preserved
and
but
that
the
mutable
parameters,
like
a
sequence,
numbers
are
lost,
and
now
so
essentially
the
jrc,
and
this
stage
does
not
have
the
sequence
number
nor
the
replay
window
that
it
should
accept
on
the
behalf
of
the
pledge.
So
what
can
happen
is
that
the
attacker
here
can
a
replay.
F
F
F
We
have
a
couple
of
ways
forward
and
with
the
latest
updates
to
do
scores
back
what
what
was
introduced
in
inner
score
is
an
appendix
B
dot
2,
which
specifies
the
challenge
response
based
mechanism
for
key
exchange
based
on
a
pre
shared
key.
You
know
that
compliments
of
score
that
we
can
use
in
order
at
trigger
this
mechanism
at
the
GRC
by
knowing
that
there
was
a
failure
event
in
order
to
rekey
the
context
so
now
in
terms
of
the
other
dollar
head
munication
overhead.
F
G
F
So
I
mean
this
is
not
specified
in
our
score,
which
is
an
advantage
that
got
approved,
so
it
would
be
very
easy
in
terms
of
the
spec
in
space
6
dish.
The
only
downside
we
have
identified
so
far
is
that
if
we
were
to
use
this
mechanism
of
for
score,
we
would
no
longer
be
compatible
with
the.
There
would
no
longer
be
the
lightweight
implementation
option
that
is
currently
identified
in
Appendix
B
of
minimal
security.
F
Just
as
a
reminder,
this
lightweight
implementation
option
allows
us
to
get
away
without
the
implementations
of
sha
and
it
KDF
in
firmer
and
by
deriving
the
session
keys
at
provisioning
time
of
the
pledge,
and
essentially
what
pledge
ends
up
with
is
the
session
key
is
provisioned
and
it
uses.
So
now,
if
we
were
to
use
this
challenge
response
mechanism
in
appendix
B
to
a
fourth
core,
essentially
we
would
need
the
we
would
need
the
HKD
of
implementation
if
error.
F
B
Domo
so
Dana
as
contributor.
So
from
what
you're
saying
it
looks
like
option,
two
is
not
you
know
it
doesn't
present
enough
advantages
over
one
or
three,
and
so
from
the
from
the
the
three
options
that
you
present.
It
looks
like
you're,
you're,
saying
one
or
three
are
realistic.
Two
is
not
that
realistic
and
I
understand
expected.
F
Yeah
so
option
two
will
require
a
bit
of
more
trip
to
work
on
in
in
minimal
security
and
ifs,
of
course,
can
introduce
the
lies
in
terms
of
the
interest
in
terms
of
the
document,
and
it
would
be
custom
to
success.
So
this
would
be
a
procedure
that
is
specific
to
the
six
dish
use
of
force.
Court,
okay,
yeah.
B
B
And
the
okay
and
then
in
option
one.
We
have
a
mechanism,
that's
already
defined
enough
score,
that's
correct
which
allows
us
to
recover
from
that
at
the
additional
cost
of
hat
a
little
bit
of
code
inside
the
moat,
in
particular
H
KDF,
and
today's
shop
is
a
correct
in
the
script,
and
so
the
additional
code
means
larger
footprint
and
larger
time
to
update
over-the-air
Thanks.
B
How
do
you
say
that
optional
so
that
in
case
you
have
that
implemented,
you
can
you
can
recover
otherwise,
you're,
just
you
just
you
know
it
doesn't
work.
And
the
second
question
is
we
had
the
discussion
as
before:
do
we
need
sha-1,
or
can
we
do
something
with
h,
KDF
around
AES
rather
than
sha-1,
and
what
what
kind
of
effort
are
we
looking
at.
F
Yes,
in
terms
of
the
first
question,
essentially,
we
I
think
we
could
that
this
would-
and
this
will
boil
down
to
saying
in
case
your
firmware
is
deployed
without
the
challenge
response
mechanism-
go-go
reprovision,
all
their
devices
..
This
is
a
if
it
happens
that
your
firmware
has
the
edge
KDF
and
the
whole
head
KDF
in
implemented.
Yes,
you
can
run
this
particle,
so
I
I
think
we
are
still
in
terms
of
interoperability.
We
are,
there
is
no.
There
is
no
problem
with
into
for
question
two
for
HK
D
F.
F
So
currently
the
default
HK
D
F
of
a
score
is
based
on
sha.
I
was
made
aware
by
the
other
authors
that
essentially,
we
can
use
an
algorithm
that
is
defined
in
cozy,
where
HK
D
F
relies
on
the
AES.
As
on
the
char
on
the
hash
function
based
on
AES
and
this,
the
changes
required
would
essentially
just
be
a
referencing,
an
algorithm
in
another
spec.
So
what
one
sentence.
G
H
H
F
B
B
I
think
that
we
have
progressed
a
little
bit
in
understanding
options,
one
two
and
three,
and
and
that
you
know
I
understand
as
a
chair
that
this
is
not
redesigning
the
food
world,
but
it
is
referencing
different
things,
so,
I'm
happy
from
that
point
of
view
and
I'm
happy
to
hear
that
Oscar
or
that
that
we
have
some
summation
ADF
wrappers
around
yes
as
well.
That
would
basically
simplify
the
code
in
terms
of
whom,
if
we
go
with
option,
one
I
suppose
yeah.
If
we
go.
B
I
The
main
update
from
this
version
is
we
introduced,
surely
an
unshared
autonomous
style
concept
and
also
we
resolve
the
pending
issues
listed
in
the
previous
version
and
to
a
row
revised
and
after
that,
I
will
give
a
valuation
of
the
MSF
performance
so
for
the
non-shared
and
for
this
M
as
a
massive
versions,
zero
you
introduced
a
now
share
and
shared
autonomous
cells.
I
will
use
a
example
to
introduce
how
it
works
so
for
in
the
picture.
In
the
figures
from
the
left
side,
there
are
four
nails
and
the
different.
I
I
So
the
node
1
will,
using
the
same
same
cell,
to
transmit
to
the
joinery
response
and
or
6
who
responds
back
to
the
to
the
south
and
later,
if
the
no.3
and
no.4
trying
to
join
no
as
a
parents
or
as
such
drawing
proxy,
those
two
nose
will
install
the
autonomously
ourselves.
According
to
the
note
grass
of
the
note
dress
of
a
note
and
the
bigger
this
cell
is
the
shared,
so
only
one
only
once
the
packet
from
either
a
nose,
relearn
or
for
I
say
no
and
then
no
will
reply.
I
The
drone
response
or
it
60
responds
to
one
of
the
notes
and
the
later
another
note
will
try
again
because
there's
a
autonomic
shared
self
and
hence
it
will
finish
to
this
drum
process
or
the
60-year
transaction.
More
sense.
So
there's
a
a
list
of
a
pending
issue
from
the
preservation,
and
this
is
the
issues
we
already
roast
resolve
the
most
with
no
result
and
there's
three
lacing
there.
But
the
main
discussion
is
already
in
many
lists,
but
I
will
focus
on
the
following
comments,
which
is
from
yes,
Yauch
who's.
I
Giving
the
corner
on
the
version
I
would
talk
about
it
this
more.
So
the
first
issue
is
the
security
issue
on
the
neighbor
caching
during
tone
process.
This
means,
if
you're
not
trying
to
join
between
a
drum
proxy
and
the
job
proxy,
will
install
those
neighbor
entry
into
the
Intuos
neighbor
cache,
which
is
defined
in
the
minimal
security.
F
So
just
a
comment
on
that
and
minimal
security:
there
is
a
net
configuration
section.
Basically
that
says
that
gives
recommendation
that
we
should
keep
a
separate
entries
for
insecure
and
secure
entries
such
that,
if
there
is
an
attack,
only
the
basically
the
insecure
entries
do
not.
Inflow
is
not
flood
over
to
the
to
the
secure
to
the
notes
already
that
that
are
already
in
the
network.
Yeah.
So
I
think
this
text
already
covers
this
and
we
we
might
just
reference
the
section
of
animal
security,
yeah.
J
Touch
yes
in
via
yeah,
so
you
do
to
find
out
the
Institute
at
that
section
or
the
skip
mini
mall
security
or
framework.
But
my
comment
is
the
join
request
would
fill
up
the
the
schedule,
the
memory
for
the
schedule,
those
cells,
so
we
may
need
to
have
some
comment
on
the
security
concerns
with
section
about
the
heart
to
prevent
filling
up
the
schedule.
I
I
F
To
make
the
just
to
make
militia
change
from
here,
just
don't
make
this
clear
you
are
talking
about.
You
are
essentially
saying
that
the
pledge
that
this
text
is
generic
enough,
that
the
pledge
can
be
recognized
as
there's
another
neighbor
and
add
that
is
the
okay.
Okay,
a
matter
of
clarification
in
the
dunyah
yeah.
I
I
missed
general,
it's
a
question
thanks
for
a
clarify,
and
so
the
the
second
issue
is
in
known.
Trust
package
should
be
counted
on
the
for
adapting
yeah
I
agree
with
that
and
the
protocols
the
packet
invitation
specific.
So
the
solution
is
either
we
remove
them
or
we
change
the
term
recommend
master
by
shoot.
This
is
under
discussion
and.
I
So
is
no
and
another
one
is
and
clear
for
how
we
implemented
the
trigger
timer,
with
a
rated,
limiting
I
think
it
will
just
a
change
removed
with
Britta,
limiting
just
using
the
tribute
hammer,
40,
IO
and
yeah.
So
there
are
other
issues
and
to
say
actually
talk
is
already
in
that
memorized
so
we'll
discuss
later
and
for
a
devaluation.
I
We
were
trying
to
push
more
higher
up
here
with
this,
and
this
is
a
performance
of
the
cell
usage,
or
so
you
can
Mosul.
Most
of
the
nose
actually
is
a
controller
between
25%
SM
type,
5%
percentage
and
for
the
lowest
one
is
a
have
low
traffic
is,
will
kind
of
a
low
cell
usage
and
for
the
highest
one.
You
can
see
the
cell
years.
We
are
changing
over
time,
but
is
over
always
a
controller
within
this
75%
and
febris
into
which
is
the
special
parameter
we
configured
when
using
MSF.
I
B
E
B
The
ninety-six
percent
is
because
of
heart,
essentially
firmware
bugs
so
that
thing
yeah
how
to
progress
this,
so
this
has
been.
You
know
thanks
for
evaluating
this,
we
have
two
implementations
that
they
felt
that
they
use
it
straight.
I
propose
that
you
guys
integrate
that
the
comments
push
the
next
version
and
the
that
next
version
should
be
close
to
ready
for
a
working
class
call
I.
B
C
Yes,
what's
nice
usually
is
to
find
one
two
person
in
the
room
who
are
all
ready
to
do
an
early
review
of
the
document?
So
it
would
be
great
that
when
thankfully
pushes
the
document,
one
or
two
persons
are
in
the
room
are
ready
to
read
it
right
away
and
give
you
know,
pre,
work
or
class
call
commands
or
something
all
there
voluntaries
in
the
room.
We
would
just
do
that
yeah.
It
may
be
another.
C
K
Hi
marketing
authorize
I'm
going
to
give
you
some
quick
update
on
this
draft
about
about
scheduling
for
selective
jumping
sisters
networks.
Just
to
recap.
The
document
in
fact
presents
an
attack
and
the
solution
against
that
attack
essentially
is
about
targeting
a
number
of
nodes
in
the
network
and
in
a
first
step
once
and
for
all
derive
their
full
communication
pattern
and
after
that
starts
actually
joining
their
traffic.
That
can
be
essentially
entirely
killed.
K
Will
effectiveness
in
a
stealthy
way
and
low-power
way,
of
course,
Mon
that
later
on
the
benefits,
and
then
we
propose
a
solution
against
this,
so
that
all
the
nodes
in
the
network,
of
course,
in
a
consistent
way,
observe
a
randomly
shuffle
the
cells
they
use
for
communication
at
each
slot
frame
regardless
the
original
schedule
they
started
from
produced
with
whatever
schedules
are
going.
We
are
agnostic
about
that
here
and
I.
K
Think
is
that
in
order
to
do
that,
the
network
nodes
engage
only
local
computation,
so
there's
no
additional
communication
they
they
have
to
take
for
this.
The
result,
of
course,
is
a
practical
news
schedule
to
preserve
for
communication,
which
is
still
collision-free
consistent
and
now
it's
also
unpredictable
for
this
versa.
So
the
original
attack
is
neutralized.
K
This
was
firstly
presented
in
bangkok
and
we
got
some
feedback
comments.
Requests
for
clarifications
of
the
updates
are
mostly
about
that.
In
fact,
we
clarified
whether
the
attack
importance
this
is
about
tearing
down
traffic
of
selected
nodes
in
the
network.
The
adversary
can
do
this
so
essentially
minimizing
the
exposure
enhance
the
there
is
to
be
detected
compared
to
alternative
forms
of
jamming.
K
We
better
qualified
well,
together
with
this
I,
can
say
the
adversary
model
versus
external
can
join
one
or
more
network
nodes
in
the
same
like
a
attack
execution
so
to
say,
and
just
to
clarify
this
is
about
our
getting
the
sack
traffic
or
off
selected
nodes
in
the
network,
node
the
network
as
a
whole.
Otherwise,
of
course
it
does
the
final
goal:
it's
just
more
convenient
to
go
for
a
whole
web
and
jamming.
K
We
clarify
the
the
main
solution
limitation.
I
would
say
so
that
this
is
about
protecting
against
selective
jamming
traffic
occurring
in
slot
frames.
Where
data
traffic
happens,
so
we
cannot
apply
the
same
principle
on
lot
frames
that
are
essentially
used
to
support
a
joining
process
to
a
minimal
cell
or
other
kind
of
runnable
cells.
So
if
we
shuffle
cells
there
to,
of
course,
the
joining
process
would
become
well,
not
unreliable,
but
for
sure
less
deterministic.
You
cannot
really
think
more
of
upper
bounds
for
joining
them.
K
So
this
is
fine
to
apply
to
stall
frames
for
data
traffic,
not
really
for
lot
frames
evolved
in
the
joining
process,
meaning
that
the
same
attack
is
still
possible.
Of
course,
against
the
join
process
as
a
whole
and
as
a
final
update,
we
already
had
in
a
previous
version
that
the
two
keys
that
are
practically
used
for
local
computation
on
the
network
nodes
to
alter
their
so
usage,
have
to
be
provided
to
them
before
the
join
the
network
and
a
possible
way
to
do.
K
That,
of
course,
is
using
the
minimal
security
framework
practically
putting
them
in
the
general
response.
In
version
zero
of
the
draft,
we
were
aligned
to
version
of
the
minimal
security
framework
before
our
submission.
So
now
this
is
aligned
to
the
current
format
of
the
general
response.
It's
essentially
about
adding
two
more
parameters
in
the
configuration
object.
The
key
set
was
in
general.
There
are
two
but
there's
a
corner
case
where
it
can
be
one
and
the
actual
permutation
cipher
to
use
with
the
keys
to
perform
the
shopping.
K
And,
of
course,
we
described
how
to
perform
higher
handling.
In
case
there
are,
some
is
matching
key
format,
numbers
and
so
on.
So
to
summarize,
this
was
about
taking
into
account
the
comments
and
feedback
got
at
their
bangkok.
We
think
we
addressed
all
of
them
in
this
update
and,
of
course,
you'd
like
to
see
document
proceeding,
for
which
definitely
we
need
reviews
from
the
group.
B
Thank
you.
Thank
you.
So
much
so
reviews
is
what
you're
asking
for
I'm
sure
makes
sense.
Can
people
raise
their
hands
if
they
so
who
has
read
this
draft
all
right,
so
yeah
less
than
ten
people
who
who
is
willing
to
review
this
in
the
next
month?
My
so,
let's
write
down
in
the
minutes.
We
have
charlie,
think
Fay,
Michael
and
Pascal.
E
B
Miss
perfect,
thank
you.
Thank
you!
So
much
okay,
so
we're,
as
you
have
seen,
watch
your
watch
we're
late.
So
what
I
propose
we
do?
Is
we
proceed
with
the
open
benchmark,
presentation
and
then
I
propose
that
we
swap
and
leave
the
plea
please
and
then
talk
about
the
outcome
of
the
hackathon
last
in
case
we're
running
out
of
time.
Thank
you
for
agreeing
to
swap
so
next
is
this
kick-ass.
L
The
owners-
okay,
hi
everyone
I-
am
bored
our
carpets
from
University
of
Montenegro
and
together
with
together
with
much
needs
and
professor
and
his
godson,
we
are
working
on
development
of
benchmarking
platform
for
six
dish
as
part
of
so
the
project
of
university
of
Montenegro.
Now,
first
of
all,
what
was
the
motivation
behind
so
that
so
the
first
reason
is
that
there
are
many
academic
papers
which
propose
a
60s
implementation,
but
failed
to
give
a
comprehensive
benchmark
and
the
general
overview
in
a
real
world
driven
scenario.
L
The
second
reason
is
that
the
standards
are
always
evolving
and
it
is
important
that
we
have
a
constant
performance
evaluation,
and
the
third
reason
is
that
it
is
also
essential
that
we
have
a
reliable
tool
for
comparing
two
implementations
with
one
another
or
to
compare
state-of-the-art
implementation
with
a
new
implementation.
Now,
how
do
we
try
to?
How
do
we
aim
to
achieve
this
by
following
these
three
sets
of
rules?
L
The
first
rule
is
that
all
the
experimentation
is
should
be
based
on
test
scenarios
which
are
defined
in
RFC
s
and
which
try
to
mimic
the
real-world
environments
will
use
case.
The
second
principle
is
that
we
define
the
performance
of
firmware
as
the
set
of
key
performance
indicators
which
are
strictly
defined,
and
the
third
principle
is
that
the
conditions
and
the
environments
in
which
we
perform
the
experiments,
namely
the
configuration
of
the
test
beds,
should
mimic
the
real-world
environments
as
closely
as
possible.
L
L
This
is
the
current
work
in
progress,
so
we
are
currently.
We
have
implemented
these
three
scenarios,
so
home
automation,
building,
automation
and
industrial
monitoring
and
we're
currently
working
on
implementation
working
on
integration
or
have
already
integrated
these
three
tests,
but
so
they
are
at
11
supply
its
WI
lab
T
in
Ghent
and
open
testbed
in
Paris,
which
is
about
within
India
and
for
the
last
for
the
end,
this
is
some
sleepy
kept
the
gy
of
the
current
version.
L
B
Thank
you
so
much
for
the
visitors.
We
don't
have
time
to
take
questions
now,
but
if
you
have
any
questions,
your
names
are
on
the
slide.
Yes,
you
want
to
highlight
the
importance
of
this
work
and
and
and
kind
of
very,
very
cool
that
you're
able
to
do
real
word
benchmarking
and
repeatable,
and
some
kind
of
continuous
integration
of
benchmarking
on
six
dish.
Very,
very
cool
thanks.
Thank
you.
Thank
you
for
coming
in
like
this.
M
Summary
is
there's
not
a
lot
of
change
since
even
Montreal,
but
the
goal
of
this
document
always
was
to
use
protocols
and
other
things
to
find
in
other
parts
of
the
IETF
and
not
do
anything
that
we
really
needed.
So
the
update
to
this
working
group
is
really
to
understand
that
the
core
burski
document
has
passed.
Working
group
last
call
had
three
very
large
reviews,
which
took
literally
six
months
of
of
several
days
a
week
to
to
deal
with
them.
That's
all
happened.
It's
it's
gone
up
to
Ignace
to
get
to
the
is
G.
M
M
M
If
you
want
to
run
all
this
over
DTLS
and
we
actually
are
making
it
run
over
a
DTLS
on
15.4,
but
not
six
dish
in
another
room,
not
associated
with
the
IETF
today
and
tomorrow,
with
the
threat
group
in
these
people-
that's
all
happens,
but
if
you
want
to
use
a
more
constrained
key
management
protocol,
if
you
want
dead
heart,
for
instance,
we
still
don't
have
a
home
for
that.
This
has
been
very
difficult.
We've
been
through
a
sec
patch,
SEC
dispatch.
M
Virtual
interim
was
that
two
weeks
ago,
Melissa
two
weeks
ago,
you
know
two
weeks
ago
and
I-
don't
know
what
the
results
are.
I,
don't
think
that
anyone
knows
at
this
point,
but
there
is
some
progress
of
some
reasonable
progress
happening
on
getting
that.
So
those
are
the
kinds
of
technology
pieces
that.
M
Secure
zero-touch
going
require
us
for
to
do
our
document,
I
refreshed
it
in
October.
Really
that
was
just
you
know:
reposted
lost
a
co-author
last
summer,
just
not
doesn't
have
time
looking
for
help
and
and
essentially
we
need
to.
We
need
to
go
through
the
document
again
and
essentially
remove
text.
The
removing
text
essentially
means
because
that
text
is
now
moved
to
another
document,
which
is
in
a
much
more
mature
State.
M
That's
the
kind
of
architecture
of
documents
that
we
have
had
that
documents
lies
been
in
front
of
you
before
and
then
I'll
just
mention.
The
other
document
is
enhanced
beacon,
so
I've
received
some
reviews
on
that
from
Pascal.
Thank
you
very
much
have
posted
a
new
document
in
Oh
on
that
I
think
that,
as
a
working
group,
we
have
pretty
much
reached
consensus
that
the
contents
of
the
enhanced
beacon
is
unchanged.
M
F
J
F
M
Just
to
add
to
that
in
the
other
room,
which
is
where
I
been
all
morning,
where
were
we're
doing
DTLS
and
over
54-
and
it's
not
easy-
the
packets
are
too
big
they
take
too
long.
We
treat
we
transmit
Tanners
mean
that
unless
you
deal
with
that
right,
you
actually
get
retransmits
before
the
original
set
of
packets
even
arrived.
So
there's
a
bunch
of
things
to
tweak
and
get
right
for
that.
It's
not
it's
not
trivial.
Making
that
stuff
smaller
really
will
help.
So.
F
G
M
M
Diego
Diego
is
gonna.
Do
some
my
co-authors
gonna
do
some
of
the
introductory
tasks.
I
think
the
working
group
needs
to
decide
if
the
introductory
texts
need
to
be
this
big.
You
know
everyone
understands
what
broadcasts
or
this
big
to
explain
to
the
rest
of
the
world.
Why?
No,
we
have
issues
about
broadcast
actually.
C
C
M
I'm
just
concerned
about
you
know:
Jen
art,
review
or
someone.
You
know
comes
along
and
goes
we'll.
What's
the
problem
right,
because
the
problem,
the
problem
is
in
some
ways
not
very
well
defined
in
the
document,
because
we
all
understand
the
problem
and
that's
why
I
said
well,
look
there's
some
more
text
that
maybe
is
needed,
but
if
we
don't
really
want
to
put
that
in
I,
don't
want
to
put
it
in
it's
it's
texted,
right
and
and
maintaining
I.
C
M
C
I
So
my
Timmy's
Menasha
and
I
attended
the
hackathon
from
two
days
ago.
Oh
I
want
to
give
the
message
later
where
it
shows
up.
If
there's
a
400
or
16
people
attending
this,
a
hackathon
so
is
largest
a
hex
on
ever
and
their
hair
is
on
pictures
in
the
middle.
Is
this
is
a
sick
day.
She
opened
August
in
table
and
right
otoko
corner
is
my
teammates
militia
is
working
harder.
I
So
what
I
plan
to
do
during
the
heck
zone
is
once
we
using
opened
up
a
new
project
to
optimize
the
imputation
of
MSF
and
another
one
is
militias
working
on
the
benchmark,
which
is
a
page
marker,
the
performance
of
sick
tissue,
so
this
one
we
have
done
after
the
exome,
so
from
the
benchmarking
part
is
able.
The
benchmark
server
is
able
to
kind
of
communicate
with
the
mouse
over
tests.
I
The
test
batch,
such
as
that
the
text
powers
at
DeGroot
and
the
others,
and
on
the
massive
site
we
trying
to
organize
the
MSF
and
also
create
a
live
demo
which
is
available
on
one.
So
with
this
link,
everyone
can
access
it
and
the
interface
look
like
this
is
as
empty
under
latency
and
an
entry
and
the
reliability
and
the
cell
usage
for
MSF
you
can
access.
Is
this
link
and
see
it's
lively
actually
right
now,
yeah?
So
it's
a
pretty
cool
heck
phone.
Here's
are
some
links.
I
B
It
thank
you
thank
you,
so
much
I
think
face
so
click
on
the
link
and
you'll
be
able
to
see
a
little
dashboard
and
see
a
live
network
running
six
dish.
Now,
that's
it
for
our
time.
We
don't
have
time
to
take
any
more
questions,
let's
reconvene
on
the
mailing
list.
Thank
you
so
much
so.
Please
make
sure
that
you
have
signed
the
blue
sheets.
There's
a
there's,
a
blue
sheet
at
the
table
there,
as
you
walk
out.
If
you
have
it.
Thank
you.