►
From YouTube: IETF-T2TRG-20211026-1500
Description
T2TRG meeting session at IETF
2021/10/26 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
Okay,
so
welcome
everyone.
This
is
the
thing
to
sing
research
group,
what
we
call
a
pre-ietf
summary
meeting,
so
at
english
in
research
group,
we
organized
these
summary
meetings
to
reach
out
to
the
broader
iot
community
around
on
the
opposite.
We
do,
but
then
the
actual
work
happens
in
more
usually
more
focused
meetings,
workshops
and
and
such,
but
these
events
are
good
to
get
an
overview
on
the
activities
that
has
been
happening
between
between
the
summary.
A
As
you
saw
since
we
are
in
an
irtf
meeting,
the
notebook
applies.
The
short
version
is
that
if
technology
works
as
expected,
you
are
being
recorded.
You
should
also
be
nice
to
each
other,
and
there
are
ipr
guidelines
that
do
apply
here
for
more
details.
You
can
have
a
closer
look
at
these
slides.
Essentially,
if
you
are
aware
of
related
ipr,
you
should
be
disclosing
it
and
when
it
comes
to
privacy
and
code
of
contact,
everything
you
do
here
is
essentially
public
and
recordings
will
be
made
public.
A
There's
a
policy
on
how
personal
information
is
handled
and
also
you
agree
to
be
respectful.
Do
it
with
each
other
and
there's
a
bunch
of
links
for
more
details
on
all
of
these
and
finally,
a
quick
reminder
about
the
goals
of
the
irtf.
So
this
is
a
research
group.
So,
even
though
we
do
close
collaboration
with
the
ietf,
where
standards
are
done
in
this
group,
we
do
mostly
research
and
we
do
discussions.
A
Side,
a
quick
administrative
for
notes.
We
do
have
the
idf
and
note
taking
tool.
It's
there's
a
link
in
the
in
the
meeting
materials
and
also
here
on
the
slides.
The
chairs
will
be
taking
notes
in
the
tool,
but
we
also
welcome
everyone
here
in
the
meeting
to
join,
join
and
take
take
the
notes
together.
A
Same
thing
goes
with
jabber.
We
will
be
looking
at
the
chat
and
relaying.
If
you
have
comments
you
want
to
be
related
to
the
meeting,
but
also
everyone
else
feel
free
to
chime
in
and
if
you
haven't
already
subscribe
to
our
mailing
list.
Thinking
arts
at
irtf
or
please
do
that
at
the
following
link.
So
you
will
be
updated
on
all
the
activities
and
we
commonly
have
a
github
repositories
about
all
the
meetings
that
we
organized
and
for
this
particular
meeting
you
will
find
all
the
information
and
materials
on
the
last
link.
A
Then
going
for
the
agenda
for
today
we
are
now
in
the
chairs,
update
slot
quick
update
about
the
research
group
status
and
upcoming
meetings
and
activities.
After
that
we
have
two
longer
slots
for
a
research
talks.
We
have
first
from
chen
gundagan
about
data,
centric,
co-op
transport
and
then
from
steve
hanna
about
a
matter.
A
Okay,
so
after
this
meeting
and
our
plan
is
that
we
would
be
continuing
our
regular
wishy
calls,
we
have
had
them
sometimes
roughly
every
month,
sometimes
a
bit
less
frequent.
We
had
one
just
yesterday
and
we
are
now
planning
for
the
next
one,
perhaps
before
thanksgiving
so
towards
the
end
end
of
november.
A
This
time
we
are
not
planning
to
have
a
tinkering
research
summary
meeting
at
the
ietf
virtual
meeting.
However,
there
is
a
good
chance,
we'll
have
some
wishy
related
activities
at
the
hackathon
on
the
on
the
week
before
ietf,
so
stay
tuned
about
that
we
also
often
have
online
meetings
with
other
organizations,
for
example,
ocf
ole,
miss
backworks,
w3c
web
of
things,
and
there
is
a
one
small
meeting
already
planned
for
for
this
thursday,
together
with
the
web
of
things,
crew.
A
Also,
we've
been
long
discussing
that
we
should
do
more
co-location
with
academic
conferences,
and
this
time
we
actually
do
have.
We
have
the
dye
snack
workshop
on
december
7th
and
you
can
find
more
information
on
the
link
on
the
slide,
but
overall
we'll
be
very
keen
on
doing
more
of
this
co-locating
with
academic
conferences.
A
So
if
you
are
organizing
such
or
you
know
a
and
an
or
a
conference,
which
would
be
a
good
good
fit
for
team,
think
archie
co-location,
please
let
us
know
and
we're
very
happy
to
talk
with
you
and
then
also,
hopefully,
next
year,
we'll
be
able
to
go
also
back
to
more
actual
face-to-face
meetings.
So
whenever
the
current
situation
allows,
we
hope
to
have
also
physical
meetings
upcoming
in
2022.
A
Briefly
about
the
research
group
document
status,
the
restful
design
for
iot
document
was
updated.
Recently
we
did
approve
the
terminology
in
particular,
and
also
added
more
details
on
the
affordances
that
were
not
discussed
in
much
detail
on
that
version.
Yet
the
authors
do
believe
there
could
be
still
many
things
added
there,
but
on
the
other
hand,
we
have
to
draw
the
limit
somewhere
how
much
things
we
act
there,
and
when
do
we
actually
publish
this.
A
So
we
believe
this
probably
time
to
go
towards
publication
of
this
document,
and
the
next
steps
here
are
for
the
have
a
a
chairs
review
and
then
go
towards
last
call.
But
if
you
haven't
look
at
the
document
recently,
please
go
ahead.
Have
a
look,
send
your
comments
to
the
do
the
authors
and
do
the
list
and
let's,
let's
get
that
document
published
likewise
for
the
it's
an
iot
and
there's
some
more
details
coming
that
on
the
on
the
following
slide,
but
also
for
that.
A
A
Also,
we
have
had
in
the
wish
a
discussion
about
this
iot
information
model,
standard
description,
that
is
in
the
plans
of
turning
into
tingling
research
group
document
and
in
addition,
in
the
in
the
wishy
work,
we
have
had
a
large
set
of
discussions
and
some
documents
in
the
wishy
wiki.
We
do
have
a
plan
on
turning
some
of
those
wishy
notes
into
research
group
documents,
also,
if
you're
interested
in
particularly
any
of
this
work,
just
approach
the
shares
and
we'll
be
more
than
happy
to
connect
you
with
the
right
people.
A
Then
briefly
about
the
two
drafts,
so
we
asked
the
authors
to
give
us
a
few
bullets
on
the
current
status,
and
this
is
the
one
for
the
iot
challenges
and
functions.
So
a
new
revision
was
published
in
august,
then
that
revision
now
reflects
the
feedback
from
the
1m2m
community
members,
in
particular
new
use
cases
in
section
2.4,
and
also
more
details
on
section
4
about
this
one
mtm
service
layer
and
related
to
the
text
to
relate
to
relevant
functions.
A
Also,
there
was
a
good
review
last
week
from
roberto
moravito
that
the
authors
are
now
planning
to
address
and
and
post
a
new
version,
but
that
seems
to
be
the
only
open
comments
at
the
moment.
So
from
chairs
point
of
view.
After
those
comments
are
addressed,
we
think
we
would
be
ready
to
move
towards
last
call
with
this
document
and
get
it
published.
C
I
do
want
to
say
I
did
not
get
around
to
samia
review,
but
I
didn't
read
it
twice.
I
just
didn't
manage
to
get
the
detailed
notes
up.
I
have
not
left
read
latest
version
number
three,
but
I
was
most.
My
comments
were
small
matters
in
the
previous
version,
so
I
think
I'm
okay,
with
version
three
being
published.
A
C
D
C
A
A
Okay,
then,
on
the
the
other
draft
that
used
to
be
known
as
secure,
bootstrapping
and
nowadays
known
as
terminology
and
processes
for
initial
security
setup
for
iot
devices
of
other
devices,
there
was
a
major
revision
submitted
just
some
short
time
ago.
There's
a
new
title
in
particular
bootstrapping
was
renamed
into
ini
security
setup.
A
There
is
a
description
on
how
you
do
the
initial
security
setup
in
bluetooth
mesh
and
also
at
least
some
terminology
by
each
standard
protocol
that
was
identified
and
unlisted
and
also
in
the
next
version.
The
idea
is
to
be
identify,
initial
assumptions
and
knowledge
on
the
device.
After
a
setup,
the
authors
are
now
looking
for
feedback
in
particular.
If
your
favorite
protocol
or
standard
is
missing,
please
do
reach
out
to
the
authors.
E
Hi
guys,
everybody
good
morning,
good
afternoon,
good
evening,
just
a
question
about
this
trap.
I
haven't
looked
at
the
revision
update
yet
is
this
the
grand
sum
total
of
the
changes
that
we're
talking
about
or
is
there
is
there
more?
I
mean
if
it
was
a
major
revision?
Maybe
the
authors
might
want
to
say
a
few
more
words.
F
Can
you
hear
me
yep,
yeah,
okay,
thanks
elliot
for
the
question,
so
basically
what
we
had
agreed
over
the
last
couple
of
meetings
was
that
maybe
calling
the
draft
bootstrapping
is
not
the
best
idea,
because
some
protocols
and
standards
use,
onboarding
and
and
obviously
some
others
use
provisioning.
So,
thanks
to
karsten,
he
suggested
the
idea
of
using
the
term
initial
security
setup,
so
the
abstract
and
and
basically
the
introduction
now
has
removed
the
reference
to
bootstrapping
and
and
now
uses.
F
Is
it
the
manufacturer,
user
owner
are
their
servers
involved
and
what
kind
of
terminology
does
each
of
the
protocol
use
and
and
what
kind
of
information
is
imparted
to
the
devices
once
this
process
is
finished,
so
some
of
them
might
provision
like
entire
access
control
list,
while
others
may
just
provision
a
single
key
which
you
can
then
use
against
authorization
server.
So
what
we
have
done
in
this
update
is
basically
restructure,
so
get
rid
of
the
old
categorization
of
managed
and
and
peer-to-peer
and
ad
hoc.
F
F
So,
if,
if
the
device
is
supposed
to
be
shipped
with
a
vendor
certificate,
then
that's
an
that's
an
initial
assumption
and
and
these
we
still
need
to
fill
in
it
takes
a
little
while
to
go
through
each
standard
and
kind
of
figure
out
the
details.
But
I
think
the
structure
is
more
or
less
ready.
It's
more
like
going
through
each
of
the
standard
and
then
filling
up
the
missing
information.
A
A
G
G
So
first,
when
I
say
data
centric,
let's
have
a
look.
What
what
that
means
and
by
data
centering
we
first
look
at
a
paradigm.
That's
called
information
theory
networking,
it's
an
alternative
paradigm
and
it's
basically
deployed
on
the
networking
layer
and
replaces,
as
you
can
see
in
the
stack,
replaces
the
host
centric
ip
networking.
It
is
highly
specialized
on
content
delivery
by
providing
very
loose
coupling
of
data
and
the
data
producers.
G
There
are
a
couple
of
architectures
that
implement
the
icn
paradigm
and
the
most
well-known
are
name
data
networking
which
is
abbreviated,
ndn
and
content-centric.
Networking
ccnx.
The
key
features
of
these
protocols
are
that
they
have
a
name-based
forwarding.
They
have
the
stateful
forwarding
which
operates
hop-wise.
They
have
caching,
that's
also
hop-wise
and
they
have
or
they
use
security
on
an
object
level.
G
G
They
have
a
flow
balance
and
the
request
date.
They
build
request
date
on
on
each
hop.
So
every
time
a
node
forwards,
an
interest
message,
there's
a
state
built
on
that
node
to
eventually
build
a
reverse
path
for
the
response
message.
We
have
the
caches.
So
when
an
interest
hits
the
cache,
then
the
data
is
returned
along
these
yeah
the
states
and
we
have
a
hopwice
re-transmission
mechanism.
So
when
we
lose
a
message
in
a
data
message,
then
the
retransmission
happens.
So
we
send
another
interest
and
the
good
thing
now
we
have
the
caches.
G
So
the
current
research
indicates
that
these
they're,
like
these
information,
separate
properties,
the
stable
forwarding,
the
caching
and
object
security.
They
are
actually
promising
and
kind
of
good
candidates
for
iot
deployments,
the
stable
forwarding
and
caching,
they
shorten
the
request
paths,
as
I
said
before,
so
they
reduce
the
link
traversals
and
the
number
of
transmissions
and
packets
in
the
in
yeah.
G
G
And
while
we
were
like
looking
into
these
kind
of
icn
networks
in
the
iot,
we
figured
that
actually,
the
co-op
standard
already
gives
a
lot
of
the
features
that
we
like
sorted
out
here.
If
you
look,
for
example,
at
core
proxy,
which
is
in
the
main
rfc
of
co-op,
then
they
already
provide
a
caching
mechanism.
G
G
Co-Op
deployment
option-
and
this
is
the
next
thing
on
jet
on
the
agenda
after
that-
I
will
show
you
how
we
made
this
possible
to
have
a
multi-party
communication
using
this
data
centric
co-op
deployment.
It
wasn't
so
easily
achieved,
but
you
will
see,
and
then
I
will
show
like
a
brief
use
case
by
how
we
send
the
firmware
updates
using
this
deployment
option.
G
So
again,
very
brief.
The
typical
core
deployment
looks
like
this.
We
have
a
client,
we
have
a
server
and
in
the
middle
we
have
ip4
orders.
Anything
is
happening
end
to
end
and
also
the
retransmissions
are
happening
and
to
end.
We
have
the
request
and
we
have
the
response
and
with
the
new
deployment
option,
we
the
data
center
deployment
option.
We
have
again
a
client
at
the
server,
but
in
the
middle
we
have
now
co-op
proxies.
G
So
we
are
building
a
path
of
of
proxies,
and
this
gives
us
the
the
stateful
forwarding
that
we
saw
before
in
in
the
end
of
season
x
and
everything
is
happening,
hop
wise.
Now
we
have
hopewise,
caching
and
even
the
retransmissions
are
performed
pop
files
and
we
have
forwarding
that
is
now
happening
on
names.
G
So
again,
it's
very
similar
to
to
ndn,
and
this
is
something
that
we
implemented
and
deployed
and
in
the
scope
of
this
paper
here,
which
we
submitted
last
year's
to
the
icn
conference,
and
if
you
look
at
this
in
more
detail
than
we
see
the
following,
so
there
are
three
data
structures.
They
are
basically
the
same
data
structures
that
also,
and
the
anesthesia
and
x
use.
G
Let's
first
start
with
the
cache,
because
there's
already
present
in
the
in
the
core
policy
and
pretty
good,
well-defined
and
the
request
table
is
something
or
let's
say
this
way.
I
think
the
the
proxy
operation
itself
is
in
the
rfc
of
of
co-op
is
a
little
bit
unspecified
regarding
how
the
proxy
is
handling
or
the
the
request
that
it
receives
and
how
they
are
stored
and
what
information
we
need
to
store
and
stuff
like
this.
G
G
G
The
next
node
sends
an
empty
acknowledgement
to
yeah
to
fulfill
the
the
confirmable
gets
and
then
stores
that
information,
where
the
request
comes
from
into
the
request
table
and
forwards
that
again
to
the
next
node
and
once
we
are
at
the
end,
node,
let's
say
so:
the
node
before
the
the
actual
server
or
maybe
here's
a
gateway.
And
then
we
have
the
internet,
and
this
node
is
resolving
the
the
forward
proxy
uri
and
puts
it
into
a
path
and
can
use
the
global
ip
address
to
to
request
the
actual
content.
G
So
when
the
server
receives
a
typical
request
that
we
would
also
get
from
a
normal
co-op
deployment,
this
node
sends
back
a
response
and
the
response
then
traverses
back
the
reverse:
the
reverse
path
that
was
built
in
the
request
tables.
So
we
know
where
the
request
came
from
and
we
can
send
back
the
data
there.
We
consume
the
request
date
and
this
is
done
until
it's
received
at
the
origin
of
the
request.
G
So
this
is
the
whole
chain
and
how
it
looks
like
we
of
course,
have
there's
oscar
to
provide
security
so,
and
what
oscar
is
doing
is
that
it
wraps
co-op
and
co-op
and
it
rewrites
the
method
into
a
post
method
and
there's
like
this
small
tradeoff,
you
can
have.
I
mean
the
proxy
yuri
itself
is
outside
the
oscar
score
context,
but
you
can
have
this
trade-off
of
whether
we
should
put
everything
like
the
whole
host
part
into
the
proxy
uri
or
also
the
the
path
itself.
G
G
So
here's
a
very
short
package,
the
section.
The
only
thing
I
want
to
show
you
actually
here
is
in
the
middle
part.
You
see
the
co-op
data
center
deployment,
you
see
the
on
route,
forwarders
and
the
packets
forget
and
the
response
packages
and
then
the
last
hop
the
last
stop
is
the
same
as
the
typical
co-op
deployment,
because
it
resolves
the
proxy
uri.
G
G
Here's
another
year
like
insight
that
we
got
in
this
paper,
it's
a
little
bit
unrelated,
but
we
were
like
testing
the
setup
against
a
typical
details,
setup
and,
of
course,
oscor
is
operating
next
to
co-op,
so
that
re-transmissions,
which
happen
actually
can
happen
frequently
in
these
setups,
that
the
re-transmissions
don't
need
to
like
re-invoke
the
whole
security
measurements
again.
But
for
dtls
because
of
this
layout
approach,
every
re-transmission
has
to
re-traverse
the
dts
record,
which
again
introduces
overhead
computational
overhead.
G
It's
some
one
point
it's
aggregated
and
then
we
only
have
one
request
that
goes
out
and
when
the
responses
come
back,
they
fan
out.
At
the
same
time,
we
can
have
a
request
fan
out
mechanism,
so
the
request
is
received
for
water
and
then
they
fan
out
and
we
have
response
duplication
mechanisms.
So
this
is
what
ndn
gives
you,
but
then
we
figured
out
okay.
If
we
use
the
typical
oscar
and
integrate
this
into
the
soh
setup,
then
we
have
a
problem
because
oscor
actually
has
a
very
strict
message
binding.
F
G
G
So
basically,
the
all
the
nodes
of
a
specific
group
assume
a
virtual
client,
the
role
of
a
virtual
client
and
they
have
the
same
keying
material
and
every
request
that
is
generated
by
using
this
virtual
client
role
looks
the
same,
and
so
now
we
can
have
the
actual
cache
utilization
that
we
want
and
also
we
can
do
the
request
aggregations,
because
the
requests
now
look
the
same,
and
this
looks
the
following.
So
in
the
picture
below
we
can
see
the
example
where
request
comes
in
on
the
folding
note.
G
G
G
G
We
use
the
right
operating
system
for
doing
the
measurements.
We
have
this
topology
on
the
right,
so
we
have
nine
clients,
one
one
server
and
some
four
orders
in
the
middle
and
the
scenario
was
that
each
client
requests
an
instruction.
So
it's
a
data
that
is
the
same
for
all
of
them,
so
this
could
be
like
a
light
fixture
and
they
want
to
have
the
yeah
the
instruction
for
a
specific
time.
G
So
what
we
see
is
on
the
x-axis.
You
can
see
the
content
retrieval
time
so
how
long
it
takes
until
the
instruction
is
received
by
a
client
on
the
y-axis.
You
see
the
cdf
and
the
distribution
function,
and
then
we
can
see
the
protocols
for
oscor
and
oscar
proxy
oscor
is
like
is
only
the
end-to-end
co-op
deployment
or
score
proxies.
The
end
is
it
is
a
hop-wise
co-op
deployment,
but
it's
not
utilizing
the
the
cache
with
the
oscar
draft
and
then
we
have
ndn,
and
then
we
have
the
oscar
proxy
with
the
cachable
oscar
draft.
G
So
we
can
see
that
for
the
first
two
protocols,
the
content,
retrieval
times
I
mean
we
can
see
re-transmissions
happening.
This
is
what's
happening
every
two
seconds.
We
have
this.
The
steps
this
these
are
the
retransmissions,
but
also
we
see
that
not
all
retrievals
are
actually
received,
so
we
don't
go
up
200
percent,
but
stay
at
almost
30
percent
of
of
content
that
is
actually
received.
If
you
look
at
the
ndn
and
the
cacheable
score,
then
we
can
see
that
they
go
up
until
almost
100
of
instructions
that
are
received.
G
Also,
if
we
look
at
the
the
sub
second
range,
we
can
see
that
the
latency
decreases
a
lot,
and
this
is
because
that,
on
the
long
paths
that
we
had
in
topology,
there
are
is
already
the
the
content
available.
The
instructions
from
from
previous
client
requests,
and
so
we
don't
need
to
traverse
the
whole
path.
G
G
So
in
this
paper
we
followed
the
suit
philosophy.
So
we
have
a
manifest
file
to
request
meta
information
on
a
specific
firmware,
and
once
we
receive
information,
we
can
request
that
multiple,
the
firmware
itself,
which
is
chunked
because
it's
typically
typically
too
big
for
for
the
mtu
of
those
link
layers
with
the
co-op
case.
We
would
probably
use
block
wise
transfer
to
do
this
with
the
core
deployment.
G
Since
we
have
the
statement
forwarding,
we
can
actually
decide
how
we
the
how
the
retrievals
are
happening.
So
we
can
have
the
typical
I
mean
the
concurrent
retrievals
is
when
each
node
somehow
discovers
there's
a
new
version,
and
now
they
autonomously
request
all
the
firmwares,
and
this
can
happen
simultaneously.
So
we
can
have
simultaneous
updates
happening
on
the
same
path
from
multiple
nodes
or
we
can
have
this
cascading
retrievals,
where
actually
an
upstream
node
is
blocking
downstream
requests.
F
G
With
this
topology
again
on
the
testbed,
we
use
riot
30
devices
in
the
use
cases.
This
use
case
is
that
each
device
is
requesting
a
firmware,
and
I
marked
this
specific
path
here
in
red,
and
this
is
what
we
will
look
at
in
the
next
plots,
because
it's
the
longest
one
of
the
longest
paths
and
will
probably
have
the
highest
stress.
G
F
G
F
G
The
guiding
retrieval
strategies
and
we
have
the
nodes
and
one
two
and
seven
and
seven
as
you
know,
that's
the
farthest
away.
So
we
can
see
for
the
concurrent
case
that
the
retrievals
I
mean
first,
the
the
download
process
takes
a
long
time.
So,
if
you
look
at
the
n7
node,
we
can
see
that
the
chunk,
retrieval
average
is
actually
a
two.
So
we
only
receiving
two
chunks
per
second
and
it
takes
almost
30
minutes
for
that
node
to
complete.
So
that's
yeah,
the
worst
case,
because
it's
also
the
fastest
farthest
away.
F
G
G
So
basically,
how
will
this
look
like
for
an
end-to-end
deployment,
for
example
by
using
core,
so
we
have
the
same
or
a
firmware
image
of
128
kilobyte
and
we
have
again
the
concurrent
and
cascading
strategies
we
have
at
the
update
completion
time
in
minutes
of
the
on
the
x-axis
and
the
cdf
and
the
y-axis,
and
now
we
have
these
two
scenarios,
one.
In
the
first
scenario,
we
are
deploying
a
common
binary,
so
binary
that's
used
by
all
the
same
nodes,
all
the
nodes,
so
we
can
actually
leverage
the
caching.
G
This
is
what
we
saw
before
the
nodes
finish
or
the
latest
download
finishes
at
almost
32
minutes
and
now,
if
you
deploy
the
individual
binary,
so
each
node
is
having
a
single
binary.
So
we
can
cash.
Well,
we
can
cash,
but
we
can't
utilize
the
caches.
Then
we
can
see
that
this
explodes
until
the
more
than
two
two
hours.
G
G
Now
you
probably
wondered
how
the
forwarding
information
on
the
proxy
level
is
is
maintained
and
handled.
There's
no
solution.
Yet
we
did
everything
with
static
routes,
but
we
plan
to
look
into
how
to
actually
discover
this,
these
hopwise
proxies
and
to
build
some
form
of
dynamic
path
to
the
to
the
content
and
also
in
the
proxy
uri
we're
using
global
ip
addresses.
G
A
Thank
you
chiang
very,
very
interesting
presentation
and
topic.
So
anyone,
if
you
have
questions,
feel
free
to
join
the
queue
we'll
be
taking
questions
from
them
iq,
but
while
waiting
for
people
to
join,
I
had
one
question
on
this:
that
it
seems
that
you're
reusing
a
lot
of
existing
co-op
functionality.
So
I
was
wondering
like
what
is
the
impact
on
implementation.
So,
if
I
do
have
a,
for
example,
a
co-op
proxy
that
already
supports
playing
co-op
and
an
oscore,
how
much
extra
do
I
need
to
do
to
actually
support?
G
A
G
G
G
Maybe
it's
even
possible
to
re
to
use
resource
directories
to
to
learn
which
yeah,
which
resources
are
are
out
there
and
maybe
then
build
a
path
towards
that,
but
I
don't
know
yet.
I
can
tell
more,
I
think,
on
the
topic,
but
it's
definitely
yeah
it's
an
open
issue
and
something
that
needs
to
be
addressed.
If
this
is
of
interest,
that's
yeah.
I
agree
with
that.
D
Yeah
my
question
is
designed
to
be
the
the
last
one
and
I
think
from
the
timing.
It
probably
is
so
there
is
the
large
body
of
icn
research
out
there
and
one
wonders
what
what
what
are
the
next
pieces
of
that
research
that
that
you?
Actually,
you
will
start
to
borrow
what
are
the
most
useful
elements
that
we
could
use
for
this
kind
of
data,
centric,
chord-based,
environment.
G
G
D
A
I
A
I
Yes,
thank
you.
Okay,
very
good.
The
full
screen
view
I
presume.
Yes,
I
see
it
so
I'm
thankful
for
your
invitation
to
come
here
and
to
talk
a
little
bit
about
matter.
The
set
of
open
standards
for
smart
home
security
or
for
smart
home.
Rather,
I
should
say
security
is
my
special
interest.
So
that's
what
I'll
be
talking
about
security
and
privacy
topics.
I
I
Specifications
are
not
yet
widely
available
only
to
members,
they
will
be
available
to
everyone
once
they're
complete
in
the
1.0
version.
So
this
is
an
opportunity
to
get
a
sneak
peek
at
how
the
security
and
privacy
works
there
and
I
think,
there's
some
interesting
innovations
that
you'll
enjoy
hearing
about.
I
I
I
That
being
said,
it
does
include
some
native
support
for
wi-fi
thread
and
ble
and
other
underlying
medium
aba
added
later
in
that
when,
as
you'll
see
later,
when
you
bring
a
batter
device
into
your
home,
we
can
automatically
provision
wi-fi
credentials
into
it.
So
that's
not
a
separate
step,
but
can
be
handled
as
a
seamless
and
single
process.
I
We
use
an
open
source
development
approach
and
the
source
code
is
already
available.
I'll
include
the
link
in
a
few
slides
and
the
source
code
is
based
on
technologies
and
source
code
already
used
by
the
members.
So
a
lot
of
contributions
from
the
members
there.
We
didn't
have
to
start
from
scratch
and
it's
designed
because
it's
ip
based
to
not
have
to
go
through
a
bridge,
necessarily
a
protocol
translation
module
to
get
from
your
device.
I
However
small,
that
device
might
be
to
your
mobile
and
eventually
all
the
way
up
to
the
cloud.
So
you
can
have
end-to-end
security
matter
as
an
application
layer
protocol
doesn't
just
include,
say,
security
protocols
like
tls
would
but
also
has
a
data
model,
and
this
means
that
we
have
a
set
of
nouns
and
verbs
specific
to
certain
device
types,
such
as
say
a
light
bulb
which
would
have
on
and
off
or
adjustments
to
the
intensity
or
perhaps
the
color
of
the
of
the
light
bulb
and
similar
other
device.
Types.
I
Zigbee
already
had
a
set
of
a
common
data
model,
and
this
is
being
extended
for
matter.
It's
designed
to
be
a
low
overhead
or
relatively
low
overhead
implementation.
When
you're,
adding
ipv6.
There
is
a
certain
element
of
overhead
and
adding
security
on
top
of
that,
as
well,
is
a
bit
of
a
burden,
but
still
we're
aiming
to
keep
the
burden
as
low
as
possible,
aiming
for
less
than
128k
of
ram
and
less
than
a
megabyte
of
flash
or
non-volatile
memory.
I
I
So
we'll
talk
more
about
the
setup
experience
in
the
next
slides
and
how
that
relates
to
security,
but
just
to
say
that
this
has
been
a
barrier
in
the
past.
Consumers
will
go
out
and
buy
an
iot
device,
bring
it
home
and
they
can't
figure
out
how
to
make
it
work
or
at
least
how
to
make
it
work
with
the
devices
they
want
it
to
work
with.
In
fact,
it
might
not
be
compatible
with
those
devices,
but
also
the
setup.
I
It's
just
confusing
because
there's
so
many
ways
that
it
can
work
I'll,
talk
more
about
the
multi-admin
feature
in
a
few
moments
and
go
into
some
more
detail.
But
essentially
this
is
a
new
feature
which
is
designed
to
ensure
that
your
devices,
such
as
a
bulb,
will
be
able
to
work
with
whatever
administrative
and
control
devices
you
might
have.
I
I
All
right,
keeping
it
moving
matter
supports
an
initial
set
of
device
types.
These
are
the
ones
listed
on
this
slide
and
other
device
types
will
be
added
later.
This
is
an
ongoing
process
and
we
do
expect
that
controllers
will
be
not
only
in
the
form
of
switches
and
dials,
but
also
say
smart
speakers,
smart
screens,.
I
Even
laptops
and
mobile
phones
and
tablets,
we'll
all
be
able
to
control
these
devices
and
control
devices
from
multiple
vendors,
of
course,
multi-vendor
interoperability
is
essential.
Here
I
mentioned
it's
an
open
source
project
and
here's
the
link
you
can
go
to
to
find
the
open
source
and
to
look
at
it
today.
I
It's
intended
to
be
quite
open
and
accessible.
That's
why
we've
made
the
code
already
available.
It's
a
apache
2.0
license
and
includes
lots
of
examples.
It's
one
of
our
reference
platforms
is
the
raspberry
pi.
So
if
you
have
a
raspberry,
pi
and
probably
most
of
us,
do
you
can
download
the
code,
build
it
and
run
it
on
the
raspberry
pi
today
and
well.
I
think
I've
mentioned
all
the
rest
here.
I
All
right
timeline,
the
specs
are
already
available
to
our
csa
members
and,
of
course
we
would
welcome
you
to
join.
If
you
wish,
the
members
have
been
working
on
the
sdk.
We
don't
intend
to
release
the
spec
until
the
sdk
is
ready
to
release
as
well,
because
well
as
ietf
would
say,
we
need
to
have
proof
in
the
form
of
running
code,
that
the
specification
is
a
good
one
and
actually
works.
I
At
that
time,
in
the
first
half
of
2022,
when
the
sdk
and
the
spec
are
released,
we
should
have
some
products
already
read
ready
for
certification,
because
they're
already
undergoing
testing
now
and
when
I
say
certification
well,
that
every
matter
device
everything
that
has
a
logo
on
it,
that
or
logo
on
it
will
be
tested.
Just
like
wi-fi
devices
are
tested
to
make
sure
that
they're
interoperable
it
doesn't
mean
you
can't
create
your
own
prototypes
at
home,
but
they
won't
be
supported
with
a
consumer
in
a
consumer
environment.
I
So
these
are
the
principles
upon
which
our
design
rests
a
comprehensive
approach.
We
don't
just
think
about
the
security
of
the
device,
but
we
think
about
the
security
of
the
network
and
of
the
cloud
and
of
the
the
privacy
of
all
of
those
as
well
in
including
guinea
gateways.
If
there
may
be
some
present,
we're
designing
it
to
be
as
strong
as
we
can
using
well-tested
standard,
crypto,
algorithms
and
protocols
and
ease
of
use,
as
I
mentioned
earlier,
is
a
requirement.
I
In
fact
one
could
say
we
intend
it
to
be
a
hallmark
of
matter,
so
that
ease
of
use
drives
design
decisions
in
the
protocols
and
the
design
and
the
standards
for
designing
matter
systems
to
be
resilient.
We
recognize
that
it
will
be
impossible
to
prevent
every
infection
and
we
want
to
make
sure
that
it's
possible
to
detect
compromise
and
to
recover
from
it
and
to
be
agile
well
with
quantum
computing
just
over
the
horizon
at
a
practical
scale.
I
It's
essential
that
anybody
who's
designing
a
secure
system
today
include
support,
at
the
very
least
for
post-quantum
crypto
to
be
added.
But
in
addition,
we
recognize
that
there
are
always
new
developments
and
especially
in
the
field
of
security,
new
threats
that
come
along
and
the
protocols,
the
standards
and
the
devices,
even
after
already
in
the
field,
need
to
be
designed
to
adapt
to
those
new
developments
and
threats.
I
I
Well,
when
we
consider
threats,
we
consider
all
different
sorts
of
threats,
any
attacker
or
actor
who's,
trying
to
compromise
the
system
in
any
way-
and
this
wouldn't
just
be
your
typical
cloak
and
dagger
government
attacker
or
a
a
an
attacker
from
overseas
performing
some
remote
attack,
it
might
be
say,
a
former
lover
or
a
spouse,
someone
who
stayed
in
your
home.
Perhaps
you
gave
them
access
as
a
guest
house,
guest
and
and
now
you
wanted
to
revoke
it.
I
It
could
be
some
other
trusted
party,
such
as
a
a
cleaning
person
that
you
gave
temporary
access
to
your
home,
and
now
you
need
to
revoke
it
or
somebody
who
snuck
into
your
home,
and
you
don't
want
that
to
become
a
permanent.
Cyber
intrusion
could
even
be
a
house
guest
who's
only
there
for
a
dinner
party,
and
you
don't
want
them
to
be
able
to
compromise
your
home.
I
They
may
have
varying
levels
of
access,
resources
and
skills.
We
recognize
that
and
of
course
we
have
to
consider
supplier
security
as
well.
If
the
supplier
of
your
devices
should
be
hacked
compromised,
have
their
development
environment
compromised,
for
example?
How
is
that
handled
or
your
cloud
provider?
I
I
I
So
when
we
look
at
the
threats
and
we've
categorized
now
something
about
200
threats
to
the
matter
system,
we
categorize
them,
we
analyze
them
and
categorize
them
in
three
ways:
severity
likelihood
and
impact
where,
let's
start
from
the
bottom
impact,
what
would
be
the
effect
of
a
successful
attack
is,
what's
the
scope
of
it?
Does
it
just
let
the
attacker
control
one
device
or
your
whole
home
network
or
the
whole
fleet
of
devices
of
that
type?
I
So
a
device
comes
from
the
factory
with
certain
set
of
credentials.
These
pki
credentials
issue
from
a
trusted
route
here
and
there
can
be
multiple
trusted
routes
which
are
distributed
through
a
distributed.
Compliance
ledger
in
this
case.
It's
a
self-signed
cert
from
bolby
and
the
pki
descends
to
a
leave
certificate
unique
to
that
device
and
identifying
what
vendor
it's
from
and
what
product
id
or
product
type.
It
has.
I
Those
correspond
to
a
private
key,
of
course,
unique
to
the
device
and
stored
on
the
device
and
a
certification
declaration
for
this
product
type,
as
well
as
a
verifier
that
will
be
used
later
when
we
bring
the
device
into
the
home
well
the
process
of
bringing
it
in
and
commissioning.
It
is
easy
from
a
user
standpoint
to
just
scan
it
scan
the
qr
code.
That
is
that
we
saw
in
the
last
slide
and
then
it
indicate
yes,
I
do
want
to
commission
this
light
bulb
and
it's
commissioned
into
the
home.
I
I
This
is
similar
to
the
ldap
id
or
local
device
id.
Now
you
see
the
device
has
a
set
of
credentials
specific
to
this
home
or
fabric.
The
fabric.
Id
is
a
64-bit
number
chosen
by
the
commissioner
or
someone
that
it
trusts
and
a
unique
node
id
another
64-bit
id
unique
to
this
device
within
the
home,
and
this
chain
goes
back
to
a
root
ca
which
could
be
located
in
the
home
or
elsewhere.
It
depends
on
how
the
particular
fabric
is
operated
by
that
administrator.
I
Each
ecosystem
will
have
its
own
decision
for
where
the
root
ca
is
located.
There's
a
private
key,
of
course,
corresponding
to
the
operational
cert
and
an
access
control
list
that
determines
who
can
do
what
on
that
bulb.
Like
turn
it
on
or
off
or
change
its
color
or
with
a
higher
level
of
privilege,
perhaps
change
its
access
control
list,
and
I
mentioned
already
the
operational
network
credentials
such
as
wi-fi
credentials
that
are
used
by
the
bulb
to
connect
into
the
home.
I
That's
the
device
attestation
insert
that
I
talked
about
earlier
in
the
certification
declaration
ability
to
check
up
to
date
info
on
revocation
of
those
credentials
device
attestation
credentials
through
the
distributed
compliance
ledger
a
strong
device
identity,
the
secondary
identity,
that's
used
within
the
home
to
ensure
that
only
your
devices
can
communicate
within
your
home
and
that
secondary
identity
is
used
in
the
unicast
communications.
Much
as
it
would
be
in
tls.
In
fact,
our
unicast
security
design
is
based
on
tls
and
uses
the
same
signal
protocol
as
tls
1.3
and
secured
group
communications.
I
The
this
provides
assurance
that
using
a
symmetric
group
key
that
the
sender
and
receiver
are
both
members
of
the
group.
It
doesn't
provide
sender
or
authentication
at
least
to
this
version,
but
it
does
provide
assurance
of
group
membership
and
the
ability
to
quickly
revoke
group
membership,
as
needed
talked
already
about
the
ability
to
have
multiple
administrators
even
from
different
ecosystems
simultaneously
and
about
access
controls
and
secure
software
updates
by
a
standard
mechanism,
or
if
you
wish
a
proprietary
one.
An
additional
thing
that's
provided
is
remote
attestation.
A
A
I
A
I
still
thinking
about,
like
you
know
the
idea.
We've
been
working
on
co-op
and
there's
a
few
other
transfer
protocols
that
are
used
by
different
ecosystems,
right
kind
of
wondering.
What
kind
of
protocols
have
you
chosen
to
use
there
or
is
it
something
completely
different
than
what
everyone
else
is
using.
I
I
believe
it
may
not
be
quite
firm
exactly
when
that
white
paper
will
be
out,
but
we
do
expect
to
have
that
out
well
before
the
the
springtime
and
then,
of
course,
you'll
be
able
to
see
the
whole
spec
once
that
comes
out
yeah,
very
good
thanks
a
lot,
and
we
welcome
engagement
with
the
research
community.
Of
course,.
D
I
Yeah,
okay,
I'll
try
to
go
back
there
we
go.
No,
the
private
key
can
be
generated
on
the
device
yeah
for
the
officer.
That's
what
he
was
asking
about.
Okay,
in
fact
it
is
in
in
this
case
it
would
always
be
generated
on
the
device
it's
for
the
device
attestation,
certainly
because
of
manufacturing
difficulties.
D
D
There
are
some
that
are
kind
of
your
personal
bubble,
like
your
smartphone
and
your
smart
speaker
and
so
on.
So
you
would
take
those
with
you,
but
there
are
other
iot
devices
that
actually
installed
in
the
home
and
one
interesting
ownership
transfer
is
the
involuntary
ownership
transfer
where
the
whole
home
changes
its
ownership
in
in
an
involuntary
way.
Is
this
something
you
have
considered.
I
It
is
and
I'll
be
honest
there
and
say
that
I
don't
think,
we've
completely
solved
that
problem.
We
have
a
solution
for
the
time
being,
which
involves
physical
access
to
the
device,
and
you
know
then
resetting
each
device
individually.
But
this
is
a
painful
process
and
we'd
like
to
have
something
better
in
the
future.
B
It
wasn't
really
a
question
so
much
as
a
request
of
you
to
to
to
make
sure
that's
an
important
part
of
it
and
as
to
carson's
comment
about
involuntary
stuff.
So
I
have
a
document
about
this
and
some
of
the
problems
and
I'd
love
some
some
more
communication
about
that
and
there's
actually
some
people
at
columbia
who
have
apparently
been
doing.
I
saw
a
talk
from,
I
can't
say
his
name
henning
there,
professor,
and
they
have
some
interesting
solutions.
B
I
D
I
A
A
A
A
Indeed,
very
good
thanks
karsten,
so
a
a
quick
update
on
on
this
recent
work
on
the
iot
semantic
hybrid
interoperability.
So
this
is
an
ongoing
activity.
We
have
in
the
tingling
research
group
looking
at
the
semantic
and
hyper-media
interoperability
aspects.
Since
the
previous
summary
meeting,
we
have
had
two
wishy
calls.
One
was
around
on
sdf,
so
this
semantic
definition
format
that
we
are
now
working
at
the
iedf
astf
working
group.
A
But
we
had
a
discussion
on
some
of
the
topics
that
go
beyond
the
current
scope
of
the
sdf
language
and
in
particular,
how
we
could
be
looking
at
different
relationships
and
instance,
information.
So
when
in
sdf
you
can
describe
the
affordances
of
iot
devices
and
more
structure
that
they
have
using
the
sdf
definitions.
A
The
idea
here
is
that
you
could
also
describe
potentially
more
complex
relationship
information
between
the
definitions,
so
not
just
simple
hierarchical
information,
but
also,
for
example,
that
this
kind
of
a
light
switch
is
connected
to
that
kind
of
a
light
bulb,
and
they
have
this
kind
of
a
turning
on
relationship
between
them
and
also
another
aspect
that
we
have
discussed
in
in
the
wishing
meetings.
Is
this
instance
information?
A
Another
topic,
a
bigger
topic
that
we
had
in
the
wishing
meeting,
is
this
follow-up
on
the
azure
digital
twins,
definition
dddl
and
how
it
would
interwork
with
the
sdf.
So
this
was
our
our
third
meeting
with
the
azure
dtdl
team.
We
discussed
in
the
meeting
that
was
actually
yesterday
on
monday
about
the
enhancements
that
would
take
for
sda,
sdf
and
ddl
that
we
can
improve
both
of
their
expressiveness
and
also
how
they
can
work
together.
A
A
So
here
we
discuss
the
latest
advancements
on
that
and
also
what
we've
been
doing.
We
did
convert
all
the
existing
sdf
playground
models,
so
a
set
of
models
coming
from
the
oma
live
within
the
iphone
ecosystem,
ocf
ecosystem
and
a
few
from
zigbee
ecosystem
into
dddl
and
be
able
to
then
use
those
with
the
azure
digital
twin
tools
and
then
also
another
exercise
we
have
done
is
we
took
a
set
of
ddl
models
that
are
describing
a
a
domain-specific
system
and
converted
those
into
sdf?
A
There
are
few
things
missing
in
the
translation,
in
particular
licensing
information
that
has
turned
out
to
be
very,
very
useful
information
to
carry
in
the
models,
so
we
might
be
seeing
that
kind
of
improvements
coming
to
the
bddl
later
on
and
overall,
a
big
topic
here
is
the
sharing,
converting
and
publishing
the
models.
So
we
can
all
learn
from
the
different
ecosystems
and
work
on
ways
to
improve
compatibility
across
different
ecosystems.
A
A
How
you
could
use
sdf
as
as
the
tool
in
between
to
go
to
get
those
devices
connected
to
your
azure
digital
print
system?
So
you,
for
example,
convert
those
ips
models
into
dtl
models,
import
them
to
a
system
and
have
that
way
more
easily
your
iot
system
up
and
running.
So
we
have
no
early
plans
on
getting
that
kind
of
hacking
activity
ongoing
together
with
the
dddl
team.
A
Okay,
hearing
none
but
you're,
of
course,
all
welcome
to
join
the
future
wishing
meetings.
We
do
have
a
plan
to
have
the
next
meeting,
hopefully
before
thanksgiving,
but
we'll
be
able
to
still
come
back
to
these
topics
and
also
another
topic
that
we'll
we're
planning
to
look
at
closer.
Is
this
the
web
of
things
thing
description
that
we
didn't
have
a
chance
to
talk
in
in
our
previous?
A
C
C
Right,
so
I
have
two
things
in
this
deck.
One
is
a:
what
is
what
and
what
is
recent
activity
because
of
limited
time,
I'm
only
going
to
like
very
quickly
do
what
is
what
assuming
most
people
have
seen
it
I'm
going
to
spend
most
of
my
time
talking
about
recent
activity,
I
will
say
I've
more
slides
than
I
will
have
time
to
spend
on,
so
you
can
go
and
find
out
more
information
on
the
slides
or
uploaded,
including
hyperlinks,
to
various
things.
C
Now
we're
in
our
second
charter,
we've
already
published
one
spec,
which
is
the
thing
description
which
is
metadata
describing
iot
devices
and
their
network
apis,
and
the
basic
idea
is
to
describe
interfaces
rather
than
prescribing
them,
and
so
you
basically
get
this
json
ld
file.
It
describes
how
to
talk
to
a
device
and
also
creates
an
abstraction,
so
you
can
deal
with
the
device
at
a
high
level,
abstraction
in
terms
of
properties,
events
and
actions,
as
opposed
to
the
details
of
the
protocols
to
implement
that
it
also
includes
data
schemas.
C
So
you
know
how
to
format
and
unpack
information
going
to
and
from
device.
It
also
supports
multiple
protocols,
so
you
can
describe
http
or
co-app
or
mpt.
I
won't
go
into
detail
about
this
too
much.
I
just
want
to
mention
you
know
some
links
here.
So
we
have.
You
know
several
we've
already
published
td
1.0,
we're
now
working
on
td
1.1.
C
C
C
I
think
models
are
kind
of
like
a
templates
for
tds
and
they
sort
of
fill
the
same
function
as
sdf
and
dtdl
and
we're
looking
at
airbuilding
between
them.
Tds
themselves
are
designed
to
describe
instances
of
devices
in
particular
devices,
and
so
they
have
concrete
urls
and
ids
in
them.
Tms
are
classes
of
devices.
C
There
are
several
other
things,
including
geolocation,
nhk
integration
and
things
like
this.
We
also
recently
had
some
presentations
about
some
a
couple:
new
commercial
applications,
so
takanaka
corporate
contract
construction
company
out
of
japan.
It's
actually
built
a
very
complete
system
using
a
watt
for
building
information
models.
C
C
C
C
C
C
C
C
C
C
So
we've
got
that
draft
proposal
for
a
new
thing,
but
I
really
like
to
figure
out
if
I
can
use
existing
standards
instead,
there's
also
a
json
ld
signature
spec
in
the
pipe,
but
it's
based
on
rdf.
You
have
to
expand
it
into
rdf
and
canonicalize
the
rdf,
which
requires
rdf
processing
if
you're
trying
to
avoid,
because
just
just
verifying
the
signature
really
shouldn't
require
pulling
things
into
an
rdf
database.
C
So
there's
a
bunch
of
practical
concerns
there
and
finally
we're
in
the
midst
of
defying
our
new
charter.
We're
gonna
be
extending
our
current
charter
for
six
months,
so
our
next
charter
would
start
next
july
and
we're
we
had
to
defer
a
bunch
of
features
for
compatibility
reasons
to
td
2.0
and
we're
also
probably
going
to
look
at
maybe
making
normative
some
of
the
stuff
that
I
mentioned
above,
like
geospatial
ontologies.
C
The
other
thing
we're
looking
at
seriously
is
managing
data
itself.
So
right
now
we
have
a
directory
for
metadata,
but
we
really
want.
Maybe
is
a
directory
for
data
and
there's
actually
some
ieee
activity
around
that
as
well
for
doing
queries
or
intervals
that
we
need
to
align
with
anyway,
that's
a
brain
dump,
but
if
you
have
any
questions,
I
don't
know
if
you
have
time,
but
I'm
open
to
it.
A
D
C
C
C
C
C
C
A
J
J
J
Yeah,
so
one
one
data
model,
just
to
recap:
well,
where
we
are,
I
don't
really
need
to
go
back
and
talk
about
what
we're
trying
to
do,
because
I
think
most
of
us
know
what
it
is
and
could
just
go.
Look
so
sdf
is
currently
being
developed
in
the
asdf
working
group.
We've
kind
of
successfully
spawned
that
out
a
year
ago.
J
Our
consensus
process
is
developed
and
resolved
in
terms
of
what
we're
going
to
to
use.
That
nicholas
drove
that
very,
very
well,
and
some
others,
but
nicholas,
is
our
acting
secretary
for
this
process,
so
we're
about
to
basically
start
reviewing
models.
We've
already
started
the
review
and
and
come
up
with
a
what
we're
calling
a
provisional
set
of
models
for
our
first
publication.
J
That's
really
our
status
and
we
we
picked
sensors
and
we
picked
some
operational
state
and
mode
setting
models,
and
I
think
we've
decided
we're
going
to
broaden
things
beyond
that,
but
that
much
has
been
decided
and
the
the
challenges
we've
encountered
so
far
are
about
sort
of
we're.
Looking
at
there
really
a
lot
of
different
ways.
Sensors
are
not
really
that
easy.
J
There
are
a
lot
of
different
ways
that
people,
design,
sensors
and
a
lot
of
different
layers
of
functionality
and
ways
of
reporting
and
features
in
the
data
model
and
azadi
was
alluding
to
earlier
different
ways
of
handling
units
versus
whether
we
have
a
sensor
category
for
each
unit
or
whether
a
unit
is
an
attribute
of
a
more
generic
sensor.
Things
like
that,
so
we're
we're
basically
going
to
work
through
those
and
figure
out
what
what
some
reasonable
solutions
are
for
those
we've
kind
of
decided
to
to
to
get
something
out
the
door.
J
J
So
we
started
a
long
time
ago
thought
we
were
going
to
extend
schema.org,
but
we
built
it
according
to
the
the
same
event,
action
property
event,
meta
model
that
that
everyone
seems
to
have
in
some
one
form
or
another
or
a
subset
of,
but
ended
up
being
that
schema.org
doesn't
really
want
to
go
in
the
direction
of
having
device
definitions.
That's
just
not
really
the
kind
of
content
they're
their
scope,
for
they
want
to
keep
things
a
little
more
generic
and
describe
more
like
patterns
so
and
our
basic
pattern
stuff
isn't
really
useful.
J
So
we
don't
really
have
a
clear
idea:
we're
working
on
rechartering.
I
can't
really
see
the
last
line
of
the
slide
is
there's.
Oh
there
we
go
oh
yeah,
so
basically
where
what
we're?
What
we're
looking
at,
though,
and
had
some
proposal
from
siemens
already,
is
some
extensions
in
the
meta
model
so
that
we
can
connect
to
physical
relations
and
we
have
another
little
ontology
that
we're
looking
at
for
that.
J
J
Yeah
interesting,
I
have
canceled
the
monthly
meetings
for
a
while,
but
basically
you
need
to
need
to
kind
of
restart.
That,
I
think,
is
what
we
need
to
do
so,
there's
a
mailing
list
that
people
are
on
and
I'll
send
out
email.
But
that's
a
that's
a
really
good
question.
I
don't
really
have
a
a
great
answer
right
now,
other
than
I
will.
I
will
try
to
get
things
going
again.
J
We
had
the
european
vacation
around
august
september
and
we
didn't
ever
really
start
back
up
since
that,
but
I
think
we
have
some
more
clear
one.
One
observation
I
will
make,
though,
is
that
we're
seeing
people
kind
of
knocking
on
the
door
at
w3c
around
web
of
things
and
sort
of
they
have
the
whole
problem.
They
have
that
what's
the
common
format,
where
do
my
models
go?
How
do
I
standardize
the
thing
that
I'm
doing
so?
J
I
don't
want
to
like
run
on
us
over
time,
but
that's
a
good
point
and
let's,
let's
make
sure
we
sort
of,
engage
something
and
look
at
that,
because
I
think
there
is
a
gap
that
needs
to
be
addressed
and
I
think
that
we
kind
of
have
the
right
approach
there.
But
the
the
bigger
integration
is
really
the
question.
Yeah,
I'm
cool.
C
J
C
D
Okay,
it
seems
to
me
that
would
be
a
good
subject
to
have
a
discussion
on
soon
with
maybe
a
few
other
players
from
the
iot
schema
side.
So
I
think
we
should
discuss
how
to
set
up
such
a
meeting,
so
we
can
get
some
progress
on
on
the
physical
relation
types
and
and
other
types
of
relations
that
we
actually
need
in
sdf
as
well.
In
the
long
run,.
J
A
Okay,
thank
you.
Thank
you,
michaels.
It
was
very,
very
good
information
and
I
clearly
you
know
a
lot
of
good
opportunities
across
these
different
activities
and
organizations
to
align
our
activities.
So
let's
take
a
step
at
that
and
definitely
you
know
in
wishy
we're
more
than
happy
to
host
this
kind
of
discussion,
so
that
could
be
a
potential
agenda
item
for
our
next
wishing
meeting.
A
Good
and
now
we're
actually
almost
at
the
end
of
the
meeting,
we
had
already
a
good
good
set
of
discussions
here
and
I
we
did
write
a
good
big
set
of
notes
in
the
usual
place.
Please
go
check
them
out
and
and
see
if
we
missed
some
something
essential
or
if
we
mis
represented
your
comments,
it's
always
good
to
to
fix
those
before
we
publish
publish
the
notes,
but
before
we
close
for
today.
In
any
final
questions,
comments
from
anyone.
A
Okay
hearing
none,
so
I
guess
our
our
next
meeting,
what
we'll
be
all
probably
seeing
in
in
the
upcoming
ietf
hackathons
and
I
idf
meetings,
but
the
next
more
official
thinking
research
group
activities
are
probably
going
to
be
than
the
upcoming
wishing
meetings.
So
wishing
you
all
well
until
then
stay
safe
and
looking
forward
to
seeing
you
soon
again.