►
From YouTube: IETF110-IOTOPS-20210309-1430
Description
IOTOPS meeting session at IETF110
2021/03/09 1430
https://datatracker.ietf.org/meeting/110/proceedings/
B
Oh,
and
here
we
go
even
better,
there
was
something
to
this
hello.
Everyone
welcome
to
the
first
meeting
of
the
freshly
minted
iot
operations
working
group
at
itf-110
alexa,
and
I
will
be
trying
to
be
your
useful
co-chairs
here
in
this
space
and
we
have
a
very
packed
agenda
for
today.
So
let
me
quickly
run
through
the
chair
slide
here,
which
probably
the
most
important
part
is
the
note
value.
So
as
this
is
going
to
be
a
place
where
even
new
attendees
might
flock
to
it's
important
to
highlight
that
there
is
a
node
value.
B
That's
all
your
questions
about
ipr.
So
follow
these
links.
If
you're
not
aware
of
that,
it's
also
google
and
the
iitv
website.
If
you're
not
familiar
with
this,
please
do
get
familiar
and
also
the
sessions
being
recorded.
Everything
you
say
here
will
be
part
of
this
ietf
and
yeah.
Again,
there
are
some
interesting
things.
Please.
We
have
to
get
some
notepad
takers
and
alexa
we'll
do
this
in
a
second.
This
is
the
agenda.
We
are
quite
packed.
B
We
hoped
for
more
open
mic
actually,
but
I'm
running
through
this
quickly,
because
I
can
spoiler
that
we
are
intending
to
do
a
virtual
interim,
very,
very
short
term.
B
Next
to
this
meeting
here
and
therefore
today
you
will
basically
get
an
insight
in
what
topics
are
interesting
in
this
space
and
then
we
can
have
a
discussion
on
that.
So
alex
say.
Please.
A
C
Today
this
is
warren,
and
I
up
first.
If
so,
I
can
present
that
way.
You
do.
Okay,
okay,
let
me
present
us
to
share
screen.
C
Yes,
a
chrome
tab
charter
interpretation.
There
we
go-
hopefully
that's
sharing
correctly
so
hi
everyone,
as
hank
said
we
are
fairly
low
on
time.
So
I'm
going
to
go
through
this
really
quickly,
but
I
want
to
give
people
a
quick
introduction
to
the
iot
ops
charter,
because
this
is
somewhat
of
an
unusual
working
group.
C
C
For
a
long
time,
it's
been
really
clear
to
us
in
the
ietf
that
we
need
some
sort
of
iot
related
working
group,
there's
a
huge
amount
of
work
that
could
be
considered.
Iot
related.
You
know
this
is
done
in
ace,
anima,
core
drop,
roll,
lpwan,
etc,
but
there
isn't
really
a
sort
of
overarching
architecture.
C
If
you
take
all
of
these
building
blocks-
and
you
want
to
actually
build
an
iot
thing,
this
is
how
you
do
it,
and
so
for
the
past
many
years,
six
or
seven
at
least
we've
been
talking
about
actually
chartering
something,
but
we
kept
running
into
the
problem
of
we're
not
quite
sure
what
area
should
go
in
we're
not
quite
sure
how
to
limit
the
scope,
we're
not
quite
sure
how
to
make
it
actually
all
work,
and
this
ended
up
the
perfect
being
the
enemy,
the
good.
C
So
after
a
while,
we
decided
that
we
should
just
do
something,
and
so
this
is
the
sort
of
initial
first
iot
ops
working
group
because
of
the
problem
of
defining
the
scope
and
the
problem
of
figuring
out
where
exactly
the
work
is
going,
we
are
trying
something
new.
C
C
I
took
some
some
stuff
from
suit
and
I
mixed
it
all
together
and
it
almost
works,
except
that
I
can't
figure
out
how
to
make
this
last
little
bit
work
or
you
know
I
have
gone
through,
and
I
have
built
and
deployed
my
iot
architecture,
but
when
I
went
to
actually
deploy
it,
I
realized
I
had
a
million
devices
that
are
deployed
now
and
the
actual
operational
aspects
of
managing
the
this
number
of
devices
are
really
hard
or
something
similar.
C
So,
as
I
said,
this
is
a
new
style
of
working
group,
it's
for
discussion
and
for
people
to
share
information,
but
it's
not
likely
to
do
that.
Much
actual
document
creation
itself.
C
This
working
group
is
not
very
likely
to
actually
create
protocol
said.
Instead,
what
will
happen
is
we
will
most
likely
say,
that's
best
developed
in
existing
working
group
or
potentially
you
know
there
is
no
working
group.
That
is
exactly
perfect
for
this
work,
and
so
we
might
end
up
chartering
new
working
groups,
either
in
the
ops
area
or
in
other
areas.
C
The
other
thing
that
this
working
group
is
likely
to
be
good
for
is
newcomers
to
the
ietf
people
who
have
already
started
developing
an
iot
ecosystem
are
going
to
come
along
and
say
the
ietf
has
all
of
this
work.
I
don't
really
know
where
my
particular
section
fits
in,
or
you
know,
are
you
already
working
on
this
particular
set
of
protocols
or
problems,
and
so
iot
ops
is
supposed
to
be
a
friendly,
helpful
way
to
introduce
people
to
to
our
work
and
where
it's
happening,
as
I've
mentioned
a
number
of
times
now.
C
C
So
what
we're
asking
is
about
one
year
after
chartering,
we're
going
to
ask
the
chairs,
in
collaboration
with
the
working
group,
to
prepare
a
report
for
the
iesg
and
ietf
as
a
whole,
explaining
what
the
working
group
has
managed
to
accomplish,
but
also
how
this
idea
of
a
discussion
style
working
group
works.
Does
this
work
well?
C
Is
it
worth
us
having
more
discussion
groups
in
other
areas
or
on
other
topics,
rob,
and
I
obviously
believe
that
this
is
a
good
concept
and
will
work
well
a
way
to
build
architectures
from
our
building
blocks,
but
that's
still
open
to
open
proof.
C
So,
as
I
mentioned,
the
chair
said:
keep
this
really
short.
So
I'm
keeping
it
really
short
questions
for
myself
and
or
rob
many
of
them
we're
likely
to
have
to
do
offline,
but
you're
underscore
so
just
speak.
D
Yeah
a
thank
you
very
much
b.
I
would
suggest
to
the
chairs
to
query
feedback
about
the
usefulness
of
the
group.
You
know
already.
You
know
this
week
and
every
other
other
time
we
meet,
because
that
makes
it
a
lot
easier
to
track
its
success,
because
they'll
typically
be
in
each
of
the
meeting
different
participants,
so
just
to
make
all
these
knucklehead
folks
in
administrative
happy
about
you
know
that
this
group
is
very
useful,
which
I
do
completely
agree
with.
D
Thirdly,
to
the
point,
so
I
think
that
requirements
already
is
fairly
far
down
the
path
of
knowing
how
to
solve
things
right.
So
I
would
very
much
hope
that
something
like
problem
statements,
you
know
looking
at
use
cases
and
how
they
don't
work.
Well,
you
know,
as
a
discussion.
Startup
would
also
be
within
scope
and
that's
a
question.
C
E
Good
evening,
thanks
for
taking
my
comment
and
thank
you
warren
for
setting
this
group
up
and
for
alexi
for
you
for
for
supporting
it
and
a
special
thanks
to
hank
for
agreeing
to
take
on
this
task,
which
really
is
rather
amorphous,
as
you
pointed
out,
just
been
a
struggle.
I
was
just
going
to
answer
a
little
bit
to
to
tour
this
on
that
point,
which
is
watch
this
space,
because
I
actually
have
a
contribution
towards
the
end,
which
I
think
goes
to
exactly
what
warren
is
is
looking
for.
E
It's
it's
not
trying
to
solve
a
particular
problem
at
this
point
in
time.
It's
just
highlighting
a
problem
in
terms
of
a
potential
architectural
component
in
the
picture.
That's
missing
in
onboarding,
but
I
I
don't
want
to
get
into
the
presentation.
I'll
just
say:
watch
this
space
and
if
we
don't
have
time
for
it,
go
read
the.
B
All
yeah:
we
have
to
cut
the
queue,
unfortunately
to
keep
in
time,
but
we
can
again,
there
will
be
a
in
the
near
future
and
interim
here.
I
will
now
share
the
slides
for
the
first
presentation.
G
B
B
Okay,
then
it
does
not
change
so
done
alexa.
B
G
G
Give
you
a
brief
overview
very
quickly
only
so
if
you
open
the
specifications
which
are
publicly
available
and
at
the
end
of
the
slide
deck
listed
as
links,
you
will
see
that
the
architecture
here
shown
in
this
yellow
bubble
consists
of
a
of
a
lightweight
m2m
client,
which
resides
in
an
iot
device,
which
then
talks
to
two
types
of
servers:
a
bootstrap
server,
which
is
a
fancy
name
for
key
distribution
server
and
a
lightweight
mdm
server,
which
does
the
rest
of
the
iot
device
management.
G
But
there's
also
obviously
happening
something
outside
that
yellow
box,
which
is
the
interaction
with
some
application,
servers
or
apps
or
who
knows
what,
and
those
are
typically
in
deployments,
also
found,
of
course,
but
are
not
covered
in
the
specification
itself.
They're,
actually
other
standards,
organizations
doing
that
type
of
work
also
not
shown
here,
which
I
would
like
to
point
out.
Given
some
of
the.
G
Is
any
type
of
provisioning
of
credentials
for
or
distribution
of
credentials
for
network
access,
because
there
are
lots
of
different
radio
technologies
out
there
and
they
often
have
their
own
scheme.
So
this
is
really
about
distributing
sort
of
or
configuring
honesty.
Your
slides
are
not
advancing.
Okay,
but
can
you
see
now.
G
Yes,
okay,
I'll
just
stay
with
this,
I
hope
you
can
still
see.
So
this
is
the
and
for
sorry
this
is
the
slide
deck.
I
was
just
a
slight.
G
I
was
just
showing
with
the
architecture
and
to
describe
these
so
the
problem,
what
is
being
described
is
a
protocol
and
there
are
different
interfaces
and
the
one
that
is
relevant
to
the
discussion
here
on
bootstrapping
or
the
key
distribution
or
security
particular
is
the
so-called
bootstrap
interface
which
works
between
the
client
and
the
bootstrap
server,
and
it
provisions
credentials
configuration
informations
about
what
server
detectors
and
and
details
of
that
configuration,
communication,
interaction
and
also
access
control
lists.
G
There
are
also
other
interfaces
which
are
equally
important
than
actually
the
main
purpose
of
of
doing
the
device
management,
but
they
are
less
security
relevant.
I
would
argue
when
you,
when
we
look
at
the
protocol
stack-
and
this
is
a
a
figure
of
the
stack
of
the
latest
version
of
the
lightweight
m2m
specification-
mentioning
that
there
are
in
the
meanwhile
various
different
versions
published.
G
You
can
see
that
first
of
all,
there
are
lots
of
iudf
protocols
being
used
here,
but
also
that
the
lightweight
m2m
messaging,
which
is
on
the
top,
runs
over
different
transports
and
can
thereby
then
daily
to
specific
usage
environment.
So
mbiod
is
different
than
let's
say:
wi-fi
deployment
and
mqtt
is
different
than
co-op
and
likely.
M2M
doesn't
care
that
much
in
general
about
what's
really
done
under
the
hood.
But,
of
course,
as
a
specification
developer,
you
need
to
describe
those
in
addition
to
what
is
shown
in
this
diagram.
G
There
are
lots
of
other
idf
specifications
being
used,
and
I
listed
some
of
them
in
the
on
the
bottom
of
the
of
the
slide.
Of
course,
many
of
the
co-op
extensions,
but
also
security,
specifications
and
sort
of
the
encoding
mechanisms
that
the
idf
has
been
working
on,
like
sibor,
cinema,
etc.
G
When
it
comes
to
the
security
aspects,
one
important
piece
is
sort
of
this.
What
the
specification
refers
as
bootstrapping
or
some
people
call
it
enrollment
key
distribution,
you
name
it
is
that
a
device,
the
lightweight
m2m
client
in
the
iep
device
needs
to
talk
to
the
server
side.
G
The
lightweight
m2m
server
and
in
order
to
do
so
securely
either
using
dls,
dtls,
oscore
or
a
combination
of
those
sort
of
osco
on
top
of
dls
or
dtls,
it
needs
to
have
the
credentials
it
needs
to
have
the
configuration
it
needs
to
potentially
have
access,
control
lists
and
there's.
Obviously,
the
question
of
where
this
comes
from
and
one
possibility
is
to
provision
this
straight
into
the
device
during
manufacturing.
G
But
this
is
less
practical
because
you
already
need
to
know
a
lot
of
that
information
up
front
and
so
to
make
this
process
simpler.
G
This
bootstrapping
mechanism
was
introduced
which
allows
the
bootstrap
server
to
send
this
information
to
the
lightweight
m2m
client,
so
that
it
can
then
talk
to
these
different
servers
and
to
send
sensor
data,
and
who
knows
what
to
those
servers,
that's
what
we
call
bootstrapping.
G
There
are
different
forms,
obviously
from
a
security
point
of
view,
and
I
believe
the
most
important
ones
are
whether
the
keys
are
generated
on
the
server
side
or
whether
they
are
generated
on
the
client
side,
and
the
specification
supports
both
also
with
different
types
of
credentials.
Symmetric
keys,
raw
public
keys
and
certificates,
and
my
favorite
obviously
is
to
generate
the
keys
on
the
device
side
and
to
never
have
the
private
key
leave
the
device.
G
And
this
is
accomplished
using
the
enrollment
of
a
secure
transport
specification
which,
as
you
know,
is
an
idf
document.
G
There's
a
a
flow
in
there
which
sort
of
details.
One
of
those
exchanges
graphically.
But
I
will
skip
it
in
for
the
benefit
of
time
and
instead
would
like
to
talk
about
the
data
model,
which
I
think
is
also
very
important
for
getting.
This
whole
thing
work-
and
this
relates
to
another
recently
created
idf
working
group,
the
asdf
group,
to
which
some
of
our
members
contributed
to
or
still
contributing
to,
which
is
the
data
model.
Because
you
need
to
have
a
way
when
you
provision
information
to
a
device.
G
You
need
to
have
a
notion
of
what
are
you
provisioning
and
how
does
this
whole
hierarchy
look
like,
and
the
data
model
like
with
the
m2m
users
is
very
simple,
and
it's
actually
shown
on
the
first
line,
where
you
access
objects
and
resources
in
a
sort
of
like
sort
of
restful
style,
and
so
a
device
can
have
multiple
objects
and
objects.
Have
resources
which
contain
parameters
essentially-
and
there
are
a
several
of
them-
are
specified
in
the
lightweight
m2m
specification
which
are
shown
on
the
screen.
G
The
most
important
one
for
this
discussion
is
probably
the
security
object,
which
contains
all
these
different
keys
and
and
parameters
that
are
being
provisioned,
but
also
that
the
others
are
obviously
important
as
well,
knowing
which
server
you
should
be
talking
to,
who
is
allowed
to
access
certain
information,
etc.
G
And
if
you
go
to
one
of
the
links
at
the
end
of
the
slide
deck,
you
will
see
that
there's
a
registry
with
several
hundred
objects
being
registered,
doing
all
sorts
of
things
from
from
a
water
meter
to
a
gas
meter
street
lighting
everything.
G
This
work
has
been
around
for
a
little
while
already
so
there.
The
ninth
test
fest
took
place,
and
the
next
one
will
be
in
two
weeks
there
at
best
fest.
We
have
counted
more
than
40
implementations
and
you
can
implement
and
run
this
and
deploy
it
on
a
very
small
device.
G
So
64
kilobyte,
flash
16
kilobyte
of
ram
isa
is
a
possible
scenario
for
full-blown
implementation,
as
I
mentioned,
is
around
for
a
little
while
and
still
working
progress
with
new
versions
and
adding
new
features
so
seven
years
of
development
time,
and
we
have
a
quite
active
developer
community.
G
So
there's
a
public
github
repository
where
developers
can
discuss
and
raise
issues,
there's
also
a
list
of
popular
open
source
implementations
that
we
collected
and
put
here
on
this
wiki
and
here's
the
link
to
this
github
repository
that
I
mentioned
a
second
ago.
G
If
you
care
about
looking
at
the
specifications
here,
are
the
different
versions
version
one
sort
of
1.0.
1.1.2
is
the
latest
one
which
was
published
end
of
last
year
and
there
are
all
sorts
of
additional
documents,
extra
features
that
were
published
on
the
site
which
you
can
find
on
on
the
other
link
and
the
last
link
is:
do
the
object?
G
Repository
which
really
make
the
whole
thing
complete,
because
you
need
to
have
a
description
of
the
sensors,
actuators
configuration
information
and
so
on,
so
to
manage
your
device
always
life-cycling
and
that's
all
I
have,
and
if
you
are
interested
in
any
of
the
details
and
get
lost
in
the
specifications.
Just
drop
me
an
email.
G
J
J
G
Yeah
and
so
the
the
relationship,
and
so
all
was
our
in
ace-
would
be
a
dynamic
model
for
managing
access
to
iot
devices,
I'm
typically
involving
also
humans,
unlike
users,
let's
say
a
technician
trying
to
access
a
device
and
that's
something
that
the
lightweight
m2m
specification
didn't
do
partially,
knowing
that
there
is
this
working
the
idf
on
on
this
specific
case,
and
so
there
is
not
much
overlapping
overlap
in
that
regard.
G
So
the
lightweight
m2m
specification
doesn't
talk
about
permissions
of
users
and
and
sort
of
more
complicated
scenarios
that
that
are
addressed
by
by
lightweight
m2m.
G
Yeah
there's
a
mistake
in
this
on
this
page
so
that,
like
the
m2m
102
was
published
in
november
2020,
not
2003,
not
2002.
That
would
be
going
back
in
time.
B
Thanks,
hannes,
thank
you
a
lot,
so
so
the
interesting
to
this
would
be,
of
course,
to
see
what
do
you
want
to
have
what
you
would
see
here
incorporated
as
ongoing
work
for
this
working
group?
So
maybe
we
can
take
this
offline
and
we
can
discuss
a
little
bit
how
this
feeds.
G
I
get
so
so
from
for
us
in
general.
It
has
been
extremely
important
to
maintain
a
sort
of
a
lively
exchange
with
the
iedf
community,
because
we
have
so
many
dependencies
on
idf
specifications
and
so
there's.
We
would
appreciate
a
better
flow
of
information
back
and
forth
between
the
groups
and
also
understanding
better
how
some
of
the
specifications
evolve
so
that
we
can
properly
make
use
of
them.
B
Thanks
anis
and
I
think
that's
a
good
segue
to
joffrey
hi
sophie.
K
Hi,
it's
your
flaw.
Okay,
thank
you.
So
this
is
jeff
cooper
and
I'm
here
from
intel
corporation,
but
also
from
the
the
the
fido
organization,
phyto
alliance,
and
I
wanted
to
talk
about
fido
device
on
board,
so
fido
device
on
board.
Let's
see
if
I
can
figure
out
how
to
there
we
go
okay,
so
the
fido
alliance.
K
K
We
figured
out
that
we
wanted
to
fast
track
the
development,
so
we
would
pick
one
target.
We
chose
sdo
secure
device
onboard
from
intel.
Let
me
see
if
I
think
I
don't
need
the
video
anymore.
So
so
we
decided
we
would
choose
secure
device
on
board.
We
allowed
for
some
modifications
of
it,
taking
in
some
newer
protocols,
cbor,
etc,
and
we
got
to
a
review
draft
and
you
can
see
some
of
some
characters.
For
example
hanu
who
just
spoke?
K
I'm
sorry,
hannes,
who
just
spoke,
and
we
have
a
url
and
you
can
take
a
look
at
it
and
we're
actually
getting
fairly
close
to
to
a
a
draft
standard
release
of
this
protocol
and
see
if
I
can
still
move
forward
and
in
addition
to
that,
we
have
an
lf
edge
project
which
happens
to
still
be
called
secure,
device
onboard
and
eventually
it'll
change,
its
name
which
is
actually
working
on
implementations
of
the
this
protocol
and
if
you
go
to
their
their
github
you'll,
actually
be
able
to
see
first
implementations
based
on
the
review,
draft
and
you'll
be
able
to
go
and
and
and
take
download
them
and
implement
them
and
try
them
out,
and
there
are
full
implementations
of
the
protocol
that
are
that
are
underway
and
will
be
available
relatively
soon
in
a
few
months.
K
K
So,
whereas
hanus
was
talking
about
an
entire
data
model
and
a
management
of
iot
we're
talking
about
the
very
first
few
seconds
of
the
device
from
the
box
opening
up
to
getting
the
device
on
board
in
full
service,
and
we
wanted
that
to
be
the
customer
value
prop
that
you
drop
zip
the
device
to
one
location
that
you
press,
essentially
one
button
to
power
up
and
connect
and
I'm
glossing
over
the
network
and
then
the
device
is
on
board
and
everything
about
that
device.
That
needs
to
be
done.
K
All
of
the
the
applications
all
of
the
sensor
connection
connectors
all
of
the
trust
models.
Everything
is
set
up
and
the
device
is
in
service
right
away,
and
so
that's
what
we
mean
by
by
saying
we're
going
to
try
to
solve
the
problem
of
onboarding.
We
want
it
to
be
fast,
scalable
and
secure,
and
we
want
it
to
be
device,
provisioning,
onboarding
and
activation,
and
you
can
do
a
cross
product
of
those
things
and
figure
out
how
they
all
fit
together.
K
So
there's
a
concept
that
we
came
in
up
with,
which
was
a
late,
binding
concept.
I
think
that's
a
really
important
piece
and
that's
the
one
that
I
wanted
to
talk
a
little
bit
about
here.
So
if
you
think
about
the
thing
that
slows
down
iot
in
this
onboarding
process,
it's
that
you
have
manufacturers
who
are
doing
this
build
to
order
kind
of
mechanism
kind
of
like
the
old
days
did.
I
am
I
not
okay
reconnecting
screen
share.
K
Okay,
you
have
manufacturers
who
are
in
this
old
old
fashioned,
build
to
order
kind
of
mechanism,
because
we
have
the
same
device
going
out
for
different
ecosystems
of
iot.
Different
customers
have
different
ecosystems.
If
you
know
in
the
days
when
you
were
allowed
to
walk
into
best
buy
in
the
united
states,
you
would
walk
into
best
buy
and
you
would
see
three
different
tables.
K
One
for
people
who
do
you
know
one
kind
of
iot
vendor
would
do
another
kind
of
iot
vendor
and
you
have
to
choose
which
table
you
buy
your
devices
from,
but
they
could
be
the
same
devices.
K
So
what
we
want
to
do
is
we
want
to
have
a
build,
a
plan,
so
we
want
to
be
able
to
make
a
single
sku
and
when
the
devices
get
on
board
at
the
end
of
the
supply
chain,
we
want
to
figure
out
which
iot
platform
they're
going
to
go
on
to.
We
want
to
figure
out
what
needs
to
change
in
the
device
to
make
that
iot
platform
happen.
K
We
need
to
download
all
the
credentials
and
perhaps
activate
software,
to
make
that
work
and
that
that's
what
late
binding
is,
and
that's
that's
what
fido
device
onboard
does
for
you.
K
So
let
me
talk
a
little
bit
about
how
it
goes.
We
don't
have
a
lot
of
time,
so
there's
a
credentials
put
in
in
the
in
the
manufacturing
period
process.
The
device
is
put
into
a
box
and
is
sent
to
its
drop
ship
location,
and
the
goal
is
that
you
don't
have
to
open
up
the
box
again.
K
So
the
fact
that
it's
a
closed
box
is
important
right
and
closed
until
you're
ready
to
power
it
on
the
there's,
a
data
structure,
that's
created
called
the
ownership
voucher
and
this
date
this
thing
is
sent
along
through
the
supply
chain.
K
Sorry
guys
frogging
my
throat
there
it
sent
along
through
the
supply
chain
to
the
that
the
target
I'm
saying
cloud,
but
it
works
in
a
closed
network.
So
you
know
it's
the
iot
system,
the
device
management
system,
the
iot
platform,
it's
it's
sent
along
to
the
target
where
you're
going
to
manage
the
device
from
and
then
the
device
is
now
ready
to
be
turned
on
the
target
cloud
that
the
device
has
this
problem.
The
device
needs
to
know
because
we're
doing
late
binding,
it
doesn't
actually
know
who's
going
to
onboard
it.
K
So
what
it
has
is
it
has
this
middleman
here:
a
rendezvous
service,
rendezvous
service
works
very
similar
to
dns
and
I'll.
Tell
you
if
we
get
a
chance
I'll
tell
you
why
we
didn't
do
dns,
but
this
is
an
application
server.
When
the
target
cloud
gets
the
credentials
for
the
device
it
registers
its
ip
address.
With
the
rendezvous
service,
the
device
has
the
same
rendezvous
service
information
configured
in
it
goes
to
the
rendezvous
service
and
gets
the
ip
address
of
the
target
cloud.
So
that's
that's!
K
Who
is
going
to
be
my
my
manager
and
then
how
they're
going
to
manage
me
how
they're
going
to
authenticate?
That's
all
done
over
this
this
last
piece
and
the
way
that
works
is
that
the
ownership
voucher
itself
is
used
to
authenticate
the
target
cloud.
So
there's
a
there's,
a
new
object
added
into
the
chain
here,
which
makes
it
possible
to
late,
bind
the
identity
of
the
target
cloud
and
the
device
authenticates
in
a
more
conventional
way,
using
its
device
certificate.
So
then,
you
do
two-way
provisioning.
Now.
K
The
important
thing
is
that
we're
not
done
yet.
The
important
thing
is
that
you
need
now.
You
need
to
go
into
a
mode
where
you
can
provision
all
of
those
things
that
you
would
like
to
have
the
device
do,
and
so
there's
a
there's,
a
data
model
that
comes
up
here,
that's
sort
of
a
general
purpose,
data
model
that
allows
you
to
do
additional
provisioning.
K
On
top
of
this,
this
connection
that
you
set
up
and
you
could
do,
for
example,
you
could
at
that
point,
adopt
a
data
model
similar
similar
to
what
hanas
was
doing
and
send
those
objects
down.
If
that's
what
you
want
to
do
with
the
device
or
if
you
had
a
more
general
purpose
device,
you
might
send
down
a
capsule
and
send
down
a
script
and
you
you
have
a
lot
of
flexibility
and
you
can
then
attach
the
device
to
as
many
truss
routes
as
you
need.
K
So
there's
a
mini
little
language
that
you
can
use
to
to
actually
communicate
with
the
device
back
and
forth
until
you've
got
the
device
in
the
in
its
final
state
and
and
then
at
that
point
you
you
complete
the
protocol
and
the
device
goes
to
doing
what
it
would
always
have
done
if
you
had
done
a
manual
onboarding
process
and
all
of
this
stuff
that
I
showed
you
goes
to
sleep,
and
it
only
appears
if
you
ever
need
to
use
it
again
and
that
that's
the
story
of
of
this
onboarding.
K
So
I
wanted
to
sort
of
emphasize
a
little
bit.
You
know,
what
can
you
do
with
it?
You
can
set
up
all
these
things
right.
You
can
set
up
multiple
credentials.
You
can
set
up
credentials
inside
of
a
t.
You
can
set
up
application
credentials,
you
can
download
hardening
for
the
os
and
for
the
firewall
etc.
You
can
set
up
other
iot
devices.
You
can
use
this
as
a
server
to
set
up
to
run
fdo
on
other
devices,
and
you
can
do
that
in
over
the
internet.
K
You
can
do
it
over
the
intranet
and
you
can
do
it
over
closed
network.
So
that's
the
story.
I
wanted
to
tell
you
today.
This
is
something
that's
coming
to
to
a
github
near
you
you're,
welcome
to
use
it
you're
welcome
to
to
come
and
participate
with
us
in
it,
and
I'm
happy
to
answer.
B
So,
as
a
chair,
of
course,
hi
jeff,
I
could
again
ask
the
question.
B
I
I
feel
that
there
is
a
lot
of
overlap
in
the
general
direction
here
and
also
a
lot
of
discrepancy
in
the
details.
How
do
you
see
this,
for
example,
with
you
when
you
take
into
account
harnesses
presentation
beforehand
how
this
requires
alignment,
and
how
do
you
expect
to
find
some
some
support
here
in
this
space.
K
So
so
we
thought
about
whether
we
should
stop
early
and
and
basically
in
other
words,
we
should
stop
early
in
the
protocol
and
say
well
at
this
point.
You
know
if
you're,
if
you're
lwm2m
or
your
azure
or
your
some
other
csp,
you
will
have
protocols
that
know
how
to
do
all
these
things.
K
So
why
don't
you
just
do
what
you
need
to
do
and
we
felt
there
was
an
impedance
matching
step
that
was
missing
and
the
problem
is
that
if
you
actually
want
to
say
that
you
have
a
device
and
it's
going
to
go
to
any
cloud,
you
any
any
any
device
manager,
you
need
to
have
some
place
where
you
can
do
a
little
bit
of
massaging
of
the
device.
So
the
way
we
do
it
is
the
minimum
you
would
do.
K
So,
for
example,
one
of
the
things
we
have
done
is
we
have
provisioned
used
the
fdo
onboarding
to
provision
lightweight,
mtm
credentials
and
then
reduce
the
previous
case,
and
then,
on
the
other
hand,
if
you
wanted
to
take
a
bear
machine
and
put
a
very
lightweight
operating
operating
environment
on
it,
we've
actually
used
it
to
install
the
entire
operating
system,
to
bring
up
a
container
environment
and
to
run
an
application.
So
we
wanted
to
give
people
the
opportunity
to
say
well.
When
you
arrive
at
the
destination,
the
destination
has
the
ability
to
tailor
the
device.
K
This
is
actually
what
we
mean
by
late
binding,
and
we
think
this
this
this
ability
to
do
as
little
or
as
much
as
you
want
to
do
at
that
point
is
actually
necessary,
but
we
are
not
trying
to
manage
the
device
from
this.
In
other
words,
if
you,
if
you
have
a
strong
device
management
system,
do
less
in
this
phase,
if
you
have
less
of
a
device
management
system
or
you
need
more
of
accommodation
in
the
device
before
you
start,
then
do
more
in
this
space.
B
L
Hi
thanks,
so
I
have
a
quick
question
about
the
rendezvous
service
and
you
mentioned
that
you
specifically
didn't
choose
dns
for
that,
and
I'm
curious
about
sort
of
the
design
decisions
that
put
you
there.
K
So
so
it's
been
one
of
those,
those
things
that
we've
had
to
sort
of
think
about
over
the
over
the
years
on
this.
So
the
the
problem
that
we
had
is
that
that,
in
a
lot
of
organizations,
the
the
owner
remember
we're
thinking
about
different
kinds
of
networks
right
so
we're
thinking
about,
say,
corporate
networks
and
internet
and
closed
networks.
K
Often
the
the
entity
that
is
managing
the
iot
is
not
the
entity,
that's
managing
the
dns,
and
we
have
this
situation
where
you
have
a
server,
that's
receiving
a
credential
and
it
needs
to
register
itself
and
with
some
kind
of
a
lookup
service
and
in
a
lot
of
organizations.
That's
a
big
problem,
and
so
we
said
well,
it's
actually
easy
in
organizations
for
an
iot
organization
to
bring
up
an
application
server,
that's
what
they
do.
K
So
if
we
put
it
in
the
information
in
an
application
server,
we
figured
out
that
we
can
make
it
happen
automatically
and
reasonably.
So
one
of
the
things
that
the
fido
alliance
did
is,
they
did
actually
put
in
a
a
breakout
mechanism.
So
if
you
have
a,
if
you
already
have
some
kind
of
a
lookout
mechanism
you
could
you
could
use
that
instead
of
the
rendezvous,
but
the
rendezvous
service
is
the
is
the
primary
mechanism,
and
it's
it's
not
a
big.
It's
not
a
big
server.
It's
a
little
server.
L
F
Yeah
thanks
dan
harkins.
Can
you
tell
me
you
said
that
ownership
voucher
is
a
data
structure?
What's
what's
in
this
data
structure,
I
guess
there's
probably
a
cert
and
maybe
an
identifier
of
the
rendezvous
service.
What
what
what
else
is?
Does
the
manufacturer
have
to.
K
K
Sure
so,
there's
a
manufacturer
certificate
information
manufacturer's
key.
There's
there's
a
device
key
in
there,
so
you
can
authenticate
the
device
and
then
basically
what's
happening
is
as
the
device
moves
through
as
the
ownership
voucher
moves
through
the
supply
chain,
you
can
build
up
a
chain
of
signatures
that
shows
a
ledger
of
of
where
the
device
has
been
and-
and
you
can
use
that
ledger
to
show
that
you're
that
you're
actually
the
guy
at
the
end
of
the
chain-
and
you
got
the
last
piece
of
it.
K
So
it's
it's
a
new
kind
of
a
tracking
data
structure,
if
you
had
say
a
a
reliable
supply
chain,
you
probably
would
already
have
this
kind
of
mechanism
since
the
world
doesn't
have
reliable
supply
chains.
Yet
we
wanted
to
have
a
mechanism
that
could
run
through
a
conventional
supply
chain
with
minimal
types
of
verification,
say
all
the
way
down
to
say
a
telephone
level
of
reading
reading
out
information
about
a
key.
K
H
I
thought
there
they.
E
I
appreciate
it
again.
I
think
this.
Let
me
just
get
to
the
start.
I
just
I
was
just
having
some
deep
thoughts
in
the
architecture,
and
I've
been
thinking
about
this
problem
for
a
while,
as
both
jeff
and
dan
know,
and,
of
course,
hannah.
So
we're
all
we're
all
well
familiar
with
each
other.
You
know
we.
We
have
this
sort
of
general
question
that
we
we
hang
out
with.
E
We
all
answered
slightly
differently,
I'm
going
to
talk
about
the
tale
of
two
protocols
in
this
context,
I'm
not
trying
to
favor
one
over
the
other.
I'm
just
saying
that
there
are
some
some
some
challenges
that
that
we
face
and
they
they're
they're
slightly
different
challenges,
but
there
are
some
architectural
components
that
that
I
just
wanted
to
note
any
other
questions.
You
know:
how
does
the
device
know
it
should
trust
a
particular
network
and
how
does
network
know
what
particular
devices
authorize?
E
Two
different
protocols
try
to
answer
this
question
in
two
different
ways:
dpp
and
brewski,
and
if
I
were
to
take
a
stick
to
it
and-
and
you
know
just
whack
it
just
so,
I'm
pretty
sure
I
could
get
fdo
in
the
same
bucket,
I'm
not
quite
sure
about
lwm
to
m.
If
I
can,
if
I
could
do
that,
but
you
know
just
a
as
a
bit
of
a
review
because
I
think
a
lot
of
people
on
a
call
know
these
protocols.
Dpp,
is
the
device
provisioning
protocol.
E
The
wi-fi
alliance
did
dan
was
intimately
involved
in
that
a
lot
of
other
people
were
too
the
basic
concept.
Is
you
know
you
have
a
a
public
key
that
is
associated
to
a
private
key.
The
public
key
appears
say
in
the
box.
E
That
scans,
the
box,
it
scans
the
the
public
key
and
then
it
does
a
little
bit
of
a
diffie-hellman
proof
that
says
you
know:
hey
I've
got
you
know,
I've
got
your
public
key
and
you
know
and
here's
my
proof
and
this
guy
says
well:
I've
got
the
private
key.
Here's
my
proof
and
the
next
step
is
a
configuration
phase
based
on
that,
and
then
this
guy
gives
this
guy
what
it
needs
to
stop
to
this
guy.
E
The
version
of
that
that
we
have
from
brewski
is
slightly
different.
It
works
with
a
voucher.
The
voucher
gets
passed
through,
it
says.
Well,
here
you
know,
can
I
can
I
please
talk
to
this
network.
It's
gonna.
This
guy
is
gonna.
Ask
this
guy
if
this
guy
can
all
can
authorize
this
guy
to
talk
to
this
guy.
This
is
essentially
what
brewski
says.
I
mean
it
does
so
with
a
voucher,
and
so
you
know
you
have
this
flow
and
the
voucher
bits
get
filled
out.
E
We
have
a
couple
of
scaling
problems
throughout
throughout
all
this,
which
is
one
of
which,
in
the
brewski
context,
how
does
this
registrar
know
and
the
the
various
enterprises
right,
because
there
are
gazillions
of
them
and,
conversely,
you
know
how?
How
does
this
enterprise?
How
does
this
manufacturer
know
that
this
that
this
enterprise
is
there
is
the
one
that
actually
bought
the
product?
So
I
just
a
little
bit
of
a
by
way
of
a
comparison
right.
What
I'm
aiming
for
here
is
zero
step.
E
Provisioning
dpp
on
its
own,
using
a
qr
code,
provides
a
sort
of
nice
one-step,
provisioning
mechanism.
You
can
get
to
zero
step
right.
I
think,
but
you
know
it's
a
little
bit
of
challenge
as
to
how
to
do
that
right.
It's
a
question
to
be
answered
and
it
can
work
with
or
without
internet
connectivity.
In
the
moment,
in
fact,
forever,
which
is
which
is
a
really
nice
property
it
has,
it
doesn't
really
have
a
concept
of
ownership
per
se.
E
It
has
a
concept
of
possession,
which
is
you
know
real,
really
nice
too,
because
it
means,
if
you
just
reset
the
device.
You
created
a
change
of
ownership
that
that's
sort
of
nice,
so
you
know
in
the
brewski
sense
you
know.
On
the
other
hand,
this
thing
can
be
zero
step
provisioning
if
you
filled
in
all
the
gaps
in
terms
of
understanding,
you
know
who
the
customer
is
and
the
associated
registrar
is
with
it
the
it
requires
internet
connectivity,
at
least
in
in
in
the
use
case.
E
That
was
envisioned,
though
there
have
been
some
thoughts
about
how
to
relax
that,
if
you
look
inside
a
brewski
voucher,
has
this
notion
of
a
nonce
right
and
that
that
nonce
is,
if
it's
filled
in
there,
then
then
you
have
to
have
a
an
interactive
exchange.
If,
if
it's
not,
then
then
you
don't-
and
this
question
here
was
left
empty
by
the
by
the
specification
right.
How?
How
is
it
you
that
that
you,
I
mean,
there's
this
notion
of
a
proxy
registrar
box,
a
a
proxy
voucher
request?
E
But
how
can
we
get
more
formal
in
terms
of
associating
this
register
with
this
customer
right
and
then
how
do
you?
How
do
you
manage
to
onboard
the
device
without
immediate
internet
access?
You
know
how
do
we
get
around
that
that
that
nuns
problem,
so
my
last
slide?
E
Okay,
you
know
the
83
66
voucher
and
the
dpp
key
are
actually
much
closer
in
in
in
style.
If
we
think
about
zero
touch,
then
then
one
might
first
appear
there.
There
seems
to
me
that
there
is
a
missing
architectural
element,
though,
which
is
this
introduction
that
that
needs
to
occur
between
the
device?
That's
going
to
hold
the
keys
in
the
dpp
case,
you
might
think
of
that
device
as
this
guy
here
or
an
agent
for
that
guy.
E
You
know
in
a
big
enterprise,
you're,
probably
not
going
to
have
every
ap
try
and
manage
all
keys
right
or
and
you're
not
going
to
have
some
guy
just
trying
to
onboard
each
device.
You
know
with
an
app
there's
going
to
be
something
more
there
right,
so
you
have
something
that
akins
to
some
sort
of
aaa
function.
That
also
is
speaking.
You
know
the
dpp
protocol
and
the
dpp
standard
allows
for
that.
E
Well,
that
looks
an
awful
lot
like
a
registrar,
as
things
begin
to
grow
right
and
the
question
then,
for
me,
is
quite
simply
this:
how
do
we
make
this
general
introduction
between
these
manufacturers
and
these
registrars
now
federations?
Do
this
nicely
right,
which
is
nice,
but
it's
also
nice
that
these
federations
be
optional
right,
that
is
to
say
one
of
the
challenges
I
think
we
see
with
with
brewski
is
that
you
have
this
a
lot
of
mechanism
here
to
and
from
the
manufacturer.
E
I
see
a
lot
of
that
mechanism
in
fdo
as
well.
It
has
its
pluses
and
it
has
its
minuses
and
if
I
were
to
add
fdl
to
this
mix,
I'd
say
one
of
the
nice
things
about
fdo.
Is
that
essentially
you
get
a
nice
sort
of
you
know.
You
know
where
this
thing
has
been
a
certificate,
but
the
open
question
here
right
is:
how
might
we
go
about
establishing
the
trusted
introduction
between
all
these
guys?
E
Just
these
guys,
not
the
devices
themselves,
these
guys
right
the
enterprises
right-
maybe
even
consumers
too,
if
we
want
to
stretch
that,
but
as
I
have
enterprise
on
the
brain,
that's
what
I
filled
out
here
and
these
guys
the
manufacturers.
And
so
that's
the
open
question
that
I
have
it's
a
problem
statement.
E
We
solve
it
for
first
so
long
as
we
can
have
a
little
bit
of
of
choice
in
the
process,
because
these
guys
are
going
to
implement
whatever
these
eyes
are
going
to
implement
and
as
long
as
we
have
some
notion
of
consistency
in
in
this
federation
element
or
whatever
it
is
in
terms
of
how
information
gets
propagated
and
introduced.
E
If
we
have
the
right
model,
then
we
can.
We
can
implement
a
couple
of
these
things,
including
perhaps
even
fdo,
and
that's
something
we
might
want
to
talk
to
the
fido
alliance,
people
specifically
jeff
and
others
about.
If,
if
this
makes
sense
for
them
too-
and
maybe
hannah's
has
thoughts
in
terms
of
lwm
to.
I
E
B
J
B
I
can
say
that
I'm
a
huge
fan
of
problem
statements
and
I
think
it's
very
spot-on
to
the
charter.
So
thank
you
a
lot
for
that.
I
think
fleshing
that
out
in
and
document
would
be
a
very
good
first
step.
So
are
there
any
other
questions
on
elliots
or
comments
on
elliot's
item
and
jeff
is
recording.
K
I
think
yep
one
yeah
yeah,
I
I
was
thinking
that
one
of
the
things
asked
you.
I
agree
that
you
do
have
to
get
through
this
like
and
one
of
the
ways
that's
going
to
be
challenging
is
that
the
supply
chain
is
so
enormous.
K
So
one
of
the
ways
to
think
about
that
is
think
about
what
objects
could
be
secured
going
into
a
group
of
companies
that
that
have
a
single
agreement
for
shipping
devices,
shipping
objects
in
the
supply
chain
and
then
how
you
would
get
an
object
out
of
that
and
into
the
next
one.
So
I'm
thinking
that
we
can
put
together
a
few
cooperating
companies
and
then
get
objects
into
them,
get
objects
out
of
them
and
then
go
to
the
next
group
and
the
next
group
in
the
next
group.
E
And
thanks
for
the
time
hank.
B
Yeah
and
thank
you
for
presenting
michael,
are
you
commenting
or
sharing
for
your
presentation.
I
I
So
in
doing
some
of
this
onboarding
work,
one
of
the
problems
that
one
runs
into
is
how
do
you
get
initially
device
identifiers
into
devices
and
one
project
I've
been
involved
in
is
doing
this
for
home,
routers
and
click
just
a
minute.
Oh
okay,
so
you
know
insert
the
mirai
story.
That's
actually
coming
up
to
five
years
ago.
I
It's
kind
of
weird
that
that's
so
long
ago,
but
I'm
involved
in
in
dealing
with
how
do
we
do
security
specifically
mud
stuff,
for
instance,
on
home
routers,
and
how
do
we
onboard
home
routers
so
that
they
stay
secure
the
whole
admin
admin
password
is
simply
not
good
enough
and
making
people
change.
I
It
is
a
great
thing,
but
then
you
just
wind
up
with
the
problem
of
they
now
have
a
strong
password
which
some
malware
on
their
home
network
can
hijack
and
if
you
think
that's
hard
to
do,
the
answer
is
that
arp
spoofing
of
192.168.1.1
is
trivial
and
there's
a
number
of
second
router
products
that
offer
some
kind
of
additional
security
that
intentionally
exploit
that
to
get
into
the
data
path.
I
And
you
know
that's
just
there.
So,
even
if
you
say
I'm
gonna
put
a
better
password,
you
still
have
the
problem
that
you
need
to
enable
https.
Somehow,
oh,
why
can't
I
just
page
down
there?
I
We
go
so
you
wind
up
with
these
two
prop
environments
for
talking
to,
for
instance,
your
home
router,
but
also
to
pretty
much
any
other
iot
device
in
your
home
network
that
you
have
purchased
off
the
the
thing
and
one
is
that
you
wind
up,
they're,
implicitly
insecure,
it's
http
and
you're
just
done,
but
apparently
the
web
page
loads
or
it's
explicitly
insecure
and
you
have
to
click
through
these
things
which,
to
the
most
extent,
the
browser
manufacturers
would
like
to
remove
these
screens
completely.
I
If
they
could-
and
the
last
thing
we
really
really
want
to
do-
is
train
any
of
the
users
to
actually
be
good
at
getting
through
these
screens.
That's
really
the
the
goal
is
that
they
never
ever
see
them.
I
So
the
question
is:
how
can
we
put
a
real
certificate
in
there,
and
so
we
came
up
with
this
mechanism,
and
what
it
is
is
that
before
the
device
leaves
the
factory
in
effect,
we
want
to
boot
it
up
and
we
want
to
do
provisioning
step,
and
this
process
involves
essentially
finding
a
provisioning
server
over
an
ipv6
link,
local
address
that
avoids
us
having
to
run
dhcp
and
a
whole
bunch
of
stuff,
but
also
really
make
sure
that
the
device
is
really
the
device.
I
That's
on
the
table
there
and
eliminates
some
other
other
security
and
other
issues,
and
then
we
do
what
is
essentially
an
est
enrollment
except
we
can't
use
est
literally
because
we
need
a
whole
bunch
of
other
data
that
doesn't
fit
into
a
csr,
for
instance,
and
in
this
case,
what
we
do
is
we
exploit
the
fact
that
home
routers
will
generate
an
ipv6
link.
Excuse
me
ula
address,
which
is
a
relatively
unique
ipv6
address,
and
we
give
them
a
name.
I
If
then,
the
manufacturers
dns
zone
and
we
do
a
a
let's
encrypt
enrollment
and
we
with
a
dns-01
challenge
to
dns,
and
then
we
return
the
resulting
certificate
to
the
device.
There's
writing
code
for
this.
In
fact,
I
believe,
I'm
speaking
to
you
through
a
router
that
was
onboarded
this
way
and
the
the
certificate
winds
up
in
the
router,
and
you
can
talk
to
it
that
way.
I
So
what
happens
so
then,
then
we
do
something
interesting.
We
populate
the
public
dns
the
manufacturer
with
this
ula
address.
In
this
case
this
is
fdd4.
I
You
see
that
address
colon
colon
one
and
we
give
it
that
name,
and
so
this
means
that
now
there
is
a
name
that
is
attached
to
the
an
ip
address
which
is
attached
to
the
name,
that
is
in
the
certificate,
and
when
I
pull
up
my
browser-
and
I
point
my
browser
at
this
at
this
router
by
name-
I
have
connectivity
to
it
and
I
load
the
certificate.
And
lo
and
behold
I
have
a
secure
connection.
I
So
that's
this
this
slide,
and
this
is
what
happens
so
we
have
had
a
little
bit
of
challenges
with
this
there
and
it
turns
out
that,
for
instance,
what,
if
you're
not
on
on
the
internet
when
you
get
connected
well,
the
answer
is
most
of
the
home.
Routers
will
answer
dns
requests
for
names
they
find
in
etc
hosts,
and
so
you
need
to
populate
that
as
well
into
there.
I
And
then
you
have
a
solution
where
you
actually
connect
and
it
works
without
a
problem
on
friday,
ted
lemon
will
be
talking
about
stub
networks,
and
this
actually
can
work
very
well
for
devices
connected
by
stub
networks
as
well.
The
key
thing
is
that
you
have
to
have
that
ula
that
you
control
and
you
have
to
be
able
to
put
it
uniquely
into
a
name
that
you
control.
I
There
are
some
issues.
The
major
one
is
with
a
let's
encrypt
certificate
is
that
it
expires
after
90
days,
and
so,
if
you
put
your
devices
from
the
manufacturing
plant
and
you
put
them
in
a
warehouse
and
they
sit
there
for
more
than
90
days,
then
when
they
come
out,
they
have
an
expired
certificate.
So
we
need
to
do
something
about
that
and
exactly
what
that.
What
that
is
is
unclear.
I
I
But
what
if
the
device
needs
human
intervention
to
get
online?
For
instance,
many
home
routers
in
a
dsl
kind
of
space
need
a
pppoe
username
password
to
be
connected,
so
that
has
a
cause
as
a
chicken
and
egg
situation.
You
need
to
log
into
the
device
to
provide
that
and
you
need
the
certificate
to
be
able
to
log
in,
and
what
are
you
going
to
do?
I
If
you
are
an
isp
and
you're
doing
this
and
you're
deploying
things,
then
you
can
do
you
can
actually
pre-provision
some
of
those
username
passwords,
so
the
device
can
actually
get
online
and
can
do
things
now.
The
reason
we
don't
use
a
private
ca
is
that
we
want
it
to
be
accessible
from
the
browser
and
that
would
not
be
accessible
if
it
was
a
private
ca.
I
So
the
typical
situation
that
happens
in,
for
instance,
with
cable
modems,
which
all
have
idev
ids
built
in,
is
that
those
are
not
connected
to
the
public
web
pki
and
you
can't
manage
them
directly
with
with
your
browser.
I
The
second
problem
we
had
was
that
we
discovered
that
quite
a
number
of
systems
are
unwilling
to
do
ipv6,
dns,
lookups
or
communications
if
they
can't
detect
that
ipv6
is
live.
So
if
you
have
a
scenario
where
you
don't
have
internet
connectivity
or
you
aren't
allowed
to
do
it
yet,
then
these
devices
will
say:
there's
no
such
name,
even
though
you
do
a
dig
or
other.
I
You
know,
command
line,
type
things
and
sure
and
hold
though
that's
there,
but
these
systems
essentially
refuse
to
do
ipv6
if
they
think
that
there
isn't
any
good
ipv6-
and
this
is,
I
think,
a
existential
challenge
to
using
ipv6
and
ulas
in
the
in
the
world.
I
We've
seen
this
with
a
number
of
browsers
and
a
number
of
systems,
but
it's
predominant
with
chrome,
but
we
believe
we've
also
seen
it
at
times
with
the
edge
browser.
But
it's
unclear
and
unconfirmed.
I
We
have
worked
around
this
by
essentially
putting
a
v4
address
and
the
etc
hosts
on
the
on
the
device,
and
then
everything
happens
over
v4
and
that's
kind
of
an
icky
hack,
but
it
did
work.
So
this
is
a
there's,
some
additional
work
that
needs
to
happen.
I
I'd
love
to
have
some
more
co-authors
and
there's
some
overlap
and
some
discussion
that
we
might
have
as
to
how
this
relates
to
danish,
because
we
are
using
dns,
but
we
aren't
really
putting
the
certificate
in
the
dns,
but
that's
a
potential
additional
thing,
but
it
wouldn't
be
very
useful
if
browsers
wouldn't
support
it.
That's
all
I
had
to
say
about
this
and
I
one
minute
over.
B
Yeah
only
one
minute
over.
Thank
you,
michael
for
throwing
out
a
tangible
problem
here.
I
think
people
are
actually
interesting.
The
chat
indicates
already
interest.
So
thank
you
for
for
that.
I'm
very
sorry
that
we
are
basically
already
at
the
bottom
of
the
hour
and
the
session's
officially
over.
But
yet
I
would
like
to
ask
to
maybe
if
people
can
attend
this
room
for
a
few
more
minutes
we
can
throw
out
and
ask
which
is
about
you.
B
Would
you
like
to
attend
a
near
time
happening
virtual
interim
to
which
actually
will
provide
more
floor,
podium
from
open
mic
and
discussion
and
and
picks
up
on
the
items
discussed
here?
Maybe
some
of
the
gaps,
maybe
some
of
the
things
you
thought
would
be
here
that
are
not
or
some
some
first
ones
on
the
items
actually
here
right
now.
B
So
so
what
I
would
do
would
like
to
do
is
to
to
issue
a
a
raised
hand
thingy
here,
that
we
have
in
this
tool
and
and
if
you
raise
your
hand,
it's
basically
two
hums
at
once.
So
if
you
raise
your
hand,
that's
the
first
hand.
You
are
basically
humming
for
yeah
I'd
like
to
do
that
and
if
you
do
not
raise
your
hand
actively
that's
an
option.
B
I
think
it's
a
weird
option,
but
still
it's
there
so
we're
using
that
as
a
second
time
in
one
question
to
basically
now
you
really
don't
want
to
see
something
like
very
early
on
a
virtual
intro
to
make
time
for
that.
So
I
will
start
that
right
now
and
I
would
be
very
happy
if
you
all
raise
or
not
race.
Actually,
your.
B
Hand
so
we're
talking
about
like
and
the
question
says
that
spreads
it
out
like
four
weeks
or
something
in
the
future
and
why
we
do
the
when
we
do
that
paul.
There
are
people
on
the
mic
and
we
can
paralyze
this
as
itf
wants
to
do
eric.