►
From YouTube: IETF100-CORE-20171114-1330
Description
CORE meeting session at IETF100
2017/11/14 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
Okay,
so
it
seems
people
have
stopped
trickling
in
so
this
is
the
second
meeting
of
the
co-working
group
and
it's
only
Tuesday,
so
I'm
still
reminding
people
that
I'm
still
reminding
people
that
this
is
an
ITF
meeting.
We
are
using
the
IP
our
principles.
If
you
know
about
patent
claim
about
technology
that
you
are
talking
about,
you
have
to
tell
us,
or
you
can
decide
not
to
talk
about
that
and
yeah.
You
will
be
on
video
and
recorded
and
everything
so
that
there
is
a
node
realm
for
that.
A
C
This
slide
chain
starts
to
work.
It's
okay,
so
I'm
gonna
give
a
quick
update
on
San
MLS.
We
had
a
group
last
call
already
on
that,
a
lot
of
lot
of
good
comments
and
we've
made
a
bunch
of
changing
since
the
last
idea
lost
of
editorial
changes.
Mostly
thanks
to
all
the
good
reviews.
We
got
a
few
clarifications
that
are
worth
mentioning.
One
was
that
what
happens
when
you
do
the
result
records
what
happens
with
the
base
person
field.
So
the
result
records
are
where
you
have
all
the
values
in
all
the
records
based.
C
Current
values
are
added
to
the
base
values
and
all
the
records
become
self
contained.
So
it
was
a
bit
of
confusion.
What
happens
with
that
version,
and
we're
now
clarified
that?
Yes,
the
version,
if
it's
something
else,
then
a
default
needs
to
be
in
all
the
records,
but
if
it's
a
default,
you
should
not
put
it
there.
C
Also,
as
decided
in
the
last
meeting,
we
removed
link
extents,
and
it's
going
to
be
done.
As
an
extension
document,
there
was
a
few
remnants
on
CD
DL
that
we
still
need
to
clean
up
but
other
linked
functional.
It
was
removed
already
also.
We
changed
the
registry
policy
to
expert
review,
only
there's
a
one
place
where
it's
all
still
that's
also
the
iesg
approval,
but
it
has
got
to
be
all
expert
review
as
decided
in
the
last
meeting,
and
then
it
was
Dave
raised
in
the
previous
meeting
was
appointed.
C
There
was
Celsius
and
Kelvin
both
in
the
units,
and
it
would
be
good
to
clarify.
Why
is
that?
And
now
there's
a
paragraph
explaining
why
this
case,
because
even
the
original
ISO
spec
has
it
both
and
both
of
them
at
the
same
level?
So
it's
reasonable
to
have
also
sentinel
has
for
both
Celsius
and
Kelvin
as
a
unit.
C
Few
more
things
we'll
do
now
soon
after
this
meeting
is
one.
There
was
a
comment
from
Hannes
that
the
current
security
consideration
section
was
quite
thin.
It
just
referred
to
the
privacy
section
and
the
media
like
registrations,
and
the
reason
was
that
at
immediate
aggregates,
racers
need
to
have
their
own
security
considerations.
But
now
it's
a
chat
with
Alec
said
it
would
be
okay
to
have
it
only
once
in
the
security
considerations
and
then
refer
to
that
security.
Consideration
section
in
the
media
type
registration.
C
C
Then
all
those
comment
from
team
shard
to
have
bit
more
details
on
the
IANA
regulate
this
table
to
have
make
sure
we
have
all
the
different
different
data
types
and
labels
in
in
table
that
we
did
take
a
stab
at
that.
It
ends
up
being
quite
awkward
table.
But
maybe
we
need
to
have
one
for
Ayane
and
another
one
for
those
who
actually
read
the
read
the
specification
and
use
it.
C
E
E
Your
your
this
is
kind
of
a
really
messed
up
thing.
You've
got
you've,
got
a
get,
that's
returning
a
location,
and
I
agree
that
would
be
normally
what
you
do
is
a
created
and
here's
the
location
header.
So
I'm
wondering
whether
the
semantics
is
just
wrong.
It's
or
you
really.
Should
you
be
doing
a
post
and
getting
you
know,
saying,
post,
basically
an
empty
body
that
says
create
me
my
response
and
then
I'm
telling
you,
okay,
I
created
it,
and
here's
where
it
is.
D
A
bit
more
optimistic
than
that,
so
the
client
usually
expects
voucher
requests
back
right.
So
it's
only
an
exceptional
cases
that
the
voucher
is
not
available
and
then,
instead
of
getting
back
the
response,
your
requesting
you're,
getting
back
a
location
where
you
can
ask
again
for
their
for
the
same
voucher.
So.
D
E
It
seems
to
me
that
you
should
get
back
an
answer,
but
the
the
answer
in
the
data
is
a
choice
of
a
voucher
or
a
location
to
go,
get
it
ended,
delay
and
all
that
and
you
don't
introduce
any.
It
is
a
success
code.
You
don't
introduce
any
new
code,
you
don't
you
have
a
header,
you
just
say
here's
my
answer.
My
answer
is
either
a
voucher
or
instructions
as
to
where
to
get
about.
If.
E
D
D
A
A
F
Hello,
can
you
hear
me
yes,
hi
I'm
Francesca
I'm
presenting
the
score
update
so,
first
of
all
the
change
of
name
until
now
you
know
this
also
school,
but
now
it's
called
Oh
score.
So
object
security
for
constraint,
restful
environments,
name
change
proposed
by
Dave.
Thank
you
and
it's
version,
zero,
six.
F
G
H
So
hummus
is
our
favorite
comment
here
on
this
topic.
I
just
want
to
comment
on
hummus
use
of
the
word.
Signature
is
not
correct,
because
this
is
not
at
all
about
signatures.
There
is
no
signature,
there
are
no
signatures,
so
that's
wrong.
I.
Think
I
think
you
shouldn't
proceed
that
discussion.
Okay,.
F
H
F
Okay,
I'm
gonna
move
forward
with
the
updates
yeah.
If
you
have
comments,
please
posted
okay,
so
one
first
update
now
we
protect
the
coop
code,
which
is
encrypted,
and
this
is
so
it
wasn't
encrypted
before
and
we
add
the
dummy
code
that
is
outside
for
the
proxy
to
read
and
we
always
use
post
or
fetch
for
requests
based
on
if
there
is
observe
or
not
because
observe,
does
not
support
post
and
we
always
use
to
a
four
four
responses.
F
Second
update
or
score
now
has
a
full
section
of
describing
how
cross
protocol
translators
work.
Also
thank
you
Dave,
and
this
was
based
on
an
ocf
request,
and
this
is
the
reason
for
the
name
change,
and
this
defines
a
new
HTTP
header
called
object
security.
Then
we
changed
how
the
cose
object
Cosi
compressed
object,
instance
portal.
So
now
in
the
coop
payload
we
have
the
cipher
text
and
in
the
object
security
option
value
we
have
everything
else.
F
So
all
the
header
fields
and
everything
that
is
needed,
then
we
did
change
the
we
announced
last
time,
which
was
we
remove
the
Auslan,
which
was
object,
security
of
content
from
the
appendix
we
simplified,
the
observed
processing
based
on
Christian
feedback
and
suggestions,
Thank
You
Christian,
and
we
update
the
nonce
construction.
Now
the
sender
ID
is
part
of
the
nuns
and
the
partial
AV
does
not
need
to
be
sent
in
non
observe
responses
which
allows
for
memory
safe.
So
in
general
we
we
did
some
updates,
but
nothing,
nothing.
F
Major
then
I
wanted
to
report
on
the
interrupt.
This
was
during
the
ITF
hackathon.
Here
in
Singapore
we
had
two
participants
thanks,
Christian
and
Jim,
and
in
total
we've
done
five
interrupt.
The
the
last
interrupt
in
includes
the
latest
changes
and
created
a
couple
of
issues
that
we
are
solving.
Now
we
have
sold
some
already
and
we
plan
to
solve
them
all
by
the
end
of
this
week.
F
F
So
we
have
one
issue
that
was
about
observation,
renewal
and
I.
Think
Christine
already
reported
that
in
the
main
list
and
then,
as
I
said
many
minor
issues
as
a
result
of
the
interrupt
and
then
some
more
general
issues
that
have
been
parked
until
now.
Our
privacy
and
traffic
analysis
considerations
and
review
then
RFC
to
one-one-nine
compliance
as
per
James
request,
and
we
still
need
to
put
in
the
test
vectors.
F
I
Since
you
didn't
have
a
slide
about
the
o,
cf1,
that's
gonna,
unless
you
want
to
I,
can
give
the
summary
from
the
report
out
with
the
discussion
of
most
yeah.
So
we
had
a
joint
meeting
between
thing
to
thing,
research,
group
and
OCF
on
Friday
of
last
week-
and
this
was
after
the
ocf
had
had
some
discussion
that
I've
led
to
no
CF
about.
Would
the
new
version
of
OS
core
actually
suffice
for
all
ocf
needs?
I
I
Add
a
table
about
which
header
fields
are,
and
you
know,
encrypted
versus,
not
just
for
readability
but
as
far
as
the
normative
part
so
CF
said.
Well,
we
don't.
We
can't
think
of
anything
that
it's
is
when
that
would
prevent
OC
FM
using
it,
as
is
there
were
things
that
OC
f
might
want
ITF
to
do
in
the
future.
I
In
addition,
that
might
use
OS
core,
but
as
far
as
this
I
think,
the
message
from
OC
f
was
yeah
draft
looks
good,
please
publish
type
of
thing
or
please,
please
complete
the
work
and
publish
it
on
your
normal
mechanism.
There's
no
no
asks
an
example
of
something
that
they
said.
That
IETF
might
want
to
consider
in
future.
I
Work
that
is
not
part
of
OS
core
but
might
use
OS
car
is
something
that
would
say
how
you
might
protect
confidentiality
wise
might
protect
some
of
the
headers
that
OS
core
does
not
covered
today,
so
like
the
identity
of
the
final
of
the
final
destination.
Now
that
the
URI
host,
for
example,
how
you
might
sort
of
hide
that
from
a
set
of
intermediaries
in
the
middle
of
a
path
that
you
want
to
protect
from
with
some
notion
of
they
call
that
tunneling.
I
But
you
know
whatever
the
mechanism
is:
what's
the
IETF
recommended
way
to
say
tunnel
OS
core
inside
something,
whether
it's
IP
tunneling
or
OS
core
inside
OS
court?
Whatever
else
it
is
right,
so
they
said
it
would
be
great
if
IETF
in
the
future
could
he
write
some
informational
document
that
said
or
whether
it's
informational,
post
and
I,
don't
think
they
care
some
document.
That
said
how
you
might
think
about
protecting
that,
and
they
might
be
interested
in
that
too,
but
the
bottom
line
was
I
think
they
said.
Yep
looks
good.
Thank.
F
A
K
L
K
F
M
A
B
F
N
M
Jim
shot
the
fiddling
with
the
nonce
was
basically
a
set
up
for
future
work,
but
it
essentially
since
for
this
document,
since
the
keys
are
separate.
How
we
fiddled
with
the
nonce
is
not
a
security
problem.
It's
just
maybe
a
little
bit
of
a
pain
for
certain
situations,
but
it
guarantees
when
we
go
into
of
the
group
document,
that
we
have
complete
separation
of
the
nonce
space,
but
based
on
the
number
of
people
in
the
system.
H
You're
on
sananda
I,
just
like
to
add
to
what
Jim
stated
here,
that
the
change
in
the
nonce
construction
actually
simplifies
to
review
to
make
sure
that
the
nonce
is
are
distinct
for
the
different
cases,
so
that
that's
actually
an
improvement
into
intro.
It
was
previously
version.
It
was
harder
to
sort
of
understand.
Ordinals
is
really
unique.
Now
it's
very
clear
because
the
nonce
is
constructed
by
by
the
entity
sending
so
it's
always
one
one
entity
which
is
clearly
pointed
out,
so
I
think
that's
that
that
comment
would
apply
better
to
the
previous
version.
O
H
A
F
P
A
So
maybe,
as
an
introduction
to
the
next
item
in
prod,
we
had
an
in-room
consensus
for
adopting
the
document,
but
given
to
some
discussions
in
the
security
area,
we
didn't
act
on
this
consensus
and
since
we
mutually
we
can
check
do
we
have
new
information.
That
would
maybe
speak
against
the
consensus.
We
have
in
fact,
so.
Q
Go
ahead
thank
market
and
I.
Six.
Few
updates
on
this.
We
have
submitted
just
before
kind
of
a
new
version,
now
version
for
a
lot
of
Victoria
anything's,
mostly
to
improve
readability
of
this
document,
like
a
lot
of
details
were
removed
as
a
penances
section,
especially
as
do
initialization
of
new
endpoints
handling
and
provisioning
of
public
keys
and
approaches
for
hanging
with
synchronization
sequence,
numbers
and
synchronization
is
thought
to
be
lost,
plus
is,
of
course,
already
aligned
with
the
latest
score
that
Francesca
just
presented.
Q
A
G
H
So
I
like
to
explain
this,
this
is
not
easy
to
understand.
Always
so.
Basically,
the
setting
is
in
this
group
we're
working
on
a
communication
security
protocol
which
applies
the
unicast
as
well
as
Malik
multicasts
in
ace,
we're
working
on
a
key
distribution
mechanism,
so
that's
providing
the
keys
for
the
different
devices
in
the
in
the
multicast
web.
So
that's
the
difference.
K
H
H
So
so
this
draft
provides
that
maybe
the
author
wants
to
answer
yes
mark.
Oh
yeah,
okay,
I
can
take
the
answer,
so
maybe
the
presenter
one.
So
this
draft
provides
a
solution
for
multicast
security,
which
is
based
on
adding
a
signature
to
a
cozy
object.
It's
the
counter
signature
field
which
yet
so,
if
you
have
the
counter
signature
field,
then
you
can
verify
so
you
have
source
origins.
We
can
actually
verify
from
which
you
entity
this
the
mess.
H
This
multicast
message
was
sent
and
there
is
a
bit
indicating
whether
this
multicast
well,
the
signature
is
included
in
the
message
or
not
so
in
principle.
You
could
set
that
bit
to
zero
and
not
include
the
counter
signature,
in
which
case
this
would
be
the
symmetric
only
setting,
so
it
actually
includes
the
solution
includes
both
symmetric
and
asymmetric
and
depending
on
whether
you
set
it
bit.
Add
the
counter
signature.
You
get
sort
of
authentication
or
not
so.
G
A
A
Mike
so
now
I
press
this
button
once.
A
S
Status
is
basically
the
same
as
it
was
when
we,
when
we
presented
this
in
Prague,
there's
no
substantial
work
done
on
a
draft.
Unfortunately,
we
were,
we
were
busy
with
other
things,
but
basically
I'll
treat
the
status.
There's
been
no
substantial
changes
since,
since
working
group
adoption
we,
we
were
not
adding
anything
to
the
protocol
very
simple
and
we
dressed
instead
of
comment
or
we're
in
the
process
of
addressing
a
substantial
set
of
comments
that
we
got
before
the
next
update.
But
we
don't
have
the
next
update
ready
at
this
time.
S
S
We
discovered
that
we
wanted
to
really
be
careful
about
the
normative
language
so
that
we
could
generate
test
cases
and
not
have
a
bunch
of
spurious
requirements
that
weren't
important.
So
we
need
to
go
through
that
and
since
we
have
a
good
security
model
now,
I
think
with
the
with
the
pub/sub
profile.
S
An
OS
OS
core
pub/sub
profile
I
think
will
incorporate
some
specific
guidance
around
that
use
of
that
profile
and
I
do
have
a
little
bit
of
feedback
on
that.
Also
that,
in
light
of
this,
so
we're
still
targeting
you
know-
will
revise
this
so
three
review
and
we'll
expect
to
have
something
that
we
can
target
for
working
group
last
call
on
that
around
that
time
frame.
So
I
guess
we're
looking
at
still
trying
to
get
something
meaningful
then
before
the
next
London
would
it
be,
but
that's
that's
basically,
the
time
training
now
I.
S
S
S
A
J
A
B
S
A
But
as
you
well
know,
we
should
agree
that
that
this
is
kind
of
stable.
Do
we
think
this
is
going
to
continue
to
look
like
this?
Of
course,
it's
modeled
after
the
HTTP
429
code,
which
is
well
established,
so
it's
not
like.
We
are
completely
inventing
this,
but
maybe
there
are
specific
considerations
we
should
think
about
before
going
that
with
a
registration
and
the
text
that
goes
with
it.
I
I
I
don't
know
if
it
was
on
behalf
of
ocf
or
not,
but
in
any
case
the
point
is
a
bunch
of
product
developers
want
to
use
4:29
potentially
outside
the
scope
of
where
it's
a
resource
directory
all
right,
because
it's
too
many
requests
do
we
charge
directory
is
one
case
by
red.
This
is
saying:
maybe
it's
not
just
for
resource
directories,
and
so
there's
actually
another
implied
question
here
is:
what's
the
right
way
to
specify
it
is
specifying
it
in
the
same
document?
O
S
I
In
the
Rd
spec,
and
so
the
issue
is
that
reviewing
the
rest
of
the
Rd
spec
a
requires
all
the
other
stuff
that
we're
talking
about
what
people
want
to
use
it
sooner,
because
it
doesn't
have
to
depend
on
all
that
Rd
stuff,
and
so
the
question
is:
should
you
split
in
a
different
document
or
so?
My
other
comment
is
the
registration
process.
Response
codes
is
IHF
review
or
iesg
approval
and
there's
the
auratus
there.
K
I'm,
usually
don't,
like
you
know,
telling
editors
to
split
to
merge
documents,
but
in
this
case
I
think
especially
if
it's
a
generic
thing
putting
it
and
separate
document
and
it's
relatively
simple:
it
can
be
progressed
early
and
once
it's
stable,
then
working
group
chairs,
request
me
and
I.
Take
it
twice:
G
duo,
location.
N
I
Because
it's
up
to
you
as
the
80
in
technically
at
the
is
G
as
a
whole
right
but
they're
going
to
look
to
you
for
recommendation
as
to
whether
it
requires
a
specification
or
not.
That's
your
call.
You
should
have
feedback
from
the
community
to
make
that
call,
so
you
could
say
we're
going
to
early
register
it
and
keep
it
in
the
same
document.
Let
it
appear
in
the
RFC
when
the
Rd
one
comes
out.
That
is
a
valid
option
to
your
choice.
I
Another
option
would
be
to
say
spit
it
into
a
separate
document,
because
you
want
there
to
be
a
document.
You
can
progress
it
earlier
and
then
it's
not
an
iesg
approval.
It's
just
regular
IETF
review,
or
it's
probably
to
a
couple
other
things.
But
the
point
is
it:
there
really
is
flexibility
here
as
far
as
what
the
process
is
and
it's
between
the
working
group
and
the
ad
and
the
iesg
to
decide
and
the
request
is
they
just
want
to
have
it
up
here?
I
Is
IETF
review
or
iesg
approval,
and
so
the
iesg
approval
path
is
saying.
Alexi
on
behalf
of
the
isg
sends
email
to
Ayana
said
it
is
okay
to
ahead
this
one
up
here
in
the
registry
prior
to
there
being
an
RFC
right
and
the
guidelines
for
and
a
consideration
section
RFC
talks
about
what
the
requirements
are
for
iesg
approval,
but
I
give
you
the
clifftop
as
a
person
just
now
you.
K
I
K
S
C
Or
to
get
on
an
yeah,
separate
document,
it's
perfectly
we
were
when
we
were
designing
it.
We
deciding
to
be
generate
to
begin
with.
It
was
just
easier
part
of
this
government
as
separate
aniseh
separately.
To
start
with,
and
one
clarification
is
the
pops
up
document
there.
It
is
not
the
RT
document,
so
if
anyone
is
looking
for
it,
it's
in
that
so
yeah
we
are
happy
to
split
it
and
as
long
as
it
progresses
fast
enough.
E
Dave,
Robin
and
I
see
a
Peter
vendor
stock
right
behind
me,
I
was
maybe
I'm
thinking
the
same
thing.
His
his
suggested
change
seems
like
it
could
be
combined
with
this
I'm
thinking.
Actually,
aren't
we
missing
302,
which
seems
to
actually
fit
with
what
Peter
would
wanting
it
says.
I
do
a
get
I
get
a
3.0
to
move
door
with
a
location
header
it's
over
there.
That
seems
to
be
traditional,
HTTP
stuff,
but
3.0
to
is
not
in
core.
Yes,.
E
So,
for
a
good
reason:
okay-
well
anyway-
maybe
I'll
just
stop
right
there,
because
I
was
going
to
suggest
we
take
302
and
429
and
maybe
some
others
and
throw
them
in
a
document
and
have
additions
the
same
way.
They
had
an
RFC
that
added
like
five.
You
know
new
status
go
to
http
way
back
when
yeah,
but
I'm
sure
you're
going
to
tell
us
what
the
good
react
so.
A
A
C
D
A
A
R
Oh
I
would
like
to
talk
about
I
couldn't
request
tech.
This
is
a
slide
please.
R
We
people
took
them
to
be
one
document
about
the
options
and
one
about
the
problem
statement
and
the
possible
attacks
that
need
to
be
taken
into
consideration
and
present
at
the
relevant
text
there
and
how
those
options
can
be
used
in
that
we're
the
devices
as
we
used
to
it
very
constrained,
maybe
doesn't
have
a
clock
and
ask
for
alternative
approaches
and
back
then
a
slide.
Please,
we've
heard
the
feedback
from
them
and
renamed.
R
R
The
document
was
taken
up
by
Oscar.
Also
Oscar
now
uses
both
options
where
it
needs
them,
and
we've
been
asked
to
upload
this
the
last
version,
as
as
a
working
group
document
which,
which
nowadays
the
mechanisms
that
are
there
so
how
things
work
are
I,
think
flashed
up
and
out.
So
these
are
functional
our
next
slide,
please
what
still
needs
some
work
is
how
we
phrase
them,
so
the
echo
part
will
undergo
a
bit
of
a
rewording
in
an
in
a
future
upload
and
there
are
various
other
editorial
fixes.
R
We
need
to
do
and
peaking
ahead
to
the
next
presentation
about
delay,
attacks.
I
think
there
is
some
valid
criticism,
we'll
need
to
respond
to
from
there
or
with
respect
to
how
easy
it
is
to
to
come
up
with
a
with
a
time
that
is
suitable
for
keeping
around
for
waiting
for
an
updated
response
to
an
echo
request.
R
O
Some
more
I
was
planning
to
some
more
structure,
clearer
requirements.
What
it's?
What
has
to
be
making
take
apart
pack,
making
clear
that
the
client
does
not
look
at
that.
Just
equate
making
it
clear
what
requirements
it
put
on
the
server
when
it's
great
the
echo
and
then
putting
forward.
These
are
two
example
and
recommended
ways
to
do
it.
Thank.
R
So
each
each
application
has
particular
freshness
requirements
which
maybe
it
should
have
arrived
within
the
last
minute.
It
should
be
fresh
by
a
few
minutes
or
which
might
be.
This
needs
to
be
very
strictly
timed
and
I
can't
accept
any
requests,
that's
older
than
two
seconds
and
the
application
need
to
to
take
that
decision
and,
if
forwarded
to
what
and
you
instruct
the
the
underlying
library
or
whatever,
to
act
on
that.
T
Okay,
hello,
my
name
is
Julian
from
our
way
and
yeah.
This
proposal
comes
from
the
question.
I
just
asked:
when
I
read
a
document
yeah,
let's
go
to
next,
each
okay,
these
older
versions
repeat
option.
What
confuses
me
is
that
how
to
set
the
threshold
because
I
think
it's
more
important
or
the
threshold
is
an
element
in
the
comparison.
J
J
T
Mechanism
and
if
we
set
it
to
large
and
I,
think
some
of
the
delay
at
our
delays
may
not
be
discovers.
So
so
that's
the
the
main
things
that
confuses
me
so
I.
We
propose
another
mechanism
to
resolve
that
way.
I'd
have
issue
way
that
we,
this
the
client,
sends
the
valid
term
window
in
the
message,
ended
to
the
with
a
server
and
which
contained
a
start
start
time
and
the
time
duration.
T
T
We
say
in
his
messages,
but
in
the
time
window,
then
in
May
it
maybe
act
immediately,
but
if
it
isn't
received
after
the
time
window,
it
may
be
discarded,
and
this
is
for
the
single
message,
requests
or
requests
and
in
some
cases
we,
for
example,
in
the
AGV
automatic
guided
vehicle
situates
and
the
AGV.
We
got
many
multiple
messages
that
h
can
only
I
mean
work
under
one
requests,
a
request,
and
so
it
has
to
process
the
requests
one
by
one
in
a
sequential
mode.
T
J
T
E
H
I
think
that
the
problem
statements,
you're
looking
at
is
slightly
different
from
the
ones
which
are
in
in
the
echo
draft
or
in
the
problem
statement
is
rather
in
the
actor
gesture.
But
the
solution
is
the
echo
solution
and
I
think
that
we
actually
need
both
type
of
mechanisms.
One
one
nonce
based
and
runtime,
based
yeah.
T
H
That's
that's
my
my
first
comment.
The
second
comment
is
that
there
is
not
so
much
coverage
on
the
use
cases
in
document
you
mentioned
now.
A
use
case
which
is
not
mentioned
in
in
the
document,
so
I
think,
would
be
good.
If
you
could
expand
on
the
use
cases
and
what
different
modes
you
would
need
and
what
situations.
So
it's
much.
H
H
How
much
of
this
should
be
specified
in
core
and
how
much
is
application
dependent?
We
actually
had
the
same
question
when
it
came
to
echo.
There
were
a
number
of
different
variants
and
adding
features
and
so
on,
but
we
basically
cut
them
down.
I
mean
it's
now.
Essentially
it's
an
ons
going
back
and
forth.
That's
the
only
thing
we
specifying
core.
So
that's
things
to
consider.
I
I
couldn't
tell
from
the
presentation
or
from
the
draft,
but
I
was
guessing.
That
was
the
case,
and
so,
if
that's
the
case,
then
you
should
say
that
explicitly
and
then
in
your
security
considerations,
you
probably
also
want
to
have
text
about
a
dependency
on
a
secure
source
of
absolute
time.
Okay,.
R
R
T
A
So
it
seems
to
me
that
there
has
been
some
some
good
feedback
on
this
draft.
It's
not
yet
entirely
clear
what
what
the
use
cases
are.
I
think
it
would
be
good
to
work
a
little
bit
on
that
and
I
think.
The
observation
about
this
whole
freshness
area
was
this
is
a
an
area
that
needs
to
be
controlled
by
the
application
and
with
the
Ecotech
we
just
have
with
the
ICO
option.
A
We
just
have
found
one
place
where,
where
we
have
common
behavior
for
many
applications
that
we
can
factor
out
in
into
a
co-op
option,
so
what
what
I
would
like
to
see
in
the
next
version,
maybe
of
this
document
is,
can
we
arrive
at
some
common
behavior
that
multiple
applications
would
want
to
use?
Because,
right
now
it
did
there's
a
lot
of
things
in
there,
but
it's
it's
more
more
of
a
shopping
list,
then
then
concise
thing
that
we
would
want
to
have
an
option.
H
H
A
A
A
A
U
U
They
utilize
for
SMS
a
WAP
what
they
call
WAP
Push,
it's
oh
it's
through
the
3gpp,
I
think
WAP
mechanism.
So
it's
called
WAP
Push
is
the
proto
Papas
protocol
pushes
the
extension
to
the
protocol.
Okay,
so
they've
already,
so
they
progressed
and
solve
their
problem
right.
So
there's
nothing
here
that
I
Jeff
needs
to
solve
for
them.
It's
my
point.
V
I
can
comment
that
a
couple
of
weeks
ago,
a
couple
of
weeks
ago,
in
the
Omaha
meeting.
Actually
there
was
an
interesting
demo
by
one
of
the
companies
there.
Av
systems
and
I
got
actually
a
commitment
in
a
sense
to
contribute
to
the
draft
to
make
it
aligned
with
Leviton
to
him
one
way
or
another
to
commit
with
these
draft
from
one
of
the
AV
systems,
guys
I'm.
U
V
What
I'm
saying
is
that
some
of
the
features
that
the
Levitan
boom
has
already
for
co-op
over
SMS
could
be
adopted
in
this
draft
or
vice
versa,
but
they
could
be
aligned.
I
already
have
a
commitment
from
one
of
the
guys
in
AV
systems
that
he's
participating
in
OMA,
DM
and
I
wouldn't
whim
to
do
that.
Sure.
U
V
A
W
W
Okay,
let
me
let
me
just
yeah
yeah,
it's
okay,
I'll
just
end
this
way,
it's
fine
yeah,
look
at
this
one
okay,
so
both
these
drops
I
think
are
in
pretty
good
shape.
Basically,
I
would
say
that
there
are
some
editorial
issues
that
need
to
be
fixed.
W
There
have
been
so
if
you
use
the
issue,
we
are
using
the
issue
tracker
in
Indian
hub,
so
there
are
some
minor
issues
to
be
fixed,
I.
Think
in
the
interfaces
draft
at
least
a
couple
of
them
have
been
opened
since
the
last
version,
and
there
are
two
new
ones.
One
is
basically
to
align
the
examples
with
what's
happening
with
sin
ml
and
then
the
other
one
that
Michael
raised
was
regarding
some
consistency
with
the
ocf
interface
pattern
or
for
using
the
the
interface
link
target
attribute
and
for
dynamic
links.
W
We
switched
back
after
Tim
brought
up
the
problem
of
G
th
and
L
th
to
GT
and
L
T,
so
that
it's
smaller
line
with
labrum
to
him
and
again
going
forward.
Probably
this
one
needs
a
lot
of
editorial
work,
then
interfaces.
So
the
examples
need
to
be
made
much
clearer.
There's
four
open
issues
and
all
of
them
need
to
be
resolved,
so
two
two
of
them
are
actually
on
absorbing
some
work
done
in
two
drafts.
W
A
Yeah,
so
these
are
interesting
documents,
because
the
diverse
other
that
sometimes
and
then
other
s
Theo's,
took
their
content
and
did
something
with
it
with
that
which
is
good,
but
we
never
really
finished
them.
So
we
are
now
in
this
situation
that
we
have
to
look
at.
What
did
the
other
people
do
there,
which
is,
for
instance,
the
reason
why
this
reversal?
There
was
done
because,
like
we
don't
have
already.
J
A
Find
it
in
a
different
way,
so
this
is
a
little
bit
yes,
yes,
yes,
so
that
change
they
would
have
been
would
have
had
to
be
a
really
good
reason
to
make
this
change
to
make
it
uncomfortable
what
latter
a
time
dream
does
so,
given
that
we
are
picking
up
speed
now,
who
would
would
be
willing
to
review
new
versions
of
this
document?
Honest.
A
W
A
A
X
Okay,
so
if
you
were
in
the
meeting
last
time,
we
talked
about
the
background
for
this,
so
this
draft
had
been
around
for
a
bit,
but
it
is
really
widely
used.
I
understand
and
their
idea
is
basically
just
to
support
various
kinds
of
device.
Identifiers
and-
and
of
course,
you
need
to
be
aware
when,
when
it
makes
sense
to
use
device
identifier
to
begin
with,
so
there
are
some
cases
where
that
makes
a
lot
of
sense
and
some
cases
where
you
probably
want
to
hide
things
instead
of
using
the
device
identifier.
X
Device
like
the
humidity
sensor,
part
of
a
particular
1-wire
devices
in
this
example,
and
which
st.
changed
the
syntax
from
using
semicolons
to
using
underscores,
and
the
reason
for
this
change
was.
Maybe
we
can
make
the
integration
with
sentimental
easier,
because
in
ml
does
require
some
limits
in
the
character
set,
and
we
we
have
gotten
some
feedback
that
you
know.
Maybe
the
the
character
here
is.
It
could
be
some
other
character
as
well,
like
slash,
would
solicit
feedback
on
that
in
a
bit.
X
The
other
change
was
that
we
added
something
called
organization
specific
device
identifier,
so
this
is
an
idea
to
open
up
the
space
a
little
bit.
So
if
you
had
a
company
or
some
kind
of
organization
that
needed
to
support
their
own
device
identifiers,
you
could
do
that
relatively
easily
without
having
to
specify
a
new
AR
see
and
the
particular
way
we
went
about.
That
was
the
point
to
private
enterprise
numbers.
X
So
here
you
are
in
dev
org
and
then
a
private
enterprise
number
32
473
is
actually
that
example,
enterprise
number
and
then
one
two,
three
four
five
six
would
be
the
device
identifier
in
this
case.
We
also
considered
using
domain
names
here,
that's
another
option,
but
again
soliciting
feedback
on
whether
this
makes
sense.
X
X
Do
you
have
any
thoughts
on
the
local
device
identifiers?
Is
that
a
good
thing?
Bad
thing
should
be
done
in
this
way
or
some
other
way.
Let
us
know,
and
then
I've
also
got
some
email
from
some
Nokia
folks,
that's
right
there
here
that
indicated
that
1m
2m
and
a
lightweight
m3m
have
some
have
been
using
some
device
identifier
types
already
in
their
specifications.
X
Should
those
be
folded
in-
and
there
was
a
question
about
a
but
I-
know
nothing
about
the
BBF
probe
and
four-room
USB
protocol,
as
my
identifiers
perhaps
be
used
incorporated
here,
I
mean
the
obviously.
The
idea
is
that
you
know
if
we
do
something,
that's
sort
of
a
friendly
amendment
of
of
this
specification
and
then
with
you
know,
some
coordination
of
the
people
who
actually
came
up
with
these
ideas,
Peter
sent
under
complaint
that
we
haven't
done
the
new
RCN
that
associated
new.
X
B
I
Taylor
so
I
looked
at
this
last
IETF,
but
not
since,
and
so
you
may
have
to
remind
me,
but
my
question
is
on
the
the
the
delimiter
part,
something
you
said
triggered
my
comment
on
the
last
slide.
You
said
that
something
about
the
humidity
part
of
a
device
and
that's
where
I
got
lost.
Is
this
a
device
identifier
or
is
this
a
resource
identifier
or
what?
Because
if
we
could
say
we
if
it's
a
device
identifier,
then
part
of
but
the
advice
doesn't
make
sense.
I
I
X
I
X
There
was
some
very
concrete
I
I
can
provide
concrete
examples.
I
don't
know
what
other
having
in
their
mind,
but
the
concrete
example
that
I
had.
For
instance,
some
of
my
devices
were
ones
where
you
had
actually
like
multiple
like
it
was
one
physical
box
with
one
physical
network
interface
number,
but
it
actually
had
two
separate
circuits
in
it.
X
X
U
J
U
U
We
actually
use
the
the
the
PE
n
to
me
to
make
to
make
it
a
private
private
enterprise
number
versus
a
no
UI
versus
whatever.
So
we
were
very
clear
on
exactly
what
was
gonna
be
the
format.
Is
it's
going
to
be
a
private
enterprise
number,
or
is
it
going
to
be
a
no
UI
or
whatever
so
we're
kind
of
clear?
We
just
didn't
use
a
you
know,
kind
of
like
the
board
type
of
thing.
You
know
where
you
were
you
weren't
really
sure
what
what
it
really
is.
Gonna
comprise
up
right.
So.
G
J
V
O
X
X
U
X
I
Thank
you.
So
the
subsequent
discussion,
including
your
response,
maybe
realize
there's
a
different
question.
That
I
should
ask
because
I
thought
I
said:
I
got
the,
but
I
got
the
use
case
for
a
device
identifier
and
then
I
realized,
there's
that
that's
actually
an
ambiguous
statement,
because
what
different
orgs
call
it
device
varies,
and
so
to
some
organizations
that
device
is
the
physical
thing
and
to
other
organizations.
A
device
is
a
particular
role
that
may
run
on
that
physical
thing.
I
So
in
the
ocf
terminology,
for
example,
they
caught
they
use
the
word
platform
to
refer
to
you,
the
thing,
that's
that
the
physical
thing
and
it
can
have
multiple
devices
installed
on
it.
You
know
the
the
humidity
device
and
the
device
is
something
that
refers
to
like
a
a
model
of
what
a
device
is
and
if
it
has
multiple
so
device
models
and
there's
one
platform
local
vices
on
it,
and
so
the
term
device
itself
is
also
ambiguous.
I
Internet
generic
sensors.
We
really
have
to
define
what
it
is
that
we're
talking
about
cuz
I,
think
you're
talking
about
a
device
in
the
same
sense
as
say
ocf
uses
and
not
the
physical
object
when
you
said
part
of
a
device
right.
That
might
be
how
how
ocf
might
describe
part
of
a
platform
when
they
talking
about
it,
the
term
device,
and
so
it's
quite
possible
that
what
you
mean
is
that
device
ID
in
the
same
sense
is
what
ocf
would
call
a
device
ID
which
is
as
a
normal
developer.
I
Specific,
you
know,
URI
scheme,
like
ocf,
has
their
own
URI
scheme
that
they
embed
a
device
ID
in
the
same
sense
that
you're
talking
about
right,
but
they
do
it
in
their
own
ecosystem,
stuff,
that's
OCF,
Khoa,
okay
and
so
I
guess.
The
question
is:
what
is
the
use
case
here
if
the
use
case
is
coming
from
one
end,
M
and
lightweight
M
to
M,
then
the
two
possible
answers
are.
I
U
So
from
the
from
the
one
M
dam
in
a
light
way
to
M
to
M
perspective,
it's
going
to
it's
going
to
be
an
identify
er
from
the
one
end
Empress
perspective,
it's
the
actual
identifier,
which
you
would
call
a
platform,
okay
for
a
lightweight
MDM.
It's
actually
identified
that
is
used
as
the
endpoint
identifier
of
the
lightweight
end
M
client
right,
so
you
know,
can
be
the
I.
Am
I
I
MSI
and
other
type
of
your
ends,
but
sometimes.
J
U
X
U
X
You
know
whatever
their
they're
doing
so
we're
trying
to
protract
what
the
idea
usually
does
provide
a
capability
to
point
to
put
particular
types
of
identifiers
for
which
there
is
no
convenient
identifiers.
At
this.
This
point
in
other
ways,
and
then
the
only
discussion
we're
really
having
is
is
a
terminology
and
and
B
whether
whether
we're
doing
those
additional
pieces
after
pointing
to
the
hardware,
identifier
and.
I
X
Yeah
I
mean
the
the
delimiters
and
the
parameter
is
so
all
the
there
it's
it's
up
up
up
to.
You
know
whoever
is
applying
this,
whether
really
they
get
to
use
them
or
they
need
to
use
those
or
not,
but
but
the
general
soon
box
was
the
question
here.
So
if
we
have
something
like
that,
this,
then
you
know
what
characters
are
allowed
there
and
how
does
that
affect
users
of
this
soon
box
on
a
higher
level,
so
that
that
that
was
they
initially
this?
I
Mean
I
understand,
you're,
creating
this
sort
of
enough
hierarchy
is
the
right
term,
but
so
your
n,
followed
by
dev,
followed
by
something
identifies
what
the
next
identifier
is.
You
know
Mac
or
whatever
it
is,
and
so
maybe
there's
multiple
possible
answer
is
one.
If
you
say
it's
Mac
and
what
if
say
it's
a
one
of
the
other
options
are
or
on
there
and
there
could
be
a
different
answer
for
each
of
those
if
it's
a
yeah
all
of
the
above
for
different
purposes,
which
is
okay.
I
Why
would
you
do
that
in
the
same
URI
scheme,
but
you
can
sure
what
I
actually
got
up
Mikey
I
just
remember
it
was
what
get
back
there,
like
you
mentioned
that
if
I
understand
right
when
you
talked
about
the
hardware
identifiers,
there's
actually
an
important
thing
that
you
didn't
put
there,
that's
consistent
with
what
you
just
said,
which
is
you
didn't
say
it
was
unique
right.
This
is
not
the
only
identifier.
I
So
if
you
have
something
with
two
MAC
addresses,
you
actually
have
to
you
our
ends
for
the
same
platform
right
and
that's
perfectly
fine
all
right
according
to
this
definition
right
because
a
hardware
identifier
does
not
mean
that
there's
only
one
hardware,
identifier
for
that
device,
you've
got
a
MAC
address
and
those
other
things,
and
sometimes
you
have
multiple
MAC
addresses
and
so
on.
This
is
one
or
more
aliases
for
that
same
device.
There
are
each
some
definition
of
device
or
platform
or
thingy
identifier
right.
C
Maybe
one
more
important
to
you,
so
I
gotta
get
an
ISO
one
use
of
the
component
part
that
there
was.
It
was
more
about
grouping,
for
example,
sensors
of
a
device.
So
then,
in
that
part
of
the
use
case
it
doesn't
necessarily
have
to
be-
and
this
was
in
sentinel
context,
so
in
that
use
case
I
mean
sentiment
will
also
define
you
can
get
the
unique
part
that
you
are
in
itself
and
then
use
some
something
else,
but
overall
I've
seen
that's
a
useful
uses
for
that.
C
C
I
Of
the
clarifying
question
about
current
deployment,
because
people
said
parts
of
this
are
already
being
used
in
like
when
I'm
dam
or
lightweight
in
them
out
of
the
different
variations
that
Gary
showed,
we
can
have
different
types
of
identifiers,
you
know
MAC
address
and
so
on
and
so
forth,
or
all
of
them
in
use,
or
only
some
of
those
in
use.
Today,
with
this,
you
are
in
scheme.
If
you
go
back
a
slide
or
whatever
you
see
the
list,
it
was
like
three
of
them,
I
just
can't
remember,
which
ones
they
were
yeah
there.
I
I
X
I
Reason
I'm
asking
is:
if
there's
already
deployment?
Ok,
then
you
can
say
there's
a
valid
justification
that
says
we
don't
care
about
back
or
we
care
about
backwards,
compatibility
right,
it's
like
the
delimiter
case
or
whatever
for
cases
that
are
not
deployed.
Then
such
a
question
is
not
important
and
you
could
even
ask
well.
X
V
Since
you
are
commenting
on
Levitan
to
emily
team
or
Hanna's
can
correct
me
if
I'm
wrong
or
if
you
can
add
additions.
As
far
as
I
know,
the
UUID
was
the
overarching
way
to
identify
endpoints
and
then
within
it
you
have
different
URLs,
depending
if
you
are
using
peer,
69
or
I'm
emails
or
m/c
or
other
way
to
identify
the
device.
The
only
case
as
far
as
I
know
on
depth
is
for
the
tier
69
case,
but
I
might
be
mistaken
in.
G
Right,
so
it's
really!
This
is
honest,
so
it
really
depends
what
type
of
devices
you
have
and
how
you,
how
you
can
best
identify
them,
uniquely
in
your
in
your
environment.
Obviously
those
who
work
more
in
the
cellular
space.
They
do
what
Tim
just
said
and
we,
for
example,
we
use
you
IDs
for
for
the
most
generic
case,
because
you
know,
if
you
have,
let's
say
a
Wi-Fi
device,
Bluetooth,
etc
anything
that
sort
of
just
connected
to
the
Internet.
Then,
obviously,
where
would
you
get
the
IMEI
from
so
so
you
use
UID,
that's
stuff.
X
But
it
okay,
so
it
just
wanted
to
point
out
one
thing,
also
an
OBE
service,
and
so
we
have
a
draft
that
is
not
an
RFC.
Yet
that
defines
this
dev
scheme
and
there
are
other
organizations
in
the
world
that
are
allocating
already
things
under
the
dev
scheme.
It's
you
know.
Maybe
we
should
get
this
registered
in
the
Ayana
and
you
know
the
RFC
out
and
all
that
pretty
soon
so.
A
From
the
discussion,
it
seems
to
be
pretty
clear
to
me
that
we
do
have
the
energy
to
work
on
this,
so
I
think
we
should
verify
this
on
the
mailing
list
and
adopt
this
as
a
draft,
but
in
parallel
continue
with
the
information
collection.
So
we
have
all
these
various
parts
that
have
been
have
come
up
here
and
we
need
to
pull
them
together.
So
we
know
what
the
picture
out
there.
A
C
Hey
it's
the
first
time
to
talk
about
our
draft
draft.
It
names
OPC
you,
a
message:
transmission,
mass
holdover
crop,
it's
jr.,
whoo.
First,
let's
talk
about
other
motivations.
Our
motivations
is
are
clear:
OPC
UA
is
a
data
exchanged
standard
that
provides
interoperability
in
industrial
automation.
Secondly,
utilizing
OPC
UA
transmitting
over
crop
could
meet
the
demand
for
industrial
4.0,
based
on
the
exchange
of
semantic
information.
Our
course
is,
example
to
achieve
different
ways
to
transmit
semantic
information
from
two
saviors
to
build
spaced
on
OPC
UA
over
crop.
C
First,
please,
let
me
introduce
what
is
OPC
UA
OPC,
unified
architecture
is
a
data
exchange
standard
for
safe,
reliable
manufacture
and
platform.
Independent
industrial
communication
ad
enables
data
exchange
between
between
products
from
different
manufacturers
and
across
operating
systems.
Opc
UA
has
a
lot
of
advantages.
First,
aid,
functional
equivalence:
it
builds
on
the
success
of
OPC
Class
A.
The
second
is
platform
independence
from
an
abandoned
backhoe
controller
to
cloud-based
the
infrastructure.
All
this
can
use
OPC
UA.
The
third
is
security.
C
Opc
UA
is
fair
for
friendly
we're
addressing
security
concerns
by
providing
a
suite
of
contrast,
the
last
acecomm
Hansa
V
Information
modelling
the
framework
terse
data
into
information.
This
is
the
protocol
stake
of
OPC
UA,
the
foundation
of
OPC
reissue
as
the
fundamental
companions
of
OPC
UA
are
transport
mechanisms
and
data
modelling.
The
transport
defines
different
mechanisms
optimized
for
different
use
case,
for
example.
If
you
want
good
speed
and
throughput,
you
could
use
you
a
TCP
with
you
a
binary.
If
you
want
it
would
be
a
fair
or
friendly,
you
could
use
HTTP
with
XML.
C
This
is
request
and
response
mode
of
OPC
UA.
A
serious
interactions
is
needed
to
needed
for
clients
to
connect
with
saviours
here
is
our
preliminary
walk.
We
designed
an
OPC
UA
compression
and
decompression
mechanism
for
6lowpan.
We
designed
an
an
OPC
receiver
for
wireless
devices.
Bios
Contiki,
we
integrated
a
cheapo
e8o
2.15
point
for
its
OPC
wave
for
low-power
wireless
sensor.
That
works
with
design
demands
nature
in
the
mechanism
with
OPC
UA.
Here
is
our
testing
plan
for
the
news
we
used
our
stm32
and
cy
2
for
2
o
RF
mode
o.
C
C
This
figure
shows
a
Kotecha
of
OPC
over
crop
in
sterilization
layer,
OPC,
UA
packets
are
inking
coated
in
as
a
you,
a
binary
and
you
XML,
and
the
option
field
in
the
Corp
header
can
subsidy
parameters
to
support
both
formats.
As
for
security,
detail
is
on
the
top
of
UDP
in
transport
layer
to
make
sure
the
whole
communications
working
in
the
security
mode.
C
We
designs,
3
transmission
schemes.
First
is
a
proxy
for
history
to
crop
in
history.
Message
is
exchanged
using
HTTP
or
TCP
crops.
Designs
is
last
inspiration,
meaning
comes
from
HTTP.
The
two
can
be
mapped
between
each
other
to
meet
some
special
sense,
so
we
put
a
HTTP
to
crop
proxy
as
a
boundary
of
the
network
to
transform
HTTP
requires
to
crop
request.
The
original
you,
a
clan
that
don't
need
to
change.
C
Second,
is
the
direct
transmission.
Opc,
a
packets
are
encoded
in
as
a
binary
or
exam
perform
it.
So
the
entire
packet
of
the
OPC
UA
can
be
deleted
up
a
lot
of
the
code
message
for
direct
transmission
notice
that
this
method
of
transmission
needs
to
be
modified
on
the
server
side
and
the
client
side.
C
The
third
one
is
dressed
transmission
for
OPC
UA.
The
traditional
PC
really
needs
a
series
of
interaction
interactions
to
establish
a
session
between
client
and
savior's.
This
scheme
reduce
the
interactions,
processing,
OPC,
UA
crop
request
and
response
can
carry
OPC
UA
information
model
to
achieve
communicating.
C
N
I
I'm
familiar
with
both
co-op
and
OPC
UA
and
have
written
code
for
both
them,
and
so
I
find
this
draft
extremely
interesting.
I
do
have
some
feedback
which
I
can
give
offline
or
whatever,
but
I,
think
the
question
I
have,
even
though
I'm
very
interested
in
I,
don't
know
right
offhand
what
the
use
case
is-
and
so
you
mentioned
that
on
your
last
slide-
is
when
would
you
run
OPC
UA
over
Co
AB,
given
if
they
already
have
OPC
UA
over
UDP,
okay
over
TCP,
where
we
have
Co
at
PCP?
I
So
what
specifically
is
the
use
case?
You're
trying
to
do
assuming
there's
a
good
use
case,
I'm
very
interested
in
this
I?
Don't
yet
know
what
the
use
case
is,
but,
like
I
said
that
I'm
tentatively
in
favor
of
this,
if
there's
a
reason
to
do
it,
which
is
what
I'm
trying
to
figure
out.
So
please
tell
me:
oh
thank.
I
We'll
make
some
use
cases
to
our
jobs
and
if
you
don't
have
the
answer
right
now,
that's
okay,
I'm,
saying
that
that's
what
I
would
be
looking
for
is
tell
me
a
good
use
case
and,
if
so,
I'm
willing
to
review
or
whatever
this
because
I
do
both.
The
an
example
of
a
technical
point
which
we
can
follow
up
on
later,
is
on
slide
130.
I
U
The
reason
why
I
asked
that
was
because
you
know
you're
doing
that
binding
of
the
upper
layer
and
you're
using
the
coop
as
a
transport,
which
is
perfectly
fine,
but
there's
nuances
to
that
protocol,
right
where
you
need
to
have
the
expertise
and
involved.
Now
thank
God.
You
got
you
know
someone
who's
got
some
expertise,
but.
I
E
E
Being
flippant,
but
what
I
mean
is
we
have
certain
lawsuits
for
requirements
or
whatever
we're
going
to
look
at
co-op
and
say?
Can
we
use
co-op
as
a
transport
for
back
net?
Yes
or
no
we're
gonna
come
to
you,
we're
gonna,
get
it
reviewed
whatever
just
like
we
did
with
with
ipv6
over
back
net
over
MSTP.
Well,
there
will
be
involvement,
but
most
of
the
brain
damage
for
specifying
the
mapping.
Then
that
will
be
done
in
back
net,
where
all
the
experts
are.
I
In
back
met,
I
still
love
seeing
a
presentation
here.
So
thank
you
for
doing
this.
It's
the
same
thing
as
like
I
was
doing
for
ocf
right
here
are
some
ass
from
ocf
here's.
The
way
ocf
is
planning
on
using,
say
the
the
URI
schemes.
Do
you
have
any
feedback
for
us
or
whatever?
When
we
talked
about
the
redirect
dish
mechanism,
you
have
any
feedback
for
us
having
the
liaison
stuff.
Even
if
it's
done
the
organization
is
very
valuable.
I
A
Y
C
Y
A
My
name
is
wrong:
tootin
I
will
talk
about
slow
reactive
devices,
but
can
be
connected
to
the
network.
So
when
I
talk
about
slow
reactive
device
is
a
device
that
cannot
talk
all
the
time.
For
example,
you
have
a
slot
network
on
you
have
slot,
but
not
there
not
very
often,
so
you
have
to
delay
your
transmission.
A
It
can
be
also
a
network
where
you
have
duty
cycle,
and
so
you
cannot
send
all
the
time,
because
you
have
to
keep
silence
if
B,
between
sending
or
in
the
example
I
I
gave
here,
is
that
you
have
some
receiving
window.
It's
been
that
you
can
receive
messages
only
after
sending
a
message
and
all
this
kind
of
network
introduced
delays
in
transmission.
So,
for
example,
here
we
have
a
device,
but
sorry
we
have
a
device
that
send
a
message
and
then
have
to
wait
a
long
time
before
receiving
an
answer.
F
A
Parameters
we
have
in
the
server
at
the
time.
We
keep
the
message,
ID
value,
to
avoid
duplicate
message
or
processing,
twice
a
duplicate
message,
so
we
will
have
trouble
if
we
want
to
add
here
a
generic
server
but
can
use
the
service
reaction
story,
reactive
devices
or
normal
devices.
So
we
need
a
way
to
inform
the
server
that
we
are
going
slow.
A
So
to
do
that,
what
we
propose
is
to
add
what
we
call
a
time,
scale:
option
that
will
say
how
long
the
message
ID
must
be
kept
by
the
server.
So
this
way
the
server
will
avoid
to
process
twice
the
duplicates.
So
the
idea
is
to
have
here
a
value,
but
we
put
in
seconds-
let's
say:
I
will
send
this
me.
Saij
must
be
kept
for
a
period
of
time,
this
period
of
time
into
the
server.
So
here
the
design
is
not
good,
so
I
need
your
help
to
do
it.
A
So
I
think
it
must
be
a
critical
option
to
inform
the
client,
but
if
the
server
doesn't
process
it
and
there
is
an
error
and
you
have
to
change
its
behavior
and
of
course
we
don't
need.
Caching,
for
for
this
so
far
as
a
security
I
think
it's
also
a
way
to
improve
security,
because
it's
the
kind
of
guarantee,
if
you
say
message,
but
must
be
kept
one
hour.
A
L
So
like,
even
if,
even
if
you
said
that
it
doesn't
increase
the
number
of
messages,
it
still
utilizes
resources
at
the
server
by
making
it
keep
things
in
the
memory
and
like
if
I
could
send
many
of
these
I
will
still
use
up
a
lot
lot
of
the
memory
and,
like
you
would
not
accept
so
you
would
anyways
authenticate
the
client
right.
You
have
some
information
of
the
client.
You
just
don't
start
like
interacting
with
anyone
on
the
internet.
You
the
first
thing
you
do.
Is
you
authenticate?
L
A
G
Hi
this
is:
how
could
you
get
back
to
the
to
the
drawing
the
figure
please
so
so
the
option
indicates
on
how
a
when
the
device
will
expect
to
be
transmitting
messages.
Again.
Is
that
fair
to
say
no,
like
I'm,
trying
to
understand
the
figure
here
that
we
see
in
front
of
us.
A
A
G
The
fact
that
you
actually
in
a
network
that
has
exhibits
that
behavior,
it's
not
going
to
be
changing
at
the
level
of
each
individual
co-op
message.
So
you're
not
going
to
send
that
information
with
every
co-op
message.
That
would
be
a
waste.
Instead,
you
send
it
during
registration
once
and
then
the
infrastructure
takes
care
of
it.
So
I'm
trying
to
maybe
I
need
to
do
a
little
bit
more
like
comparison
now
so
I
don't
know
if
you've
ever
looked
at.
G
R
Hello
just
announces:
could
you
go
two
slides
forward
to
the
time
scale
option
Thanks
I
think
you
should
be
careful
to
consider
the
case
of
crux
is
here,
even
if
they
are
not
sleeping
proxies,
because
what
this
is
proposing
is
a
mechanism
on
message,
ID
level,
and
this
terminates
on
the
proxy.
So
this
shouldn't
be
an
option
that
could
just
before
water
through
the
proxy,
because
the
end,
the
the
client
doesn't
actually
need
to
know
about
the
oddities
of
that
end
point.