►
From YouTube: IETF-T2TRG-20220310-1500
Description
T2TRG meeting session at IETF
2022/03/10 1500
https://datatracker.ietf.org/meeting//proceedings/
B
So
we
are
now
at
the
top
of
the
hour,
so
let's
get
started.
Welcome
everyone
to
the
fingertiping
research
group,
this
pre-idf
113
summary
meeting.
So
we
are
not
planning
to
meet
at
the
idea
face-to-face
meetings,
so
instead
we're
having
this
meeting
summer
meeting
before
the
actual
ietf
week,
so
my
name
is
arik
keran
and
karsten.
Bormann
is
also
the
co-chair
of
the
group.
Also
in
this
meeting.
B
B
You
can
check
out
the
following
two
slides
in
the
share
slide
deck,
but
I
think
most
of
you
are
already
quite
familiar
with
them,
a
quick
reminder
about
the
goals
of
the
irtf,
so
here
in
irdf,
we
focus
on
long-term
research
issues
that
relate
to
the
internet,
so
we
do
actually
make
research
here
instead
of
standards,
although
we
do
work
very
closely
together
with
the
ietf,
where
the
actual
standardization
work
happens
here.
Really,
the
primary
goal
is
to
promote
development
of
research,
collaboration,
teamwork,
exploring.
B
Quick
administrative
issues:
we
have
notes
at
the
url
that
you
see
on
the
slides
today.
Please
go
ahead
and
join
the
the
ether
pad
well
kodi
md
nowadays,
and
we
also
still
have
a
jabra
channel
that
is
connected
to
the
meet
the
code
chat.
You
can
also
use
the
medical
application
to
join
and,
finally,
if
you're,
not
at
the
mailing
list
already,
please
do
join
it.
B
B
After
that
we'll
go
to
the
main
part
of
the
meeting.
We
have
a
a
half
an
hour
session,
around
security
considerations
for
constant
restful
environments,
seccore
a
new
thing
to
research
group
activity.
We
have
had
quite
a
bit
of
work
on
iot
security
before,
but
it's
going
to
be
a
more
focused
set
of
activities
happening
and
uran.
B
Will
give
you
an
overview
of
that
then
a
particular
item
related
to
that
work.
Your
matter
will
be
presenting
amplification
attacks
on
iot
after
that,
we'll
have
a
as
a
research
talk
from
savio
on
security,
extensions
for
using
much
to
give
fast
response
to
new
vulnerabilities
on
domestic
id
networks,
and
then
we
have
a
couple
of
updates
from
a
organizations
that
we
have
close
collaboration
with.
So
michael
mccool
will
talk
about
the
double
to
receive
web
of
things,
and
michael
koster
will
give
an
update
on
the
one
dm
and
iot
schema.
B
B
Okay,
then,
going
for
the
update,
so
we
have
had
usually
the
wishy
activity,
by
or
or
by
one
monthly
meetings
or
monthly
meetings,
depending
on
on
that
on
the
occasion
where
we
look
at
these
interoperability
aspects
on
on
semantics
and
hyper
media
and
we're
planning
to
start
a
similar
meeting
series
around
our
own
security.
B
So,
as
I
mentioned
before,
we
don't
have
a
thinking,
artsy
meeting
planned
at
the
idea
face-to-face.
Instead,
we
have
this
summary
meeting
before
we
have
had
a
set
of
online
meetings
earlier
with
different
sdos,
for
example,
w3c
with
oma,
but
also
very
much
looking
forward
to
have
similar
meetings
with
other
alliances
and
in
particular
open
source
communities.
B
So,
if
you're
interested
to
have
a
such
meetings
together
with
us,
please
go
ahead
and
approach
us
chairs
very
happy
to
work
together
with
you.
Also.
We
are
thinking
of
having
a
work
meeting
so,
whereas
this
meeting
is
a
summary
meeting
where
you
mostly
hear
about
the
updates
of
various
activities,
we're
planning
to
have
a
work
meeting
where
we
actually
have
more
of
these
research
focused
discussions
and
currently
planning
one
around
april
may
time
frame.
B
B
Also,
we
are
always
very
keen
on
having
a
collocation
with
academic
conferences.
We
had
one
recently
online
and
doing,
for
example,
another
one
online
this
year
or
maybe
even
face-to-face
going
forward.
That
would
be
very
much
in
our
interest.
B
Then
quickly,
update
of
the
current
research
group
documents,
so
restful
design
for
iot
document
got
a
minor
update
just
a
few
weeks
ago,
mainly
on
puts
method,
use
of
side
effects
and
also
addressing
some
of
the
chair
review
comments.
B
There's
a
plan
to
have
a
bit
more
substantial,
substantial
prs,
pull
requests
on
github
on
some
of
the
bigger
issues
from
the
chair
share,
reviews
going
forward,
and
then
the
idea
is
to
move
towards
research
group
last
call:
it's
an
iot
got
a
bit
more
substantial
update
recently
and
now
it's
waiting
for
chair
reviews
and
also
reset
scope
last
call
coming
hopefully
very
soon.
B
Then
we
have
had
a
quite
a
long
standing
process
on
the
secure
iot.
Bootstrapping
traffic
is
nowadays
known
as
terminology
and
processes
for
initial
initial
security
setup
for
iot
devices.
We
didn't
have
an
update
for
this
meeting,
but
what
a
check
with
the
authors-
and
they
said
that
work
is
still
ongoing
and
we
can
hopefully
get
updates
on
that
also
soon.
B
One
is
this
iot
information
model
standards
prescription
and
there's
a
related
work
on
semantic
landscape
that
has
been
discussed
earlier
in
wishy
and
there's
probably
going
to
be
a
new
draft
coming
on
that
topic
soon,
and
also
we
have
had
this
idea
of
id
work
on
the
route
of
trust
security
work
from
from
michael
richardson,
and
for
that
we
actually
got
a
review
quite
recently
hasn't
yet
been
posted
on
the
mailing
list,
but
it
seems
to
be
raising
interest
from
from
different
people.
B
So
we
look
forward
to
also
the
progress
that
work
and
finally,
we
have
had,
in
the
wishy
context,
quite
a
lot
of
discussions
and
there's
an
plan
to
make
potentially
research
group
documents
on
some
of
those.
What
we
call
now
wishing
notes,
for
example,
around
terminology.
B
Then
a
quick
update
on
the
wishy
activity,
so
a
lot
of
the
work
related
wishy
has
been
recently
happening
in
the
asdf
and
one
dm
context
so
where
in
which,
if
we
look
at
this
hyper
media
and
semantic
heating
durability,
a
lot
of
a
lot
of
those
topics
have
been
now
discussed
in
those
two
fora.
We
did
have
one
meeting
in
november,
where
we
discussed
web
of
things.
Topics
in
particular,
however,
things
think
descriptions
and
things
models
relate
to
sdf
how
these
technologies
can
be
interworking
together.
B
Also,
we
have
been
discussing
ipso
model
sdf
dtdl
interwork,
and
make
an
implementation
of
that.
How
we
could
bringing
these
multiple
data
model
technologies
together
and
demonstrating
how
they
can
be
nicely
working
together.
B
B
So
that
was
the
quick
update
on
the
research
group
status,
any
questions
or
comments
from.
B
Anyone
okay
hearing,
no
questions.
Next,
it
would
be
uran
and
sakura.
D
Thank
you,
carson,
okay,
so
I'm
joran
I'm
going
to
talk
about
this
new
topic
series
for
thing
to
think
rg,
which
we
called
seccore,
which
deals
with
security
for
co-op
based
applications
or
more
generally
constrained
restful
environments.
D
D
So
that's
that's
what
we
went
for
and
this
so
there's
been
a
series
of
planning
meetings
in
tttrg
and
we've
discussed
a
little
bit
of
the
content
and
the
forms-
and
this
presentation
is
my
take
on
on
on
the
outcome.
I
don't
think
we
have
converged
exactly
on
on
meeting
schedules
and
topics,
but
so
so
anyone
who
participated
in
the
planning
meetings
are
welcome
to
to
raise
their
voice
and
and
comment
and
then
as
it's
anyone
else.
D
Of
course,
if
they're
having
comments,
so
this
work
actually
started
with
a
breakout
meeting
at
the
core
working
group,
itf
113
in
november,
where
we
realized
that
we
need
to
do
more
work
on
on
security
for
co-op-based
applications,
and
this
slide
is
just
showing
that
we
do
work
already
on
on
security
for
applications.
Here
are
two
examples,
and
so
we
do
work
in
the
itf
like.
The
first
example
is
a
recent
rfc
looking
at
security
enhancements
for
co-op.
D
There
also
other
work
in
ace
and
lake
and
cozy,
and
so
on,
on
security
related
to
co-op
applications,
but
there
is
also
work
done
outside
itf,
which
is
used
in
sort
of
use,
results
that
are
needed
by
by
the
idf
and
this.
The
second
example
here,
which
related
to
a
problem
that
appeared
in
with
co-op
group
communication.
D
So
that's
the
example
on
the
bottom
right,
where
we
have
a
multicast
co-op
message
or
a
co-op
over
ip
multicast,
for
example,
which
is
signed
and
where
the
response
could
either
be
a
signed
message
or
a
emacked
message
and
in
particular,
in
the
case
when
there
is
unicast
response,
it
certainly
makes
sense
to
just
have
a
mac
targeting
the
the
the
sender,
the
client
in
this
case.
D
Could
we
use
the
same
public
key
for
creating
a
shared
secret
with
the
client
and
derive
a
key
used
for
the
for
the
mac,
and
is
that
secure?
Basically,
that
was
the
question,
and
this
was
proven
by
eric
to
marker
in
this-
it's
a
reference
here
to
to
a
proof,
so
that's
the
type,
an
example
of
a
result
which,
where
we
needed
some
research
to
advance
the
the
the
work
in
the
itf
in
this
case
the
the
group
security
for
co-op.
D
D
So
with
this
in
mind,
we
started
to
think
about
this.
We
have
we
need
to
do
more
work
on
security
for
co-op-based
applications,
and
these
this
could
example
be
topics
that
are
not
not
in
scope
of
a
single
working
group,
so
we
or
or
an
itf
working
group
at
all,
but
we
could
see
that
there
is
plenty
of
space
in
the
ttr
rd
charter
to
actually
perform
a
security
research
group
for
for
iot.
D
So
so
the
rationale
here
is
that
we
we
think
there
is
a
need
for
for
a
space
where
we
can
gather
researchers
and
other
people
who
are
interested
and
to
progress
the
research
as
one
one
one
important
item,
but
also
to
explain
the
results
for
those
interested,
but
perhaps
not
experts
in
in
the
in
that
particular
security
area,
and
these
results
can
then
be
reported.
Also
at
the
summary
meetings
like
like
this
meet.
D
So
that's
that's,
basically
the
setup
for
motivation
for
this
work.
The
type
of
results
that
we
expect
is
specific
research
papers
or
or
preprints.
It
could
be
surveys
so
which
they're
already
I
mean
this.
There
is
already
an
example
of
that
the
t2trg
rfc
on
it
security,
or
it
could
be
that
we
are
discussing
topic
spanning
multiple
itf
working
groups,
which
doesn't
have
an
established
home
and
there's
an
example
next
slide
and,
as
ari
pointed
out,
the
the
work
in
this
should
be
related,
of
course,
to
somehow
to
idf
work.
D
And
here
is,
I
wanted
to
write
candidate
topics,
but
that's
not
I
I
didn't
want
to
do
that
because
there
are.
Some
of
these
drafts
are
adopted
in
other
working
groups,
and
this
is
not
intended
to
be
a
competing
activity.
It's
a
supporting
activity
where
we
collaborate
with
with
working
groups,
and
we
try
to
solve
problems
that
doesn't
have
any
other
home,
basically,
where
we
can
work
on
them.
D
D
So
we
also
in
this
group
started
to
think
about
how
to
group
topics
in,
in
short,
made
the
long
term
identifying
what
karsten
is
calling
a
pen
holder,
maybe
a
good
name
secretary,
a
person
that
actually
takes
doesn't
have
to
be
the
one
doing
all
the
job,
but
is
preparing
the
topic
and
providing
the
starting
points,
or
at
least
some
starting
points
for
for
discussion
and
yeah.
So
that's
basically
the
ideas.
I
don't
think
we
have
a
strong
view
yet
on
how
frequent
these
meetings
should
be.
Bi-Monthly
was
a
proposal.
D
D
A
Yeah,
I
didn't
want
to
impinge
on
on
euron's
segment
here,
but
if
we
have
time
at
the
end,
I
will
have
a
quick
teaser
for
something
that
that's
swan
and
maybe
will
be
called
tina.
A
A
So
this
we
don't
need
to
be
extremely
sharp
in
in
distinguishing
things
that
don't
fit
and
distinguishing
things
that
fit
so,
for
instance,
what
I'm
going
to
present
has
has
a
lot
of
interactions
with
who
are
the
actual
players
in
a
security
protocol.
And
how
do
you
set
up
iot
environments?
A
So
I
think
it's
more
important
that
we
get
interesting
conversations
going
between
researchers
on
one
and
and,
of
course,
between
themselves
and
also
between
protocol
developers
in
in
the
iitf
that
want
to
make
sure
that
the
security
concepts
they
come
up
with
actually
are
supported
well
by
research.
B
F
A
E
So
this
seems
not
unreasonable
and
that
there's
clearly
some
some
research
things
here.
I
think
my
only
caution
would
be
looking
at
this
topics
for
inspiration
slide.
There's
a
lot
of
itf
work
so
make
sure
you
understand
the
boundary
between
what
this
group
is
doing
and
what
the
the
itf
is
doing
and
try
to
stay
on
the
research
side.
D
Thanks
yeah,
that's
it
that's
a
good
comment.
We
actually
had
the
discussion
in
the
planning
on
the
boundaries
to
to
working
groups,
to
iot,
iotops
and
and
cfrg
and
other
things
so
yeah.
So
there
that's
clearly
something
to
to
think
about.
I
mean
in
this
case
the
the
boldface
highlighted
here
are
are
not
identified
as
as
iot
sorry
as
itf
working
group
topics.
D
So
so
those
are,
I
think
we
are
safe
and
and
most
of
the
other
drafts
are
not
adopted
and
which,
which
means
that
they
haven't
found
a
home.
But
that's
that's
what
I
just
why
I
just
won't
call
these
topics
for
inspiration.
This
is
not
not
intended
as
a
list
where
we
are
taking
things
with
which
you
already
have
found
between
working.
E
D
B
Great,
thank
you,
colin
and
and
for
everyone
I
mean
if
you
want
to
join
the
comment.
Queue
there's
the
hand
raised
button
in
the
top
left
corner
of
your
of
your
mythico,
so
you
can
use
that
to
join
the
join
the
queue
meanwhile
euron.
What
should
be
for
everyone
who
is
interested
in
enjoying
this
work?
What
should
be
the
right
way
of
going
getting
involved?
B
D
Yeah
that
was
actually
my
question.
Going
back
is:
do
we
need
to
plan
anything
more?
Should
we
just
get
started,
send
out
invitations
and
based
on
that
see,
if
more
people
show
up
and
and
have
proposals
we?
What
we
did
was
we
had
this
this
slide
here,
where
we
said
that
if
you
have
a
topic
that
you
think
is
relevant,
why
don't
you
just
prepare
this
type
of
think
think
through
these
starting
points
here
and
and
come
come
back,
send
an
email
to
the
ttr
list
and
say
I
haven't.
I
have
a
proposal.
D
That's
I
think.
That's
I
mean
it's
fine.
If
anyone
wants
to
contact
me
personally,
that's
that's.
That's
excellent
and
using
the
tttrd
list
is
fine,
showing
up
at
one
of
these
meetings.
When
we
discuss
these
topics
and
say
and
mention
new
topics,
I
think
that
would
be
a
sort
of
recurring
point
on
the
agenda
for
these
meetings.
What
what's
the
next
topic?
What
do
we
have
any
new
topics
in
mind
and
so
on
so
yeah
just
interact
in
any
way
that
you
find
find
easy.
E
Yeah,
so
so
I'm
just
in
terms
of
what
this
thing
could
be
organized
as
to
trg
meetings,
with
a
focus
on
a
particular
topic
right,
which
happens
to
be
the
set
course
stuff
right.
D
H
So
so
this
is
one
of
the
topics
we
we
suggest
should
be
handled
as
sec
core.
It
was
recently
discussed
in
core
and
the
suggestion
was
that
this
would
fit
better
in
thing
to
think
already
and
after
thinking
about
it,
I
I
I
totally
agree
so
this
will.
H
This
short
presentation
will
just
give
an
overview
and
the
presentation
is
about
amplification
attacks,
but
I
think
secor
should
probably
work
with
the
knight
of
service
in
in
general,
so
the
night
distributed
denial
of
service
is
a
huge
and
costly
and
growing
problem
in
general.
It
can
be,
it
has
been
growing
and
you
can
do
quite
many
different,
quite
the
denial
of
service
tech.
You
can
do
something
smart
based
on
the
specific
protocol,
such
as
the
tcp
student,
fluid
attack.
So
you
try
to
drain
the
resources
of
the
server.
H
You
send
a
small
message
to
a
server,
but
you
spoof
the
ip
address,
and
then
you
get
a
request
that
generate
a
large
response
and
the
difference
between
what
the
attacker
send
and
what
reaches
the
target
is
the
amplification
factor,
this
presentation
and
the
draft
I
r
we
recently
submitted
exemplifies
amplification
attack
with
co-op,
doesn't
mean
that
co-op
is
worse
than
other
protocols,
but
there
has
been
some
significant
amplification
attacks
with
co-op
in
recent
years
and
it's
ex
they
likely
used
co-op
and
nosek.
H
Luckily,
the
number
of
new
sec
serve
co-op
servers
on
the
public
internet
has
actually
gone
down
quite
drastically.
Since
I
presented
this
in
july,
2021
and
the
big
co-op
attacks
started
in
2018.
H
The
biggest
attack
reached
320
gigabyte
bit
per
second
is
a
very
large
denial
of
service
attacks,
at
least
it
was
in
2018,
then
2019.
The
attacks
totally
stopped
and
quite
little
is
known
on
what
actually
happened.
Most
of
the
reports
are
a
bit
misleading
and
strange,
but
I
think
we
can
conclude
that
they
did
happen,
but
not
how
it
seems
like
co-op.
Amplification
attacks
made
a
return
in
late,
2020
and
2021,
one
and
I'll
say
likely,
because
it's
highlighted
in
this
raspberry
report,
but
the
report
used
the
same
caller
for
coop
m
memcached.
H
H
At
least
they
seem
to
have
disappeared
again
in
the
for
the
rest
of
2021.
yeah.
I
guess
this
is
quite
you
can
see
with
the
other
attacks
here
they
come
and
then
they
disappear
because
the
attack
was
patched
by
the
device
or
they
found
something
better,
so
very
high
level.
H
H
H
And
if
you
combine-
and
you
can
also
use
it-
to
attack
some
service
on
the
local
network,
not
on
the
public
internet,
if
you
combine
them
multicast
and
observe
you
obviously
get
the
application
factor
of
a
times
m
times
n
and
whatever
a
a
and
m
and
n
is
here.
It's
it's
big,
reasonable,
amplification
factor
that
quick
recently
so
atf
has
tightened
the
requirements
on
amplification
factors
recently
had
a
have
which
was
published
recently.
Have
it
must
not
have
an
amplification
factor
over
three,
which
is
a
very
hard
requirement.
H
H
H
If
we
don't
take
care
of
our
denial
of
service
hygiene,
probably
nobody
else
will
either
and
if
the
industry
doesn't
take
care
of
this,
then
probably
regulators
will
step
in.
If
they
do.
We
want
them
to
have
an
idea
for
irdf
document
to
read.
We
don't
want
to
think
this
is
a
perfect
topic
for
tinting
or
the
sec
core.
We
need
to
raise
awareness,
increase,
understanding
and
hopefully
find
some
suitable
mitigation
suitable
for
constrained
devices.
I
think
this
topic
should
handle
the
nano
service
in
in
general,
not
only
amplification
attacks.
A
Yeah,
I
think
the
the
interesting
observation
in
in
this
amplification
environment
is
that,
of
course,
the
amplification
only
becomes
a
threat
if,
if
somebody
actually
uses
it
and
the
the
interest
in
the
community
of
attackers
is
highly
variable,
there
are
fads.
A
People
suddenly
detect
the
ability
to
use
ntp
and
then
they
use
ndp
for
a
while,
and
then
they
start
using
dns,
because
people
are
becoming
better
in
protecting
ntp
and
so
on.
So
the
understanding
the
dynamics
of
of
the
attack
community
is
certainly
one
questions
where,
where
we
could
make
some
some
progress,
better
understanding
what's
going
on,
because
it's
really
not
a
property
of
the
protocol
that
is
of
interest
here.
That
really
is
when
is
this
actually
started?
A
We're
getting
started
to
be
ex
exploited,
and
the
other
observation
is
that,
of
course,
protocols
can
be
deployed
in
different
ways,
and
some
of
these
deployments
are
more
vulnerable
and
some
are
less
vulnerable
and
and
actually
the
the
co-op
standard
contains
security
considerations
telling
people
to
not
deploy
the
more
vulnerable
cases,
but
these
deployments
did
happen.
So
why
did
they
happen?
Was
this
essentially
just
just
a
lack
of
communication
that
people
who
were
planning
deployments,
don't
know
about
the
problem
or
were
the
the
requirements
that
we
put
there?
A
Were
they
actually
not
requirements
that
people
could
follow?
So
so
there
was
this
incentive
following
the
requirements,
because
that
created
operation
problems
or
something
so
this
is
again
something
that
that
is
very
hard
to
to
assess
from
a
distance
and
where
we
could
really
benefit
from
research.
I
mean
people
can
go
out
and
and
try
to
get
interviews
with
people
who
have
running
these
deployments
and
so
on.
A
This
is
research
that
that
would
be
really
useful
and
that's
information
that
then
would
guide
us
in
understanding
what
we
actually
can
do
to
to
make
the
recurrence
of
this
less
likely.
So,
for
instance,
the
the
quick
mandate
is
interesting,
because
it's
very
hard,
it's
very
measurable.
A
You
can
write
an
interrupt
test
for,
for
that,
probably
and
so
yeah.
What
what
are
the
the
best
ways
to
incentivize
implementers
and
and
deploy
us
not
to
create
these
vulnerabilities?
That's
I
think,
then,
the
next
step,
once
we
understand
the
motivations
on
both
sides.
D
D
A
We
can
come
from
from
various
angles
here.
So,
of
course,
there
is
an
existing
community
that
examines
the
ddos
earth
space.
So
talking
to
those
people
will
be
of
interest.
A
We
know
of
the
the
various
open
source
implementations,
so
this
may
be
a
channel
to
actually
talk
to
find
and
talk
to
people
who
are
deriving
their
implementations
from
these
open
source
implementations
and
who
are
building
applications
around
it
and
then,
of
course,
from
from
the
the
ddos
research,
we
might
find
big
deployments
that
we
want
to
address
directly
so
that
there
was
this
one
deployment
that
initially
was
responsible
for
almost
all
of
the
servers
with
a
high
amplification
attack,
and
it
would
have
been
interesting
to
try
to
find
these
people
and
talk
to
them
to
do
interviews
with
them.
A
Of
course,
there
are
limitations
to
all
these
approaches,
but
I
think
in
in
total
they
could
generate
some
some
useful
information.
D
A
Okay,
thank
you.
I
think
we
need
to
do
all
these
all
these
things
and
I
think,
starting
with
with
the
ddos
research
community
and
actually
finding
out
the
structure
there
and
finding
people
who
are
interested
in
this.
What
would
be
a
good
step
to
to
move
this
forward.
A
Oh
there
we
are
at
the
penholder
issue
again,
so
so
somebody
needs
to
push
this
forward
and
that's
probably
someone
who
already
has
a
little
bit
in
the
way
of
channels
talking
to
research,
communities
and
yeah,
of
course,
doing
master
fields
in
this
space
and
so
on.
These
are
all
also
very,
very
useful,
because
there's
a
lot
of
information
out
there
that
we
haven't
gathered
yet,
but
I
think
actually
talking
to
to
the
people
who
do
the
investigations
in
this
space
will
also
be
very
interesting.
D
Okay,
is
there
any
sorry,
michael
for
keeping
keeping
you
waiting?
I
just
wanted
to
sort
of
nail
down
this
one.
Is
there
anyone
that
is
interested
in
going
forward
and
addressing
research
community
in
this
on
these
questions,
or
maybe
they
already
have
experiences.
D
A
A
Vulnerability
to
to
attacks,
and
so
on
and
gathering
these
people
and
and
having
a
special
workshop,
bringing
the
various
views
of
these
people
together
might
be
a
first
step
to
get
them
interested
in
the
subject.
B
I
Yes,
I
mentioned
one
use
case:
we've
been
working
on
discovery
and
we've
been
taking
an
approach
of
a
two-phase
strategy
where
we
have
an
an
open
mechanism,
that's
kind
of
on
on
ramps,
and
then
we
do
authentication.
Then
we
act
as
metadata,
but
your
talk
may
be
realized
that
the
onboarding
of
the
on-ramp
mechanisms
may
themselves.
I
I
So
I
just
thought
I'd
mention
that
use
case
that
I
think
we
need
to
look
in
carefully
at
things
like
discovery
that
are
meant
to
be
open
but
and
would
have
to
be
to
get
started.
But
maybe
we
need
to
really
nail
down
exactly
how
to
minimize
the
the
information
yeah.
H
H
A
B
Okay,
very
good,
I
mean
good
discussions
and
good
input
for
the
work.
I
think
we
have
a
good
amount
of
interest
on
the
whole
area,
secure
security
and
and
secora
going
forward.
So
yeah
as
as
europa
pointed
out,
please
don't
hesitate.
You
know
communicating
on
the
tingling
research
group.
Mailing
list
are
more
on
the
topic
and
then
look
forward
for
announcements
on
the
invitations
to
the
meetings
on
that
topic
and
let's
continue
the
discussions.
Also,
there
now
moving
forward.
We
have
the
research
talk
from
savio
savio.
Please
go
ahead.
F
F
Sorry
here
I'm
gonna
talk
a
bit
about
the
the
rece,
the
product
of
my
master's
research.
My
master's
course
research,
which
resulted
in
the
draft
morris
iotops
issue
which
focuses
in
coordinating
fast
responses
for
two
new
responsibilities
in
home,
iot,
okay,
which
was
was
carried
in
the
in
the
labnet,
which
is
the
computer
network
laboratory.
F
I
have
made
my
masters
in
the
federal
university
of
of
the
united
states
here
in
brazil,
so
going
to
the
point:
okay,
the
main
problem,
not
not
exactly
the
main
problem,
but
one
of
the
problems
that
we
have
in
home,
iot
insecurity
now
is
that
we
have
a
lot
of
persons
having
small
problems
that.
F
A
big
problem
as
the
ddos
problem
or
any
other
any
other
things
with
infected
devices
or
vulnerable
devices
that
can
have
data
leaked
from
malicious
agents
and
for
the
end
users
it's
hard
to
keep
protected
from
these
new
vulnerabilities
as
every
day's.
One
new
vulnerability
is
discovered
from
the
community
from
the
attackers
or
something
like
that,
and
the
idea
behind
this
project
is
to
speed
up
this
response
in
a
community
view,
in
a
coordinated
view
for
many
home
iot
networks.
F
F
All
this
response,
we
always
need
some
fine
tuning.
We
always
need
to
get
news,
attack,
signatures
or
or
vulnerability
signatures,
and
we
we
and
for
doing
this.
We
somehow
need
technical
expertise
for
for
that,
and
they
read
my
users
that
does
not
have
it
and
when
we
use
anomaly
solutions
based
in
anomaly
detection,
we
can
have
some
scenarios
where
the
device
is
prof.
F
The
common
behavior
that
the
normal
behavior
of
the
device
is
profiled
during
one
attack
during
one
infection,
and
also
the
profiling
process,
has
a
high
computational
cost,
and
maybe
the
current
algorithms
has
high
computational
costs
and
in
some
cases
we
need
to
outsource
this
processing
for
cloud
computing
sources
or
something
like
that,
all
supporting
putting
in
risk
my
the
privacy
of
the
end
users,
sending
private
data
from
my
internal
network
to
cloud
computing
services
or
to
a
technical
expert,
a
technical
expert
security
expert
for
analyzing
and
fine-tuning
my
roles
in
my
home
network.
F
And
besides.
Besides
of
that,
we
also
have
one
important
tool,
which
is
also
mentioned
in
the
in
the
in
the
rs
that
is
but
gives
gives
some
tools
to
us
that
supports
the
generation
of
supporters
on
building
a
graph
of
the
network
communication
of
our
iot
devices,
independently
of
our
topology
and
having
this
graph
in
mind
or
in
our
hand.
Sorry,
we
can
identify
it's
easier
for
us
to
identify
threats,
vulnerabilities
attack
paths
or
something
like
that,
because
we
have
one
one,
two,
that
maps
all
the
communications.
F
So
this
is
also
important
and
is
it's
used
in
this
proposal
in
the
proposal
of
issue,
but
the
problem
of
mud
is
that
we
still
keep
relying
in
the
manufacture.
F
Now
we
have
one
one
security
tool
for
giving
a
kind
of
coordination,
coordinated
response
to
a
vulnerability,
for
example,
a
manufacturer
again
releasing
mud
file
blocking
the
traffic
that
it's
related
to
one
one
critical
vulnerability,
but
we
are
still
we
for
for
the
manufacturer
or
the
device
vendor,
and
not
only
this.
The
users
keep
using
the
the
iot
devices
even
when
they
are
they
reached
the
the
end
of
life.
F
The
manufacturer
is
stopping
to
release
security
updates
from
the
device,
so
we
need
some
support
in
this
kind
of
situation,
not
only
during
the
life
cycle
of
the
device
but
after
the
end
of
its
life
cycle.
So
the
idea
of
issue
of
the
proposed
orphan
shoe
is
to
give
the
support
this
cognitive
support
as
a
second
as
a
second
security
support
for
the
ordinary
user,
the
common
users.
F
So
the
the
issue,
the
name,
the
complete
name
of
issue-
is
international
exposure.
Analyzer
utility
is
a
proposed
framework
to
simplify
the
process
of
identification
and
classification
of
potential
vulnerabilities
and
threats,
so
ensure
provides
means
to
give
a
fast
and
coordinated
responses
in
a
community
view
for
new
vulnerabilities
in
iot,
not
only
vulnerabilities
but
attacks
and
and
and
malwares
whatnot,
and
so
on.
F
But
the
fine-tuning
process
of
these
signatures
is
made
by
issue
in
the
internal
network
by
using
the
information
provided
by
mug.
So
we
keep
the
end
users,
privacy,
as
we
do
not
need
the
the
third
part
support
our
rules,
our
signature
signatures
and
all
these
works.
F
How
this
process
works
by
using
knowledge
sharing
for
the
the
community
protection
as
a
whole?
Okay
and
more
than
on
the
the
holy
community
protection.
F
We
also
have
one
on
protection
for
the
whole
internet
community
when
we
talk
about,
for
example,
botnets.
So
this
is
the
architecture
of
issue
we
have
basically
incorporated
integrated
the
whole
functioning
of
mud
and
in
as
the
output
of
mud,
we
have
the
communication
graph
of
the
of
the
network,
and
then
we
we
use
this.
F
We
will
process
this
information
and
identify
and
assess
potential
threats
in
our
network
and
by
comparing
the
signatures
of
malicious
trafficking
of
attacks
and
mars
and
the
the
actual
traffic
that
we
can
have
in
our
network,
which
was
provided
by
web.
So
we
also
proposed
in
this
draft
the
malicious
description
data
model,
which
is
which
is
an
end
data
model.
Inspired,
is
strongly
expired
in
the
data
model,
where
we
use
access
control
list
for
describing
the
the
attack
or
in
our
signature,
the
whole
traffic,
for
example,
a
common
network
service.
F
So
we
use
this
this
the
acls
for
describing
the
traffic,
but
we
also
have
the
context
information
in
this
signature,
which
describes
the
the
conditions,
the
scenarios
of
where
the
combination
of
of
exposure
of
vulnerabilities
can
can
become
a
real
threat,
a
real
risk
where
someone
can
exploit
it
for
for
care
on
one
attack.
F
So
this
is
basically
how
do
we
describe
the
the
the
two
kinds
of
of
malicious
activities,
isolated
attacks
and
malwares,
where
we
we
separate
the
both
things
because
attack.
F
Attacks
here
we
understand
as
one
single
attack
a
coordinate,
not
coordinated
attack
carried
by
only
one
person
exploiting
one
or
two
just
a
few
vulnerabilities,
as,
for
example,
someone
brought
foss
in
my
my
the
ssh
of
my
cpe,
for
example,
and
then
our
description
is
a
way
more
complex
and
has
much
more
complex
information
with
combination
of
of
critical
traffic
that
can
become
or
not,
malicious,
risky.
Sorry
so
in
each
attack
or
mower
is,
is
defined
by
one
or
more
acl
control
list.
F
F
The
access
to
a
telnet
port
has
one
one
integer
value
associated
that
if
there
is
a
exists,
one
exposure
with
some
all
this
this
this
risky
exposure
and
then
identify
is
that
acl
is
risky
or
not,
and
also
in
the
scenario
of
mowers.
We
have
combination
of
risky
acls
which
which
here
we
we
mentioned
as
critical
ecl,
sets
that
when
we
have
this
combination
of
criticals,
we
have.
We
indicate
one
action
to
take
when
we
identify
the
this
combination
of
critical
issues.
F
So
the
process
starts
by
by
with
the
the
network
communication
graph
provided
by
mud.
So
we
get
each
one
of
these
links.
This
is
a
just
for
a
visual.
F
Tool
that
the
mod
visualizer
provides
us
just
to
to
give
an
example,
a
visual
example
for
you,
so
each
one
of
these
links
is
compared
with
each
one
of
the
access
confluences
in
the
mtd
file
and
then
the
first
phase
of
the
the
assessment
of
threats
is
on
identifying
the
exposure
of
vulnerabilities.
F
In
case
of
this,
in
tcp
communication,
we
can
specify
this
tcp
initiator
the
transport
in
case
of
transport,
header,
tcp
or
udp.
You
can.
You
will
compare
the
source
and
destination
ports
and,
in
case
of
icmp,
they
type
in
the
code
of
the
message:
nothing
exactly
new,
but
after
identifying
a
complete
match
of
of
communication
link
and
malicious
traffic
description,
we
will
combine
all
them
for
assessing
the
the
the
trap.
The
this
approach
assessing
the
combination
of
exposures
to
understand
if
it
is
a
really
a
real
threat.
F
F
That
is
specific,
specifically
assessing
the
trap
where,
in
the
context
of
isolated
attacks,
we
just
block
or
suggest
to
block,
depending
on
the
implementation,
and
that's
that
link
that
communication,
or
in
the
case
of
malware,
we
will
see
all
the
acls
that
access
control
list
that
are
in
the
context
of
that
malware
and
verify.
If
we
have.
F
Some
combination
of
critical
sales
acl
sets
as
a
risky,
as
as
a
risky
combination
as
a
great
combination
and
then
take
the
action
that
is
indicated
in
the
in
the
malicious
traffic
descriptive
and
then,
when,
when
that
file
can
see
which
links
we
can
block
single
links,
simple
links
and
broke
the
chain
of
the
attack
and
reduce
the
threat,
the
risk
of
trap.
F
F
F
Results
with
issue
where,
for
example,
while
we
were
using
mud,
we
still
had
generation
of
the
dos
packets
in
in
a
private
network
and
while
in
issue
we
did
not
have
any
generation
mud
blocked,
almost
every
traffic
but
but
ensure
did
not
generate
anyone.
So
I
can't
go
ahead,
but
basically
it
should
block
at
all
the
traffic
that
we
that
we
describe
it,
and
this
is
the
the
relative
gain
that
we
have
that
we
had
of
issue
over
month.
I
had
we
have
one
paper
published
with
this.
F
So
we
understand
that
maybe
ensure
can
be
improved
by
using
its
output
as
a
filter
for
the
input
of
an
on
anomaly
detection
algorithm,
and
then
we
are
planning
to
test
with
different
approaches
for
profiling.
The
vast
devices
traffic
and
identifying
these
anomalies
and
about
improving
the
issue
proposal
itself.
F
The
draft
itself
we
currently
are
still
working
in
the
transport
layer,
but
considering
what
we
had
in
our
in
our
experiment,
we
saw
that
we
still
can
exploit
dns
traffic
even
with
with
the
deployment
of
issue,
so
we
are
planning
to
go
to
the
application
layer
only
for
protecting
dns
and
also
deploy
and
test
ensuring
in
the
real
world
for
measuring
the
impacts
in
usability
and
see
other
things
that
we
can
improve
it,
and
we
also
have
one
undergoing
one:
ongoing
undergrad
thesis
being
developed
in
the
federal
university
of
eugene
on
a
collective
approach
show
to
profiling
one
hour
with
the
same
idea
of
keeping
the
end
user
private,
even
when
we
share
data
of
our
traffic,
but
we
are
still
trying
to
find
some
ways
to
share
this
information
and
keep
privacy
of
my
network
and
the
final
output
of
this
research.
F
The
idea
is
to
have
the
automatic
generator
of
malaysia
traffic
description
files,
so
that's
all
for
now,
but
I'm
hoping
to
listen
to
any
comments
or
questions.
Thank
you.
B
Great
thank
you
savio
and
for
anyone
who
would
like
to
learn
more
about
this
topic,
I
guess
reading
a
draft
and
having
a
look
at
the
related
research
paper
are
those
the
best
sources.
B
Yes,
no,
you
should
be
able
to
talk
oh
yeah,
so,
but
my
question
was
like:
if
someone
would
like
to
have
a
bit
more
reading
on
the
topic,
you
have
now
a
link
to
the
draft
on
the
slides.
I
guess
also.
We
could
put
a
link
to
the
research
paper
that
you
had
on
the
topic
that
people
can
kind
of
have
a
look
at
that.
F
A
Yeah
I
like
the
offer
of
sharing
your
master's
thesis,
so
that
could
go
into
a
collection
of
documents
that
we
collect
in
conjunction
with
the
secor
activity.
But
I
I
have
two
questions,
one
one
very
specific
to
your
slides.
You,
you
went
over
slide,
13
a
little
bit
quickly.
A
So
can
you
quickly
explain
what
this
two
letter
you
go
back
to
slide
13
and
quickly
explain
what
the
these
two
letter
things
were.
I'm
not
sure
I
understood
that.
A
F
The
the
meaning
of
controllable,
controllable
bots
is
the
number
of
bots
that
really
were
connected
with
the
common
and
control
of
the
of
the
myriad
but
not
divided
in
the
variant.
We
use
it
in
this
pyramid
so
how
many
bots
really
connected
to
the
to
the
command
and
control
circuit.
A
So
the
the
first
two
items
we
can
see
here
is
that
normally
more
than
100
nodes
go
into
the
the
botnet
and
some
20
less
than
20
are
infected,
and
when
you
switch
on
your
mud
implementation,
you
you
only
have
40
who
join
the
the
net
and
almost
no
one
is
infected.
Do
you
read
this
right.
F
We
had
some
scenarios
where
we
started
with.
In
all
the
scenarios
we
had
at
least
one
device
infected,
but
in
this
we
had
100
bucks
in
in
the
experiment
in
in
the
paper
in
the
diseases.
I
explained
better
this
number,
but
this
this
metric,
the
the
cb
we
get
from
the
really
connected
device
to
the
to
the
to
the
server.
So
even
with
the
device
infected.
F
If
it
starts
infected
in
the
in
the
running
of
this
experiment,
it
cannot
connect
to
the
server
because
some
solutions
block
well
so,
for
example,
in
this
second
scenario,
from
the
left
to
the
right,
where
all
the
devices
were
infected,
but
mud
was
was
deployed,
but
mod
based
rooms
were
were
deployed
only
40
or
or
I
think
that
was
it.
A
A
Okay,
so
my
second
point
was
you:
you
now
have
these
mud
files
and
the
malicious
traffic
descriptions,
and
so
on
and,
of
course,
that
to
be
useful,
this
needs
to
become
a
pretty
sizable
collection
of
data.
A
So
do
you
have
any
idea
how
you
would
want
to
to
organize
cooperation
with
other
groups
on
sharing
this
data
so
that
there
is,
for
instance,
this
group
in
australia,
which
has
collected
a
lot
of
mod
files,
and
I
think
it
would
be
interesting,
interesting
to
bring
these
data
together
and
get
a
little
bit
of
a
synthesis
between
what
we
have
from
from
the
various
groups.
Working
on
this.
Do
you
have
any
any
idea
how
to
do
this,
or
do
you
want
to
help
doing
that.
F
The
mod
files
that
I
used
in
the
experiment
were
the
were
the
ones
that
was
provided
by
the
group
in
australia,
so
the
the
networking
started
there
but
yeah
I
can.
I
can
share
the
the
malaysia
traffic,
the
malicious
description
file
and
I
also
have
in
my
github
account
the
data
that
I
collected
from
this
experiment.
F
If
someone
else
can
can
check
it
and
they
can
find
some
way
to
to
share
all
this
information,
but
I
think
that
in
the
draft
I
have,
I
have
put
the
as
one
example
of
mtd
file,
the
example
that
I
used
in
this
experiment
based
in
this
variant
of
my
life.
So
it
is
all
it
is
public,
but
maybe
we
can
find
some
some
other
way
to
share
it.
I
am
completely
open
for
for
sharing
it.
A
C
C
Well,
well,
you
did
an
experiment
yeah,
so
I'm
interested
in
what
controller
you
used,
and
you
know
you
wrote
mud
files
and
not
every
so
far.
I
don't
know
anyone
who's
implemented,
all
of
the
mud
spec,
so
I
was
interested
in
what
you'd
had
and
and
then,
if
also
and
if
you
actually
were
just
using
routers,
which
were
home
routers,
which
were
vulnerable
to
mirai,
whether
the
mud
controller
was
running
on
them,
they
were
protecting
themselves
or
something
else
was
protecting
them.
F
For
the
experiment
I
have
as
I,
as
I
said
in
the
in
these
lights,
it
was
in
vitro
past,
like
I
used
docket
containers
with
open
telnet
servers
for
simulating
vulnerable
iot
devices,
so
it
was
not
like
in
actual
devices.
It
was
really
in
vitro,
not
like
real
traffic.
It
was
just
like
the
my
right
traffic
in
the
in
the
network.
It
was
really
individual.
C
Okay,
so
basically,
what
you're
telling
me
is
you
had
containers
running
vulnerable
instances
with
a
telnet
server
running,
and
I
guess
this
is
some
really
old,
open,
wrt
or
something
like
that
running
inside
of
it
or
and
then
your
mud
controller
was
something
you
built
yourself.
C
F
Those
rules
by
hand
with
in
the
the
open
v
switch,
which
was
connecting
the
the
devices.
B
Okay.
Thank
you.
Sorry
thank
you
for
the
good
discussions
we're
now
approaching
towards
the
end
of
the
this
slot.
So
thanks
again
for
the
good
discussions.
Definitely,
let's
continue
them
on
their
thinking,
research,
school
mailing
list
and
also,
of
course,
on
the
sec
core
activity.
I
think
this
could
be
a
good
fit
to
be
also
discussed
there,
and
now
we
have
next
w3c
web
of
things
update
from
michael
mccool.
I
Great
there
you
go,
oh
so
we'll
say:
I've
got
a
fair
number
of
slides
here,
but
I
will
basically
quickly
go
over
things
that
people
have
seen
before
most
likely
and
then
focus
on
some
topics
that
are
more
discussion
oriented.
I
So,
okay,
what's
the
other
things
we're
basically
trying
to
adapt
web
technology
to
iot
and
the
the
gap
we
identified
a
while
back
was
a
lack
of
a
common.
You
know,
narrow
waste
and
the
ship
had
sailed
make
that
narrow
waste
protocol.
So
we
focused
instead
on
common
metadata
to
describe
interfaces
across
protocols,
and
so
we're
kind
of
looking
at.
I
You
know
how
to
build
the
layer
between
protocols,
not
just
focusing
on
one
particle
and
and
the
main
deliverable
which
is
already
published,
is
the
thing
description
we
are
currently
on
the
second
round
and
we
are
looking
at
new
standards,
including
one
for
discovery
which
I'll
talk
about
here.
I
Okay,
so
again,
that's
what
td
looks
like
and
it's
basically
a
json
ld
file,
meaning
it
has
semantic
support
and
in
fact
we
in
our
discovery
mechanism
we're
looking
at
enabling
sparkle
queries
to
allow
full
semantic
functionality.
I
I'm
just
going
to
skip
through
this
and
get
to
the
meat
I'll
skip.
This
too.
This
says
say
that
we,
generally
speaking,
can
deploy
tds
in
different
use
cases.
It
can
be,
you
know,
peer-to-peer
devices,
it
could
be
clouds
or
devices,
it
could
be
between
two
cloud
services
and
so
forth.
So
we
can
describe
a
range
of
different
services,
they
could
be
individual
devices
and
it
could
also
be
services
in
the
network
or
on
the
edge.
I
Okay,
so
I
want
to
do
a
bit
more
of
a
deep
dive
into
this
and
discuss
the
point
that
I
raised
earlier
about
amplification
attacks
among
other
issues.
So.
I
Constrain
my
pets
here
so
so
in
discovery
we
have
a
spec
that
is
currently
under
review
and
we're
hoping
to
publish
it
later
this
year
and
this
spec
is
about
okay.
We
have
this
metadata
format.
How
do
I
get
it
and
how
I
get
it
in
kind
of
an
ad
hoc
fashion
and
so
we're
looking
at?
I
I
mean
a
two-phase
strategy
where
we
have
introductions
and
we,
the
introductions,
are
kind
of
don't
require
authentication
and
the
second
stage
is
expiration
and
exploration
does
require
authentication
and
the
general
idea
is
to
reuse
existing
mechanisms
for
introductions,
including
simply
being
given
a
url
or
having
it
with
beacon
or
upnp,
or
things
like
this
and
then
the
output
introductions
is
a
set
of
urls,
which
then
you
need
to
access
a
service
authenticate
and
then
get
full
metadata
for
devices.
I
So
the
challenge
here
and
then
the
the
exploration
services.
The
second
phase
can
allow
you
to
do
queries
and
even
things
like
sparkle
endpoints.
To
do
queries,
we've
also
been
looking
at
json
path
and
xpath.
I
The
problem
of
having
is
json
path
is
not
standardized,
yet
it's
still
in
flight
under
I
under
ietf.
So
we're
kind
of
waiting
for
that,
but
it
currently
lacks
particular
substring
matching
and
regular
expression
matching,
which
we
feel
are
important
for
filtering
out.
Tds
xpath
is
great
and
it
has
json
support,
but
there's
not
a
lot
of
industry
pickup
of
it,
and
there
are
enough
implementations
out
there.
So
we
decided
not
to
include
it
and
sparkle.
I
Is
there,
but
it's
relatively
expensive
to
implement
so
so
we're
kind
of
waiting
for
jsonpath
to
really
make
queries
be
appeals
by
the
right
level.
We
also
are
still.
We
were
originally
going
to
be
doing
location
based
queries,
but
we
decided
to
defer
that
because
we're
we're
waiting
for
some
convergence
on
geospatial
data
anyways.
So
I
I
have.
I
have
a
link
in
the
in
the
minutes
about
an
issue
about
the
amplification
attacks
and
we're
we're
probably
going
to
figure
out
how
to
limit.
I
You
know
introductions
that
return
multiple
urls
and
require
I'm
going
to
look
particular
at
core
rd,
which
is
one
of
the
introductions
that
we've
included
probably
require
authentication.
If
you
have
lots
of
results
from
core
id
anyways.
Let
me
just
plow
through
here,
so
we've
been
updating
our
scripting
api.
This
is
not
normative,
but
we've
been
looking
very
closely
at
how
to
deal
with
things
at
discovery
as
well,
and
we
also
have
various
integrations
within
the
node-red
that
also
support
discovery.
Now
I
won't
really
dive
into
this.
I
Just
these
are
out
there
and
there
are
implementations
of
them
node.
What
is
an
open
source
implementation
that
can
consume
tds
and
then
talk
to
them
using
the
watt
abstraction,
but
it's
not
a
normative
part
of
the
spec.
I
We
also
have
a
huge
document
with
lots
and
lots
of
use
cases
and
we're
currently
analyzing
these
to
derive
requirements
for
a
further
round
of
work.
On
other
things,
and
in
particular
you
know,
looking
at
things
like
you
know,
muds
looking
at
you
know
proxies
how
hubs
work,
lands
and
onboarding
mechanisms.
So
there's
a
bunch
of
things
that
are
currently
gaps
in
the
watt
spec.
I
That
kind
of
are
appear
in
some
use
cases,
a
geolocation
information,
so
we're
going
to
be
looking
at
those
probably
in
a
new
round,
but
we
haven't
been
decided
yet.
But
sometime
in
the
fall,
we're
now
finishing
up
this
phase
and
the
fall
will
be
discussing
you
know:
do
we
do
another
round,
and
if
so,
what
does
it
include?
I
So
I
would
welcome
comments
on
things
that
are
gaps,
I'm
not
going
to
flavor
that
I
will
just
mention
that
we
have
a
bunch
of
links
here.
If
you
want
to
do
lots
of
reading.
But
again
the
new
stuff
is
updates
to
td
1.1.
We
have
a
discovery
which
is
totally
new.
We
have
updates
to
architecture
and
there's
also
use
cases
document
down
there.
I
Next
week
we
have
a
plug
fest.
If
you'd
like
to
join
us
and
play
with
watt
you're.
More
than
welcome
just
send
me
an
email,
I'm
also
gonna
in
a
minute
have
a
slide.
I
Talking
about
some
new
applications
and
of
what
in
commercial
applications
actually
and
also
some
open
source
projects
for
discovery,
we
also
have
some
implementations,
at
least
two
of
which
are
open
source
and
allow
you
to
do
queries
of
various
types
and
as
far
as
ietf
goes
a
couple
major
things
I
didn't
mention
actually
json
schema,
which
is
actually
quite
important
to
us,
but
also
json
path
and
and
also
things
like
core
id
and
cos
a
and
asdf
so
we're.
I
We
also
have
a
thing
model
and
we're
looking
very
closely
at
making
that
interconvertible
with
sdf.
So
the
same
information
can
be
expressed
both
ways.
Another
relationship
looking
at
closely
is
open
api.
I
So
a
lot
of
what
things
described
by
watt
tvs
could
also
be
described
by
open
api,
but
open
api
is
sort
of
very
targeted,
http
and
web
of
things.
Thing
descriptions
are
open
to
other
protocols,
including
mqtt
and
co-op,
and
we're
also
looking
at
bacnet
and
opc
ua
and
other
things
like
this
anyways
we're
also
been
looking
at
signatures
to
be
able
to
nail
down
and
constrain
changes
to
watt
tds.
I
That's
not
in
the
current
spec.
We
have
a
draft,
but
we
need
to
like.
We
need
to
align
that
with
json
ld
signatures,
which
are
in
flight
right
now,
and
there's
also
geospatial
data
and
we're
working
with
ogc
to
try
and
get
that
aligned
with
their
standards.
I
Okay,
so
just
mentioned
some
applications,
so
takanatha
corporation
is
a
huge
construction
company
in
japan
and
they
have
been
using
one
of
the
things
for
building
information
systems
so
for
large
commercial
buildings,
keeping
track
of
all
the
various
devices
and
presenting
unified
interfaces
to
them,
and
actually
siemens
has
a
commercial
product
as
well
as
the
same
thing.
I
So
we've
been
actually
been
looking
at
collaborating
with
link
building
data
model
and
things
like
looking
at
the
bot
ontology
and
things
like
this
things,
which
can
work
well
with
the
json
lv
infrastructure
that
we're
establishing
with
thing
descriptions.
I
So
what
thing
descriptions
can
include
extensions
from
other
vocabularies
to
handle
other
kinds
of
metadata,
and
so
you
could
examine.
Imagine,
for
example,
identifying
what
room
a
device
is
in
or
what
zone
a
a
control
or
a
sensor
affects
and
so
forth,
and
these
are
actually
quite
useful
in
bim
systems
and
in
building
management
systems.
I
Netso
it's
a
startup
out
of
basically
from
tom
university
tum
in
munich,
and
they
are
looking
at
creating
dashboards
and
hubs.
So
the
other
place
that
what
method
is
useful
is
to
generate.
I
You
know
integrated
dashboards
for
a
set
of
devices
that
you
want
to
coordinate
and
have
a
nice
single
user
interface
for
ditto
is
an
open
source
project
which
is
primarily,
however,
been
being
driven
by
bosch
and
is
basically,
you
know,
a
foundation
of
their
commercial
products
and
they're
focusing
on
digital
twins,
and
I
will
say
that
oracle
is
also
involved
in
what
is
heavily
invested
in
digital
twins
and
has
a
way
to
interconvert
between
their
proprietary,
digital
twin
model
and
web
of
things
tvs.
I
So
there's
also
some
activity
around
generally
digital
twins
and
having
services
that
can
you
know,
shadow
or
provide
additional
functionality
to
iot
devices
or
even
just
simulate
them
for
testing.
I
Okay,
so
I
guess
I
have
like
five
minutes
left.
Let
me
just
mention
a
range
of
things
that
we
are
you
know
thinking
about
doing
next
and
that
we
probably
need
some
research
on
so
one
gis
integration.
I
didn't
mention
smart
city
applications.
We.
C
I
I
I
But
that
requires
us
to
standardize
the
metadata
for
where
a
device
is
data
management,
digital
twins,
there's
a
bunch
of
patterns
like
shadows
and
simulation
systems
and
proxies.
We
need
to
figure
out
and
we
have
to
figure
out
how
to
handle
historical
data,
perhaps
and
event
notifications
like
you
know
how
often
you
get
them
and
whether
you
want
to
get
notified
if
things
are
differ
from
past
experience
or
whatever.
I
Okay,
however,
I
would
say
the
biggest
blocker
right
now
for
watt
is
definitely
security.
So
what
wanted
to
replicate
the
success
of
the
web
in
iot?
What
does
the
web
have
going
for
it?
It's
like
common
data
format,
html
like
common
protocol
http,
and
it's
a
common
security
infrastructure
structure
for
identity
and
keys
ca
certificate
for
is
okay.
So
in
the
wat
we
focused
on
standardizing
the
data
format
and
describing
protocols
to
get
some
consistency
around
the
abstraction
for
protocols,
okay,
but
we
don't
have,
and
we
have
declared
out
of
scope
in
our
past.
I
I
What
can
be
used
if
you
can
depend
on
ca,
if
you
don't
have
the
ability
to
use
ca,
for
example,
in
a
segmented
network,
you
need
some
other
mechanism
which
is
currently
out
of
scope
for
what,
and
that
means
that
browsers,
for
example,
necessarily
work
out
of
the
box
with
what,
because
you
have
to
set
up
search
and
things
first.
I
So
this
is
a
big
problem.
We,
I
think,
it's
also
kind
of
something
we
need
to
work
with
browser
vendors
and
to
adopt
something
that
works
well,
iot
devices
online,
and
it's
not
like
technical
problem.
There
are
known
ways
to
deal
with
this.
It's
a
problem
of
getting
the
browser
vendors
on
board
and
and
having
some
common
system.
Everyone
agrees
on
is
the
right
thing
to
do
so.
That's
something!
That's
probably
going
to
be
another
big
chunk
of
work
in
the
next
little,
while
also
been
looking
at
accessibility
mapping.
I
You
know
input
and
output
modalities
and
doing
things
like
having
smart
city
services
for
mobility
and
so
forth.
Okay,
I'm
just
gonna
stop
there.
I
know
I've
been
a
little
long,
but
according
to
schedule,
a
couple
minutes.
B
Yes,
thanks
michael,
we
have
a
few
minutes
for
questions.
Carson
go
ahead.
A
Yeah
I
just
wanted
to
to
thank
you
for
this.
I
think
this.
This
list
of
gaps
is
definitely
a
very
useful
piece
for
us,
and
may
we
actually
should
go
into
documenting
in
a
little
bit
more
detail
what
those
gaps
are.
There
is
currently
a
discussion
going
on.
I
forget
which
mailing
list
this
was
about
doing
pki
like
stuff,
with
iot
devices
that
that
are
in
a
home
environment.
A
So
I
think
that
that
will
be
interesting
in
this
context.
I'm
sure
yeah
richardson
has
has
more
thoughts
about
that.
I
Yeah
and
I
think
we
need
a
good
technical
solution
and
then
we
need
to
get
it
adopted
by
browser
vendors,
so
one
of
the
motivations
of
doing
what
is
to
use
browsers
as
a
user
interface
iot
devices
right,
but
you
can't
do
that
right
now,
at
least
not
easily
without
having
a
lot
of
security
set
up
which
an
ordinary
user
will
not
do
so.
That's
our
biggest
problem
right
now.
We
need
to
get
the
browser
vendors
to
buy
into
it.
E
A
B
Thank
you,
okay.
Thank
you.
Thank
you
mike.
Maybe
one
quick
question
like
to
continue
the
discussions
on
these
topics.
What
are
the
best
venues,
for
example,
for
the
sdf
web
of
things
interval,
I
think,
wishing
meetings.
I
will
definitely
continue
that
I
guess
for
the
security
aspects
secure,
perhaps
what
about
for
the
all
the
others?
What
do
you
think
is
the
best
way
to
continue
the
discussion.
I
Well,
w3c
has
both
interest
groups
and
working
groups,
and
so
we're
going
to
be
now
looking
at.
I
think
the
interest
group
need
to
like
explore
various
approaches
in
a
non-normative
setting
that's
sort
of
more
researchy,
but
at
some
point
we
want
to
get
to
the
point
where
we
have
something
we
can
work
towards
a
standard
on.
But
I
think
we
really
need
to
do
is
work
on
our
use
cases
and
get
the
business
case
and
the
incentive
structure
in
place
and,
like
I
said,
get
passwords
on
board
but
yeah.
I
And
ideally
it
was
pick
something
that's
already
been
standardized
and
is
something
that
you
know
is
worth
it
while
adopting
as
part
of
other
things.
B
Okay,
great
thanks
yeah
and
perhaps
we
could
take
a
session
in
one
of
the
working
meet
upcoming
working
meetings
too,
to
explore
this
in
in
more
detail,
but
thanks
a
lot
for
the
overview
and
very,
very
good
good
discussions.
So
now,
let's
move
forward
to
the
1dm
update,
so
michael
coster,
please
go
ahead.
B
G
Should
I
I
will
slide
slideshare
hang
on.
How
do
I
do
this
yeah,
it's
the
second.
B
J
J
Okay
cool,
so
I'm
gonna
mostly
talk
about
one
dm
and
and
summarize
some
stuff,
but
also
have
a
slide
on
iot
schema.
So
how
do
I
advance
the
slides
is
that
is
that
real
obvious
here.
J
J
There's
a
button
at
the
bottom
okay,
so
so,
where
we
are,
is
we
have
a
lot
of
contributed
models
from
oma,
spec
works
and
ocf
that
constitute
about
200
definitions
in
our
playground?
J
We
have
developed
an
operational
process
for
selecting
and
converging
and
what
we
call
adopting
models,
but
this
is
a
hard
problem
to
to
to
do
and
what
we've,
what
we've
kind
of
come
up
with
as
a
metric
as
as
midterm.
Ultimately,
we
want
everyone
to
be
using
the
same
models,
but
in
the
midterm
we
want
to
come
up
with
models
that
will
mostly
work
for
all
the
different
device
ecosystems
and
there
we
recognize
there
may
be
some
corner
cases,
but
this
is
what
we're
kind
of
shooting
for
is
a
midterm
goals.
J
This
is
sort
of
where,
where
we
are
conceptually
in
in
the
organization-
and
we
really
have
great
interworking
between
ocf
and
oma
demonstrated
already
with
the
converters
and
in
fact
a
little
bit
more
about
that
later
and
we've
we've
out
of
the
process
have
come
some
requirements
for
how
designs
really
ought
to
be
structured
to
meet
everybody's
requirements
from
simple
to
complex
without
losing
functional
interoperability.
J
So
internal
functional
modularity
is
kind
of
what
that
looks
like
how
do
we
layer
functions
within
a
definition
so
that
we
can
have
a
semantic
thing
that
has
some
some
varying
depth
to
it
and
and
won't
go
too
deep
into
that,
but
going
forward
what
we're
doing
sort
of
the
new
stuff
there's
a
new
mailing
list,
we're
off
causeway
now
and
we're
on
o.
So
you
can
sign
up
for
that.
It's
just
one
dm
at
groups,
dot
io!
J
We
are
continuing
to
refine
the
convergence
process
working
toward
how
we
create
evolvable
designs
and
so
we're
recognizing
we're,
probably
not
just
going
to
be
adopting
existing
designs,
but
rather
adopting
sort
of
refinements
of
those
designs.
And
then
what
are
the
best
practices
around
that
to
arrive
at
at
those
results?
J
Really
great
development.
In
my
opinion,
we've
created
bespoke
repositories.
What
I
mean
by
that
is
that
as
an
organization
or
model
developer,
you
can
come
in
and
create
a
1dm
repo
that
uses
the
ci
tools
but
doesn't
have
a
convergence
requirement
upfront.
So
so
only
if
you
satisfy
the
ci
requirements,
you
can,
you
can
basically
publish
models
on
one
dm
in
your
own
name
space.
So
we
have
these
table
name
spaces
and
that's
kind
of
the
idea
is
that
from
there
we
can
build
interworking
and
incremental
convergence.
J
Much
in
the
way
that
we've
seen
with
one
oma
and
ocf
so
far-
and
these
are
you
know,
can
be-
will
be
public-facing
models
with
common
ci
tools,
but
the
the
content
governance
is
loosely
coupled
you
could
sort
of
have
your
own
way
of
deciding
what
how
models
get
get
incremented
and
versioned
until
you
start
contributing
to
them
to
the
adopted
models.
J
So
if
you
want
to
figure
out
what
that
means
a
little
bit
more
come
to
our
meetings
and
join
up
we're
adding
more
models
from
bluetooth
mesh,
and
it
makes
it
easier
to
do
this-
we're
starting
with
the
models
they've
already
published
and
already
using
across
the
bluetooth
range.
So
that
would
be
the
characteristics
and
the
data
types
that
they've
already
defined
and
we're
going
to
publish
sdf
models
for
those
and
then
move
up
the
stack.
J
If
you
will,
as
we
get
composable
models
toward
the
bluetooth
mesh
and
those
will
be
good
examples
of
composable
models,
because
there's
some
depth
of
feature
that
that
we
have
there
to
work
with
so
we're
working
on
how
we
compose
models
internally
and
reuse,
definitions,
semantically,
that's
an
important
thing
for
interoperability
and
extending
our
models
with
linking
and
composing
complex
objects.
And
this
sort
of
thing.
J
Also,
one
of
our
main
goals
is
to
do
an
sdf
pressure
test
and
what
I
guess,
we've
concluded
as
we're
ready
to
sort
of
go
to
the
next
step
with
sdf
that
it's
working
as
it's
designed
for
the
object
granularity
we
originally
intended.
J
But
of
course
now
we've
got
an
expanded
use
case
where
we
need
to
do
some.
Some
of
this
internal
modularity,
as
well
as
complex
objects
and
composed
objects
and
they're-
probably
some
more
features
there.
But
we
we
think
that
even
sdf
as
it
is.
We
have
an
extension
point
that
we
can
use
to
exercise
new
features
that
that
will
probably
work
pretty
well
so,
but
we're
working
on
coming
up
with
some
examples,
so
validate
all
of
that,
but
that
you
know
the
things
we
talked
about.
J
The
internal
modularity
extension
points
for
mapping
to
different
things
that
so-called
mapping
files
complex
compositions
and
we
find
that
you
know
working
with
other
frameworks,
is
sort
of
like
complex
composition
in
terms
of
their
there's.
Some
loosely
coupled
models
for
building
up
structure
and
system
structure
that
are
non-hierarchical
that
we
need
to
think
about.
So
that's
kind
of
a
summary
of
where
we
are
with
one
dm.
The
high
level
points.
J
One
thing
to
point
out
that
this
bespoke
repositories,
we
already
have
the
1dm
and
ocf
separate
repository,
so
that
model
is
deployed
and
we're
we're
basically
looking
for
more
people
now
to
be
able
to
come
in
and
more
orgs
to
be
able
to
come
in
and
build
those.
So,
for
example,
if
we
could
re-engage
with
well
what
we're
going
to
do
with
bluetooth,
for
example.
J
But
then
a
couple
of
our
earlier
interested
parties
like
sunspec,
have
gone
off
and
created
a
bunch
of
modbus
register
definitions
that
can
be
turned
into
one
data
model
models
now
as
well.
J
Okay-
and
the
last
thing
I
wanted
to
just
sort
of
summarize-
people
might
be
wondering,
what's
going
on
with
iot
schema,
we
haven't
had
a
meeting
since
last
august,
basically
just
to
refresh
everybody's
memory,
we
were
building
an
rdf
framework.
We
are
building
and
really
built
it
for
this
event,
action
property
meta
model
to
come
up
with
definitions,
so
it's
essentially
what
1dm
and
sdf
does,
but
we
were
using
rdf
there
and
there
are
a
there's,
a
good
set
of
definitions.
J
There
we've
been
playing
with
those
with
w3c
and
the
linkage
using
what
we
call
semantic
annotation
to
say
that
oh,
this
data
set
here
corresponds
to
the
control
of
a
light
switch,
and
then
we
can
sort
of
link
that
back
semantically
to
the
to
the
iot
schema
definition
of
a
light
switch
and
describe
its
affordances
connected
to
that
semantic
definition
of
that
sort
of
is
meant
to
cover
all
light
switches.
That's
kind
of
the
idea
of
iot
schema,
so
we're
compatible
with
w3c.
It's
been
used
in
plug
fest.
J
It
seems
like
a
good
pattern,
but
but
we
really
didn't
get
the
engagement
of
people
to
create
models.
So
that's
that's
kind
of
happening
more
in
1dm,
so
we're
looking
at
maybe
what
repurposing
iot
schema
and
using
it
to
be
an
rdf
interface
to
extend
the
modeling
to
physical
domains.
But
we
really
don't
have
much
participation,
the
we
have
a
w3c
community
group,
but
it's
been
dormant
for
some
time
and
there's
a
problem
as
I'm
not
in
the
org
I
was
in
so
I
can't
be
the
chair
of
it.
J
We're
not
really
extending
schema.org
anymore
either.
So
I
don't
really
have
a
forward
direction
for
for
this,
but
just
just
to
get
everyone
up
to
speed
that
we're
we're
not
really
active
right
now,
and
but
there
are
some
proposals
to
to
use
the
the
name
in
the
space
to
to
fill
some
other
gaps
in
the
industry.
It's
just
no
one
really
working
on
that
right
now.
So
that's
that's
really.
All
I
have
I'm
not
sure
about
the
timing
and
probably
time
for
some
questions,
but
mainly
mainly
wanted
to.
J
Can
I
bring
up
the
stuff
that
we're
doing
in
one
data
model
going
forward,
questions
comments,
audi,
has
hand
up
yeah
and
also
please
fill
in
any
gaps
with
things
that
I
have
failed
to
explain.
Great.
B
Great,
thank
you
michael
yeah.
I
was
thinking
of
commenting,
perhaps
saying
I
was
asking
for
the
previous
presenters
like
the
best
ways
to
get
engaged.
I
guess
like
for
the
1dm
work.
I
mean
talking
about
model
conversions,
how
we
get
to
commons,
common
semantics,
etc.
A
1dm
license
group
is
an
open
group,
so
just
joining
the
mailing
list.
B
20
meetings-
I
guess
that's
the
best
way
forward
and
then,
if
you
are
more
interested
on
the
let's
say
the
standardization
aspects,
the
sdf,
the
language,
standardization
is
happening
in
the
asdf
working
group
and
then
for
the
more
researching
topics
in
the
wishing
meetings
we
have
been
discussing.
Many
many
topics
are
related
to
1dm
and
sdf.
B
Okay,
we're
actually
quite
okay
on
on
time
here
at
thanks
a
lot
for
the
update,
michael
and
let's
continue
the
discussions
in
those
aforementioned
venues
and
then
go
ahead.
Karsten
with
the
sworn
tina
teaser.
A
A
We
did
some
research
for
for
a
manufacturer
of
iot
devices
where
they
wanted
to
put
these
iot
devices
on
the
internet,
but
somehow
needed
to
protect
them
from
unwanted
traffic
on
the
internet,
because
that
unwanted
traffic
would
drain
their
battery.
A
So,
in
particular,
the
wake
on
radio
scheme
that
these
devices
were
using
that
needed
to
be
very
tightly
controlled
and
we
came
up
with
something
we
called
swan
secure,
awaken
radio
nudging,
which
is
essentially
the
yellow
part
in
in
the
picture
where
we
have
a
client
that
wants
to
talk
to
the
device-
and
we
have
a
last
hop
router.
A
So
imagine
that
the
left
arrow
is
much
longer
than
the
right
arrow
and
the
last
half
router
is
essentially
the
device's
friend
in
the
network
or
if
you're
not
familiar
with
that
terminology,
you
could
call
it
a
policy
enforcement
point
and
that
router
only
lets
packets
through
that
the
device
really
wants-
and
this,
of
course
works
by
by
the
device
sending
out
grants
and
the
client
can
use
this
ground
to
generate
a
token
and
the
token
is
checked
by
by
the
router.
A
We
we
did
this
and
wrote
it
up
in
2017,
but
they
didn't
really
want
to
to
push
this
through
standardization
in
any
way,
because
we
thought
this
was
just
a
scheme
that
was
interesting
to
to
document
now
recently
there
has
been
a
renewed
interest
in
this
and
maybe
in
in
generalizing
the
concept
a
little
bit
and
actually
adding
roles
to
the
model,
and
this
is
the
white
part
of
the
figure
where
we
have
authorization
managers
which
which
look
a
lot
like
the
four
leg,
actual
model
that
was
discussed
in
in
ace.
A
It's
not
exactly
the
same,
but
some
of
the
things
are
similar.
So
basically
the
the
device
no
longer
has
to
do
everything
on
its
own,
like
like
what
was
necessary
and
so
on,
but
can
delegate
some
of
that
to
the
device
authorization,
the
manager
and
the
device.
Authorization
manager
talks
to
a
client
authorization
manager,
which
does
all
the
necessary
work
to
prepare
things.
A
So
grants
can
be
asked
for
by
the
client
and
the
grants
can
be
obtained
right
from
the
client
authorization
manager
and
then
the
the
client
can
compute
a
token,
send
it
over
the
the
path
to
the
router,
which
doesn't
need
to
be
a
last
abroad.
A
In
this
case
anymore,
because
we
are
not
only
talking
about
wake
on
radio
and
then
we
would
have
the
the
router
verify
the
token
again
and
send
the
data
onto
the
device
and
possibly
the
the
token
will
be
sent
with
that,
because
the
the
device
might
be
interested
in
doing
some
of
these
short
checks
themselves.
A
A
And
so
on
can
be
in
in
one
or
two
of
the
authorization
managers
and
the
authorization
manager
can
also
do
the
communication
with
the
routers
on
the
way
and
what
we
are
really
interested
in
right
now
is
two
things:
one
actually
coming
up
with
a
protocol
that
can
be
efficiently
executed
by
the
routers
so
possibly
using
something
that
that
is
done
using
in-network
computing,
something
that
the
coin
research
group
would
be
interested
as
well,
so
that
that's
one
layer
of
the
discussion,
but
this
is
maybe
not
the
interesting
part
for
the
think
to
think
research
group.
A
The
the
interesting
part
for
the
thing
to
think
research
group
is:
did
we
get
the
the
right
model
here?
Do
we
have
the
right
players
so,
for
instance,
is
it
a
reasonable
assumption
that
that
the
client
authorization
manager
actually
talks
to
the
policy
enforcement
point?
Do
we
have
to
do
this
in
the
device
authorization
manager
so
who,
who
actually
has
the
job
of
protecting?
Whom
and
and
what
information
is
exchanged
before
that
can
be
done
and
so
on?
So
I
think
that's
really
the
interesting
part
here.
A
Getting
up
getting
the
right
players
defined.
Getting
up
processes,
security,
workflows
that
can
be
run
to
make
this
happen
and,
of
course,
deriving
crypto
from
that
that
actually
can
be
executed
by
in
network
computing.
So
that's
where
the
two
areas
are
linked,
so
the
simple
approach
of
having
the
client
design
each
packet
obviously
works,
but
we
need
very
fast
routers
to
make
that
happen.
Okay,
so
that
was
just
a
teaser.
I
think
we,
we
should
have
some
more
discussion
about
this
and
we
already
have
had
some
interchanges.
B
Okay-
and
I
guess
the
follow-up
discussions
thinking
research
group
mailing
list-
perhaps
that's
where
the
discussions
would
be
happening
going
forward.
B
Thank
you,
karsten,
and,
and
and
thank
you
everyone,
I
guess
we
know
we're
actually
quite
nicely
on
time,
exactly
one
minute
over
the
of
the
planned
time
for
for
the
wrap-up,
so
yeah,
as
mentioned
in
the
beginning.
This
was
one
of
the
overview,
summary
meetings
that
we
have
for
the
research
group
and
then
for
the
more
leader
discussions.
We
have
a
in
different
forms
sessions
where
working
meetings,
interim
meetings
etc.
So
please
do
join
those
discussions.
B
B
Okay,
but
that
was
everything
we
had
planned
for
today,
any
more
final
questions
from
comments
for
anyone
before
we
wrap
up
for
the
day.
B
Okay,
in
in
that
case,
thank
you,
everyone
for
joining
today,
let's
stay
in
touch
in
in
the
upcoming
meetings
and
for
those
of
you
traveling,
physically
to
itaf113,
good
luck
and
looking
forward
to
seeing
many
of
you
soon
face
to
face.
Unfortunately,
I
will
be
myself
over
there,
but
hopefully
very
soon
again
in
these
ongoing
meetings.