►
From YouTube: IETF103-CORE-20181105-1350
Description
CORE meeting session at IETF103
2018/11/05 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
B
Okay,
thank
you.
Yeah
I'm
used
to
two
computers
with
keyboard,
so
I
don't
know
how
to
press
these
buttons
on
the
screen
yeah.
So
this
is
an
ITF
meeting.
We
assume
people
have
read
the
draft
and
you
should
be
aware
of
the
so-called
IPR
principles
and
all
the
other
principles
that
apply,
and
these
are
all
summarized
in
a
note
well-
that
we
no
longer
seem
to
get
with
our
materials.
B
I,
don't
know
how
that
works,
but
just
read
this
quickly
and
then
you
will
know
what
applies
to
you
and
in
particular,
if
you
know
about
claims
that
might
apply
to
something
you
want
to
talk
about,
you
can
always
shut
up
and
not
talk
us
about
talk
about
it
or
tell
us
about
it.
These
are
the
true
choices.
B
Okay,
the
agenda
is
a
little
bit
jumbled
up
at
the
moment,
because
it's
Monday
very
early
morning
in
Europe,
and
so
people
have
not
been
submitting
things
and
so
on.
So
we
will
see
how
we
get
through
this.
So
we
have
reshuffled
this
a
little
bit
and
I'm
will
need
to
check
that
we
do
this
in
the
right
order.
B
B
B
C
B
B
So
the
main
difference
is
that
coral
is
really
optimized
to
be
used
on
small
devices
and
that
a
coral
also
can
much
easier.
Carry
additional
information
that
with
links
Jason,
we
still
have
to
somehow
fudge
into
link
format,
style
target
attributes.
So
it's
a
much
more
flexible
way
of
doing
things,
but
of
course,
flexibility
always
has
a
price.
B
B
Any
other
question
I
should
ask
at
this
point:
yeah
probably
I
should
ask
if,
if
color
is
the
thing
we
want
to
go
with,
who
would
be
willing
to
provide
reviews
of
this
document?
Jim
re
primer
Matias,
so
the
euro
suspects
Christian,
but
okay.
So
we
do
have
some
some
support
for
working
on
this
reduction.
B
Okay,
anything
else
we
want
to
discuss
on
this
I
would
propose
to
take
you
to
the
list
from
here.
So
then,
the
next
step
for
me
would
be
to
go
for
workgroup
adoption
to
do
a
working
of
adoption
call
for
the
coil
document,
because
that's
the
obvious,
like
next
step.
If
we
want
to
pull
this
in,
thank
you
can
use
the
microphone.
D
B
B
B
B
So
it's
bridging
between
this
working
group
and
the
transport
area,
maria
volunteered,
to
be
the
ad
here
and
we
got
some
great
feedback
and
and
generated
a
new
version
to
show
three
and
in
London
we
actually
found
out
there.
There
seems
to
be
some
potential
for
misunderstanding.
The
document
and
said
as
it
is
I
have
to
report
that
we
still
have
not
resolved
this.
So
we
ran
out
of
time
in
Montreal
doing
this
and
yeah.
Maybe
we
can
try
again
this
week
to
find
out
what
the
problem
is.
B
So
we
can
ship,
therefore,
and
go
on
from
that,
but
I
also
want
to
remind
people
that
poco
is
not
the
only
congestion
control
scheme
that
ever
will
be
defined
for
co-op.
If
you
think
about
TCB
that
there
are
a
three-digit
number
of
them
and
that's
not
a
problem,
because
the
congestion
control
scheme
is
a
local
matter,
so
you
implement
whatever
fits
your
application
best,
and
so
there
is
a
next
one,
lined
up
the
phaser
work
and
we
will
talk
about
that
on
Thursday.
B
Object
security
I
think
we
just
said
we
will
discuss
it
on
Thursday,
but
just
as
a
quick
status
report,
this
was
submitted
to
the
is
G
in
February.
There
were
a
lot
of
useful
ISD
comments,
and
these
have
led
to
the
main
revisions,
11
and
12,
and
there
have
been
three
additional
minor
updates
since,
and
there
will
be
some
discussions
this
week
to
see
whether
we
can
clear
the
remaining
discussed
by
better
fair
okay.
B
So
the
assumption
that
most
people
have
who
have
looked
at
this
in
detail
is,
we
will
get
it
fixed
at
some
point
but
as
with
with
every
piece
of
security,
it
does
require
a
very
good
look.
So
we
can
consider
ourselves
very
happy
that
we
got
this
detailed
look
from
the
is
tree
and
can
make
sure
that
they
aren't
even
editorial
forms
of
misunderstanding
things.
E
Okay,
so
the
too
many
requests
that's
in
is
you
review.
It
has
about
no
discusses
a
decent.
We
relatively
happy
with
that,
but
there's
a
whole
bunch
of
comments
that
would
be
clarified
there,
small
things
here
and
there,
so
this
is
about
the
0-5,
is
the
current
version
in
the
data
tracker,
but
then
there's
also
a
zero
there's,
also
a
zero
six-person,
its
upcoming,
that
is
in
the
github.
E
So
key
things.
Some
clarifications
number
one
question
that
got
from
the
IES
she
was
like:
why
are
we
using
max
age
and
not
defining
a
new
option,
and
the
reason
for
this
is
that
503
is
already
using
max
AIDS
for
the
purpose
of
telling
the
client
to
back
off
come
back
after
this
time
and
then
we'll
be
done
and
I
guess
the
reason
for
503
the
use
that
or
initiative
was
that
it's,
the
proxy
castro's
actually
not
nicely.
E
So
what
we
did
clarify
in
this
draft
that
we
are
not
defining
a
new
use
of
max
age
were
simply
reusing.
Whatever
was
defined
for
503,
and
there
was
one
is
you
commented?
Maybe
we
should
also
update
there
I
in
a
registry
to
point
out
that
okay,
also,
this
government
is
using
max
age
to
make
it
more
clear
for
implementers
when
they
see
that,
but
it
still
seems
to
be
the
reasonable
way
forward
that
we
are
using
Max's.
E
We
did
discuss
it
and
also
earlier
in
the
core
group
whether
we
should
have
a
different
option
for
that.
So
far
the
constant
seems
to
be
leaning
towards
keeping
it
as
max
age
on
the
server
behavior.
What
we're
clarifying
is
that,
if
the
client
does
not
respect
the
backup
from
the
four
to
nine,
so
the
client
keeps
on
doing
the
same
requests,
even
though
there
was
a
max
a
chop,
something
not
to
do
so.
It's
not
said
that.
E
Okay,
a
server
may
also
respond
with
503
and
the
rationale
here
being
that
maybe
the
client
simply
doesn't
recognize
the
four
to
nine
error
code.
This
is
a
new
error
code
that
it's
at
now
being
definitely
find.
The
503
gets
the
same
behavior,
but
just
gives
the
clients
much
less
information
what
it
could
do.
E
Then.
Currently
there
was
a
transfer
area
review
saying
we
may
need
to
do
some
rate
limiting
on.
How
often
would
you
answer
with
this
code,
so
currently
draft
says
you
could,
for
example,
limit
to
once
every
RTT
estimated
RTT,
but
discussing
here
in
Bangkok
with
Karsten
that
exceeds
such
estimates
may
not
be
well
available
for
a
server,
and
there
could
be
some
other
criteria,
how
you
wanna
run
a
rate
limit,
so
not
as
a
proposal
that
maybe
instead
of
saying
once
every
RTT
is
saying,
taking
into
account
your
usual
load
sharing
policies.
E
So
that
is
now
noted
in
the
draft
and
also
there's
finally
a
reminder
that
this
code
is
meant
for
do
the
client
that
is
actually
causing
the
overload,
if
it's
some
other
clients
or
some
other
reason
causing
overrode.
The
503
is
more
appropriate
for
that
use.
Just
as
a
note
about
something
that
I
guess,
we
all
know
implicitly
that's
good
to
be
explicit
on
that
on
the
client
behavior.
There
was
a
question:
how
do
you
interpret
max-age
and
like
what
is
the
exact
time?
When,
should
you
start
your
timer?
E
How
long
to
wait
so
co-op
RFC
currently
says
about
this
max
a
said:
it's
current
at
the
time
of
transmission,
so
there
was
a
offline
discussion.
What
does
that
actually
mean,
and
we
realize
well,
it's
a
bit
ambiguous,
maybe
bit
more
clarifications,
for
this
would
be
useful,
so
Carson
started
this
new
draft
on
clarifications
and
corrections
which
could
eventually
then
be
verifying
this
for
all
use
of
coop.
E
Because
again
this
Mac
says
it's
not
specific
for
this
trap
so
having
those
d-doesn't,
these
trusses
may
problem,
not
the
right
thing
to
do,
but
having
a
general
clarification
draft
for
that
purpose
makes
more
sense.
One
thing
we
did
clarify
here
is
that
the
if
the
max
is
missing
use,
the
default
value
has
already
find
instrumental
five,
but
just
to
reiterate
that
those
rules
do
apply.
E
On
a
security
area,
especially
when
a
security
area
review,
we
had
a
few
clarifications
again.
The
first
one
may
be
a
bit
obvious.
The
RFC
security
considerations
apply.
Maybe
that's
that
that's
a
helpful
thing
to
note
there
and
then
on
that
trust
on
the
response
code.
So
again,
this
is
nothing
specific
for
this
response
code,
but
if
you
are
using
Nosek
mode
yeah,
you
cannot
trust
the
response
is
coming
from
the
right
and
the
right
H,
and
then
that
would
actually
mean
could
be
used
as
a
for
the
EOS.
E
So
you
should
trust
the
response
only
to
the
level
you're,
a
trustee
underlying
security.
So
if
you
use
TLS,
you
know
you
can
t,
let's
get
freshness
and
and
an
integrity
for
example.
But
if
you
have
no
sec
well,
you
should
take
that
into
account.
There's
a
minor
privacy
concern
on
that.
If
you
don't
use
encryption
and
you
do
send
these
replies,
that
could
be
leaking
some
form
of
information.
What
is
the
current
state
of
the
server?
The,
for
example?
The
server
is
being
now
currently
are
under
heavy
load.
E
Didn't
seem
like
a
big
issue,
so
we
didn't
normative
text.
What
we
did
note
that,
in
the
security
considerations,
if
there
is
a
a
concern
from
some
some
kind
of
deployment,
and
finally
the
security
considerations
already
earlier
said
that
if
you
are
under
attack
instead
of
replying
to
all
of
those
requests,
just
simply
dropping
them
could
be
the
right
kind
of
approach.
However,
the
downside
of
that
is,
the
clients
are
likely
to
retry.
E
So
again,
it's
a
it's
a
trade-off
to
be
to
be
taken
into
consideration
on
the
kind
of
a
policy
you
would
apply,
whether
you
drop
or
reply
to
all
of
them,
if
you're,
if
you
consider
yourself
being
under
attack
and
then
final
thing,
so
we
didn't
add
anything
on
this
topic
to
the
to
the
graft,
but
again
because
it
seems
to
be
an
issue
wider
than
just
this
particle
draft.
But
we
got
questions
on
what
happens
when
you
behind
a
proxy.
E
So
if
there's
number
of
clients
behind
a
proxy,
they
all
communicate
with
the
same
server
they
in
the
basic
mode,
the
server
for
the
server.
It
seems
that
all
the
clients
are
clients,
because
it's
the
proxy
unless,
unless
you
use
some
additional
piece
of
information
and
now
when
the
server
replies
with
too
many
requests
to
the
proxy
well,
the
the
last
one
actually
beat
the
request
that
went
over
the
line
will
get
that
reply
and
that
could
have
been,
for
example,
the
very
first
request
that
client
made,
but
it
seems
there
isn't
much.
E
F
E
See
anyone
reacting
massively
of
any
of
these
things,
so
I
assume
they're
all
okay
and
they
were
all
or
a
discussed
on
the
list.
So
this
is
just
check
if
there's
no
issues,
I
can
press
the
button
today
tomorrow
with
along
the
lines
of
that
which
is
presented
here.
The
one
thing
that
has
not
been
on
the
list
was
this
new
proposal
servers
a
great
limit,
four
to
nine
replies,
because
that
came
basically
yesterday
so,
but
that
seems
to
make
a
lot
of
sense.
It's
just
it's.
E
G
B
Yeah,
so
the
customer
and
the
documents
about
proxies
right
now
we're
written
with
a
consideration
that
we
would
learn
things
about
proxies
as
we
go
along
so
they're,
not
at
the
current
moment,
trying
to
turn
a
lid
on
everything.
So
maybe
this
is
a
good
opportunity,
but
let
me
quickly
point
out
the
the
reason
why
this
is
a
little
bit
more
complicated
than
we
like.
So
this
is
trying
to
be
a
rest
environment,
so
the
ideas
that
the
server
doesn't
keep
state
about
what
clients
are
out
there.
B
So
if
the
server
wants
to
tell
a
particular
client,
you
are
sending
too
many
requests
that
that's
entirely
wrong
from
the
point
of
view
of
rest.
Now,
in
a
real
world,
HTTP
environment,
of
course
you
would
have
the
TCP
connection
as
a
piece
of
state
on
which
you
can
piggyback
something
like
that,
but
we
don't
have
that
at
least
we
don't
always
have
that
and
of
course,
once
we
have
a
proxy
in
there,
it
becomes
worse
because
even
if
the
origin
server
has
the
state
telling
the
right
client
who
is
overloading
them
there
is.
B
We
can't
expect
the
proxy
to
also
keep
state
above
request
rates
and
so
on,
because
the
proxy
has
no
idea
what
the
server
actually
is
is
able
to
handle
and
so
on.
So
it's
really
hard
for
the
proxy
to
send
back
the
information
that
this
is
too
much
through
the
right,
client
and
and
unless
we
changed
the
architecture,
a
lot
I,
don't
think
there
is
a
good
way
to
fix
that.
B
So
the
inverse
observation
is
that,
as
a
nice
word
well
behaving
client,
you
might
go
through
a
proxy
that
suddenly
sends
you
a
429,
because
some
other
kind
of
that
proxy
is
sending
too
many
requests.
So
that's
something
that
that
the
nice
client
has
to
be
prepared
to
receive
that.
Of
course
complicates
state
machines
because,
right
now
you
would
expect
as
a
client.
You
would
expect
to
get
a
response,
and
now
you
have
the
possibility
that
you
get
a
429,
but
you
always
had
a
possibility
that
you've
got
a
503.
E
At
the
use
of
this
response
code-
yeah
not
much.
This
is
actually
a
really
recent
thing,
but
it
seems
to
be,
as
the
ocf
guys
said,
they're
already
implementing
something
like
this,
so
probably
worth
while
asking
from
them,
but
it
seems
to
be
the
need,
seems
to
be
there
being
something
more
better
guidance
for
client
than
503.
Just
503.
Pretty
much
was
earlier.
You
could
say,
like
hey
something,
went
wrong
on
this
side,
please
back
off
now
you
have
bit
more
indications,
but,
let's
say
operational
experience
is
still
real.
Oh
thanks.
B
So
we
have
one
one
other
document
that
is
post
work:
new
Blasco,
that's
the
my
teapot
content
type,
which
is
pretty
interesting,
Swiss
Army
knife
tool,
and
one
wonders
why
that
hasn't
been
defined
twenty
years
ago.
But
the
answer
is
probably
there
was
no
see
about
20
years
ago,
so
Thomas
Thomas
Thomas
tried
to
define
it
five
years
ago
and
we
didn't
have
SIBO
at
the
time,
so
we
finally
have
it.
So
we
can
do
it.
B
B
So
if
you
don't
want
to
send
something
you
you
don't
put
it
in,
of
course,
and
obviously
a
solution
and
the
other
thing
you
can
do
in
this
version
of
the
draft
is,
you
can
actually
indicate
there
might
have
been
a
text
plain
something
or
application
PDF
something,
but
this
something
explicitly
has
a
very
of
not
so
that
that's
more
flexibility
for
putting
in
the
information
that
something
is
not
there.
So
you
can
say
it's
not
there
by
not
putting
it
there
or
you
can
say
yes
really.
This
is
not
there
now.
B
The
second
one
is
this,
and
this
runs
this
now,
if
the
second
and
the
third
one
happened
to
have
the
same
media
type,
and
you
want
to
leave
out
this
idea-
the
second
and
not
the
third,
that's
hard
to
say
without
this
functionality,
but
still
the
question
is:
how
often
do
you
need
something
like
that,
and
is
it
worth
complicating
this
structure
by
allowing
another
value,
and
we
already
have
taken
out
some
other
things
from
the
structure
because
it
was
too
complicated.
So
this
is
really
a
question
that
we
could
ask
ourselves
now.
B
I
think
this,
this
measures
well
with
the
other
observation
here,
which
is
that
the
current
version
of
the
pub/sub
draft
is
not
yet
using
multi-part
CT.
We
essentially
have
have
defined
multiple
city,
among
others,
to
solve
the
problem
for
pub/sub,
and
the
document
is
using
this
as
an
example
and
for
pub/sub.
B
It
might
be
useful
to
have
this
null
version
to
say
there
is
nothing
new,
so
yeah
we
have
a
little
problem,
because
market
Costa,
who
could
be
talking
about
the
pub
side
document,
cannot
be
here
because
of
a
medical
emergency
and
he
cannot
join
remotely
to
today.
He
hopes
to
be
back
on
Thursday,
so
we
probably
can
discuss
the
pub
sub
part
on
Thursday,
but
at
this
point
I
would
just
like
to
hear.
Does
anybody
have
an
opinion
on
this
little
piece
of
complexity?.
C
C
Yes,
I
mean
say
you
know:
if
I
go
in
and
I
say:
okay,
I've
got
an
application.
/
ace,
+,
C
boar
here
and
was
there
is
nothing
that
kind
of
is
maybe
confusing
to
some
people,
whereas
boy,
if
I
go
in
and
say,
there's
a
no
content
type
in
this
slot.
That
may
actually
be
a
better
answer
in
the
long
run.
Mm-Hmm.
F
Yeah
Lexi,
I
I
think
I
I'm
not
entirely
convinced
this
is
needed,
but
if
it's
needed
I
probably
would
agree
because
the
current
proposal
is
sort
of
deviating
from
mine
and
I
know
you're,
not
using
mine
structure,
but
you
are
conceptually
using
similar
thing
as
a
collection
at
three
of
you
know,
budda
parts
and
stuff
so
yeah
keep
it
simple
for
now.
Maybe
do
something
like
what
Jim
said.
You
know
later
well.
B
F
Well,
if
you
have
to
extend
it,
is
it
going
if
the
new
version
going
to
be
backward
compatible?
Yes,
can
the
old
stuff
still
read
and
you
know
possible?
Well
then,
what
I'm
saying,
if
you
sort
of
have
extensibility
right,
then
you
probably
don't
need
to
okay
to
change.
If
you
change
the
structure,
if
you
decide
that
you
need
extra
fields
which
weren't
there
well,
then
it
has
to
be
a
new
mime
type
because
all
stuff
couldn't
parse
it
right.
F
B
B
F
B
F
I
But
makhmur
from
Nokia,
so
this
question
at
least
for
me,
I'm,
trying
to
evaluate
whether
this
means
like
every
time
it
repeats
this
null.
When
you
could
occur
like
multiple
times
that
CD
is
coming
up,
or
is
that
like
one
time
thing,
because,
depending
on
that,
for
example
like
if
you
are
going
to
send
C
or
TLV
etcetera
together
each
of
it?
If
it
has
a
null
value
represented
by
itself,
then
that
could
occur
in
the
compacted,
multiple
content
type.
B
Yeah,
so
the
the
Nvidia
would
be
in
place
of
a
reservation
of
the
part,
and
of
course
it
wouldn't
mean
there
is.
We
have
extended
the
media
type
by
an
IVA
us
and
there's
no
possibility,
but
that
would
mean
that
thing
isn't
there
and
if
you,
if
you
don't
have
a
way
of
saying
that
thing
is
in
there
explicitly,
then
you
cannot
always
use
positional
encoding.
B
B
Great,
so
we
have
minus
five
minutes
to
talk
about
two
documents.
One
is
the
statements
document
that
passed
recently
and
we're
waiting
for
the
author
to
resubmit
it
as
a
draft
IETF.
So
this
represents
the
result.
We
had
of
the
discussion
how
to
solve
the
status
problem
and
six
dishes
waiting
for
us
to
resolve
that.
So
we
don't
have
all
the
time
in
the
world
of
doing
this.
So
of
the
two
ways
of
doing
this
we
had.
B
B
Now
we
don't
have
any
any
mechanism
that
would
indicate
somebody
is
able
to
accept
it,
hoping
that
there's
longer
than
eight
bytes
and
it
sounds
enough
years
if
there
is
12
bytes,
but
it
might
be
60,
kilobytes
and-
and
so
we
have
to
think
about
how
to
handle
this
case.
Of
course,
there
are
other
things
that
can
be
made
big.
So
it's
not
a
completely
new
problem,
but
since
it's
in
a
place
of
the
message
format
that
didn't
grow
much
yet
it's
maybe
something
to
specifically
look
at.
B
Okay,
the
other
document
that
that
didn't
begin
workgroup
adoption
yet,
but
that
should
have
maybe
is
the
corrections
and
clarifications
document.
I
think
we
have
talked
about
this
in
a
number
of
meetings
and
now,
finally,
there
is
an
initial
draft
for
it
and
the
idea
is
to
do
the
same
thing
that
was
done
in
RFC
48:15.
B
Now,
of
course,
most
of
you
won't
know,
RFC
4815,
that's
another
document
that
has
correct
and
clarifications
in
the
title,
and
this
was
held
as
a
running
document
as
a
working
document
by
the
rock
working
group
for
almost
five
years,
and
the
rock
working
group
used
this
draft
or
document
minor
points
of
clarification
and
so
on
plus
actually
actually
needed,
Corrections,
which
usually
also
work
Larry
vacations.
But
there
they
were
clarifications
very
really.
A
decision
had
to
be
made
before
the
clarification
could
be
issued.
B
These
were
collected
in
in
the
document,
and
this
was
mostly
based
on
implementer
feedback.
So
we
haven't
done
this
in
this
working
group
and
I.
Consider
lucky
that
we
didn't
have
to
so
rock
is
an
extremely
complicated
standard,
170
pages,
and
so
it
does
attract
bugs
when
you
build
something
of
that
complexity
and
curb
isn't
as
complex.
B
Each
time
we
have
one
of
these
small
issues,
so
yeah
I,
don't
know
4815
has
has
a
large
two-digit
or
a
small
three-digit
number
of
issues
in
it
and
we
might
not
get
there,
but
it
doesn't
make
sense
to
exercise
the
process
each
time,
so
the
next
version
of
the
structure
might
have
a
draft
version
of
that
process.
So
if
people
are
interested
in
in
this,
I
would
like
to
hear
from
them
offline
what
we
might
want
to
put
in
there,
but
I
think
it's
pretty
much
clear
what
you
want
to
do
there.
B
So
you
have
a
candidate
issue,
then
you
have
a
issue
with
a
Provost
resolution
and
then
at
some
point
you
have
an
issue
with
an
accepted,
a
resolution.
That
would
be
three
steps
and
maybe
we
have
to
add
a
fourth
or
a
fifth
and,
and
that
should
be
about
it
and
of
course
an
accepted
issue
might
itself
have
issues
that
have
to
be
fixed
afterwards.
B
F
Just
had
a
very
quick
look
at
artis
7815
and
that
it
has
sort
of
list
of
issues
and
alt-text
mutex,
so
it's
kind
of
patch,
yes
right
from
recent
experience
in
IHG
I,
think
it's
very
hard
to
review
the
documents
like
this.
It's
much
easier
to
review,
actually
updated
document
then
try
to
apply
a
patch,
especially
if
we
had
a
document
recently
where
there
were
multiple
issues
and
sometimes
they
were
being
applied
to
the
same
section.
F
F
B
At
some
point
and
said
we
don't
have
the
cycles
to
do
the
editorial
work.
To
put
this
together,
I
mean
this
was
before
get
and
so
on
and
I
receive
said.
You
know,
95
was
written
in
Microsoft
Word
and
it
was
a
complicated
process.
So
that's
why
this
just
was
published
as
a
separate
document,
but
I
don't
propose
that
we
want
to
do
this.
It
might
turn
into
a
nice
informational
document.
At
the
end,
if
we
have
applied
all
the
things
that
are
really
issues-
and
we
just
have
nice
explanations
that
that
might
happen,
but.
B
B
So
if
you
look
at
the
document
that
she
lists
some
five-hour
C's
would
it
would
be
updating
if
it
were
published?
But
again
the
point
is
not
necessary
to
publish
it
in
this
fall
and
yeah.
We
will
have
five
years
since
the
original
publication
of
our
c7
five
next
year,
so
it
might
be
a
good
thing
to
actually
start
this
process
at
some
point,
but
let's
first
collect
the
things
they
really
want
to
change
and
see
how
heavyweight
that
is.
B
B
K
Okay,
Marko
Tanaka
from
Rhys
a
quick
update
on
Oscar
for
group
communication.
We
have
a
major
revision
of
the
document,
mostly
based
on
two
different
views
from
Jim
and
Peter.
Thanks
a
lot
for
that,
of
course,
all
the
Victoria
changes
mostly
to
improve
readability
and
have
a
better
alignment
with
the
main
Oscar
document
and
upon
many
people's
requests.
We
moved
every
detail
on
key
management,
key
provision
aspects
out
of
this
document
and
to
the
related
document
in
ace
we
refer
here.
K
We
keep
in
this
document
only
high-level
pointers
and
discussion
on
the
importance
of
that
especially
and
the
group
manager
is
the
only
responsible
for
key
provisioning
and
handling
key
material
in
the
group
and
acting
as
a
repository
for
public
keys
of
group
members.
But
again
the
details
are
moved
out
to
the
ACE
document.
K
A
big
technical
update
is
the
countersignature
it
used
to
be
placed
inside
your
score.
Option
out
has
been
moved
out
and
appended
to
the
payload
of
the
secure
message,
and
this
has
the
advantage
to
achieve
what
more
affordable
impact
in
terms
of
message
fragmentation,
while
still
it's
just
possible
to
easier
parse.
The
years
core
option,
retrieve
the
context
and
then
proceed.
K
We
added
some
more
text
on
security
considerations
that
we
actually
plan
to
extend
further,
several
time
being
mostly
on
management
and
group,
key
material
and
possible
misalignment
of
security
contexts
among
group
members
right
after
new
key
material
has
been
distributed
in
the
group
and
how
to
handle
that
other
aspects
handle
what
happens
if
USPS
run
off
sequence,
numbers
by
group
members
and
use
the
special
IDs
and
how
to
handle
that.
We
have
compressed
the
the
list
of
responsibilities
of
the
group
manager.
K
Now
single
one
used
to
be
two
lists
pointed
out
explicit
of
the
need
for
registering
the
beat
in
your
score
option
to
signal.
The
presence
of
the
signature
is
actually
the
fun
in
this
document,
and
we
have
rewrote
I
would
say
from
scratch
a
massively
shortened
appendix
D,
describing
at
a
very
high
level
the
set
up
of
a
new
item
point
because
again,
everything
related
to
the
provisioning
of
key
material
to
a
new
endpoint
is
out
of
scope
for
this
document
and
described
in
the
h1.
K
As
the
next
steps,
we
would
like
to
converge
to
an
actual
implementation
version
of
this
document.
We
believe
we
are
pretty
much
there
actually,
because
s
caught
ourselves,
we
don't
see
any
big
issue
left
that
will
stop
an
implementation
of
this
back.
We
just
like
to
define
what
aspects
are
exactly
up
to
application
policy
like
overall
messages
back
to
group
members.
If
something
is
wrong
and
we
would
like
to
expand
further
the
security
considerations,
hopefully
as
a
one-to-one
match,
with
respective
subsections
in
the
main
Oh
score
document.
K
Speaking
of
implementation
in
rice,
we
are
going
to
start
soon,
implementation
for
californium
building
on
the
current
one
available
for
score
and
all
certain
innovations
also
plan
to
start
soon.
An
implementation
in
C
I
was
all
to
be
used.
Specifically,
for
the
dot
framework,
of
course,
is
anyone
else
is
interested
in
considering
this
like
for
implementing
you're,
very
welcome,
and
that
was
it
for
you
update.
K
K
B
K
K
Okay
mark
confirm
rise
again.
This
is
a
related
work
that
we
started
after
some
discussion
at
the
mic
on
group
of
score
immoral,
actually
we're
somewhere
wondering.
Is
there
any
other
work,
especially
in
this
working
group
that
somehow
uses
groups
and
can
be
helpful
in
any
way
to
a
group
of
score?
And
we
talked
about
the
possible
use
of
the
resource
directory
for
that
so
to
facilitate
applications
using
security
and
based
on
groups.
K
For
instance,
the
identifier
of
the
group,
the
IP
address,
is
used
in
a
group,
multicast
IP
addresses,
or
specifically
the
link
to
a
drawn
resource
of
the
group
manager
to
get
access
to
the
group
and,
at
that
point
in
time,
also
get
the
key
material
to
operate
in
the
group,
and
this
can
actually
happen
for
reasons
like
even
the
manufacturing
time
and
there's.
Just
not
such
available
information
to
provide
to
the
joining
node
or
the
information
that
the
join
node
would
required
to
operate
in.
K
K
So
we
try
to
find
a
way
to
use
essentially
the
core
resource
directory
for
joining
device,
to
possibly
find
the
existence
of
the
ascore
group
in
the
first
place
and
to
retrieve
all
the
missing
required
information
to
join
the
group
through
the
responsible
group
manager
and
we
actually
use
resource
lookup
of
the
resource
directory.
Because,
in
the
end,
the
join
device
needs
to
retrieve
the
pointer
and
a
link
to
the
join
resource
of
the
group
manager
to
access
the
group
and
get
the
key
material
to
securely
operate
in
the
group.
K
We
try
to
be
general,
but
we
had
as
a
guideline
the
method
described
in
the
ace
draft
refer
here.
So,
of
course,
we
are
consistent
with
that.
First
and
foremost,
it
works
like
that
pretty
much
as
steps
order
in
time.
The
group
manager
sooner
or
later
is
supposed
to
register
itself
as
an
endpoint
in
the
resource
directory
and,
at
the
same
time,
to
register
all
its
join
resources
with
the
relay
link
attributes,
and
we
are
referring
also
to
a
new
value
for
resource
type
of
j
2,
because
here
for
the
core
parameters
registry,
this
example.
K
Essentially,
a
group
registers
itself
and
one
of
its
resource
with
additional
information
later
on,
might
happen
that
the
group
manager
creates
newest
core
groups
or,
for
some
reason
it
has
to
update
some
information
related
to
those
groups.
And,
of
course,
it
has
to
have
the
80
entries
related
to
those
resources,
and
one
way
to
do
that
is
that
the
group
manager
Arie
registers
itself.
K
An
alternative
way
will
be
somehow
using
fetcher
patch,
but
that,
of
course,
would
require
the
proper
definition
of
format.
For
that
and
then
later
on,
the
device
can
performers
look
up
at
the
resource
directory,
specifying
a
number
of
search
criteria
which
resource
type
LJ
is
mandatory
and
other
possibly
usable.
K
In
addition,
like
the
identifier
of
the
score
group
or
the
identifier
of
the
group
manager
registers,
an
endpoint
in
the
Rd
and
the
journey
not
gets
back
as
a
reply,
all
information,
it
needs
to
contact
a
group
manager
and
join
the
group,
and
already
in
this
example,
I
alighted
the
possible,
of
course,
optional
use
of
observation
for
this
request,
which
has
a
number
of
advantages
like,
of
course,
automatic
notification.
In
case.
K
One
of
these
information
is
updated
later
on,
or
even
for
the
extreme
case,
where
the
journey
node
is
deployed
even
before
the
group
manager
is
deployed
or
the
group
is
created,
and
so
only
later
on,
when
the
group
is
created.
All
the
related
information
is
fully
available.
They
can
be
provided
to
the
observe
response
to
the
join
node.
Of
course,
if
you
do
like
that,
you
can
produce
a
response
drum
set
with
quite
a
large
payload
if
there
are
so
many
general
resources
for
the
group
measure.
So
it's
actually
recommended
to
use
observe
here.
C
K
L
Peter
found
a
stock
to
react
to
that.
If
we
remain
with
the
old
groups
have
specified
in
the
resource
directory,
it
will
work
as
well
and
we
have
got
done
and
going
forward
to
the
next
one,
which
is
more
appropriate
because
it
uses
resources,
and
so
that
will
be
reworked
better.
It
will
be
much
more,
but
of
course,
we
have
to
say
that
we
must
have
more
experience
in
how
we
install
things
to
see
if
it's
actually
the
right
approach.
Okay,.
I
K
I
Okay,
so
that
still
happen,
and
then
the
other
question
I
had
was
like
the
right
now:
I'm,
looking
at
Darby
and
lightweight
m2m
service
and
equivalence
like
we
were
discussing
so
in
terms
of
this
group
server
or
group
manager,
can
it
also
be
an
RD?
So
then
it
kind
of
gels
well
with
the
management
weapon.
K
J
M
Mattias
Kovich
simmons,
so
I
was
under
the
impression
that
RD
became
more
modular
so
that
you
can
provide
extensions
that
provide,
for
instance,
new
forms
of
lookups.
You
are
using
explicitly
the
existing
resource
lookup.
Then
we
appoint
to
the
resource
to
get
information.
I
just
wanted
to
confirm
this
kind
of
dynamic
that
we
had
discussing
about
Rd,
making
a
bit
modular
kind
of
plugging
in
more
mechanisms
that
use
the
existing
resource.
M
K
N
D
B
B
B
K
C
B
One
hand
Alex
thank
you,
okay,
good,
so
I
think
we
should
do
that
next
now,
on
the
actuators
document,
I
think
we
have
had
a
little
bit
of
a
different
perception
of
what
this
is.
Is
this
admonition
to
implementers
which
which
would
make
it
like
an
a
week
document?
Is
it
some
some
text?
We
may,
at
one
point,
add
to
our
C
725
to
clarify
that
you
have
to
be
a
bit
careful
how
you
use
these
primitives
I'm,
not
entirely
sure
what
the
correct
disposition
of
this
is.
B
B
Remember
we
need
also
need
to
take
that
to
the
list
so
I
shuffle
it
around
the
agenda
a
little
bit,
but
maybe
we
actually
should
unravel
this,
because
we
just
ran
into
the
resource
directory
issue,
and
maybe
we
can
can
relatively
quickly
go
through
that.
So
I
think
the
idea
would
be
to
do
the
resource
directory
part
now
and
then
go
to
the
next
parts.
B
O
Like
to
talk
about
the
resource
directory
and
especially
its
status
since
the
last
ITF
meeting,
so
there
are
two
big
things
that
have
come
up
here.
Our
next
slide.
Please
one
thing
is
that
we
finally
received
a
review
on
the
topic
of
the
modernizing
former
thanks
to
Charles,
which
indicates
that
we
should.
The
quote
would
probably
not
want
to
do
that.
The
other
is
the
topic
of
which
has
already
been
introduced
in
the
questions
tomorrow,
but
we
before
we
get
to
those
I'd
like
to
give
a
short
update
off
of
what
had
happened.
O
I'm
slide,
please
so
there's
a
the
security
policies
have
been
updated.
Responding
to
some
comments
that
we
got.
There
was
a
successful
plaque
test,
although
there
are
still
issues
with
the
university
universal
deployment
of
ipv6,
so
we
couldn't
test
all
the
working
clients
against
each
other
and
but
what
we
could
test
did
largely
work
but
resulted
in
some
good
comments
which
have
been
which
are
either
under
processing
or
have
been
incorporated
as
editorial
changes.
Now
all
those
changes
wound
up
in
a
dash
16
version.
O
You
might
have
noticed
that
there's
also
a
dash
17
person
which
which
includes
the
latest
changes
to
the
group,
but
as
I
see
you,
the
slides
are
the
other
way
around
so
slide
plays.
Let's
start
with
the
tactic
of
modernizing
forward.
O
What
we
tried
to
do
with
modernize
link
format
was
to
work
around
the
limitations
of
66
90
by
doing
what
you
could
describe
as
66
90
bits
in
an
appendix
now
that
didn't
go
too
well
with
the
reuse.
So
we
are
moving
back
a
little
now
to
saying
that
there
is
a
limited
subset
of
66
90
links,
which
is
which
should
work
with
what
people
have
implemented
and
prescribed
that
only
those
four
only
for
those
datasets
the
resource
directory,
can
can
work
with
link
format.
O
Now
those
can't
work
with
that
kind
of
links,
but
those
applications
can
still
either
use
coral
or
any
other
link
format.
That's
not
inheriting
the
sixty
six
ninety
problems
or
rely
on
the
implementation
to
work
with
those
links
that
are
outside
of
of
what
the
resource
directory
specification
actually
says
is
is
okay.
O
O
You
groups
have
been
in
the
resource
directory
for
for
about
five
years
and
what
came
up
in
the
discussion
of
the
world
with
macro
and
trying
to
to
work
on
a
concrete
application
of
groups?
Is
that
what
those
groups
do
is
not
actually
what
you
need
to
deploy
group
because
back
then
it
seems
to
me.
The
impression
was
that
a
resource
directory
could
just
publish
a
list
of
endpoints
and
the
to
be
part
of
a
group,
and
they
would
automatically
join
now.
O
Joining
is
a
bit
more
complicated
now
that
we
expect
everything
to
run
over
Tripta.
So
there
is
not
much
value
anymore
in
numerating
the
membership,
and
also
that
that
part
of
resource
rectory
added
quite
a
bit
to
complete
complexities
of
what
it
was.
Maybe
ten
percent
of
of
the
whole
document
length.
So
what
I'm
trying
to
do
with
this?
This
group
proposal
is
to
say
that
groups
are
not.
O
Groups
are
not
a
thing
as
an
as
a
separate
entity
in
resource
directory,
basically
ripping
out
those
ten
percent,
but
introducing
a
way
of
registering
a
group
as
an
endpoint.
Now
this
is
something
that
doesn't
need
complexity
on
the
on
the
implementation
side,
because
it's
just
an
endpoint
just
with
a
particular
attribute
which
it
could
already
have
had
and
next
slide.
Please.
This
also
means
that
we
can
now
look
up
groups,
look
up
resources
of
groups,
which
is
something
Micro
hinted
to
in
the
in
the
group,
application
for
Oscar
as
well.
O
Yeah
and
as
it
would
always
have
been,
a
group
is
registered
by
a
commissioning
tool
that
knows
all
the
details
of
the
groups
now
that
we
would
in
practice
often
be
the
next
slide
place
that
would,
in
practice
always
often
be
in
the
group
manager.
That
knows
what
the
details
of
that
group
are.
So
in
the
17
draft,
this
the
old
groups
got
replaced
with
a
basically
an
appendix
that
says.
This
is
a
way
how
you
can
use
groups.
This
is
use.
O
This
is
a
usage
pattern
for
which
we
also
define
an
endpoint,
an
end
point
type,
so
it
is
well
defined,
but
it's
rather
simple
straight
forward,
and
hopefully
something
the
working
group
will
not
object
to
this
late
in
the
process,
given
that
we
are
already
trying
to
to
move
towards
or
working
group
last
call
now.
One
reason
why
this
was
done
is
that
implementers
usually
didn't
implement.
O
There
was
exactly
one
implementation
by
Jim
that
that
implemented
those
groups
as
they
where,
and
this
means
that
we
can't
really
present
much
interim
interoperability
experienced
with
those
groups,
whereas
the
the
new
groups
are
are
something
you
can
do
with
any
resource
directory
next
slide,
please.
So
as
as
to
the
point
of
what
how
can
resource
directory
progress?
Now,
there
are
two
concrete
questions.
O
I'd
like
to
ask
one
is:
does
anyone
use
all
the
all
the
details
of
our
C
66
90,
in
particular
the
origin
resolution
rules,
because
if
so,
we
might
need
to
prescribed
that
on
our
that
an
RD
even
processed
those
correctly,
which
I
think
we
don't
need
to
making
implementations
way
simpler
and
the
other
question
is:
are
there
any
applications?
We
did
not
hear
before
of
the
groups
that
we're
in
the
personal
five
draft
up
until
they're
16?
D
So
Zac
shall
be
from
arm
thanks.
Christian,
really
good
presentation
and
good
work
to
repin
reduce
the
size
of
a
draft
going
into
working
group.
Last
call
that
doesn't
happen.
Often
just
just
my
insight
under
both
of
these
I
mean
the
reason
we
added
groups,
as
they
were
back
then,
was
because
of
Peter.
D
You
know
in
the
lighting
industry,
this
was
seen
as
a
necessary
tool
for
installation
management
tooling,
and
so
it's
really
just
based
on
a
very
clear
industry
request.
Now.
This
is
a
neat
way
of
solving
the
same
problem
with
less
mechanics.
You
know
nobody
ended
up
implementing
that
group
thing,
because
a
lot
of
our
DS
that
are
deployed
today
on
the
Internet
are
centralized
cloud.
D
Thingies
they're
not
available
available
locally
for
this
type
of
group
communications,
so
I
haven't
seen
a
lot
of
Rd
deployments
at
the
edge
that
could
change,
and
that's
fine,
because
I
think
this.
This
new
mechanism
is
okay.
On
the
first
question,
I'm
not
aware
of
people
doing
advanced,
66,
90
work,
I
haven't
seen
that
in
the
wild,
so
I
think
it's
safe
to
say
we
could.
D
We
could
simplify
it
and
dumb
it
down
for
this,
and
then,
let's
see
in
the
future,
what
happens
with
coral
one
thing
I
do
think
we
have
to
be
aware
of.
Is
future
compatibility
with
new
link
formats
and
just
double-check
that
we
don't.
We
don't
get
caught
with
coral
coming
and
then
not
being
able
to
use
it.
M
Matthias
Kovac
Siemens,
so
I
try
to
catch
up
kind
of
the
exact
issues
with
RFC
66,
90
and
I
couldn't
find
actually
explicit
text
that
redefines
the
your
I
resolution
mechanism
or
that
you
should
do
it
in
a
different
way.
I
think
there
was
just
explanation
missing
that
people
who
are
not
aware
of
the
actual
algorithm,
do
it
right,
so
I'm,
not
sure
kind
of
what
happened.
I,
try
to
figure
it
out
from
the
meaningless,
but
but
I'm
a
bit
lost
there.
Is
there
really
a
feature
that
people
wanted
to
use?
I?
O
Well,
it's
it's
not
particularly
about
the
the
euro
resolution
itself,
so
so
396
stands,
but
66
90
says
that,
for
example,
before
you
resolve
the
d8
ref
links,
you
have
to
first
resolve
the
anchor
and
then
resolve
the
references
in
the
H
ref
relative
to
what
that
anchor
resolved
to
and
in
between
at
some
times
in
between,
you
have
to
form
the
origin
of
that.
So
you
strip
all
the
past
components.
That's
something
that
technically
is
not
part
of
the
euro
resolution,
but
part
of
the
resolution
that
happens
before
before
the
your
eyes
are
resolved.
O
B
B
One
of
the
original
ideas
was
that
you
can
put
your
link
format
text
into
ROM
by
using
relative
references
and
was
it
that's,
fall
use
in
brain
on
call.
But
we
have
the
simple
registration
mechanism
where
the
resource
directory
then
fetches
the
random,
coil
and
construct
the
registration
out
of
that.
So
that's
why
relative
references
sometimes
do
occur
and
we
should
make
sure
that
we
can
say
where
they
work
and
where
they
don't.
L
L
Okay,
this
is
if
every
small
update
on
the
our
DD
+
SSD
draft,
what
we
have
done
is
added
a
section
in
the
beginning
of
the
ID
DNS
draft,
which
motivates
actually
the
mapping
which
goes
on
from
the
resources
to
the
surfaces.
So
one
of
the
things
that
film
has
to
find
it's
the
DNS
domain,
in
which
the
shorter
resource
holding.
L
No
how's
this
called
host,
which
domain
it
is,
and
there
is
a
new
draft
which
has
been
done
so
V.
That
tells
you
how
you
can
actually
find
the
domain
of
your
note
very
mature
F
at
which
the
software
is
running,
so
that
is
then
soft.
The
surface
type
we
have
discussed
that
actually,
the
resource
type
and
the
surface
type
actually
serves
the
same
functionality
because
their
services
delivered
and
you
want
to
service
off
a
tippet,
friction
ality.
L
You
want
to
discover-
and
that
is
what
you
want
to
do,
both
with
the
resource
type
in
a
service
type
by
the
surface
type
actually
may
envelope
several
resources
within
this
different
resource
types,
which
can
be
then
put
together
in
an
embalm
type
of
resource
type.
So
that's
motivates
that
and
then
further
the
instance.
The
instance
can
be
a
manufacturer
generated
name.
L
L
The
UUID,
which
is
supposed
to
be
other
identity,
I
identify
the
the
instance
of
the
surface
or
what
you
could
do
that
you
have
an
interface
description
and
you
describe
in
it
how
you
actually
finds
the
attribute
for
the
instance
or
you
can
do
in
deployment
find
using
commissioning
to
Estelle's.
You
look
here.
You're
number.
Five
format
fifty-five
in
the
left
hand
corner.
So
these
are
the
different
examples
that
we
put
in
the
instance,
and
together
is
the
domain
service
type
and
the
instance.
The
surface
type
for
used
in
the
DNS
is
completely
defined.
L
Yep,
there
is
one
suggestion
that
every
family
have
in
the
IANA
registry,
which
automatically
Maps
the
surface
type
to
the
resource.
That
I
don't
know
if
this
is
a
good
idea
should
like
to
have
some
reactions
about
that.
If
people
think
it
is
good
but
or
that
we
just
keep
the
service
type,
writes
history
and
the
resource
type
s
history,
and
we
do
not
care
about
an
fixed
mapping.
H
H
There
is
a
surface
that
that's
just
we,
no
no
I,
don't
mean
I,
don't
mean.
Are
you
talking
about
the
DNS
SD
service
type
registry?
You
know
what
I
mean
is
that
the
register,
the
things
that
can
appear
in
Cordy,
are
not
enumerated
and
therefore
defining
a
mapping
between
them
and
DNS.
Sd
service
types
is,
is
problematic
so
and-
and
this
is
a
problem
that
exists
because
there
are
about
fifteen
different
standards-
bodies
defining
their
own
different
ways
of
doing
these
things,
and
you
know
this
is
something
the
IAB
actually
did
a
report
on
recently.
B
A
B
H
H
B
G
B
G
Oc
f
has
a
policy
to
register
all
the
resource
types
with
I
Anna,
there's
no
intent
to
keep
any
of
them.
Private
in
fact,
part
of
their
requirement
before
they
publish
a
standard.
Is
they
make
sure
everything's
that
I
ended
before
they
publish
their
document,
but
it
as
the
final
copy
now
you'd
ask
about
other
organizations.
I
can't
come
on
them,
and
so
the
ocf
wants
everything
to
be
the
I
know.
Resource
type
registry,
but
I
can't
comment
on
is
whether
ocf
cares
about
the
service
type
mapping,
no
idea
and.
G
Mapping
a
service
type
to
a
resource
type
is
actually
the
easier
direction.
The
opposite
direction
is
much
harder
because
resource
types
can
be
arbitrary,
URLs
and
not
just
things
that
are
in
the
registry
mapping.
The
things
that
are
in
the
registry
is
very
straightforward
by
mapping
arbitrary
resource
types,
and
so
maybe
in
the
proxy
you
say
that
the
mapper
or
whatever
you
say,
I,
choose
to
not
register
and
not
make
those
be
discoverable
in
DNS.
That's
why
that
one's
a
much
harder
problem
so
near
I,
think
I
answered
half
of
one
of
your
questions.
L
And
now
the
solution
is
that
actually
we
defined
and
parameter,
which
is
called
SD
is
so
that
for
each
note
that
is
defined
what
his
service
type
is,
and
so
we
have
no
mapping
nothing
else.
It
is
the
bomb
who
installs
the
note
who
actually
knows
what
to
order
manufacture.
Who
knows
what
the
service
type
should
be
I.
B
G
So
one
other
point
ahead
does
daysailer
again,
it
said
if
you're
not
familiar
with
the
resource
type
registry.
The
syntax
and
research
type
registries
allows
things
like
dots,
which
makes
it
complicated
to
map
it
into
service
types,
not
the
other
way
around.
So
that's
just
another
example
of
if
you
look
at
all
the
ones
you
know
the
the
200
whatever
that
are
registered,
the
vast
majority
of
them
have
a
bunch
of
dots
in
them.
L
N
P
L
I've
run
into
a
problem
is
registration
of
seats
to
yoga,
mind
bird.
We
have
the
contents
of
a
young
specification
can
be
transported
or
for
constraint
networks.
We
have
done
the
young
to
see
poor
draft,
which
tells
you
how
this
young
is
converted
is
to
see
BER,
which
makes
it
smaller.
However,
the
young
names
can
be
very
long,
so
you're
still
left
with
a
very,
very
large
payloads,
so
that
we
have.
What
has
been
done
is
that
they're
young
names
can
be
reduced
to
numeric
identifier
code
and
sit
for
example.
L
L
That's
what
we
want.
We
don't
want
to
change
it
for
at
this
moment,
the
seat
ranges.
Sit
range
is
allocated
to
modules
from
comb
space
facility
and
they
can
be
changed
during
the
development.
If
you
need
be,
if
you
don't
want
to
changed
me,
you
don't
change
them,
but
suppose
you
change
your
whole
draft
or
another
draft,
etc.
So
you
can
change
them.
So
you
have
all
this
freedom
once
the
errors
you,
the
ID,
is
ready
to
go
to.
L
Now
what
we
have
now
that
the
it's
not
clear
how,
within
this
base
in
the
RFC,
the
seats
should
be
registered
and
administrated.
So
this
is
what
we
propose
that,
once
you
have
a
set
range
for
every
module
in
RFC
that
the
contents
of
the
seat
files,
which
are
this
tire
which
actually
specified
this
is
the
young
name
and
it's
the
seat-
fell
that
that
is
part
of
the
of
the
RFC.
L
Just
like
the
same
as
you
have
now
that
the
whole
young
specification
is
part
of
the
RFC
and
also
how,
for
example,
the
tree
which
you
have,
which
is
specific,
which
is
constructed
as
part
of
the
RFC.
So
we
want
to
include
that
as
well.
But
we
also
then,
once
that,
apart
from
that,
the
module
do
normally
is
registered
by
Jana,
which
tells
you
how
about
what
is
in
it.
L
L
Q
Ok,
so
Alexander
on
the
mic,
thanks
very
much
for
email
and
for
this
presentation
Peter.
So
this
is
completely
in
line
with
what
the
company
space
and,
on
the
whole
thing
the
whole
system
that
it
it
was
supposed
to
work
right
once
you
assign
and
I
think
Carsten
pitched
in
on
the
mailing
list,
once
you
assign
the
CID,
then
it
never
changes
and,
of
course
this
we
meet
up
to
Ariana
times,
and
this
is
really
something
in
the
in
the
way
things
should
be
working.
Q
C
Q
Need
to
go
and
and
make
sure
that
it
is
actually
written
in
a
way
that
works
for
people
that
are
actually
using
it.
So
that
does
seem
to
me
to
be
like
yes,
this
is
in
the
way
that
listen,
how
I
felt
it
it
goes
exactly
in
that
direction,
and
it
just
in
this
in
like
okay.
Well,
there
is
maybe
something
that
was
not
explicit.
Let's
make
it
explicit
yeah
yeah.
L
B
So,
of
course,
I
Jana
has
to
be
happy
with
doing
this,
I
mean,
given
that
there
will
be
hundreds
of
modules
with
hundreds
of
names
in
it.
So
essentially,
this
registry
will
in
the
end,
have
ten
thousand
hundred
thousands
of
entries,
so
we
have
to
make
sure
that
ini
can
actually
handle
that.
As
far
as
I
understand
you
have
discussed
this
with
Michelle
to
some
extent.
Yes,.
Q
So
we
discussing
with
Michelle-
and
she
was
basically
also
always
saying
well,
you
know
just
get
the
Lascaux
we're
pretty
happy
with
most
of
the
things
that
are
that
are
out
there
and
we
just
want
some
more
feedback,
but
they're
pretty
happy
with
the
things
are,
as
they
are
right
now.
So
now,
when
you
say
okay,
we
need
to
specify
a
little
bit
more
this
process.
L
Q
See
it,
you
have
a
module
in
IRC
and
there's
no
for
allocated
what
do
I
do
all
of
the
sudden
yeah
yeah,
but
I
mean
for
me.
This
is
very
very
that
can
be
worked
out,
but
and
if
you
are
able
to
contribute
some
some
text
to
to
that,
actually
to
actually
specifying
the
other
way.
This
behavior
works
and-
and
you
know,
make
sure
that
we
actually
go
and
I
mean
also
you
and
together
we
go
to
Michelle
and
and
make
sure
that
your
text
actually
corresponds
to
something
that
she
considers
not
a
horrible
nightmare.
B
B
B
If
you
hear
him
talking,
it
sounds
exactly
like
me
shares.
So
he
is
like,
like
really
good
stand
and
furnish
every
yet,
but
he
also
knows
a
lot
about
all
this
technology.
So
I
think
he's
also
the
right
person
to
do
this
so
I'm
proposing
that
that
we
add
a
value
to
the
documents
as
an
editor
and
yeah
give
him
a
chance
to
finish
this.
B
Q
So,
as
an
author
of
this
draft
I
support
this
because
it's
see
I
mean
we've
been
like
the
little
epsilon,
the
little
Delta
that
is
really
having
some,
where
someone
every
day.
Thinking
about
this
I
would
be
about
getting
this
finished
and
not
having
been
on
two
continents
and
stuff
like
this.
It's
really
helpful,
so
I
think
that's.
Q
A
B
R
R
You
were
in
selected
likely
to
appear
in
sin
ml
sensor,
name
fields
which
have
been
defined
in
84
28
us
with
a
very
limited
character
set
in
order
to
then
be
able
to
easily
be
lifted
out
and
used
in
various
query
components,
and-
and
basically
this.
This
means
that
it's
it's
not
a
necessary
good
idea
to
include
person
signs.
So
if
we
take
that
out-
maybe
that's
that's
okay,
but
otherwise
this
is
relatively
stable,
as
at
least
us
as
one
considers
two
things
that
are
in
the
draft
today.
R
R
There's
the
OS
and
o-p-s
syntax
for
serial
numbers
and
they're,
not
exactly
in
in
the
same
format
in
this
draft
that
they
were
in
in
the
OMS
spec,
but
I
think
it
makes
sense
for
the
ITF
to
sort
of
try
and
generalize
like
okay
seems
like
a
useful
thing,
let's,
let's
make
sure
that's,
actually
defined
and
fits
with
the
rest
of
the
structure
index
wise.
It
doesn't
use
the
person
signs
and
all
kinds
of
other
things
like
that,
so
we're
making
a
change.
R
We
were
incorporating
some
things
and
we
have
been
trying
to
ask
if
there's
people
who
would
be
impacted
by
that,
we
haven't
found
any
but
I,
don't
know
if
we
reached
everybody
so
now
we
could
turn
to
shout
if
any
of
that
causes
heartburn
for
you.
I
should
also
mention
that
there
are
some
other
types
in
this.
R
These
are
my
specifications
that
we
did
not
deal
with
and
there
might
be
some
opinion
that
we
should
deal
with
some
of
that.
So
there's
a
couple
of
things
there
they
refer
to
the
NAI.
You
were
in
type
that
doesn't
exist
anymore,
nobody's
defined
that
it
felt
a
little
bit
like
that's,
not
our
or
in
it's
not
a
great
fit
for
this
draft,
but
it
might
be
every
useful
thing
perhaps
to
do
and
then
there's
some
other
things
that
maybe
at
least
on
last
time,
I
looked
at
it
might
need
some
slight
adjustment
there.
R
There
are
some
UN
types
that
can
be
used
for
some
of
these
things
like
maids,
anime
and
so
forth.
But
at
least
one
might
look
that
the
zoomtext
isn't
didn't
seem
to
be
exactly
correct
at
the
spec
at
the
time
that
I
looked
at
it
so
I
guess
the
question
is:
where
do
we
stop
like?
Do
we
stop
here
or
do
we
add
something
and
I?
You
know
I'm,
just
editing
this
draft,
it's
up
to
you
guys
to
say
what
should
we
do
so
I'll
leave
it
at
that
and
open
it
up
for
comments.
M
Thank
you
Gary.
This
is
Mattias
Simmons,
so
there's
something
I
contacted
you
I
think
to
IDF's
ago.
So
the
context
is
I'm
active
in
the
w3c
at
this
web
of
things
working
group
and
the
background.
Is
there
a
lot
of
kind
of
companies
who
don't
have
this
detailed
background
in
Internet
and
web
technology,
but
they
want
to
kind
of
move
there.
M
One
one
thing
I
saw
is
that
they
wanted
to
have
something
like
your
ends
and
use
them,
but
they
didn't
know
that
there
is
something
in
the
beginning
that
basically
defines
how
you
can
use
them.
So
there
was
things
like
a
UN
:
company
name
and
then
a
common
pattern
was
something
like
the
Java
package
names
to
have
like
an
easy
way
to
construct
something
that
is
unique
but
kind
of
intuitive
and
so
on.
M
R
I
think
we
have
that
easy
way,
because
we
have
this
organization
and
serial
number
and
and
so
on,
based
options
here.
So
if,
if
you
can,
you
know
bother
yourself
by
registering
a
Enterprise
number
from
Ayana,
which
would
be
really
easy,
like
basically
an
email
or
fill
in
a
template,
then
then
you
can
stick
that
into
the
right
branch
here
and
then
do
whatever
afterwards
yeah
and
exactly.
M
M
So
I
don't
have
my
own
agenda
on
this,
so
I
want
to
bring
it
up
to
basically
get
some
more
input.
How
we
should
do
this,
so
I've
been
going
around
to
to
people
who
started
viewing
using
your
ends,
especially
internally
in
the
company
and
point
to
this
draft
like
pick
something
that
works
correctly.
I
use
the
UUID.
If
you
use
uu
IDs
there,
but
don't
it's
it's
not
a
free
format
that
you
can
choose.
M
R
M
This
meta
question
is:
if
there
is
some
feedback
on
should
we
have
something
like
the
Java
package
named
style,
where
you
can
use
your
own
domain
name?
That,
basically,
is
unique.
That's
why
it
was
chosen
there
and
then
construct
something
tech
space
that
fits
your
needs
or
yeah.
If
you
should
have
to
the
stronger
push
back
and
and
educate
people
here,
do
it
that
way
and
then
maybe
improve
the
document,
as
you
suggested,
that
is
kind
of
the
really
free
steps
explanation
how
to
get
it.
R
B
Really
helps
to
have
examples
in
the
document,
so
one
quick
comment
I
would
like
to
make
about
enterprise
numbers
is
that
in
some
organizations
it's
really
difficult
to
get
control
over
what
you
are
supposed
to
do
with
an
enterprise
number
I
mean
imagine
Siemens.
This
is
a
big
organization.
Then
somebody
has
this
enterprise
number,
and
are
you
allowed
to
use
this
enterprise
number
in
a
specific
context?
That
requires
some
work.
Yeah.
M
Yeah,
maybe
multiple
ones,
but
you
have,
for
instance,
between
Siemens.
It
would
be
really
hard
to
know,
like
who's
actually
person
responsible
to
register
this.
Who
is
then
allowed
to
use
that?
What
is
the
process
to
have
some
Sabbath
under
that
because,
like
there
is
the
the
brand,
then
there
are
these
different
divisions
and
kind
of
what
I
saw
is
that
the
divisions
figured
out
how
to
do
the
domain
registration,
so
these
subdomains
that
works,
that's
something
that
is
established.
The
other
thing
is
not
so.
R
I
Put
my
part
from
Nokia:
we
had
an
exchange
earlier
on
the
lightweight
machine
to
machine
so
basically
on
the
NAI
and
Amir
I
mean
MZ,
etc.
These
combinations
are
all
used
under
the
lightweight
m2m
tears,
under
the
assumption
that
these
are
device
identifier.
So
it's
like
you
are
n
the
needs
which
are
being
brought
in
by
different
operators.
So
there
isn't
so
it
is
used
within
the
network
and
under
the.
U
RN
:
do
with
this
kind
of
identifier
like
IM
e
MZ,
so
so.
R
My
understanding
is
that
the
the
the
spec
refers
to
multiple,
u
RN
types
like
that
day
viewer
and
is
one
of
them,
but
there's
also
others
like
UUID
and
and
and
so
on,
and
and
then
the
only
way.
There's
no
question
about
that
and
that
that
seems
very
sensible
and
and
so
on.
But
but
then
there's
some
that
haven't
been
defined.
R
It's
like
you
need
to
either
fall
into
this
draft
that
we're
discussing
here
or
some
other
draft
somewhere
and
and
some
that
like
might
need
some
small
editing
in
the
in
the
spec,
because
they're
pointing
to
the
like.
The
string
is
wrong
that
you
stick
in
front
of
the
identifier
and
because
this
be
defined
by
3gpp
and
other
RFC's
in
the
ITF
previously
like
I'll,
this
MC
stuff
and
so
on.
Yeah.
I
I
agree
to
that
I
mean
some
of
this
should
needs
to
be
added.
But
in
the
context
of
this
you
are
on
:
dev.
Can
we
extend
your
n
:
dev
with
all
these?
What
are
part
of
that
network
and
it's
a
device
identified,
so
it
could
be
like
in
nai,
or
it
could
be
anything
what
that
network
would
like
to
use
beyond
that.
You
are
n
:
diff.
I
R
I
R
So
again,
I'm
just
editing
this
thing
you
guys
tell
me
what
to
do.
My
personal
opinion
is
that
we
should
probably
not
mix
the
fact
that
we
are
you
doing
IOT
with
that
sort
of
the
identity.
For
us
we
did
like.
We
have
different
types
of
identifiers
and
we
use
them
for
different
purposes.
Sometimes
it's
an
IOT
device.
R
Sometimes
it's
something
else,
and
so,
let's
just
define
all
the
all
the
ones
you
know,
possibly
in
one
or
multiple,
you
are
n
types,
but
we
shouldn't
necessarily
try
and
do
everything
under
the
dev
you
are,
and
that
seems
personally,
but
but
then
there's
like
the
question
of
the
nai,
which
we
you
and
I
discussed
like
what
to
do
with
that.
Should
we
have
somebody
else,
drive
a
draft
on
that
or
stick
it
in
here
or
forget
it
or.
I
E
E
E
M
Mattias,
so
yeah
I
think
there
might
be
an
informal
document
about
that.
That
explains
what
are
your
ends
and
how
do
you
use
that
and
I
mean
it
doesn't
help
that
there
is
a
death
in
the
end,
and
you
know
art
is
to
identify
in
device
because
it's
kind
of
at
two
different
levels
where
it
is
I
kind
of
what
is
using
be
identifies,
and
then
you
only
need
unique
ones
and
it
doesn't
have
to
be
in.
You
identify
itself
for
what
you
are
using.
It
I.
R
Actually
give
some
credit
for
the
light
wave
into
an
document
on
that
that
record
I
mean
they
actually
try
to
identify
that.
These
are
the
things
that
we
need
in
the
industry,
and
I
mean
that
the
only
problem
with
that
is
is
that,
okay,
it
shouldn't
point
to
things
that
don't
exist.
If
they
don't
exist,
we
should
either
get
rid
of
them
or
define
them.
B
B
S
Hello,
everyone.
So
let
me
just
briefly
go
through
the
use
case
yeah,
so
we
were
working
on
a
real
business
problem.
The
problem
was
that
in
many
cases
people
want
to
stream
the
live
first-person
view
over
internet
over
IP
to
do
certain
intelligence
for
operations
in
warehouse
or
for
some
monitoring
or
for
defining
the
path
that
a
dump
robotic
terminal
should
take
remotely,
so
that
is
called
visual
slam,
so
visual,
simultaneous
localization
and
mapping.
So
now
the
thing
is
that
the
experience
is
the
existing
technologies
that
are
used
for
streaming
causes.
S
Certain
kind
of
I
mean
video
freezes
and
lots
of
problems
happen
because
of
non
real-time
Ness
and
on
non
guarantee
in
delivery
and
all
these
things.
So
when
this
problem
came
to
us,
we
kind
of
look
back
into
where
and
what
we
realized
is
that
probably
we
can
look
at
crap
from
this
angle
also,
so
one
side
we
have
HTTP
on
TCP,
and
that
is
the
de
facto
standard
right
now
for
streaming
over
the
public
Internet
right.
They
some
some
or
other
variation
using
adaptive
bitrate
on
top
of
that.
S
But
the
core
thing
is
HTTP
handshakes
right,
so
we
have
restfulness
standardized
API
is
we
have
reliability
in
their
wide
adaption?
We
have
condition
avoidance
on
the
other
side.
If
you
look
at
the
initial
days
since
the
beginning
of
this
millennia,
so
we
had
this
RTP
on
UDP,
which
guarantees
real-time
this,
but
reliability
is
missing.
Now.
If
we
combine
these
two,
we
see
that
co-op
is
restful.
Co-Op
has
both
the
options,
so
you
can
change
between
optionally,
between
reliability,
delivery
and
based
effort
delivery,
and
because
no
response
actually
gives
you
the
open-loop
delivery.
S
So
we
have.
We
can
marry
the
best
of
these
two
words
using
intelligently,
so
the
idea
is
that,
can
we
have
something
that
is
equally
good
in
sending
small
sensor
data
as
well
as
streaming,
video
or
a
time
series
streaming?
Can
you
have
something
like
a
counterpart
of
HTTP?
So
HTTP
is
while
it
is
giving
you
web
services
normal
web
services?
At
the
same
time,
it
is
not
treating
video
as
a
special
special
care
type
of
data,
and
it
is
streaming
video
with
the
same
infrastructure.
S
So
can
we
have
something
for
these
scenario
because
in
many
cases,
the
dump
terminals
which
are
moving
around
across
warehouses
or
in
different
fields
or
for
some
remote
maintenance?
They
are
also
sending
some
small,
tiny
sensor
data
as
well
as
well
as
they're,
sending
the
first-person
view
so
that
the
person
sitting
at
the
control
room
can
do
something.
So
I
will
not
go
through
much
details
because
to
honor
the
time
so
we
made
certain
extensions.
I
will
directly
go
to
the
results
and
experiments.
You
please
go
through
the
draft
if
you
are
interested.
S
These
are
few
headed
extensions
that
we
have
kind
of
borrowed
because
we
want
to
relate
segments,
so
it
is.
It
is
following
the
same
methodology
as
the
progressive
download
or
for
what
we
had
for
HTTP
streaming,
the
basic
technology.
That
is
the
same
thing
we
are
using
so
chunk,
and
what
we
are
doing
here
is
that,
based
on
the
criticality
of
the
current
Chang,
what
is
the
criticality
of
the
segment
that
is
being
delivered?
S
Does
it
transfer
certain
important
metadata
or
there
may
be
several
other
criterias,
and
that
depends
on
the
context
we
are
deciding
whether
to
go
for
based
based
effort,
delivery
or
whether
to
go
for
reliable
delivery.
So
that
way
we
can
maintain
a
balance
between
your
reliable
delivery,
real
tennis
right
and
the
other
thing
is
that
if
you're
receiving
end
does
have
enough
computing
capacity,
so
you
have
100%
reliable,
made
the
metadata
and
critical
information
and
based
on
the
loss
probability
of
the
channel.
You
have
certain
part
of
the
critical
non
critical
information
combining
these
two.
S
You
can
actually
predict
the
whole
frame
so
that
technology
is
available
and
many
people
working
on
image,
processing
and
video
processing
are
actually
using
that
and
also
if
you
are
not
able
to
send
the
critical
information
drop
the
whole
frame
so
that
we
are
implicitly
condition
here,
avoiding
the
condition.
Implicitly
we
did
certain
these
are
the
Hanshin
see
will
find
them
in
okay.
So
this
is.
S
This
was
our
setup,
so
one
thing
we
did
is
for
open
Internet
for
different
abilities,
so
we
had
raspberry
PI's
where
we
installed
the
program,
so
one
had
HTTP
streaming,
one
had
aerialist
and
this
guy
was
sitting
at
this
end.
He
is
working
with
me
and
we
are
streaming
this
over
an
emulated
network
setup
and
we
are
trying
to
get
the
data
on
three
different
interfaces
here
over
were
shocked
and
there
was
another
thing:
was
we
try
to
create
a
realistic
loss
model?
S
So
there
is
an
an
AV
moving
around
a
work,
a
warehouse
and
there
is
an
obstruction,
radio
of
section
which
is
creating
some
shadowed
area
and
probably
for
three
seconds.
It
takes
to
cover
this
area
for
two
or
three
seconds
and
we
are
getting
a
radio
I
mean
zero
radio
zone
over
there,
so
just
to
come
with
this.
So
this
is
what
we
are
getting
is
very
excellent
result
using
by
streaming
in
on
fire.
So
one
thing
to
and
we
compared
with
RTP
as
well,
we
have
not
produced
the
result.
S
Rtp
is
not
giving
us
good
psnr
because
of
the
reason
that
if
the
metadata
gets
lost,
you
have
no
mechanism
to
retrieve
it.
But
in
case
of
where
you
have
some
chances
of
retrieving
the
meta,
so
we
were
getting
better
sanity
in
terms
of
reception
of
frames
and
in
terms
of
reception
of
or
in
terms
of
reproducing
the
frames
at
the
receiving
end,
and
this
is
also
another
experiment
that
we
did
with
real
ApS,
the
mobile
aps
that
we
have
in
India.
So
so
this
is
the
topology,
and
this
guy
is
holding
the
AP.
S
It
is
close
to
the
raspberry
PI's,
and
now
this
guy
is
moving
out
so
as
he
is
moving
across
the
region.
What
we
have
is
it
drop
in
the
RSSI
receive
signal
strength,
and
what
we
see
is
that
when
it
is
in
this
region
there,
the
HTTP
stream
or
the
standard
streaming
mechanism,
it
kind
of
freezes
at
that
point
of
time,
and
then
when
this
guy
starts
to
move
back
to
the
same
place
and
we
were
actually
holding
a
stopwatch,
I
mean
I
was
holding
the
stopwatch
and
so
and
we
were
recording
the
time.
S
S
If
I
use
RTP,
then
what
will
happen
is
at
least
I
lose
more
of
the
frames.
In
this
case,
we
just
work
with
JPEG
streaming.
One
of
the
reason
for
our
motion,
JPEG.
One
of
the
reasons
for
using
motion
JPEG
is
that
we
wanted
to
avoid
the
complexity
of
time
compression
in
these
case,
and
the
other
thing
is
that
in
many
cases
to
take
the
decision,
the
decision
logic
uses
information
in
the
frame,
so
they
have
to
reconstruct
the
frame
and
do
the
image
processing
to
extract
the
information.
S
So
if
I
am
transferring
the
motion-
JPEG,
maybe
I'm
not
at
that
high
frame
rate-
maybe
I
am
in
this
case
we
send
I,
think
five
or
six
frames
per
second,
but
that
was
when
he
spoke
to
the
engineering
Treeing
who
are
working
out
wrong.
They
said
that
it
is
quite
good
for
them
to
I
mean
do
a
survey
or
do
a
scanning,
or
things
like
that.
S
So
I
request
you
to
please
go
through
the
draft
and
if
you
have
any
comments
and
what
I
think
is
that
this
kind
of
work
will
go
well
with
the
to
many
responses
and
some
of
the
streaming
or
time
series
related
contributions
that
are
going
on
in
T
to
PRT
as
well
as
in
this,
and
that's
it
from
my
side.
I
think
T
is
waiting.
S
B
Thank
you
so
I
think
it's
really
interesting.
There
are
ways
can
be
used
that
I,
wouldn't
have
dreamed
of
and
I
think
we
probably
have
the
research
group
where
we
can
look
at
some.
Some
of
these
aspects
as
well
and
I
think
we
should
find
how
these
customers
from
management
from
from
this
is
not
exactly
video,
it's
a
slightly
different
kind
of
video,
but
how
they
actually
fit
into
our
ecosystem
and-
and
we
had
the
dots
people
here.