►
From YouTube: T2TRG Interim Meeting, 2020-04-14
Description
T2TRG Interim Meeting, 2020-04-14
A
Okay,
come
everyone
so
welcome
to
the
tingling
research
group
online
summary
meeting,
so
this
is
the
first
time
we're
doing
this
online.
You
all
know,
because
of
why
all
the
meetings
have
turned
virtual
during
these
times,
so
my
name
is
Carolyn
and
together,
Kirsten
Borman.
We
are
chairing
that
interesting
research
group
quick,
note,
well
points.
If
everything
works
as
expected,
you
are
being
recorded
right
now.
A
You
should
also
be
nice
and
professional
and
welcoming
to
each
other
and
also
the
IP,
our
guidelines
of
the
IETF
to
apply
this
meeting
or
more
detailed
person
of
the
note.
Well,
you
can
have
a
look
at
the
slides
and
the
links
here
on
the
IP
guidelines
and
all
the
privacy
and
code
of
conduct
and
a
quick
reminder
about
the
goals
of
Tyre
TF.
A
So
this
is
not
the
IETF
but
I
RTF
and
the
internet
research
task
force,
refocus
on
the
longer
term,
research
issues
of
the
Internet,
whereas
on
the
IETF
side,
the
focus
on
the
short
term
issues
of
engineering
as
standards
making
ire
d
f,
we
are
doing
research
and
not
a
standard
or
standards
as
an
IETF
side.
But
of
course
we
do
do
a
lot
of
collaboration
with
IETF
on
all
of
these
topics.
If
you
want
to
have
more
information
with
ography,
if
you
can
look
at
the
RFC
7
for
18.
A
So
we
don't
have
physical
blue
seats
on
this
meeting.
However,
at
the
end
of
the
etherpad,
in
the
link
that
that
is
on
visible
in
the
WebEx
chat,
you
have
blue
sedan
or
attendance
section
where
you
can
write
your
name
and
affiliation
see.
We
have
no
takers,
we
have
Christian
who
volunteered
thanks
a
lot
Christian.
We
also
have
couple
of
persons
in
each
other
if
you
want
to
be
able
to
keep
up
with
what's
happening
at
thinking,
arty.
A
The
best
way
to
do
that
is
to
sign
up
on
the
mailing
list,
thinking
RH
entirely
after
cork.
There's
a
link
also
on
the
slide.
However,
to
do
that,
and
also
as
we
have
been
having
on
all
the
meetings
so
far,
we
do
have
a
keep
up
repository
with
all
the
latest
information
about
this
meeting
and
also
the
materials
that
are
are
shown
are
shown
here
and
the
link
is
on
the
last
line
of
this
slide.
A
Agenda
for
today,
we
are
right
now
in
the
intro
part,
so
we'll
give
a
status
update
of
the
research
group
and
also
quick
update
on
the
upcoming
meeting
activities.
We
have
reports
from
various
things,
energy
and
related
activities
from
wishy
I
hope
we
do
with
one
DM
and
also
quick
one
on
doubled,
receivable
things
that
Kirsten
will
give
a
1,
DM
update
and
an
tutorial
and
then.
C
A
And
also
a
quick
reminder:
how
don't
thank
you
management,
since
we
don't
have
physical,
my
clients
here,
you
can
at
any
moment
put
a
q+
on
the
WebEx
chat
and
that
way
get
a
position
in
the
queue.
But
since
we
are
not
a
massive
amount
of
people
and
if
you
feel
there's
a
natural
time
to
chime
in,
you
can
also
go
ahead
and
do
that
just
like
Hank
Hank
just
did,
but
it
went
there.
A
Moving
on
quick
reminder
about
the
tingling
research
group,
scoping
goals,
so
just
like
a
tire
TF
large,
we
are
focusing
open
research
issues,
but
in
particular
in
this
group
we're
focusing
on
the
Internet
of
Things.
How
can
we
can
make
the
real
IOT
reality
open
focus
here
on
low
resource
nodes
and
how
we
can
bring
those
low
resource
notes,
part
of
the
bigger
Internet
or
the
bigger
IOT?
A
A
So
we
work
with,
of
course,
many
IETF
groups.
We
here's
an
example
of
two
groups
that
we
have,
in
particular
close
cooperation
with.
So
as
we
do,
the
research
on
the
open
research
issues
on
the
Tingting
RT,
for
example,
in
the
core
working
crew,
is
lot
of
them,
where
the
protocol
engineering
for
restful
environments
happen,
and
we
have
had
many
multiple
topics,
moving
between
thinking,
arty
and
core
recently,
and
then
we
have
in
particular,
and
the
group
called
L
week.
A
So,
right
now
we
are
in
a
summary
meeting.
We
have
these
meetings,
usually
during
the
IETF
week.
This
time,
of
course,
on
online,
and
here
we
in
general
give
an
update
on
what
has
happened
between
the
IETF.
What
was
coming
next
for
the
research
group,
a
lot
of
the
actual
work
technical
work
happens
in
other
other
meetings,
so
what
we
have
coming
next
fourteenth
energy
is
that
we
have
had
this
regular.
We
she
work
on
IOT,
semantics
and
hypermedia.
Interoperability
calls
roughly
on
a
monthly
gatherings,
usually
on
one
of
the
meetings
we
decide.
A
What
is
a
good
time
for
the
next
meeting
for
worship.
Now
we
are
planning
one
next
Friday
24th,
the
exact
still
TBD.
We
have
also
had
online
meetings
commonly
with
OCF,
only
speaker,
people
3c
web
of
things.
In
particular,
we
had
in
a
meetings
with
ocf
some
weeks
ago
about
their
use
of
IETF
protocols
and
and
information
and
data
planning.
We
were
applying
for
a
physical
meeting
which
I
really
see
what
are
things
in
June
Kolak
I
did
I
said:
I
CW
e
academic
conference.
A
Also,
planning
topics
based
meetings
on
selecting
one
data
model
related
issues
somewhere
in
the
May
time
frame.
The
details
are
still
open
and,
of
course,
at
the
next
IETF,
depending
whether
that's
going
to
be
an
online
meeting
or
or
a
physical
meeting,
we
will
have
some
activities
co-located.
We
all
will
have
to
wait
until
May
about
the
decision
if
the
IDF
is
going
to
be
fiscal
or
online.
A
We
also
have
this
long
starting
plan
to
have
more
or
hole
located.
Meetings
with
academic
conferences
almost
had
one
now
entered
into
meeting,
but
unfortunate
that
was
turned
into
in
the
online
meeting,
but
hopefully
next
year
we
managed
to
have
something
physically
co-located
with
an
academic
conference,
and
if
you
have
any
ideas,
what
we
a
good
conference,
perhaps
you're,
organizing
one.
Please
do
approaches
chairs
for
mourning
for
my
severe
Ahmad
and
happy
to
talk
with
you.
A
On
to
the
research
group
documents,
because
currently
we
have-
we
have
published
one
RFC
on
on
security,
and
we
have
another
research
group
document
in
the
works
right
now
called
restful
design
for
IOT.
That
one
still
has
a
couple
of
issues
we
want
to
have
a
closer
for
before
publishing
it
in
particular
offer
lessons
in
Discovery.
We
are
now
thinking
if
we
should
have
a
design
team
meeting
with
with
altars
and
and
open
for
everyone
else
to
join,
to
really
have
finally
close
those
issues
and
and
publish
the
document.
A
We
have
upcoming
this
h
and
iot
document.
That's
going
to
be
a
short
update
coming
later
today,
and
we
are
now
with
that
to
be
ready
for
research
group
adoption.
So
of
course,
reviewers
for
that
document
will
be
more
than
welcome.
Also,
we
have
secure
boot
serving
for
IOT
document,
a
short
update
coming
in
a
moment.
They.
A
Other
areas
that
we
have
had
discussions
along
and
there
are
also
documents
for
a-
u
p
or
describing
binary
data
in
legacy
formats,
variety
of
difference
of
core
applications,
core
interfaces
and
also
layer,
three
communication
considerations.
They
are
not
presented
today,
but
they
are
topics
that
we
have
ongoing
work,
you're
interested
of
getting
involved.
Please
contact
shares.
We
can
point
you
to
write
people
and
write
documents,
so
we
are
planning
to
make
some
of
the
wishy
notes
into
more
formal
documents.
A
Then
a
quick
update
on
the
wish
the
activity,
so
we
see
activity,
is
something
that
the
research
group
has
has
had
for
the
past
few
years
already
it
started
with
it
a
it
works
up
at
the
proc
IDF
and
then
happy
happy
continuing
in
in
various
forms
of
physical
and
and
physical
and
online
meetings
last
night.
If
we
have
a
to
online
meetings
with
two
topics
that
have
been
in
both
of
those
meetings,
the
model
has
been
very
much
in
focus
for
both
of
those
meetings.
A
In
particular
in
one
of
we
have
been
looking
in
one
DM
and
how
it
relates.
A
lot
of
things
is
schema
how
these
things
work.
Together,
we
had
discussions
on
how
we
do
protocol
bindings
from
one
data
model
and
also
how
we
build
applications
on
one
day
tomorrow,
so
how
you
fit
a
7
ik
proxy,
and
what
should
the
semantics
api's
look
like
Carsten,
who
is
gonna,
be
talking
about
one
DM
more
in
in
a
moment.
A
Also
another
topic
we
have
had
it
was
this
data
model,
design
considerations
and,
in
particular,
do
versioning
of
data
models,
and
how
do
you
handle
the
number
of
spaces
of
data
models?
That
seems
to
be
a
topic
that
is
popping
up
right
now
in
multiple
different
fora.
Working
on
data
models,
including
one
DM,
we've
been
trying
to
gather
some
common
knowledge
and
design
guidelines
for
those
topics.
A
Few
words
about
the
we
see
one
DM
hackathon,
so
we
had
a
normally
we
have
had.
We
see
hackathons
as
part
of
the
IETF
hackathon
in
the
face-to-face
meetings.
But
now,
since
the
based
waste
hackathon
was
cancelled,
we
had
a
a
virtual
hackathon
last
week,
since
it
was
a
four-hour
WebEx
session
where
we
started
with
the
show
on
tell
session.
So
everyone
who
had
relevant
implementations
could
show
them
and
see
how
they
could
be
made
to
work
together.
A
A
That
interoperability
between
two
different
ecosystems
to
partner
ecosystems,
we
chose
for
this
challenge
for
the
Ole
Miss
back
works
like
within
to
him.
If
so
and
OCF
was
to
have
a
ocf
application
working
through
the
seminary
proxy
using
information
that
is
in
the
STF
one
day
the
mole
STF
models
and
be
able
to
communicate
with
a
lightweight
entering
device,
for
example,
to
read
a
temperature
value
during
these
four
four
hours.
We
didn't
quite
get
to
the
implementation
details.
A
However
deep
we
did
manage
to
get
quite
a
bit
refined,
prototyping
plan
and
we
do
have
several
components.
Software
components
chosen
for
that
and
we're
gonna
be
continuing
putting
those
together
and
be
able
to
actually
this
proof
a
constant
in
internet
future
interested
in
joining
this
activity.
Please
do
let
us
know
when
we
can.
We
can
tell
you
more
about
it
and
show
where
it's
done.
A
So
before
the
ietf,
we
had
a
a
pre
idea
meeting.
We
have
had
it's
commonly
in
the
past
few
face-to-face
meetings
on
the
Friday
before
the
idea
weekend
hackathon
and
this
one
was
focused
on
one
DM
again.
Of
course,
it
was
an
online
meeting
this
time
very,
very
similar
topics,
as
we
have
had
in
the
way
she
calls
so
versioning,
evolution
of
data
models,
data
model
and
evolution.
Trade
among
languages
were
in
the
focus
and
in
particle
whether
you
should
use
versioning
or
if
features
are
a
better
solutions
for
it
for
the
same
challenges.
A
A
Given
that
this
meeting
was
supposed
to
be
co-located
with
the
IDF
one
key
topic,
there
was
this
port
for
one
DM
language,
standardization
at
the
IETF,
but
Kirsten
will
be
going
in
more
details
on
that.
But
if
you're
interested
on
the
details
of
this
meeting,
you
can
check
out
the
detailed
notes
on
the
link
below.
A
E
E
So
I
would
like
to
start
with
a
small
recap,
so
the
current
and
what
we
were
working
on
in
the
web
of
things
working
group.
We
were
focusing
on
these
five
deliverables,
so
the
what
architecture
is
a
document
that
was
detailing
the
different
use
cases
for
robotics
technologies
and
was
giving
the
formal
definitions.
E
It
shows
what
it
would
look
like
defined
behind
some
proxies
or
not,
and
so
on.
So
it's
more
of
an
informative
document,
which
has
some
more
normative
definitions
and
I
would
say
the
core
document
or
the
deliverable.
We
have
is
the
thing
description
document
and
it
is
basically
what
we
use
to
represent
the
network
facing
interfaces
of
things
so
by
the
way,
oops
yeah,
so
natural
facing
interfaces
of
things.
So
at
the
moment
it's
adjacent
LD
document,
but
it
could
be
represented
in
other
ways,
but
in
the
foremost
it's
it's
a
model.
E
So,
with
the
buying
templates
document,
we
explain
how
we
can
represent
different
protocols
of
these
things.
So
if
a
thing
is
using
HTTP,
Co,
app
or
ng
DT,
how
would
it
look
like
in
a
description
document
and
instead
of
Jason?
If
I
were
to
transmit
XML?
How
would
it
look
like
in
the
scripting
API
document?
We
actually
prescribe
a
scripting
API,
so
how
you
can
program
a
consumer's
for
the
client
applications
and
also,
like
a
think,
implementation.
E
As
you
can
see,
all
these
documents
are
linked
here
and
to
their
official
WC
recommendations.
And
lastly,
we
have
the
security
and
privacy
guidelines,
which
is
as
a
non
normative
guide
on
on
how
to
use
the
correct
security
standards,
so
we
don't
prescribe
on.
So
we
don't
like
say
that
you
have
to
do
security
this
way,
but
it's
more
like
there
are
these
security
technologies
and
you
should
use
them
in
your
application.
E
E
Okay,
so
that
was
more
or
less
what
has
happened
until
more
or
less
last
week
and
just
for
a
quick
reference.
If
somebody
want
to
quickly
understand
what
is
a
team
description,
it's
basically
this
model
that
we
propose
where
we
have
like
the
one
DM
proposal,
the
property
action
and
event
affordances,
and
we
also
have
some
method:
data,
human,
readable
metadata.
E
We
have
some
information
on
versioning,
different
language
support
and
so
on
so
different
security
schemes
yeah.
But
this
is
like
a
high-level
view
of
the
model
and
what
we
have
more
to
come
is
that
the
working
group
is
going
on
a
small
maintenance
round
and
we
are
aiming
to
release
so
what
we
call
version
1.1
of
the
specifications.
So
it's
basically
some
small
features
that
were
like
that.
We
couldn't
finish
until
the
release
and
some
things
that
were
found
during
the
last
phases
of
the
sanitization.
Where
we
couldn't
change
the
standard
anymore.
E
We
have
a
new
task
force
on
the
discovery.
So
how
can
we
use
different
discovery
mechanisms
in
the
way
of
things
context?
We
are
working
on
more
streamlined
testing.
So
how
can
we
improve
the
current
testing
activity
and
like
propose
more
online
tools
for
this,
and
we're
also
playing
some
developer
outreach
sessions
where
we
first
show
from
our
side?
How
can
somebody
develop
a
thing
or
consumer
implementation
and
also
would
like
to
invite
other
people
to
come
and
explain
their
implementations
for,
like
developers.
E
F
E
This
is
my
last
slide,
so
if
you
want
to
have
more
information
about
the
standards
there
in
the
second
slide,
as
I
shown,
we
have
this
main
page.
That
gives
a
little
introduction
into
web
of
things
and
we
have
our
wiki,
where
you
can
see
the
different
calls
we
have
and
the
minutes
of
the
calls
which
are
all
public,
and
we
have
a
library
that
groups
different
available
things
implementations.
So
you
can
go
and
look
at
the
source
code
of
some
things
and
and
their
team
descriptions,
as
with
any
CC,
sees
the
recommendation.
A
A
You
again
so
next
we
have
on
the
agenda
Carsten
and
with
the
Quantium
update
and
tutorial
and
just
a
reminder
for
everyone.
Please
don't
don't
share
your
app
video
that
will
be
consuming
bandwidth
from
all
of
us,
and
that
seems
to
be
cars
at
the
moment
and
please
keep
your
microphone
muted
if
you're
not
talking
or
presenting.
Thank
you.
D
Have
you
seen
my
slides
okay,
so
this
is
a
really
brief
tutorial
about
one
date:
remodel
activity
and
tsdf
former
that
is
being
created
there.
Mike
Acosta
had
a
very
nice
tutorial
about
this
at
the
Singapore
IETF
I.
Actually,
at
the
workshop,
we
had
a
head
of
that
I'm
not
going
to
try
to
redo
his
work
there,
but
I'm
going
to
take
a
slightly
higher
level
of
view
and
try
to
explain
what
what
are
the
components
and
and
cogs
and
gears
and
and
how
do
they
actually
fit
into
each
other.
D
So
just
as
a
reminder,
why
is
it
useful
to
do
this?
Of
course,
it's
always
nice
to
have
common
standards,
but
really
the
motivation
here
is
that
we
have
number
of
ecosystem
specific
standards.
Development
organization
is
in
the
Internet
of
Things,
and
each
ecosystem
has
developed
their
own
data
models
in
their
own
way
to
document
them
and
it
turns
out
applications
really
have
to
talk
to
things
through
devices
from
multiple
ecosystems.
So
there
is
no
chance
that
a
single
ecosystem
can
supply
all
the
devices
that
may
be
needed
in
a
less
than
trivial
IOT
application.
D
So
applications
need
to
talk
to
all
those
two
devices
from
all
those
ecosystems
or
for
many
of
these
ecosystems
and
while
building
protocol
translators
is
possible,
I
mean
it's
not
easy.
It's
possible,
it's
actually
even
harder
to
translates
their
hundreds
of
data
models
that
we
have
out
there
for
for
the
different
devices,
and
actually
nobody
is
really
making
money
for
having
a
better,
better
data
model,
then
the
other
ecosystem.
So
it's
not
really
something
where
where
people
compete.
D
So
at
some
point
people
from
different
the
stos
science
available
organizations
noticed
this
and
created
a
liaison
group,
which
is
an
informal
group
of
people
from
these
different
stos
who
talk
to
each
other,
and
the
idea
is
to
bring
together
these
these
hundreds
of
ecosystem,
specific
data
models,
express
them
in
a
common
format
and
then
actually
work
on
merging
and
harmonizer.
It's
really
hard
to
merge
data
models
that
are
in
a
in
in
completely
different
forms,
but
once
you
have
expressed
them
in
a
common
format,
you
actually
see.
D
Oh,
this
is
redundant
and
our
models
actually
missing
that
part-
and
let's
add
that
and
so
on.
So
this
is
really
the
harmonization
process
and-
and
that
is
that
is
just
starting
I-
think
that
there
right
now
there
is
a
single
model
where
that
actually
has
worked,
but
that's
really
the
the
main
job
here
to
look
at
data
models
and
look
where
there
is
potential
for
for
coming
up
with
common
models.
D
So
the
whole
thing
is
done
in
the
open.
The
data
models
will
be
available
for
for
all
it's
a
BSD
license
behind
them,
so
it's
completely
open-source
no
strings
attached
a
license
and
actually,
even
though
the
liaison
group
still
is,
is
a
group
of
stos
which
are
mostly
operating
under
non-disclosure
agreements.
D
The
the
actual
harmonization
work
is
happening
in
the
open,
so
you
can
go
to
the
github
repository
one
data
model
and
find
things
there
now
I've
stressed
the
need
for
a
common
format
and
and
that's
what
I'm
going
to
focus
on
for
the
next
ten
slides.
So
in
order
to
be
able
to
harmonize
data
models,
we
need
to
be
able
to
express
them
in
a
common
format
and
that's
SDF.
D
So
SDF
stands
for
simple
definition:
format,
usually
all
standards.
That
start
out
with
the
word
simple
in
the
name
at
some
point
have
to
use
that
word.
Well.
There
is
a
certain
hope
that
we
actually
can
have
a
simple
standard
for
once,
and
there
is
a
github
repository
where
you
can
look
at
the
current
state
of
development.
D
So
you
you
heard
you
can
talk
about
the
thing
you
scription,
which
is
a
format
to
describe
a
single
thing
and
SDF
is
a
formal
to
describe
a
class
of
things
so
things
with
with
certain
common
characteristics
and
of
course
that's
not
that
much
different.
So
some
of
the
things
you
saw
on
on
EGIS
slide
will
come
up
on
my
slides
again
and
of
course,
it's
all
the
same
people
who
are
doing
this
work.
D
D
Things
have
interactions
with
their
peers
and
I'm
going
to
use
the
word
clients
here.
That's
not
a
1dm
term,
because
it
sounds
like
client-server
and
we
are
going
to
beyond
that,
but
but
bear
with
me
for
these
slides
that
I
called
the
guys
who
are
not
the
things
clients
so
those
things,
those
things
offer
interactions
that
can
be
done
and
we
call
them
foreign
service
you
so
on
and
I
guess
the
slides
and
it's
kind
of
popular
to
a
group
of
audiences
into
interaction
patterns.
D
Pattern
and
I
also
have
a
column
that
talks
about
the
initiative,
so
who's
actually
starting.
This
interaction
and
the
final
two
columns
of
the
table
show
what
what
kind
of
data
is
actually
processed.
Why
I
perform
in
this
interaction,
and
you
can
talk
about
input,
data
and
output
data,
so
a
property
is
like
a
something
that
is
like
a
rest,
get
a
forints.
D
It
can
be
initiated
by
a
client,
and
it
gives
you
some
output
data,
but
there
are
also
writable
properties,
which
are
properties
that
also
allow
a
push
interaction.
So
there
are
two
different
interactions
provided
by
the
same
affordance
here.
If
it's
writable
and
of
course
the
idea
is
that
a
property
puts
our
asset.
Actually
change
is
something
that
is
used
by
the
thing
to
do
its
work
like
a
temperature,
setpoint
or
color,
or
something
like
that.
D
The
the
second
group
of
interaction
is,
is
the
action
which
is
pretty
much
a
remote
procedure
call
in
the
view
of
many
people
in
in
rest,
we
have
the
the
post
primitive
for
that.
The
initiative
again
is
with
the
client,
and
there
is
input,
data
and
output
data
and,
and
these
input
and
output
data
are
different,
because
it's
not
just
setting
a
proxy
here
a
property
here.
It
might
be
something
like
like
starting
process
making
a
coffee
or
something
like
that.
D
So
the
output
data,
of
course
on
the
physical
side,
will
be
the
coffee,
but
on
the
side
that
we
model
here
will
be
the
fact
that
the
coffee
is
done
and
maybe
some
additional
information
about
it.
And
finally,
there
is
the
event,
which
is
something
that
is
not
really
supported,
very
well
by
rest,
so
that
there
are
various
ways
of
supporting
event
style
data
in
various
rest
environments.
D
But
the
whole
point
is
that
the
event
also
has
some
some
data,
which
I
call
output
data
here,
and
that
is
the
search
pattern.
So
let's
talk
about
those
patterns
in
a
little
bit
more
detail,
so
the
action
pattern
is
is
sometimes
in
some
ecosystems.
It's
the
only
thing
you
have,
you
can
send
a
command
to
something
and
you
get
a
response
and
whether
that
was
a
property
right
or
an
actual
action
in
our
sense
here,
that's
not
modeled.
D
So
here
we
do
distinguish
properties
which
are
just
data
that
that
can
be
set
atomically
and
Shins,
which
do
something
create
and
output.
That
is
the
result
of
an
operation
and
actually
may
take
some
time
to
do
so.
An
action
may
have
client
initiate
initiative
to
initiate
it,
but
then
it
may
only
result
in
data
later,
so
it's
very
different
from
a
property
which
always
happens
instantly.
D
So
this
is
the
only
pattern
we
have
where,
where
we
have
two
different
data
models
that
go
into
it,
so
I
talked
about
properties
already
a
little
bit.
Let
me
just
point
out
that
SDF
also
has
an
observable
property.
Like
the
thing
description
picture
you
just
saw
from
again
and
and
that's
pretty
interesting
because
with
an
observable
property,
the
initial
initiative
again
is
with
a
client,
but
from
then
on
it's
the
thing
that
tells
you
that
there
are
updates
to
this
property,
and
you
can
see
this
is
actually
not
much
different
from
an
event.
D
D
So
you
might
model
the
insertion
of
a
coin
in
a
device
as
an
event
and
then,
of
course,
you
you
need
to
model
the
the
fact
that
you
cannot
lose
these
events.
So
there
we
have
a
little
bit
of
openness
in
the
specification,
but
in
the
end
we
defined
the
output
data
and
and
that's
what
we
focus
on
in
the
data
model
work
for
now.
So
let's
talk
about
data.
Yes,.
E
So
like
a
some
sort
of
like
subscription
payload
that
you
send
and
like
set
up
some
sort
of
a
delivery
mechanism
and
then,
whereas
in
properties,
then
you
would
need
to
add
more
like
sort
of
like
information
into
how
we
would
set
up
this
thing.
So
we
leave
this
kind
of
heavy
event
streaming
protocols
through
the
event
affordances
and
also
for
of
the
real
properties,
we
sort
of
say
that
it
reports
only
the
changes
to
the
property.
E
D
E
D
So,
for
instance,
you
can
say
that
the
data
has
a
particular
media
type
or
content
format,
as
we
call
it
or
you
can
say
that
that
data
on
a
little
have
certain
scale
limits
and
so
on.
So
that
probably
requires
a
little
bit
of
a
longer
term
discussion
how
we
actually
evolve
these
data
format
elements
right
now.
This
is
pretty
much
based
on
what
what
we
found.
We
could
immediately
use
I'm
saying
this
from
from
academia.
Quite
a
few.
D
D
So
the
assumption
is
that
it
makes
sense
to
reuse
object,
definitions
in
things
and
I
think
that's
something
that
that
many
asteroids
have
and
things
actually
can
reuse
things
and
I've
put
a
little
green
thing
here,
insert
magic
because
we
are
still
discussing
how
exactly
to
model
a
thing.
That's
actually
composed
of
multiple
things
of
the
same
class.
So
if
you
have
a
smart
outlet
that
might
have
a
fuse,
which
you
can
read
whether
it's
it's
open
are
still
working,
you
can't
might
have
a
switch.
D
You
might
have
several
outlets
which
might
have
properties
like
current
flow
and
so
on
and
the
way
these
objects
are
put
together
to
a
thing
that's
currently
still
being
discussed.
But
the
point
here
is
that
we
can
build
up
a
little
library
of
objects
that
we
actually
can
use
to
build
things
and
then,
in
turn,
ODM
products,
combinations
of
things
that
I'm
not
harmonized,
but
that
would
describes
the
specific
products
you
can.
So
you
can
find
out
what
SCF
definitions
govern
the
workings
of
that
product.
D
So
it's
really
important
to
be
careful
not
to
confuse
the
use
of
selected
json
schema
or
terms
within
STF,
with
the
way
we
describe
the
syntax
of
the
format,
in
addition
to
the
syntax.
Of
course
we
need
semantics
and
that's
currently
just
a
text
file
and
actually
a
markdown
fire
to
make
it
easy
to
collaborate
on
that
and
there's
also
nests
and
best
practices
document
that
will
define,
define,
not
so
normative
parts.
So
people
know
how
to
best
use
this.
D
D
So
we
have
these
data
models
coming
out
and
we
are
learning
a
lot
about
what
what
data
models
actually
need.
The
specification
itself
also
needs
some
some
cleanup,
so
in
particular
the
the
natural
language
part
of
it
needs
an
editorial
round
and
we
are
looking
at
four-day
online
conference
in
the
first
weeks
of
May
to
actually
do
this
kind
of
work.
So
originally
we
planned
a
face-to-face,
that's
not
going
to
happen
and
in
order
to
get
the
work
done,
we
will
have
to
our
slots
distributed
over
four
days.
D
So
we
we
make
some
progress
and
the
whole
thing
I
think
should
be
completed
by
the
end
of
May
the
slide.
So
what
are
we
going
to
do?
Next?
I
said
we're
going
to
fix
the
language
and
so
on,
but
I
think
the
really
interesting
work
is
now
to
get
tools
done
on
the
model
consuming
side.
So
we
know
how
to
produce
these
models,
but
that
doesn't
give
us
a
lot
of
certainty
that
these
models
are
actually
useful.
So
we
actually
have
to
do
work
now.
D
Building
towards
that
consume
these
models
and
do
something
useful
based
on
the
information
extracted
from
those
models.
So
this
is
what
one
of
the
points
of
the
vichy,
hackathon
and
I
think
one
of
the
fun
parts
will
be
seeing
how
SDF
and
and
w3
what
thin
descriptions-
and
it
can
be
combined
to
to
make
this
useful
so
or
the
thing
descriptions
have
all
these
things
like
protocol
bindings
and
so
on
that
SDF
actually
doesn't
have.
So
it
makes
a
lot
of
sense
to
work
with
those
together
yeah.
D
So
a
few
things
need
to
be
solved
to
get
something
like
an
SDF
1.0,
which
would
be
an
output
of
that
liaison
group.
We
can
use
those
playground
definitions
to
serve
as
a
corpus
in
solving
issues,
and
one
of
the
interesting
thing
of
aspects
of
having
all
these
models
in
one
place
is
that
if
we
make
non
backwards
compatible
change
to
SDF,
we
can
just
go
over
all
these
definitions
with
a
tool
and
and
change
those
definitions
automatically.
So
we
don't
have
to
be
quite
as
afraid
of
doing
non
backwards,
compatible
changes.
D
So
this
this
is
something
that
that
will
be
done
in
in
the
spring
early
summer
this
year
and
then,
of
course,
the
next
question
is:
how
do
we
turn
STF
in
into
a
real-world
specification?
So
we
probably
want
to
find
a
venue
for
Standardization
and
typically
the
ITF
comes
up
as
potential
venue
there
and
those
are
discussions
there.
That
now
need
to
be
here
to
find
out
whether
the
IGF
is
the
right
place
to
do
this
and
and
actually
wants
to
do
this
questions.
F
D
Well,
the
motivation
for
publishing
the
ecosystems
specific
specifications
in
SDF
is
that
you
want
other
people
who
are
rounding
out
the
ecosystems
with
specifications
for
the
things
that
you
already
have
stay
compatible
to
you.
So
you
are
kind
of
the
the
opinion
leader
for
this
particular
kind
of
thing.
I
think
there's
tank
tangible
value
for
that.
One
of
the
reasons
why
the
ecosystem
people
are
so
interested
in
making
their
specification
available
quickly.
D
So
how
do
you
actually
work
in
this
space?
Well,
as
I
said
right
now,
it's
a
liaison
group,
so
you
have
to
be
affiliated
with
with
one
of
the
ecosystems
to
actually
join
the
the
the
actually
1bm
meetings.
But
since
the
work
is
happening
in
the
open,
you
can
just
send
a
per
request
to
the
playground
and
and
submit
things,
and
you
can
be
sure
that
other
people
will
be
looking
at
that
and
give
you
feedback.
D
G
H
For
the
demo
is
we're
using
the
are
planning
to
use
the
3c
web
of
things.
Implementation
in
eclipse
foundation
called
a
thing
web
node
watt,
which
has
protocol
bindings
that
we're
using
already
so
we're
basically
planning
to
use
the
SDF
model
with
creating
of
option
tree
the
proxy
that
has
its
protocol
binding.
That
describes
that
protocol
and
then
sort
of
have
do
the
work
in
inside
node.
What,
if
you
will
to
do
the
actual
proxy
conversion
by
property
or
whatever?
We
need
to
do.
A
I
think
everyone's
very
good
discussants
but
I'm
afraid
we're
running
a
bit
short
on
time,
so
maybe
Lars
can
prepare
to
present
next
and
for
everyone
who's
more
interested
on
this
particular
topic.
I
recommend
you
join
one
of
our
upcoming
wishi
one
day,
a
meeting.
So
even
if
they're
1dm,
let's
say
core
work,
is
happening
within
the
liason
group
that
it's
not
open
for
everyone.
D
A
I
Right,
so
this
is
talk
about
a
paper
I
had
at
one
of
the
NGSS
workshops.
I
think
was
called
this
and
then
I
also
talked
at
the
quips
workshop,
which
was
on
securing
quick.
But
this
is
a
sort
of
the
write-up
of
a
little
sort
of
side
experiment.
It
was
trying
to
figure
out
if
you
could
actually
run
a
quick
stack
on
an
IOT
device,
and
so
what
I
did
is
are
basically
data
to
both
feature
for
boards.
I
That
I
could
find
that
also
have
Wi-Fi,
because
I
wanted
to
make
I
could
run
something
and
and
sort
of
solve
how
that
work
is
sort
of
the
write-up
of
the
outcome.
I,
don't
think
I
really
need
you
to
really
motivate
my
right.
This
is
a
research
thing
and
be
right.
If
we
could
use
quick
on
IOT
devices
or
do
some
IOT
devices,
we
could
sort
of
leverage
all
of
the
engineering
gets
being
poured
into
a
quick
and
for
IOT
right
and
I
guess
this
would
be
a
good
thing
most
beautiful
degree.
I
It's
also
pretty
clear
that
you,
you
there's
a
line
here
in
terms
of
device
capabilities
below
which
it's
not
feasible.
To
do
this,
and-
and
we
can
argue
whether
you
know
it's-
it's
feasible
at
all
or
not,
but
at
least
I
could
get
it
to
run.
As
you
will
see,
the
two
things
are
part
of
this.
This
quick
stack
right
so,
on
the
left
hand,
side
warp-core.
This
is
basically
it's
an
UDP.
Ip
Ethernet
stack
that
I
originally
wrote
on
top
of
that
map
for
data
center
networking
purposes.
I
So
it's
basically
meant
to
be
as
fast
as
possible,
so
it
bypasses
the
kernel.
It
writes
straight
to
the
make
it
easily
fills
a
40
gig
path
with
you
know
a
single
core
with
a
single
flow,
it's
pretty
small.
So
it's
it's
obviously
not
fully
standards
compliant,
but
it
can
take
it
enough
so
that
you
could
speak
to
arbitrary
hosts,
but
at
least
sort
of
mostly
so
it's
like
three
thousand
lines
of
code
and
it's
another
theory
about.
If
you
actually
use
that
map
which
we
don't
for
these
IOT
devices.
I
Obviously,
it
also
has
a
forked
back-end
which
which
I
use
for
two
of
them
and
it
sort
of
exports
an
API,
that's
zero
copy,
which
is
also
nice,
because
I
thought
that
would
be
useful
for
IOT.
It
turns
out
the
operating
systems
that
are
used
which
were
riot
and
particle,
have
no
zero
copy,
so
mode
of
operations
that
I
was
useless
by
the
way.
Since
I
don't
see
the
question
qre.
I
If
you
want
to
interrupt
me
at
any
point
and
see
if
there's
any
questions
that
people
want
to
ask
or
people
that
just
interrupt
me
themselves,
we
can
do
this
alright.
So,
as
I
mentioned,
I've
got
two
boards.
One
is
a
particle.
The
other
one
is
in
the
SP
32.
The
argon
has
particles,
what's
called
device
OS
on
it,
which
has
L
width,
which
is
nice
right.
So
you
can
basically
just
run
this
or
core
thing
on
top
of
L,
WebSocket
emulation
and,
and
that
that's
good
enough
riot.
I
Has
this
thing
called
G
and
I
see
a
generic
generic
network.
I,
don't
know
with
the
RS
core
and
C's
for,
but
it's
basically
its
own
ipv6
stack
and
it
has
a
bunch
of
problems.
Most
of
all,
it
doesn't
let
you
wait
until
a
packet
arrives,
there's
no
Pole
or
select,
it
doesn't
have
ipv4
and
unfortunately,
the
Elric
court,
which
exists
for
riot
at
the
time
I
try
to
use.
I
It
was
broken
on
the
ESP
32,
and
so
I
couldn't
use
it
so
for
the
riot
implementation
I
hack
together
and
very
bad
warp-core
back
and
it's
port
sneaks
to
GN,
RC
and
sort
of
fakes,
pull
and
select
in
ugly
ways
right.
So
that's
that's!
Maybe
packet
I
all
this.
This
lets
you
send
UDP,
IP
and
Ethernet
packets
come
Qantas,
the
quick
stop.
I
So
this
is
a
thing
that
I've
been
I'm
sharing
a
quick
working
which
would
also
you
don't
know,
and
one
thing
that
I
quickly
realized
I
wanted
to
be
sure
that
what
we're
standardizing
is
actually
implementable
and
so
I
decided
I'm
going
to
do
a
little
toy
implementation
along
and
be
able.
You
know,
along
with
specification
process,
and
that's
been
going
on
like
for
three
four
years
now
and
I've-
been
doing
this
since
version
like
seven
or
11
or
whatever,
but
it's
come
a
long
way.
I
I
would
not
recommend
you
use
this
for
anything
protection
related,
but
you
know
for
playing
around
it's
fine,
it's
about
10,000
lines
of
code.
When
I
did
this
experiment,
which
is
a
couple
months
ago
again,
the
focus
of
coin
is
actually
high
performance.
Datacenter
networking
so
I'm
interested
in
how
fast
can
I
make
quick
go,
but
it
turns
out
because
it
runs
over
this
warp
core
packet
I/o
background,
it's
actually
reasonably
portable
to
IOT
devices,
and
it's
not
optimized
at
all
for
IOT.
Neither
is
warp
core
by
the
way,
but
it
turns
out
it.
I
It's
not
terrible.
So
it
uses
a
bunch
of
data
structures
that
you
normally
wouldn't
want
to
use
on
an
IOT
device,
so
it
uses
k
hash,
for
example.
Alright,
it
uses
timing
wheels,
it
uses
splay
trees
from
previously
uses
bit
sets
and
the
Doozers
kazuo's
pico
TLS
implementation,
which
is
a
reasonably
lightweight
TLS.
One
three.
Only
implementation
that
uses
has
to
a
crypto
backends
one
is
open
SSL,
which
obviously
doesn't
make
a
lot
of
sense,
but
it
also
has
what
Kazuo
calls
mini
crypto,
which
uses
sifri
and
micro
ECC
for
the
crypto
operations.
I
So
it's
not
terrible
and
so
I
wanted
to
sort
of
figure
out.
Can
I
run
this
thing.
This
is
a
little
bit
of
a
overview
slide
or
though
you
don't
know
these
boards
on
the
left-hand
side
are
again
on
the
right
side.
Let's
see
yes
p32,
you
can
see
that
they're
reasonably
powerful
right,
so
the
Argan
has
iron
cortex
m4
with
floating-point
it
ones
at
64,
mega
Hertz
right
it
has
a
nephew.
It
has.
I
It
even
has
an
arm
trust
zone
which,
for
the
measurements
here,
doesn't
matter
because
it's
not
exposed
by
particle
to
user
application,
so
I
can't
use
it
from
from
Tico
TLS,
there's
quite
a
bit
of
RAM
and
quite
a
bit
of
Flash,
and
then
this
was
because
I
wanted
to
make
sure
I
could
run
something,
but
I
didn't
want
to
like
do
to
work
and
then
realize
I
got
the
wrong
port
to
actually
run
something
on,
and
it
does
wireless
LAN.
Why?
Because
also
easy
easy
experimentation
on
the
right
hand.
I
Side
is
an
EFP
32
or
does
most
people
have
seen
these
again,
it's
pretty
powerful.
It
comes
so
this
Argan
device
OS,
is
free
our
toe
space
and
and
normal
expressive.
Development
kit
is
the
same
right,
but
I
didn't
want
to
compare
like
two
free
artists
based
system,
so
I
decided
I'm
gonna
run
riot
on
the
ESP
32,
just
because
it's
supported-
and
you
know,
to
get
a
little
bit
of
a
different
operating
system
in
there
to
make
to
see
if
it
makes
any
difference
so
I
used
riot
as
of
release
from
last
October.
I
Both
of
these
tool
chains
are
are
pretty
old
right,
given
that
that
GCC
9
is
our
so
and
we'll
see
that
there's
some
issues
with
link
time,
optimizations
that
don't
work
for
both
entities
which
might
have
made
the
footprint
under
that's
more.
So
those
are
the
board's
right
sorts
of
measurements.
So
maybe
now
would
be
a
good
time
if
there's
any
questions
about
anything
I've
said
so
far,.
I
I
guess
not:
let's
look
at
the
measurements,
I'm.
Basically
gonna.
First
talk
about
the
code
and
static
data
size,
meaning
you
know
how
much
flash
do
you
need
to
consume
to
run
quick
and
NTL
s13
I'm
gonna
do
a
baseline
build
first,
so
this
is
basically
so
both
1
and
work,
or
have
a
bunch
of
things
that
are
already
pretty
small
in
size
right
so
they're
they
already.
You
know.
If
you
just
compile
them,
you
can.
I
Is
the
size
of
the
quick
tag,
meaning
quant
and
warp-core
purple
is
the
application
you
will
see
here
that
the
application
for
the
Oregon
is
a
little
bit
bigger
than
the
application
of
DSP
32,
which
you
can't
see
it
all
really.
That's
because
on
the
Oregon
I
had
it
first
and
I
had
more
time
with
it.
So
I
stuck
some
stuff
in
there
that
you
know
turns
on
the
LEDs
and
makes
it
reply
to
button
presses
and
so
on.
I
So
there's
a
little
bit
more
application
code,
but
basically
all
the
application
does
is
a
get
for
a
5k
object
to
a
web
server
in
HTTP
3
server,
that's
running
on
my
my
laptop,
and
you
also
see
that
they're
sort
of
dark
and
light
green
and
red.
So
the
dark
red
is
quantity.
Quick
stack,
the
right,
LED
light
red
is
worker,
which
is
a
tacit
I/o
and
obviously
you
know
the
majority
of
that
red
is
is
going
towards
the
quick
functionality.
I
I
I
I
You
know
some
bit
tricks
and
you
can
get
rid
of
that,
which
is
nice
and
safe
if
you
kilobytes
I'm,
using
32-bit
width
for
a
whole
bunch
of
internal
variables
for
quick
that
are,
you
know,
64-bit
wide
in
the
specification
like
type
of
numbers,
but
I
chose
to
just
use
32-bit
widths
because
4
on
an
IOT
device
right.
How
likely
is
it
that
you're
gonna
use
sent
more
than
2
to
the
power
32
packets
over
a
single
flow?
You
know
track
equals.
I
You
know,
and
that
sort
of
you
know
already
brings
down
the
code
size
by
like
5k,
let's
say,
but
that's
pretty
good
right
and
we
haven't
given
up
much
sort
of
standards.
Compliance
quote-unquote,
yet
next
thing
so
quantify
default
is
a
server
and
a
client
library.
So
you
can
run
you
know
bolt
at
the
same
time.
If
you
want
to
be
a
proxy,
so
I
made
the
assumption
that
on
an
IOT
device,
maybe
you
just
want
to
be
a
client.
Alright,
I,
don't
really
see
a
need
to
run
a
quick
server
on
an
IOT
board.
I
If
people
want
to
do
that,
you
can
measure
it.
I
haven't
alright,
but
if
you
are
basically
dropping
server
more
for
both
TLS
and
for
Quake
you,
you
get
a
really
big
savings
right,
you're,
going
down
to
under
80
km,
75
K
for
USB
32.
So
you
can
specifically
see
that
the
TLS
savings
are
quite
substantial:
you're,
almost
gaining
like
10
K,
just
getting
rid
of
all
that
server
side,
TLS
processing,
which
is
quite
nice.
I
I
What's
the
RFC
2119
term
recommended
whatever?
So,
if
you're
the
client
right
at
the
server
you
you
do
want
to
speak
all
of
them
as
a
client,
you
can
sort
of
choose
not
to
and
still
interoperate
with
all
servers,
which
is
nice,
so
basically
I'm
leaving
yes,
128
sha-256
as
a
cipher
suite
and
one
key
exchange.
I
I
So
quick
has
this
thing
called
connection
migration,
where
if
you're
naturally
binds
or
you
want
to
switch
from
one
interface
to
another
interface,
you
can
do
that
and
the
connection
survives
that
that
I
would
claim
a
sort
of
unnecessary
for
IOT
use.
So
if
you
turn
that
off
you
get
another
few
kilobytes
of
code
reduction
at
the
quick
layer,
sort
of
quick
has
connection
close
frames
and
they
have
a
reason
field
that
you
can
take
arbitrary
text
and
quantify
default
is
quite
rebels
in
using
that.
I
So
whenever
it
sends
your
connection
to
those
frames,
it
puts
like
a
string
in
there.
It
says
here
is:
why
I
closed
your
connection?
It
obviously
does
need
to
go
into
the
static
image.
Somehow.
So,
if
you,
if
you
don't
do
that,
then
the
another
protocol
useless
you're
only
there
for
like
human
admits
to
look
at.
We
don't
do
that.
We
save
another
few
kilobytes,
because
we
don't
need
a
carried
off
strings.
I
Quick
has
a
feature
which
is
a
stateless
reset,
which
means
that
I
can
tell
you
I'm
gonna
send
if
I
have
lost
State
for
a
connection
that
we
had
I'm
gonna.
Send
you
this
random
number
instead
in
some
way,
and
that
is
for
you-
a
signal
that
I
have
I,
don't
know
who
you
are
anymore
and
obviously
I
think
I
can
compute
this
thing
based
on
target
that
I
see
coming
in
from
you,
so
that
that
lets
you
basically
drop
state
2
rather
than
keep
retransmitting
and
eventually
timing
out.
I
I
So
there's
a
support
for
dealing
with
reordering
in
in
quick
sort
of
two
things
that
you
want
to
do
your
zero
RTT
packets,
which
are
if
they
reordered
it,
would
be
nice
to
catch
them
so
that
when
you
have
the
keys
for
them,
you
don't
need
to
appear
to
retransmit
them.
So
we
need
to
store
them
in
some
new
data
structure.
And
if
you
know
you
don't
do
that,
you
have
more
gains.
I
What
potentially
you
have
a
little
bit
of
a
trouble
in
performance
if
there's
reordering
and
you
will
just
drop
all
reorder
data
rather
than
you
know,
keeping
it
around
to
deliver
it
when
it's
in
order
and
that
again
forces
the
PHA
we
transmit
that
but
lets
you
drop
some
data
structures
again,
and
so
this
is
sort
of
the
final
thing
that
I
did
right.
So
indeed
you
run
this
thing
now
in
63,
kilobytes
to
58
kilobytes
for
the
ESP
32,
which
is
actually
quite
good
right.
So
you
it
so
in
around
60
kilobytes.
I
You
can
get
a
full
TLS
on
three
stack,
including
software
crypto,
and
you
get
a
quick,
snack
and
I
should
have
said
earlier
that
that
quant
does
not
implement
HTTP
3.
So
it
implements
sort
of
a
TCP
TLS
like
protocol.
It's
a
transport
protocol,
then
it
doesn't
do
HTTP
3.
So
if
you
wanted
to
actually
do
HTTP
3,
you
probably
add
a
few
more
kilobytes
for
an
HT
stack
which
I
haven't
done.
I
There's
some
other
things
that
I
did.
Oh
there's
one
more
so
there's
also
less
compute.
If
you
like
connection
information
structure
that
one
by
default
keeps
Barrasso,
you
can
see
like
what
happened
to
this
connection.
You
know
how
many
frames
were
transmitted,
how
many
packets-
and
if
you
don't
want
that
and
IOT
device,
you
likely
don't
you
can
compile
that
out
and
you
gaining
a
little
bit
not
a
whole
or
not
even
the
whole
kilobyte
and
that's
my
final
slide
on
this.
I
So
that's
it
for
the
static
sizes.
What
stack
and
heap
usage
so
again,
I'm
going
to
show
you
two,
the
same
two
sort
of
diagrams
that
something
up
bar
diagrams
but
they're,
actually
just
top
plots.
So
I
instrumented,
the
binaries
to
log
stack
and
heap
usage
whenever
functions
entered
and
exited.
It
specifically
block
this
out
over
serial
that
you
can
imagine
that
that
gets
very
noisy,
very
quickly
and
I.
I
It
actually
became
so
noisy
that
it
didn't
terminate
in
any
sort
of
sane
amount
of
time
like
in
less
than
a
day,
so
I
dropped
instrumentation
of
the
crypto
functions
one
because
you
could
argue
that
if
you
had
how
to
put
their
support,
you
wouldn't
execute
those
anyway
and
and
they're
they're
very
frequently
called,
and
they
are
very
many
small
functions.
So
what
I
show
you
on
the
right
hand,
side
is
actually
the
lower
bound
of
the
stack
use
and
heap
use.
I
Oh,
don't
specifically
stack
use
because
I
don't
go
into
those
functions
and
I'm
not
showing
time
units
on
the
x-axis
and
that's
by
default,
because
I'm
actually
exporting
this
over
a
serial
line.
So
it's
meaningless
right.
It
takes
it
takes
sometimes
when
hour
or
two
to
do.
One
of
these
runs.
So
this
there's
no
performance
to
this.
Just
look
at
it.
This
time,
there's
sort
of
and
I
removed,
random
20%
of
the
data
points
to
make
the
over
plotting
a
little
less
severe.
So
you
can
feel
bit
more.
I
What's
going
on,
there's
three
sort
of
action
of
three
days:
five
phases
to
these
graphs
right.
There
is
a
dark
bread
which
you
can
barely
see
on
the
very
left,
which
is
the
you
know,
the
initialization
phase.
You
can
see
it
a
little
bit
better
on
the
yeast
and
thirty
two,
the
initialization
phase
on
the
argue
is
much
shorter
because
on
the
argan,
the
application
quote-unquote
get
started
once
the
device
has
attached
to
the
base
station.
While
on
on
the
ESP
thirty
two
under
riot,
that
thing
already
counts
towards
the
application
runtimes.
I
You
can
see
these
few
sort
of
dots
that
are
there
in
the
interphase
on
the
bottom
on
the
bottom
graph,
which
is
you
know
when
functions,
get
called
while
the
thing
is
trying
to
find
the
Wi-Fi,
so
that's
pretty
flat
there.
The
interesting
thing
is
doing
the
open
phase
right,
which
is
when
you're
actually
opening
your
quick
connection
to
the
server,
and
you
can
see
that
that's
really
when
the
stack
usage
is
is
highest
and
it's
pretty
bad.
It's
certainly
reaching
three
kilobytes
and
since
I
don't
plot
the
part
in
several
microwave
micro
ACC.
I
It's
actually
worse,
it's
actually
over
four
kilobyte,
because
those
have
quite
a
few
stuck
hungry
functions
that
they
use,
which
is
pretty
bad
on
device
OS.
The
defaults
Diagnostics
kay.
So
it's
actually
okay
to
run
on
riots.
It's
one
case
or
it
crashes.
So
you
know
compile
Ryan
with
a
larger
stack
to
make
it
run.
So
that
is
that's
pretty
bad,
and
part
of
that
is
due
to
pico
TLS,
which
has
a
bunch
of
functions
that
also
use
large
like
allocated
variables.
I
The
part
of
it
is
also,
as
I
said,
that
due
to
this
public
key
crypto
stuff,
which
is
not
super
great-
and
you
can
see
that
the
public
key
crypto
is
worse
and
it
symmetric
key
crypto,
because
during
the
green
phase,
which
is
the
data
transfer
phase,
the
stack
utilization
is
is
way
lower
than
during
connection
open,
which
is
nice,
but
you
can't
buy
anything
for
that.
You
got
the
worst
thing
or
the
thing
that
actually
matters.
It's
the
worst
case.
I
You
know
you
don't
get
a
cookie
for
using
that
stack
on
average
and
reconnection
closed
again,
run
that
ramp
down.
So
it's
it's
not
super
great,
but
stack
usage
could
certainly
be
improved
and
I
was
quite
surprised
that
crypto
libraries,
like
micro
ECC
that
specifically
like
claim
that
they
are
meant
for
embedded
devices,
then
use
a
couple
hundred
bytes
of
stack
allocated
space
anyway.
But
if
you
even
could
use
the
hardware
crypto
that
wouldn't
happen,
so
I
actually
went
through
all
this
already
so
I'm
gonna,
just
you
know,
zoom
through
these.
I
Eeep
usage,
so
this
is
again
over
at
the
runtime,
and
you
can
see
that
the
initialisation
in
close
there's
a
little
jump
there
and
blue
equalization.
That's
because
what
core
uses
statically
allocated
packet
buffers
and
that's
where
they
allocated
and
for
this
run
we
use
fifteen
buffers
at
1500
bytes,
which
translates
to
that
arrow
there.
One
thing
you
will
see
is
that
the
baseline
heat
usage
on
the
argon
is
somewhere
around
almost
around
96
kilobyte.
I
What's
notable
is
that
during
the
open
trace
right,
keep
is
slightly
increasing,
but
it's
not
terrible,
there's
no
large
chunks
and
that's
because
a
whole
bunch
of
sort
of
connect
per
connection
stuff
gets
allocated.
Ideally
you
want
to
have
all
of
that
statically
allocated,
but
because
this
is
not
IMT
code,
I
have
another
memory
allocations,
but
it's
not
terrible
and
during
a
transfer
phase.
What's
nice
is
it
stays
flat
right?
So
no
spikes
which
is
which
is
greater,
then
stuff
gets
the
allocated
and
you're
out.
B
I
The
arcing
can
measure
its
own
voltage
and
there's
a
whole
question
about
how
accurate
that
is,
but
it
sort
of
you
know
it
goes
down
over
time.
There's
two
runs
I
wanted
to
see
whether
quick,
zero
RTT
connection
resumption
makes
a
difference.
So
blue
is
everything
runs
with
one
RG
t
handshakes
red?
Is
you
run
exactly
one
one
Rd
handshake
at
the
beginning
of
the
connection
and
beginning
of
the
run
and
every
secret
connection?
That
is
the
zero
GD
connection
reestablishment.
I
One
second
and
medium
zero.
Rtt
connections
talked
about
four
point:
seventy
four!
So
I
can
so
it's
you
know
0.35
seconds
faster
to
do
zero,
RTT,
which
is
nice.
There's
some
open
questions
around
this
sort
of.
If
you
look
in
the
graph
there,
dear
RT
TV
does
show
a
little
bit
more
of
a
slope
compared
to
100
GT,
which
is
pretty
much
a
straight
line
up
until
the
1892
percentile
I.
Don't
know,
I
need
to
look
at
why
this
happens.
I
I
would
have
actually
expected
the
opposite,
but
but
there
you
have
it,
and-
and
one
RTT
is
sometimes
faster.
If
you
look
at
the
very
bottom
right,
there's
the
the
lines
are
crossing
and
that
I
don't
quite
understand
either.
There's
some.
You
know
future
work
here,
there's
actually
quite
a
bit
of
more
future
work.
I
What's
my
time,
Lots
right,
so
in
terms
of
measurements,
you
know,
data
upload
isn't
done,
there's
almost
no
varying
of
any
parameters
of
these
measurements,
objects,
sizes,
dreams,
connections
and
so
on,
when
not
comparing
against
anything
else
right,
neither
TCP
nor
TLS
or
co-op,
nor
something
else,
there's
nothing
about
different
boards
or
different
operating
systems.
Energy
measurements
are
pretty
xx
rough.
When
implementation
side,
there's
lots,
like
could
be
done
right,
I
said
I,
don't
do
HTTP
3
at
the
moment
that
that
could
be
included.
Eco
TLS
could
be
improved
quite
a
bit.
I
Better
data
structures
could
be
used
that
are
sort
of
more
optimized
for
IOT
usage.
Hardware
crypto
I
think
would
be
the
highest
on
my
list
actually
in
terms
of
performance
and
energy
savings.
Do
we
actually
you
know
what?
If
we
just
didn't
do
zero
RTT?
Could
we
shrink
down
the
code
size?
More
I
would
be
interested
in
looking
over
to
IP
over
ble
or
802
15
4
instead
of
wireless
LAN,
just
sort
of
a
cookie
right.
I
So
on
the
ESP
32,
with
Rio
doors,
the
wireless
LAN
driver
is
115
kilobyte,
which
is
45%
of
the
stuff
that
you
need.
25%
of
the
entire
size
of
riot
is
for
the
wireless
driver
for
DSP
32,
so
I'm,
hoping,
for
example,
that
ble
480
15
before
I've
sort
of
seen
our
drivers
and
the
question
you
know.
Can
you
actually
scale
this
down
to
to
smaller
devices?
And
you
know
my
gut
feeling?
Is
you
probably
could
if
you
were
to
build
a
quick
implementation
from
scratch
for
IOT?
I
F
Loves
thanks
for
this
excellent
presentation
as
Caravan
wig.
Of
course,
we
would
be
happy
to
host
this
work
there
at
some
point
when
you
wish
to
bring
it
there.
So
some
technical
comments,
I
think
I,
even
though
maybe
some
of
the
rest
community
will
disagree,
but
I
am
fine
with
this
that
the
IOT
device
is
it
like
that
initiates
connection.
D
F
F
Idea
of
like
like
how
far
can
you
go?
If
you
have
hardware
support
and
then
the
third
I
guess
your
future
work
was
saying
about
16-bit
I
wouldn't
do
that
I
think
it's
almost
like
very
hard
to
find
16-bit
microcontrollers
so
and
I
mean
there's
no
point.
I.
Think
the
32-bit
like
arm
cortex-m
3
are
sometimes
more
energy
efficient
than
any
eight
or
16-bit
microcontrollers.
So
I
don't
see
any
point
going
down
that
path
and,
of
course,
yeah
ble
or
15
for
quite
happy
to
see
results
on
that
in
the
future.
A
A
F
F
F
How
do
you
define
bootstrapping
and
there's
a
bunch
of
related
terms
that
are
used,
for
example,
onboarding
commissioning
and
so
on,
initialization?
How
are
they
related
and
how
are
other
people
using
these
storms?
So
one
of
the
goals
of
the
document
is
just
to
see
like
what
are
the
related
terms
and
how
they
are
being
used
and
possibly
identify
some
common
patterns
and
provide
recommendations
that
perhaps
maybe
we
at
the
IRT,
F
or
IETF,
should
should
be
using
this
or
favor
favoring.
F
These
terms
over
some
other
more
obscure
terms
and
then
like
of
course,
we
still
continue
with
the
original
goal
of
providing
examples
of
bootstrapping
techniques
we
cover.
We
will
try
to
cover
all
IETF
and
several
non
idea
protocols.
Knowing
that
you
know
we
can't
cover
every
every
bootstrapping
technique
that
that
exists,
and
perhaps
maybe
try
to
see
if
we
can
classify
them
based
on
like
do
they
require
a
server,
do
they
require
a
smartphone
application
and
and
so
on,
like
just
just
to
get
a
better
feel
for
what
are
their
their
requirements
and
assumptions.
F
So
I
went
through
some
of
the
specs,
including
OMA
OCF,
a
bunch
of
others
to
see
what
are
the
terms
that
have
been
used
in
the
specs,
and
this
is
the
list
that
I
had
it's
not
complete.
So
you
know,
if
you
find
something
that's
missing,
say
now
or
mention
on
the
list,
so
bootstrapping
provisioning,
onboarding,
initialization
registration,
commissioning
configuration
and
in
the
next
few
slides
you'll.
You
can
kind
of
see
how
some
of
these
SDOs
have
been
have
been
using
these
these
storms,
but
of
course,
I
might
be
missing
one
or
two.
F
So
so
so
one
of
the
stos
that
that
we
work
with
and
are
kind
of
interested
in
is
the
oma
lightweight
m2m
specification
and
basically
I
went
through
the
spec
to
see.
What's
the
what's,
the
term
they
are
using
and
basically
a
new
IOT
device
needs
to
contact
bootstrapped
server,
which
is
responsible
for
provisioning,
essential
information.
So
they
refer
to
the
fact
that
a
server
is
giving
credentials
to
the
devices
as
provisioning
and
once
the
device
is
provisioned,
then
it
goes
to
the
actual
lightweight
m2m
servers
and
registers
itself
there.
F
From
and
later
on,
this
lightweight
m2m
server
will
manage
the
client
device.
The
specification
talks
about
for
bootstrapping
modes,
so
there's
factory,
boot,
straps,
smart
card
client,
initiated
and
so
very
initiator,
I'm
sure
some
of
you
are
familiar
with
these,
but
they
are
quite
obvious,
so
in
implied
initiated
the
client
is
initiating
the
bootstrapping
in
server
initiated
it's
the
server
in
smart
card
there
is,
there
is
a
smart
card,
and
in
factory
there
is
like
some
some
things
that
are
burned
into
the
device
at
the
time
of
manufacture.
F
The
other
SEO.
Another
SEO
that
I
looked
up
looked
at,
and
perhaps
you
are
quite
interested
in
is
open
connectivity
foundation
and
this
sdo
cause
the
process
before
a
device
is
operationalize
onboarding
and
the
first
step
in
in
the
onboarding
process
is
configuring
the
ownership
of
the
device?
So,
basically,
if
you
have
a
new
IOT
device,
you
need
to
somehow
configure
who
is
the
owner
owner
of
this
device
and
they
list
a
bunch
of
owner
transfer
methods,
which
is
how
you
will
establish
a
owner
of
a
new,
completely
blank
IOT
device.
F
So
there's
the
gist
works,
which
is
kind
of
like
bluetooths
just
works,
so
you
basically
have
an
authenticated
if
you
have
an
exchange
and
if
there
is
a
man-in-the-middle
attack,
ur
then
well
too
bad.
So
it's
not
completely
secure
another
mode.
They
have.
Is
this
random
pin
where
the
IOT
device
is
supposed
to
generate
a
ping
and
show
it
to
the
user,
which
the
user
will
then
copy
on
to
this
onboarding
tool
and
onboarding
tool,
even
though
they
say
can
be
anything
it
can
like
run
on
any
device?
F
In
most
most
scenarios,
it
would
be
like
a
smartphone
application.
You
could
also
use
manufacturer
certificate,
though
they
don't
really
answer
in
the
spec.
How
so
like
yeah
a
manufacturer's
certificate
can
say
that
this
is
samsung
device
with
a
serial
number
so,
and
so
they
never
really
say
that
you
should
also
check
that
it's
the
same.
Serial
number
that
you
shown
that
there
is
shown
on
the
box
of
that
IOT
device.
F
So
it's
still
some
some
open
questions
and
then
there's,
of
course,
the
vendor
specific
option
where
they
don't
say
like
how
it's
done,
but
vendors
can
choose
how
how
they
wish
to
establish
the
owner
of
IOT
device.
But
the
idea
that,
at
the
end
of
end
of
this
process
there
is
the
owner
of
this
IOT
device
and
at
the
end
of
this,
this
new
owner
would
provision
or
configure
the
device
with
owner
credentials.
F
So
basically,
let's
say
after
just
works,
there
is
some
kind
of
a
session
key
and
using
this
session,
key
I
will
send
new
credentials
that
are
kind
of
that
I,
probation
or
configured
and
after
this
ownership
is
established.
I
would
also
send
more
information
like.
Where
is
your
bootstrap
server?
What
are
the
credentials
that
you
should
you
use
with
the
bootstrap
server
so
on,
but
again
a
mixture
of
terms,
so
there's
onboarding
configuring
provisioning
and
then
there's.
Of
course,
this
bootstraps
over
there's
also
device
provisioning
protocol.
F
So
this
is
a
specification
coming
out
of
the
Wi-Fi
Alliance
and
it
describes
itself
as
a
standardized
protocol
for
providing
user
friendly
Wi-Fi
set
up.
Dpp
also
relies
on
configurator,
so
most
likely
it
would
be
a
smartphone
application,
which
would
then
help
you
in
like
setting
up
all
your
other
devices
which
are
called
enrollees
in
the
network,
and
it
has
three
sub
protocols
and
or
three
phases.
So
there's
the
bootstrap
face
authentication
phase
configuration
phase,
so
here
like
the
they
use
provisioning
as
the
overall
step
and
and
then
inside
provisioning.
F
F
Perhaps
you
can
look
at
it
later,
but
again,
similar
idea
that
you
have
some
kind
of
key
pair
and
you
have
a
QR
code
that
you
scan
potentially
with
a
smartphone
and
and
then
there
is
some
kind
of
elliptic
curve,
diffie-hellman
key
exchange,
so
some
similar
patterns
doesn't
really
go
into
the
terms
that
match,
so
they
don't
really
use
any
of
these
common
terms
like
provisioning,
onboarding
bootstrapping,
but
rather
just
prescribe
what
what
the
device
and
and
the
controller
should
do.
So
what
are
the
common
pattern?
F
F
So
in
the
next
version
of
the
draft
I
plan
to
include
the
IDS
protocol,
so
so
in
the
current
version,
I
only
had
what
other
stos
are
doing,
but
I
plan
to
include
how
some
of
these
terms
are
used
within
our
own
specs
at
the
idea.
So
how
is
enrollment
used
and
brewski
and
what
is
a
zit
teepee
using
so
on?
F
Sorry
I'm
hearing
someone's
phone-
it's
not
not
mine,
then
you
have
p2p
ad-hoc
methods,
opportunistic
heap
of
faith'
methods
and
most
most
of
the
methods
are
actually
hybrid,
so
they
might
use
initially
like
some
kind
of
a
dog
setup
where
you
pair
with
your
smartphone
but
eventually
use
a
central
bootstrap
server.
So
yeah,
it's
it's
hard
to
classify
and
most
of
the
methods
are
like
some,
some
hybrid
where,
where
they
use
components
of
both
one
thing
that
I
would
like
to
cover
in
the
in
the
draft
and
I
think
which
is
important
and
fundamentally
effects.
F
Unless
you
know
the
Google
account,
which
is
there
on
the
phone-
and
this
is
like
a
preventive
mechanism,
if
your
phone
gets
stolen,
then
the
thieves
shouldn't
be
allowed
to
just
factory
reset
and
start
using
your
phone.
But
of
course
like
what,
if
you
had
the
sole
to
mately,
sold
this
on
a
flea
market
but
forgot
to
factory
reset
it
yourself.
F
So
should
the
next
owner
like
go
around
looking
for
the
previous
owner,
I
was
also
surprised
to
see
that
some
of
these
devices
actually
require
you
to
have
physical
access
before
you
can
revoke
any
like
keys
or
network
access
that
that
you
had
allowed
them.
So
at
least
I
saw
this
tomorrow.
Flood
sensor
requires
you
to
press
a
button
to
remove
it
from
your
network.
I
was
wondering
if
I
have
already
sold
it.
F
How
do
I
go
in
and
do
that
and
they
actually
require
you
to
press
the
button
while
it's
next
to
your
controller
or
smartphone,
which
which
I
find
it
like
weird?
So
this
is
something
that
that
is
often
overlooked,
but
fundamentally
affects
the
bootstrapping
process
and
fro
pole
and
is
something
that
there
is
worth
looking
at.
So
what's
the
status,
it's
some,
my
personal
github
and
I'm
open
to
receiving
pull
requests
and
issues
on
github
or
on
the
mailing
list.
Both
are
equally
welcome.
There
have
been
some
comments
in
the
past
on
this
draft.
F
A
B
Hello,
everyone
I'm
through
I'll,
be
presenting
our
draft
TLS
profiles
for
IOT
devices.
This
draft
extends
smart.
What
is
the
manufacture
user
description
specification
to
describe
TLS
infractions,
modest
search,
fits
RFC,
eight,
five
to
zero,
which
defines
l3
l4
a
seals
for
permitting
intended
behavior
for
IOT
devices,
because
I
would
really
versus
typically
have
specific
purpose.
B
What
we
have
been
seeing
in
the
last
few
years
is
malware
has
started
using
TLS,
more
and
more
malware
that
are
coming
every
year
are
using
TLS
and
very
few
malware's
are
now
using
clear
text,
but
the
diff,
but
we
see
a
lot
of
differences
between
the
way
malware
uses
TLS
versus
what
we
see
tail
is
used
by
legitimate
software.
For
instance,
we
see
the
domain
name.
B
The
subject
name
indicated
quite
different
from
the
subject
or
name
malware
uses
domain
generation,
algorithms,
the
cipher
suits
and
as
TLS
extensions
used
by
malware
is
quite
different
and
what
is
used
by
abandoned
software
malware
also
uses
self-signed
software
we've
been
we
providing
IOT
security
for
several
devices,
and
what
few
observed
is
that
many
of
these
IOT
devices
do
not
follow
the
best
current
practices.
For
instance,
we've
seen
a
greedy
vs.
B
which
are
using
expired
certificates
are
using
weak,
cipher
suits
and
many
of
these
IOT
devices
come
hard
coded
with
the
same
private
keys,
and
we
also
see
that
many
of
these
IOT
devices
are
vulnerable
to
server
certificate
validation
which
caused
them,
which
makes
him
susceptible
to
man-in-the-middle
attacks.
For
instance,
us
back
something
had
a
wonderful
tea
where
it
was
subjected
to
a
my
TM
attacks,
because
it
was
unable
to
properly
evaluate
the
server
certificate.
The
key
benefits
of
mud
TLS
profiles
are
that
it
can
define
TLS
profiles
for
IOT
devices
that
have
diverse
communication
patterns.
B
So
as
part
of
this
draft,
we
have,
we
exchanged
them
at
a
young
model
to
include
the
observable
TLS
profile
parameters.
The
TLS
profile
parameters
is
defined
once
for
use
and
TLS
profile
can
also
be
defined
specifically
for
specific
destinations,
for
example,
from
where
server
using
a
specific
private
CA,
so
that
we,
the
CAS,
could
also
be
specific
to
specific
destinations.
I
have
various
examples
here:
I've
listed
Google
Chrome
as
an
exam
as
an
example
to
see.
B
Show
you
how
the
cipher
suits
used
by
benign
flows
on
a
Google
home
is
quite
different
from
the
cyber
suits
used
by
malware
flows,
and
the
protocol
versions
were
also
different.
That
malware
was
using
priority.
Ls
versions
and
the
benen
flows
were
using
TLS,
1.2
and
higher.
The
number
of
extensions
were
also
different
extension
types,
deferred
groups
and
all
the
most
of
the
parameters.
We
saw
quite
a
bit
of
differences
between
the
way
malware
and
been
in
flows
for
behaving
on
Google
moment.
B
D
F
So
till
you
I
have
three
quick
questions
which
are
going
in
one
go
and
then
you
can
see
if
there
is
time
to
answer
so
one.
This
looks
like
IETF
worked
and
then
I
adhere,
but
I
don't
really
care
where
this
this
work
is
done,
it's
up
to
you
and
cheers
and
another
people.
Second
question:
this
is
like
a
typical
cat
and
mouse
game
that
currently
malware
doesn't
use.
This
kind
of
cipher
suits
and
you
will
start
filtering
them
and
they
would
eventually
move
to
the
same.
F
Cipher
suits
that
that
is
used
by
Google
or
I
know
the
same
same
parameter.
So
it's
it's
like
a
temporary
cat-and-mouse
game
that
we
might
win,
but
eventually
I
feel
that
they
would
use
exactly
the
same
protocol
versions.
I
see,
there
is
no
reason
why
malware
would
use
TLS
one
and
not
one
or
three
or
particular
mode
of
AES,
and
not
not
the
other
mode
of
a
yes.
So
that's
that
that
that's
another
thing.
F
How
often
our
Google
device
is
moving
from
one
version
of
TLS
to
another,
and
my
worry
is
that
when
eventually
they
update
the
software
or
firmware
the
profile
would
not
be
updated
at
the
same
time,
because
you
know
the
mud
profile
is
from
from
this
URL
so
since
I'd
actually
break
when
you
start
updating
like
to
a
new
curve
or
to
a
new
protocol,
because
those
things
happen
so
rarely
that
there
is
no
to
do
coverage
testing
for
that.
So
that's
something
to
consider
that
deep,
it
might
break
say.
B
Hey
thanks
I
mean
all
the
valid
questions,
so
I'll
just
answer
quickly,
each
of
them
and
we
can
take
it
offline.
So
this
draft
is
currently
dis
question
the
operations
and
management
working
group.
So,
at
the
reason
why
I
brought
it
to
the
research
group
was
since
many
of
the
IOT
devices,
especially
the
home
I,
would
read.
He
was
a
student
support
mod.
We
were
looking
for
a
way
to
collaborate
and
profile,
benin
and
malware
flows.
The
second
question
regarding
malware
catching
up
and
exhibiting
the
same
behavior
as
menon
flows.
B
Yes,
that's
a
possibility
and
we
have
been
I
work
for
McAfee
and
we've
been
seeing
the
malware
behavior
for
several
years
and
they
always
catch
up.
But
the
challenge
here
is
they
can't
catch
up
in
a
way
that
they
may
make
the
behavior
of
the
tls
profile
on
each
and
every
IOT
device.
For
instance,
the
malware
has
to
tailor
itself
so
that
they
use
the
same
TLS
profiles
and
from
our
observation,
the
TLS
profiles
for
each
of
these
IOT
device,
even
with
different
models,
was
different
from
each
manufacturer.
B
So,
unless
the
malware,
a
manufacturer,
malware
provider
comes
up
with
a
way
that
he
Taylor
says
malware
to
be
specific
for
each
IOT
device
type
make
it
model,
it's
gonna
be
really
impossible
because
they
typically
use
a
rootkit,
and
it's
going
to
be
really
unequivocal
for
them
to
basically
suit
and
tailor
their
a
malware
for
each
IOT
device.
The
third
question
was
yes.
These.
This
requires.
A
Excellent,
thank
you
tiro
and
the
interest
of
time.
We
need
to
take
the
rest
of
the
questions
on
the
mailing
list,
but
Sevilla,
u
P!
Next,
please
go
ahead
and
start
the
presentation
and
have
quite
a
lot
of
know.
We
don't
have
much
much
time
that
I'm
afraid
we
might
be
going
a
few
minutes
over
time,
still
make
it
through
the
presentation.
Let's
go
ahead.
J
J
With
a
short
history
of
the
draft,
I
will
go
quickly
on
that
one,
so
we
presented
the
first
time
in
ITF
103
and
there
was
a
discussion
in
ITF
104
on
edge
and
iut
meeting
where
this,
what
was
considered
a
possible
starting
point
for
a
group
document
to
kick
off
this
activity.
So
between
this
ITF
and
the
next,
a
new
co-authors
joined
and
in
ITF
105,
we
presented
a
renamed
version
of
the
draft
in
it
was
integrated
with
survey
and
gap
analysis
presentation
made
earlier,
indeed
etiology.
J
J
So
in
terms
of
updates,
we
made
editor
editorial
and
clarification
edits
in
all
sections,
especially
we
kind
of
wrote
the
abstract
and
introduction
we
reorganize
the
draft.
So
now
you
have
like
three
main
sections:
you
have
the
background,
challenges
and
edge
completing
functions,
and
we
extended
the
background
from
section
on
edge
computing
to
cover
different
understandings
of
edge.
You
know,
depending
on
people's
background
background,
can
be
in
cloud
a
telco
industry
or
industrial
automation,
and
we
also
expanded
on
the
term
fog
to
give
it
somewhat
of
an
equal
weight
in
this
section.
J
We
extended
section
5
to
detail
the
list
of
functions,
including
detailed
challenges
functions
you
know
which
are
listed
here
on
the
on
the
Left
can
be
present
in
some
all
modems.
You
know
either
centralized
or
decentralized,
and
the
models
are
still
covered
at
the
beginning
of
the
section.
5
functions
are
loosely
classified
as
functional
and
application
components.
J
This
classification.
We
are
aware
of
that.
It's
you
know
it
could
be
made
better
or
you
know
it's
not
always
what
I,
what
I
mean
that
it's
not
always
very
clear
in
some
systems,
some
systems
would
be
we'll
see
more
integration
between
these
different
layers,
but
it's
not
prescriptive
and
it's
call
it's
just
to
be
to
clarify
the
text.
J
J
You
know
this
function
and
some
challenges
associated
to
it
and
we
added
a
5.4
on
simulation
emulation
environments.
It's
you
know
ring
that
only
open-source
tools,
but
also
the
current
EDC
Mac
sandbox
initiative,
for
example,
not
for
reviewers,
the
section
4
and
5
both
have
challenges.
You
know,
research
challenges
listed
section,
4,
describe
challenges
on
the
IOT,
leading
to
the
adoption
of
edge
computing
and
section.
5
covers
different
types
of
challenges
associated
with
individual
educating
functions,
so
we
don't
want
to
hold
off
any
no
reviewers.
J
So
please,
you
know
if
you
wish
to
review
this
document,
please
be
aware
that
boost
our
you
know.
Different
types
of
challenges
will
be
covered
in
different
places
in
there,
so
we
have
also
shot
version.
3
update
that
we
made
based
on
in
part
on
some
comments
from
Rooter
on
the
list.
So
we
had
we
added
several
clarifications,
including
that
devices
can
be
computing
notes
and
also
we
expanded
on
the
mobility
support
challenge.
J
There
are
still
some
areas
we
think
need
to
be
improved
and
clearly,
but
we
would
like
to
gather
some
feedback
and
base
improvements
on
the
feedback
you
know
from
from
reviewers.
So
we
like
to
highlight
just
a
few
points
for
people
who
wish
to
review
the
doc
first
know,
as
mentioned
in
the
last
slide.
Please
be
aware
of
the
relationship
between
challenges
in
Section,
four
and
five.
J
Then
the
models
we
have
for
IOT
edge
computing
in
Section
five
can
be
extended.
Some
of
the,
for
example,
some
of
the
coauthors
have
made
some
progress
on
distributed
models
and
we
like
to
share
some
insights
in
there.
So
we'll
probably,
we
will
probably
update
that,
but
maybe,
after
after
a
range
of
first
set
of
reviewers
and
individual
functions,
descriptions
in
section
five
can
also
be
developed
further,
for
you
know,
especially
in
the
detailed
challenges.
J
So
for
now,
the
level
of
the
details
in
the
section
can
be
a
beaten
egg
wall,
some
some
sections
of
research
challenges
listed
and
some
don't
we
we
need
to
work
on
that,
but
also
the
input
from
the
group
would
be
greatly
appreciated.
On
this.
Finally,
I
mean
the
security
related
contributions
and
commands
are
also
welcome.
So,
to
conclude,
the
draft
is
now
available
for
the
research
group
to
review
and
to
computer
for
research
group
function.
J
D
D
D
Plus
one
for
a
review,
so
I
think
we
have
to
take
this
to
the
list.
I
think
we
do
need
a
couple
of
reviews
to
assess
whether
this
can
go
ahead
as
a
research
group
document
I
would
want
to
remind
people
that,
when
they
write
the
reviews,
the
the
criteria
for
accepting
something
as
a
research
document
is
that
we
consider
the
word
used
for
it.
Not
that
we
agree
with
every
point
of
view.
Would
that
be
authors
have
taken
so
research
route
documents
do
not
need
to
be
consensus
documents
they
need
to
be
useful
documents.
D
A
Thank
you,
unfortunately,
and
apologies
for
running
a
few
minutes
late
and
just
a
reminder.
This
was
a
a
summer
meeting
where
we
give
a
quick
overview
of
the
topics
were
working
on
if
you're
interested
in
working
on
the
details,
please
join
the
discussion.
The
painting
list,
showing
the
upcoming
work
meetings
that
we
always
announce
with
the
mailing
list
to
see
many
of
you
contributing
on
all
their
upcoming
activities
in
the
future.