►
From YouTube: IETF97-T2TRG-20161116-1520
Description
T2TRG meeting session at IETF97
2016/11/16 1520
A
A
So
this
is
a
research
group
I'm
going
to
talk
a
little
bit
more
about
that
in
a
minute,
but
we
still
have
blue
sheets
and
we
are
looking
for
no
takers.
Do
we
have
no
takers?
Now
we
have
one
okay,
thank
you.
So
are
you
going
to
do
it
on
the
etherpad?
So
maybe
maybe
somebody
can
chime
in
and
fill
in
the
blanks
a
little
bit.
C
A
A
A
Right
yeah,
I
just
want
to
point
out.
The
research
group
has
a
mailing
list
and
there
is
a
little
trap
here,
because
all
of
our
stuff,
of
course
ends
with
ad.
I
RT
f
dot,
org
except
sometimes
so.
Sometimes
you
have
to
look
a
little
bit
closer,
whether
there
is
an
ietf
dot.
Org,
oh
and
I
RT
f
dot
org
there
and
maybe,
quite
importantly,
we
tend
to
put
our
meetings
on
github.
So
each
meeting
has
its
own
repository
and
the
repository
for
this
meeting
is
github
com
/t
to
TRG
/,
2016,
desh,
ITF
97.
A
A
We
will
talk
about
the
security
considerations
document,
which
is
probably
the
most
substantial
document
that
we
have
agreed
as
a
research
group
to
work
on.
We
will
discuss
the
rest
for
design
and
hypermedia
subject.
There
are
a
number
of
documents
here.
One
may
become
a
research
group
document.
Very
soon
and
other
a
little
bit
more
exploration,
l
in
nature,
and
finally,
we
will
have
a
quick
discussion
about
a
yang
as
an
interaction
model
for
coming
again.
A
For
instance,
the
security
considerations
probably
do
collect
information
that
many
people
have
been
collecting
over
the
last
couple
of
years:
okay,
okay,
what
is
the
research
group
about
the
thing
to
think
research
group
was
officially
chartered
a
year
ago
in
December
2015,
and
we
look
at
open
research
issues
in
telling
a
true
Internet
of
Things
into
a
reality,
so
I
don't
know
who
he
was
there
on
tuesday
at
the
I
sock
panel.
A
few
think
you
missed
something,
so
we
are
interested
in
making
an
internet
a
reality
where
low
resource
nodes
are
full.
A
Citizens
are
not
just
devices
that
can
can
talk
to
or
to
a
big
brother
in
the
cloud,
but
actually
can
interact,
are
maintaining
some
of
the
invariance
of
the
internet
and,
of
course,
within
this
really
big
subject,
we
focus
on
issues
with
opportunities
for
ITF
standardization,
but
we
do
that
folds
tech.
So
if
somebody
comes
with
an
adaptation
layer
problem,
we
are
as
interested
in
that
as
when
somebody
comes
and
wants
to
talk
about
human
rights
issues.
In
think
of
thing,
communication,
don't
know
how
that
would
work,
but
we
were
find
something.
A
Ok.
So
again
we
were
chartered
a
year
goal.
We
have
had
a
pretty
full
calendar
this
year,
so
we
have
done
research
group
meetings
partially
co-located
with
w3c.
We
have
had
one
co-located
with
the
IAB
semantic
interoperability
workshop.
We
had
meetings
with
the
ITF
at
the
ITF
locations.
We
participated
in
the
software
update
workshop.
The
riot
sandwich
in
Berlin
talking
to
implement
us
is
very
much
of
interest
to
us,
so
we
just
recently
had
a
implementers
meeting
with
the
Eclipse
con
conference,
which
was
very
interesting.
A
A
A
But
really
we
haven't
really
schedule
with
that
very
much
yet
so.
On
the
meeting
we
had
on
Sunday,
we
had
a
joint
meeting
with
IC
energy
for
two
and
a
half
hours
two
and
a
half
hours.
It's
not
much.
In
particular,
if
two
established
communities
meet
each
other
for
the
first
time
in
a
room
but
I
see,
energy
has
a
lot
of
perspective
on
iog
already.
A
But
of
course,
with
a
view
to
we
have
this
hammer
and
and
how
is
IOT
a
nail
and
I
think
the
thing
research
group,
on
the
other
hand,
has
grappled
with
issues
that
are
just
the
the
stable
issues
of
the
ice
energy,
such
as
data
naming
and
so
on.
So
it
makes
sense
for
us
to
talk
to
each
other,
and
we
presented
a
couple
of
we
had
presentations
for
a
couple
of
ICN
IOT
project
and
discussed
different
aspects
of
semantics
and
security.
A
So
again,
this
was
only
12
hours.
We
didn't
get
very
far,
but
it
seemed
to
us
that
we
will
continue
that
so
I
expect
us
to
have
further
joint
meetings
with
IC
energy
in
the
future.
It
might,
we
might
even
want
to
have
cross
review
of
documents.
There
is
an
IOT
architecture
document
being
prepared
by
IC
energy.
So
maybe
that's
something
we
will
look
at.
D
Lee
Howard
I'm,
sorry
for
interrupting
I've
noticed
we
have
several
people
standing
in
the
back,
who
can't
find
seats
and
I've
noticed.
We
have
a
lot
of
people
putting
stuff
on
seats
next
to
them.
Can
you
can
people
please
up,
make
room
and
raise
your
hand
to
get
this
chair
next
to
you
on
a
chair?
Come.
E
F
E
Just
start:
okay,
yeah
I've,
some
updates
on
the
Bible
finks
activity
at
w3c.
So
just
recap:
what
is
this
about?
So
the
mission
is
definitely
not
you
to
create
a
new
standard
in
a
w3c
for
this.
So
we
aware
that
there
is
a
lot
of
affectivity,
so
they're
a
lot
of
alliances
and
and
platforms
out
there.
E
Office
specific
platform-
and
another
thing
we
want
to
tackle
is
how
you
develop
IOT
applications
so
that
it
becomes
easier
to
actually
write
applications
for
for
the
Internet
of
Things
and
to
get
ultimately
in
something
similar
to
the
web
browser
that
is
the
runtime
for
web
applications,
but
have
that
for
for
actually
things,
and
for
that
we
currently
targeting
at
those
building
blocks.
So
we
have
to
vote
scripting
API
so
that
we
have
some
kind
of
common
API,
that
you
can
write
an
application
against
and
that
should
then
run
on
different
things.
E
Again,
it's
a
building
block,
so
you
not
forced
to
pick
that
or
implement
that.
But
it's
something
if
you
say
you
want
to
support
this.
This
is
something
you
can
integrate
in
in
your
platform
and
then
the
next
thing,
probably
the
central
part,
is
the
map
of
things
fing
description.
So
this
leverages
semantic
technologies
to
to
describe
how
interfaces
of
things
work.
E
So,
on
the
one
hand
there
is
this
support
for
the
scripting
API,
it's
a
sore,
so
you
need
to
parse
these
fing
descriptions
and
then
ya
want
to
write
code
that
can
actually
work
on
this.
So
for
that
we
have
the
connection
up
to
the
scripting
API
from
this
fing
description,
and
we
have
these
protocol
mappings.
E
So,
for
instance,
a
lot
of
platforms,
leverage
co-op
so
there's
a
co-op
binding
for
192
m,
for
instance
ocf
users
co-op,
but
they
use
go
up
in
a
different
way
and
what
we
try
to
do
in
these
mappings
is
to
describe
how
to
use
go
up
in
a
different
way
so
that
you
can
have
a
vanilla,
co-op
stack
and
then
produce
messages
that
will
be
understood
by
the
ocf
device
or
by
the
one
fom
device,
and
this
is
then
in
the
end
also
part
of
this
finger
scription.
So
you
see
the
finger.
E
Scription
is
basically
the
central
part
of
or
the
central
building
block
and
for
application
development
it
extends
to
the
scripting
api
and
for
the
interconnection.
It
goes
down
to
the
protocol.
Meh
things
to
do
yeah
create
messages
that
will
be
understood
and
kind
of
yeah.
Part
of
all
of
these
is
security
and
privacy.
So
we
also
want
to
provide
means
to
describe
the
security
mechanisms
that
are
used
by
the
thing
and
also
have
their
checks
that
you
can
write.
Applications
that
yeah
are
able
to
express
privacy
needs,
for
instance.
E
So
how
is
this
work
organized
in
w3c?
So,
for
one
and
a
half
years
we
have
now
the
web
of
things,
interest
group,
which
is
mainly
for
exploration,
so
looking
at
technology
out
there
and
identifying
building
blocks
that
might
be
worth
as
standardizing
and
it's
the
the
group
that
is
open
for
collaboration.
So
we
actually
have
quite
a
number
of
lazing
on
going
so
with
the
one
m2m
with
the
OPC
foundation
and
we're
currently
setting
something
up
with
the
with
OC,
f
and
gas.
So
we
exist
since
april
2015.
E
E
The
working
groups
in
wvc
are
those
who
can
actually
do
normative.
Standardization
work,
so
you
can
compare
it
a
bit.
Wpc
working
group
is
like
an
ITF
working
group
at
the
interest
group
is
like
an
IR
TF
working
group.
So
that's
why
the
interest
group
also
meets
with
the
thing
to
thing
research
group.
E
We
have
the
proposed
charter,
it's
out
there
since
end
of
August
about
saying
yeah,
so
we
had
the
AC
review.
So
that's
the
what
committee
a
committee
in
the
w3c
I
forgot,
the
name
too
many
abbreviations
that
looks
at
these
charges
and
and
then
decides
or
boats
ever
this
should
be
a
working
or
should
become
a
working
group.
You
can
have
a
look
at
the
results
here.
The
summaries
we
have
49
supports,
as
is
for
member
companies,
comments
but
support
the
chart
anyway,
and
we
had
two
comments.
That
would
formally
then
object.
E
If
you
do
not
apply
the
changes
they
propose
and
that's
basically,
what
we
are
doing
right
now,
we're
together
with
w3c
management,
resolving
those
issues.
In
summary,
one
was
about
RDF
dependency,
so
you
shouldn't
force
dependency
on
RDF
or
these
heavyweight
semantic
frameworks,
and
that
kind
of
shifted
to
to
a
comment
that
rdf
word
semantics
classically
created
some
complexity
in
the
setup
of
the
working
group
order.
The
solutions
that
you
work
on
so
one
thing
is:
we
do
not
force
a
dependency.
E
So
it's
basically
an
extension
point,
because
there
are
lot
of
member
companies
that
actually
want
to
provide
rich
semantic
tooling.
But
then
there
are
also
average
that
just
want
to
benefit
from
a
common
format
that
can
be
parsed
by
classic
jason
parcels,
for
instance,
and
for
the
complexity.
You
basically
have
a
plan
now
how
to
a
set
a
priority
of
the
different
deliverables.
E
The
scripting
API
solution
for
that
on
the
scope-
that's
already,
but
I
present
it
so
the
fing
description
itself
becomes
the
central
piece
it
has
the
priority
and
it's
also
what
is
the
the
greatest
interest
of
all
the
member
members
and
the
scripting
api,
and
these
protocol
mappings
become
kind
of
secondary
things,
but
they
are
connected,
so
you
cannot
even
design
those
independently,
so
it
wouldn't
would
make
any
sense
to
not
work
on
those.
And
finally,
they
were
some
some
security
considerations
or
yeah
hints
that
yeah
I
OT
is
dangerous,
especially
with
the
recent
attacks.
E
So
there
was
more
emphasis
on
that.
We
have
the
right
checks,
so
we
actually
also
established
this
kind
of
model
of
running
code
in
it,
this
interest
group
and
working
group,
so
we
actually
implement
the
drafts
in
parallel
and
we
are
planning
to
have
a
security
testing
before
we
actually
go
to
two
new
status
of
those
documents
so
before
we
have
the
first
public
reference
and
people
have
rigorous
testing
and
those
who
had
the
the
objections
on
this
actually
will
help
to
develop
a
proper
testing
on
that.
E
So
it
were
basically
browser
vendors
who
had
some
some
issues
here,
but
they
can
definitely
also
support
us
in
coming
up
of
the
right
testing
how
to
do
that,
how
to
roll
it
out
and
yeah.
That's
about
the
update.
I
summarize
the
a
lot
of
links
here
that
you
can
follow
up
to
get
more
information
on
this
and
I.
Don't
know
if
you
have
time
for
questions
or
if
they
are
any
questions
at
all.
A
C
E
Depends
your
university
doesn't
have
any
contract
various
w3c,
so
sometimes
it's
possible
to
get
invited
experts
in
there,
but
also
the
work
is
public.
So
if
you
follow
the
links,
you
can
see
what
we
are
doing
on
on
github.
You
can
yeah
just
a
comment
on
that
and
I
actually
don't
know
what
happens
if
you
sign
or
subscribe
to
the
public
mailing
list.
I
mean
it's
supposed
to
be
public
and
the
IP.
Our
policy
is
also
pretty
loose
or
dares
no,
no
policy
in
the
interest
group.
D
G
Hello,
everyone
I'm,
oh
it
and
I'll,
be
presenting
our
draft
on
security
considerations
for
the
Internet
of
Things.
This
work
was
done
together
with
my
co-authors,
Oscar
and
Sandeep,
who
unfortunately,
could
not
make
it
to
this
ITF,
so
I'm
sure
some
of
you
are
aware
about
the
history
of
this
document.
G
This
was
recently
submitted
to
the
core
working
group
several
years
ago,
but
now
it
has
been
decided
that
we
will
work
on
this
document
in
the
research
in
the
tea
to
TRG
and
the
idea
being
that
the
iot
related
drafts
would
reference
this
draft
in
the
security
considerations.
So
this
would
then
act
as
a
repository
for
security
considerations,
to
which
other
drops
would
good
reference.
G
So
since
it's
it
hasn't
been
presented
formally
in
the
in
the
key
to
TRG,
the
cheers
suggested
that
I
actually
present.
What
does
it
contain,
rather
than
just
presenting
what
has
been
updated
so
I'll
briefly
present
what
what
this
draft
is
all
about.
So
the
first
thing
the
draft
contains
is
is
the
thing
life
cycle
so
which
basically
describes
the
life
cycle
of
internet
of
sing-sing
device.
You
know
it
gets
manufactured
on
the
factory
floor.
G
It
goes
through
the
supply
chain,
it
ends
up,
probably
in
a
shop
you
go
and
buy
it,
and
then
you
need
to
physically
install
it
and
Commission
it
so
kind
of
run
the
bootstrapping
process
with
which
it
would
become
operational,
and
once
there
its
operational,
you
will
have
things
like
software
updates
reconfiguration.
So,
for
example,
if
you
change
the
battery,
then
you
need
to
run
the
bootstrapping
process
again
and
and
so
on,
once
the
operational
cycle
or
the
lifetime
is
over,
you
decommission
and
remove
it,
but
that
doesn't
mean
that
the
device
is
unusable.
G
G
So
yeah
we
had
one
section
describing
in
all
the
different
phases
of
the
law
of
the
of
the
IOT
device
lifecycle.
So
then
we
have
a
section
on
on
threat
analysis.
So
basically,
what
kind
of
threats
does
IOT
device
face?
So
we
could
have,
for
example,
an
untrusted
manufacturer
or
an
incompetent
manufacturer.
You
know
if
he
is
responsible
for
putting
the
keys
in
your
IOT
device.
Does
it
make
a
copy
of
them,
or
does
he
like?
Unknowingly,
reveal
them
and
so
on?
G
You
have
physical
attacks,
so
if,
if
your
device
is
installed
somewhere
and
your
neighbor
goes
and
replaces
them
or
takes
them
home
on
the
on
the
network
level,
you
have
attacks
like
East,
dropping
and
and
man
in
the
middle
and,
of
course,
ifs
dropping
is
not
just
a
security
threat.
It's
also
a
privacy
threat.
A
lot
of
these
Internet
of
Things
devices
are
extremely
constrained
in
terms
of
the
resources
they
have
so
in
terms
of
the
battery
or
energy
or
computation,
and
so
on.
G
So
if
you
have
followed
the
Internet
of
Things
software
update
workshop,
you
might
have
seen
the
example
of
TR
69,
which
is
one
of
these
protocols
that
you
use,
for
you
know
doing,
updates
and
firmware
updates,
which
was
found
to
have
certain
holes
in
it,
and
an
attacker
can
use
use
those
two
replace
your
your
firmware
with
a
malicious
firmware.
Of
course,
there's
also
possibility
of
routing
attacks.
G
So
then
we
have
so
we
know
what
are
the
threats
the
IOT
device
faces,
and
then
you
know
what's
the
challenges
in
securing
against
these
threats,
so
the
first
is
just
the
heterogeneity,
so
you
have
extremely
resource-constrained
devices
and
full-blown
laptops
and
no
devices
are
much
more
computationally
capable
and
how
do
these
devices
you
know
talk
to
each
other,
and
this
also
relates
to
the
second.
Second
challenge
is
like
you
have
a
device
that
speak
speaks
go
up
and
you
have
you
know
an
Internet
service
that
speaks
HTTP
or
HTTP.
So
how
do
you?
G
How
do
they
interact?
You
probably
need
some
kind
of
a
proxy
or
protocol
translation,
but
then
how
do
you
still
ensure
end-to-end
security?
So
this
is,
of
course,
of
course,
the
challenge
and
specially
not
just
Progo
translation,
but
if
you
have
aggregate
gators
and
so
on,
how
do
you
still
have
n
to
n
security?
G
G
Then
we
got
some
comments
from
Stephan
Farrell,
based
on
which
we
added
new
challenges.
So
one
was:
how
do
you
verify
that
your
device,
IOT
device
that
you
just
bought
is
behaving
the
way
it's
supposed
to
behave
so
for
any,
for
example,
I
go
to
the
shop
and
I
buy
this
TV
and
bring
it
home
internet
connected
TV
and
bring
it.
F
G
G
Exactly
so
end
of
life
is
again
a
big
challenge.
So
what
happens
when
the
manufacturer
does
not
exist
or
refuses
to
support
your
device?
Is
it
still
usable
can
I
still
do
software
updates
and
those
kind
of
things
are
X
tremely
challenging.
So
so,
how
do
you
handle
those
and
can
I
do
some
pen
testing
on
my
IOT
device,
even
though
it's
it's
very
resource
constrained?
How
do
I
do
pen
testing
and
how
do
I
ensure
quantum
resistance?
F
G
You'll
have
different
kinds
of
IOT
devices
themselves,
so
some
will
have
no
hardware
support
and
some
will
have
PPM's
and
some
might
not
so
so
we
discuss
about
that
and
what
kind
of
trade-offs
you
have
between
centralized
and
distributed
security
architectures
and
then
then
we
cover
know
some
of
the
ongoing
work
for
IOT
security,
so,
for
example,
minimal
like
and
we
had
the
dice
working
group
which
specified
DTLS
444
constrained
devices,
and
how
do
you
do
lightweight
IPSec?
So
that's
something
ongoing
in
the
El
Vic
working
group.
G
So
we
cover
all
that
in
the
in
the
draft,
so
yeah
that
was
kind
of
overview
of
what
the
draft
contains
and
now
I
come
to
the
part.
What
has
been
changed
since
the
last
version,
so
in
in
devotion
that
was
in
that
was
submitted
to
the
core
working
group
some
years
ago
we
had
the
lifecycle,
the
considerations
state
of
the
art
and
then
all
the
challenges
and
and
profiles,
but
in
the
version
that
is
now
in
the
research
group
here
are
some
changes.
G
So
here's
you
know
next
steps
that
we
plan
to
do
and
we
are
open
for
no
comments
and
feedback.
I
think
the
draft
would
still
take
at
least
one
or
two
more
iterations
before
it's,
it's
really
ready
for
publication.
So
it's
it's
relatively
long
and
that's
always
we,
as
authors,
run
into
the
problem.
How
do
we
keep
it?
You
know
it
useful
in
and
relevant
information,
but
at
the
same
time
that
it's
not
too
long
and
people
actually
actually
read
it.
G
So
we
will
try
to
still
make
it
more
concise
but
also
know
how
do
we
ensure
that
it's
it's
more
smooth
in
terms
of
the
flow?
So
how
is
it
more
uniform
in
in
terms
of
its
structure,
and
for
that
you
know
we
are
proposing
that
we
have
this
security
pillars
and
basically,
in
each
of
the
section
we
structure
it
according
to
the
pillars,
and
these
pillars
are
what
kind
of
architecture
you
have.
Is
it
centralized
or
distributed?
What
kind
of
a
device
you
have?
G
G
So
right
now
we
have
some
threats
in
the
thread
section,
but
they
are
rather
ad
hoc
and
you
can
see
that
it's
written
by
different
authors
over
time,
so
it
needs
a
little
bit
of
more
no
work.
So
it's
it
smooths,
but
we
are
also
thinking
that
we
organize
the
threads
based
on
the
life
cycle
we
present
in
the
first
section.
So
what
kind
of
threats
do
face
face
in
the
bootstrapping?
G
What
kind
of
threats
do
you
face
in
software
updates
and
what
kind
of
threats
do
you
face
when
you
do
ownership
hand
over
and
and
things
like
that,
so
for
the
security
profiles
again,
like
just
add
a
little
bit
more
detail
but
making
sure
the
document
doesn't
become
too
long
and
what
kind
of
security
properties
do
you
expect
in
different
application
scenarios
so
state-of-the-art?
This
will
still
require
some
work,
so
some
of
the
references
are
out
of
date,
so
they
need
to
be
updated.
G
There's
always
new
work
going
on,
so
we
need
to
add
as
much
of
it
as
we
can
and
include
all
all
the
new
references
and
the
challenges.
So
we
added
some
new
new
challenges
such
as
you
know,
pen,
testing
and
and
so
on,
so
trying
to
make
sure
that
it
follows
the
same
structure
as
as
the
rest
of
the
document.
So
we
just
described
the
challenge-
and
you
know
here
here-
are
the
potential
solutions
that
you
can
use
to
address
address
those
challenges.
H
Hi
Maxine
chance
I've
gone
through
the
stack
in
a
couple
times
over
the
years
or
similar
document
and
I'm
kind
of
frustrated
with
a
couple
of
things
in
here.
First
thing
is:
the
threat
section
is
all
about
threats
to
the
things,
not
the
threat
from
the
things,
and
that
may
actually
be
the
biggest
problem
we
have
to
deal
with.
Okay,
the
other
piece
of
it.
Sorry
I'm
a
little
bit
have
I've
had
a
cold
for
a
while
or
something's
been
caused
me
problems
it
it's.
H
Now
I
think
I'm
going
to
stay
with
that
one
I
think
it
I
think
we
need
to
start
thinking
about
the
Internet
of
Things,
not
just
like
we
thought
of
PCs
and
everything
else,
but
the
fact
that
we
don't
have
the
same
model
of
control
over
them
with
respect
to
what
we're
talking
about
here.
Thinking
about
the
threats
from
these
devices
is
important,
and
probably
more
so
than
threats
to
the
devices
I'm
going
back,
especially
to
things
like
the
cyber
physical
threats,
the
denial
service,
the
distributed
nyala
service
stuff,
for
example.
H
G
So
barn
when
taken,
but
we
will
what
have
any
solutions
in
this
document,
so
we
can
of
course
note
that
this
is
an
a
challenge,
an
issue
we
need
to
be
aware
of
it.
You
know
physical
attacks,
like
you,
pointed
out
those
those
can
be
added,
but
I,
don't
think
we'll
go
into
actual
solutions
of
how
do
you
mitigate
d
dose
from
IOT
devices?
We
can
give
point
you
to
tools.
Other
drafts
that
are
that
X
is
right.
H
I
Dan
York,
so
I
would
agree
with
Mike
actually
that
threats
from
is
an
interesting
thing
to
consider.
But
I
was
really
more
coming
up
here
to
ask
a
practical
question,
which
is
just:
how
do
you
want
the
the
feedback
as
far
as
email
to
the
authors
by
notice
you're
using
github?
Do
you
also
want
github
issues
or
how
do
how
do
you
work
I'm
new
to
this
group,
so.
B
J
Moving
good
quick
note,
it
may
be
worth
using
as
a
reference
or
looking
at
it
for
some
of
the
security
challenges
and
so
on.
There's
a
paper
coming
out
on
monday
or
tuesday
from
the
be
tagged,
which
is
the
broadband
internet,
technical
advisory
group
and
one
of
the
co-editors
that
goes
through
these
issues,
so
you
might
be
able
to
some
of
sections
that
you
still
need
and
put
on.
You
know,
sort
of
pull
directly
out
of
that
document,
so
Monday
or
Tuesday
it'll
be
up.
Please.
G
Send
it
on
the
list,
but
I
would
also
say
there's
a
bunch
of
people
writing
guidelines.
So
we
have
the
cloud
security
alliance.
We
have
the
GSMA,
we
have
the
trusted
computing
forum.
There's
everyone
is,
you
know,
writing
guidelines,
so
I,
don't
I,
don't
think
we
can
make
everyone
happy,
but
definitely
we
can
take
contents
from
from
the
paper
and
and
hardware.
D
Necessary
Lee
Howard
can
responding
to
Mike's
points
and
also
you
response
that.
Yes,
we
should
be
thinking
about
threats
from,
but
in
many
cases
in
many
ways
at
least
we
can
prevent
frets
threats
from
by
preventing
threats
to
right.
So
if
we
can
say
here's
a
collection
of
problems,
if
you
follow
all
these
security
pillars,
then
you
have
at
least
reduced
the
possibility
of
attacks
out
right
die,
falling
I'm
only
about
eight
pages
into
the
document
you
yeah.
K
B
B
B
If
you
start
for
the
guidance
there's
all
those
smaller
boxes
are
our
drafts
that
we
have
other
working
group,
we
had
a
restful
design
priority
systems,
giving
high
level
overview
on
what
kind
of
systems
you
could
to
be
designing.
Here
we
had
core
application
descriptions
which
is
somewhere
in
between
guidance
and
on
the
hypermedia
language
couple
of
documents
on
hypermedia
languages,
coral
and
HS
ml.
I
will
have
more
details
coming
the
follow-up
study
all
of
these
and
then
also
a
seaborne
conform
data.
That
is
closely
related
to
the
coral
color
document,
not
the
hypermedia
applications.
B
There's
one
older
document
called
core
lining.
Does
the
first
document
that
we
were
discussing
in
this
space,
but
now
there's
a
brand
new
document
called
tingling
data
hub.
That
is
probably
keep
how
every
if
you're
interested
in
that
topic,
but
also
this
work
relates
to
the
lot
of
the
work
we
are
doing
in
the
core
working
group,
so
being
resource
directory
box,
a
broker
etc.
B
So
if
you
coat
the
details
on
the
documents
on
the
restful
design
document,
this
is
the
one
of
the
doc
wants
has
been
quite
some
time
work
in
a
resource
group
and
it's
really
about
guidance,
how
you
design
these
restful
systems
with
with
the
iot
aspects
in
mind.
So
it's
a
collection
of
you
could
say
basic
information,
something
you
can
give
us
a
relatively
new
person
in
the
field
and
should
be
able
to
grasp
some
of
the
key
concepts.
B
So
there
are
we're
discussing
flexible
data
formats,
interaction
patterns
and
other
mechanisms
that
make
it
suitable
for
situations
where
you
want
to
minimize
the
human
interaction
the
device
is
talking
or
things
talking
to
each
other
and
then,
of
course,
a
lot
of
our
focus
is
on
the
constraint.
End
of
the
iot
spectrum.
So
how
can
you
make
these
things
possible
in
an
inner
constrained
environment,
constraint,
networks,
constraint
devices
and
the
draft
the
last
place
in
of
the
craft
and
ask
Karsten
mentioned?
B
B
Then
another
data
document
on
the
area
of
guidance
is
this:
core
application
descriptions,
this
document
from
Klaus
Hartke
and
the
idea
of
the
document
is
to
this,
how
you
can
describe
api's
that
are
constrained,
restful,
hibernian,
driven
applications.
So
what
kind
of
controls
you
would
have
in
this
kind
of
API
and
what
is
a
standard
way
of
describing
them?
So
when
you
do
an
API
that
is
using
using
this
kind
of
mechanisms
that
they
are
actually
understandable
for
everyone
else
and
also
following
a
standard
form.
B
B
So,
as
in
layman
terms,
you
would
call
this
HTML
for
IOT,
however,
whereas
in
HTML
lot
of
the
focuses
on
how
you
can
have
structured
data
presented
in
a
generic
way,
this
one
focuses
more
on
the
control
side,
so
you
help
recent
links,
how
you
present
forms,
etc
and
there's
also
a
lot
of
related
work
going
on
at
the
doubletree
type
of
things
that
Matthias
presented
earlier.
So
you
should
also
check
that
area
out.
B
So
then,
if
we
look
on
bit
on
the
details
of
the
languages
that
we
are
working
on
right
now,
so
coral,
the
constant
restful
up
case
in
language,
the
idea
there
is
to
have
an
efficient
way
to
represent
format,
forms
and
links
in
a
hypermedia.
So
it
is
using
c
bar,
which
is
a
way
to
express
chasing
by
structures
in
a
very
efficient
way
suitable
for
IOT
devices.
It
setups
a
host
of
default,
so
you
don't
have
to
send
every
value
every
time,
because
it
has
a
sensible
default
values
for
a
lot
of
things.
B
You
will
be
working
on
instead
of
string,
IDs,
it's
using
numeric
IDs,
which
are
in
general,
more
efficient
in
these
kind
of
environments
and
overall
thanks
all
mechanisms.
Often
it's
only
a
few
bites
that
you
need
to
be
exchanging
in
the
interactions
with
the
hypermedia
and
also,
even
though
focus
is
on
is
on
the
controls.
B
So
there's
two
different
drafts
that
are
all
related
on
this
topic
and
then
we
have
HS
ml
is
from
a
micro
coaster.
So
here
the
idea
is
to
have
a
combined
cording
format
and
send
a
mail
and
having
something
called
HTC,
my
collections.
This
is
also
using
JSON
and
see
board
for
the
representation,
so
it
has
a
lot
of
similarities
with
for
the
coral.
However,
the
key
thing
here
is
use
link
annotations
for
describing
the
application
semantics
and
there
you
have
the
traffic
coaster
in
archaea
at
HS
ml
for
reference.
B
So
at
this
that
you
may
wonder
why
do
we
have
two
different
documents?
Well,
one
thing
is
coffee:
our
research
group.
We
are
exploring
what
is
a
good
way
of
doing
things.
We
have
been
thinking
comparing
these
two
different
approaches
and
what
are
similarities
and
what
are
the
commonalities,
they're
so
similar
things
here,
both
use
collections
of
links
and
items,
so
they
follow
a
similar
pattern.
There.
They
use
hyper
media
controls
to
perform
research
state
updates.
They
have
interval
data
models
as
its
custom
in
here
and
also
actually,
as
Michael
pointed
out.
B
Html
can
even
be
encoded
as
coral,
so
they
have
a
lot
of
commonalities,
but
there
are
a
few
differences
to
which
we
are
now
looking
into.
For
example,
coral,
the
data
model
is
derived
from
hell.
The
hypermedia
application
language,
whereas,
as
mentioned
HS
ml,
is
more
on
the
cording
format
and
send
email
and
exploring
how
those
together
can
be
used
in
an
efficient
way.
B
Also,
Cora
used
media
types
heavily
and
with
HH
HTML
is
focusing
on
link
annotations,
so
those
are
similarities
and
differences
between
those
two
documents
and
what
right
now
ongoing
work
is
that
figuring
out
what
what
what
situation,
what
kind
of
mechanisms
makes
make
sense
in
what
kind
of
environments?
So
that's
experimentation
on
use
cases
and
implementation
tis,
and
the
idea
is
eventually
to
converge
to
a
single
solution.
But
right
now
we
are
exploring
both
of
these
tracks.
B
And
then
the
whole
area
of
hypermedia
applications,
so
what
kind
of
things
we
can
actually
build
on
the
tools
that
we
have
in
our
toolbox?
Cora
lining
is
one
of
the
earliest
documents
that
we
had
in
this
space
and
those
also
by
call
circa.
It
was
about
even
control.
Smart
objects
in
a
small,
smart
home
environment,
simple
lighting
scenario.
In
that
context,
that
graph
is
currently
expired
because
it
other
other
graphs
have
newer
material.
But
there
is
maybe
a
plan
to
let
it
all
update
that
using
the
latest
things.
For
example,
coral.
B
However,
there's
a
a
brand
new
document
in
this
space
called
the
tingling
data
hub
and
the
tingling
data
hub
is
really
a
a
restful
hypermedia
driven
web
application
that
you
can
use
for,
storing
and
publishing
information
on
a
central
location.
So
it
has
a
lot
of
similarities
with
a
resource
directory
with
pub/sub
broker,
with
the
old
mirror,
server,
etc.
Trying
to
generalize
these
concepts
and
look
at
them
at
in
a
bigger
picture
with
the
with
the
proper
hypermedia
controls,
so
what
it
supports
the
kind
of
functionality.
B
Of
course,
you
can
has
functional
to
discover
this
data
hub.
You
can
read
information
from
it.
You
have
the
usual,
create,
read,
update,
delete
semantics
and
also
with
observe
supported
by
coop,
and
it
also
supports
simple
search
source
Curie
semantic.
So
you
can
be.
You
can
find
work
out
things
today.
The
hubby
storing,
but
the
key
thing
in
the
kings
of
the
data
hub.
Is
this
evolvable
API
based
on
hypermedia.
B
So
where
a
lot
of
the
work
we
have
been
doing
it,
a
core
working
group
so
far
has
relatively
static,
API
defined
by
the
URI
templates.
So
you
haven't
have
a
one
URI
where
you
post
and
then
maybe
you
discover
links
etc,
but
this
is
aiming
to
be
the
really
fully
restful
way,
using
only
proper
hypermedia
controls
to
achieve
achieve
same
things
and
there's
the
draft
on
that
one.
B
So
that
was
an
overview
rather
quick
overview
because
we
are
low
on
time.
So
it's
a
whole
bunch
of
documents
in
a
pretty
interesting
area
on
the
hypermedia
application.
So
please
read
the
documents
and
if
you
are
interesting
on
one
of
those
any
of
those
sent
sent
review
comments
on
the
on
the
list
of
the
authors
and
hope
you
guys
are
able
to
participate
in
to
work.
Any
questions
comments.
L
I'm
actually
surprised
how
you
managed
to
present
all
this
information
in
time.
I
was
sorry
thinking,
okay,
yeah,
so
today,
I'm
go
on.
My
name
is
Alexandra
pelf
and
I'm
going
to
be
talking
to
you
about
the
thing
that
is
a
little
bit
at
the
fringe
between
the
research
and
the
reality
that
will
be
seeing
coming
so
I.
Imagine
that
most
of
you
know
what
co-op
is
and
the
IOT
part
of
the
the
world
and
I
would
like
just
to
see
raise
of
hands.
L
So
first
thing
that
I
would
like
to
send
us
a
message
for
you
is
that
in
reality
we
think
that
things
will
look
more
like
this
in
the
future,
because
you
know
the
modules
of
young
that
you
see.
Well,
you
know
you
don't
have
like
billions
of
types
of
routers
out
there,
but
we
will
have
billions
of
devices
so
right
now
we
can.
We
say
that
ok,
jung
can
serve
all
this
area
and
actually,
in
fact
we
say
yeah,
so
young
will
be
everywhere.
L
Well,
of
course,
there
will
be
some
parts
that
will
be
non
completely
young.
It
will
be
very,
very
small,
of
course,
but
this
is
may
be
completely
restful.
View
will
be
there.
So
I
hope
I
got
your
attention
and
what,
where
I'm
going
to
be
talking
about
here,
is
an
interaction
model
for
making
IOT
applications
and
for
managing
energy
devices
with
young.
L
So
what
I'm
not
going
to
talk
about
is
how
we
are
going
to
replace
all
the
things
that
have
been
that
we
were
doing
in
in
core
and
I'm
not
going
to
be
talked
about
how
we
are
going
to
be
replacing
the
things
that
re
was
talking
about.
You
know
how
you
do
the
web,
linking
how
you
do
the
gateways,
how
to
you,
how
we
do
restful
pops
up
and
all
that
stuff.
L
So
these
are
things
that
remain
completely
valid
and
I'm
not
going
to
I'm
not
going
to
be
talking
about
how
you
replace
the
semantics
and
things
like
this.
What
I'm
going
to
be
talking
to
be
talking
is
that
this
is
a
way
that
actually
allows
you
to
do
to
have
a
much
richer
way
of
communicating
of
communication
and
interaction
between
the
devices
you
either
in
a
thing
to
think
fashion
or
from
a
centralized
to
thing
or
I
think
the
device.
L
L
What
is
what
what's
not
an
interaction?
Well,
when
you
have
like
different
things,
talking
dif
different
languages,
having
different
representations
of
the
of
the
data.
So
what
is
an
interaction
model
description,
for
example,
in
a
restful
application?
Well,
you
have
links.
You
follow
the
links,
then,
in
these
links
you
get
some
content
formats
and
then
you
find
out
how
to
submit
some
forms,
and
then
this
is
how
you
know
you
go
from
one
device
or
from
one
resource
to
another,
and
this
is
how
you
interact
with
this
end
device.
L
So
now
what
and
this
is
an
example,
so
you
have
like
a
simple
request
that
says
put
and
you
have
some
resource
and
on
this
resource
you
have
some
data
representation
and
the
value
25,
so
you
put
some
temperature
there
and
then
you
have
some
answers.
That's
okay!
That
I
updated
the
I
updated
is
for
you.
So
you
know
this
is
like
a
method:
the
URI
that
you're
in
the
syntax
and
the
data
variables.
L
So
the
question
is
how
you
actually
know
so
this
answers
a
lot
of
questions
about
how
that
you
actually
interact
with
this
device,
and
this
is
actually
provides
you
with
with
the
semantics
of
what
you
are
doing
there
so
now.
The
big
question
is:
how
do
you
know?
So
how
does
the
desert
the
client?
How
does
this
the
client
knows
that
here?
Actually,
the
cloud
must
send
25
so
that
this
is
a
temperature
that
is
in
degrees.
L
You
know
you
went
through
all
the
parts
you
you
found
that
there
is
a
you
right
and
you
found
that
you
can
do
it
put
on
it
and
then
you
can,
you
can
learn.
You
know
cake
out.
Why
not?
Why
not
just
put
like
a
string?
What
so,
how
would
can
indicate
me
what
I
can
do
with
this
link
or
how
can
I
know
that,
for
example,
of
a
very
huge
value,
a
very
huge
integer
is
not
a
valid
thing
to
do.
L
Well,
of
course,
when
you
do
restful
api
ice,
you
have
this
and
you
have
this
in
coral.
You
have
this
in
the
other
thing
that
I
forgot.
How?
What
is
the
name
is
you
have
a
waiting
to
get
this
information
and
one
of
the
ways
is,
for
example,
you
have
like
content
type
here
that
will
say
that
will
indicate
you
well.
This
is
the
type
of
content
which
you
can
give
to
this
resource,
in
which
you
can
that
forget
from
resource,
and
this
way
we
will
interact
with
it.
L
So
let
me
present
you
with
another
with
another
alternative
to
this.
So
of
course
you
can
go.
You
can
use
your
restful
api,
so
you
can
use
your
restful
way
to
finding
all
links
in
all
resources
and
then
at
some
point
you
stumble
other
thing
that
is
marked
as
being
calm,
I
or
as
being
young.
So
when
you
do
this,
so
you
discover
it,
and
when
you
do
this,
you
can
actually
send
a
much
richer
set
of
interaction.
You
can
have
a
much
richer
set
of
interaction
with
this
entry
point.
L
The
thing
that
is
really
important
here
is
that
young
actually
defines
has
a
way
to
defining
schema.
So
you
can
get
the
model
of
interaction
with
this
Buddhist
point,
so
you
can
now
okay,
there
I
have
under
this
point,
I
have
a
temperature
and
this
temperature
is
expressed
in
Celsion,
and
this
cell
sium
can
be
from
0
to
200
degrees
Celsius.
So
you
use
your
restroom
engine
to
get
to
this
point,
and
then
you
know
how
to
interact
with
it.
You
know
that
you
can
have
temperature
humidity
or
something
else.
You
can
get
some
values.
L
You
know
some
values
that
can
be
read
only
and
so
forth.
So
all
these
things
are
already
there
and
they're
well
understood
by
most
more
than
half
of
you
now
in
the
indie
in
this
room.
So
you
know
about
the
young.
You
know
how
to
describe
this
interaction.
So
basically
it
comes
like
a
medium
term
solution
that
gives
actually
quite
a
lot
of
power.
You
know
between
the
fully
restful
application,
where
you
have
the
haters
and
when
you
go,
and
you
discover
all
the
things
and
you
need
to
understand
them
here.
L
You
have
all
this
thing
that
are
already
there
and
we
have
the
protocol.
That
is
there
so
come
by
the
protocol,
which
is
under
discussion
a
lot
in
in
the
core
working
group,
and
we
have
all
these
mappings
that
order
to
do
this
actually
quite
efficiently.
So,
okay,
I
think
that
was
the
last
slide
and
I
flipped.
Over
with
this,
I
would
like
to
submit
to
you
that
you
know
we
have
the
restful
way.
That
is
like
that
in
the
haters
way.
L
That
is
like
the
the
long-term
ideal
vision
of
the
world,
and
we
have
the
same
thing:
minus
one
that
is
a
little
bit
much
much
closer
and
which
can
give
you
a
lot
of
the
things
that
we
are
actually
good
that
we
care
about
how
we
do
how
we
build
applications
in
a
much
in
a
specific
and
concrete
way
that
work
today
and
that
can
scale
for
a
iot
thanks.
Thank
you.
So.
A
Whose
heads
are
spinning
no
nobody's
had
this
funny
35
whose
whose
heads
are
spinning
in
a
comfortable
way,
I
mean
who
liked
what
they
saw
in
the
last
hour
here.
Nobody
liked
what
they
saw,
who
did
not
like
what
they
saw,
would
not
come
to
another
meeting
of
this
group.
Okay,
can't
people
to
raise
their
hands.
A
Thank
you
for
coming
anyway.
We
are
likely
to
have
further
summary
meetings
of
this
kind
here
and,
of
course,
if
you
are
in
active
in
the
research
group,
you
can
suggest
topics
that
we
are
you
talking
about
at
these
summary
meetings
and
if
you
are
not
active,
you
also
can
suggest
topics
that
we
should
be
talking
about.
So
with
that
enjoy
the
plenary.