►
From YouTube: IOTOPS WG Interim Meeting, 2021-04-20
Description
IOTOPS WG Interim Meeting, 2021-04-20
A
B
D
Okay,
so
welcome
everybody.
This
is
the
interesting
starting
virtual
interim
for
the
iot
operations
working
group
and
I'm
welcoming
everybody
here.
This
is
the
first
virtual
inventory
meeting.
We
have
four
presentations
for
today
and
please
note,
as
you
probably
or
heard
right
now,
though,
this
meeting
is
being
recorded
next
slide,
so
we
have
the
notebill.
I
hope
everybody
is
familiar
with
it.
D
D
D
D
B
E
D
E
D
C
No,
I
I
can
go
ahead
and
start
for
a
ahead
of
time.
It
would.
It
would
have
been
nice
to
to
follow
carson,
but
but
there's
no,
no
reason.
I
can't
go
ahead
and
start
now,
so
so
so
I
actually,
as
you
probably
can
tell-
I
am
not
paul
wotrowski
or
susan
simmington.
They
are
actually
the
experts
on
our
team
of
on
this
this
project,
but
for
various
reasons
it
this
one,
you
you're
stuck
with
me
today.
C
What
I
would
like
to
talk
to
you
is
to
you
all
about
is
a
project.
That's
been
going
on
at
a
small
component
of
nist
called
the
national
cyber
security
center
of
excellence
or
nccoe,
where
we
work
very
collaboratively
with
industry
to
do
demonstration
projects
to
try
to
accelerate
the
adoption
of
security
technologies.
C
C
C
C
I
want
to
say,
unlike
a
lot
of
the
talks,
that
you're
going
to
get
here,
there
is
no
internet
draft.
We
haven't
submitted
this
as
an
internet
draft
and
we
don't
really
plan
to
we're
hoping
that
you
know
we've
done
a
lot
of
legwork
here
and
that
you'll
find
this
work
useful
and
just
use
it.
It
is
important
to
us
to
stay
aligned,
and
so
you
know
we
hope
people
will
read
it
and
let
us
know
if
you
perceive
any
conflicts
next,
please.
C
So
we
see
trusted
layer,
network
layer,
onboarding,
where
this
is
what
our
term
is
for
a
specific
component
of
this.
We
see
this
is
really
crucial,
both
to
protect
the
devices
from
being
taken
over
by
the
wrong
networks
and
to
protect
networks
from
having
devices
connect
up
that
really
shouldn't
be
there.
But
more
than
that,
we
see
this
as
important
for
the
rest
of
the
life
cycle.
C
C
I
think
you're,
familiar
probably
with
with
some
of
the
different
pieces
and
others
will
get
talked
about
today,
a
lot
of
different
projects
and
various
sdos
on
onboarding
solutions,
the
characteristics
and
the
capabilities
they're
different,
and
so
we
ended
up
where
we
were
trying
to
compare
apples
and
oranges,
and
we
felt
we
needed.
We
needed
something.
We
needed
a
common,
a
set
of
words.
We
needed
a
common
framework
to
be
able
to
say.
C
Oh,
this
onboarding
solution
provides
this
feature
this
on
another
onboarding
solution.
Does
not
you
also
you'll
see
we
talk
about
trust
trusted
onboarding,
we're
very
focused
on
what
are
the
security
characteristics
that
you're
going
to
get
from
this
this
from
from
onboarding?
If
you
invest
in
it
next
slide,
please.
C
So
there
is
an
88-page
paper
online
on
the
url
here.
Also
there's
a
slide
at
the
end
that
has
all
of
the
urls
again,
but
we
developed
this
paper
88
pages.
It
goes
through
onboarding
and
sort
of
what
is
it
generically?
What
does
it
mean?
What
are
the
the
functional
roles
that
have
to
be
implemented?
What
it?
How
does
it
fit
into
the
greater
life
cycle
of
these
devices?
C
We
look
at
it
from
the
user
point
of
view,
the
manufacturer's
point
of
view,
the
service
provider.
We
we
do,
recommend
a
set
of
security
capabilities.
So
there's
a
lot
of
material
in
here
in
my
15
minutes,
I'm
not
even
going
to
attempt
to
go
through
all
of
it.
I
just
wanted.
You
have
an
idea
of
what
the
landscape
is
next
slide
please.
C
That
is
more
about
now
that
I
have
the
device
on
board.
If
it's
changing,
if
it
would,
how
do
I
provision
new
applications,
new
software?
How
do
I
add
new
capabilities
and
make
all
of
this
work,
and
all
of
this
also
then
comes
around
too
to
other
parts
of
lifecycle
management
like
how
do
I
transfer
ownership
of
the
device?
C
C
Next
slide,
please
one
of
the
really
interesting
things
that
we
cover
in
our
document.
That
is
a
little
different,
I
think,
is
that
we
cover
what
we're
calling
the
supply
chain
phase
of
onboarding,
because
our
focus
is
working
with
with
vendors
with
developers
to
demonstrate
these
new.
These
new
technologies,
part
of
what
we
want
to
be
able
to
do
at
the
end,
is
say
if
you
want
to
support
this
technology
in
your
products.
C
What
are
the
things
that
you
need
to
do
so
the
supply
chain
phase-
and
you
know
this-
is
a
different
use
of
the
worst
supply
word
supply
chain.
I
I
don't
know
that
that
was
our
best
decision,
but
what
we're
really
saying
is
all
of
the
tasks
that
have
to
happen
to
make
devices
ready
to
bring
on
to
the
network
to
use
to
achieve
trusted.
Onboarding,
there's
a
lot
of
materials
that
need
to
be
built
into
the
sys
installed
on
the
system.
C
C
The
second
is
the
world
of
use.
If
you're
going
once
the
supply
chain
is
done
and
a
device
has
been
transferred
to
its
first
owner.
What
what
are
the
onboarding
things
that
may
happen?
You
know
both
at
network
layer
and
at
the
application
layer.
We
want
to
be
able
to
cover.
You
know:
maintenance,
repurposing,
resale,
periodic
refresh.
C
C
Please
we
go
because
we're
looking
at
trusted.
We
national
cyber
security
center
of
excellence.
We
are
security,
focused,
so
there's
a
lot
of
security
characteristics
that
we
wanted
to
define
wanted
to
identify.
Some
of
these.
We
consider
to
be
mandatory.
Others
we
consider
to
be
a
requirement
for
certain
kinds
of
downstream
features.
You
know.
Are
we
preparing
to
do
other
things
during
the
life
cycle?
C
C
C
So,
for
your
point
of
view,
some
of
the
things
that
I've
left
out,
because,
frankly,
as
a
security
guy,
they're
less
interesting
to
me,
they
may
turn
out
to
be
very
important
in
your
group.
So
now,
back
to
the
next
slide,
I
think
everybody
knows
there's
really
kind
of
a
dichotomy
with
a
lot
of
iot
devices.
C
The
world
is
different
for
installing
and
maintaining
thermostats
in
my
home
and
a
thermostatic
nist.
The
kinds
of
capabilities
that
are
required,
or
that
are
important,
may
be
very
different.
You
know
you
really
can't
expect
the
home
user
to
go
through
a
lot
of
training
to
put
in
their
new
thermostat,
where
the
folks
that
do
the
installation
at
nist,
because
they're
doing
lots
of
buildings.
C
That
may
be
just
fine
if
they
have
to
do
some
training
to
really
be
able
to
do
it.
There's
a
lot
of
differences
in
how
these
things
work,
and
actually
it
really
affects
onboarding
as
well.
So
we
tried
to
go
through
all
of
that
in
the
document
as
well.
Next
piece
next
slide
so
kind
of
came
at
this
backwards,
because
actually,
in
some
ways
this
slide
should
have
been
first.
C
Why
am
I
here?
Why
am
I
giving
this
presentation
of
some
of
our
partners
that
are
involved
in
this
group
pointed
out
that
the
group
has
been
looking
at
things
like
2t
trg,
secure,
bootstrapping
and
they
said
hey.
You
know
you
guys
have
put
in
a
lot
of
leg
work.
We
have
one
set
of
words
that
we've
sort
of
agreed
upon
using
when
we're
working
with
the
nccoe,
maybe
they'd,
be
valuable
to
the
iot.
Ops
group
certainly
would
like
if
they
need
them
to
be
using
the
same
words.
C
Why
don't
you
come
in
and
talk
about
this
a
little
bit
so
we
went
back
and
we
looked,
and
I
did
over
the
weekend,
take
a
little
bit
of
time.
Looking
at
t2
trg,
secure,
bootstrapping.
One
thing
is:
that's
a
very
nice
clear
document.
The
scope
is
smaller
than
ours,
but
much
easier
to
handle
than
than
than
the
88
pager
that
we've
dropped
on
the
world.
Part
of
it
is
scope.
The
t2
trg
document,
in
my
opinion,
really
looks
at
the
options
for
what
we're
calling
network
layer
onboarding.
C
My
first
observation
would
be
that
my
second
observation
would
be
that
the
recommendations,
the
core
recommendations
in
the
t2
trg
document
on
the
use
of
the
fir,
the
words
bootstrapping
and
the
provisioning
configuring
they're,
actually
pretty
consistent
consistent
with
what
we've
called
provisioning
and
bootstrapping,
and
I
was
actually
really
relieved
to
find
there's
some
commonality
in
some
of
the
core
areas.
So
I
don't
think
that
you
know
once
I've
come
back
in
and
looked
that,
there's
anything
immediately
broken
between
us
and
the
the
t2
trg.
C
No
other
people
may
read
that,
and,
and
tell
me
things
are
a
little
different,
but
that
was
my
initial
feedback
on
this.
The
document
goals
are
pretty
different.
That
document
is
pretty
agnostic
about
really.
What
does
it
mean
to
do?
Secure,
bootstrapping,
where
we
felt
we
had
to
for
our
own
purposes?
C
We
had
to
establish
requirements,
and
that
meant
that
there
are
some
more
features
of
onboarding
that
we
specifically
talk
about
and
so
that
that's
kind
of
an
interesting
piece.
We
do
look
at
a
bigger
scope,
a
more
generic
model
with
we
have.
You
know
things
like
16
functional
roles,
which
I
didn't
list
here.
C
We've
got
a
robust
list
of
characteristics
for
security
and
not
that
go
throughout
the
life
cycle.
I
guess
from
my
point
of
view.
What
I
would
want
to
say
is
for
this
group
if,
in
fact,
you
find
those
if,
if
there
are
more
pieces,
that
you'd
like
in
this
group,
to
have
a
common
set
of
language
on
beyond
what
the
secure
bootstrapping
document
has,
we
hope
that
you
will
look
at
our
document
as
at
least
one
source
for
actually
getting
that
material.
C
We
are
going
to
be
working
with
vendors
on
a
number
of
the
different
protocols
that
actually
are
described
in
the
secure
bootstrapping
paper
and
we're
gonna
be
looking
both
at
the
the
network
layer
onboarding,
but
also
at
what
other
capabilities
we
can
integrate
so
that
we
can
actually
secure
that
full
device
like
cycle.
As
we
talk
about
in
our
document.
So
can
we
do
application
layer
onboarding?
Can
we
leverage
mud
and
make
it
make
mud
stronger
because
of
the
onboarding?
C
C
This
is
our
usual
plan
on
where
we
are
in
the
project
timeline.
We
are
just
getting
ready
to
really
form
teams.
So
if
you
are
a
vendor
who
produces
products
in
this
space
and
you're
interested
in
working
with
us,
please
keep
an
eye
out
for
work
from
at
the
nccoe,
where
we're
gonna,
publish
a
federal
register
notice,
we'll
be
able
to
form
some
teams
and
we're
gonna
do
demonstration
projects
over
the
next
12
months
or
so
where
we
hope
to
prove
that
this
technology
really
works
next
slide.
Please.
C
So
I
know
that
I've
used
up
my
time
and
we're
gonna
have
question
time
later,
but
we,
we
certainly
are
interested
in
everyone's
feedback.
You
can
send
follow-up
email.
If
I
don't,
if
we
don't
get
to
answer
your
question
later
in
the
session
and
next
slide,
so
the
meeting
materials
will
have
if
you,
if
you
go
to
the
meeting
materials
and
download
these
slides,
it
has,
I
think,
all
the
urls
that
you
will
really
need
if
you
want
to
follow
up
on
this
work.
F
D
C
D
G
G
G
It
looks
good
to
me,
okay,
good
yeah,
so
we
we
are.
We
do
have
ongoing
discussions
in
in
the
thinking
research
group
about
how
to
address
this
field.
So
the
the
document
from
mohit
that
that
tim
briefly
talked
about
is
is
a
work
in
progress.
So
it's
an
interesting
snapshot,
but
it
certainly
will
move
forward
and
the
the
term
that
we
seem
to
be
converging
on
is
really
initial
security
setup,
because
bootstrapping
is
just
one
of
the
many
terms.
G
But
in
the
end,
this
is
all
about
the
fact
that
when
iot
environments
are
being
set
up,
things
or
devices
need
to
be
set
up
as
well.
They
they
need
to
know
their
purpose
in
life,
which
is
really
the
the
most
important
part
and,
of
course
they
need
to
know
all
about
how
to
to
fulfill
their
purpose
in
life
in
a
secure
way
and
on
the
other
hand,
the
environment
in
which
these
devices
are
put.
G
One
is
what
what
are
actually
the
the
parties.
What
are
the
players
that
need
to
know
something
and
perform
their
their
work
in
a
secure
way
and
that
there
are
parties
that
are
only
relevant
during
set
up
and
and
not
during
operation,
and
there
are
others
that
are
only
relevant
during
operation,
not
doing
setup,
and
there
are
some
that
are
both.
G
So
what
we
want
to
do
is
go
a
little
bit
from
the
the
phenomenology
that
we
have
at
the
moment.
So
we
can
look
at
a
number
of
setup
mechanisms
and
try
to
to
derive
their
properties
by
describing
them
to
an
actual
taxonomy.
So
we
have
terms
for
the
various
approaches
and
results
and
can
describe
the
setup
mechanisms
in
those
terms.
G
G
We
can
also
talk
about
owners
and
controllers
of
the
device
and
of
course,
we
have
all
identified
that
there
is
probably
something
like
an
owner
and
probably
something
like
a
manufacturer,
and
these
are
two
to
identifiable
roles
that
need
to
interact
with
the
device
and
we
have
additional
roles
like
facilitators
and
so
on.
That
also
need
to
be
part
of
the
model,
so
that
that's
the
first
part
and
and
next
slide.
G
G
G
Yet
so
there
are
authorizations
that
allow
the
device
to
do
something.
That's
actually
often
forgotten.
The
the
owner
of
the
device
has
certain
plans
with
the
device
and
the
the
owner
needs
to
to
indicate
their
authorization
information
to
the
device.
So
the
owner
tells
the
device
hey,
there's
this
network
over
there
and
you
are
authorized
to
join
that
network.
G
So
it
usually
does
that
in
a
complicated
way
that
we
described
by
onboarding,
but
but,
in
the
end
it's
the
authorization.
That
is
part
of
the
belief
that
is
institut
so
at
the
end
of
the
setup
process,
the
device
a
believes
that
its
owner
allows
it
to
to
use
a
particular
network
or
to
do
some
other
x.
G
So
this
is
a
little
bit
complicated,
but
that's
the
nature
of
the
authorizations
that
they
have
these
three
different
components
and,
of
course
there
are
also
specific
authorizations
on
a
device.
So
device
aim
might
allow
hold
off
an
edit
to
be
to
do
z.
So
these
are
really
the
beliefs
that
should
be
the
the
result
of
the
initial
security
set
up,
and
it
would
be
great
if
we
had
a
better
way
to
describe
these
beliefs
in
in
a
way
that
transcends
different
terminology
systems
next
slide.
G
So
the
the
the
might
zones
that
we
usually
talk
about
are
network
onboarding
platform
on
boarding
and
application
onboarding.
Sometimes
you
don't
need
application
onboarding,
because
the
application
never
actually
talks
to
the
device,
but
talks
to
the
platform.
In
that
case,
you
just
have
a
platform
on
boarding
yeah
and
the
fun
part,
of
course,
is
that
network
and
onboarding
requires
a
network.
G
We
don't
have
a
accidentally
exceedingly
good
term
for
that
we
call
it
overseeing
principles.
Sometimes,
let's
call
it
owner
for
now,
even
though
it's
very
clear
that
the
overseeing
principle
is
not
always
the
legal
owner
of
the
device,
and
then
we
have
an
original
owner,
which
we
sometimes
call
manufacturer,
even
though
it's
becoming
much
less
likely
that
the
original
owner
actually
is
the
manufacturer.
G
And
here
again
we
have
lots
of
interesting
milestones,
the
two
of
which
require
some
some
very
specific
thinking.
One
is
the
ownership
transfer,
which
is
a
little
bit
of
a
euphemism,
because
it's
not
actually
happening
in
most
cases,
so
the
the
new
owner
gains
some
control.
The
original
owner
also
retains
some
control,
and
also
authorizations
that
had
been
issued
to
the
device
remain
in
place
or
parts
of
them
remain
in
place
and
the
other
important
milestone
is
the
software
update,
and
then
we
have
a
whole
working
group
working
with
that.
G
G
G
G
But,
as
I
said,
the
very
important
aspect
is
who
controls
what
and
which
pairs
or
groups
of
players
are
under
the
same
ownership
or
control.
So,
for
instance,
for
instance,
if
manufacturer
and
platform
are
under
the
same
ownership
or
at
least
share
some
control.
So,
for
instance,
the
manufacturer
has
contracted
the
the
platform
to
provide
the
platform
services
that
enables
some
back
channel
processes,
for
instance,
pre-authorization
processes
that
are
important
to
to
describe
in
in
the
description
of
the
setup
process.
G
Another
interesting
question
is:
which
of
these
players
are
being
swapped
in
and
out
in
regular
use.
So
where
do
we
actually
have
to
have
processes
that
go
beyond
the
initial
setup
and
and
repeat
some
of
the
installation
of
authorization
information
so,
for
instance,
when
a
device
moves
between
networks
that
that
becomes
interesting
or
when
a
device
actually
operates
with
multiple
setting
up?
Another
application
may
require
to
do
some
setup
and
one
one
last
interesting.
Flavor
is
whether
physical
access
implies
full
authorization
or
what?
G
G
So
I
don't
know
how
how
useful
this
will
be
for
iot
ops.
It's
it's
probably
a
slightly
more
long-term
view
at
this,
a
more
researchy
view,
but
if
we
manage
to
pull
this
off,
I
think
it
will
be
very
useful
to
to
understand
all
these
specifications
and
proposals
that
are
out
there,
and
so
we
can
describe
a
new
proposal
as
that
uses
flavor
x
and
then
processes,
y
z
and
a
and
then
everybody
knows
what
they
are
doing
and
then
we
don't
have
to
translate
between
different
terms
all
the
time.
G
C
G
D
D
H
H
H
There
we
go
so
there
are
many
different
challenges
associated
with
operation
of
iot
devices,
and
I've
highlighted
a
few
of
them
here.
Some
of
them
are
in
the
category
of
onboarding,
some
of
them
in
ongoing
device
management
and
device
maintenance,
and
some
in
the
category
of
well
shall
we
say,
device
disposition
when
the
device
needs
to
transition
to
a
new
owner,
for
example,
and
let
me
talk
about
each
of
these
in
turn.
H
So
with
respect
to
device
onboarding,
there
are
several
steps
that
may
be
needed.
One
would
be
a
verification
of
the
device
to
determine
whether
it
is
an
authentic
and
legitimate
device
that
should
be
onboarded,
perhaps
including
the
decision
as
to
whether
it
is
one
which
was
anticipated
to
be
onboarded.
H
Then
there's
the
matter
of
establishing
credentials
on
the
device
for
the
device
itself
that
will
be
recognized
and
also
configuration
of
the
device
so
that
it
can
operate
effectively
for
whatever
application
it
is
to
be
used
for
so
this
would
include
configuration
not
only
of
security,
related
parameters
but
also
operational
parameters,
for
example,
a
light
switch
being
configured
with
the
identity
and
perhaps
addresses
of
the
other
switches
of
the
lights
that
it's
going
to
control
and
network.
Configuration,
of
course,
is
a
very
important
part
of
this
as
well.
H
Naming
can
be
useful
here
to
the
extent
that
it's
desired,
to
have
a
user,
visible
and
readable
names
for
devices
and
other
data
about
the
device
if
it
is
to
be
comprehensible
to
the
user.
It
probably
needs
to
be
established
at
the
time
that
the
device
is
brought
on
board
and
then
there's
management
of
the
device
throughout
its
operation.
H
That
would
include
monitoring
the
device
to
see
if
it
deviates
from
normal
operational
parameters
as
well
as
changing
the
configuration
of
the
device.
Even
its
credentials
perhaps
may
need
to
change
and
certainly
authorizations
and
access
control,
as
well
as
things
that
might
safely
be
considered
strictly
to
fall
into
the
management
or
maintenance
category
firmware
and
software
updates
to
the
device.
H
So
all
of
these,
and
probably
others
as
well,
are
real
challenges
for
iot
operation
and,
as
was
described
earlier,
the
challenges
vary
depending
on
the
type
of
environment
where
the
iot
device
is
to
be
used,
whether
it's
a
home
or
business
or
a
government
entity.
The
requirements
in
terms
of
ease
of
use
and
security
will
change
as
well.
H
H
The
reason
that
I
think
it's
especially
important.
It
is,
of
course,
an
effort
to
create
some
widely
supported,
iot
communication
standards
to
reuse.
As
many
as
possible
and
create
whatever
else
is
needed
to
support
those
the
normal
operation
of
the
device
throughout
its
life
cycle,
it's
intended
to
run
over
any
media
that
supports
ip,
but
the
first
priorities
are
wi-fi
thread
and
bluetooth,
low
energy
and
the
focus
is
on
smart
home,
not
to
say
that
commercial
applications
may
not
come
into
focus
in
future
releases,
but
the
members
of
the
chip,
as
we
call
it.
H
H
Signify
and
others
and
they're
all
actively
involved
in
and
committed
to
the
development
of
these
standards.
Intellectual
property
has
been
contributed
and
will
be
made
available
on
a
royalty-free
basis
to
anyone.
The
working
group
is
only
open
to
zigbee
members,
but
the
open
source
implementation
and
the
specification
will
be
open
to
all
and
in
fact
already
are
so.
If
you
want
more
information
on
you
go
to
this
website
here,
connectedhomeip.com.
H
H
H
H
Many
of
these
tiny
devices
operating
with
energy
harvesting
or
with
very
small
batteries
and
long
lifetimes,
can't
use
wi-fi,
and
yet
they
can
still
use
ip
so
long
as
we
support
thread
or
ble,
I'm
sure
there'll
be
other
media
supported
later
as
well,
and
this
being
iot
connectivity
toward
the
cloud
is
enabled
by
ip.
Although
it's
not
required,
you
can
go
up
to
your
mountain
cabin
and
no
external
connectivity
whatsoever
and
set
up
a
chip
network
up
there.
H
H
H
I
D
J
You
put
it
in.
If
you
put
it
in
a
portrait
mode,
then
you
can
see
the
unmute,
but
if
you
turn
it
to
a
more
much
more
usable
landscape
mode,
then
oh,
the
mute
button
disappears
is
hidden
if
you,
unless
you
poke
it
or
not
so
okay,
I
don't
know.
If
I
turn
my
camera
on,
I
didn't
they're,
not
I
kind
of
don't
intend
to.
J
Me
well,
if
you
can
see
me
great
and
if
you
can't
tough
all
right,
so
I
just
wanted
to
talk
a
couple
minutes
about
this.
I
guess
is
really
good,
we're
actually
all
without
really
preparing
we're
kind
of
all
on
the
same
topic
here,
particularly
carsten
tim
and
I
so
I
wanted
to
talk
about
the
issue
of
device
and
certificate
life
cycles
and
management
next
slide.
Please.
J
So
you
know,
we've
talked
about
on
boarding
and
commissioning,
and
you
know
that's
my
common
favorite
topic,
but
let's
talk
a
little
bit
about
something
that
comes
after
it,
which
is
operations,
and
I
want
you
to
think
about
a
little
bit
and
that's
not
so
much
in
terms
of
the
smart
home
as
steve
has
described,
although
there
is
a
fairly
important
part
of
that
in
the
smart
home.
But
I
want
you
to
think
about
the
summer
as
a
multi-tenant
building
a
smart
building
where
there's
a
a
multitude
of
tenants.
J
The
foyer,
for
instance,
is
used
by
all
sorts
of
tenants.
The
front
door
needs
to
be
lockable
by
everybody
and
unlockable
by
emergency
services
and
over
time,
there's
different
occupants
who
occupy
different
pieces
of
the
building,
and
not
only
that,
but
there's
also
possible
subli
sub
lease
arrangements.
J
But
when
I
bought
my
new
home
it's
coming
up
on
exactly
20
years
ago.
The
first
thing
we
did
was
we
went
out,
took
all
the
tumblers
to
the
hardware
store
and
got
the
whole
home
re-keyed
literally
re-keyed,
and
I
have
the
same
key
for
all
three
doors,
which
is
wonderful
which
the
previous
owner
did
not
have.
J
J
So
right
now
we
know
who
owns
what,
essentially
by
the
fact
that
we
have
some
kind
of
an
owner
and
brewski
it's
a
registrar
and
it
signs
an
ldf
id
for
each
device,
and
I
appears
that
that
that
fido's
iot
does
something
like
this,
and
I-
and
I
guess
chip
does
a
certain
amount
of
this.
All
I'm
unclear
if
it's
a
certificate
or
a
symmetric,
key
or
not
police
authority
is
actually
very
much
like
intel
sdo.
J
But
I
don't
know
exactly
the
details
and
they
have
a
lot
of
ipr
claims
that
that
means
I
don't
want
to
read
their
specs
and
but
essentially,
everyone
has
some
kind
of
cryptographic,
identity
that
that
says
which
device
is
owned
by
whom-
and
I
think
that's
a
pretty
good
model
and
I
don't
think
I'm
going
to
propose
to
change
it.
But
I
think
we
need
to
think
of
this
all
the
way
through
next
slide.
Please!
J
So
it
turns
out
that
there's
some
interesting
tricks
and
and
simplifications
with
wpa
psk,
where
in
most
cases
you
can
actually
assign
a
per
device
wpa
key,
but
only
if
you
know
the
mac
address,
if
the
mac.
If
the
device
comes
in
with
a
randomized
mac
address,
then
you
have
this
problem
of
you
actually
don't
know
what
key
to
look
up
to
figure
out
what
how
to
authenticate
it
until
you,
you
figured
it
all
out,
and
since
you
don't
transmit
the
key
over
the
wire,
you
can't
use
that
as
a
thing.
J
This
is
actually,
if
you're
familiar
with
ip1
with
main
mode
and
psks.
It's
it's
very
similar
problem
there
so
and
it
goes
away
with
certificates
because
you
can
do
asymmetric
signatures
and-
and
those
can
be
proven.
So
if
you
throw
mac
randomization,
which
is
the
medina's
working
group
is
about
to
embark
into,
then
you
suddenly
discover
that
you
really
can't
use
mac
addresses
and
that
mostly
eliminates
the
ability
to
have
a
per
device.
Wp
psk,
you
think,
oh
well,
why
do
I
need
a
per
device
this?
J
And
the
answer
is
because
you
have
to
be
able
to
the
only
way
to
kick
a
mel
behaving
device
off.
The
network
is
to
revoke
their
key,
and
if
you
want
to
change
the
ownership
of
the
devices
and
who
has
access
to
the
network,
then
the
only
way
to
do
that
is
to
greet
in
and
change
their
psk
again
and
that
changes
what
network
they
can
go
on
and
change
the
ssid
and
also
it
restricts
that
they
can't
be
on
the
old
network
anymore.
J
J
J
J
So
sometimes
that's
because
the
ca
is
gone,
just
died
and
they
can't
get
a
new
one
and
they
have
to
restart
everything.
And
today
that
certainly
involves
going
and
resetting
every
device
and
redoing
the
onboarding.
And
then
the
question
arises
well.
Is
that
authorized
right
in
a
multi-tenant
environment
if
someone
can
go
around
pushing
the
buttons
and
re
onboarding
devices
and
that's
a
problem
and
that's
probably
a
problem
in
your
home?
J
J
J
Usually
they
have
more
than
one
bank
of
elevators
and
they
have
separate
control
systems,
so
they
can
only
put
always
put
some
and
maintenance
in
some
way
while
some
of
them
are
operating,
but
if
they're
all
tied
together
in
some
intelligent
way
and
you're
trying
to
redo
the
management
system.
That's
maybe
is
a
real
problem
and
I
think,
there's
a
whole
class
of
devices
that
we're
going
to
discover
that
we
really
they
do
need
to
operate
in
some
continuous
fashion.
Compare
in
the
compared
to
the
timeline
of
re.
J
I
don't
know
what
what
right
we're
re-parenting
them
or
something
like
this
occurs
right.
Perhaps
your
furnace,
you
think.
Well,
I
can
survive
for
half
an
hour
while
it's
on
it's
re-parented
to
a
new
device.
That's
okay,
but
can
I
survive
the
whole
weekend?
If
it's
you
know
waiting
for
monday
morning
for
the
furnace
company
to
say?
Oh,
yes,
we
agree
that
we
are
now
your
new
furnace
management
company
and
the
answer
is
probably
in
at
least
my
my
neck
of
the
woods.
J
You
know
you
can't
survive
the
whole
weekend
on
in
january.
That
way-
and
I
think
that's
almost
the
last
slide-
next
slide,
it's
probably
just
as
questions
is
there
one?
No
there
you
go
yeah,
so
that's
really
the
questions
right.
What
are
we
going
to
do?
Are
we
going
to
do
long,
lift
certificates
with
frequent
checking?
Are
we
going
to
do
short-lived
certificates
always
renewing
some
kind
of
a
push
mechanism,
and
can
we
really
deal
with?
J
J
D
D
Yeah,
so
we
have
schedule
a
little
bit
of
after
open
mic
time
to
under
the
actual
content
presented
today.
So
if
there
were
no
immediate
questions
beforehand
so
for
now,
I
would
like
to
throw
at
least
one
question
to
the
ring
and
see
how
that
works.
This
was
oh
and
there's
sorry.
I
will
just
step
down
for
everybody
who's
queuing
right
now.
Thank
you
for
the
queuing
here
and
I
see
the
chat
warren
was
in
first
and
I'm
opening
up
a
mic
line.
Now,
therefore,.
I
I
It's
just
while
listening
to
this,
I
kept
thinking
michael's
example
of
a
furnace
and
it
can't
be
of
being
offline
for
a
few
days
because
of
change
of
ownership
or
a
change
of
who
runs
it.
I
don't
currently
have
that
problem
and
I
think
it
would
be
a
sad
world
if
we
ended
up
in
a
place
where
that
becomes
the
norm.
J
J
F
F
D
D
So
I
would
like
to
point
out
that
warren
commented
on
some
of
this
on
the
chat,
so
that
is
not
always
catching
someone's
eye
and
I
wouldn't
actually
call
it
a
rent
to
be
honest.
But
personally-
and
this
is
saying
without
a
head-on
effectively
getting
into
the
line
here-
I
think
that
there's
somehow
there
is
always
a
theme
between
these
presentations
and
then
again
I
think
it's
it's
relatively
hard
to
derive
a
a
for
example.
J
Well,
so
I
think
that
there's
two
parts
here
is
that
we
need
to
understand
whether
we
understand
the
problem
well,
and
the
second
part
is
that
we
need
to
just
to
figure
out
whether
we
like
to
have
the
what
is
the
model
of
the
solution.
So
there's
there's
a
number
of
different
ways
in
which
we
can
do
it.
I
mean
we
had
a.
J
Because
something's
happened,
and
you
know
that
might
be
a
one-page
rfc
to
to
define
a
new
header
that
describes
what
that
polling
period
is,
or
it
might
be.
Just
that
we
have
a
conversation
about
well,
the
work
that's
been
done
in
netcomf
and
we
say
that
you
know
what
devices
need
to
support
an
https
target
that
supports
yang
rpc
and
well
that
sentence
pretty.
It
sounds
pretty
trivial
to
say
the
implementation
requirements
may
be
quite
steep
because
it
implies
a
whole
bunch
of
other
stuff
like
that.
J
F
F
F
Some
of
these
things
were
raised
then,
and
the
ramifications
here
aren't
just
that
you
might
lose
certain
functionality
in
some
cases,
but
that
other
people
retain
that
functionality
when
you
don't
want
them
to,
and
so
just
a
a
small
document
on
that
I
don't
know
if
it's
a
blog
or
whatever,
to
explain
the
ramifications
of
not
handling
handoffs
is,
I
think,
useful
and
then
what
the
you
know,
what
sort
of
parameters
there
are
to?
Even
how
do
you
even
know
the
thing
was
sold
and
what
you
know?
F
What
does
it
mean
ownership
in
this
context?
These
are,
I
think,
challenging
points
and
well,
if
we
look
at
things
like
you
know,
sort
of
devices
without
pre-built
in
trust,
anchors
beyond,
say,
a
public
key
allah.
You
know
dpp
or
whatever
chip
is
delivering
in
this
regard
that
that
that
to
me,
I
think,
has
certain
benefits
but-
and
I
think
it
also
addresses
warren's
concern,
and
it
may
be
something
we
we
may
even
want
to
take
a
position
on
at
some
point.
F
I
mean
figuring
out
for
certs
is
hard
in
this
case
right.
It
may
not
be
improper
in
other
cases.
By
the
way
it
may
be
proper
to
use
a
certificate
based
approach
when
you
have
a
really
high
value
asset
that
need
that
really
ought
to
have
been
tracked
by
the
manufacturer.
Assuming
the
manufacturer
survives,
which
is
another
question,
but
those
are
some
thoughts
we
can
put
into
a
document
even.
D
So,
thank
you
elliot
for
basically
the
segway,
yes,
and
that
is,
I
think,
a
good
point
in
time
to
use
the
smallest
theory
topic
that
we
have
called
phrasing
scoping
of
deliverables,
because
here
in
this
working
group,
we
are
basically
tasked
with
creating
a
set
of
work
items.
I
would
say
that
we
can
capture
in
the
scope
of
documents,
and
so
my
my
very
naive
first
question
to
the
participants
here
right
now
and
of
course
we
will
continue
and
extend
this
discussion
to
the
list
would
be.
F
So
I
guess
I'll
throw
out
the
the
document
idea
that
I
just
I
just
gave
you
you
heard
me
chuckle
just
because
of
what
cars
did
just
tossed
in
the
chat,
which
is
key
escrow
because
you
know.
Obviously
the
computer
industry
has
ward
over
that
exact
phrase
when
we
start
thinking
about
who's,
doing
the
escrow.
J
J
J
It
should
be
a
discussion
about
the
you
know,
pros
and
cons,
maybe
never
to
be
published
as
an
rfc,
but
I
think
that's
a
document
that
we
should
write
and
and
figure
out
what
the
boundaries
are,
and
maybe
it's
actually
something
that
actually
you
know
nist
actually
would
prefer
to
to
take
over
in
some
way,
because
I
think
there's
aspects
of
regulation
and
legal
inputs
to
this.
That
really
need
to
be
taken
into
account.
G
C
I
I
think
I
would
support
having
the
the
technologists
having
the
the
things
happen
in
public
as
much
as
possible
until
you
get
to
the
limits
of
what
technology
can
do
and
then
the
pieces
outside
of
that,
you
know,
I
think
we're
all
going
to
just
cover
our
eyes
and
pray,
but
but
I
I
would
certainly
support
solving
the
solutions.
Solving
the
problems
as
much
as
possible
in
this
kind
of
a
venue.
J
Yeah,
so
that's
what
I
had
in
mind.
I
wasn't
intending
to
to
write
a
document
for
for
lawyers,
but
rather
to
create
a
palette
of
different
mechanisms,
but
but
from
the
one
side
is
key:
escrow,
okay
and
and
on
the
other
side,
is
yeah
just
push
this
button
right
and
I,
I
think,
there's
a
bunch
of
scenarios
in
between
and
there's
you
know
you
know
it
comes.
J
You
know,
there's
there's
many
devices
that
you
can
get
where
you
can
convince
the
manufacturer
to
help
you
recover
and
then
there's
devices
you
know
where,
for
instance,
apple
has
said
that
they
won't
help.
You
recover
right
and
I
think
that
that
palette
needs
to
be
described
from
a
technical
point
of
view,
and
then
I
think
that
once
we've
said
what's
possible,
then
I
think
it
comes
back
to
regulators
or
or
or
industry
self-governing
things
to
decide.
You
know
well.
J
This
is
an
appropriate
level
of
security
versus
paranoia
versus
compromise
because
of
of
call
it
national
cyber
security
issues.
So
I
mean
we
all
want
the
devices
the
manufacturers
all
want
to
make
it
easy
for
the
devices
to
be
quickly
recovered
and
the
nash,
the
nations
all
want
to
make
sure
that
that's
not
abused
on
mass
right
or
that
there
aren't
any
too
many
cross-jurisdictional
boundaries
on
that
process.
D
L
L
That
might
that,
might
that
that
format
of
the
work
might
give
an
opportunity
for
a
considered
discussion
about
different
alternatives,
and
then
say
you
know
the
way
and
the
winner
is
whether
you
know
just
just
to
be
able
to
move
that
that
work
forward.
The
other
thing
was
I
this
is
me
personally,
but
I
think
it's
perfe
perfectly
fine
for
a
bcp
to
say
these
are
some.
These
are
some.
L
L
The
other
thing
is,
I
think,
you
guys
are
headed
towards
something
that
really
needs
to
be
published
as
an
rfc,
because
it's
going
to
be
something
that
people
are
going
to
want
to
reference
in
other
sdos
and
even
perhaps
in
regulatory
environments.
So
you
know,
wiki
pages
are
great,
but
maybe
not
for
that.
I
Thank
you
yeah.
I
I
think
that
spencer
said
almost
everything
I
wanted
to.
I
think
sort
of
talk
about
stuff.
Like
you
know,
key
escrow
versus
a
reset
button
might
currently
be
a
bit
premature
because
I
think
we
first
need
something
that
describes
more
of
what
not
quite
problem
statement
and
requirements,
but
more
sort
of
what
we're
talking
about
and
how
we
think
that
things
fit
together.
I
F
I
think
there's
a
phrase
that
we
like
to
use,
which
is
secure
by
design
and,
of
course
everybody
bickers
about
what
the
word
secure
means
right.
We
we
love
to
do
that,
but
what
I'll
tell
you?
What
I
think
we
shouldn't
do?
I
don't
think
we
should
be
aiming
the
society
and
the
industry
towards
solutions
that
that
require
outs
of
security
right.
We
don't
want
to
have
what
amounts
to
downgraded
tax,
and
so
my
view
right,
it
should
be
secure
by
default.
F
F
A
J
D
Plan,
so
this
is
hank
commenting
on
on
the
content
of
that.
So
I
think
what
was
the
term
actor
or
a
player?
That's
a
player,
so
so
carson
introduced
the
term
player
before
then,
so
so
the
owner
also
so
the
air
quotes
owner.
I
guess,
are
players
here,
but
sometimes
you
have
to
involve
some
other
governing
entity
that
helps
you
transition
a
device.
D
So
that
would
be
just
a
a
comment
when
something
starts
that
that
please
keep
in
mind,
there
might
be
other
work
that
will
accompanying
this,
and
then
we
have
to
reuse
that
and
make
it
consistent.
So
I
hope
that's
that's
something
we
can
achieve
here
and
we
have
to
start
with
the
first
document
and,
let's
find
out.
D
Are
there
any
other,
so
I
haven't
paid
attention
to
the
chat
toy.
I
have
to
move
there,
I'm
using
a
a
a
mobile
device
also
right
now.
So
that's
a
little
bit
difficult,
but
I
think
the
mic
line
is
empty
now
and
we
have
at
least
a
document
that
could
become
something
that
is
worked
on
here
or
the
voluntary
ownership
change.
D
F
Go
ahead,
I
just
told
the
voluntary
ownership
change
thing
for
for
a
moment.
One
aspect
that
we
might
want
to
consider
is
whether
it
should
be
necessary
in
some
environments
to
test
that
there
is
at
least
possession
of
the
device
in
some
way
shape
or
form
right.
So
you
know
is
that
per
does
that
person
still
have
possession
of
the
device
and
how
do
you
test
and
what
are
the
ramifications
if
the
test
fails-
and
you
know
these-
these
are
things
we
might
want
to
ask
as
we
pursue
this
activity.
D
Up
so
thank
you,
michael.
We
are
basically
five
minutes
before
the
top
of
the
hour
and
these
call
for
for
for
content
items
or
work
items
we
will
put
to
the
list
of
course,
and
the
minutes
will
follow,
and
I
think
thank
you
for
the
mistake.
I
thank
you
a
lot
for
the
extensive
minutes
taking
so
that
looks
really
comprehensive
to
me
and
we
work
through
that
and.
D
D
So
so
one
of
the
takeaways
I
personally
noted
was
that
the
question
from
tim
about
where
would
these
taxonomies
go
and
that
was
basically
answered
by
carson
with
the
thing
to
think
research
group,
a
research
group
would
be
a
good
place
for
that,
but
making
use
of
taxonomies
here
of
course
makes
sense
when
we
reuse
the
appropriate
labels
that
are
replaced.
They
are
there
so
what
cars?
Maybe
you
have
something
to
add
to
this.
G
G
I
would
like
to
discuss
this
with
the
the
authors
of
the
current
documents
as
well,
so
we
can
come
up
with
an
arrangement
that
that
makes
sense,
but
we
we
have
a
variety
of
mechanisms
we
can
use
to
to
get
these
documents
out
and
internet
drafts
is
one
and
of
course
we
also
have
wikis
where
we
could
collect
some
terminology
and
so
on.
So
we
we
will
have
to
find
out
how
to
do
that,
and
I
could
imagine
that
we
develop
a
relationship
that
is
a
bit
of
a
client
server
nature.
G
So
iot
ops
tells
us
where
terminology
is
actually
needed
and
the
research
group
actually
tries
to
define
that
terminology
but
yeah.
In
the
end,
it's
all
going
to
be
people
who,
who
will
will
be
to
a
large
part
in
both
groups.
So
I
think
it's
not
even
necessary
to
to
define
this
in
a
particular
detailed
way.
D
Yeah
and
micah
also
said
that
the
document
can
be
useful
to
capture
ideas
and
contents.
I
think,
and
it
doesn't
necessarily
have
to
become
an
rfc,
so
that
is
also
a
a
very
good
message,
so
in
order
to
structure
and
and
move
forward
with
work
here
and
structure
the
plan
accordingly,
I
think
I
think
gathering
information
and
drafts
is
a
good
initial
process,
of
course,
and
yes,
nothing
and
not
everything
that
we
have
to
we
were
creating
here
because
has
to
become
a
a
published
document
in
the
end.
D
D
If
that
is
not
the
case,
I
would
really
thank
everybody
to
to
stay
with
us
due
to
all
this
technical
stuff,
but
the
very
beginning
of
the
session.
Again,
I
hope
really
that
is
somehow
due
to
my
settings
and
not
due
to
a
new
feature
with
webex.
Having
said
that,
we
will
explore
the
option
to
use
a
media
code
in
the
near
future
when
we
try
to
do
this
again
and
so
again,
thank
you.
Everybody
for
joining
us
here.
Thank
you
for
adding
a
blue
sheet
list
to
the
minutes.