►
From YouTube: IETF-T2TRG-20210621-1500
Description
T2TRG interim meeting
2021/06/21 1500
B
C
C
This
is
an
irtf
meeting
which
means
that
the
ipr
guidelines
of
the
ietf
apply.
This
is
the
short
form
of
the
node.
Well,
there's
also
a
long
form
which
reminds
you
that
if
you
are
talking
about
technology,
where
the
you
know
about
pattern
claims
you
you
have
to
disclose
that
or
you
can
not
talk
about
that
technology.
C
We
are
in
in
a
standards
meeting
where
we
try
to
be
nice
to
each
other
and
be
productive
and
so
on,
and
this
is
an
irtf
meeting.
So
we
are
not
developing
standards
here
we
are
trying
to
get
research
done,
so
we
are
not
going
to
check
whether
a
new
specification
that
has
to
be
implemented
by
everyone
has
is
getting
working
with
option
or
something
like
that.
We
are
just
trying
to
collect
interesting
content.
C
C
C
C
This
time,
w3c
web
of
things
and
1dm
by
two
of
the
three
michaels
that
will
be
presenting
today.
Savvy
will
then
talk
about
the
research
group,
draft,
iot,
edge
challenges
and
functions,
and
mohich
and
michael
will
talk
about
the
research
group
draft,
secure
bootstrapping
and
the
idf
id
considerations.
That
goes
with
that.
C
So
in
the
research
group
we
look
at
open
research
issues
in
making
a
true
internet
of
things
happen,
and
since
this
is
a
giant
area,
we
are
really
focusing
on
issues
where
we
have
opportunities
for
iatf,
standardization
and
yeah.
We
are
living
in
a
context.
The
one
of
the
useful
things
about
the
itf
is
that
it's
close
to
the
ietf,
so
we
have
various
ietf
working
groups
that
we
are
interfacing
with,
but
I
think
most
people-
you
know
that,
so
I
think
I
can
skip
that
quickly.
C
C
We
decided
to
have
this
meeting,
not
at
iitf
111,
but
a
month
earlier
now,
but
in
july
we
will
have
a
wishy
hackathon
week
in
the
iitf
hackathon
context,
so
that's
july,
19
2023,
if
you're
interested
in
code.
I
will
talk
about
that
in
a
minute.
We
are
also
looking
at
meetings
with
other
sdos
like
ocf
or
oma
or
w3c.
C
B
C
With
some
oh
there,
it
is
okay,
I
I
just
I
thought
I
had
made
an
edit
and
that
somehow
was
lost,
so
we
have
several
documents
that
are
that
have
a
research
group
document
status
that
is
almost
but
not
entirely
unlike
working
group
documents
in
the
ietf.
So
these
are
documents
where,
where
the
research
group
things
it's
good
to
to
pay
some
attention
to
them-
and
these
may
be
worth
publishing
when
completed,
we
have
the
restful
design
for
iot
document
that
that
is
in
progress.
C
C
C
The
second
one
is
the
agent.
I
t
document,
which
we
will
talk
today
talk
about
today,
which
is
also
likely
to
be
completed
this
year
and
the
third
one
is
the
secure
bootstrapping
document
that
we
will
talk
about
later.
Today,
there
is
work
going
on
on
the
information,
modeling
standards
description,
so
something
that
we
have
been
calling
nutrition
labels
for
for
information,
modeling
informally-
and
we
had
some
discussion
about
that
in
the
wishing
meeting
on
on
last
thursday,
and
we
will
continue
that
work.
C
B
Sure
I
can
take
this
one,
so
in
the
wishy
work
we
had
a
meeting
last
week.
It's
been
a
few
months
since
the
last
meeting
I
mean
a
few
months
ago,
we
started
a
discussion
with
the
microsoft
azure
pixel,
queen's
definition,
language
team,
on
how
their
work
on
that's
that
language
and
the
work
we
done
at
the
iedf
on
the
sdf,
how
they
relate
to
each
other
and
how
we
could
perhaps
make
them
interwork.
B
B
One
long-standing
discussion
when
it
comes
to
id
data
models
have,
of
course,
be
this
alignment
and
use
of
engineering
units
so
many
ways
to
do
the
same
things.
Luckily,
with
sdf
and
ddd
we're
both
already
using
si
units.
But
then
again,
ddl
has
extended
a
bit
further
beyond
simple
si
units
and
so
we're
discussing.
What's
the
best
ways
we
can
express
them
in
sdf
and
dddl
to
enable
automatic
conversion
and
interoperability.
B
B
Another
topic
we
discussed
was
this
sdf
young
conversion.
So,
as
you
know,
yang
is
one
of
those
iedf
data
models,
but
then
jana,
the
main
author
of
that
work
will
be
presenting
that
shortly.
So
I
won't
go
with
the
details
here
and
finally,
the
last
piece
of
work
we
discussed
in
the
wishing
meeting
was
iot
information
model
standard
description
as
an
scarce
dimension.
There's
a
tinting
draft
forthcoming
on
that
topic,
then,
on
the
next
slide,
a
bit
of
the
we
see
work
in
future.
B
B
B
And
finally,
we
have
an
sdf
topic
bubbling
under
we've
been
planning
tackle
for
quite
some
time.
It's
what
we've
been
calling
mapping
files
for
sdf.
So
it's
really
about
attaching
additional
information
to
the
sdf
models
that
you
have
defined
with
sdf
and
working,
for
example,
instances
and
classes
and
composition.
C
Yeah,
I'm
just
amazed
by
by
mitchell,
which
saw
me
unmuting
and
I
then
I
didn't
immediately
say
something
and
it
told
me
oh
you're,
not
saying
something
which
is
very
nice.
Okay,
so
ari
already
mentioned
that
there's
work
on
an
sdf,
yank
converter
and
we
have
cut
out
five
minutes
for
for
jana
who's.
Writing
that
a
converter
to
talk
about
that.
Maybe
first
give
an
overview
of
what
what
is
actually
being
converted
there
and
then
give
a
short
overview
over
the
tool
that
you
can
use
today
to
play
with
us.
C
D
Yeah,
okay,
hi,
I'm
jana,
I'm
a
student
at
the
university
of
brim
and
I'm
writing
my
master's
thesis
currently
with
carlson.
As
my
supervisor,
I'm
working
on
a
sdf
van
converter,
and
today
I
just
want
to
show
you
a
selection
of
mappings
between
the
two
formats
to
just
give
you
a
quick
introduction,
because
I
could
also
use
your
help
in
evaluating
the
the
mappings
that
I've
come
up
with
so
far
for
those
of
you
who
don't
know
yang
that.
D
D
D
This
is
translated
to
the
sdf
model,
and
so
the
thing
that
consists
of
the
info
blog
namespace
section
and
definitions,
then
in
yang
you've,
got
containers
who
can
contain
any
of
the
other
nodes.
This
is
a
little
bit
trickier.
It's
either
translated
to
sdf
objects
if
the
container
occurs
at
the
top
level
or
to
sdf
property
of
the
compound
type
so
of
type
object
which
can
have
properties.
D
D
D
So
in
case
of
a
top
level
or
one
level
below
list,
the
list
is
converted
to
sda
property
and
if
it
occurs
at
any
other
level,
it
is
translated
to
the
property
of
a
compound
type
element.
Again
and
in
both
cases
the
type
is
array
and
the
items
of
the
array
are
of
type
object,
because
the
list
has
well
complex,
complex
items.
D
D
D
The
types
array
and
the
items
are
simple
types
on
any
other
level.
Leave
notes
are
just
simple
type
notes
that
occur
a
single
time,
so
this
is
again
same
concept:
sdf
property
of
a
simple
type.
If
the
leaf
occurs
at
top
level
or
one
level
below
or
again
the
property
of
a
compound
type
on
any
other
level,
then
there's
also
type
diffs
and
groupings
which
are
basically
derived
types
that
can
be
used
elsewhere.
D
D
What
I
wanted
to
tell
you
about
actually
is
my
converter
demo,
which
you
can
find
at
sdf
yang
converter.org,
where
you
can
try
out
the
converter
yourself,
so
you
don't
have
to
install
it
from
github
and
all
that
stuff
and
yeah.
I
would
really
appreciate
feedback
on
the
conversions,
because
there
were
some
issues
that
came
up
with
conversions
that
aren't
as
straightforward
as
the
ones.
I
told
you
about
and
yeah.
D
C
Thanks,
john,
so
just
to
remind
people
if
we
want
to
discuss
this,
we
can
do
this
on
the
thing
you
think
research
group
list.
So
don't
don't
be
shy
about
talking
about
things
you
found
there
and
if
we
get
too
detailed,
of
course,
we
can
start
to
take
things
off
list,
but
I
think
right
now
we
are
not
in
in
danger
of
drowning
from
the
synchro
thing.
Research
group
list.
C
So
again,
we
are
not
meeting
at
the
ita
itf
111
itself,
but
we
are
meeting
at
the
hackathon
week
that
precedes
it
and
we
want
to
have
a
wishy
call
on
the
first
day
on
the
monday,
probably
at
1400
utc
and
then
probably
will
just
have
daily
synchronization
calls,
because
most
of
the
work,
of
course
is
is
going
to
happen
on
the
on
the
web
on
the
internet.
So
we
will
throw
models
at
each
other's
tools
and
and
see
what
what
happens
and
so
on.
C
So
we
will
have
a
daily
call,
also
probably
around
the
time,
maybe
a
little
bit
later
in
the
day,
depending
on
how
people
feel
so
converters.
Of
course,
the
dtda
converter
that
ericsson
brought
to
the
table,
the
the
sdf
young
converter,
the
various.
What
converters
that
are
out
there
there's
some
pretty
interesting
stuff
out
there
and
I
hope
we
we
will
be
able
to
get
the
various
authors
of
the
various
tools
together
in
this
hackathon.
C
C
A
A
So
I'm
going
to
do
a
quick
update
of
the
work
on
web
of
things
and
I
actually
have
a
friend
of
material
sorry
for
the
long
slides
the
ones
I
uploaded,
I'm
going
to
skip
over
a
bunch
of
slides
and
materially
uploaded.
So
you
can
look
at
that
later
on
to
get
more
material
and
I'm
just
going
to
very
quickly
do
a
summary.
In
case
people
haven't
seen
it
before,
although
I'm
sure
90
people
here
have,
but
basically
the
web
of
things
is
working
adapting
web
technology
to
iot
within
the
context
of
w3c.
A
Two
years
ago
we
actually
published
a
thing
description,
metadata
format,
which
is
somewhat
similar
to
to
things
like
gtdl
and
an
sdf,
but
it
focuses
on
describing
an
instance
of
a
device,
but
it
gives
you
the
network
interface,
and
it
gives
you
metadata
about
the
device
and
it
also
is
based
on
json
ld.
So
it
supports
things
like
web
semantics
and
the
general
idea
is
provide
kind
of
a
a
common
abstraction
to
interface
between
applications
and
different
other
different
standards.
A
A
A
A
Now
work
in
progress
is
actually
a
signature
pr.
I
will
summarize
that
later,
but
basically
we're
looking
at
extending
jws
now
for
discovery.
We
have
a
new
spec
for
that
and
it's,
as
I
mentioned
later
on,
to
two-phase
mechanism,
but
it
has
relationships
to
dns.
Sd
did
core
rd
we're
also
defining
a
directory
service
api,
which
is
a
http
web
service,
provides
a
database
lets
you
do
search
searching
database
of
tds.
A
A
A
I
don't
think
it's
an
especially
good
design
pattern,
but
we're
trying
to
describe
existing
devices,
including
ones
we
don't
certainly
agree
with,
so
that
was
added,
there's
also
a
similar
mechanism
where
people
might
put
keys
into
a
payload
alongside
other
stuff.
That
is
actually
real
payload,
and
so
we
added
a
mechanism
to
describe
that
as
well.
A
A
A
A
A
The
current
status
is,
we
basically
are
in
the
phase
where
we
have
the
spec,
mostly
written,
and
now
we're
trying
to
figure
out
how
to
test
it
under
introductions.
We
have
a
few
normative
extensions,
so
in
particular
for
things
that
have
a
service
type
like
dns
sd,
we
have
to
define
some
service
types.
A
A
C
Michael
can
can
interject
there,
so
I
think
the
json
path
working
group
would
be
really
interested
in
your
requirements.
So
what
what
do
you
need
jsonpath
to
have
to
do
right
now?
We
are.
The
general
sentiment
is
that
we
will
have
something
like
a
minimum
viable
product
in
the
first
rfc
right.
But
if
there's
something
you
need,
we
need
to
know.
A
Yeah-
and
I
think
we
need
to
do-
is
we're
able
to
use
cases
and
examples
to
clarify
that
the
main
thing
we
need
that's
different
from
the
current
you
know
version
is
we
have
to
limit
the
power
of
you
know,
j
javascript
snippets,
so
we
don't
want
to
be
I'll,
have
to
be
able
to
do
a
injection
attacks
on
on
directory
servers.
So
we
need
to
limit
the
not
the
comparisons
that
can
be
done
and
the
the
scripts
to
like
just
a
small
subset.
C
A
Well,
I
will
say
our
main
issue
right
now
is
timing,
so
we
don't
have
a
lot
time
to
make
fancy
requests.
What
we
really
need
is
have
a
minimum
vial
product
out,
so
we
can
reference
to
reference
it,
and
then
we
can
do
fancier
things
in
in
the
discovery
2.0
next
year.
So
I
think
what
we
want
right
now
is
just
the
minimum
viable
thing.
I
think
we
at
least
want
to
have
equivalent
functionality
to
json
pointer
right.
You
know
select
a
particular
yeah.
You
know
that
should
be
easy.
A
A
Sorry,
I'm
going
to
move
on
because
we're
out
of
time
here
our
profiles
are
constraints.
So
profiles
just
try
to
constrain
things.
As
I
said,
we're
focused
on
just
the
hub
functionality,
which
translates
a
bunch
of
different
standards
into
one
http
json,
and
we
also
want
to
make
sure
the
implementation
is
fine,
finitely
implementable,
so
the
finite
set
of
things
that
it
has
to
do
because
the
tv
is
pretty
open-ended.
We
wanted
to
like
limit
it
to
make
it
implementable
and
make
it
validatable.
A
So
this
is
just
a
set
of
constraints
to
be
able
to
happen.
I
won't
go
through
this
in
detail,
just
the
idea
that
we
only
allow
a
certain
fine
set
of
things
and
we're
currently
doing
this
sort
of
baseline,
and
we
also
are
trying
to
you
know
clear
things
like
you
know:
what
are
the
error
codes?
What
do
they
mean
and
so
forth?
A
A
A
C
A
A
C
C
E
E
Okay,
so
this
is
a
an
update
on
one
data
model.
I'm
assuming
everyone
sort
of
has
a
an
idea
of
what
one
data
model
is,
but
what
we're
doing
is
using
the
sdf
language
to
to
drive
for
a
common
data
model
for
common,
in
other
words,
that
one
data
model
that
everyone
can
use.
Hence
the
name
one
data
model
for
the
common
iot
affordance
patterns
like
on
off
control
and
color
control
of
a
light
and
temperature
sensing
and
thermostatic
control,
and
things
like
that.
E
So
I'm
going
to
go
through
what
you
know
where
we
are
and
and
sort
of
we
depend
on
sdf,
but
we've
we've
moved
the
sdf
work
completely
out
of
one
data
model
and
and
that
standardization
is
in
process
and
we're
we're
just
going
to
use
whatever
is,
is
done
by
one
by
stf
and
provide
requirements.
So
we're
kind
of
doing
a
pressure
test
of
sdf
right
now
and
we're
looking
at
a
couple
of
new
features
as
re
mentioned.
But
the
main
body
of
work
is
around
the
convergence
of
data
models
across
industry.
E
So
currently
we
have
about
200
models.
I
think
it's
about
195
models
in
the
playground
contributed
mostly
from
oma
lightweight,
m2m
and
ocf,
but
we
have
some
examples
from
bluetooth
mesh
and
the
zigbee
cluster
library
in
there
as
well,
and
we've
we've
determined
what
process
we
want
to
use
for
convergence
and
that
is
sort
of
a
model.
E
E
We
have
some
provisional,
basically
we're
going
to
create
some
provisional
adopted
models
for
the
first
ones,
with
the
understanding
that
they'll
be
stable,
but
ultimately
they
may
be
superseded.
As
we
get
more
a
larger
body
of
people
involved
in
the
consensus
process,
we
need
to
go
back
and
re-engage
with
some
of
the
early
contributors
because
the
we
spent
a
lot
of
time
on
the
language
design
and
on
the
process
and
and
a
lot
of
the
folks
just
want
to
get
their
models
adopted.
E
E
The
the
owen
so
basically
there's
some
ongoing
questions
about
how
sensors
should
be
handled
in
quantities
and
units,
as
audi
mentioned
earlier.
I
don't
know
if
we
really
talk
about
that
too
much
in
another
slide,
but
here's
the
ocf
models
and
we're
basically
looking
at
things
that
things
that
can
be
that
don't
really
that
don't
overlap
with
a
lot
of
other
models.
I
we
had
some
some
criteria
for
what
models
we
wanted
to
select
for
the
early
revisions
and
they
were
sort
of
non-controversial.
E
So
you
think
in
a
mode
as
being
you
know,
diagnostic
mode
or
running
mode
or
a
failure
mode,
or
maybe
a
fan
mode
that
might
be
running
one
way
or
another,
and
then
operational
state
is
sort
of
what,
where
you're
going
on.
If
it's
a
dishwasher,
you
might
have
the
rinse
cycle,
the
wash
cycle,
the
drying
cycle,
etc,
and
so
those
are
all
in
the
on
off
switch.
E
So
basically,
quantities
in
units
is
probably
a
good
place
to
start
because,
as
hardy
said,
that
that
really
turns
out
to
be
a
bigger
issue
than
than
I
expected
it
to
be.
But
basically
you
know,
should
we
bind
units
to
sensor
type
and
that's
a
really
good
question
should
should
a
temperature
sensor
always
report
in
celsius,
or
should
we
basically
have
some
conversion
ability
or
adaptation
ability
to
different
units?
And
of
course,
temperature
is
a
good
example,
because
it
has
some
alternate
units,
many
sensors.
Don't
so
it's
not
a
problem.
E
So
that's
really
the
the
crux
of
the
the
question
here
is:
should
we
have
a
bunch
of
definitions
that
are
tied
to
units
like
a
temperature
sensor,
a
humidity
sensor,
a
barometric
pressure
sensor
and
so
on?
Or
should
that
be
a
sensor
as
in
say,
bacnet
has
just
a
sensor
and
then
you,
you
have
values
that
you
put
in
and
then
you
customize
it
according
to
engineering
units
way
down
the
road,
and
so
there's
really
a
range
for
a
few
different
patterns
here.
E
Currently,
in
the
definitions
contributed,
they
were,
they
were
specialized
per
units,
but
it's
not
really
clear
that
that's
the
the
best
way
to
do
things
or
if
there
should
be
two
patterns
and
an
alternate
specialized
sensors
and
a
generic
sensor,
then
people
have
a
question
of
which
one
to
use
etc.
So
that's
basically
the
flavor
of
it
and
then
you
know
a
lot
of
the
sensors
are
multi-sensors,
and
so
how
do
you
deal
with?
That?
Is
there
a
way
that
we
need
to
standardize
the
way
multiple
sensors
are
packed
together?
E
Particularly
bluetooth
mesh
has
a
really
good
system
for
doing
that
from
columnar
data
and
timestamp
series,
but
that's
their
way
of
doing
it,
and
is
that
something
that
we
could
standardize
or
do
we
need
to
have
some
some
consensus
sort
of
drive
for
some
consensus
around
a
few
different
you
know
have
a.
I
guess
what
you'd
call
a
dialectic
approach
where
we
try
to
synthesize
the
best
from
a
few
different
approaches
all
right.
So
this
is
kind
of
my
last
slide
to
illustrate
sort
of
a
use
case
and
what
really
driving
for
an
industry.
E
We
could
create
a
proxy
from
that
software
and
that
would
automatically
consume
essentially
any
any
any
oma
server
or
device
that
has
a
definition
in
sdf
and
expose
it
as
an
ocf
client.
Now
I
think
something
that
michael
mccool
was
mentioning
earlier
is
really
interesting
here.
If
there
is
a
common
web
of
things
profile
for
how
software
clients
access
things,
then
this
picture
would
have
many
different
types
of
servers
and
devices
on
the
bottom
ocf
oma,
you
know
lightweight
m2m,
zigbee,
bluetooth
and
then
the
top
part
would
be
the
common
web
of
things
profile,
client.
E
Let's
see,
I
think,
that's
all.
I
have
there's
some
backup
slides
here
that
you
can
look
at
and
then
we
kind
of
show
how
the
workflow
works
and
and
for
adopting
models
and
and
some
of
the
stuff
about
who's
involved,
and
this
is
kind
of
interesting,
where
one
little
point
where
we're
planning
on
providing
a
way
for
anyone
to
just
host
their
models
in
sdf
as
a
as
a
way
of
standardizing
the
format,
without
necessarily
participating
in
the
in
the
convergence
process.
E
E
So
I'm
not
going
to
be
personally
interested
in
this
much
about
you
know
smart
home
devices
anymore,
but
I
think
that
I'm
looking
at
conversions
for
dtdl
to
sdf
and
bacnet
and
a
new
thing
that
we're
developing
called
the
quantum
ontology,
which
is
a
physical
physics
ontology
for
building
that
has
to
do
with
enthalpy
and
things
like
that.
So
that
would
add
three
new
three
or
four
new
conversions,
so
we
could
think
about.
You
know.
You
know
that
coming
up
with
that.
E
So
far,
though,
there's
only
really
a
sort
of
a
software,
repo
or
open
source
sort
of
conversion,
but
I
think
if
we
could
move
these
up
to
a
sort
of
a
high
level
status
in
in
terms
of
there's
a
conversion
as
the
spec
changes,
the
conversion
changes,
maybe
not
everyone's
involved.
Maybe
this
is
just
being
pulled
from
an
open
source,
repo
and
being
synced
whenever
they
make
an
update.
E
So
there
are
a
lot
of
different
ways
to
do
that,
and
I
think
that
your
suggestion
could
be
taken
as
a
general
sort
of
category
of
things
to
add
to
one
dm
to
what
we
talk
about
and
track
and
manage.
So
I
I
think,
that's
that
sounds
pretty
good
and
again
thanks
for
the
the
plug
for
moving
moving
on
to
sort
of
digital
twin
work,
because
I
think
that's
a
new
emerging,
a
new
emerging
thing
that
that
creates
almost
a
whole
new
application
area
for
something
like
this
and
also
this.
E
This
diagram
here,
basically,
is
a
good
illustration
of
the
kind
of
architecture
that
a
digital
twin
would
would
use.
It
would
normalize
the
data
from
a
bunch
of
different
sensors
and
actuators
and
the
control
affordances,
and
it
would
present
a
single
sort
of
unified
semantic
interface
to
the
to
the
upper
layers,
and
indeed
that's
one
of
the
bigger
questions
about
digital
twin
that
helps.
You
do
the
modeling,
because
then
you
don't
have
to
think
about
a
lot
of
different.
A
Michael
yeah,
I'm
most
interested
in
tracking
the
conversions,
I
think
they're
a
really
good
test
case.
Let
us
know
how
compatible
the
different
standards
are
and
whether
they're
just
modeling
the
same
information
in
different
ways,
and
so,
regardless
their
practical
utilities.
I
think
they
are
very
practical.
I
think,
having
those
conversions
around
really
helps
us
test
our
compatibility
of
our
various
information
models,
in
fact,
to
the
extent
that
when
looking
at
like
directory
services
and
thinking
you
know,
could
we
have
a
single
information
model
and
just
serialize
it
in
different
formats?
C
Truly
yeah,
I
think
this
is
really
important,
really
useful
input
for
the
hackathon
that
we're
going
to
have
in
in
four
weeks.
We
have
started
in
the
wishy
activity
to
collect
pointers,
to
tools,
and
maybe
this
is
a
reminder
to
update
that.
So
we
we
should
be
able
to
have
an
inventory
of
what
the
kinds
of
tools
we
have
available.
Maybe
that's
something
we
can
prepare
for
the
hackathon
and
then,
of
course,
at
the
hackathon.
C
We
can
look
a
bit
more
more
closely
and
what
we
actually
can
get
converted
and
one
one
great
thing
that
came
out
on
thursday.
When
we
had
our
wishing
meeting
and
talked
to
the
microsoft
people
about
the
asia
gtdl
work.
Is
they
now
also
have
some
models
out
there?
So
the
next
thing
that
we
will
look
at
is
how
to
get
these
models
in
into
the
repositories
as
well.
And
of
course,
there
are
other
models
that
are
waiting
for
this.
E
Yeah,
that's
that's
really
good
and
I'm
remembering
carsten
really
early
on.
In
fact,
even
back
at
the
iab
semantic
interoperability
workshop,
you
had
made
a
diagram
of
of
how
translation
works
in
general,
with
the
common
format
showing
a
box
in
the
middle
and
arcs
coming
in
and
arcs
going
out
and
really
the
system
we're
building,
isn't
just
the
box
in
the
middle.
It
includes
these
arcs
that
come
in
and
go
out
which
are
in,
in
fact
the
conversions.
E
So
really
that
makes
a
lot
of
sense
and
and
having
those
as
something
a
little
bit
higher
level,
also
with
digital,
twin
and
other
kinds
of
we're.
Looking
at
physical
models
of
things
that
aren't
necessarily
don't
have
the
same
kind
of
affordances.
They're
they're
mainly
object
property
models,
but
they
describe
the
physical
part
of
things
that
are
connected
to,
like
you
know
the
heaters
and
the
the
the
pump
and
the
tank
and
things
like
that
condensers.
E
So
those
things
are
also
needed,
but
they
don't
necessarily
get
converted
they
get
expressed,
or
maybe
they
get
converted
if
we're
talking
about
something
like
opc
ua,
where
those
models
already
exist.
But
that's
also
part
of
the
ecosystem.
We
need
to
understand
that
sdf
is
going
to
be
modeling
more
than
just
connected
devices
that
you
can
talk
to,
but
also
the
things
that
they
connect
to.
G
Here
we
go
good
yep.
Thank
you,
yeah.
So
I'd
like
to
present
an
update
to
our
draft
on
iot
edge
computing
challenges
and
functions
right,
so
in
revision
2,
which
we
are
presenting
today,
we
addressed
commands
from
milan
and
we
made
also
other
related
changes,
so
we
will
go
through
that
in
the
rest
of
the
slides.
We
also
contacted
some
standard
community
members
for
comment,
but
for
now
we
didn't
get
technical
feedback,
so
we
are
still
waiting.
G
G
G
We
then
list
in
the
same
section
for
research
challenges
organized
by
functions
or
components,
so
they
are
loosely
classified
as
oem,
functional
and
application
and
well,
one
point
is
that
those
functions
need
to
be
at
relatively
high
level
so
that
you
know
they
map
to
research
challenges
without
too
much
overlap
between
them.
So
this
this
this
function
is
here
to
structure
the
the
research
space.
In
a
way
you
know,
then
we
have
a
section
on
simulation
and
emulation
environments
and
one
on
security
considerations.
G
G
The
second
comment
had
basically
two
observations.
You
know
from
the
fact
that
connectivity
can
be
constrained
and
also
it
can
be
costly
upstream
and
downstream.
So
basically,
there
was
a
need
to
broaden
some
statements,
so
we
changed
the
title.
We
made
the
minor
changes
to
basically
cover
those
additional
aspects,
and
the
third
comment
was
that
it
was
about
resilience
and
it
provided
some
text
to
describe
resilience
today
in
iot,
iot
deployments.
G
G
D
G
G
We
also
added
new
research
challenges
corresponding
to
recent
papers.
They
are
added
in
references
in
ref.
So
basically,
if
you
want
to
check
them,
you
know
because
the
diff
is
a
bit
difficult
to
read,
so
you
can
look
at
the
diff
of
the
reference
section
and
basically
look
them
up
in
the
in
the
text.
They
will
correspond
to
new
challenges
or
extensions
of
existing
ones
and
those
are
basically
2021
papers.
G
So,
finally,
we
did
some
editorial
changes
as
well.
Right,
so
to
our
knowledge,
all
outstanding
comments
are
addressed.
The
draft
is
in
a
stable
state.
Additional
comments
are
welcome
and
finally,
I'd
like
also
to
take
a
you
know
for
us
to
to
discuss
whether
it
makes
sense
to
start
a
last
call.
Is
this
the
right
moment,
so
it
could
help
elicit
some
final
comments.
G
G
A
G
C
A
I
think
that's
a
yeah,
I
do
recall
now
I
checked
it
out
and
got
it
to
compile,
so
it
just
got.
I
ran
out
of
time
and
then
the
new
version
came
out
and
my
comments
were
no
longer
valid
right,
so
I
just
need
to
get
it
all
done
quickly,
so
I
guess
I'll
have
to
find
some
time
to
sit
down
and
just
do
it
for
the
third
version.
Third
time.
C
Yeah,
so
I
think
that's
also
one
thing
that
that
we
learned
it's
really
best
to
submit
comments
in
in
smaller
pieces.
So
if
you
do
a
review
and
you
have
done
the
partial
one-
don't
don't
wait
until
you
have
time
to
actually
complete
the
thing,
send
it
on
to
the
authors.
They
can
do
something
useful
with
that,
and
you
can
always
go
back
to
reviewing
the
the
next
version
of
the
document.
C
So
I
think
that
that's
a
pretty
important
thing
also
when,
when
you
have
these,
these
monster
pull
requests,
it's
sometimes
hard
to
to
integrate
them
in
particular,
if
you
get
two
at
the
same
point
in
time,
so
keep
it
small,
keep
it
simple
and
keep
it
timely.
I
think
that
that's
the
advice
I
would
give
to
people
who
want
to
do
this
pull
requests.
C
Yeah
that
may
be
also
be
overwhelming
because
you
might
have
20
years
in
the
end,
but
so
the
truth
may
be
somewhere
in
the
middle,
but
I
think
the
important
point
is
actually
sending
things
incrementally.
So
you
you
don't
create
a
lot
of
delay,
but
I'm
hearing
from
this
that
that
people
are
actually
interested
in
getting
a
few
more
reviews
in,
and
I
think
it's
also
time
for
for
the
chairs
to
provide
a
review.
C
C
C
H
The
change
since
the
last
ietf
is
that
the
document
is
officially
adopted.
As
a
research
group
item,
we
haven't
really
made
changes
to
the
content,
but
I
guess
the
goal
of
today's
presentation
and
interim
meeting
is
to
present
some
suggestions
that
we
have
on
on
possible
future
directions
for
this
document
and
get
feedback
from
all
of
you
before
we
actually
go
and
edit.
H
The
draft
and
a
lot
of
the
the
changes
and
suggestions
are
actually
coming
coming,
not
not
from
the
authors
but
from
working
group
chairs
and
and
members
like
carsten.
So
a
lot
of
the
material
that
we'll
be
presenting
today
is
actually
based
off
off
of
a
presentation
from
carson
borman
in
the
iot
ops
working
group.
H
So
just
to
recap,
why
does
this
document
exist?
And
what
are
we
trying
to
do
with
this?
So
the
goal
was
that
there
is
so
many
different
bootstrapping
protocols,
so
we
thought,
like
maybe
having
a
document
trying
to
summarize
some
of
the
common
bootstrapping
protocols,
would
make
sense
and
when
we
started
doing
that,
more
and
more
new
protocols
from
different
standards,
organizations
came
up
and
obviously
not
all
of
them
were
even
using
say,
similar
or
same
terminology
and
over
time.
H
Another
goal
is
to
identify
common
patterns
so
and
provide
recommendations
on
applicability
of
terms
so
with
common
patterns.
I
guess
by
now
many
of
you
have
seen
this
common
interaction
in
smart
home
environments,
where
you
are
expected
to
either
scan
some
qr
code
or
or
something
of
that
sorts
before
your
iot
device
can
join
your
home
network,
so
different
protocols
and
sdos
may
call
it
a
companion
device
or
a
configurator,
for
example,
but
it's
essentially
the
same
purpose
and
then
the
same
pattern.
So
one
of
the
goals
was
to
identify
these
common
patterns.
H
We
did
try
to
initially
classify
these
bootstrapping
techniques
using
some
traditional
methodology
like
managed
and
unmanaged
and
leap
of
faith
methods,
but
we
soon
realized
that
it's
actually
pretty
hard
to
classify
them.
Some
of
them
are
obviously
easy
and
straightforward
and
fall
into
one
or
the
other
category,
but
many
of
them
fall
into
this
generic
category
of
hybrid
methods
where
they
might
do
this
or
might
do
that
and
in
some
situations
they
support
this,
and
obviously
you
know
anyone
who
is
writing
a
protocol
specification
once
it's
to
address
as
many
use
cases
as
as
possible.
H
So
it
often
happens
that
in
some
cases
it's
in
one
category,
whereas
in
in
other
cases
it's
in
another
category.
So
there
are
very
few
protocols
that
say
we
only
address
small
enterprise
or
something
I
think
many
of
them
would
say.
We
address
home
and
small
enterprise
and
maybe
also
like
full
enterprise
experience.
H
So
moving
on
so
we
started
documenting
the
terminology
and
the
current
list
which
we
have
in
the
draft
and
and
here
on
the
slide.
So
we
immediately
realized
that
there
is
lots
of
similar
terms
that
are
being
used
in
this
context.
There's
bootstrapping
provisioning,
onboarding,
initialization
registration
commissioning
configuration
discovery.
H
So
immediately
we
realize
is
even
is
the
title
of
the
draft
correct,
because
we
call
this
secure,
bootstrapping,
secure,
iot
bootstrapping
survey,
but
if
bootstrapping
is
not
the
only
term
that
is
used
in
this
context,
what
should
the
draft
be
called
and
we
got
a
nice
suggestion
from
carson
of
using
initial
security
setup
as
kind
of
an
overarching
term?
That
includes
there's
an
essence
of
all
these
terms.
H
Basically
that
you
want
to
do
the
initial
security
setup
of
of
an
iot
device
and
the
suggested
new
title
is
terminology
and
processes
for
initial
security
setup
of
iot
devices,
and
obviously
we
look
forward
to
your
feedback.
If
this
makes
sense.
The
other
idea
we
got
from
carson
was
to
actually
break
down
protocols
into
three
things.
So,
first
is
to
identify
the
players.
H
H
So
typically,
this
may
include,
like
ssid
network
key,
even
some
protocols
like
configure
the
initialization
vector
that
should
be
used
by
the
device.
All
these
things
would
be
the
post
up,
beliefs
that
are
instilled
into
the
device
during
the
process
and
the
third
building
block
for
these
protocols
is
the
actual
processes,
so
the
sequence
of
events
that
must
be
done
for
this
security
setup.
So
many
times
it's
powering
up
the
device.
H
H
It
may
be
like
accepting
some
checkbox
on
your
companion
device
like
a
smartphone,
but
basically
what
kind
of
interactions
are
required
and-
and
there
are
many
protocols
that
actually
don't
require
anything
from
the
user.
So
you
I'm
sure
all
of
you
have
heard
about
this
zero
interaction
protocols
where
the
user
doesn't
really
have
to
do
anything.
So
I
have
taken
two
examples
of
protocols
and
then
tried
to
break
them
down
into
these
building
blocks
of
players,
beliefs
and
processes.
So
the
first
one
is
device
provisioning
protocol.
H
H
It
has
three
sub
protocols,
so
bootstrap
where
you
typically
scan
a
qr
code
or
tap
nfc
for
the
device.
Then
there
is
a
actual
exchange
that
happens
between
the
smartphone
and
the
iot
device,
where
authentication
happens,
and
typically
it's
a
authentication
in
one
direction
where,
like
the
iot
device,
is
authenticated.
H
But
the
protocol
allows
you
to
do
authentication
in
both
the
both
the
directions.
It
would
just
require
that
not
only
the
smartphones
can
secure
code.
You
will
also
need
the
other
other
direction
in
in
some
form,
so
whether
the
iot
device
scans
a
qr
code
as
well
or
uses
some
other
mechanism
to
transfer
the
public
keys
is
kind
of
left
open,
but
it
is
possible
to
do
mutual
authentication.
H
All
the
most
most
deployments
would
do
only
only
one
way
and
then,
finally,
once
the
authentication
is
complete,
the
smartphone
will
configure
or
install
information
such
as
the
ssid
and
passphrase,
so
quite
straightforward
protocol
and
user
experience.
So
let's
look
at
the
players,
so
there's
the
manufacturer,
which
installs
a
key
pair
and
then
ensures
that
the
public
key
and
other
metadata
of
the
of
the
device
that
is
being
shipped
is
available
on
the
device
or
on
its
packaging.
H
There's
the
user,
which
in
most
cases
is
then
also
treated
as
the
owner
of
the
device
and
a
companion
smartphone,
which
is
used
for
completing
the
process,
believes
that
exists
before
the
protocol
is
executed.
So
basically,
it's
the
manufacturer
installed
asymmetric
keypair
and
after
the
setup
is
done,
the
device
is
installed
with
knowledge
such
as
the
ssid
and
passwords.
It
should
use
to
connect
to
the
internet,
and
the
process
is
user
scanning
a
qr
code
or
tapping
nfc.
H
If
mutual
authentication
is
desired,
then
it's
done
twice
in
both
directions
and
generally
the
user
kind
of
configures,
the
ssid
and
passphrase
of
his
home
router
that
the
iot
device
should
connect
to
so.
The
second
protocol
that
I
wanted
to
cover
today
was
bluetooth.
One
of
the
reasons
was
this
for
covering
bluetooth,
and
this
is
currently
not
in
the
draft.
H
It
just
says
to
be
done,
and
erranding
complained
at
the
last
d2trg
meeting
when
it
will
be
done
so
at
least
now
we
have
it
on
the
slides
and
hopefully,
after
this
meeting
I'll,
add
this
information
to
the
draft
as
well.
So
bluetooth
mesh
calls
provisioning
similar
to
dpp,
which
is
device
provisioning.
Protocol
bluetooth
mesh
calls
this
process
of
initial
security
setup
as
provisioning
and,
as
is
quite
common.
H
There
is
a
device
which
is
unprovisioned
and
needs
to
be
provisioned
and
then
a
smartphone
which
kind
of
helps
the
user
in
the
process
to
do
that,
it
begins
with
the
invitation,
so
the
device
sends
out
beacons.
Saying
I'm
unconfigured,
please
configure
me
a
smartphone
will
discover
these
beacons
and
then
send
an
invitation
that
hey,
I
could
configure
you
and
the
new
device
would
say
here
are
my
capabilities.
So
these
are
the
cryptographic
algorithms
I
support.
These
are
my
I
o
capabilities
and-
and
these
are
like
elements
that
are
part
of
the
device.
H
So
elements
is
basically,
if
you
think
of
a
light
strip,
then
each
each
individual
light
would
be
an
element.
That's
how
at
least
bluetooth
mesh
defines
them.
There's
a
public
key
exchange
that
happens
after
this.
So
it's
a
typical
elliptic
curve
tv
helmet
key
exchange
with
fresh
keys,
and
this
happens
if
ob
input
or
ob
output,
authentication
method
is
used.
So
ob
here
stands
for
out
of
band.
H
So
if
out
of
band
authentication
is
used,
then
typically
a
fresh
ecdh,
key
exchange
happens,
and
thereafter
there
is
a
actual
transfer
of
data
on
an
out-of-band
channel
and
bluetooth
actually
is
allows
sending
this
data
as
a
blinking
led
light
or
as
audio
noise.
So
you
could
think
of
this
configuring,
like
some
bluetooth
speakers,
for
example.
H
Finally,
once
this
shared
key
is
set
up
between
the
smartphone
and
the
new
device
that
is
used
to
like
protect
data
which
is
being
sent
to
the
unconfigured
device,
so
this
data
can
include
the
network
key
unicost
address
that
the
device
should
use
and
and
other
information,
such
as
the
iv
index
and
and
so
on,
so
to
look
at
the
building
blocks
for
this
protocol.
The
the
players
in
this
case
are
a
user
and
provisioner.
H
So
you
might
immediately
notice
that
in
this
case
the
manufacturer
of
the
device
is
not
really
a
player,
at
least
in
the
mode
of
provisioning
that
I
have
shown
in
the
slides.
Bluetooth
also
has
other
other
modes
of
probationing,
where
the
manufacturer
may
install
a
key
pair
and
and
print
a
qr
code,
but
just
to
kind
of
show
a
variation
of
that
process.
H
C
Okay,
thank
you.
So
I
think
the
the
same
observation
applies
that,
since
the
thing
is
on
github,
it
may
be
very
easy
to
put
up
issues
there
or
make
text
suggestions
there.
But
of
course
we
also
welcome
the
traditional
review
sent
to
the
meeting.
So
if
you
have
a
small
thing,
maybe
the
issue
is
the
right
way
to
do
this
or
a
short
notice
to
the
meetings,
of
course.
Also
is
the
right
thing.
C
H
I
guess
I
would
like
to
get
at
least
the
updated
content,
some
of
the
updated
content
ready
before
the
cut
off
for
july
ietf,
but
yeah
after
that
it
depends
a
little
bit
also
on
getting
some
some
feedback
on
on
the
content.
That
is
there.
So
obviously
all
the
authors
have
been
also
busy
and
we
have
been
a
little
bit
lacking
and
we'll
try
to
make
up
for
that.
So
hopefully
there
should
be
a
new
version
before
the
cutoff
for
july,
and
after
that
it
depends
on
what
kind
of
feedback
we
get.
C
I
Well,
I
think
that
that
this
is
michael
richardson.
I
think
that
the
proposed
revisions
to
the
art
to
the
structure
of
the
document
are
really
good.
I
says
mohit
said:
there's
a
fair
bit
of
work
to
do
to
to
reorganize
it.
That
way-
and
I
guess
I'm
really
looking
forward
to
that
thing-
and
I
really
like
this-
the
process
that
in
slides
three
or
four
or
whatever
it
was
that
he
proposed.
I
I
think
it's
great,
but
I
think
that
we
just
need
to
get
to
that
point
somewhere,
yeah,
that's
the
breakdown
yeah
exactly.
I
really
like
that.
I
think
that's
a
really
good
thing,
and
I
think
that
it
will
maybe
provide
a
good
for
future
documents
that
people
write
about
this
thing
they
will
hopefully
provide.
I
You
know
a
clear
clarity
on
this
and
I
think
it
would
also
provide.
I
don't
know
whether
this
I
don't
know
this
document
needs
to
go
actually
talk
about
very
many
examples,
but
I
guess
it's
good
to
talk
to
about
those
that
we
know
about.
I
really
hope
that
there
might
be
somebody
in
this
working
group
that
is
a
able
to
provide
these
details
on
the
chip
matter
stuff
in
an
authoritative
fashion
for
it,
because
I
think
that
would
be
timely
to
include
that.
I
C
Yeah,
I
think
one
one
as
michael
said,
one
of
the
important
benefits
from
this
document
might
be
that
we
have
an
example,
a
model
for
how
you
would
talk
about
a
specific
bootstrapping
approach
on
boarding
approach.
So
we
have
the
right
words
to
talk
about
these
things,
and
so,
for
instance,
if
if
people
are
coming
with
new
models,
they
would
be
able
to
describe
in
a
way
that
it
can
be
compared
with
existing
ones,
of
course,
unless
they
want
to
obviously
how
their
stuff
works,
which
also
sometimes
happens.
J
Yes,
sort
of
telling
what
michael
richardson
said
so
yeah
sure
not
to
to
list,
I
don't
think
we
should
list
every
single
one,
but
let
me
offer
another
one
in
addition
to
matter
that
might
be
important.
The
fido
issued
recently
an
iot
security
spec,
so
that
one
might
be
might
be
relevant
just
because
fido
is
is
very,
very
prevalent
in
authentication
space
already
and
the
another
thing
that
comes
to
mind
is
nist
has
issued
guidelines
for
iot
security,
and
it
would
be
good
to
see.
J
Maybe
it
would
be
an
extra
section
to
see
of
the
the
mists
of
the
world
or
the
government
guidance
which
ones
of
the
reviewed
comply,
or
how
do
they
comply
sort
of
to
give
guidance
to
folks
who
might
be
interested
in
going
one
step
beyond
and
actually
contemplating
adoption,
because
once
you
contemplate
adoption,
then
things
like
what
governments
are
that
government
guidance
becomes
fairly
important.
I
think
at
least
for
certain
style
of
deployments.
H
Yeah
thanks
gabriel,
for
the
feedback
fido
is
currently
at
least
in
the
draft.
It's
described
what
the
protocol
does.
Obviously
it's
not
described
in
the
fashion
that
the
slice
currently
suggests.
So
this
was
more
like
asking
for
feedback,
and
it
seems
people
seem
to
support
this
direction
of
breaking
down
protocols
into
players,
beliefs
and
processes.
So
I
would
do
that
for
fido
as
well.
H
C
C
Okay,
so
yeah.
I
hope
that
the
the
prediction
I
made
in
in
the
introduction
that
this
is
a
20
20ish
20
22-ish
document
will
come
true,
maybe
a
bit
hard
to
finish
it
during
this
year,
but
we
might
get
it
in
a
status
where
we
can
do
most
of
the
process
this
year.
So
I'm
looking
forward
to
this
document
being
processed.
I
I
So
an
experience
I
went
through
with
a
couple
of
sort
of
non-ietf
reviewers
and
some
you
know,
there's
a
list
called
dumpster
fire
out
there
as
well,
and
basically,
what
I
encountered
at
some
point
was
that
there's
a
certain
amount
of
skepticism
as
to
you
know,
oh
well,
pki
will
never
be
secure
because
someone
will
just
screw
it
up
and
the
manufacturer
won't
know
what
they're
doing
they'll
forget
what's
going
on
and
other
stuff
and
then
other
people
said:
oh
no,
no!
No!
I
Of
course,
none
of
them
were
willing
to
talk
about
the
details
of
why
theirs
was
was
sufficiently
secure
but
not
excessively
secure
and
that
why
it
was
useful,
and
so
this
is
where
this
document
came
about
to
kind
of
provide
some
analysis
of
what's
going
on.
So
how
does
it
relate
to
this?
So
we
have.
I
I've
should
have
called
this
players,
but
it's
the
manufacturer,
the
manufacturing
player,
and
they
do
things.
I
I
Once
it's
on
the
network,
backup
of
the
configuration
and
the
settings,
that's
actually
something
often
forgot
particularly,
is
very,
very
critical
in
industrial
settings
because
they
really
need
to
be
able
to
restore
the
the
configuration
essentially
when
they
replace
the
device,
and
there
may
also
be
some
discovery
here
that
happens
as
part
of
onboarding
and
there's
some
back
and
forth
there.
So,
for
instance,
mohit's
previous
slide
about
bluetooth
mesh
on
boarding
that
there's
a
definite
discovery
process.
I
I
So
what
I'm
actually
interested
is
now
going
into
the
third
dimension
of
that
that
box
and
talking-
and
this
is
what
my
document
tries
to
do-
is
to
connect
the
two
things.
So
in
some
cases
there's
the
manufacturer.
What
they
do
in
particularly
in
the
silicon
space
is
that
they
provision
some
kind
of
shared
secret
into
the
silicon
and
they
provide
it
to
the
next
people
down
the
chain.
I
Who
may
do
something,
and
as
far
as
I
can
tell,
this
is
probably
you
know,
transmitted
in
the
form
of
excel
file
or
something
like
this
or
csv
file
securely
transported.
And
if
you
have
visions
of
that
johnny
mnemonic
movie,
I
think
that
you're
thinking
the
right
way,
because
I
think
that's
actually
the
kind
of
level
of
security
that
people
need
to
think
about
here.
I
But
the
next
step
here
is
you,
you
create
an
idev
id,
and
that
requires
some
kind
of
a
certification
authority
to
do
something
like
this
and
to
sign
them
for
in
a
device
unique
way.
And
then
you
put
some
kind
of
a
root
ca.
On
top
of
that,
because
the
ca
that's
running
in
the
factory
is
perhaps
only
the
one
that
runs
for
a
couple
months,
or
maybe
a
year
at
most,
and
then
you
cycle
it
get
a
new
private
key
and
things
like
that
and
that's
what
this
document
talks
about.
I
I
Well,
how
do
we
do
the
security
around
this
process
right?
What
is
the
human
factors
around
this
and
what
pieces
can
we
understand
this?
So,
for
instance,
was
there
one
does
the
secrets
held
by
one
person
or
by
three
people
or
seven
people?
Do
you
need
four
people
to
put
the
secret
back
together
or
or
two,
and
that's
just
a
number
that
that
is
there
is,
is
three
better
than
four.
I
don't
know,
and
I'm
not
trying
to
say
so,
one
way,
the
other.
I
So
that's
a
downside,
you
might
say,
on
the
other
hand,
the
more
pieces
you
have,
the
more
likely
it
is
that
they
don't
get
killed
in
a
bus
by
a
bus
or,
if
you're,
trying
to
bring
up
a
new
plant
in
a
new
continent
that
they're
still
able
to
travel
to
that
continent
during
a
pandemic,
to
bring
something
up
and
that's
a
sort
of
consideration
that
you
may
actually
have
to
think.
Oh
wait
a
minute.
I
What
can
I
continue
operations
during
a
travel
restrictions
and
for
the
dns
sec,
for
instance
the
the
last
year?
They
actually,
as
I
understand
it
last
june,
they
got
the
drills
out
and
they
drilled
open
the
vault
because
they
couldn't
actually
have
all
the
right
people
travel
to
the
to
california
to
resign
the
dnessec
route,
and
so
there
was
a
process
that
I
guess
they
understood
well,
where
they
physically
attacked
themselves.
I
I
guess
on
video,
and
that
happened
so
of
course
the
other
ca
could
have
also
a
split.
That
may
be
a
different
thing:
it
might
have
different
characteristics
as
things
and
that's
part
of
the
goal.
If
we're
going
to
convince
these
reviewers
security
reviewers
that
this
anchor
is
actually
properly
taken
care
of,
then
you
need
to
actually
sit
down
and
go
well.
What
what?
How
is
it
taken
care
of
care
of?
I
And
what
does
that
mean
and
then
there's
a
final
thing
that
you
might
think
about
is:
is
that
the
same
ca
and
it
could
be
and
there's
some
good
reasons
to
make
it
the
same
ca
and
there's
some
good
reasons
to
make
it
a
different
ca
and
all
I
really
want
to
do
with
this
document
and
have
a
manufacturer
say?
Yes,
no,
that's
all
these
are
questions
that
I
want
to
ask,
and
so
really
what
I
want
to
get
in
this
document
is
the.
I
I
I
I
This
this
analysis
wouldn't
apply
to
the
fido
onboarding
system,
but
rather
to
the
qualcomm
implementation
of
the
fido
onboarding
system,
and
so
qualcomm
would
say
what
what
is
their
policy
they
or
what
are
they
doing
and
how
are
they
doing
it
and
they
don't
need
to
tell
us
our
details.
They
don't
need
to
tell
us
the
names
of
the
secret
splitted
people.
That's
completely
uninteresting.
I
I
So
I
think
that's
a
commonality,
so
I
would
think
this
document
needs
to
reference
the
other
document
for
the
the
different
steps
and
the
different
things
that
go
on.
I'm
not
sure
if
there's
references
the
other
direction
that
make
any
sense,
but
if
there
are
then
of
course
we
could
do
them,
but
I
don't.
I
see
them
as
being
related,
but
not
necessarily
co-involved.
I
This
is
my
view
of
the
other
document
right
and
so
I'm
interested
in.
What's
in
the
yellow
box
that
supports
the
rest
of
it,
and
so,
if
you
like,
as
I
said,
think
of
this
as
now
driving
in
the
third
dimension
up
and
down
into
your
screen,
and
what
does
that
mean
for
this?
So
so
I
would
expect
this
kind
of
activity
to
be
mentioned
in
the
first
document
that,
for
instance,
you,
the
a
player
being
a
manufacturer,
may
prepare
an
idev
id
or
some
kind
of
other.
I
Some
cases
are
still
producing
per
customer
skus
with
per
customer
secrets,
for
instance,
and
that's
something
that
can
happen
that
can
be
explained
and
can
be
done
right,
but
that
when
you
want
to
go
details
as
to
what
is
the
manufacturer
actually
doing,
then
that
my
document
is
what
matters
and
it
could
be
that
in
the
bluetooth
mesh,
for
instance,
situation.
Well,
that's
not
an
example
where
the
manufacturer
was
there,
but
the
dpp
situation.
I
So
it
could
be
up
to
this
amount
of
security.
If
the
manufacturer
does
the
most
security
and
it
could
be
the
at
least
the
least
amount
of
security,
if
the
manufacturer
does
the
minimum
amount.
But
if
you
want
to
know
what
amount
the
manufacturer
actually
does,
then
you
need
to
know
you
need
to
ask
the
manufacturer
for
their.
I
And
I'm
not
actually
asking
to
establish
levels
of
security,
I
think
that's
outside
of
the
ietf
and
the
irtf's
view
that
needs
to
be
established
by
somebody
else,
but
in
the
you
just
use
one
one
parameter
levels
of
bits
of
security
right,
and
so
that's
a
that's
a
question
you
can
say
what
is
your?
What
is
your
aes
bit
level
count
and
someone
can
answer
that,
but,
as
we
know,
that's
maybe
completely
meaningless.
If
the
256
bit
key
is
printed
on
the
side
of
the
building
right.
So
that's.
I
C
H
I
can
obviously
volunteer
to
review.
I
joined
the
queue
to
say
that,
if,
if
you're
going
to
adopt
this,
I
think
we'll
need
to
like
obviously
involve
the
ops
people
in
the
ietf
to
look
at
this
and
perhaps
also
like.
If
the
chairs
can
help
like
get
reviews
from
the
actual
manufacturers
and
ceos
to
kind
of
make
sure
that
the
processes
that
that
are
written
in
the
draft
reflect
what
is
happening
in
inside
their
organizations.
I
It
has
been
difficult
to
pull
teeth,
but
I
think
that
with
the
pandemic
waning,
I
think
that
we,
I
will
be
able
to
come
back
and
get
some
more
of
their
time,
so
I've
actually
done
a
lot
of
that
already
in
the
past
year,
and
I
I
in
many
cases
they're
like
I
got
to
think
about
what
I
can
say
and
what
I
can't
say
under
nda
and
that's
what's
actually
taking
them
time.
Is
they
just
can't
walk
into
the
lawyer's
office
and
say
well?
What
can
I
do.
I
C
H
Yeah
I'll
just
kind
of
respond
to
michael,
that's
great
that
you
have
presented,
and
at
least
I'm
not
expecting
them
to
like
write
comments
on
the
list
or
I
don't
know,
review
the
draft
or
anything
like
that.
It's
just
good
to
know
that
they
have
kind
of
seen
your
presentation
and
no
not
to
it
so
kind
of
indicating
that
whatever
is
there
is
correct.
So
that's
that's
what
I
was
looking
for
and
that's
I
think
enough
for
me.
I
C
Yeah,
I
think
that
that's
an
interesting
discussion
how
we
do
we
actually
elicit
this
information.
I
think
in
the
end,
we
will
also
need
to
to
involve
people
who
make
regulations
and
discuss
with
them
what
they
actually
might
be
eliciting
from
from
manufacturers,
so
that
that
might
be
an
interesting
other
part
of
the
conversation.
I
I
was
going
to
say
that
that
that
this
is
why
it's
a
taxonomy,
because
we
not
we're
not,
we,
we
really
don't
want
to
make
a
judgment
about
any
of
the
content.
We
really
want
the
regulators
to
say
and
therefore
this
number
shall
be
at
least
12
or
something
right,
and
our
goal
is
just
to
figure
out
what
is
the
number
12?
Actually,
what
is
what
is
12?
Actually,
what
are
the
units
for
the
number
12?
What
are
the
units
that
12
is
denominated
in
or
whatever
the.