►
From YouTube: IETF108-ASDF-20200728-1100
Description
ASDF meeting session at IETF108
2020/07/28 1100
https://datatracker.ietf.org/meeting/108/proceedings/
B
I
have
to
you
can
probably
change.
C
D
E
D
E
E
Carson
can
you
I
will
kick
you
off
the
video
now,
so
we
get
going.
E
Michael,
if
you
want
to
stay
on
stay
on
with
video,
feel
free
to
do
so
so
well.
Welcome
everybody.
Now
it's
time
for
the
asdf
buff
asdf
standing
for
as
semantic
definition,
format
for
data
and
interaction
of
things
and.
E
Let's
get
going
or
one
in
the
post
so
first
of
all
here
is
the
note
well,
and
this
is
the
short
form
of
the
night
well
for
our
new
and
people
new
to
itf,
there
will
be
long
form
in
the
moment.
The
key
things
are,
you
will
be
go
back,
please
sorry,
so
you
will
be
recorded.
This
will
be
on
youtube
afterwards,
and
this
is
a
public
meeting,
be
nice
and
professional
to
each
other,
and
do
remember
that
the
ipr
guidelines
for
itf
apply.
That
is
a
link.
E
There
is
a
repo
with
some
more
material
and
so
on.
Here
is
the
full
note?
Well,
we
don't
yeah
you
can
go
to
that.
Here
is
a
full
note.
Well,
please
look
at
it
if
you
haven't
looked
at
it
at
some
time.
It
is
important
and
it
governs
our
work
here
and
then
it
will.
It
will
be
in
effect,
during
this
meeting
well
before
we
go
next
slide.
There
is
one
thing
to
mention
here,
as
you
remember,
the
blue
sheets.
They
are
virtual.
E
E
So
the
rules
of
engagement,
here's
a
small
list
of
rules,
so,
first
of
all,
please
try
to
hold
with
questions
until
the
other
representations,
and
we
will
ask
you
to
only
have
clarifying
questions
when
directly
after
the
presentations
and
then
we
will
have
a
full
discussion
session
after
the
presentations
be
polite
and
concise
at
the
mick.
Keep
your
mix
muted,
while
you're
not
talking,
and
do
remember
that
this
is
a
non-working
group
forming
buff.
So
there
is
no.
There
will
be
no
charter
discussion
today.
E
Yes,
so
here
is
the
agenda.
We
will
start
out
with
a
a
brief
introduction
to
one
data
model.
One
dm
and
sdf
give
me
a
second
here,
alan
and
router.
I
will
just
youtube
or
yeah:
that's
what
carsten
will
provide
and
then
there
will
be
the
ecosystems
that
have
been
contributing
to
this
work
in
the
list
there.
E
They
will
say
a
few
words
each
and
explore
or
expand
why
they
are
interested
in
this
work
and
why
they
think
it
should
be
done.
After
that
and
under
the
correlated
clarifying
questions,
there
will
be
a
discussion
session
about
30
minutes
and
here
the
mic
line.
G
E
For
any
kind
of
questions
relating
to
this
topic,
and
as
we
get
towards
the
end
of
this,
they
will
we
call
out
the
questions
to
see
whether
we
should
adopt
this
work,
or
I
shouldn't
say,
adopt
this
work,
whether
what
should
be
the
next
step,
as
this
is
not
to
work
in
group
forming
broth,
we
cannot
adopt
it,
but
we
can
at
least
point
in
the
in
in
the
positive
direction.
What
works
this?
E
What
direction
this
works
should
take
before
we
start
here
so
I'm
nicholas
fidel.
I
will
be
doing
managing
the
queue
and
a
bit
of
the
talking
introductions
as
you've
seen
so
far.
Michael
richardson
is
my
co-chair.
He
will
be
flipping
the
slides
and
doing
some
other
following
jabber
and
so
on,
and
we
have
ahri
and
jaime
as
notetakers
who
are
in
the
kodi
md.
E
So
thank
you
very
much
for
arya
to
aryan
and
jaime
for
doing
that.
With
that,
I
think
we
can
continue
so
now
on
with
the
introduction
to
one
data
mold
kirsten,
please
go
ahead.
The
floor
is
yours.
H
Thank
you,
so
my
my
job
for
the
next
30
minutes
is
to
try
to
explain
what
the
the
problem
is,
that
we
are
trying
to
solve
and
what
the
approach
the
proposed
approach
is.
So,
let's
talk
about
the
problem.
First,
in
iot,
in
the
internet
of
things,
we
have
many
different
devices
and-
and
that's
really
an
overwhelming
number
of
devices
that
that
need
to
be
worked
with
and
different
ecosystems
like
the
home
world
and
the
factory
world
and
the
building
management
world
and
so
on.
H
These
are
developing
standards
for
some
of
these,
and
the
problem
that
we
are
running
into
is
that
the
temperature
sensor
in
ecosystem
a
is
not
the
same
thing
as
a
temperature
sensor
and
ecosystem
b.
So
we
have
lots
of
different
data
models
behind
these
iot
devices
and
there's
really
not
much
point
in
this
diversity.
H
Of
course,
sometimes
ecosystems
have
specific
requirements,
but
in
many
cases
there
really
is
no
point
in
having
two
different
data
models,
with
different
names
for
things
that
are
described
in
a
different
language
and
so
on.
So
the
the
idea
is
to
come
up
with
a
way
to
harmonize
device
data
models.
H
The
the
group
that
did
this
and
that
started
this
in
2018
is
called
one
data
model
which
may
be
a
little
bit
misleading
because
of
course,
there
is
not
one
data
model.
The
intention
is
to
have
one
data
model
per
kind
of
device,
so
in
the
end
there
will
be
hundreds
of
data
models
or
maybe
up
to
a
thousand
or
so,
but
one
data
model
means
at
least
for
one
kind
of
device.
There
will
only
be
one
data
model
next
slide,
so
this
is
not
about
reinventing
the
the
whole
stack.
H
We
certainly
don't
need
another
wire
format.
The
various
ecosystems
by
now
have
decided
how
to
do
their
communication
hands-ons.
So
we
are
not
trying
to
redo
that,
and
this
means
the
data
models
that
we
are
talking
about,
really
are
information
models.
If
you
know
about
this
terminology
from
rfc
three,
four,
four:
four
plus
interaction
models
and
the
action
ones
on
the
internet
side,
of
course,
not
on
the
side
where
the
the
human
user
sees
buttons
or
something
like
that,
but
the
interaction
models.
How
can
I
request
data
from
the
sensor?
H
How
can
I
make
the
sensor?
Send
me
something
when
the
threshold
is
reached
and
so
on
and
so
on.
So
data
and
interaction
models
is
the
the
subject
here
and,
of
course,
different
wire
formats
and
protocol
details
exist,
but
we
think
about
them
as
protocol
bindings
that
can
be
attached
to
the
the
device
data
models
and
tell
you
how
to
actually
talk
to
to
the
thing
in
detail
and,
as
you
can
see
from
this,
the
the
intention
is
not
to
describe
everything
in
all
detail
formally
or
something
like
that.
H
But
to
do
this
at
the
right
level
of
abstraction
and
the
the
point
is
the
right
level
of
abstraction
will
allow
us
to
harmonize
things.
Even
if
the
modbus
people
still
have
their
weird
data
format
over
zero
lines
and
and
everything
we
still
can
describe
the
other
things
at
this
level
of
abstraction
in
a
way
that
allows
into
operation
next
slide.
H
Now
the
question
of
course,
is:
why
do
we
need
an
effort
here?
We
have
so
many
standards
to
choose
from.
Actually
we
don't
really
have
the
standard
we
would
need
here.
So,
for
instance,
cinnamell
provides
an
overall
data
model
and
a
wire
format
for
data
to
and
from
a
device,
but
in
cinema
you
cannot
really
describe
what
the
same
temperature
sensor
is.
H
You
can
send
data
from
a
temperature
sensor
and
then,
if
the
recipient
knows
that
this
is
a
temperature
sensor,
it
will
be
able
to
make
sense
of
it,
but
the
cinema
itself
doesn't
do
this
descriptive.
Part
ctdl
is
actually
a
language
for
defining
data
models,
so
so
that's
already
helpful,
but
1dm
really
is
about
data
and
interaction
models.
So
it's
a
bit
of
a
different
way
of
doing
things,
and
it's
also,
we
also
probably
can
get
by
with
a
language
that
doesn't
have
all
the
functionality
of
the
cdl.
H
W3
thing
descriptions
these
describe
a
single
device,
not
not
a
class
of
devices
like
all
temperature
sensors,
but
a
single
device
down
to
the
level
of
protocol
bindings
and
that's
really
very
useful.
But
again
it's
solving
a
different
problem
and
there
there
are,
of
course,
many
other
activities
that
that
could
be
cited
here
in
the
itf.
Of
course,
we
have
yang,
which
also
is
a
language
for
describing
devices,
but
on
a
very,
very
different
level
of
of
detail.
H
H
So
you
all
know
this:
this
comic,
that's
exactly
what
we
don't
want
to
do,
and
that
also
meant
not
just
technical
issues,
but
also
how
do
you
position
one
game
in
a
way
that
the
the
other
ecosystems
or
the
ecosystems
don't
don't
consider
1dm
as
a
competitor,
but
actually
as
a
good
way
to
to
achieve
interability
with
other
ecosystems?
H
So
next
slide.
The
the
situation
we
want
to
avoid
is
that
everybody
who
deals
in
in
data
from
devices
from
different
ecosystems
has
to
solve
the
the
n
square
problem
and
next
slide.
Obviously
what
what
you
all
want.
What
we
all
want
is
this,
this
thing
in
the
middle
that
everybody
can
translate
two
and
everybody
can
translate
from
so
these
actually
should
be
many
more
squares
and
circuits
and
and
triangles
because
there
are
so
many
different
formats
to
look
at.
There
are
the
ecosystem
models
like
bluetooth,
ocf
omazigby.
H
There
are
other
standards
like
like
w3c
thing
descriptions
already
talked
about,
and,
of
course,
there
are
also
implementation,
specific
models,
so
most
vendors
have
an
in-house
modeling
technique
and
we
need
to
be
able
to
interface
to
those
as
well.
Even
if
we
may
not
be
talking
about
that
in
the
open
very
much
next
slide,
so
1dm
has
had
its
big
coming
out
a
couple
of
weeks
ago.
H
It
was
started
as
a
liaison
process
in
2018.,
so
there
was
a
meeting
in
the
context
of
zigbee
and
I'm
using
the
old
spelling
here,
which
probably
still
was
the
right
one
in
2018.
sorry.
So
there
was
a
meeting
in
the
zigbee
organization
where
they
invited
other
people
to
to
create
an
outlook.
H
So
when
this
started,
it
started
under
an
nda
and
the
intention
was
to
to
pull
everybody
together
and
and
give
them
a
comfortable
environment
to
work
because,
as
the
seos
operate
under
ndas,
they
expect
to
to
do
their
liaisons
under
an
nda
and
that
that
was
what
the
one
data
model
organization
did
for
its
first
year,
but
yeah
at
some
point
to
to
make
this
to
turn
this
into
an
open
process.
One
dm
had
to
come
out
next
slide.
H
So
1dm
decided
that
it
doesn't
want
to
exist
as
an
organization
like
the
atf
did
for
a
long
time
and
ocf
was
one
of
the
of
the
organizations
that
occasionally
helped
when
when
not
existing
was
was
inconvenient,
but
that
meant
that
one
vm
also
is
not
the
place
where
you
can
park
copyrights
and
and
do
legal
agreements
with
and
so
on.
So
after
some
discussion,
it
was
discovered
that
actually
using
open
source
licenses-
and
in
this
case
the
bsd
three
cross
open
source
license,
which
is
one
of
the
permissive
most
permissive
ones.
H
You
can
get
that
this
allows
cooperation
on
common
models
without
jumping
through
all
the
legal
hoops.
So
the
the
complexity
of
interacting
goes
down.
The
the
legal
overhead
goes
down
and
so
on,
so
everyone
keeps
their
trademarks.
Everybody
keeps
their
patents
and
there
is
a
liberal
copyright
license,
and
this
is
the
legal
model
under
which
the
1dm
operates.
Now.
H
That
this
thing
needs
a
work,
so
the
ping
part
is
what
we
will
be
concerned
here
with,
and
the
other
parts
are
things
that
one
dm
will
continue
to
manage,
and
the
third
component
of
that
is
actually
getting
data
models
contributed
that
are
specified
in
sdf
and
right
now
we
have
specimens
from
four
sdos
or
a
couple
hundred
right
now.
A
couple
of
data
models
and
other
sdos
are
senate
development
organizations
are
in
the
pipeline
for
for
also
contributing
some.
So
this
sdf
is
not
a
paper
tiger.
H
People
actually
have
taken
their
their
data
models
in
their
specific
ecosystems
and
looked
at.
How
can
we
convert
this?
Translate
this
into
sdf,
and
some
of
them
actually
also
have
started
to
do
the
other
direction.
Next
slide.
H
So
sdf
really
is
is
the
red
star
of
of
the
the
picture
in
in
three
slides
ago.
It's
really
optimized
for
collaboration,
and
I
think
that
that's
something
that
people
who
do
specification
formats
in
this
space
often
do
not
have
in
mind
as
the
top
priority
and
yeah.
It
avoids
the
the
n
square
problem
and
actually,
we
are
already
seeing
seos
using
sdf
as
their
own
development
format.
So
when
they
do
new
data
models,
they
write
in
an
sdf
first
and
then
they
they
convert
it
to
their
native
tool
chain.
H
So
what?
What
is
this
sdf
sdf
is
a
domain
specific
language.
Obviously,
it's
solving
a
very
specific
problem,
collaboration
on
data
models
and
it's
represented
in
json,
because
that's
the
lowest
threshold
way
we
can
actually
get
interchange
between
the
various
organizations
and
the
various
tools
these
organizations
are
using.
Json
means
we.
H
We
need
a
way
to
actually
define
the
syntax
that
that
is
not
a
b
and
f,
but
something
on
on
the
data
model
level
and
the
syntax
is
currently
defined
both
in
cdl
and
json
schema
org
format
that
there
is
a
converter
from
from
ctdl
to
json
schema.org.
So
we
are
doing
the
actual
specification
of
cddl,
but
also
output,
json
schema
out,
because
that
is
convenient
for
many
people.
H
The
data
models
itself
again.
The
data
modes
are
really
data
models
and
digital.
So
the
actual
data
models,
the
data
shape,
uses
a
format
that
is
inspired
by
json
schema
org,
but
it's
a
curated
super
subset
so
that
not
everything
that
is
in
json
schema
org
is
in
that
language
in
that
sub
language,
and
it's
also
augmented
by
by
some
iot
considerations
that
are
part
of
json
schema
work
and
the
interaction
model
is
based
on
three
types
of
performances.
H
Most
ecosystems
have
something
like
this:
these
three
pillars
here:
properties,
which
are
data
you
can
set
and
get
actions
which
are
things
you
can
ask
a
thing
to
do,
and
events
which
a
thing
reports
back
is
happening,
and
each
of
these
affordances
is
characterized
by
input
and
output
data
models.
Next
slide.
H
So
how?
How
would
we
work
with
that?
We
are
talking
about
the
red
star
here.
Various
organizations
and
and
ecosystems
are
building
the
arrows
that
converge
from
and
to
their
native
formats,
or
should
I
say,
legacy
formats
depends
on
the
ecosystem
and
the
the
main
user
of
sdf
actually
would
be
1dm
for
doing
the
work
on
harmonizing
the
data
models.
H
Obviously,
one
dm
would
have
a
lot
of
people
who
are
interested
in
sdf
and
in
the
end,
will
work
in
this
working
group
as
well,
and
the
other
users
will
be
the
ecosystems
either,
just
as
as
a
target
or
source
of
translation
or
actually,
as
as
the
overall
new
way
in
which
things
are
being
developed
next
slide.
H
I
simply
made
the
same
picture
for
yang
just
just
to
compare
to
one
of
the
the
various
formats
that
the
idf
is
using
yang
is
not
exactly
optimized
for
for
converting
other
formats
into
and
out
of
it,
of
course,
that
kind
of
needed
to
to
handle
the
transition
from
smi
v2,
but
that
that's
a
history
now
mostly
and
so
yang
is,
is
really
the
focus
of
people
who
want
to
define
full-fledged
data
models
that
essentially
imply
the
protocol
bindings
as
well,
and
the
the
main
user
of
of
the
yang
is
the
itf
itself,
because
we
are
using
gang
2d
to
write
our
own
standards.
H
Of
course,
there
are
other
organizations
here
like
vendor
two
and
vendor
two,
don't
know
what
happened
to
vendor
one,
and
these,
of
course
also
work
with
yang
and
sometimes
submit
things
to
the
itf
or
don't
submit
things
to
the
itf,
because
that's
a
product
feature
and
so
on.
So
at
the
from
from
10
000
feet,
it
may
look
similar,
but
when
you
go
into
the
down
into
the
way,
this
is
actually
being
used.
It's
it's
quite
different.
H
I
think
the
the
the
obvious
approach
here
is
to
start
from
what
1dm
already
has
specified
and
pressure
tested,
as
we
are
saying
in
1dm
by
by
actually
converting
data
models
into
and
out
of
it,
but
yeah
the
the
people
who
are
working
with
sdf
know
what
sdf
is
so.
The
specification
in
many
places
isn't
really
something
you
could
send
to
mars
and
and
have
have
some
martian
implemented.
H
So
the
specification
needs
to
be
improved
as
a
as
a
specification,
and
there
are
also
gaps
in
in
the
functionality.
So
there
are
some
forms
of
composition
that
that
we
will
have
to
address
next.
Things
often
are
built
out
of
other
things,
and
we
have
one
form
of
composition,
but
that's
a
caused
grain,
but
we
don't
have
composition
at
the
fine
grain,
so
we
will
have
to
put
that
in
so
that's
gaps
in
functionality.
H
There
is
also
the
question
about
the
stability
of
the
normative
references
so
that
there
are
some
things
being
used
in
sdf
that
are
not
standardized
either
and,
of
course,
you
can
copy
some
of
this
into
the
document
or
work
on
getting
the
normative
reference
standardized
and
so
on.
So
that
that's
another
thing
where,
where
work
needs
to
be
done
and
of
course
it's
also
always
possible
to
question.
H
So
yeah,
I
would
have
to
look
into
the
document,
but
the
the
most
daring
one
is
json
schema,
of
course,
because
that
is
the
source
of
the
pieces
we
are
using
for
defining
the
the
actual
data
data
models
right
now,
but
I
think
there
are
some
other
things
in
there
as
well.
But
I
can't
remember
at
the
moment.
H
So
this
is
a
little
bit
different
from
from
working
on
specs
that
are
offloaded
from
from
some
other
organization,
and
then
you
are
told
rubber
stamped
this
or
the
whole
thing
will
die,
because
1dm
is
actually
working
on
harmonizing
things.
H
H
I
I
have
a
question
about
the
inclusion
of
performance
characteristics
in
the
in
the
description
language
or
in
in
the
in
the
in
the
sdf.
It
might
be
useful
to
understand
what
the
bandwidth
requirements
are
going
to
be,
what
the
response
time
requirements
are
going
to
be
how
often
one's
going
to
communicate.
I
The
reason
for
that
is
that
if
we
have
a
centralized
way
of
gathering
that
information
for
the
various
things
that
are
connected
to
a
central
controller
or
whatever,
we
can
understand
what
the
burden
on
the
central
controller
is
going
to
be
or
how
stringent
the
response
time,
the
interaction
requirements
are
or
whatever,
and
I'm
wondering
if
we
could
include
other
non-functional
requirements
in
there
as
well.
H
Yeah,
I
think
that
that's
an
interesting
idea-
it's
maybe
not
that
easy
to
to
capture
these
non-functional
requirements,
but
if
we
manage
to
do
that,
that
would
certainly
be
something
that
that
would
be
very
useful
in
such
a
data
model
approach.
H
Yes,
but
some
of
these
performance
characteristics
can
only
be
analyzed
in
conjunction
with
protocol
bindings,
so
we
would
have
to
to
get
further
in
the
way
protocol
bindings
attach
themselves
to
sdf
to
actually
make
useful
statements
in
there
fair
enough
yeah.
That's
an
interesting
idea,
and
I
agree.
We
should
examine
that.
H
E
H
And
four
more
slots
valtter.
Do
you
have
a
clarifying
question.
H
Okay,
maybe
we
can
continue
so
next
slide.
H
H
Why
should
we
have
a
standard
at
all
and
the
standard
standard?
I
mean
a
standard
in
the
at
the
quality
level
of
an
itf
specification.
H
1Dm
contributors
need
the
stable
and
well-defined
format
specification,
and
one
vm
itself
needs
a
stable
basis
for
its
model.
Immunization
efforts,
so
this
is
a
good
time
to
to
nail
this
down
and
also
tools.
Implementers
will
benefit
from
having
a
stable,
very
defined
specification.
So
all
this
work
is
starting
or
emerging
from
the
prototype
phase.
H
Why
did
1dm
get
the
idea
that
the
itf
might
be
the
right
place
to
standardize
this
well?
First
of
all,
ietf
has
a
vendor
neutral
process
that
tends
to
result
in
high
quality
specifications.
H
Sdos
are
actually
used
to
to
basically
work
on
itf
specifications,
there's
of
course,
because
no
iot
product
or
ecosystem
out
there
that
doesn't
doesn't
use
some
itf
specifications,
so
they
already
know
what
to
expect
from
the
itf
and
they
trust
the
itf
to
get
the
job
right
and
finally,
iatf
does
have
some
experience
with
the
domain
specific
data
model
I
mentioned
yang,
so
this
this
is
not
a
new
kind
of
work
except
this
time.
H
So
what
would
an
asdf
working
group
do?
It
would
focus
on
the
sdf
specification?
That
would
be
it's.
It's
only
deliverable
unless
there
is
agreement
at
some
point
that
we
actually
need
to
to
do
something
like
like
the
json
path
thing.
H
I
don't
know
if
you
were
in
the
dispatch
meeting
yesterday,
so
sdf
doesn't
need
json
path,
so
this
is
just
an
example
we
get
by
with
jason
poynter,
but
if,
if
there
are
small
pieces
that
that
actually
need
to
be
done
to
get
normative,
completeness
yeah
that
that
might
come
up
at
some
point.
But
right
now
I
think
the
only
delivery
we
will
really
have
to
make
is
the
sdf
specification
and
yeah
the
normative
dependencies.
H
We
either
ensure
that
they
are
stable
or
we
customize
them
for
inclusion
in
the
sdf
specification
and
the
the
work
group
would
work
with
one
dm,
of
course,
with
iot
data
model
sdos.
We
will
hear
from
them
in
a
couple
of
minutes
and
with
iot
vendors
and
the
deliverable
is
the
sdf
format
specification.
E
E
I
saw
a
question
in
yeah
yeah.
J
Ron
cohen,
it
was
my
question
which
was
given
the
timeline
where's,
given
the
timeline
that
you're
saying
it's
within
months
that
doesn't
seem
very
compatible
with
not
forming
a
working
group
kind
of
now.
If
we
need
to
be
able
to
to
do
whatever
edits
happen
within
months,
is
there
a
time
frame
on
this
and
what
is
that
time
frame.
H
Well,
there
is
not
something
like
the
january
ces
we
have
to
make
an
announcement
for,
but
yeah
getting
this
started
within
months
would
be
useful
and
I
think
getting
it
getting
a
stable,
sdf,
1.1
or
2.0.
However,
we
want
to
call
it
call
it
out
of
the
working
group
by
the
end
of
next
year
would
also
be
very,
very
important.
J
K
K
As
you
know,
if
we,
if
ietf
say,
for
example,
was
to
make
changes
and
to
make
sure
that
that
those
things
stay
that
the
translations
stay
valid,
how
do
you
see
that
work
happening.
H
So,
first
of
all,
I
think
it's
the
the
job
of
one
dm
to
to
actually
get
this
harmonization
process
defined
and
right
now
we're
actually
discussing
a
document
about
how
this
this
process
works
or
should
work
in
in
detail.
H
So
some
of
the
questions
will
be
answered
from
that
one
vm
process
document,
but
in
general
I
think
the
the
actual
tools
will
be
written
by
by
the
ecosystems
and
and
realistically
by
the
vendors
within
the
ecosystems,
and
we
need
to
to
keep
up
a
relationship
with
these,
preferably
the
people
who
do
these
tools
also
interface
with
the
working
group,
and
they
will
be
an
important
voice
in
what
changes
can
be
made
and
what
changes?
What
would
require
artificial
intelligence
in
in
the
tools
or
something
like
that?
G
K
E
Okay,
thank
you
very
much.
I
think
we
are
unless
there
are
more
clarifying
quick,
clarifying
questions
we're
out
of
time
for
the
first
part
here.
So,
let's
move
on
to
the
second
part,
and
here
I
would
like
to
call
up
to
the
myq,
the
supporting
organizations,
so
michael
koster,
simon
walter,
alan
aria,
please
get
put
yourself
in
the
queue,
so
we
can
easily
find
you.
E
F
F
We
identified
this
need
and
it
so
me,
and-
and
some
of
these
other
participants
have
been
trying
to
marshal
this
effort
to
the
point
where
we
actually
make
the
impact
that
we're
hoping
to
so
from
an
oma
perspective,
there
are
two
working
groups:
the
data,
the
device,
management
and
service
enablement
along
with
the
ipsmart
objects,
which
is
a
separate
organization
that
was
merged
into
oma.
F
I
don't
know
a
little
over
a
year
ago,
so
next
slide.
Please,
I
see
what
we
did
from
the
lma
side
is
we
we
tried
to
make
sure
that
we
coordinated
well
out
throughout
the
process
here
in
one
end,
one
1dm
and
on
the
oma
side,
and
if
you
look
at
some
of
the
names
on
this
contact
list,
hannes
chofinig
is
familiar
to.
I
think
everybody
that's
ever
worked
in
some
of
these
areas.
F
You've
got
travis
shanahan
from
itron
bahudurdanes
from
nokia,
scott
potter
from
cisco,
and
I
think
some
of
you
may
know
behind
me
as
well
joe
concerted.
So
the
the
just
the
overall
scope
here
is
that
we
believe
in
this.
From
an
oma
perspective,
we've
been
working
from
this
from
an
oms
perspective.
F
Very
beginning,
and
so
we're
trying
to
actively
I'm,
I
don't
want
to
say
adopt,
because
that
might
be
too
strong
a
word
but
make
sure
that
the
1dm
models
become
a
source
of
truth,
and
that,
essentially,
is
the
big
issue
here
all
right.
Next,
please.
F
So
if
you
just
look
at
this,
obviously
we
we
acknowledge
the
value
here.
Not
only
do
we
acknowledge
it,
we
want
to
enhance
it
endorse.
It
evolve
it
and
continue
to
to
really
make
this
real
and
that's
the
key
to
having
ietf
adopt
it
is
to
make
it
real
all
right.
The
bsd
three
clause
license
was
also
very
important.
F
That
was
a
decision
that
was
debated
and
the
bsd3
clause
is
the
most
let's
say
easily
adopted
of
the
open
source
licenses
across
the
different
organizations,
and
that
was
key
is
is
adoption
all
right?
Next,
please
am
I
done
now.
I
I
would
like
to
say
that
I
did
this,
but
that
would
be
stealing
from
ari,
because
I
already
just
this
is
I
love
this
tool
and
what
it
is
is
a
very
active
you
copy,
an
sdf
on
the
left.
You
convert
a
lightweight
m
on
the
right.
F
You
can
cut
and
paste
into
lightweight
m
m
on
the
right,
convert
it
to
sdf
on
the
left.
It's
active
it's
real
time
and
it's
what's
the
word.
I
want
to
use
it
it.
It
maintains
fidelity
across
the
two
models,
and
that
was
our
biggest,
I
would
say
our
biggest
bonus
was
just
maintain
that
fidelity,
and
this
was
a
great
tool.
So
thank
you
again
aria
on
this
one
all
right,
I
think
that's
it
for
me.
Thank.
F
L
L
So
I'm
going
to
appear
twice
here,
but
first
from
the
point
of
view
of
zigbee
alliance.
L
L
Yeah,
so
I'm
going
to
represent
our
use
cases
in
zigbee.
Why
we're
interested
in
one
data
model
and
and
sort
of?
I
think
that
the
impetus
has
already
been
explained.
It
did
come
from
the
zigbee
and
across
cross
ecosystem
industry-wide
effort
back
about
a
year
and
a
half
ago.
So
we
really
want
to
provide
a
more
tool-friendly
entry
point
for
developers
currently
using
xml
and.
G
D
Yeah
we
did,
we
lost
michael's
audio.
Why
we
go
ahead
with
rooter,
then
okay,
can
you
hear
me.
A
Yeah,
okay,
so
I'm
the
technical
steering
committee
coordination
steering
committee,
chair
of
the
open
connectivity
foundation
and
we
were
involved
in
1dm
from
the
beginning
and
all
the
things
that
happened
before
we
went
public
were
done
on
the
ocf
ndas,
so
that
gave
us
all
the
freedom
to
discuss
under
nda
without
issues
that
we
could
reach
this
result.
A
One
of
the
things
that
we
like
to
say
is
that
ocf
has
adopted
the
bsd3
clause
license.
So
we
changed
our
internal
working
with
data
models
to
contribute
to
this
effort,
and
also
one
of
the
things
that
we
did
is
create
conversion
models
between
ocf
used
models
and
sdf.
A
Vice
versa,
it
is
not
as
sleek
as
what
a
lightweight
m2m
did
with
a
nice
ui,
but
it's
just
a
python
tooling,
but
it
works
perfectly
fine
as
well.
So
that's
the
reason
why
we
definitely
think
that
sdf
is
a
way
forward
to
get
out
of
the
the
only
view
on
yourself
issue
with
all
these
technologies.
A
All
the
organizations
that
we
have
talked
to
right
now-
and
this
is
one
of
the
things
that
we
really
like
to
use,
going
forward
to
open
up
and
get
rid
of
silos
and
because
the
interoperability
starts
with
data
models.
If
you
don't
understand
data
models,
then
all
the
communication
that
you
have
been
established
before
is
not
not
that
useful.
A
A
N
Hi
good
morning,
good
afternoon,
good
evening,
I'm
representing
bluetooth
here
so
I'm
simon
slupik,
chairing
the
mesh
working
group
at
pluto's,
sig
and
also
representing
one
of
the
bluetooth
member
companies.
N
We
very
much
believe
in
interoperability,
and
actually
interoperability
has
been
the
cornerstone
for
bluetooth
for
the
last
20
plus
years.
So
bluetooth
is,
is
really
the
synonym
of
interoperability
and
when
looking
at
the
iot
space
now,
especially
smart
buildings,
this
is
our
one
of
our
focus
areas.
N
Protocol
wire
formats
or
wireless
formats
are
secondary
and
can
be
derived
agreements
on
models
and
even
before
the
agreements
on
model
description,
language
is
is
paramount.
Therefore,
we
we
very
strongly
endorse
this,
this
effort
and
and
are
very
happy
to
be
part
of
that.
N
E
L
Great,
I
thought
it
was
being
heard
before,
because
the
little
audio
bar
chart
was
moving
the
little
spectrum
chart
anyway.
So,
as
I
work
for
smart
things,
that's
sort
of
that's
our
vendor.
We
have
a
you
know,
iot
platform
that
serves
quite
a
few
people,
and
my
role
at
smartthings
is
mostly
iot
industry
standards,
and
I
also
work
on
the
smart
things
capability
model,
which
is
our
internal.
L
L
So
we
really
see
a
lot
of
uses
for
one
dm
and
seeing
coming
to
the
platform
in
a
number
of
different
places.
The
first
first
is
sort
of
the
device
integration
where
we're
going
to
be
able
to
get
sdf
files
for
the
different
devices
that
we
integrate
and
that's
going
to
make
it
really
easy
to
automate
integrating
those
devices
into
the
platform,
and
sometimes
we
need
to
generate
code
or
generate
device
drivers,
and
it's
going
to
make
that
quite
a
bit
easier.
L
And
even
if
we
don't
get
sdf,
we
can
easily
create
the
sdf
for
a
device
based
on
whatever
its
native
data
model
is
and
integrate.
That
way,
and
this
already
makes
it
easier
to
do
that
internally,
we
have
a
capability
model
already.
That
looks
quite
a
bit
like
sdf
in
terms
of
a
meta
model,
and
we
could
replace
that
with
with
sdf
we're
moving
to
a
more
service-oriented
management
of
that
data
model.
L
As
we
integrate
more
and
more
devices
and
more
custom
devices
with
custom
capabilities,
we're
seeing
a
lot
more
people
get
involved
in
defining
and
using
the
data
models.
Developers
that
aren't
really
data
model
experts,
but
need
to
do
this
as
part
of
their
job.
So
sdf
is
something
that's
going
to,
as
I
mentioned,
with
the
zigbee
provide
a
tool-friendly
developer
entry
point
that
they
can
use
and
as
a
standard
people
will
already
know
it.
L
L
And
then
we
have
third-party
apis
that
we
integrate
and
currently
have
a
few
different
protocols
that
we
can
do
that
through
including
mqtt
and
rest
protocol
and
a
more
event
sort
of
cloud
to
cloud
event
stream
type
protocol,
and
we
can
use
swagger
and-
and
things
like
that,
but
we
need
also
the
semantic
integration.
So
sdf
is
going
to
be
a
way
for
us
to
integrate
those
those
third-party
apis
semantically.
As
well-
and
that's
really,
all
I
wanted
to
talk
about
was
mainly
our
use
cases.
E
Thank
you
very
much.
Do
you
want
to
save
just
a
million
times
much
time,
but
the
the
zigbee
was
the
more
on
the
secret
slide.
L
Yeah,
well,
you
could
go
back
to
that
and
I'll
talk
to
a
little
bit
that
basically
we're
already
sort
of
down
the
road
with
this
in
zigbee,
but
we're
using
xml,
and
we
see
sdf
as
a
more
developer,
friendly
way
of
of
doing
that,
as
well
as
within
our
own
organization.
In
zigbee.
We
have
now
chip
and
zigbee
pro
and
the
jupiter
mesh
protocol,
and
we
want
to
use
the
same
models
across
all
of
those,
but
they
have
different
code
generators.
L
So
we're
planning
on
maybe
using
xml
as
more
of
an
assembly
language
and
using
sdf.
E
Michael,
we
lost
you
again,
I'm
afraid.
Okay,
mile
michael
koster
tries
to
reconnect
ari.
M
Sure
I'll
be
giving
a
short
short
overview
from
eric
some
point
of
view,
so
maybe
go
for
the
next
slide.
Please
can
you
hear
me
yeah
go
ahead.
Thank
you.
So,
of
course,
also
at
ericsson.
We
believe
strongly
in
the
interoperability
as
a
key
driver
for
value
in
iot,
and
we
see
a
lot
of
potential
in
different
aspects
that
all
the
previous
speakers
already
highlighted,
but
in
particular
we
see
an
sdf,
valuable
tool
for
reducing
integration
cost
when
it
comes
to
iot
platforms.
M
E
Thank
you
very
much
ari,
so
my
michael
koster
did
you
have
anything
else
on
your
slide
that
you
wanted
to
say,
or
I
think
you
we
are
pretty
much
at
the
clarifying
questions
point
otherwise.
E
Okay,
thank
you
very
much.
So
are
there
any
clarifying
questions
to
the
to
the
previous
presentations
here?
All
the
ecosystem
input.
E
Okay,
great,
if
not,
then
we
are
moving
on
to
the
to
the
the
key
session.
Are
we
actually
on
time
here?
That's
good.
We
will
have
a
discussion
now
on
what
to
do
with
this,
and
after
that
we
have
a
couple
of
sort
of
calling
the
questions.
But
since
this
is
not
the
working
group
for
the
graph,
we
will
sort
of
try
to
decide
on
what
to
do
next,
and
here
are
roughly
the
id
the
questions
that
we
will
try
to
ask.
E
E
E
B
Now,
okay,
that's
really
interesting!
The
icon
show
me
is
having
no
audio
now,
but
now
can
you
hear
me.
I
can
hear
you
a
lot
of
claire.
Thank
you,
okay.
So
this
really
question
about
change
control
and
how
done
this
is
so
I've
heard
some
comments
about
sdf
that,
like
wow
it'd
be
nice
if
it
had
a
much
more
an
extensibility
model
where
you
could
say,
I
have
an
object.
That's
much
like
some
other
object,
but
it
doesn't
end.
B
So
how
much
are
we
open
to
to
significant,
not
not
small
fixing
up
changes
but
significant
re-change
of
sdf,
or
do
people
want
to
keep
it
largely
as
it
is?
I
mean
one
of
the
things
I
think
I
like
about
it
is,
it
seems
fairly
functional
as
it
is
so,
what's
the
view
on
basically
change
control
and
and
how?
How
is
this
a
starting
point,
or
is
this
a
close
to
done
point,
I
guess,
is
what
I'm
trying
to
get
at.
H
In
my
presentation
that
this
is
actually
an
unusually
specification
that
is
unusually
open
to
significant
changes
because
of
the
way
that
this
is
not
a
format
that
people
actually
directly
write
in,
they
do
that
now
and
then,
but
really
that
they
build
tools
for
to
translate
into
and
and
auto.
So
it
is
relatively
easy
to
make
a
sweeping
change,
and
we,
we
did
a
number
of
sweeping
changes
in
in
the
weeks
that
that
led
up
to
1.0
and
it
was
a
pretty
painless
situation.
So
it's
never
without
cost.
H
E
So
I
don't
see
anybody
in
the
queue
please
enter
the
queue
by
taking.
E
F
Colin
as
well
yeah
colin,
I
think
the
answer
is
actually
both.
It's
a
it's
a
well-established
floor
of
where
we
start
to
do
evolution,
but
evolution
is
always
beneficial
in
the
sense
that
when,
if
there
are
more
use
cases
we
need
to
address,
we
can
do
that.
So
I
think
it's
both
we
have
a
great
foundation
but
yeah.
We
need
to
continue
to
evolve.
B
E
A
I
can
add
that
why
we
went
public
is
that
we
now
have
a
working
situation
which
fits
multiple
ecosystems
already,
and
there
are
already
I'm
not
saying
issues
enhancements
and
needed
to
do
this,
but
at
some
time
you
have
to
draw
a
line
in
what
is
sufficient
to
get
started.
And-
and
this
is,
I
think,
a
very
reasonable
set
of
constructs-
that
we
reason
that
we
can
use
already.
A
Is
this
enough?
No,
but
this
kind
of
work
will
probably
never
stop,
because
there
is
always
something
new
on
the
horizon.
That
needs
where
you
need
to
be
adapting
to.
E
E
I
Okay,
I've
worked
for
a
long
time
on
performance
questions
and
I've
found
that
performance
is
very
often
an
afterthought.
I
So
I'm
wondering
if
it's
a
good
opportunity
now
to
try
and
embed
performance
characteristics
into
this
definition
format
so
that
things
can
be
captured
early
on.
It
may
be
that
some
of
the
devices
that
you're
monitoring
or
controlling
need
to
be
spoken
to
within
a
certain
amount
of
time
or
have
domain
specific
performance
requirements.
I
That
need
to
be
understood,
and
it
seems
to
me
that
this
might
be
a
good
place
to
capture
that
early
in
the
game,
so
that
you
can
at
least
draw
attention
to
the
need
to
think
about
performance
issues
so
that
when
you
knit.
I
Together,
you're
not
suddenly
stuck
with
capacity
or
unresponsive
unresponsiveness,
it
undermines
functionality.
I
And
it
seems
that
one
could
come
up
with
a
taxonomy
of
performance,
characteristics
and
requirements
that
could
be
taken
into
account
and
captured
in
this
kind
of
a
framework.
E
I
think
kirsten
addressed
some
part
of
this
before
and
it's
perhaps
not
right
now,
at
least
what
is
what
was
intended
with
the
group,
but
I
guess
it
could
easily
be.
I
mean
I
could
see
it
as
an
extension
karsten
or
someone
else
would
have
additional
comments
to
that.
I
H
E
Thank
you,
so
we
do
have
an
empty
queue.
I
hope
that
means
that
everybody
is
happy
with
this.
So
unless
any
final
thoughts
about
this,
I
think
we
should
there
is
no
need
to
linger
here
and
try
to
move
on,
and
so
actually
we,
the
idea
with
this
buff.
It
was
also
asked
in
the
in
the
in
the
jabber
room,
that
why
is
this
both?
E
Not
the
working
group
forming
buff
and
the
reason
was
that
there
was
a
wish
to
see
more
sort
of
industry
support
for
this
beforehand,
and
that
is
why
we
had
lined
up
all
the
industry
folks
on
this
buff,
and
so,
but
as
you
can
see,
this
work
has
been
progressing
and
is
it's
reasonably
mature,
as
is
with,
of
course,
the
caveat
that
it
would
be
taken
over
by
itf
the
particular
sdf
specification
work
and
the
resulting
specifications.
E
C
E
I
think
there
are,
there
are
different
ways
to
to
formulate
this.
There
is,
as
far
as
I
can
tell
no
disagreement
about
this
work
being
useful
and
so
on.
E
So
the
big
key
question
is
and
also
came
out
of
the
initials.
The
both
request
is:
is
this:
the
right
is
itf
the
place
to
do
this
so.
E
So
maybe
we
might
want
to
do
a
ham
afterwards,
but
since
there's
the
humming
seems
to
be
a
bit
controversial
this
time.
Let's
just
walk
through
this
and
see
if
you,
if
you
have
disagreements
or
disagree
with
this,
please
ask
for
objections,
basically
and
and
then
we
can
so
I
will
just
move
through
these
questions
and
please
ask
for
objections.
E
If
you
don't,
if
you
don't
agree
so,
first
of
all
the
next
stage
from
this
after
this
buff,
if
everybody
is
okay
or
there,
if
there
is
rough,
consensus,
will
be
to
draw
draw
up
a
charter
and
have
that
discussed
on
the
mailing
list
so
and
the
charter
to
reasonably
cover
what
was
covered
in
the
presentations
here
today.
E
Then
the
question
is:
do
we
have
energy
for
this?
It
seems
to
me
that
the
which
I
say,
the
the
the
external,
the
user
industries,
at
least
they
have
energy
for
this
they've
expressed
strong,
strong
support
for
this,
and
both
anecdotal
and
and
real.
But
also
the
question
is,
of
course,
is
there
enough
ietfers
who
would
like
to
to
do
work
on
this
and
as
you've
seen
in
the
there
is
a
bunch
of
highly
engaged
ietfers
in
id
space
already
involved
with
this
work.
E
C
E
Okay,
let's
do
as
barry
said,
if
you
would
like
to
be
engaged
with
this,
I
will.
I
will
now
try
out
this
hum
tool
and
the
first
question
will
be
if
this
work
starts.
E
Would
you
let's
see
here
if
you
will
participate
in
this
work,
please
hum
now
when
I
will
start
the
timer.
E
Yeah
then
I
guess
with
this
size
of
community,
I
don't
think
we
need
to
have
a
should
we
anybody
do
I'm
new
to
this
sort
of
running
boat,
but
it's
kind
of
both.
So
please
bear
with
me
here:
do
you
want
to
have
a
a
negative
question
as.
E
Great
then
we
will
have
the
next
question
and
that
would
be
the
is
ittf
the
right
place
right.
E
Give
me
a
second
here
to
pick
up
the
should
should,
should
I
atf
do
this,
so
I
hope
everybody
has
found
the
home
button
and
I
will
start
out
with
a
with
a
with
a.
C
Right
more
to
the
point
you
eat,
schooler
asks
a
question
in
the
daba
room
of.
Can
we
have
a
discussion
about
where
else
it
would
get
done?
If
not
here,
and
I
think
that's
more
useful
than
having
a
hum
about
whether
it
should
get
done
here,
because
I
think
we
already
have
people
saying
they
want
to
work
on
it
here.
Let's
talk
about
what
the
alternatives
would
be.
E
Yeah,
so,
okay:
let's,
let's
wait
with
a
put
eventual
hum
for
that
and
move
back
to
the
main
queue
then,
and
so
obviously,
the
the
one
dm
folks
have
think
that
sdf
as
carson
stated
and
the
other
state
that
I
think
that
itf
would
be
the
right
place,
and
I
mean
that
I
assume
comes
from
internal
discussions
about
what
would
be
the
right
place.
E
So
I
mean
I
think,
if,
if
we
want
to
tell
the
sdf
folks
to
go
elsewhere,
we
should
also
object
to
this.
There
needs
to
be
some
objection
why
it
shouldn't
be
done
on
itf
right.
So
if
you
have
thoughts
about
this,
please
get
on
the
mic
line
and
sort
of.
E
A
E
So
I
don't,
I
don't
really
hear
any
anyone
coming
to
the
mic.
Don't
see
anyone
coming
to
the
mic
line
and
I
don't
see
any
further
points
in
the
in
the
chat
so.
E
With
that,
I
think
I
mean
it's
it's,
it
still
needs
to
have
a
working
charter,
and
the
charter
must
be
approved
by
by
the
right
folks
and
so
on.
E
But
as
I
see
it,
there
is
no
really
any
enthusiasm
to
discuss
any
other
alternative
places
to
do
this.
Work
colin,
you
want
to
say
anything
or.
B
C
C
This
came
from
the
buff
approval
call
in
the
iesg
and
iab
cullen
which
you
you
were
part
of.
C
Perhaps
you
remember
there
were
there
were
some
concerns
about
the
industry
pick
up
on
this,
and
you
know
whether
this
was
a
just
a
few
people
interested
or
whether
there
was
broad
interest,
and
so
we
approved
it
as
a
non-working
group
forming
buff.
With
that
in
mind,
so
we
can,
you
know
the
the.
It
sounds
to
me
that
it's
pretty
clear
that
the
next
plan
is
to
get
the
charter
out
on
the
mailing
list
and
finalize
it
and
send
it
to
me.
B
P
Yeah,
do
I
have
yes,
I
do
have
audio
good.
I
was
just
wondering
it
sounds
like
you've
got
a
charter
in
your
back
pocket
waiting
to
be
worked
on.
Is
there
anything
controversial
about
that
charter?
We
are
early
in
the
day.
Is
it
okay
to
talk
about
whether
there
are
particular
issues
that
we
should
be
thinking
about
that
you
all
need
input
on
for
for
that
charter
right
now,.
P
Mean
look,
you
don't
have
to
show
the
actual
charter
and
we
don't
have
to
go
through
it
piece
by
piece.
I'm
just
thinking.
If
there's
anything,
that
is
that
you
feel
like
is
currently
something
that
you
were
thinking,
I'm
going
to
need
group.
You
know
input
into
this
particular
part
that
might
be
useful
to
discuss
now
going
through
it
line
by
line.
I
don't
think,
is
going
to
be
a
productive
use
of
time,
because
no
one's
had
a
chance
to
look
at
it
previously.
H
E
H
Yeah,
I
think
you
can
scroll
down
from
the
background.
I
think
we
covered
the
background
here.
So
just
the
three
paragraphs
about
asdf-
and
I
think
the
the
interesting
thing
about
sdf-
is
that
it's
a
bit
of
a
stew
of
different
technologies
and
handling
this
stew
is,
is
maybe
something
that
we
haven't
done
as
much
and
and
the
the
inputs
come
from
various
places
and
some
of
them
can
be
handled
separately.
H
So,
for
instance,
we
had
this
json
path
thing
yesterday,
where
we
don't
know
whether
we
will
need
it
or
not.
We
will
need
it
on
the
discovery
side,
but
we
don't
necessarily
need
it
in
sdf
itself.
H
So
there
are
things
like:
how
do
we
actually
do
the
the
data
modeling
part?
How
do
we
do
the
attachment
modeling
part?
What
what
parts
do
we
import?
I
would
hope
that
we
actually
can
handle
all
these
questions
in
the
working
group.
H
So
sometimes
the
isg
wants
decisions
to
be
made
before
the
working
group
is
formed,
so
the
working
group
doesn't
get
itself
blocked
by
by
some
some
bike
share
discussion,
but
I'm
not
seeing
that
problem
at
the
moment.
The
the
the
way
we
arrived
at
sbf
1.0
was
a
pretty
constructive
process
and
I
think
we
can
continue
this
process,
so
I'm
not
seeing
the
need
to
actually
put
any
of
this
in
the
charter.
H
So
there
are
a
few
working
group
relationships
and
research
group
relationships
down
there,
the
zebra
working
group-
because
that's
some
of
the
cd
area
specification,
the
formal
description
techniques
proposed
research
group
that
that
might
be
a
number
of
people
to
talk
to
and,
of
course,
this
interesting
research
group
that
has
done
work
in
this
space
for
a
couple
years
now,
barry.
C
Okay,
the
only
thing
that
strikes
me
in
the
text
here
is
the
bit
that
says
to
work
with
one
dm
in
its
contributing
organizations
and
I'm
sure
that's
going
to
get
some
questions
from
the
iesg
if
it
goes
forward
that
way
along
the
line
of
concern
about
there
being
representatives
from
one
dm
who
say,
one
dm
says
this
rather
than
having
participants
as
individuals
working
on
this,
so
maybe
re-spinning
that
sentence
would
be
would
be
useful.
You
know
how
the
ietf
works.
C
H
E
So
I
understand
that
this
is
not
something
that
now
at
least
people
have
seen
this
charter,
and
so
should
this
charter
be
discussed
on
the
asdf
list.
I
guess
so.
E
Yeah,
so
please
sign
up
for
the
asdf
list
and
for
the
charter
discussions.
If
you
have
further
interest
in
this
and
then
I
think
we
have
a
clear
plan
forward,
all
right
move
this
along,
as
barry
said,
and
the
charter
is
approved
and
then
start
to
work.
E
Yeah
there
you
can
see
the
mailing
list
asdf
very
easy
to
remember
very
easy
to
type
good
name.
Okay
are
there
any
other,
because
we
actually
have
a
couple
of
minutes
left?
Are
there
any
other
comments
to
this,
or
are
everybody
happy
now,
so
we
can
move
along
with
the
preparations
for
next
meetings.
H
Resources
you
could
use,
one
is
on
my
youtube
channel.
There
is
1dm.org,
which
is:
maybe
you
can
bring
up1dm.org
briefly,
which
is
the
landing
page
for
information
about
1dm
and
there
you
also
find
the
github
repositories
where
the
various
models,
the
various
stages,
are
kept,
and
this
is
all
working
progress.
So
it's
not
finished
and
we
know
this
needs
lots
of
work,
but
I
think
it's
a
good
way
to
get
familiarized
with
this.
O
Yeah,
maybe
I
had
to
put
this
question
earlier,
but
I
would
like
to
know
whether
we
have
looked
into
what
is
happening
or
what,
in
in
other
sdos,
for
example,
the
1
and
3m
and
maybe
w3c
on
this
area.
Have
you
looked
into
into
what
they
are
doing
there.
H
O
L
That's
right:
we
work
we
we
and
a
number
of
us
individually
and
also
as
an
organization
to
some
extent
we
work
with
the
web
of
things
group
and
I'm
in
particular,
my
or
my
involvement
has
been
to
kick
off
the
protocol
binding
activity,
part
of
thing
description.
What
what
we're
focusing
on
is
the
the
domain
specific
vocabularies
and
that's
specifically
excluded
from
the
web
of
things.
L
We
plug
those
into
thing
description.
So
it's
it's
a
complementary
thing
where
you
have
an
sdf
model
that
describes
the
semantics
of
the
thing,
and
then
you
have
a
thing
description
that
applies,
those
semantics
to
a
network
object
and
specifies
protocol
bindings
and
over
the
over
the
wire
data
formats.
O
L
Yes,
we're
currently
working
on
a
feature
of
thing:
description
called
thing:
description
templates,
where
there's
there's
a
possibility
to
make
thing
descriptions
composable
by
plugging
in
one
dm
definitions
for
objects
into
a
thing,
description
and
composing
them
that
way,
and
we're
currently
actively
working
on
that
in
the
plug
fests
and
as
the
there
are
a
number
of
other
intersections.
Also,
for
example,
discovery
if
you
want
to
say,
find
a
temperature
sensor,
the
terminology
you
use
the
semantic
concept
uri
and
all
that
would
be
potentially
a
1dm
uri.
L
If
you're
looking
for
a
temperature
sensor,
although
there
are
there,
are
other
vocabularies
like
iot
schema
that
that
are
also
aligned
and
can
be,
can
be
just
directly
linked
to
so.
At
this
point,
we're
just
really
linking
to
to
uris.
E
O
And,
and
regarding
one
mpm,
you
looked
into
that.
L
One
mtm
was
involved
early
on,
but
they
we
had
to
partition
the
work
because
of
the
conflict
with
huawei,
which
is
now
over,
and
it's
been
mostly
resolved
by
the.
There
was
a
specifically
a
u.s
thing,
but
it
impacted
a
lot
of
companies
abilities
to
to
participate.
L
But
so
one
m2m
is
potentially
part
of
this,
and
also
the
the
modeling
part
of
one
dm
sorry,
one
one
mtm
and
and
one
dm
there's.
Another
potential
intersection.
L
H
So
maybe
one
thing
I
could
add
is
that
the
thinker
thing
research
group
has
been
organizing
a
number
of
informal
events
where
we
bring
people
from
different
sdos
and
vendors
together,
and
we
have
had
a
lot
of
workshops
with
w3c
in
in
the
process
of
creating
this.
So
w3c
is
that
the
web
of
things
interest
group.
There
is
a
bit
of
a
sister
organization
of
of
the
think,
the
thing
research
group.
H
In
a
way
they
also
have
a
working
group,
but
they
have
an
interest
group
as
well,
and
while
I
have
the
microphone
I
could
place
an
advertisement
for
the
next
bushy
call,
which
will
be
the
day
after
tomorrow,
where
we
will
talk
with
microsoft,
about
the
asia
dtd
digital
twin
description,
language.
So
that's
another
language
we
want
to
take
in
the
fold
of
sdf
and
we
will
have
a
discussion
the
day
after
tomorrow
how
that
might
work.
E
You're
sending
thank
you,
carsten
very
good
points.
I
think
one
thing
that
came
up
during
the
the
pre-both
discussions
around
this
asdf
and
one
dm
was
that
1dm
coming
out
of
the
closet,
so
to
speak
when
it
comes
to
becoming
a
vegetable
organization.
E
E
E
E
Thank
you,
barry,
okay,
everyone
with
that
we're
done
for
today,
and
many
thanks
to
jaime
and
ari
for
taking
notes
thanks
a
lot
for
that.
So
take
care
everyone
and
have
a
great
work
from
home.
Itf
week.
Take
care,
cheers.