►
From YouTube: IETF110-T2TRG-20210311-1600
Description
T2TRG meeting session at IETF110
2021/03/11 1600
https://datatracker.ietf.org/meeting/110/proceedings/
B
B
A
Okay,
we
have
waited
two
two
minutes,
which
is
the
half
of
the
official
ietf
four
minute
standard
delay.
But
let's
start
anyway.
So
this
is
the
thing
to
sing
research
group.
Custom
bowman
is
me
ari
karen.
Is
there
as
well
or
can
you
show
your
video,
because
I
don't
have
video
this
week,
because
my
wife
has
the
video
capable
set
up
for
doing
exams.
B
Yeah,
okay,
it's
try
testing
screen
sharing,
but
it
wouldn't.
Let
me
in
the
test
setup.
So
hopefully
it
works.
A
A
This
is
my
version
of
the
node
slide,
which
tells
you
that
you
may
be
recorded.
Rightly,
you
are
being
recorded.
A
We
try
to
be
nice
and
professional
and
the
ipr
guidelines
the
intellectual
property
rights.
If
you
like
that
term
guidelines
of
the
itf
apply,
so
you
can
go
to
the
link
shown
there
to
find
out
more
details,
but
there's
actually
a
long
version
of
that
which
you
all
are
reading
and
understanding
now,
so
I
can
move
forward
to
code
of
conduct
and
anti-harassment
and
so
on
and
okay.
So
that
should
be
the
the
formal
part.
A
A
We
have
a
mailing
list
and
we
also
have
a
repository
for
each
meeting.
So
in
the
github
organization
tjrg,
you
find
repositories
for
each
meeting
and
some
additional
repositories
and
the
one
for
this
meeting
is
as
convention
conventionally
called
2021-iitf.
110.
A
Intro
stuff
is
what
what
I'm
doing
right
now.
There
will
be
a
couple
of
reports
from
various
activities,
including
wishy
and
and
the
asd
asdf
rishi
hackathon
we
just
had,
and
then
we
will
have
updates
from
various
organizations
this
time
from
w3
3c
web
of
things
and
from
1dm
one
data
model
and
at
1650
utc.
We
will
actually
move
to
contributions.
A
Michael
richardson
will
talk
about
the
taxonomy
of
operational
security.
Savvy
will
talk
about
progress
in
the
iot
edge
document,
which
already
is
a
research
group
document.
So
we
hope
to
publish
this
one
shown
soon
and
mohit
will
talk
about
the
bootstrapping
terminology,
which
has
been
around
10
years
now.
A
Okay,
so
let's
talk
about
the
research
group
for
for
a
short
time
in
case
new
people
are
here.
What
is
the
point
of
the
think
to
think
research
group?
Well,
the
point
is
that
we
have
a
large
number
of
standardization
activities
in
the
ietf
that
that
are
related
to
the
internet
of
things,
depending
on
how
you
count
them.
A
So
we
focus
on
issues
where
there
might
be
opportunities
for
ietf
standardization
and
really
it
really
starts
slightly
above
layer
2
and
ends
at
application
layer,
security
functions,
possibly
even
user
interface.
I
think
we
had
a
proposal
at
one
point
to
actually
collect
icons.
That
would
be
used
in
in
a
user
interface
for
iot
things.
I
think
that's
something
we
should
pick
up
again
at
some
point
so
visually.
If
you
look
at
the
way
the
irtf
and
the
ietf
interacts,
the
the
irtf
think
the
thing
research
group
is
at
the
top.
A
Of
course,
we
also
interact
with
other
research
groups,
which
is
not
shown
on
this
picture,
but
we
we
interact
with
other
groups
in
the
with
working
groups
in
the
itf,
and
there
are
the
actual
engineering
working
groups
like
core,
which
has
been
doing
copen
related
protocols
and
a
more
recent
one
is
asdf,
which
is
engineering,
a
format
for
supporting
iot
model
convergence
in
in
the
sense
of
consolidation
and
transformation.
A
There
are
also
some
groups
in
the
itf
that
also
are
more
on
the
informational
side.
So,
for
instance,
there
is
the
eric
group
which
has
recently
completed,
for
instance,
some
really
interesting
work
on
on
getting
the
right,
ecc
curves
out
there
for
constrained
devices.
They
have
looked
at
tcp
for
constraint,
uis
and
so
on.
So
that's
what
eric
does
and
there
is
a
very
new
thing
called
iot
ops,
which
is
discussing
operational
issues
which
often
are
security
issues
in
the
end.
So
it's
a
very
interesting
group
to
interact
with.
A
The
the
meetings
we
are
trying
to
organize
are
summary
meetings
like
the
current
one,
where
we
try
to
to
bring
things
together.
We
also
have
been
having
regular
wishy
calls
work
on
inter
ability.
A
What
is
the
expansion,
some
something
with
interability,
hyper
media
and
and
something
where
we
meet
approximately
monthly
and
discuss
various
things
that
has
been
paused
for
a
while
and
is
now
picking
up
again,
and
I
expect
that
we
will
do
this
monthly
again,
then
we
have
interaction
with
various
other
sdos
that
use
ietf
or
that
are
related
to
ietf
products
like
oma
and
ocf
and
and
w3c.
A
So
what
what
ever
we
want
to
do?
There
is
usually
organized
around
a
specific
topic
that
we
want
to
advance.
A
A
A
There
was
a
question
in
in
the
chat
that
I
missed
what
about
ap
when
and
sheik
at
the
crab
level?
Interesting
questions
again
there
are.
There
are
15
working
groups
that
really
do
stuff,
that
is
iot
related,
and
if
people
want
to
bring
up
things
that
have
more
researchy
perspective
to
them,
please
do
just
send
a
brief
message
to
the
mailing
list
and
we
can
start
the
discussion.
A
A
There
are
several
documents
that
are
research
group
documents
that
we
have
adopted.
The
restful
design
for
iot
document
has
recently
got
the
terminology,
update
and
probably
needs
one
more
pass
before
we
can
sign
this
off.
A
We
will
talk
about
the
the
edge
computing
and
iot
document
today,
and
I
think
the
the
document
is
pretty
much
cooked,
but
we
we
need
a
few
reviews
to
actually
decide.
This
is
ready
for
publication.
A
We
have
a
secure
bootstrapping
for
iot
document
that,
as
I
said,
has
been
around
for
a
while,
and
we
probably
should
be
adopting,
and
also
there
are
some
non-internet
draft
documents
called
wishy
notes
which
are
collecting
at
the
wishy
wiki
and
that's
also
activity
that
should
be
ramping
up
again.
Now
that
we
are
done
with
our
asdf
support
activity
in
wishy,
which
kind
of
occupied
much
of
2020.
A
So
which
yeah
that's
the
expansion?
Sorry
work
on
iot
semantic,
hyper
media
internal
ability.
So
this
is
where
we
are
semantics:
data
models
hyperlinks
and
similar
things
go.
So,
as
I
said,
we
we
have
been
trying
to
help
the
the
asdf
working
group
get
off
the
ground
that
is
done
dear
now.
A
Actually
the
the
the
asdf
working
group
has
completed
its
first
deliverable
today,
so
we
haven't
published
an
rfc
yet
because
we
still
want
to
work
on
the
sdf
format,
but
we
have
after
1dm
brought
us
a
working
sdf,
1.0
version.
We
have
managed
to
actually
get
a
1.1
1.1
version
agreed
to
today
and
that
will
be
ongoing,
but
it
will
no
longer
be
an
irtf
activity.
A
We
are
looking
at
the
various
standards
in
this
space
in
the
semantics
and
hypermedia
space,
and
we
are
really
interested
in
describing
them
so
finding
out.
How
do
these
things
fit
together?
Where
are
they
similar?
Where
are
they
doing
very
different
things?
Because
it's
really
hard
when,
when
you
learn
about
a
new
thing,
actually
penetrating
the
marketing
materials
and
and
finding
out
what
it
actually
is,
and
we
actually
had
an
online
wishing
meeting
since
the
last
itf
and
also
an
asushi
hackathon,
I
will
talk
about.
A
A
One
was
focusing
on
on
validating
sdf
1.1
and
essentially
preparing
the
decision
that
was
made
today
to
to
label
the
current
version
as
sdf
1.1
and,
of
course,
the
tools
and
models
that
are
still
sdf
1.0
need
some
attention
to
move
them
to
1.1
michael
costa
produced
a
very
interesting
modbus
example
that
tells
us
how
to
include
ecosystems
that
are
very
much
focused
on
registers
and
and
bits,
and
and
so
on
into
this
space.
A
We
actually
defined
some
some
part
of
scf
1.1
that
that
was
just
missing
the
fragment
identifier
considerations
and
we
also
identified
a
problem
with
one
component
of
sdf
1.0
that
we
we
we
are
going
to
work
on
in
sdf
one
point
next,
but
that
that
is
not
currently
part
of
sdf
1.1,
and
we
also
had
an
interesting
discussion
about
the
compact
notation
for
for
sdf.
A
So
we
are
now
starting
in
earnest
to
get
tools
that
operate
on
on
sdf
models
and
build
new
models
out
of
existing
models,
and
that's
certainly
something
that
that
is
worth
some.
Some
research
and
finally,
we
discussed
mapping
files
which
are
a
way
to
add
information
to
an
sdf
model
that
might
be
ecosystem
specific,
so
like
ipso
or
zigbee
or
bluetooth,
or
might
even
be
instant.
Specific
and
one
aspect
is
how
to
add
protocol
binding.
So
you,
you
have
some
abstract
property
in
the
sdf
model
at
it.
A
A
Okay,
yeah
with
that
more
updates
and
I
hand
over
to
mila.
A
Okay,
so
maybe
we
just
push
this
to
a
later
point.
I
don't
see
him
in
the
participants.
A
Thank
you.
So
I
think
that
completes
the
the
chairs
part
of
the
overview
and
we
can
now
move
over
to
michael
mccool's
presentation.
B
Here
we
go
great
okay,
so
I
already
typed
in
some
stuff
into
the
notes.
So
for
follow-up
be
aware,
there's
some
urls
and
things
like
already
typed
into
the
into
the
script.
I'm
just
going
to
quickly
go
through.
You
know
this
and
see
what
we
can
do
here.
B
So
the
web
of
things
is
a
w3c
activity
which,
as
you
probably
know,
focuses
on
web
technologies
most
of
the
browser,
but
the
the
wall
activity
is
focused
on
iot
and
is
focused
on
applying
those
web
technologies
to
iot,
and
we
didn't
want
to
create
a
completely
separate
vertical
stack,
because
one
of
the
big
problems
with
iot
is
the
proliferation
of
different
silos.
B
So
instead
we
try
to
identify
a
gap
and
the
gap
we
identified.
This
was
you
know
three
or
four
years
ago,
was
the
lack
of
documentation
between
different
standards
and
how
to
connect
different
things,
and
you
know
it
was
very
hard
to
use
a
system.
It
wasn't
well
documented,
and
we
wanted
to
see
the
gap
we
saw
was
actually
a
need
for
formal
documentation
of
you
know
the
capabilities
and
way
to
access
a
system,
and
we
also
want
to
create
kind
of
a
common
abstraction
layer.
B
B
Instead,
every
app
could
support
a
common
abstraction
in
terms
of
you
know,
kind
of
a
generic
interface
and
that
abstraction
can
be
mapped
to
various
protocols.
But
you
still
we're
not
trying
to
like
create
a
new
protocol
that
does
everything
instead
we're
trying
to
create
a
common
description
language
so
that
apps
can
easily.
You
know
use
protocols
directly,
but
through
an
abstraction,
so
we
do
think
that
the
common
protocol
for
everything
you
know
is
not
the
ship.
That
is
sailed.
That's
not
really
feasible.
B
Now
I
just
want
to
give
a
brief
example
what
he
looks
like,
so
we
are
again
focusing
on
describing
existing
systems
in
a
thing
description,
so
we're
not
trying
to
be
prescriptive.
We
are
trying
to
support.
I
mean
there
is
some
recommendations
for
new
devices
that
are
ridden
from
scratch,
but
we
also
want
to
have
ability,
support,
brownfield
devices,
devices
they're
already
deployed,
and
you
know
you
just
want
to
figure
out
how
to
talk
to
them.
B
At
any
rate,
the
thing
description
is
this
json
ld
file-
and
you
know
it
includes
you-
know,
properties,
events
and
actions,
there's
an
information
model
for
it
and
technically
jason
ld
is
one
possible
serialization
of
the
information
model
for
a
td,
but
it
does
mean
that
it's
easy
to
ingest
into
things
like
an
rdf
database
and
then
be
able
to
do
things
like
semantic
searches
on
it,
so
which
is
kind
of
the
next
point
here
and
well.
Let
me
just
talk
about
where
we
are
with
our
process,
so
we
we
published
a
bunch
of
standards.
B
Well,
we
punched
the
thing
description
and
the
architecture
in
january,
technically
and
well
january
last
year,
and
now
we're
working
we're
almost
at
the
end
of
our
second
charter,
where
we're
doing
several
updates,
we're
updating
our
theme,
description
and
we're
updating
the
architecture
document
we're
also
developing
some
new
standards
in
discovery
and
profiles
and
discovery
is
really
about.
Okay.
How
do
I
find
metadata
and
it's
not
just
about
land
discovery?
B
So
it's
a
more
general
concept
of
finding
metadata,
and
it
also
has
a
strong
emphasis
on
privacy
preservation,
which
is
one
of
our
major
constraints
and
profiles
is
more
about
constraining
the
implementations
a
bit
so
that
things
work
out
of
the
box
there's
also
some
updated
documents.
Binding
templates
is
very
similar.
B
B
Now
so
I
think
that
that's
basically,
you
know
the
summary,
and
I
think
that
to
get
mentioned
a
bit
more
about
you
know,
discovery
discovery
is
one
of
our
major
new
thing.
I
guess
I've
spent
the
timeline,
so
we're
currently
finalizing
our
draft
with
the
intention
of
having
solid
first
drafts
end
of
march,
and
then
we
want
to
have
complete
drafts
ready
for
review
by
may
1st
and
we're
looking
at
entering
the
formal
process
and
keep
training
into
a
standard
within
w3c
at
the
beginning
of
july.
B
So
between
may
1st
and
july,
we'll
be
open
for
review
and
we
can
still
make
changes
at
that
point.
But
then,
after
the
july
first
deadline,
it's
really
hard
to
make
changes,
so
so
that's
kind
of
the
window
that
we
want
to
target.
If
people
want
to
look
at
our
standards
and
contribute,
we
do
want
to
kind
of
wrap
things
up
in
the
next
few
months
and
and
stabilize
these.
B
I
should
also
mention
for
thing
description,
we're
starting
a
thing
model
and
the
thing
mod,
so
thing
description
is
about
instance,
of
a
device.
A
thing
model
removes
instance,
particular
definitions,
like
particular
urls
or
network,
addresses
so
they're
close
thing
models
are
closer
in
concept
to
sdf
files
and
there's
been
some
exploration
about
converting
stf
files
into
thing
models
and
to
go
to
a
thing
description.
You
also
need
things
like
network
address.
B
B
But
okay:
well
I
guess
maybe
we
can
move
on,
but
if
anyone
wants
to
follow
up,
we
do
have
a
face-to-face
next
week.
Actually,
the
next
two
weeks
and
if
you
would
like
to
attend
some
of
the
open
sessions,
send
me
an
email
and
we
can,
we
can
get,
we
can
bring.
You
bring
you
in
as
a
guest,
otherwise
the
web
page
and
the
specs
are
out
there
at
these
urls.
A
Yeah,
thank
you
michael.
There
are
some
pretty
good
links
in
the
cody
md
in
the
notes
document.
So
if
you
want
to
know
more
about
these
activities,
I
want
to
find
out
what's
happening
in
the
next
few
weeks.
Please
look
at
the
the
notes
and
there
are
links
you
can
click
on.
Unfortunately,
you
cannot
link
on
the
quick
click
on
the
links
here
in
in
the
slides
that
we
are
looking
at.
That's
the
limitation
of
mute
echo.
B
A
D
Yeah
good
morning,
I'm
milan
de
la
cruz
from
calling
from
california
this
morning,
and
this
is
a
brief
update
about
three
minutes
on
the
paper
and
activity
that
we
are
starting
in,
describing
the
iot
standards.
I'm
gonna
get
the
next
slide.
Please,
oh,
am
I
can
I
move
the
slides
or
okay
great,
and
so
basically
we
have
had
the
discussion
for
a
while
in
to
tr
research
group
and
then,
basically
in
wishy
meetings,
to
create
a
paper,
probably
in
the
form
of
informational
rfc.
D
That
will
describe
key
attributes
of
iot
standards,
nothing
new
there
and
information
models,
but
in
a
consistent
manner,
basically
agree
on
the
structure
and
the
concept
and
how
they
are
described
and
then
allow
standards
to
be
described
in
a
consistent
manner.
This
is
important
and
potentially
useful,
because
different
standards
groups
have
different
assumptions,
some
of
which
are
articulated,
some
of
which
are
not.
They
have
some
implicit
point
of
views
that
are
not
clear.
D
So
what
we
are
looking
for
is
is
trying
to
do
a
sort
of
high
level
description
but
provide
some
structure
and
almost
like
the
checklist
of
what
is
the
intent.
What
is
the
purpose,
the
scope
and
the
approach
using
some
common
terms
and
criteria,
and
and
and
then
doing
so
define
the
terms,
articulate
the
concept
assumptions,
not
the
implicit
assumptions
or
everybody
in
the
group
knows
it
sort
of
becomes
a
group
knowledge
by
osmosis.
But
it's
not
always
obvious
in
documents.
D
D
Labeling
guide,
like
you,
have
the
food
labels
in
terms
of
nutritional
contact
and
calories
and
various
others
think
agreeing
on
what
is
the
structure
of
the
things
to
be
described
and
how
they
are
quantified,
obviously
wouldn't
be
quantifying
them
here,
but
we
would
provide
a
common
basis
for
comparison,
a
straightforward
which
is
you
know
we
like
to
do
it
we'll,
try
and
see
if
we
succeed
is
to
get
some
of
the
important
ongoing
standards
described
in
this
manner
or
at
least
and
concept
described,
obviously
not
the
specifications
and
we
would
rely
initially.
D
D
So
the
current
status
is,
we
have
discussed
in
an
earlier
meeting
in
june
in
t2
trg
strowman,
of
what
the
common
description
criteria
need
to
cover.
What
are
sort
of
the
items
we
think
will
cover
that's
available
as
a
document
at
this
link,
and
the
suggestions
are
welcome.
It
can
give
you
an
idea
of
what
the
outline
of
things
in
this
effort
the
outline
the
first
sort
of
draft
that
puts
everything
down,
not
necessarily.
Obviously
the
final
form
is
planned
in
about
six
to
eight
weeks
and
I'll.
D
D
If
you
have
also
done
there
are
several
floating
comparisons
of
applicable
standards
that
contact
the
authors,
often
see
if
they
want
to
participate
and
obviously
they
will
be
incorporated
as
references
into
this
work
and
in
terms
of
actually
describing
standards
along
this
line.
I
know
we
have
discussed
earlier.
Both
michael
koster
and
michael
mccool
have
done
some
more
detailed
feature,
analysis
of
various
standards
and
comparison,
and
we
I'll
work
with
them
also
and
we'll
work
together
to
incorporate
those
as
well.
D
This
is
basically
a
very
brief
update
that
I
wanted
to
give
you
on
this
activity
and
obviously,
when
we
have
the
first
draft,
it's
going
to
be
more
tangible
and
something
to
discuss.
That's
basically,
my
update,
and
I
give
it
back
to
captain.
A
A
Thank
you
so
in
this
case
we
are
on
time.
The
next
item
is
michael's
presentation.
Do
you
want
to
present
michael.
E
Share,
I
put
the
request
yep
all
right,
you
get
that
and
we
can
just
run
the
slide
from
here.
Do
you
see
it
it's
working
on
it
yeah.
E
A
A
E
I
learned
why
it
was
that
I
don't
often
update
my
system,
but
the
longer
you
wait,
the
more
painful
it
is,
and
basically
every
application
now
acts
like
it's
brand
new
and
anyway
great.
So
this
is
a
summary
of
what
we've
been
doing
with
one
data
model
mostly
and
some
other
related
things
also
next
slide.
Please,
our
goal
in
one
data
model
was
originally
or
is,
is
still
mainly
to
normalize
the
information
models
for
iot,
pretty
much
across
industry,
information
models
and
data
models,
but
it
really
is
an
information
model
focus.
E
We
call
it
one
data
model.
I
think,
maybe
some
historically,
that
most
people
recognize
that
and
saying
information
model
is
more
correct,
but
you
know-
and
it
brings
up
some
questions,
so
it
seems,
like
you
know,
we're
all
right.
That's
it
this
way,
what
we
ended
up
really
deciding
to
do
was
really
kind
of
refine
that
mission
a
little
bit
and
what
we're
providing
for
really
broad
semantic
interoperability
across
industry.
E
We
want
to
converge
the
existing
models
and
we
want
to
create
a
system
of
interoperability
and
reusability
at
the
semantic
level,
among
other
things,
so
it
started
as
a
liaison
group
between
sdos,
and
you
know
we
have
zigbee
and
oma
and
ocf
and
bluetooth,
mesh
and
and
some
other
more
vertical
oriented
ones,
and
we
decided
to
focus
on
a
representation
language,
a
modeling
language
or
a
domain
specific
language
for
this
work
and
that
the
outcome
of
that
was
sdf.
E
Next
slide,
please
the
current
status
is.
We
have
about
200
examples
of
object
models
which
are
the
main
sort
of
reusable
building
block
it.
It's
a
slice
of
functionality
like
turning
something
on
or
off
and
or
changing
the
color,
and
so
a
typical
product
will
have
a
a
set
of
these
object
models
to
describe
its
full
functionality.
But
we
have
200
of
these
mainly
the
whole
catalog
of
ocf
and
and
episode.
E
Smart
objects
minus
a
few
that
are
kind
of
corner
cases
and
then
a
few
examples
from
zigbee
and
bluetooth,
but
we
haven't
done
any
wholesale
conversions
from
from
from
those
catalogs
yet,
but
that's
in
the
future.
E
We
have
automated
tools
that
have
been
built
by
folks
on
the
call
here,
mostly
converting
from
ocf
and
oma
back
and
forth,
around
tripable
to
and
from
sdf,
and
that's
where
all
those
200
models
came
from
is
there's
some
automated
conversion.
E
New
models
also
can
be
easily
generated
in
sdf
and
then
converted.
You
know
down
converted
if
you
are
targeted
toward
oma,
ocf
or
others.
Once
we
have
the
converters
and
the
whole
system,
then
models
can
be
translated
from
one
ecosystem
to
another.
Through
the
standard
sdf
models,
I
can
take
an
ocf
model
and
up
convert
it
to
sdf
down
converted
to
oma.
E
For
example,
and
that
allows
me
to
can
translate
from
one
model
to
another
next
slide,
please
so
the
one
one
was
mentioned,
the
semantic
proxy.
This
is
one
useful
one
use
of
this
ability
to
translate
those
models,
and
this
is
sort
of
picture,
gets
refined
a
little
every
time
this
is
sort
of
the
best
one.
E
So
far,
if
we
were
to
use,
we
already
have
some
proxy
functionality
with
web
of
things
in
in
a
project
called
the
eclipse
project
called
node
watt
and
it
consumes
it
or
it
uses
thing
description
to
consume
and
expose
apis.
E
To
sort
of
you
know.
Continuity
test
various
parts
of
this,
but
this
is
what
we're
working
for
is
our
sort
of
first
big
demo
for
one
dm
and
why
you
want
your
models
on
one
dm
and
one
of
the
one
of
the
useful
things
that
can
happen
other
than
just
you
know,
everyone
converging
and
arriving
at
a
common
set
of
models.
If
you
want
to
translate
models,
this
is
a
great
intermediate
step.
E
Alright
next
slide,
please
we
need
to
kind
of
finish
up
here
to
stay
on
time
so
going
forward,
since
we
have
the
now
a
stable
implementation
draft
of
the
language,
we're
going
to
go
out,
reach
out
to
zigbee
and
the
bluetooth
mesh
folks
and
some
of
the
others,
and
and
start
getting
contributions
in
and
start
working
on
the
conversions
and
eventually
get
going
on
our
convergence
process.
E
So
we
have
also
a
few
broader
use
cases
and
collaborations
we're
involved
with,
as
some
of
this
has
been
mentioned
before,
but
there's
a
solar
energy
spec
sunspec
that
currently
have
a
modbus
register
definition,
but
we
could
add
all
the
semantics
to
that
and
and
they
were
interested
about
a
year
ago.
So
we
want
to
get
that
and
so
there's
some
folks
doing.
Textile
manufacturing
equipment
contacted
us.
E
There's
some
work
being
done
on
electronic
data
sheets.
That
is
closely
related.
That's
they
would
like
to
look
at
using
sdf
again
there's
an
iso
sc41
sort
of
it's
a
little
tighter.
E
I
guess
you'd
say
they
sort
of
would
want
to
see
sdf
be
sort
of
part
of
part
of
that
and
not
clear
exactly
how
the
integration
is,
and
maybe
others
could
explain
it
a
little
more
and
also
we
were
contacted
by
the
u.s
standards
bureau
called
the
national
institute
for
standards
and
technology
or
nist
in
the
u.s
to
to
look
at
common
ways
of
modeling
things,
and
they
were
quite
interested.
Also.
E
A
lot
of
this
is
basically
just
sdf
and
not
really
one
data
model,
so
we
probably
need
to
look
at
where
the
center
of
the
collaboration
really
needs
to
be
for
some
of
these
things,
so
textile
might
and
electronic
data
sheets
might
be
more
1dm,
but
sc41,
and
this
might
be
more,
you
know
sdf
and
basically
we
want
to
get
the
convergence
process
going
and
start
working
on
parallel
tracks
where
we
can
separate
the
dependencies
between
groups
of
models,
as
some
group
of
people
want
to
be
interested
in
pushing
one
set
of
models
forward.
E
Another
group,
you
know
vertically
vertical
groups,
maybe
somebody
working
on
lighting,
someone
else
working
on
appliances,
someone
else
working
on
energy
and
we
want
to
get
a
two-week
cycle
going
between
work
and
questions
coming
up
and
then
broader
review
and
the
broader
process.
So
on
to
the
next
slide.
Please.
E
Yeah,
so
the
super
I'm
not
going
to
talk
through
all
of
this,
but
basically
this
shows
that
we
we
have
existing
models.
We
have
new
models
that
are
going
to
be
created,
and
then
we
have
models
that
are
going
to
be
sort
of
alloys
or
amalgams
of
existing
models
and
and
those
all
kind
of
start
off
differently,
but
end
up
consolidating
down
to
the
same
adoption
process
next
slide.
Please.
E
And
which,
which
I'm
not
going
to
talk
through
this
either,
but
essentially
models
go
into
a
thing.
We
call
the
playground
where
this
this
alloying
and
this
annealing
and
working
off
the
rough
edges
and
convergence
takes
place.
E
Then
they
go
through
a
review
cycle
which
they
can
get
but
kick
back
from
our
work
or
they
can
go
on
forward
to
a
sort
of
a
last
call
and
a
model
adoption
process
where
they
get
published
in
our
official
adoption
repo
and
we're
basically
just
on
the
leading
edge
of
that
we
have
stuff
in
the
playground
and
we're
we're
just
about
to
as
soon
as
all
the
all
the
plug,
fest
and
hackathons
and
meetings
are
over,
we'll
select
a
set
of
modding
models
out
of
the
playground
and
work
toward
convergence,
and
I
think
we
have
a
couple
of
different
verticals
already
selected
to
work
on
there.
E
E
I
don't
know
exactly
how
it
works,
but
since
it's
on
github,
all
we
really
need
to
do
is
share
the
ci
and-
and
we
can
scale
to
what
we
want-
they
don't
all
have
to
be
in
our
organization,
but
right
now
we're
thinking
they
will
be
in
the
same
1dm
org
just
for
the
sake
of
collaboration,
but
the
contributors
will
be
able
to
sort
of
manage
their
own
name
space
while
they're
preparing
for
contribution
and
then
there's
also
some
repo
exploratory
repositories
for
testing
new
features
with
one
repo
now
to
look
at
the
mappings
and
extensions,
and
things
like
that
that
we're
doing
and
play
those
out
without
without
introducing
too
many
ci
issues
into
the
playground.
E
So
I
think
I
have
one
more
slide.
E
No
references
so
basically
go.
Look.
We
have
some
stuff,
you
can
poke
out
at
1dm
and,
of
course,
sdf.
That
folks
already
hear
all
know
about
already.
Thank
you.
A
B
Do
you
have
any
idea
what
your
time
frames
are
for
like
getting
this
these
drafts
stabilized
and
finalized?
I
was
in
the
meeting
earlier
this
today
and
I
know
there's
some
new.
Some
final
pr's
are
being
discussed.
A
B
B
Right
so
now,
you're
in,
like
looking
for
new
features
to
to
consider,
I
guess
round,
yeah.
A
I'm
not
really
looking
for
new
features.
We
know
a
lot
of
new
features
that
we
should
be
considering,
so
that
was
actually
more
than
half
of
the
meeting
this
morning,
where
we
looked
at
what
we
already
know,
what
needs
to
be
part
of
one
dot
next.
B
A
E
Basically,
they
they
were
strong
enough
desire
to
converge
across
industry
that
they
they
worked
on
one
dm
for
a
while
and
then
sort
of
I
I
would
say
it
was
part
of
them
being
able
to
find
each
other
to
go
to
zigbee
org
and
decide
to
to
go
straight
to
implementation
of
of
the
chip
standard
as
a
way
to
fulfill
their
commercial
interests.
E
But
one
dm
is
the
more
long-term
focus
of
converging
the
models
and
there's
still
a
desire
from
zigbee
to
do
that,
although
they're
now
very
busy
with
chip
and
they
need
to
get
chip
out
the
door
before
they're
going
to
have
significant.
But
the
good
news
is
the
models
from
chip
to
zigbee,
aren't
really
that
much
different
there'll
be
some
new
ones.
Of
course,
since
there
are
new
new
players,
ip
bliss,
we
and
other
other
organizations
like
that.
E
I
think
we
have
had
some
contact,
I'm
to
the
extent
that
the
mission
that
our
mission
and
theirs
align
there
was
there
was
some
interest,
but
I'm
not
sure
what
going
forward
is
going
to
be,
and
I'm
not
sure
if
wowder
is
on
the
on
the
call
he
might
be
able
to
say
more.
But
I
don't
see
wilder
water
vendor
vanderbik
is
our
contact
with.
A
Iplus,
thank
you,
michael.
That
was
interesting,
so
questions
more
questions
for.
A
Okay
with
that,
thank
you,
michael,
and
we
are
moving
to
the
next
presentation
again,
michael
richardson,
you
heard
already
have
the
screen
ready
and
I
have
to
press
a
few
buttons
to
make
that
happen.
F
Good
hi,
so
I'm
just
here
to
talk
about
this
document,
which
has
been
suggested
to
become
a
taxonomy
of.
I
should
put
the
document
title
in
there.
I'm
sorry
of
I
idev
id
issues,
so
this
was
first
presented
last
summer
at
sec
dispatch
with
a
kind
of
like
I
don't
know
where
to
send
this.
What
to
do
with
it
and
carson
suggested
that
tdt
rg
would
be
a
good
place
to
do
this,
and
so
now
I'm
talking
to
you.
So
this
is
about
roots
of
trust
and
trust.
F
F
Computing
space
is
actually
usually
something
that
you
sign
your
data
with,
so
it's
in
fact,
some
kind
of
a
private
key,
that's
embedded
in
a
device,
that's
used
in
some
cases
for
attestation
and
that's
why
it's
called
the
root
where
you
start
with,
whereas
trust
anchors
are
public
keys
that
you
embed
into
the
device
that
allow
you
to
verify
things
that
other
things
people
say
and,
as
I
said,
if
you
go
into
the
pki
community
and
start
talking
about
roots
of
trust,
they
assume
you
mean
trust
anchors
and
that's
often
not
the
case
though.
F
But
what
we're
really
talking
about
is
that
in
both
cases,
what's
what's
important
at
the
very
bottom
of
the
process
and
there's
this
allusions
to
its
turtles
all
the
way
down-
and
the
answer
is
well.
No,
it
can't
be
somewhere's
at
the
bottom
is
a
is
a
turtle
that
anchors
it
all
and
that
fundamentally,
is
a
private
key,
whether
it's
in
the
device
or
if
it's
in
a
manufacturing,
plant
or
infrastructure,
and
one
of
the
things
that
I've
noticed
is
that
when
peop,
we
have
conversations
about
security
considerations
around
other
documents.
F
One
of
the
questions
is
well:
what's
the
incentive
to
keep
some
of
this
private
key
private
and
who's
going
to
attack
what
and
how
can
I
really
trust
it?
And
what
about
this
manufacturer?
Who
didn't
do
things
right
and
and
that's
kind
of
a
slippery
slope
of
just
kind
of
disastrous
things
in
a
document,
because
it's
essentially
asking
layer,
9
or
financial
and
type
questions
about
a
technical
document,
and
we
don't
really
have
a
good
way
of
answering
it.
So
this
is
an
attempt
to
kind
of
qualitatively
answer
it
on
there.
F
So
this
is
what
the
document's
about
it's
about
the
quality
of
these
turtles.
How
secure
are
they
who
who
owns
them?
Who
controls
them?
How
are
they
created
and
how
are
they
provisioning
and
one
of
the
things
that
you
kind
of
have
to
realize
when
I
come
back
to
this
at
the
end?
Is
that
if
you
can
change
the
software,
then
of
course
you
can
change
what
keys
it
thinks
does
what
and
so
in
some
sense,
the
ultimate
trust
anchor
is
the
one
that
defines
what
software
you're
able
to
run.
F
So
one
of
the
first
first
questions
is
about
the
roots
of
trust.
So
this
fundamentally
is
an
idev
id.
If
you
want
it's
not
always,
but
it
usually
is,
and
the
question
is,
how
do
you
get
it
into
the
device?
So
this
means
a
key
pair
private
key
pair
that
needs
to
be
kept
in
the
device
and
how
was
it
produced?
How
was
this
associated
probably
certificate
created?
F
What
resistance
do
we
have
against
devices
which
are
being
signed
with
the
keys
that
that
is
inappropriate
devices
are
being
signed
and
what's
the
opposite,
where
devices
that
you
don't
know
have
been
compromised
and
they're
they're
still
said
to
be
good,
and
one
of
the
big
problems
with
this
is
that
when
you
go
through
the
supply
chain
processes,
there's
usually
two
some
three
layers
of
ndas
involved
and
just
mentioned
before.
F
I
continue
that
some
of
these
roots
of
trust,
some
of
these
things
are,
in
some
cases,
symmetric
keys,
but
usually
there's
another
layer
of
in
the
supply
chain.
That
turns
that
into
a
asymmetric
key,
but
you
won't
find
that
out
unless
you
signed
all
the
ndas
and
know
what's
going
on
so
the
goal
of
this
document
is
to
ideally
to
have
some
kind
of
a
thing
that
says:
well,
you've
done
the
following
thing
and
I
don't
really
care
if
you
got
a
certificate
from
some
government
body.
F
That
said
you
did
the
right
thing
or
you
have
the
cheetos
level
of
security
here,
because
what
I
care
is
that
you're
able
to
distinguish
those
two
and
that
you
have
can
say
I
point
to
the
top
one
or
you
point
to
the
bottom
one
and
for
some
devices
you
know
what
that
cheetos
might
be.
Actually
all
the
security
you
actually
needed
on
your
bike
shed.
That
may
be
enough.
F
So
the
document
has
a
outline
and
it
deals
with
different
types
of
identities,
and
it
deals
with
a
series
of
evaluation
questions
that
I'm
suggesting
that
I
would
like
to
be
answerable
by
things,
I'm
not
proposing
to
answer
them
for
any
specific
case
and
I'm
actually
not
proposing
to
even
to
say
what
are
good
values
and
what
are
bad
values.
F
But
here
is
a
value
and
we
agree
what
the
definition
of
that
value
is
there,
so
sec
dispatch
said,
go
out
and
ask
industry
people
outside
the
ietf
what's
going
on
and
I've
presented
it
four
or
five
other
conferences
or
groups
in
this
and
about
four
other
one-on-one
conferences
with
various
suppliers,
and
I'm
bugging
them
regularly.
To
give
me
some
kind
of
replies
everyone's
really
interested,
but
it's
not
a
high
priority.
F
So
unfortunately,
I
don't
have
a
lot
of
feedback
for
that,
but
it
is
the
goal
to
get
that
through
through
some
kind
of
a
process.
This
way-
and
I
would
certainly
like
your
help
in
that
so
some
of
the
things
that
are
described
in
this
document
is
the
structure
of
a
pki.
F
One
of
the
questions
is,
for
instance,
is
this
level
zero
or
level
one,
and
the
conclusion
is
that
if
you
just
had
this
pki
and
you
just
had
a
self-signed
certificate
that
you
actually
have
a
pki
of
level
with
a
depth
of
one
not
of
depth
zero.
The
second
question
is
the
second
level
of
pkis.
Is
that
an
intermediate
pca
or
is
it
a
subordinate
ca?
F
F
If
you
want
to
see
what
an
intermediate
ca
looks
like
then
follow
this
link
and
you
have
to
go
and
play
with
some
of
the
zoom
in
and
out
and
and
clicking
on
some
of
the
things,
and
you
will
see
the
immense
complexity
which
has
been
created
in
the
u.s
federal
bridge
ca
system
through
a
number
of
intermediate
cas
and
those
are
quite
clearly
documented
in
quite
a
number
of
documents
as
intermediate
cas,
and
so
I'm
going
to
avoid
that
term,
and
I
suggest
you
to
do
and
anyway,
subordinate
just
sounds
so
cool,
I
think,
is
a
term,
and
so
it
deals
with
also
recovery
and
resilience
and
and
how
are
the
private
keys
generated
and
how
are
they
kept
safe
is
an
important
discussion
that
I
think
you
need
to
that
need
to
that's,
usually
what
we
want
to
be
able
to
talk
about
in
the
end.
F
F
Well,
those
those
private
keys.
They
remain
in
your
factory
and
the
top
level.
Probably
if
you
can
afford
it
and
your
smart
probably
goes
into
some
kind
of
a
hardware-
security
module,
that's
an
hsm,
but
they
are
expensive
and
it's
not
always
clear
to
me
that
they
have
a
specific
value
and
sometimes
they're
more
of
a
hassle
as
well.
One
of
the
things
you
may
be
interested
is
to.
F
Sorry
I
have
to
I
have
to
close
my
gather
town,
because
it's
talking
to
me
for
some
reason
there
we
go
so
the
the
issue
is,
if
you,
for
instance,
looked
at
what
the
root
dns
people
had
to
do
last
summer
to
essentially
deal
with
the
fact
that
they
actually
couldn't
have
a
key
ceremony
due
to
the
pandemic,
and
so
at
one
point
they
under
supervision
drilled
their
some
of
the
data
out
of
there
out
of
their
safe,
to
be
able
to
continue
and
sort
of,
I
sort
of
had
to
say
what
was
the
point
of
having
a
safe.
F
If
we
could
just
drill,
we
could
just
be
allowed
to
drill
it
out,
and
I
guess
the
answer
is
that
we
knew
that
they
were
doing
it.
So
you
have
this
crop
this
quandary.
On
the
one
hand,
you
would
be
a
good
idea
to
divide
your
private
information
into
more
pieces
and
have
it
more
resiliently
available,
maybe
on
different
continents,
so
that
you
can
continue
to
deal
things
and
deal
with
maybe
pandemic
issues
to
travel.
F
On
the
other
hand,
if
you
have
more
pieces,
then
there's
more
likelihood
that
some
smaller
conspiracy
of
people
could
continue
to
do
something
else
or
the
fewer
number
of
people.
You
need
to
need
to
be
the
more
number
of
people
that
need
to
be
resilient
to
corruption,
bribery
or
extortion,
and
if
it's
value
due
to
them
again,
the
point
is
not
to
say
what
is
better
and
worse
but
to
understand
what
are
the
risks.
F
So,
if
you're
buying
national
id
cards
as
taiwan
did
a
decade
20
years
ago,
you
probably
want
to
know
that
they
have
good
cryptographic
content
and
that
they
can't
be
easily
forged,
and
if
they
can,
then
at
least
you
as
the
national
agency,
hold
all
the
cards
making
that
happen.
I
mentioned
them
specifically
because
it
turned
out
that
they
had
issues
with
their
private
keys
were
not
as
random
as
they
thought
they
were,
and
there's
a
paper
out
there
that
you
can
read
it's
quite
astonishing.
F
So
this
is
the
question:
how
are
you
going
to
describe
this
thing?
How
are
you
going
to
describe
this
this
level?
Is
this
something
that
you
actually
want
to
describe
as
part
of
this
there,
but
as
an
end
user,
you'd
kind
of
like
to
know
what
are
the
risks
to
the
supply
chain?
Maybe
not
for
your
home
webcam?
Maybe
that
you
think
you
don't
mat,
it
doesn't
matter
to
you,
but
maybe
you
really
do
care
about
the
pieces
that
go
into
your
autonomous
vehicle,
for
instance.
F
So,
as
I
described
before,
a
great
number
of
this
is
hidden
behind
non-disclosure
agreements
and
you
don't
really
know
what's
what
and
who's
woo
and
they
don't
aren't
likely
to
get
behind
that.
So
that's
the
goal
is
not
to
kind
of
to
break
that
open.
I'm
not
trying
to
say,
okay,
tell
us
all
your
secrets
tell
us
what's
going
on,
but
rather
that
when
you
hire
an
auditor
or
the
company
has
provided
you
with
audited
resort
results
that
you
can
actually
read.
F
The
audit
results
in
an
intelligent
way,
and
this
has
kind
of
input
into
the
rest
of
our
our
security
considerations.
Other
documents
where
you
may
actually
have
to
say
well.
This
is
the
kind
of
thing
that
I
would
expect
this
level
of
security.
There
and
you
could
go
and
go
and
find
out
if
that
actually
happened.
F
And
finally,
I
just
come
back
to
one
of
the
last
little
things
that
I
started
with.
Is
that
pretty
much
you
should
realize
that
every
device
out
there
is
going
to
be
determined
by
what
software
it
runs
and
whoever
determines
what
software
it
runs,
probably
determines
what
the
authorizations
that
are
that
are
associated
with
a
particular
set
of
trust
anchors.
So
that's
the
public
keys
that
you
built
into
your
device.
F
So
if
you
can
change
that
software,
then
you
pretty
much
win
and
I
think
this
is
actually
one
of
the
places
where,
if
we
were
to
go
through
a
number
of
of
audits
and
things
we
would,
we
would
actually
be
kind
of
surprised
that
some
of
the
software
signing
keys
are
really
not
as
as
well
secured
as
we
thought,
and
there
was
recently
an
issue
with
a
microsoft
windows,
active
directory
management,
a
third-party
tool.
I
believe
which
had
this
problem.
F
It
turned
out
that
there
there
were
possibly
access
to
that
code,
signing
key
elsewhere.
It's
unclear
from
the
press
release.
But
the
point
is
that
if
you've
got
a
thing-
and
you
have
this
gone
through
this
process
of
trying
to
make
it
secure
and
then
you
hand
out
your
signing
key
to
anyone
that
asks
then
maybe
that's
a
problem
and
maybe
some
of
the
process
that
you
need
on
top
of
that.
But
whatever
the
case,
my
goal
is
simply
to
be
able
to
to
track
in
a
qualitative
way.
F
C
Point
from
there
to
my
client
thanks,
michael,
it's
very,
very
interesting
piece
of
work
and
one
thing
that
occurred
to
me.
I
think
there's
quite
a
lot
of
similarities
on
the
work.
Milan
is
doing
kind
of
from
the
iot
protocol
side,
you're
kind
of
doing
the
security
side
establishing
terminals
and
ways
to
describe
things
in
a
uniform
way.
So
you
can
actually
understand
what
is
there
inside?
C
F
Let's
just
fit
into
sdf
is
that
what
you're
asking
in
some
level?
I'm
sorry
that
would
be
an
interesting
way.
I
mean,
as
my
goal
was
not
to
make
this
machine
readable
but
human,
understandable,
but
at
some
point
in
the
supply
chain
space
you
actually
do
need
to
make
this
machine
readable
because
you
get
a
num.
F
The
number
of
parts
that
you
get
and
the
changes
to
those
parts
are
the
security
properties
behind
those
parts
needs
to
be
needs
to
go
through
a
supply
chain,
but
I
wouldn't
want
to
try
to
write
it
down
before
we.
Actually,
you
know
in
a
machine,
readable
format
until
we
had
enough
examples
to
make
sense
of
it.
1Dm
had
you
I've,
I'm
just
amazed
that
you
guys
have
200
models
already
and
I
think
that's
really
valuable.
F
G
Sorry,
I'm
very
sorry,
so
my
question
is
about
slide.
Nine,
where
you
said.
I
don't
know
if
this
is
a
tauntology
and
I
don't
know
why
you
want
to
know
that.
So
I
think
it's
good
to
structure
things
kind
of
I
don't
know
hierarchically
and
then
this
is
like
a
subclass
3
in
a
taxonomy
and
that's
always
well,
that's
the
first
step
towards
ontology
modeling.
I
guess
with
more
narrower
and
broader
terms
and
and
maybe
that
helps
to
some
extent.
F
So
the
reason
I
said
I
don't
know
is
that
that
then
I
don't
know
if
there's
enough
structure
to
bother
at
this
point,
I'm
quite
happy
to
just
put
put
a
bunch
of
terms
in
a
bag
and
not
worry
about
how
they
relate
to
each
other
and
later
on.
If
the
like,
you
know,
literally,
that's
all
the
terms
that
I
have
in
in
this
thing
at
this
point
when
that
exceeds
three
pages
or
three
slides,
then
I
think
we're
probably
it's
time
to
structure
it
in
some
way.
F
But
I
know
if
you
look
through
the
document
there
are,
you
know,
parts
that
relate
to
trust,
anchors
and
parts
that
relate
to
private
keys,
but
that's
just
really
how
they
do
so.
I'm
not.
F
I
guess
part
of
the
point
is
that
I
don't
really
want
to
argue
about
how
what's
similar
to
what's
what
other
thing
I
just
really
want
to
get
the
terminology
down
in
a
way
that
I
can
reasonably
find
out
for
devices
that
I
own
or
parts
that
I
want
to
include
in
devices
that
I'm
building
how
they
are
managed
and
how
it
happens
right
and
and
that
some
of
these
questions
could
be
answered.
G
G
I
think
when
you
have
to
want
this
semantic
dependencies
like
I
need
the
location
and
a
key
is
in
there
and
and
it
can
be
private
and
it's
used
for
and
all
these
semantic
relationships
between
these
terms,
that
might
actually
become
an
interesting
thing
to
consume
for
other
stakeholders.
G
So
I
would
keep
that
in
mind
and
and
just
as
a
first
question,
so
to
speak
at
the
very
beginning
you
were
talking
about
and
I
think
it's
excellent
to
bring
that
up
to
confuse
what
actually
well-defined
things
like
root
of
trust
and
trust,
anchor
and
and
looking
at
the
document,
I
think
you're,
not
opening
that
kind
of
worms
there
right
you're,
not.
F
Introducing
these
two
categories,
there's
two
categories
of
things
that
we
need
to
discuss
right,
but
there's
there's
the
private
keys
that
are
in
your
devices,
which
turn
out
to
be
your
roots
of
trust,
okay,
but
then
there's
the
private
keys,
which
are
in
your
factories,
which
are
which
are
are
not
the
same
thing,
but
they
lead
to
the
trust
anchors
that
are
in
your
devices.
F
So
both
cases,
though
the
discussion
of
how
is
the
private
key
protected
and
who
had
access
to
it
and
how
is
it
generated?
Well,
that's
that
actually
applies
to
both
just
the
types
of
the
answers
you
get
are
different
right,
like
the
number,
how
how
many
people
have
access
to
the
private
key
in
the
device.
I
hope
is
zero.
How
many
people
have
access
to
the
private
key
in
the
hsm?
F
G
Yeah,
okay,
so
so
maybe
it
is
worth
at
least
considering
opening
that
kind
of
worms
and
actually
pull
in
the
term
root
of
trust
into
your
document.
But
I'm
not
sure
if
that's
useful,
so
just
just
as
a
food
for
thought.
F
F
G
Think
that's
another
big
big
big
big
discrepancy
for
the
world,
but
I'm
really
like
this
is
the
flood
of
cars.
Now
so.
A
No,
I
would
also
not
try
that
there
is
a
reason
that
sdf
is
not
a
yang
model,
but
that's
that
wasn't
the
point
I
was
going
to
make.
So
the
reason
why
I
think
it's
really
worth
thinking
about
modeling.
A
What
software
am
I
trusting
when
I
allow
this
thing
into
my
my
network
and
I
think
that,
having
a
way
to
document,
what
are
the
the
trust
relationships
to
entities
that
that
do
things
like
like
certify
key
pairs
and
and
the
the
trust
anchors
out
there
and
so
on?
A
That
may
be
a
useful
thing.
So
so,
after
a
solar
wind
thing
or
a
microsoft
exchange
thing,
I
I
can
look
into
my
network
and
find
out
in
a
limited
amount
of
time
who
is
actually
impacted
by
this
and
which
part
of
my
factory
do.
I
have
to
shut
down
because
I
no
longer
have
control
over
it
and
that's
why
I
think
modeling
these
security
relationships
is
really
so
important.
F
Yeah,
so
I
like
I,
I
I'd
like
to
have
a
conversation
on
the
list.
I
guess
about
what
level
of
modeling
you
think
is
appropriate
and
and
how
you
know,
because
what
I'm
hearing
is
that
we
would
like
to
be
able
to
point
to
particular
profiles
of
this
model
that
would
be
asserted
by
a
manufacturer.
We
are
following
this
model,
blah
blah
blah
and
a
coastwood
wants
to
be
able
to
point
at
or
some
other
an
spdx
or
something
wants
to
be
able
to
po
point
at
this,
but
yeah.
F
Also
applies
to
to
you
know
the
the
who
signed
the
firmware
in
your
keyboard
right
in
the
microcontroller
of
your
keyboard.
Right
so,
and
did
they
even
think
that
was
an
important
key
to
keep
private,
but.
A
Yeah
so
there's
a
whole
area
of
work
waiting
for
us
bringing
all
these
various
models:
sdf
yang,
the
mud,
various
pieces
of
mud
information-
that's
out
there
there
and
so
on
together.
So
we
can
do
useful
inferences
from
that
information
at
the
security
layer.
F
Well,
I
would
propose
that
we
flush
out
some
more
bits
in
this
document
that
we
think
about
what
other
other
questions
like
the.
How
do
I
explain
the
k
of
n
for
recovery
process
there
that
that
we
publish
an
initial
document
and
then
we
come
back
and
discuss
well?
How
do
we
arrange
this
into
a
model
that
we
can
do
this?
Other
other?
F
You
know
do
things
that
are
machine
readable,
but
I
really
think
that
that
the
ideal
thing
is
that
we
were
able
to
talk
to
people
and
say
you
know:
can
you
describe
it
in
this
using
this
terminology
and
then
and
then
we
can
use
those
examples
to
encode
our
examples
or
use
cases
for
the
second
thing
aaron,
you
had
no,
no.
A
I
wasn't
suggesting
that
that
all
the
that
big
area
I
talked
about
needs
to
be
covered
by
this
document.
I
think
that
you
have
chosen
a
really
interesting
angle
to
to
make
a
crack
into
that
area
and
that
that's
why
I
think
it's
it's
a
very
useful
document
to
look
at,
but
I
also
would
like
us
to
think
about
the
larger
area
and
see
what
other
components
can
can
we
actually
work
on
to
to
make
that
vision
of
finding
out
what's
going
on
in
my
network
actually
happen
at
some
point.
F
Okay,
thank
you.
I'm
gonna
start
a
couple
more
threads
on
the
list,
but
thank
you
for
the
discussion.
Yeah.
A
I
A
Thank
you.
We
have
used
up
10
minutes
of
our
20
minutes
of
flex
time
and
with
that
the
next
talk
is
the
iot
edge
challenges
and
functions.
So
yeah,
do
you
want
to
present
or
do
you
want
me
or
you
want
to
present?
So
I
just
press
here.
A
Oh,
while
we
are
waiting
for
that
to
come
up,
I
have
a
little
poll
for
you.
So
can
can
you
press
the
sixth
button
on
top
of
your
screen,
the
one
that
has
turned,
yellow
and
answer
the
question
there.
A
A
Okay,
so
about
half
of
the
participants
has
answered
now,
and
so
we
have
a
gauge,
and
I
hope
this
discussion
has
motivated
you,
the
ones
who
did
not
raise
them
to
actually
locate
it.
Thank
you
so
on
to
savvy.
H
Thank
you
yeah.
So
I'd
like
to
yeah
present
recent
updates
on
the
draft
iot
edge
computing.
H
H
Two
so
mary,
jose
and
carlos
and
in
this
presentation.
So
thank
you
for
the
reviews
and
the
in
this
presentation.
I
will
summarize
the
update
and
discuss
the
next
steps.
H
H
We
also
added
text
in
the
introduction
about
our
focus
on
research
topics
rather
than
industry
projects,
so
we
still
have
like
a
section
4.1
that
represents
the
current
state
of
iot
computing
in
industry,
but
it
does
not
dive
into
individual
projects
and
doesn't
list
them
we're
just
trying
to
provide
a
high
level
view
right
and
we
spend
most
of
the
rest
of
the
section,
for
example,
to
speaking
about
individual
research
challenges.
So
it's
more
focused
on
this
on
this
side
of
things.
H
Other
comments
on
the
specific
text
were
addressed
as
well,
so
we
had
an
update
on
the
description
of
an
in-network
computation,
which
was
a
bit
too
narrow,
and
we
also
added
data
discovery
as
a
research
challenge,
and
we
did
quite
a
you
know.
A
few
editorial
changes
as
well.
H
Right
so
since
so
you
know
in
the
next
and
last
slide,
we
will
ask
people
who
are
interested
to
provide
some
feedback,
so
I'd
like
to
give
you
know
a
quick
overview
of
the
document
and
to
highlight
what
was
updated
most
recently.
So,
of
course,
we
welcome
comments
on
any
part
of
the
document
on
the
structure
on
anything
you
you
think
is
worth
it.
However,
you
know
the
the
parts
that
are
highlighted
here
will
benefit
from
you
know,
most
from
reviews
right.
So
beyond
the
introduction.
H
In
section
2,
we
have
a
quite
mature
text
with
a
high
level
descriptions
of
iot
cloud
computing
edge
computing
and
we
have
a
few
new
use
cases.
Section
3
is
quite
stable.
I
think
you
know
it
lists
reasons
that
motivate
the
use
of
edge
computing
for
iot.
It
has
been
reviewed
a
couple
of
times.
It
has
been
discussed
in
t2
trg
even
before
starting
this
draft,
you
know
by
some
co-authors,
so
it
should
be
relatively
stable
at
least
and
section
4
has
more
recent
text,
so
the
the
overview
part
we
already
discussed
that
earlier.
H
It's
it
covers
a
very
dynamic
field,
so
people
who
are
involved
in
this
domain
or
are
interested
in
some
part
of
this
domain
may
have
like
good
input
here
to
maybe
update
some
parts
or
improve
the
text
there
and
following
that
we
have
a
model
which
is
very,
very
general,
so
in
its
we
think
it
needs
to
be
general
to
cover.
You
know
very
different
system
designs
in
this
in
this
field.
H
However,
you
know,
for
example,
one
possibility
would
be
if
you
are
aware
of
some
models
for
iot-h
computing,
which
could
be
it
could
bring
some
additional
value.
You
know
we
could
point
towards
them
or
you
know,
could
improve
the
model
in
some
way.
H
Then
we
have
one
section
per
function
or
component
and
each
section
has
a
description
text
and
a
list
of
research
challenges.
So
this
part
is
relatively
recent
and
it
would
benefit
from
really
more
reviews.
You
know
feel
free
to
propose
new
research
areas
in
there
or
new
functions
that
we
may
have
missed,
or
we
can.
E
H
H
The
draft
is
in
the
stable
state
and
you
know
we,
you
know
it's
ready
to
be
reviewed
as
a
group
draft,
so
please
feel
free
to
provide
feedback.
You
know
if
you
are
interested
on
the
mailing
list.
Even
you
know,
if
you
don't
have
a
lot
of
time,
I
mean
you
know.
This
document
is
not
very
long,
it's
still
20
pages,
but
if
you
want
to
focus
really
on
some
parts
of
interest,
you
can
just
do
that
and
you
know.
H
Finally,
we
also
had
a
discussion
among
co-authors
and
group
chairs
about
reaching
out
to
a
wider
group
of
reviewers,
so
either
you
know
in
parallel
with
the
reviews
in
t2,
trg
or
maybe
later
I
don't
know.
H
A
first
possibility
is
to
reach
out
to
irtf
groups,
so
related
groups
will
include,
for
example,
core
energy
and
energy
for
some
aspects,
and
a
second
possibility
is
to
reach
out
to
participants
in
external
industry
forums.
You
know
through
personal
contacts,
you
know,
for
example,
you
know
in
cmx
you
know
some
some.
There
is
some
sub
group
looking
at
iot
api,
so
we
could
do
that,
for
example.
H
We
so
any
you
know,
feedback
on
this
or
anything
would
be
a
welcome.
So
thank
you
for
your
time
and
that's
it,
for
the
presentation
is
complete.
Thank
you.
A
Okay,
one
of
the
advantages
of
the
physical
situation
in
the
room.
That
is
that
when
you
do
a
show
of
hands
you
actually
can
see
who
is
showing
dance
and,
unfortunately,
with
a
poll
I
can't,
but
there
are
seven
hands
up
right
now,
which
I
think
is
is
approximately
the
amount
of
review
we
we
need
to
get
this
completed.
So
if
people
plus
could
please
remember
that
they
raised
their
hand
here
and
actually
provide
some
form
of
review,
some
form
of
comments
that
that
would
be
great.
So
we
can
advance
this
document.
A
So
this
summary
is
six
people
think
they
won't
provide
comments.
Seven
people
think
they
will
and
everybody
else
is
still
making
up
their
mind.
H
A
Yeah,
so
the
idea
is,
is
not
so
much
that
you
put
an
item
on
your
calendar
that
you
do
a
full
review
of
the
document.
That's
also
great,
but
it's
it's
also
useful
to
to
simply
look
at
an
area
of
the
document
where
you
maybe
have
some
some
previous
experience
with
and
and
can
send
some
comments
to
the
mailing
list.
A
J
J
Great
hi,
can
you
hear
me?
Yes,
thank
you
excellent.
So
I
just
finished
to
check
this
dispatch
and
joined
now.
Sorry
that
I
was
in
two
places,
so
yeah
I'll
be
presenting
our
draft
on
secure,
iot
bootstrapping.
We
started
this
as
a
survey
and
I'm
mohit.
This
was
work
done
together
with
my
co-authors,
bechet
and
dan
and
various
other
contributors.
J
So
just
to
recap,
this
draft
was
well
exactly
like
five
years
ago
version
zero
zero
was
submitted,
so
in
march
2016.
This
has
been
around
for
a
while
and
obviously
has
been
undergoing
changes
since
the
beginning.
So
we
have
added
definitions.
You
know,
classifications
and,
and
the
new
part
added
in
the
last
year
has
been
the
bootstrapping
terminology.
So
a
lot
of
the
contents
were
written
even
before
many
of
the
protocols
that
are
being
developed
now
existed
so
I'll
be
presenting
version
11
11
of
the
draft
today.
J
So
one
thing
we
wanted
to
cover
in
this
draft
is
that
there's
various
terminology
that
is
kind
of
interrelated
and
is
used
a
little
bit
freely,
although
we
are
not
sure
we
completely
understand
the
relationship
between
the
different
terminologies
and
how
different
standards
bodies
are
are
using
those
terms.
So
one
of
the
goals
of
this
draft
was
to
find
the
terminology
and
then
also
try
to
document
what
are
the
terminologies
used
by
the
different
sdos,
including
ietf,
but
also
outside
the
itf.
J
So
we
have
bootstrapping
provisioning,
onboarding,
enrollment,
commissioning,
initialization
configuration
registration
and
discovery
and
in
the
next
few,
slides
I'll
just
be
going
through
some
of
the
example
protocols
or
systems
and
what
kind
of
terms
they
are
using.
So
the
first
one
I
have
on
the
list
is
dpp.
Hopefully
some
of
you
know
wi-fi
alliance
device
provisioning
protocol.
J
I
saw
dan
as
one
of
the
attendees
so
he's
I
guess
one
of
the
main
authors
of
dpp,
hopefully
dan.
You
can
correct
me
if
I
have
not
written
the
summary
correctly,
but
dpp,
at
least
in
the
spec
has
the
following
three
sub
protocols
or
phases.
The
first
is
bootstrapping,
where
basically,
you
obtain
the
public
key
of
the
other
party,
so
this
can
be
through
scanning
a
qr
code
or
tapping
nfc
or
some
other
form
of
out
of
band
communication.
J
Once
you
have
done
that,
you
can
do
authentication
so
there's
at
least
authentication
of
the
responder
to
the
initiator,
but
optionally.
There
is
also
mutual
authentication.
So
if
you
have
scanned
qr
codes
in
both
directions,
then
you
can
get
mutual
authentication
there's
a
couple
of
different
terms
used
in
this
in
the
spec,
so
there's
the
in
in
row,
configurator,
enrollee
and
roller
and
there's
the
initiator
and
responder.
But
I
guess
the
important
ones
are
here:
colored,
so
there's
the
bootstrapping
authentication
and
then
the
configuration
so
once
the
parties
are
authenticated.
J
Then
the
draft
also
covers
omar
lightweight
m2m,
so
oma's
design
is
basically
a
new
device
contacts,
a
bootstrap
server
which
is
responsible
for
provisioning
information
such
as
credentials,
and
once
the
device
receives
these
credentials
and
information,
it
then
registers
itself
to
one
of
the
lightweight
m2m
servers,
which
will
then
manage
the
device
during
its
life
cycle.
J
The
specification
defines
four
different
ways
of
bootstrapping.
You
have
factory
bootstrap
where,
like
the
credentials,
are
already
pre-provisioned
into
the
device
at
the
time
of
manufacturer.
In
that
case,
the
device
doesn't
really
need
a
bootstrap
server.
It
can
directly
contact
the
lightweight
m2m
server.
Then
there
is
options
of
bootstrapping
through
a
smart
card.
There
is
client
initiative,
bootstrap
and
server
initiated
bootstrap
in
the
draft.
I
also
or
we
have
also
written
about
ocf,
but
I
thought
for
brevity
in
the
presentation
I'm
not
presenting
the
terminology
used
by
ocf
here.
J
Instead,
I
thought
it
might
be
interesting
to
cover
what
fido
is
doing
so.
Fido
alliance
has
auto
automatic
onboarding
protocol
and
is
using
lots
of
ietf
specifications
like
eat
and
seaborg,
so,
basically
they're
they're.
J
What
fedo
is
trying
to
do
is
provide
the
iot
device
with
sufficient
information
so
that
it
can
interact
with
an
online
cloud
platform
typically
hosted
in
in
a
cloud
so
think
of
some
amazon
or
azure
platform,
but
my
understanding
at
least
of
reading.
The
specification
is
that
the
problem
of
network
connectivity
is
not
really
solved
by
the
protocol
and
the
protocol
assumes
that
the
device
has
already
joined
the
network.
J
Joining
the
network
doesn't
necessarily
mean
that
it
has
joined
the
internet,
but
at
least
it
has
some
network
connectivity.
One
of
the
features
that
fido
alliance
claims
to
bring
to
the
table
is
late
binding.
So
basically,
the
concept
here
is
that
owners
can
choose.
Owners
of
iot
devices
can
choose
the
platform
to
which
their
device
would
connect
to
at
quite
a
late
stage
in
in
the
device
life
cycle.
J
The
protocol
is
again,
as
as
you
can
expect,
is
composed
of
of
sever
several
sub
protocols.
So
there's
the
device
initialization
protocol,
which
is
executed
in
the
factory
and
here
the
initial
ownership
and
manufacturing
credentials,
are
placed
typically
in
a
secure
storage
like
a
tpm,
then
you
have
transfer
of
ownership
protocols
and
there
are
three
of
them.
J
So
here
they
are
written
as
to0,
1
and
2,
and
these
protocols
occur
between
the
device,
a
rendezvous
server
and
an
owner
onboarding
service,
and
the
whole
idea
is
that
once
these
transfer
of
ownership
protocols
are
completed,
the
new
owner
of
iot
device
and
the
new
and
the
device
have
authenticated
each
other,
and
once
this
authentication
is
complete,
the
owner
can
obviously
provide
cryptographic,
information
and
urls
to
the
device
of
of
the
iot
platform
to
which
it
should
connect.
J
J
It's
a
profile
of
certificate
management
over
cms.
If
you're
wondering
what
is
cms,
it's
cryptographic
message,
syntax,
so
many
new
acronyms
to
learn
here.
But
the
idea
is
simple:
that
client
devices
can
obtain
client
certificates
and
associate
associated
ca
certificates,
and
originally
it
was
specified
with
interactions
over
http.
J
But
thanks
to
this
working
group,
there
is
now
a
companion
specification
that
defines
how
est
can
also
be
transported
over
co-op.
One
interesting
thing
in
rfc
7030
is:
it
allows
you
to
bootstrap
basically
devices
which
have
minimal
configuration.
So
if
you
have
no
credentials
on
the
device,
then
you
can
rely
on
the
human
user,
and
the
idea
here
is
that
the
human
user
can
verify
information
such
as
the
ca
certificate,
with
the
fingerprint
shown
over
an
authenticated
tls
channel.
J
So
you
can
set
up
an
authenticated,
tls
channel
and
show
the
user
that
this
is
the
ca
you
are
interacting
with.
Do
you
want
to
request
a
client
certificate
from
there
and
after
successful
bootstrapping,
you
can
proceed
with
enrollment,
there's
also
brewski,
so
bootstrapping
remotes
secure
key
infrastructure
which
uses
a221ar
vendor
certificates
on
the
device
and
the
device
performs
several
steps.
So
first
it
discovers
a
register.
J
J
And
finally,
we
have
satp
secure
zero
touch,
provisioning
and
the
rfc
8572
calls
it
a
bootstrapping
strategy
which
enables
a
device
to
obtain
bootstrapping
data
with
no
to
minimal
installer
action.
The
rfc
defines
several
ways
of
obtaining
this
bootstrap
data,
so
you
have
dns
dhcp,
removable
storage
or
from
a
bootstrap
server.
J
The
draft
also
uses
the
term
onboarding
server.
Oh
sorry,
I
should
not
call
it
a
draft,
it's
rfc,
so
the
rfc
also
uses
the
term
onboarding
server,
which
is
basically
a
bootstrap
server
that
returns
onboarding
information
there's
also
something
called
as
a
redirecting
server,
but
I
thought
that
was
not
so
important
to
cover
in
the
slides
here.
That
is
very
simple
that
if,
if
you
receive
some
information
that
is
untrusted,
then
either
it
has
to
be
signed
or
it
it
can
only
be
processed
provisionally.
J
J
Well,
at
least
our
understanding
is
that
there
are
several
stages
before
a
device
can
become
fully
operational,
and
this
typically
involves
establishing
some
initial
trust,
after
which
you
kind
of
provision
or
configure
the
device.
So,
for
example,
in
dpp
bootstrapping
is
the
first
step.
Then
there
is
authentication
and
then
you
provision
credentials
onto
the
device.
J
Obviously,
some
protocols
only
deal
with
parts
of
the
process,
whereas,
like
some
other
sdos
build
entire
systems
where
you
not
only
provision
credentials,
but
you
provision,
access,
control,
lists
and,
and
so
on.
So
omar,
for
example,
is
something
that
not
only
is
provisioning,
urls
and
credentials,
but
also
access,
control
lists
and
other
types
of
configuration
objects.
J
Please
join
the
queue.
I
can't.
I
can't
see
the
queue
but
feel
free
to
stop
me
at
any
point.
There
are
slight
numbers,
so
hopefully
you
can
always
take
me
back
to
some
slide.
If
you
have
have
questions
so
the
draft
doesn't
stop
here.
There's
after
all,
this
terminology
discussion
from
various
seos,
we
try
to
do
a
survey,
an
obvious
problem
with
with
writing
services
like
there's
tens,
if
not
hundreds
of
protocols
and
and
specifications
to
cover,
so
you
don't
try
to
cover
all
of
them,
but
rather
try
to
classify
them.
J
So
the
draft
currently
has
this
classification
technique,
where
we
classify
things
into
managed.
P2P
and
ad
hoc
leap
of
faith
and
opportunistic
protocols
as
well
as
hybrid
and
one
of
the
key
takeaways
is
that
obviously
categorization
is
not
always
easy
or
clear.
So
protocol
might
fall
in
some
version.
It
might
fall
in
one
category
and
in
another
version
it
might
fall
in
another
category,
but
at
least
it
gives
you
an
idea
of
trying
to
classify
different
protocols
in
in
different
categories.
J
This
is
our
last
slide,
so
obviously
this
draft
has
been
here
for
five
years
and
the
authors
think
that
it's
very
far
away
from
publication,
but
super
ready
for
adoption
and
one
question
is-
is
the
title
reflective
of
the
content,
because
now
it's
not
just
a
survey
of
bootstrapping
procos
but
also
bootstrapping
terminology,
and
it
goes
a
little
bit
beyond
that
and
tries
to
understand
the
relationship
between
the
bootstrapping
terminology.
K
Thank
you,
carsten
very,
very
interesting
talk
as
I
was
listening
to
this.
I
couldn't
help
wondering
whether
there's
been
any
thought
about
the
performance
implications
of
enrollment
and
onboarding,
and
whether,
if
people
have
thought
about
the
performance
requirements
with
for
these
for
different
kinds
of
devices,
I
could
see
a
scenario
where
a
device
fails
and
you
need
to
bring
a
replacement
on
very
quickly.
But
if
the
enrollment
time
is
an
hour,
that's
not
so
good.
J
Well,
at
least
this
draft
has
not
taken
any
position
on
any
of
those
aspects.
So,
as
from
my
slides,
it
was
evident.
Some
protocols
require
a
human.
So
if
you're
scanning
a
qr
code,
then
that's
a
different
user
experience,
then,
let's
say,
for
example,
zero
touch
provisioning
where
there
is
no
human
and
the
costs
of
failing
and
retrying
obviously
are
different,
whether
you
have
to
take
out
a
app
and
scan
again
or
whether
you
are
just
really
trying
on
the
network.
J
But
at
least
this
draft
has
not
gone
into
trying
to
distinguish
those
aspects
we
might
run
into
problems
in
in
trying
to
do
that,
especially
if
we
actually
like
run
prototypes
and
try
to
collect
actual
data
from
from
the
network.
I'm
not
saying
it
should
not
be
done.
It
would
be
pretty
interesting,
but
so
far
that
draft
has
not
not
done
that.
L
Aaron,
okay:
yeah.
Can
you
hear
me
now?
Yes,
yeah,
okay,
yeah,
very
nice
work,
so
I
have
been
actually
following
these
parts
for
a
while.
I
noticed
that
in
the
recent
versions
there
is
a
bluetooth
section,
you
added
there
in.
I
don't
know
since
the
version
6
or
somewhere,
but
then
it
has
been
there
for
a
while.
L
So
I
was
wondering,
since
you
want
to
bring
this
further,
it's
a
nice
work,
but
then,
at
which
point
you
would
like
to
say,
you
know
this
is
sort
of
like
you
know
the
somehow
phrases
settled
here
like
this
bluetooth
parts,
I'm
interested
into
what
you're
going
to
add
there,
but
then
yeah,
since
it
has
been
there
for
a
while.
What's
the
latest.
J
Just
I
guess,
lack
of
time
on
the
author,
so
I
have
materials
I
have
studied
bluetooth
mesh
and
our
how
the
provisioning
works
there.
It's
just
finding
the
time
to
write
it,
and
I
promise
if
this
gets
adopted
in
in
the
version
that
that
is
the
research
group
version.
There
will
be
text
on
on
bluetooth
as
well.
J
Weren't
texting
this
to
be
done,
so
I
promise
to
add
add
that
great
card
go
ahead.
B
J
I
think
the
the
summary
of
the
different
sdos
is
stable
unless
the
spos
go
and
change
their
specs.
Obviously
the
takeaways
is
is
something
that
is
currently
the
author's
reflection
of
of
understanding
that
that,
generally
there
is
this
bootstrapping
phase,
which
is
then
followed
by
provisioning
and
configuration.
A
Okay,
so
the
the
result
of
the
poll
was
that
there
are
eight
people
who
are
interested
in
providing
comments
on
this
document.
So
that's
a
significant
level
of
interest,
so
I'm
not
going
to
start
another
poll,
but
just
to
get
a
sense
of
the
room.
If,
if
you
are
opposed
to
the
idea
that
the
research
group
could
be
adopting
this
document,
please
speak
up.
A
A
A
A
So
this
should
be
the
point
where
the
the
chairs
point
to
all
the
wonderful
things
that
we
will
be
doing
in
in
the
next
time,
and
much
of
this
actually
depends
on
on
getting
feedback
from
the
research
group.
So
we
have
seen
three
drafts
actually
could
use
feedback
at
the
moment.
Please
please
go
ahead.
A
A
Together,
thank
you,
so
I
think,
with
that
we
can
close
the
meeting.
Thank
you
for
your
participation.
Thank
you
for
for
the
great
talks
and
see
you
at
one
of
the
ad
hoc
meetings
or
the
one
of
the
wishing
meetings
we
are
making
and
otherwise
at
ietf
111's,
summary
meeting.