►
From YouTube: IETF-IOTOPS-20221012-1500
Description
IOTOPS meeting session at IETF
2022/10/12 1500
https://datatracker.ietf.org/meeting//proceedings/
B
C
Fine,
a
question
to
the
group
I
uploaded
all
my
slides
to
the
data
tracker:
does
it
do
interims,
do
not
provide
them
through
the
media
call
so
typically
I
find
them
in
Beauty
material.
A
They
do,
you
may
have
to
go
to
settings
to
the
screwdriver
and
I
see
a
wrench,
and
then
you
can
import
them
because
they
they
do.
They
do
their
thing.
15
minutes
before
the
meeting
starts.
Oh.
C
Yeah
I
see
no
interesting.
Okay.
Last
time
I,
probably
my
coach
edited
it
so
I
was
like
cool
they're
already
there.
Let
me
try
to
find
a
close
button
and
to
refresh
this
one
here.
That
did
not
do
the
trick.
C
C
C
But
but
I
don't
see
something
to
accept
yet.
D
A
C
Second,
I
just
successfully
share
the
slide.
I
wonder
if
all
that
worked
out
look
there,
I
I'm
fibing
diabetics
materials,
but
we
can
start
now.
I
think
welcome
everybody
to
the
iot
apps
virtual
interim.
C
We
have
a
overlap
with
the
co-working
group.
That's
due
to
Smart
Share
scheduling.
I
have
supported
up
to
iot
of
chairs,
because
we
can't
distinguish
60
minutes
from
90
minutes
and
now
30
minutes.
Spillover
of
car
are
happening
here
in
iot
oops.
That's
not
a
huge
problem
because
they
think
some
of
the
audience
will
be
the
same.
C
So
this
will
be
recorded.
I'm,
pretty
sure
everybody
knows
the
node.
Well,
this
is
an
official
ietf
meeting,
so
the
movie
applies,
especially
with
a
code
of
conduct
and
copyrights.
Please
read
the
bsps
if
you're
not
familiar
with
them,
also
only
say
things
that
you
think
that
other
people
should
say
to
you
in
the
same
way
so
be
nice,
that's
always
a
good
way
to
treat
each
other.
C
Having
said
that,
we
are
have
a
standard
procedure
here
on
the
I'm
Hank
burkholz
I'm,
your
I'm
one
of
the
co-chairs,
Alexey
minikoff
is
the
other
co-chair,
currently
absent,
but
hopefully
incoming
at
the
bottom
of
the
hour.
We
have
a
zoo,
lib,
formerly
known
as
Japan,
that
at
the
moment
we
have
tulip
if
you
could
have
a
scribe
for
the
chat.
That
would
be
helpful.
If
the
chat
comments
are
there
I
know
we
are
like
with
13
participants.
It's
not
the
biggest
crowd
ever
anybody
here,
volunteering
for
our
minutes
drives.
C
So
this
is
a
Cricut
pause,
but
I,
unfortunately
think
we
can't
really
continue.
Also,
we
can't
really
stress
that
present
us
to
the
minutes,
so
typically
I
would.
C
I
see:
okay,
thank
you.
So
these
were
a
muted
crickets
excellent.
So
you
probably
found
the
media
call
because
you're
here
the
link
is
on
the
slides
also,
and
there
are
some
yeah.
Basically,
all
these
links
can
be
found
on
the
data
tracker
at
the
material
meeting
material
page.
So
we
have
a
agenda
for
today
we
are
in
the
midst
of
the
working
group.
Sorry
of
the
meeting
Ministry
lab.
We
we
settled
with
a
scribe.
C
I
already
highlighted
that
we
have
the
spirit
over
from
core
and
forever
enshrined
here.
Is
that
chairs
are
only
as
smart
as
they
can
get
and
I
don't
know
exactly?
Who
will
be
the
presenter
for
the
core
item
but
we've
scheduled
until
the
bottom
of
the
hour,
plus
maybe
five
minutes
of
the
image
sativa
that
I
just
took
up
so
there's
no
further
Ado
who
will
be
presenting
on
the
constraint
giant
proxy?
Oh,
it's
Michael,
okay,
Michael!
The
floor
is
yours.
A
Yeah
did
the
button
where
I
asked
to
share
work.
I
think
you
have
to
prove
it.
C
A
Okay,
so
I'm
gonna
jump
in
the
middle
of
the
slides
and
use
them
as
as
background
more
than
top
to
bottom.
These
slides
I
did
upgrade
load
them
Hank
if
you
want
to
put
them
in
the
unit
somewhere
but
they're
from
July.
A
So
we
have
the
situation
in
anima
with
our
constraint,
iot
onboarding
process,
where
we
have
a
new
device.
This
is
diagram
is
repeated
twice
here
in
this
page
new
device,
which
we
call
the
pledge
and
it
reaches
out
to
find
a
helper
node
called
a
join
proxy
and
the
join
proxy
is
going
to
transmit
the
traffic
from
this
clear
Network,
which
for
which
there
is
no
encryption.
A
No
access
control
selectively
onto
this
protected
Network
through
potentially
through
other
nodes
in
the
middle
to
what
we
call
a
registrar
or
a
jrc,
join
registrar
and
coordinator
coordinator,
because
it
does
some
other
other
functions
in
the
802
15.4
space
as
well.
A
A
A
We
can
do
this
with
grasp,
which
is
RFC
8990
and
that's
appropriate
for
some
environments
and
inappropriate
for
others.
We
can
do
this
with
mdns
and
that
works
pretty
well
over
here
and
works
less
well
over
here,
where
it's
a
multi-hop
mesh
because
of
of
certain
other
attributes,
but
they
can
be
made
to
work
there
and
we
can
do
it
with
Co-op
resource
Discovery
and
which
essentially,
is
also
multicast
throughout
this
network
and
on
this
network
here.
A
Okay,
so
so
far
so
good,
it
doesn't
sound
like
it's
such
a
big
deal
and
for
the
case
where
this
joined
proxy
is
stateful.
A
It's
not
a
big
deal,
because
the
there's
simply
Discovery
and
the
registrar
announces
itself
and
using
the
typical
Co-op,
well-known
core,
and
it
all
makes
sense.
The
problem
is,
is
that
we
have
a
different
version
of
the
of
the
protocol
from
J
to
R,
which
is
stateless
when
it
runs
over
dtls
RFC
9031
actually
has
a
version
where
it's
pure
Co-op
and
where
the
security,
which
is
OS
core,
actually
runs
above
the
co-op,
and
so
you
can
still
do.
A
You
can
still
use
What's
called
the
co-op
extended
token
to
essentially
store
the
state.
This
guy's
State
as
to
which
p
is
which
in
the
network,
rather
than
in
the
ram
for
the
dtls
case,
we
have
created
a
new
protocol
which
is
a
guess
what
a
UDP
encapsulated
protocol
with
some
co-op
in
the
middle
and
do
I
have
a
diagram.
This
is
what
it
looks
like.
A
We
changed
it
from
some
stuff
over
here
to
some
stuff
over
here,
and
we
basically
have
this
extra
bit
of
of
of
Co-op
B
string,
which
is
this
pledge
context
message,
and
as
long
as
you
send
it
back,
the
register
sends
it
back
to
the
join
proxy
The
Joint
proxy
can
decrypt
it
and
extract
what
was
inside
of
it
and
figure
out
where
the
state
is,
and
that's
all
fine.
A
Okay,
except
for
we
get
into
this
question
of
how
does
the
join
proxy
discover
the
location
of
the
registrar
and
what
is
the
actual
request
so,
prior
to
July,
we
were
going
to
return
this
as
a
co-app
s,
some
funny
port
number
here
and
we
are
going
to
say
this
resource
is
an
rjp
type
thing.
So
this
went
through
the
expert
reviewer,
who
said
well,
that's
not
really
correct,
and
we
don't
really
want
to
do
that
so
now.
A
What
we've
proposed
is
that
this
here
be
replaced
with
a
new
scheme
which
is
Co-op
JPY
and
that
will
register
a
new
scheme.
And
then
you
know
actually
this
doesn't
belong
here
at
all
now
and
you
have
to
ask
for
it
somehow.
So
we
still
get
into
this
question
of
okay.
We've
asked
for
this.
A
Is
this
acceptable
and
or
is
it
still
kind
of
gross,
and
we
should
still
do
something
else
right,
so
those
are
the
choices
that
we
discussed
in
July
and
we
kind
of
well.
We
called
Co-op
JPY
rather
than
just
JPY,
and
so
a
little
bit
we're
here
to
discuss
whether
you
have
another
brilliant
idea
that
we
should
apply
for
that
and
I.
Think
quite
a
few
people
would
not
like
this.
This
item
they'd
like
to
have
a
pure
Co-op
Discovery
mechanism.
A
That
was
the
whole
conversation
that
we're
trying
to
get
the
right
people
in
the
room
to
finalize
whether
we're
okay
with
Karsten.
D
Yeah
before
we
actually
take
the
the
problem,
we
have.
What
was
the
reason
why
why
RFC
8974
is
not
good
enough
for
carrying
this
extra
context.
A
This
RFC
8975
extended
tokens.
Oh
yes,
the
reason
why
we
can't
use
extended
tokens
is
because
the
co-op
layer-
let
me
just
go
back
to
the
diagram,
the
co-op
s
layer-
goes
from
The
Pledge
to
the
registrar.
So
the
joint
proxy
can't
see
it.
It's
embedded
inside
a
dtls
layer.
E
A
A
Okay-
and
you
know
what
that
to
me-
falls
in
the
brilliant,
your
brilliant
idea
here,
and
we
could
do
that
all
right
and
there's
really
not
much
difference
between
to
me
to
putting
a
co-op
layer
there
and
this
JPY
layer
there's
still
some
bytes.
We
have
to
put
in
it's
more
bites,
I!
Think
I,
don't
know
exactly
how
many
probably
at
least
16
I
would
think.
What's
this
minimum
size
of
a
co-op
header.
E
A
Four
bytes,
so
four
bytes,
so
we
could
do
co-op
plus
we
could
use
extended
token
and
put
our
stuff
there.
A
The
advantage
of
also
of
also
meaning
that
we
now
have
a
mechanism
that
we've
already
described
in
9031
to
do
this
and
quite
reasonably
the
code
is
probably
identical
for
a
lot
of
it,
but
at
the
other
end
you
have
one
end
you
at
the
other
end
you
either
do
OS
core
or
you
do.
Dtls
and
we'd
have
to
have
some
way
to
distinguish
what's
happening,
but
I'm
sure
we
can
find
a
co-op
place
to
do
that
in.
D
B
Yeah
I
think
I
just
wanted
to
react
into
the.
Why
not
use
Co-op
so
I
think
for
my
just
mentioned,
but
if
you
use
Co-op,
then
typically
you
would
include
a
URI
as
well
for
that,
so
it
basically
gets
a
lot
much
larger
than
if
you
have
a
particular
well-known
URI.
B
For
example,
you
get
a
lot
of
bytes
extra
and
I
think
the
idea
was
as
small
as
possible
and
the
other
remark
is
that
actually,
in
the
open
thread,
implementation
of
a
mesh
network-
something
similar-
is
used
as
what
we
are
discussing
here
and
there
actually
Co-op
is
used
also
for
the
yeah,
let's
say
the
outer
layer
and
and
it
just
transports
dtls
within
the
payload
in
that
case,
so
that's
also
possible,
but
but
it
was
not
chosen
for
this
particular
documents.
A
B
Yeah,
that's
simply
a
co-op
protocol
with
with
a
particular
URI
path
that
is
predefined
for
this
purpose.
B
So
it's
like,
like
just
plain
Co-op
basically,
and
the
payloads
of
the
co-op
is
yeah
that
contains
then
the
the
data.
That's
the
dtls
data
that
is
being
relayed
through
the
network.
A
So
so
you
know,
we've
changed
a
couple
times
already:
I
don't
have
a
problem
with
changing
again
I
guess,
because
I
don't
have
any
code
written
that
I
have
to
remove
so,
but
to
me
there's
some
advantage
to
doing
whatever
it
is.
That
thread
did
if,
if
it's
easily
reusable
90
31
in
its
mechanism,
sets
the
URI
path
to
J.
A
Okay,
single
letter
URL
with
the
URI
host
option
set
to
sixtish.arpa,
so
I
think
there's
space
in
there
to
define
a
very
short
kind
of
header,
and
we
could
do
exactly
the
same
thing
and
a
uripath
could
set
be
set
to
K
or
whatever
it
is
that
you
know
that
would
definitely
distinguish
the
two
while
allowing
you
know.
Essentially
we
could
reuse
the
same
mechanism
and
then
it
really
would
be
a
co-op
proxy
and
you're
saying
that
thread
is
really
using
it
as
a
co-op
proxy.
A
B
That's
not
the
case.
No,
basically,
it
receives
the
details
and
then
the
basically
join
proxy
creates
a
new
Co-op
message
as
an
endpoint
and
then
sends
it
to
the
registrar.
So
when
the
registrar
sends
something
back
so
there's
not
no
co-op
proxying.
In
that
sense,.
A
No
no,
but
we
would
be
doing
that's
what
sixish
is
doing.
It's
creating
a
new.
Oh
yeah,
it's
not
it's,
not
really!
It's
editing
it
as
it
goes
through
six
yeah
90
31
is
actually
editing
it,
but
in
this
case
we
would
be
the
joint
proxy
would
be
doing
what
thread
is
doing,
which
is
creating
a
new
co-op
layer
to
put
the
dtls
in.
A
D
Are
kind
of
replacing
one
heck
by
another
one,
so
I'm
not
sure
this.
This
is
so
much
better
unless
it's
really
Co-op
that
is
going
going
on.
A
Well,
we
would
be
using
the
extended
token
we
we
would
be
able
to
navigate
through
any
other
Co-op
proxies
that
happen
to
exist,
and
we
would
you
know
so
and
potentially
I'm
saying
what
I'm
seeing
is
that
potentially
you
could
have
a
joint
proxy
that
could
do
thread
could
do
six
Tish
and
could
do
could
to
do
constrained
voucher,
possibly
all
at
the
same
time
right
without
a
lot
of
very
much
code
differences
at
all
for
that.
A
A
So
so
maybe
Esco
Could,
you
perhaps
tell
the
list
what
you
know
point
us
at
the
at
the
thread
mechanism
and
and
see
whether
we're
all
pleased
by
that
and
if
so,
then
it
seems
like
that
might
be
the
right
way
to
go,
because
I
think
that
it
it
devolves
to
what
we
just
said,
which
is
that
really
use
Co-op.
B
Yeah
I
can
certainly
point
to
the
the
source
code
for
that
so
that's
available,
but.
A
A
E
In
particular,
the
the
the
the
the
the
note
could
easily
pick
pick
a
dedicated
quote
and
then
go
with
a
completely
empty
URI
path,
that's
completely
possible,
and
that
would
again
put
it
back
down
to
those
four
bytes
of
difference.
E
Maybe
five
bytes
with
the
extended
token.
But
then
one
of
those
bytes
will
also
be
in
the
Seaboard
representation.
So
are.
A
A
That
sounds
like
a
good
resolution
to
me
and
it
removes
a
custom
part
completely
I.
E
A
E
A
E
The
thing
is,
the
the
we
might
need
to
put
a
few
constraints
on
what
can
be
in
the
discovered
content.
If
we
as
as
I
understand
what
the
pledge
would
now
do
is
the
Pledge
would
send
a
request
would
establish
a
details,
connection
to
Fe
80,
colon
colon
Something
on
the
link
on
the
local
link
yeah,
requiring
of
its
peer
that
dtls
certificates
be
presented
that
make
it
eligible
for
being
a
registrar
and
sending
their
own
certificates.
E
Okay,
yeah.
So
then
the
pledge
sends
a
get
for
well-known
call
to
that
registrar,
and
we
will
then
have
to
require
that
that
register
only
advertise
resources
in
a
relative
fashion,
because
the
Regis
yeah
what
the
registrar
sees,
especially
if
the
registrar
is
distinct
from
the
party
that
undoes
the
the
statelessness.
The
registrar
sees
a
request
to
its
own
IP
address
to
2001
debate,
something
well-known,
well-known
core,
and
it
sends
back
a
response
that
may
or
may
not
encode
its
full
URI
and
if
it
doesn't.
A
A
E
It
has
to
know
that
it's
sitting
behind
a
quote
very
stupid
proxy,
because
it's
not
even
a
proxy,
it's
a
portfolk
order
and
it
has
to
know
that
it's
sitting
behind
a
port
forward.
It.
A
B
Yeah
one
thing
to
keep
in
mind
is
that
what
I
think
happens
right
now
is
that
the
pledge
will
send
just
a
basically
yeah
DT,
less
records
in
UDP
directly
to
the
Joint
proxy.
So
it's
not
encapsulated
in
anything,
not
in
Co-op.
It
isn't
even
Co-op,
it's
just
a
dtls
record
UDP
message
and
then
the
proxy
basically
forwards
that
encapsulated
in
something
and
gets
the
response
back
and
then
sends
it
back
as
a
pure
dtls
record
to
the
pledge.
B
A
There
we're
not
changing
that
part
that
we're
not
changing
that
part.
This.
This
dotted
line
over
here
looks
like
a
co-op
s
and
we're
not
changing
that
it
it
yeah
it.
This
guy
sees
Port,
you
know,
probably
56.83
a
dtls
connection
and
that's
all.
B
Yeah,
that's
that's
good,
but
I
think
what
we
did
not
have.
There
is
yeah
for
the
discovery
part
at
least
we
did
not
advertise
a
particular
resource
here
we
say
only
say:
there's
Co-op
s
and
it's
at
this
joint
port
and
it
has
a
resource
type
and
for
the
rest,
there
do
not
need
to
be
any
resources
in
that
Discovery,
because
the
pledge
already
knows
the
resources
they
are
well
known,
so
they
don't
need
to
be
advertised.
B
A
We
tell
them
I
could
pull
it
up
if
you
want
so
so
I'm
gonna
I'll
write
some
text,
Esco
I'm,
going
to
ask
you
to
review
it
and
we're
gonna
bring
this
to
the
anima
and
core
working
groups
next
week
next
month
and
that'll
be
like
our
you
know,
consensus
this.
You
know
I
hope
well,
it'll,
be
for
final
objections.
Only
the
word
smithing
or
something.
C
So,
thank
you
all
I'm,
going
to
reach
what
we
have
here
on
the
and
this
is
again
I
always
have
to
refresh
apparently
okay,
every
time
refresh
times,
I'm
going
back
to
this
chest
lights,
just
to
show
them
once
again.
C
I
should
be
okay.
This
is
just
very
slow
okay,
so
we
have
been
going
through
that
so
thanks
car
attendees,
for
being
so
patient
with
us
and
thanks
iot
Ops,
then
the
experience
a
patient
with
Corey
for
this
combined
joint
meeting
time.
C
The
next
item
on
the
agenda
is
actually
the
first
item
that
is
a
candidate
for
adoption,
iot
Ops.
We
are
talking
about
a
lot
of
onboarding
mechanisms
in
the
last
year.
We
have
isolated
and
interesting,
Gap
I
think,
and
there
is
one
draft
that
is
currently
illustrating
that
Gap
to
some
extent,
that
could
be
the
basis
for
a
Doctrine.
We
want
to
adopt
and
Foster
an
iot
of
to
make
that
the
first
document
you
can
look
at
and
understand.
C
C
I
can
hear
well,
so
that's
a
good
thing.
No,
that's
not
what
I
want
to
do,
and
this
is
now.
F
Okay,
so
I
have
renamed
this.
The
last
time
that
I
presented
it
Michael
had
some
comments
about
the
name,
so
there
there's
a
new
name
we'll
see
if
that's
any
better
next
slide.
Please.
F
I'm
not
trying
to
define
a
normative
draft.
This
is
essentially
going
to
be
informational,
not
not
normative
requirements,
probably
a
landing
pad
that
the
question
is:
who
is
this
actually
for
next?
Please.
F
So
I
don't
think
that
we're
looking
for
a
a
draft
for
implementers
and
I,
don't
think
that
that
Library
authors
are
going
to
read
this
I
think
they
would
read
the
normative
drafts.
Instead,
some
oems,
which
could
be
implementers
I,
suppose,
will
likely
want
to
know
which
drafts
to
use
how
to
find
the
libraries
they
need
and
find
solutions
to
the
problems
that
they
have
end.
F
Users
are
almost
certainly
not
going
to
look
at
this,
and
operators
might
want
to
know
what
to
ask
oems
for
so,
there
might
be
an
element
of
of
compliance,
checking
from
it
departments,
and
things
like
that
as
well.
Next
slide,
please
well.
F
I
know
that
there
are
varied
opinions
about
Anisa,
but
their
Baseline
security
recommendations
for
iot
is
pretty
good
and
their
take
on
audience.
I
thought
was,
probably
you
know
a
not
a
bad
parallel
to
what
we
probably
need
next
slide.
Please.
F
So
I
think
that
there's
a
gap
in
the
ITF-
and
that
is,
we-
don't
have
a
baseline
security
recommendations.
Draft
at
least
not
that
I've
discovered
there
are
a
lot
of
drafts.
Maybe
I
missed
one
Anisa's
Baseline
is
is
pretty
good
as
I
said,
but
it's
a
bit
old
now
and
there
are
some
some
Modern
threats
that
it
doesn't
address
and
as
a
result,
it
is
missing
remote
attestation
and
confidential
Computing
I
think
those
are
critical
for
the
iot
and
for
the
internet.
F
Moving
forward,
so
I
think
that
those
two
elements
on
their
own
May
well
justify
us
producing
our
own
draft
rather
than
just
referencing
one
that
exists
I
think
we
may
well
need
to
produce
our
our
own.
F
F
There
are
other
documents
that
we
should
review,
but
I
want
to
crowdsource
identification
and
review
of
other
Baseline
requirements.
So
if,
if
you
have
a
particular
one,
you
think
should
be
reviewed,
please
bring
it
to
the
list
next
slide.
F
Please
so
the
ones
that
I'm
aware
of
already
are
the
Anisa,
the
Etsy
and
the
nist
Baseline
recommendation
drafts
I
think
that
there
are
likely
more
out
there
next
slide,
please
so
the
Anisa's
Baseline
document
as
an
example
gives
you
a
sort
of
a
fuzzy,
iot
architecture
and,
and
that
makes
sense
you
don't
want
to
be
too
prescriptive
about
this.
F
It's
more
a
question
of
establishing
terminology
that
we
use
throughout
the
rest
of
it
and
there
are
a
lot
of
standard
setting
organizations
have
an
iot
architecture.
Document
of
some
kind.
I
have
seen
a
few
sort
of
cursory
attempts
at
this
in
the
ietf.
There's,
probably
something
out
of
chord
that
comes
close
to
this,
but
I,
don't
think
I've
spotted
it.
Yet
if
we
don't
have
one
that
would
match
this
kind
of
thing,
we
probably
need
to
either
reference
one
or
produce
one.
F
Next,
so
then,
the
next
thing
is
a
survey
of
common
Assets
in
iot
systems
and
I
mean
this
is
the
foundations
for
building
a
threat
model.
We
need
the
assets
so
that
we
can
build
the
threat
model
there.
There
are
probably
some
pointers
to
methodologies
for
identifying
more
assets,
since
we
can
never
hope
to
have
an
exhaustive
list.
F
What's
really
missing
and,
oh
sorry,
there's
also
risks
and
threats
to
iot
systems
and
the
draft
that
the
the
iot
Nets
draft
that
I've
submitted
is.
It
has
a
lot
of
this
kind
of
content,
common
risks
and
threats
to
iot
systems.
It
doesn't
point
to
methodologies
for
identifying
more
risks
and
threats,
so
maybe
that's
an
area
that
could
be
expanded,
but
what
Anisa's
Baseline
document
is
missing.
F
So
if
we
do
go
through
writing
a
baseline
requirements
document,
we
need
to
convey
that
this
is
all
real
there.
This
is
not
a
thought
experiment
about
things.
That
might
happen.
This
is
what
will
happen.
These
threats
are
real.
They
do
exist
and
they're.
You
know
this.
You
know
there.
This
is
something
that
has
to
be
taken
seriously
Anisa
in
an
attempt
to
make
that
point
backed
up
pretty
much
everything
with
examples
of
real
attacks
and
I.
F
Think
that's
an
interesting
approach,
I'm
not
sure
that's
appropriate
in
the
ietf,
but
it
it
does
make
the
point
pretty
effectively.
On
top
of
that,
there's
also
the
the
move
towards
legislation.
So
there's,
of
course,
the
the
national
cyber
security.
Sorry
National
Security
memorandum
on
cyber
security
that
came
up
not
so
long
ago
and
and
that's
moved
things
forwards
a
bit
and
in
the
UK
there's
the
DCM
masses
call
for
reviews
on
or
sorry
call
for
views
on
the
cons,
consumer
connected
product
cyber
security.
F
That's
it
hasn't
moved
into
legislation
yet,
but
you
know
it
when
the
when
a
government
department
is
exploring
What
legislation
is
needed,
it's
kind
of
a
hint
that
there
might
be
headed
in
that
direction
at
some
point.
So
that
is
another
example
where
legislators
are
are
moving
towards
this
next
slide.
Please.
F
So
Baseline
requirements
are
great.
I've
already
mentioned
we're
missing
pointers
to
technologies
that
provide
those
requirements,
but
there's
always
the
question
of
you
know
if
you
start
with
Baseline
requirements,
I
mean
that's
fine,
but
if
you
want
to
go
the
extra
mile
and
produce
you
know
something
high
security
rather
than
Baseline
security.
F
As
I
mentioned,
we
have
a
threat
to
draft
mapping
in
iot,
Nets
and
I
think
that's
useful,
even
outside
the
context
of
Baseline
security
requirements.
So
that's
that's
my
that's
my
pitch
for
why
we
should
adopt
it.
Even
if
we
don't
produce
a
baseline
security
requirement
document,
it's
still
useful
as
a
threat
to
draft
mapping
and
I
think
that's
still
a
useful
thing
to
do
next
slide.
Please.
F
So
if,
if
I
had
my
ideal
way
that
this
this
working
group
progressed,
I
I
would
expect
that
we
probably
need
a
new
Baseline
recommendation.
Draft
I
think
that
that's
one
of
the
things
that's
missing
in
the
ietf
today.
I
think
that
we
might
need
to
do
a
little
bit
of
architecture.
Terminology
work,
but
that's
that's
it
I'm,
not
sure
about
that.
One
I
I
would
welcome
input.
F
Should
the
question
is:
should
we
adopt
it
and
would
this
work
help
us
to
identify
any
gaps
and
and
produce
an
engine
for
producing
future
work
and
and
areas
of
protocol
to
explore,
since
we
may
not
have
covered
them
yet
there
we
are.
That's
that's
where
I
am
with
the
iot
Nets
Draft
today
and
I
guess.
That's
raises
a
whole
pile
of
questions
so
go
ahead.
A
So
hi
I
guess
what
I'm
hearing
is
that
and
I
haven't
read
the
Anisa
document
but
I'm
hearing
that
this
is
actually
a
kind
of
a
road
map
document
to
the
different
protocols
that
we
have
and
I
think
that's
actually
a
really
useful
thing
and
from
from
an
outsider
looking
into
the
ietf,
you
know
we
have
not
done
our
iot
stuff
in
a
particular
place
and
so
I
think
that's
particularly
useful
to
do
now.
A
This
is
very
much
security
related
and
so,
for
instance,
I
think
that
while
we
think
of
software
update
as
being
a
security
thing,
I
don't
know
that
the
rest
of
the
industry
necessarily
does,
and
so
I
think
that
we
should
think
a
little
bit
about
some
other
pointers.
That
might
we
might
not
think
of
it
as
a
security,
so,
for
instance,
connections
to
some
of
the
elwig
stuff
7228
for
terminology
I'm.
A
Okay,
if
we
produce
a
document
which
essentially
has
a
bunch
of
pointers
to
other
things
as
to
what
is
the
current
state
of
the
art
for
this
and
and
I'm,
also
okay,
if
we,
if
our
document
actually
just
you
know
if
this
Anisa
document
has
really
good
actual
threats,
that
we
assuming
it's
easily
readable,
that
you
know,
we
actually
refer
to
it
directly.
That
would
be
fine
with
me.
F
Yeah
I
think
I'm
quite
happy
to
refer
to
another
document.
If
there's,
if
there's
adequate
content
in
it
I'm,
what
I
am
finding
to
be
a
problem
with
the
Anisa
document
today
is
that
it
is
five
years
old.
Now
it
was
released
in
2017
and
that's
okay,
but
remote
attestation
and
confidential
Computing
hadn't
really
started
to
take
off
at
that
point,
and
the
result
of
that
is
that
they
don't
really
make
mention
of
it
and
I
think
that
moving
forward
is
a
bit
of
a
problem,
because
those
are
foundational
Technologies
now.
F
Sorry,
notwithstanding
that,
there's
still
a
nist
document
that
I
need
to
review
and
an
Etsy
document.
Well,
sorry
that
we
need
to
review
and
an
Etsy
document
that
we
need
to
review
and
maybe
between
the
three
of
them
there's
something
that
is,
you
know
more
complete.
The
Anisa
document
is
reasonably
consumable.
It's
written
in
pretty
plain
language
and
the
difficulty
I
have
with
it
is
that
it
is
a
hundred
pages
long
and
getting
through.
All
of
it
is
time
consuming
and
not
that
we're
going
to
do
better.
C
I
know
so
this
is
hang
I
want
to
want
to
ask
one
question
with
no
hats.
So
would
that
also
acts
that
you
were
mentioning
remote
at
the
station
confidential
Computing
Etc?
Would
that
also
extend
to
a
more
more
broader
Concepts
like
zero
trust
architectures?
Is
that
already
mentioned
in
deniza,
based
on
I.
C
C
If
not
I
think
positioning
some
iitf
work
in
that
I,
don't
want
to
call
it
a
buzzword,
but
let's
call
it
a
domain
of
perception
would
also
be
useful,
but
but
what
I
heard
is
that
they
also
the
the
Nissa
document
is
big
and
and
also
about
readability.
And
one
of
the
chat
comments
here
is
that
well,
the
thread
labeling
like
threat.net.acl.broad
is
also
not
very
readable.
C
I
I
understand
that
there
seems
to
be
some
some
taxonomy
here
in
the
naming
convention,
but
but
I
think
the
the
comments
in
chat
are
are
valid.
So
so
would
you
think
that
addressing
that
kind
of
threat,
taxonomy
in
a
more
readable
way,
would
be
part
of
the
work.
F
Yes,
I
think
that
taking
taking
Michael's
comments
in
his
review
that
he
presented
at
114.,
absolutely
we
need
to
revisit
how
the
iot
Nets
draft
is
is
written.
The
taxonomy
maybe
doesn't
need
to
be
part
of
the
titles,
and-
and
maybe
there
needs
to
be
a
taxonomy
used
separately
or
identified
separately.
F
Maybe
the
taxonomy
is
not
relevant
at
all
and
can
just
be
dropped.
I'm
happy
with
with
whatever
feedback
is,
is
available
on
that.
My
inclination
was
to
leave
some
feedback-
sorry
some
taxonomy
in
there,
so
that
we
can
sort
of
think
about
what
applies
to
networks.
What
applies
to
end
devices?
You
know
which,
which
libraries
are
threats
relevant
against
things
like
that,
so
I
can
see
why
there
might
be
some
need
to
to
refine
that
a
bit
I
just
haven't
done
that
work.
Yet.
C
And
that
could
be
working
group
work,
so
everybody
who's
here
in
the
room
I
would
like
to
pose
another
question.
What
I
heard
is
we
have
two
things?
Actually
we
have
the
threat
model
that
that
that's
kind
of
generic,
and
probably
we
can.
We
don't
have
to
start
at
zero
with
that,
and
then
we
have
the
Baseline
document
that
would
refer
to
the
ietf
building
blocks.
C
So
do
you
brand?
Would
you
Envision
this
as
as
one
document,
or
would
it
be
better
to
disentangle
that,
maybe
because,
if
you
would
drop
our
own
taxonomy,
we
could
just
inherit
it
from
somewhere
else
so
and
that
would
that
work
would
reside
in
a
non-published
ID
in
the
end,
where
we
experiment
with
that
and
the
Baseline
draft
is
basically
the
the
intended
output
that
was
is
more
more
set
in
stone,
more
more
guaranteed.
Is
that
a
way
forward,
or
how
would
you
assume
that
would
work
out.
F
I
I
don't
have
any
assumptions
on
that.
I
think
that
it
would
be
I
mean
I'm
happy
with
whatever
the
it
is,
the
the
best
result
for
the
working
group-
I'm,
not
you
know,
tied
to
making
sure
this
is
adopted.
As
long
as
the
the
mapping
comes
out,
I
think
that
the
mapping
is
the
important
part.
F
And
the
Baseline
security
recommendations
are
probably
important
too,
but
there
are
a
few
copies
of
those
already
floating
around
in
Industry
I.
Think
it's
useful
for
us
to
to
have
a
bit
of
ietf,
specific
recommendation
and
I.
Think
the
other
thing
is
that
the
you
know
a
lot
of
them.
We're
not
sitting
still
and
a
lot
of
the
other
ones
are
fairly
static.
They
haven't
been
updated
in
the
last
no.
F
However
many
years,
I
think
that
if
substantial
new
Technologies
come
out
in
the
ietf
I
suspect
we
will
update
this
so
I
see
the
the
you
know
the
prospect
of
being
a
semi-living
document
being
useful.
G
Good
morning,
good
afternoon,
good
evening
to
some
I
agree
with
Brendan
that
this
is
going
to
be
a
living
document
and
to
prove
the
point.
I
don't
know
about
this
idea,
but
probably
next
to
ITF
we'll
be
introducing
some
capability
into
skim
for
doing
iot,
onboarding,
specifically
device
onboarding,
so
I
expect
it
would
join
the
list.
G
So
I
like
the
idea
of
a
living,
a
living
document,
whether
that's
a
draft
a
web
page
or
what
have
you
I,
don't
have
a
particularly
strong
view,
but
I
think
we
should
keep
in
mind.
They're
going
Brendan's
points
exactly
correct.
So
when
we
talk
about
provisioning
there,
for
instance,
while
there's
work
going
on
in
the
ietf
and
EST
we've
already
done.
G
Work
in
enu
for
this
in
two
different
forms
that
we
might
want
to
listen
to,
and
one
of
which
is
Noob
and
the
other
watch
is
tip
tip-
has
the
same
provisioning
functions
as
EST.
Only
at
L2,
the
only
difference
being
everybody
actually
wrote.
The
darn
code,
which
is
sort
of
annoying
the
crap
out
of
me
in
terms
of
provision
I'm
gonna,
go
fix
that
and
then
probably
come
up
with
an
updated
on
that.
G
C
So
I
know
that
we
are
now
relatively
small
subset
of
the
typical
iitfinity
group,
but
just
just
to
to
help
me
a
little
bit
see
chair
to
to
assess
the
room.
I
tried
to
phrase
a
raised
hand
thing
and-
and
that
is
absolutely
of
course,
first
of
all-
not
binding
of
Representative
just
to
get
a
feeling
for
the
for
the
virtual
room
here,
I
would
press
the
start.
Essentially
I
edited
this
twice.
So
probably
there's
a
spelling
error
now
in
that
I'll
try
to
to
raise
hand.
C
If,
because
sometimes
it's
really
not
easy
to
understand
when
you
want
to
have
a
razor
hand,
so
foreign
I
will
not
be
able
to
see
anything
I.
Think
of
until
oh
I've
had
scroll
down.
I
can
see
something
okay,
yeah
I'm,
using
this
from
a
tablet.
Sharing
from
a
tablet
is
an
interesting
experience.
I
can
tell
everybody
who
wants
to
share
and
meet
Echo,
maybe
don't.
C
D
In
the
English
sense,
but
when
I
buy
a
roadmap
in
in
a
store
that
usually
does
not
tell
me
how
the
the
roads
will
look
like
in
10
years
that
they
showed
the
rules
right.
Oh.
D
A
A
C
I
I
think
so
too
so
I
think
the
the
the
two
takeaways
that
we
have
here
is
that,
yes,
we
should
talk
about
this.
Definitely
there
is
some
value
perceived
in
the
subset
of
attendees
here
so
Brandon.
C
That
unfortunately
means
a
few
action
items.
Aka
work.
Could
you
please
recap
the
threat
model,
Baseline
mapping
items
on
the
list
in
the
concise
message
so
that
we
can
then
talk
about
and
then
ask
basically
for
adoption.
So
we
can
have
a
discussion
on
an
adoption
call
before
I.
Don't
know
if
we
can
do
an
adoption
call
before
the
idea
actually,
but
but
we
could
start
one
in
in
and
so
that
we
can
have
a
healthy
discussion
on
the
list
before
then.
Would
that
be
comfortable?
C
F
Is
to
make
the
point
that
the
the
draft
I've
written
is
a
starting
point
for
a
map
of
a
map
of
threats
and
use
cases
to
ietf
drafts
that
deal
with
them
and
that's
useful.
And
we
should
adopt
that.
C
Yes,
no
so
yeah.
That
would
be
the
minimal
thing
to
do,
but
I
think
that's
not
what
we
want
to
work
on
only
as
as
far
as
I
understood
it
now
so
I
think
the
the
work
is
to
to
use
the
example
to
provided
for
Baseline
documents
from
in
east
side.
C
Cnist
I
have
remember
correctly
and
and
I
understand
what
their
structure
is
to
to
condense
them
down
into
either
our
own
translated
threat
model
or
a
referenced,
a
reference
system
to
their
threat
models
and
and
taxonomies,
and
then
do
the
mapping
to
the
iatf
building
blocks,
which
ultimately
would
steer
also
in
future
work,
because
some
things
might
not
be
mappable
and
expose
gaps
and
and
items
that
we
want
to
work
on.
So,
but
that's
that's
my
my
some
here.
Would
you
agree
with
that?.
F
C
F
So
I
I
think
that
this
is
I,
think
I
would
prefer
to
adopt
first
and
then
you
know
gather
a
few
more
authors
and
and
see
what
we
can
do
at
that
point,
that
that
would
be
my
preference.
If
that's
not
what's
going
to
happen,
that's
okay,
I'll
I'll
do
my
best,
but
I'm
not
sure
that
I
can
get
like
not
sure
that
I
can
do
a
good
treatment
of
all
three
of
those
documents
in
the
time
available
before
the
submission
deadline.
C
Oh,
no,
not
the
submission
deadline
that
that
is
not
the
problem,
so
I
think
the
the
important
thing
here
is
to
discuss
this
until
and
and
and
in
London
we're
not
under
any
pressure
of
of
having
an
adoption
call
here.
I
think
the
more
important
thing
is
to
have
a
healthy
discussion
so
that
people
aware
of
this
and
then
have
a
good
meeting
session
and
from
that
point
on
I
think
adoption
can
be
steered
pretty
easily.
C
So
that
would
be
my
recommendation
and
but
I
would
always
highlight
if
you
put
something
to
the
list,
that
we
are
planning
for
adoption
and
that
the
last
interim
there
was
a
12
to
2
hand-raised
thing
that
will
be
in
the
minutes.
I'll
refer
to
the
minutes.
That
is,
it
seems
to
be
a
good
idea.
That's
why
we
are
now
pondering
that
plan.
D
So
when
we
adopt
something
automatically,
your
message
is
sent
to
a
new
work,
mailing
list
that
goes
to
other
sdos
and
so
on
and
I
think
that
we
should
really
think
about
this.
This
the
gating
function
of
adoption
here,
as
as
a
way
to
indicate
to
other
people
that
this
work
is
being
started
and
that
the
igf
is
interested
in
in
getting
some
some
work
done
there.
D
So
I
I
wouldn't
wait
until
the
the
document
is
super
wonderful,
of
course,
if
the
the
document
is
misleading
to
stos
as
to
what
kind
of
work
we
are
trying
to
do
here,
that's
also
not
good,
but
we
we
shouldn't
fine
tune.
The
document
repeatedly
until
we
finally
adopt
it
fine-tuning
is,
is
for
for
working
group
work.
C
Yeah
so
Carson,
would
you
have
an
opinion
on
the
time
of
adoption,
call,
because
personally,
I
would
feel
more
comfortable
with
having
this
agreed
on
a
second
basically
at
the
at
the
meeting,
while
having
the
discussion
on
the
list
until
the
meeting,
which
is
probably
like
a
month
or
something,
and
so
so.
What
would
that
sound
like
a
good
time
frame
for
our
discussion
and
then
call
it
well.
D
We're
having
a
meeting
so
I
think
we
we
have
all
we
need
to
to
decide
here.
What
we
don't
have
is
a
version
of
the
document
that
really
announces
the
the
direction
we
seem
to
be
picking
up.
So
what
I
think
we
really
want
is
a
new
revision
of
that
document
that
that
doesn't
magically
do
all
the
work,
that's
of
course
impossible,
but
that
is
more
indicative
as
to
what
what
we
are
now
trying
to
achieve
with
this
document
and
I
I.
D
What
optimistically
think
that
this
actually
can
be
done
before
the
24th,
so
that
would
be
a
great
basis
for
actually
starting
an
adoption
call
before
IHF.
Then
we
can
still
discuss
the
results
of
that
call
at
iitf,
excellent.
C
Okay,
so
Brenton
I
see
some
support
on
the
chats,
so
maybe
have
a
look
at
that.
So
you're
not
alone
and
I
also
think
that
other
participants
here
will
comment
and
contribute.
So
would
you
be
comfortable
to
trying
to
remold
the
existing
ID
to
capture
the
goals,
at
least
the
the
the
the
path
forward
before
they
cut
off
and
because
24th,
by
the
way
in
October,
is
cut
off
day?
So
that's
why
this
is
the
deadline.
Yes,.
F
So
I
think
that
I
could
sort
of
restructure
the
document
a
little
bit
to
say
these
are
some
of
the
Baseline
security
documents
that
already
exist,
and
but
they
don't
tell
us
which
Technologies
to
use
to
fill
these
gaps.
Here
are
a
list
of
technologies
that
fill
some
of
the
gaps
and,
and
maybe
that
will
help
us
find
some
of
the
missing
bits
as
well.
I
think
I
could
probably
do
that
reasonably
easily.
We
can
sort
of
Park
the
threat
model
that
I
put
in
there
for
the
moment.
F
If
we're
taking
that
approach,
because
I'm
not
sure
how
much
it
overlaps
with
what's
already
there,
and
then
that
could
be
a
question
perhaps
that
winds
up
in
a
different
document
in
the
future.
That's
fine.
C
Okay,
because
I
think
getting
help
and
and
getting
this
more
visible,
GitHub
would
help
yes
and
and
and
and
and
and
just
not
only
just
highlighting
the
goals
that
you
have
with
the
IDE
would
help
people
here
in
the
chat
to
to
maybe
on
board
with
that
work
and
and
then
have
you
I'm
getting
the
the
initial
stuff
done
for
for
the
cut
off
date
and
Michael,
no
I,
don't
think
we
have
a
GitHub
organization.
C
Yet
that's
an
excellent
point
because
we
don't
written,
have
had
documents
yet
I
think
so.
I
would
initially
would
put
that
in
the
in
the
GitHub
in
the
in
the
individual
realm
of
of
of
participants
here,
but
I
can
also
in
parallel,
find
out
how
to
get
the
IIT
Ops
iot
apps
GitHub
organization.
C
Okay,
so
are
there
any
more
comments
on
the
plan
or
are
there
like
say
concerns
the
way
forward?
We
just
highlighted
here.
C
If
that
is
not
the
case,
I
can
give
you
a
lot
of
all
respect,
because
I
think
we
discussed
agenda
item
two
or
three
also
now,
which
is
oh
there's
Michael
in
the
queue.
C
Yeah
we
did
that
in
the
case
of
that
we
reported
through
the
IDS,
but
we
did
not
create
a
document
for
that.
But
I
think
this
activity
right
now
could
be
an
update
to
that
and
we
can.
We
could
phrase
it
in
an
document
format,
but
we
did
not
write
an
ID
based
LED
framed
report
the
last
time.
So
so
that's
that's
something
but
I
think
you're
correct
this
activity
on
the
list
could
be.
We
could
summarize,
as
chairs
for
the
isg
again.
C
But
I
think
there's
no,
how
you
call
it
there's
no
template
for
that,
because
I
think
that
that's
not
been
done
before
I'm.
Looking
at
the
check
right.
C
C
Well,
we
we
we,
we
were
the
last
ITF
meeting.
We
had
a
at
least
Alexa
and
I.
What
was
the
the
80s
but
lxa
might
have
something
to
say
about
that.
Also
yeah
I
think
we
need
to
check
with
our
AG
that
yeah,
but
the
last.
C
Positive,
so
yeah
I
didn't
think
we
we
need
to
write
something
but
I,
don't
think.
We've
had
much
Cycles
to
actually
do
anything
yeah,
but
but
yeah.
Absolutely
that's
a
good
point
to
be
transparent.
On
reporting
about
this
is
fine,
but
but
to
some
extent,
all
the
recordings
minutes
and
and
threat,
and
that
visible
list
activity
is.
Is
this
report
to
some
extent,
but
we
can.
We
can
provide
a
summary
and-
and
we
could
provide
it
in
a
written
form,
but
but
what
exactly
format
it
is?
C
C
And
thank
you.
Brandon
I
was
looking
at
the
chat
for
getting
a
GitHub
repo
for
that
individual
ID
started
again.
In
parallel,
we
will
check
for
creation
of
an
iot
Ops
GitHub
organization.
A
C
Doing
once
going
twice,
that's
not
the
case.
We
can
give
you
a
lot
of
time
back.
We
have
a
few
action
items
done.
We
will
continue
the
discussion
on
the
list
and
thank
you
for
attending.