►
From YouTube: IETF94-T2TRG-20151104-1030.webm
Description
T2TRG meeting session at IETF94
2015/11/04 1030
A
So
if
you
know,
if
you
talk
about
technology
and
know
that
technology
has
a
patent
claim,
you
need
to
be
telling
us
all.
Maybe
you
don't
want
to
talk
about
technology?
If
you
can't
I
would
have
expected
to
find
some
some
pink
sheets
here,
I!
Don't
so
can
I
ask
somebody
who
has
paper
to
generate
one
for
us
for
circulating
it?
A
A
A
Remember
that
when
you
subscribe
to
the
mail
list
there
is
an
IR
TF,
there's
still
lots
of
confusion
between
I
RTF
and
I
and
I
EGF
year.
So
last
time,
I
look.
This
was
the
place
to
actually
subscribe
and
we
also
have
had
some
recent
trouble
with
a
mailing
list.
So
if
something
is
strange
about
the
waiting
list,
please
tell
me
it
should
be
working
by
now,
but
if
something
doesn't
work,
the
way
you
think
it
should.
Please
tell
me
we
also
have
a
github
organization,
and
the
repository
for
this
meeting
is
up
there.
A
A
A
So
that's
a
very
broad
topic
and
of
course
we
are
focusing
this
on
areas
where
we
actually
makes
sense
that
we
are
closely
associated
with
the
IETF
so
areas
where
we
would
expect
future
standardization
to
be
of
importance.
Those
are
really
the
things
we
want
to
focus
on,
and
that
means
we
probably
won't
look
at
specific
radio,
techno
technologies
or
something
like
that.
Our
battery
technologies.
We
will
start
at
the
adaptation
layer
and
end
at
the
application
layer,
including
architecture,
ascent
and
a
P,
is
for
communicating
and
data
and
management
functions.
A
That
also
include
security.
So
that's
the
the
everyone
to
cover
here.
One
interesting
development
is
that
in
the
w3c
something
has
been
going
on.
That
is
a
bit
mirroring
what
we
are
doing
here.
The
w3c
has
so-called
interest
groups,
which
are
working
groups
that
haven't
quite
formed
yet
and
that
try
to
generate
overview
documents
and
an
interest
group
for
the
web
of
things
has
been
created
in
the
w3c
this
year
and
they
are
kind
of
a
natural
partner
at
the
application
layer.
A
They
are
probably
not
not
so
interested
in
an
application
layer
issues,
but
at
the
application
layer
they
are
interesting
people
to
to
talk
to,
and
that
is
actually
just
an
example
of.
What's
going
on
out
there,
we
now
have
a
first
wave
of
IOT
standards
completed
by
the
IGF
and
out
there.
There
are
lots
of
organizations
that
want
to
build
systems
on
top
of
these
standards,
and
this
causes
new
requirements
for
results.
So
we
are
no
longer
looking
at
small
pieces
of
a
technology.
A
A
A
So
you
don't
have
single
single
application
networks
generally.
There
are
deployment
considerations,
scaling
is
probably
the
most
important
word
in
the
internet
of
things,
not
just
scaling
up
but,
as
importantly
scaling
down,
so
we
can
use
many
many
inexpensive
devices,
management
and
operation
are
issues
so
far
we
haven't
really
looked
at
management
Percy,
but
we
have
looked
at
what
protocols
we
might
be
using
for
actually
getting
existing
management
frameworks
to
work
in
the
Internet
of
Things
lifecycle
aspects
are
very
important.
A
If
your
thing
is
acquired,
then
most
likely
that
we'll
have
a
certain
life
cycle.
When
you
are
done
with
it,
you
cannot
just
delete
it.
It's
still
there
and
we
need
to
find
out
how
to
handle
that
a
life
cycle,
and
there
are
always
security
considerations
around
them
as
well
and
finally,
in
particular,
incorporation,
worse
w3c
data
formats,
semantics
and
so
on
will
need
to
be
worked
on.
Clearly.
That
is
something
where
lots
of
organizations
are
actually
working
on,
but
there
may
be
some
some
IETF
specific
aspects
here
that
we
may
want
to
focus
on.
A
Areas
of
interest
where
we
don't
quite
know
what
we
will
be
doing
here
but
which
might
become
interesting
one
aspect
is
things
often
have
more
complicated
relationships
to
the
humans
and
the
organizations
out
there.
Then
a
data
file
data
file
is
typically
in
the
hands
of
a
single
organization.
A
thing
much
we
owned
by
someone
might
be
used
by
someone
else
might
actually
collect
data
that
is
personally
identifiable
information
of
a
third
stakeholder
and
so
on.
So
the
situation
around
things
can
get
more
complicated.
A
I'd
like
you
to
get
more
complicated
than
around
data
object,
those
that
have
followed
the
development
of
Internet
of
Things
applications.
Protocols
in
the
last
couple
of
years
would
have
noticed
that
we
have
two
cams
there.
One
is
looking
at
web
based
approaches,
representational
state
transfer,
so
the
main
keyword,
a
stage
and
other
people
are
looking
at
message,
based
approaches
and
the
keyword,
there's
events,
and
if
you
look
a
little
bit
closer,
you
will
find
out
that
states
and
events
are
in
the
same
kind
of
duality
in
which
particles
at
waves
are.
A
A
So
that's
something
we
want
to
explore
which
which
we
are
already
doing
a
little
bit,
but
that's
an
interesting
question:
a
distribution
of
processing
keywords
like
for
computing,
scalability
considerations
there.
How
do
you
work
in
an
environment
where
there
are
lots
of
resources?
But
you
cannot
rely
on
all
of
these
resources.
There
should
be
something
that
brings
home
for
four
people
who
are
working
on
the
internet
and
similar
considerations
apply
to
go
to
the
computing
resources.
And,
finally,
how
do
you
actually
apply
the
trend
of
containerization
and
mobile
code
to
very,
very
simple
basic
devices?
A
So
these
are
the
areas
of
interest
and
to
do
this
to
work
on
these,
we
probably
have
a
few
more
objectives.
One
is
the
definition
of
benchmarks
or
reference
environments.
It's
always
very
hard
to
talk
about
someone
to
talk
with
someone
about
performance
considerations,
because
the
scenario
they
have
in
mind
is
probably
completely
different.
Then
the
scenario
you
already
have
so
it
is
probably
useful
to
have
some
reference
environments
that,
for
instance,
will
allow
us
to
run
plug
fests.
A
So
we
all
have
a
common
scenario
working
on
when
plugging
things
together
and
testing
our
protocols,
but
also
as
a
basis
for
repeatable
research,
because
if
you
have
a
benchmark
environment-
and
you
might
be
able
to
say
something-
this
is
thirty
percent
faster
than
that
other
approach
or
uses
thirty
percent
less
memory
and
that's
hard
to
do.
If
you
don't
have
a
benchmark,
it
might
be
useful
to
simply
describe
applications
running
in
the
Internet
of
Things.
A
So
what
what?
What
actually
has
worked?
And
what
are
the
characteristics
that
made
it
work?
We
probably
need
Tom's,
we
need
need
survey
documents
and,
after
while
probably
prospectus
documents
and
finally,
the
objective
is
to
to
work
with
industry
for
our,
not
not
in
the
meaning
of
a
formal,
yeas
and
reiationship,
or
something
like
that,
but
just
making
sure
they're
relevant
information
gets
known
here
and
our
relevant
information
gets
not
there.
A
Obviously,
we
ought
to
have
a
relationship
to
the
ITF
working
groups.
There
are
currently
H
working
groups
in
the
IDF
working
on
internet
of
things,
issues
focusing
on
internal
things,
the
shoes
I
should
say-
and
probably
cover
more.
That
also
are
highly
interesting
to
us
and,
of
course,
the
the
job
of
the
research
group
is
not
not
to
replicate.
What's
going
on
there.
All
the
knowledge
of
work,
of
course
goes
on
in
working
groups,
but
we
want
to
know
what's
going
on
there.
A
So
for
this
one
interesting
consideration
is
that
maybe
doing
something
like
a
use
case
document
can
be
done
in
parallel
with
actually
chartering
a
working
group.
So
when
do
a
group
actually
hits
the
ground?
It
already
has
a
document
to
look
at
for
use
cases
or
other
information
of
reference
surveys,
and
so
on
yeah
and
there's
also
an
IOT
Directorate.
This
is
a
little
bit
running
on
the
back
burner
right
now,
but
it's
definitely
an
environment
that
we
to
talk
to
the
IAB
is
very
important
for
us.
A
They
have
been
to
Seminole
workshops
run
by
the
IAB
or
by
IAB
people
that
really
have
shaped
the
work
in
the
last
half
decade
in
VI
EGF
on
the
Internet
of
Things,
the
smart
object
workshop
in
Prague
and
the
not
object
security
workshop
in
Paris.
These
have
been
very
useful
and
I
would
expect
additional
workshops
like
this
to
happen,
in
particular
in
areas
that
are
kind
of
related
to
our
work.
So,
for
instance,
there's
going
to
be
a
workshop
on
semantic
interoperability
early
next
year
and
that
certainly
something
where
we
want
to
cooperate.
A
Explaining
the
name
I
sometimes
get
asked,
this
research
group
is
called
thing
to
thing,
so
you
are
not
interested
in
thing
to
cloud
architectures.
That's,
of
course
not.
The
point
here
actually
think
you
think
came
up
as
as
a
large
to
the
end-to-end
research
group
that
has
been
working
on
a
number
of
subjects
for
a
long
time
and
we
are
not
excluding
device
to
Clark
models
to
the
country.
Of
course,
things
work
best
if
they
also
have
bigger
companions
to
talk
to.
A
This
will
operate
a
lot
like
the
other
research
groups
that
you
are
familiar
with
and
I'm
not
going
to
cite
all
those
research
groups
that
we
can
learn
a
lot
from,
so
things
like
regular
plug
casts
and
so
on
may
be
common
open
source
software
that
we
are
looking
at
and
so
on.
That's
something
that
we
can
learn
from
from
other
user
troops.
A
The
proposed
research
group
has
already
met
a
couple
of
times
before
so
we
had
our
first
meeting
in
dallas
with
ITF
92,
where
we
identified
three
main
areas
of
internet
breast
management
protocols
and
security
and
in
prague
we
kind
of
focused
on
rest
and
security,
not
ignoring
management
protocols,
but
just
considering
management
protocols.
Another
application
in
the
area
of
applied
west
and
prague
also
was
our
first
joint
meeting
with
w3c
interest
group.
A
Where
were
things
that
had
just
before
had
their
first
face-to-face
meeting
in
Munich,
and
in
this
meeting
we
had
another
joint
meeting
with
the
interest
group
rubber
things.
The
interest
group
already
had
met
in
sapporo
last
week
and
we
took
a
lot
of
input
from
there
and
again
we
essentially
split
into
two
tracks.
One
track
that
we
have
been
calling
rest
as
we
know
it
about
that
might
turn
into
a
beyond
rest
activity
over
time,
and
we
are
the
one
about
security
and
lifecycle
aspects
and
constraint.
Note
networks.
A
So
again,
since
this
is
a
joint
meeting,
we
were
focusing
on
joint
discussion.
Maybe
when
we
have
a
few
meetings
that
are
not
join
me
drinks,
we
will
be
having
additional
focuses
that
are
beyond
those
of
w3c.
But
right
now
this
seems
a
very
natural
partnership
and
we
have
very
similar
ideas
of
the
gaps
that
need
to
be
addressed
right
off,
okay
and
yeah.
This
is
actually
a
meeting
where
we
want
to
do
a
little
bit
of
administrative
work
as
well.
At
the
end
of
this
summary
meeting,
the
agenda
was
pretty
much
split
between
talks.
A
I
didn't
count
them,
but
we
had
approximately
10
talks
by
different
researchers
and
breakouts,
where
we
were
progressing.
These
two
tricks
a
and
B,
and
let
me
talk
about
those
tracks,
the
rest,
followed
track
or
the
track
a
has
since
identified
two
deliverables.
They
want
to
work
on
this.
The
first
one
is
often
called
a
cookbook,
so
it's
been
as
a
guidance
document,
so
we
have
terminology
basic
guidance,
point
us
to
other
work,
that's
neat
that
needs
to
be
considered
in
one
document
and
that
will
grow
with
information
about
design
patterns,
resource
design.
A
A
The
other
document
I
come
back
to
that
in
a
minute.
Really
right
now
is
well
as
a
scenario
document.
It
describes
ways
to
develop
and
test
hypertext
a
hypermedia
driven
approach,
and
we
will
develop
this
by
actually
running
plugfest
plug
rest,
as
we
have
called
them
where
we
actually
build
these
systems
and
try
to
collect
information
from
from
this
actual
building.
A
A
There
are
three
task
forces
in
the
wot
interest
group
called
thing,
description,
discovery
and
API
and
protocols.
We
were
interacting
with
all
three
right
now
thing
description
is
the
one
where
we
have
the
strongest
ideas,
how
to
run
the
next
black
vest,
and
the
idea
is
to
do
this
as
a
very
cooperative
activity
sharing
experiences
sharing
code.
A
Yeah,
so
just
to
give
you
an
idea:
what
of
what
this
is
about?
There
are
tons
like
application
stage
that
we
have
to
be
looked
at
closely
when
you
talk
about
distributed
systems
with
many
things
in
them.
You
have
in
rest,
you
have
state,
but
of
course
we
also
have
actions
and
how
do
your
model
actions
with
a
rest?
A
How
do
you
links?
How
do
you
represent
values
there?
How
do
we
do
partial
changes
on
resources?
The
term
collections
is
coming
up
about
every
five
seconds,
and
particularly
also
when
we
talk
about
management
and
the
conclusions
are
we.
We
think
we
know
how
to
do
this,
but
it
would
be
much
better
if
we
had
done
it
once
and
had
documented
our
experience.
A
So
there
are
lots
of
components
which
reaching
all
world
but
building
systems
with.
That
is
an
activity
that
actually
still
is
research
and
and
the
idea
is
to
learn
from
specific
scenarios
so
that
this
hard
draft
here
is
one
of
the
scenarios
and
it's
a
simple
application
level
design
where
these
design
Styles
have
been
applied
to
a
basic
lighting
scenario.
A
A
They
are
trying
to
add
safety
to
that
list,
because
when
you
do
things,
then
you
probably
have
to
think
about
safety
as
well,
and
they
have
ongoing
work
on
challenges
or
gaps
requirements
and,
in
particular
on
a
landscape
of
needs,
which
means
they
are
survey,
surveying
what
words
are
there
already
in
our
cricket?
There
are
lots
of
truths
in
our
toolkit
and
we
need
to
since
there's
almost
nobody
who
knows
all
these
security
technologies.
A
We
need
a
little
bit
more
information
about
what
their
characteristics
are
and
what
problems
they
can
sort
of
and
where
the
gaps
are.
So
this
is
very
good
for
work
and
I
think
there
will
be
a
lot
of
cross-pollination
for
the
research
group
side.
We
have
identified
two
documents
that
really
would
like
to
work
on
now.
A
One
everybody
who
has
followed
the
work
of
the
car
working
group
probably
is
a
way
about
this
document.
It's
the
document
that
we
have
been
working
on
a
little
bit
in
the
car
working
group,
but
recovering
who've
always
had
had
this
these
angular
to
do
and
had
to
get
out
standards
and
so
on.
So
maybe
it
wasn't
the
right
environment
to
move
this
forward.
So
in
the
research
group
we
have
identified
the
number
of
people
who
want
to
work
on
this.
A
A
It
allows
IDF
documents
reference
this
document,
so
they
don't
necessarily
need
a
lot
of
verbiage
about
security.
Consideration
Conservation's
that
I
global
to
the
IOT
domain
is
not
specific
to
of
the
document,
so
this
is
a
well
prepared,
a
document
that
essentially
just
needs
to
be
picked
up
and
infused
with
new
energy.
The
other
deliverable
we
have
in
mind.
B
A
A
Identifying
their
characteristics
may
be.
Grouping
them
into
categories
would
be
a
very
good
basis
for
the
next
steps
that
will
happen
in
the
IDF,
where
we
will
actually
have
bootstrapping
operations
in
the
protocol.
So
right
now
the
projects
that
are
being
worked
on
don't
have
bootstrapping
functions,
but
I'm
sure
they
will
grow
them
over
time
and
it
would
be
good
to
have
this
production.
So
this
is
a
bit
more
risky
and
we
also
don't
have
quite
as
many
people
who
want
to
work
on
this.
A
A
A
The
plans
forward
include
going
to
that
joint
meeting
with
w3c
and
in
France
in
the
week
from
january
25th.
That
seems
like
a
pretty
good
idea.
Then
we
don't
have
a
very
solid
idea.
What
we
will
do
in
the
spring.
Probably
you
will
contribute
to
that
IV
workshop
on
semantic
interoperability,
but
that
hasn't
been
quite
laid
down.
Yet
as
far
as
I
understand,
there
is
also
w3c
meeting
that
we
might
somehow
try
to
be
involved
with
then.
A
Maybe
the
next
combination
color
here
is
the
July
ietf
and
in
August
we
should
be
trying
to
get
a
workshop
at
a
major
research
conference,
but
that
of
course
depends
on
whether
from
the
proposal
is
accepted,
and
that
is
the
meeting
planning
we
have
in
mind
so
far.
But
of
course
we
are
flexible,
except
maybe
for
this
January
thing
which,
which
seems
to
be
pretty
much
said,
no
questions
on
the
summary.
B
Kevin
fall
CMU,
so
in
your
one
of
your
first
slides
where
you
define
things,
it's
constrained
nodes
constrained,
sort
of
communication
in
those
environments,
and
maybe
this
ship
is
sailed
already,
given
all
the
previous
work.
But
you
did
use
the
word
safety
in
your
discussion
there
and
there's
a
whole
category
of
things
right
that
we
might
call
industrial
internet
or
other
sorts
of
things
that
are
not
necessarily
communication
constrained,
or
at
least
they're,
not
node
constrained
but
may
have
real-time
timing.
Requirements
may
have
sort
of
special
security
requirements,
proofs
for
control
loops.
B
A
That
that
suddenly
can
be
fleshed
out.
I
think
that
the
idea
here
is
to
think
about
architecture
that
that
can
include
constrained
objects
and
constraint
networks,
but
that
doesn't
mean
that
that
all
the
elements
of
that
architecture
are
constrained.
But
we
don't
want
to
do
another
car
to
car
research
group.
So
I
think
the
thing
is,
is
the
important
element
here.
B
A
A
C
Hi
I'm
Andrew
Sullivan,
so
now
I'm
confused
well,
no
now
I'm
confused
about
a
different
thing,
so
it
sounded
to
me
like,
like
what
kevin
was
asking
was:
okay.
Well,
you've
got
this.
This
definition
of
thing
that
seems
to
have
you
know,
constraint,
constrained
something
in
it
and
and
and
now
we
just
said
well,
okay,
but
it's
true
that
there
are
these
things
that
aren't
constrained
so
so
now
it
seems
like
what
we're
talking
about
is
networking
and
that
doesn't
sing
good
answer
either
so
we're
gonna
have
to
like.
C
B
So
Kevin
fall
again
not
that
I'm
trying
to
advise
you
one
way
or
the
other,
but
I
lived
through
a
world
in
a
2000
era
which
we
called
sensor
networks
where
the
premise
right
was
constrained,
nodes
and
as
one
year
would
go
to
the
next,
they
became
less
and
less
constrained.
Nonetheless,
all
sorts
of
interesting
work
came
out
of
that
and
we
have
census
which
might
be
the
place
you
want
to
connect
with
and
so
on.
B
But
I
guess
I
want
to
make
clear
that
if
your
choice
is
that
the
constrained
pneus
is
the
primary
thing,
you're
going
to
focus
on
that's
going
to
lead
you
down
a
certain
set
of
paths,
whereas
the
real
time
and
control
loop
and
all
of
that
stuff,
you
might
say
the
inverse
of
GT
energy
in
some
ways
would
admit
a
different
set
of
work
potentially
and
so
just
wanted
to
bring
that.
But
it
worries
me
a
little
bit
if
thing
equals
constrained.
Node
well,.
A
A
C
Well,
so,
well
it
it!
It
gives
me
since
I
start
from
a
naturally
confused
state.
It's
not
like,
there's
a
whole
lot
to
do
there,
but
it
it's
android
game
by
the
way
for
the
for
the
roads.
It
seems
to
me,
though,
that
now
we
really
are
in
risk
of
of
making
a
scope
of
this
research
group
such
that
it's
going
to
have
a
hard
time
focusing,
so
it
would
be
valuable.
B
Agree
that
some
things
are
constrained,
but
I
think
that
most
many
of
the
problems,
they're
most
interesting
to
me
are
specific
research
problems
that
have
to
do
with
devices
that
that
I
think
of
as
things
because
they
do
not.
We
cannot
use
the
men,
manage
the
user
in
phases
and
inputs
to
them
that
we
do
with
most
networking
equipment
so,
like
the
security,
provisioning,
bootstrapping,
enrollment
type
problem,
that's
a
very
specific
problem.
B
It
doesn't
matter
whether
the
thing
that
that
problem
exists
for
both
constraint
non
constrain
things,
many
of
the
devices
they're
actually
being
sold
in
this
space.
Right
now,
like
I,
you
know
I'm
involved
with
a
power
meter
that
goes
for
seven
hundred
dollars.
Each
I
mean
the
number
of
transistors
in.
It
is
not
really
an
issue
in
that
sort
of
space,
but
it
still
has
that
boots
tearing
a
provision
problem.
So
when
I
read
the
Charter,
it
was
just.
It
seemed
to
me
that
it
covered
every
research
problem
that
ever
impacted.
B
Maybe
anything
that
happened
at
I
ETA
is
very,
very
broad,
so
I'd
prefer
us
to.
But
when
you
go
and
start
when
you're
talking
about
specific
for
areas
to
look
at
those
seem
much
narrower
like
we
could
say,
here's
a
particular
research
question.
So
I'd
rather
see
a
charter
that
that
had
a
set
of
specific
research,
fairly
narrow
questions.
D
Laughs,
I
good,
so
I
want
to
push
back
on
on
the
last
two
points
a
little
bit
because
in
the
IR
ITF
we
actually
try
and
have
so.
The
charters
in
the
I
RTF
fulfill
a
very
different
golden.
The
charges
in
the
ITF
right
there
much
more
satis
le
this
week,
too
much
more
advertisements
to
researchers
to
understand
whether
the
research
will
fit
in
this
group
I.
Think
of
it
almost
like
a
call
for
paper
or
something
and
yeah
I've
got
the
call
for
paper
says
you
know
everything
in
network
against
in
scope.
D
That
is
to
broaden
and
I
think
that
we
want
to.
We
want
to
look
at,
but
otherwise
I
wouldn't
want
to
have
something.
That
is
that
it's
very
tightly
constrained
because
we
are
supposed
to
be
open
and
we
in
the
I
RTF
often
rely
on
the
chairs
of
the
groups
to
give
it
a
focus
at
any
given
time
and
make
sure
that
the
work
isn't
all
over
the
place
and
then
some
research
group
that
works
better
and
in
others.
D
D
You
know
something
that
is
armed,
very
limited
and
we
have
to
reach
arter
them
in
six
months,
but
so
that
that's
really
not
sort
of
Holly
I
I
RTF,
normally
operates
I
think
they
look
at
Kadesh
terminal
research.
Group
I,
don't
think
your
Charter
has
averaged
changed,
changed
in
20
years
and
everybody
sort
of
kind
of
gets
what
they're
doing
and
it
changes
over
time
and
that's
fine.
C
It's
andrew
again,
so
I
agree
with
everything
you
just
said:
I'm
not
trying
to
say
say,
like
you
know,
get
yourself
milestones
and
and
and
that
sort
of
thing
that's
not
my
goal-
I,
it's
it,
but
but
we've
seen
research
groups
right
that
have
scope.
That
is
is
too
broad
for
people
to
focus
on,
because
you
you
know
they.
They
end
up
spending
a
lot
of
time,
I'm,
arguing
amongst
themselves
about
what
what
is
the
real
problem.
They
ought
to
be
working
on
and
I.
Just
don't
think.
D
So
in
the
IETF
right
we
we,
the
80s
and
the
chairs,
oftentimes
use
the
Charter
and
we
use
it
to
be
very
descriptive
so
that
we
can
eliminate
a
lot
of
arguments
with
people
that
want
to
put
their
work
in
where
it
really
shouldn't
be
in
that,
because
it's
trying
to
do
something
else,
but
in
the
I
RTF
we
rely
more
on
the
chairs
to
explain
to
people
that
comments.
So
how
does
this
fit
and
say?
Yes,
it
does
fit
the
general.
You
know
the
general
umbrella
of
work,
but
it
is
IOT
related.
D
C
Again,
I
agree
and
I
I
guess
what
I'm
trying
to
it
really
I
only
got
up
because
of
what
Kevin
said
and
what
I
heard
in
response
was.
Oh,
yes,
that's
a
problem
here.
You
can't
get
up
anymore.
Oh
yes,
that's
a
problem
here
too,
and
that
seemed
to
me
to
be,
like
you
know
at
least
90
degrees,
away
from
the
first
thing
that
I
thought
we
were
working
like
so
so
we
should
probably
have
some
agreement
at
least
about
what
are
the
interesting
problems.
That's
I,
don't
care
how
we
get
it.
A
B
So
Kevin
phone
again
I'm
just
so
now
I
will
make
a
slight
advocation
before
I
was
just
making
the
observation
so
based
on
I
can't
get
up
again
right.
This
idea
that
these
are
advertisements
for
weather
researchers
might
be
interested
is
to
the
point.
In
fact,
what
I
really
want
to
know
is
if
I
got
somebody
who's
doing
real-time
controller
research
using
Internet
protocols.
Do
they
go
here
or
not,
because
the
first
line
of
the
Charter
says
constrained
nodes.
B
A
A
B
Have
a1
questions
you
mentioned
as
a
internal
collaboration
with
other
research
group
like
I,
crg
you'll
have
any
concrete
plan
from
my
knowledge,
adult
group
is
working
on
specific
some
people
mentioned
as
the
issues
with,
for
example,
like
a
naming
like
a
security,
a
search
with
naming
and
the
data
forwarding
associate
with
naming
whatever
the
status
and
eventually
the
scoop
is
going
to
to
to
hate.
So
does
not
well.
A
I
synergy
is
this
is
trying
to
solve
a
problem
that
is
very
much
related
to
that
problem
that
we
called
the
undress
this
year.
We
have
managed
to
always
put
our
research
group
meetings
on
top
of
icy
energy
meeting,
so
we
don't
didn't
quite
have
the
amount
of
off-exchange
that
I
hope
we
will
be
and
will
have
in
the
future.
But
yes,
I
agree
that
that
the
ICN
work
is
very
relevant
to
the
work
that
we
are
doing
here.
B
Suggestion
that
it's
been
up
to
the
chair
to
figure
out
how
to
focus
things,
you
know
at
the
end
of
the
day,
this
is
contribution
driven
and
if
you
are
suddenly
going
to
get
a
gazillion
requests
on
that
involve
real-time
control
of
devices
attached
to
monstrous
things.
That
move
other
things
that
weigh
tons,
and
then
that
is
probably
a
valuable
input
to
the
community.
B
B
Are
Quran
as
someone
who
has
been
participating,
the
last
few
meetings
I
think
we
had
pretty
open
scope
to
begin
with,
and
I
were
discussing
quite
a
lot
and
then
quite
naturally,
two
different
tracks
emerged.
We
had
the
security
track
and
a
restful
track,
and
then
we
were
focused
within
those
groups
within
those
topics.
I
think
that
model
worked
well
so
far,
so
I
would
also
have
lean
more
on
the
towards
the
open
side
and
see
how
things
evolve
and
right
from
there
yeah.
B
Actually
this
definition
that
it's
something
connected
to
something
physical
and
it
may
be
constrained,
and
so
it
could
be
these
kind
of
real-time
controllers.
However,
we
won't
discuss
what's
the
best
way
to
do
real-time
control
there
but
kind
of
discuss
how
this
affects
the
protocols
and
the
networking
that
is
involved
there.
So
usually
we
look
at
architectures
that
involve
these
different
kind
of
things
and
they
should
work
together.
So
someone
could
work
on
this.
Give
us
some
input.
B
This
is
definitely
interesting
for
the
architecture,
but
you
won't
find
that
many
people
who
can
advise
or
where
ideas
on
return
control
can
can
be
exchanged.
The
same
is
if
you
have
to
use
cases
from
some
specific
application
domains.
That's
not
really
what
we
want
to
work
on,
but
it's
kind
of
this
architecture
that
can
unify
these
kind
of
different
systems.
I.