►
From YouTube: IETF105-CORE-20190725-1000
Description
CORE meeting session at IETF105
2019/07/25 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
So
on
Tuesday,
we
already
agreed
that
we
will
massage
this
agenda
a
little
bit
and
and
move
fazer
early
and
because
it's
so
hard
to
change.
My
slides
I
decided
to
redefine
time
instead,
so
10:30
comes
before
10:00
today.
So
we
will
mostly
talk
about
group
communication
multicast
things
like
that
for
the
first
hour.
A
A
A
A
Ten
years
ago
we
had
the
six
low
ab,
bob
of
which
was
pretty
legendary
because
we
had
actual
beer
in
a
meeting
room.
So
we
had
an
extra
bar
buff
in
a
meeting
room
that
was
organized
by
zeg
heavy.
Who,
essentially,
is
the
man
who
who
made
co-op
happen,
and
it
was
a
bob
of
in
Stockholm,
so
I've,
no
idea
how
much
money,
since
you
know
it
has
paid
for
that,
but
fortunately
I'm
bought
that
at
some
point,
so
they
got
the
money
back.
A
It
was
an
interesting
bob
off
because
there
were
at
least
five
area
directors
in
the
room,
I
think
even
more
I.
Don't
don't
have
the
exact
count
right
now
and
that's
where
we
decided
to
do
the
application
layer
for
6lowpan.
We
would
start
working
on
an
application
layer
protocol
and
not
try
to
define
a
transfer
protocol,
and
the
reason
for
the
letter
was
that
we
thought
it
would
take
ten
years
to
do
that.
A
Now,
then
those
ten
years
are
over,
so
the
transfer
protocol
would
now
be
done
and
I
would
not
be
available,
but
maybe
a
little
bit
too
late
to
make
a
difference
anyway.
So
this
happened
10
years
ago
and
took
about
half
a
year
until
we
sufficiently
understood
our
requirements
to
either
draft
published
on
December
24th
2009.
So
you
you
either
do
things
on
my
birthday
or
you
do
it
on
Christmas
I
think
this
is
a
good
tradition.
We
should
try
to
pick
up
again.
The
working
group
was
established
in
March
of
the
following
year.
A
That's
also
a
relatively
normal
period
for
the
ITF,
and
it's
interesting
to
see
that
we
actually
got
our
draft
approved
four
years
after
the
initial
bob
off
so
I
think
that's
already
pretty
good
I
mean,
given
that
we
really
did
this
from
our
cloth
this.
This
is
an
interesting
development
time
and
then,
of
course,
we
got
held
up
for
another
year
by
a
normative
reference
to
a
security
area
draft
that
was
stuck
in
some
absolutely
meaningless
squabble,
but
that's
a
story
on
it.
A
So
if
you
think
about
when
co-op
was,
was
done,
the
birthday
of
Webb
that
was
2013
6
years
ago,
and
then
we
just
had
to
wait
for
a
year
for
office
politics
reasons
anyway,
I
thought
I
would
throw
this
in
who
was
present
in
that
first
year.
I
know
that
Klaus
was
making
first
comments
on
some
email
from
him.
A
B
This
future
to
the
new
draft,
with
ESCO
as
an
update
to
7390,
so
to
delegate
this
kind
of
check
to
co-op
itself,
and
if
we
do
that,
then
it's
just
no
need
to
do
it
again.
In
group
ascore,
then
we
have
extended
a
bit.
The
actual
message
protection
part
introducing
two
externally
ATS
used
to
be
one.
Only
before
for
encryption
and
signature
of
messages,
we
essentially
extended
the
first
one
with
additional
parameters
related
to
the
context,
signature
algorithm
and
his.
B
Then
we
created
a
second
one
to
be
used
for
the
signature
process
only
where,
in
addition,
we
further
added
the
value
of
the
oscar
option
that
they
somehow
protected
also
going
directly
to
the
country's
insurer.
Now
we
agreed
already
on
further
manual
improvements
on
this
encoding,
but
the
big
thing
is
now:
we
have
two
different
external
IDs.
B
That
was
the
result
of
very
good
and
long
discussion,
especially
with
challenging
also
the
security
considerations
continuing
with
a
number
of
sections
essentially
aligned
with
the
respective
ones
you
had
in
the
Oscar
document.
Already
there
are
a
few
open
points
some
earn
well.
Where
is
before,
and
not
exactly
close
now
right
now
we
are
mandating
to
implement
it
say
it
did
say
with
the
2509
curve.
B
We
wonder
if
this
is
the
right
choice.
If
we
should
mandate
more,
there
are
more
details
in
issue
7
the
data
from
John.
We
mostly
need
feedback
from
deployers
on
this
because
from
a
street
photography
point
of
view,
we
wouldn't
make
this
big
difference.
Otherwise
we
would
likely
stick
to
the
other
curve.
A
So
the
the
interesting
observation
is
that
we
have
mandatory
to
implement
algorithms
in
in
the
base
call
document,
and
that
is
ECDSA
pasted
at
the
moment,
via
twenty,
seventy,
nine,
thirty,
five
and
so
on,
and
if
we
want
to
move
to
a
different
set
of
preferred
curves,
that
probably
should
be
done
in
a
coordinated
fashion.
So
so
I
would
say
it's
the
correct
thing
to
say
ECDSA
now,
but
it's
all
it's
all
a
little
bit
of
a
push
to
one
small
thing
is:
it
may
be
time
to
move
to
a
different
default
and
I.
A
Don't
have
the
answer
on
that
and
we
were
probably
not
going
to
discuss
it
today,
but
I
think
it's
a
good
thing
to
do.
A
really
a
reality
check
again
what
what
we
can
do
in
implementations
today
and
very
we
want
to
see
this
go
so
my
assumption
here
is
that
it's
there
is
no
overwhelming
technical
advantage
of
one
over
the
other.
D
A
B
We
are
given,
in
principle,
total
freedom
about
that
to
the
group
manager
to
define
it,
but
we
are
also
providing
an
example
as
an
appendix
to
structure
the
group
identifier
in
two
parts,
a
constant
prefix
that
never
change
and
the
network
that
is
essentially
incremented
every
time.
The
key
material
is
register
buted
in
the
group.
B
B
B
B
One
is
about
the
management
of
group
identifiers,
of
course,
by
the
group
manager
and
right
now
we're
saying
that
in
the
terminology
section,
actually
they
should
be
unique,
just
non
normative,
even
within
the
set
of
the
whole
of
all
the
groups
under
the
same
group
manager,
and
the
comment
was
well.
Why
don't
we
just
demand
that?
Why
is
it
not
just
that
way
now,
if
it's
different
group
manager,
there's
nothing,
you
can
do
fundamentally,
you
can
have
collisions.
B
Of
course,
if
the
group
managers
are
non
synchronized
and
you
just
have
to
live
with
it
and
handle
them
at
the
application,
but
under
the
same
group
manager,
perhaps
we
can
actually
use
at
least
a
normative
sure
to
say
that
a
sane
group
manager
should
not
assignment
the
same
time
the
same
group
ID
to
two
or
more
different
groups.
So
this
makes
to
me
at
least
I.
C
C
E
B
B
The
client
still
has
still
has
the
old
one,
so
his
law
in
switching
to
doing
one,
the
client
protects
a
request
with
the
old
context
sends
it
and
it
gets
the
server
when
the
server
has
already
fully
established
the
new
context.
If
we
stick
to
that,
of
course,
the
processing
of
the
server
would
fail
and
there's
an
error
message
returned,
but
in
the
section
we
we
are
admitting,
though
highlighting
is
not
exactly
good
to
do
that.
A
F
G
F
Okay,
I'll
try
anyway,
so
I
think
a
much
better
solution,
but
perhaps
I
overlooked
some
problem
with
that
say
you're
this
client,
who
is
using
this
old
context
and
has
just
sent
the
request
with
the
old
context,
and
then
you
discover
this
this
new
context.
Why
not?
Just
instead
of
saying
you
can
keep
old
context
around
just
say
if
you
just
send
a
request
with
the
context
that
gets
renewed,
then
within
a
certain
time
frame,
you
just
resend
your
your
request
with
the
newer
context.
B
E
Franchesca
from
from
the
floor
also
for
implementations,
I
think
you'd
be
crossing
the
security
layer
and
the
application
layer,
because
you
need
to
know
okay,
I'm,
keeping
that
context
I
just
repeat,
which
means
that
now
the
application
will
have
to
send
the
second
request.
I'm,
not
sure.
That's
a
good
idea.
E
F
B
H
B
E
H
In
mind
here
is
I
think
we're
trying
to
get
at
and
that
doesn't
really
work
with
ludwig's.
The
proposal
is
that
rekeying
or
making
new
contracts
distributing
them
takes
a
long
time
possibly
so
there
has
to
be
a
lot
of
forgiveness.
It's
not
like
oh
I,
just
sent
that
and
I
got
a
new
one.
Well,
I
better,
send
it
again.
It
might
be
minutes
or
longer
for
everybody
to
get
the
new
car.
H
So
you
this
it's
a
difficult
problem,
but
but
I
think
having
the
receivers,
have
overlapping
and
accept
either
one
within
a
reasonable
time
frame
to
allow
everybody
to
get
up
to
speed,
oh
you're,
using
an
old
key.
Well,
let's
find
it's
been
ten
minutes,
that's
cool,
or
even
an
hour
or
a
day,
I,
don't
care
what
it
is.
That's
application
dependent
whatever
your
security
gun,
but
you
have
to
allow
the
protocol
to
allow
a
lengthy
review
process
or
redistribution
I
mean.
A
D
Beautiful
stuff
I'm
not
so
much
worried
about
the
security
as
about
the
ordering
of
the
messages,
because
so
messages
should
not
be
allowed
on
the
vulnerability
core
set
of
keys
and
on
the
other
box.
So
if
you
have
several
key
sets-
and
you
want
to
go
to
the
new
one,
then
you
should
not
allow
any
messages
with
the
new
city
set
before
you
have
to
lift
out
all
vista
up
old
key
set.
Otherwise
you
have
an
inconsistent
message
sets
and
you
may
have
problems
efficient
applications.
C
Jumpshot
one
of
the
problems
we
have
in
terms
of
dealing
with
key
location
is:
we
do
not
currently
have
any
sort
of
standardized
way
of
a
KDC
even
telling
people
that
the
key
has
rolled
over
it.
Just
kind
of
happens
in
an
ad
hoc
way.
I
think
we
should
not
forbid
the
eff
that
the
server
to
retain
the
old
context,
but
I
think
we
should
give
it
the
option
of
returning
a
not
authorized
if
it
decides
that
the
key
context
is
no
longer
acceptable
for
his
application
purposes.
B
Okay,
good
and
we
have
also
good
news
from
the
hackathons
we
came
here
with
three
implementations
from
rice,
Peter
and
Jim
we're
an
interrupt
test.
According
to
a
plan
we
can
find
here
linked
on
the
Eric's
on
github.
More
results
would
be
published
on
the
list.
As
an
actual
report,
we
managed
to
cover
most
from
the
test
specification,
all
the
run
tests
where
we're
fine,
somewhere
remaining
due
to
lack
of
time
as
to
optional
features
to
be
tested,
the
next
a
cat,
hopefully
as
next
steps.
B
Well,
we
would
like
to,
of
course
amend
the
pending
comments
in
the
text
and
trying
to
wrap
up
also
these
open
points
after
this
discussion
and
possible
follow-ups
on
the
main
list.
Also,
we
had
to
make
some
updating
the
text
based
on
latest
discussion
with
Jim
about
again
the
exact
format
of
the
external
ad
and
just
clarified
that
it's
really
up
to
the
group
manager
to
say
that
the
form
of
the
public
is:
are
fine,
they're
consistent,
be
using
that
group.
B
A
B
I
A
In
Europe,
of
course,
we
we
have
vacation
period
coming
up,
which
will
be
interesting
for
the
class,
because
no
French
person
will
be
able
to
answer
that
because
it
will
be
entirely
in
August,
but
I
think
September
is
level
okay.
So
let's
shoot
for
September
as
the
working
class
go
period
of
this
great
next,
then
your
next.
B
Okay,
an
update
on
this
at
other,
draws
very
much
related
to
grupo
score
version
3.
Just
as
a
quick
recap,
we
we
thought
of
this
thinking
of
a
new
device
deploying
the
field
has
to
join
a
group
where
communication
is
secured
with
a
group
of
score
and
has,
in
the
first
place,
to
find
out
the
group
practically
found
out
the
group
manager
and
its
general
resource
to
access
the
group,
and
we
talked
about
way
to
achieve
this
using
the
the
core
resource
directory.
B
So
the
idea
is
that
the
group
manager
registers
itself
and
it's
joy,
resources
in
the
resource
directory
and
then
later
on.
A
journey
node
can
find
the
links
to
those
joy
resources
and
later
on
approach,
the
group
manager
to
join
the
group-
and
this
is
by
the
way,
a
landline
consistent
with
the
approach
we
have
for
joining
oscar
groups
in
a
is
in
a
separate
document
and
what
we
use
for
the
join
notes
here.
It's
simple
resource
lookup.
B
So,
in
fact,
looking
for
the
jury,
sources
of
the
group
manager-
and
this
is
essentially
intended
for
a
scenario
like
this-
where
you
start
defining
application
groups
as
collection
of
resources
shared
by
multiple
endpoints,
and
then
you
can
map
one
or
multiple
application
groups
to
a
same
security
group
in
this
case
all
score
group.
That
is
the
same
set
of
key
material
and
then,
of
course,
you
have
a
special
request
running
over
multicast.
B
B
We
believe
this
fully
enabled
this
approach
as
one
of
the
approaches
described
in
the
ACE
document
about
the
joining
to
know
very
much
in
advance
how
the
group
works
essentially
in
terms
of
algorithms,
and
if
you
know
that
so
in
advance,
you
can
essentially
avoid
having
any
specific
interaction
about
this.
With
a
group
manager
like
explicitly
or
by
a
trial
and
error.
You
have
also
second
advantage
upon
performing
this
discovery.
B
The
jury
not
can
just
find
out
that
the
group
works
according
to
algorithms,
that
it
doesn't
support
and
can
just
decide
to
give
up
and
forget
about
joining
the
group
all
together,
a
few
Willis,
a
minor
or
open
points
about
this.
We
are
defining
target
attributes
here
and,
of
course,
you'd
be
ideal
to
register
them.
But,
as
you
know,
there's
no
registry
to
register
target
attributes.
B
Like
a
few
months
ago,
Haim
I
started
document
or
a
wiki
to
collect
existing
target
attributes
here
and
there
what
they
are
used
for,
and
so
on,
I
like
to
believe
with
intent
to
think
more
of
a
possible
registry,
and
then
I
remember
a
few
Corinne
three
meetings
ago.
Just
mentioning
it
was
considering
to
revise
a
few
related
registers
about
this.
So
I
wonder
if
putting
all
this
thing
together,
possibly
that
there
is
enough
critical
mass
to
think
of
a
registry
for
target
attributes.
I
would
like
to.
C
B
C
B
A
So
this
child
has
an
opinion
on
that
resource
directory
is
an
application
we
have
defined
here
the
call
working
group,
but
not
everything
that
uses
that
application
has
to
be
defined
in
the
cover
group.
So,
given
that
the
the
the
subject
matter,
the
content
of
that
registration
is
mostly
security,
stuff
I
could
very
well
imagine
doing
this
in
the
yes
looking.
C
E
C
D
Beautiful
stoke:
it's
not
that
I
prefer
link
format
of
a
coral
or
vice
versa,
but
I
think
that
the
people
who
might
use
it
in
the
future
in
the
short
term
say
two
years
that
those
will
be
more
used
to
link
format
than
to
coral.
So
if
you
want
to
encourage
the
use
and
I
think
link
form,
it
should
be
a
part
and
a
coral
and
second
language,
mm-hmm.
E
A
Well,
we
can
just
do
the
work
wherever
the
thing
is
at
the
moment,
so
I
have
no
idea
what
the
ace
chairs
think
they
need
to
do
to
pull
this
over
whether
there
needs
to
be
another.
Adoption
call
how
you
plan
to
handle
that,
but
we
don't
have
to
wait
for
anything
of
this
to
happen.
We
will
just
go
forward,
so
you
next
job
is
to
make
the
videos
right.
C
A
A
A
B
B
We
we
thought
this
to
rely.
Essentially
you
have
the
observers
to
7640.
One
is
an
unicast
registration
request
and
you
get
after
that
and
notifications
over
unicast
in
the
update
to
7390
base.
We
are
actually
defining
well,
you
can
send
a
registration
request
over
multicast
able
to
target
multiple
servers
and
you
will
you
will
get
from
each
of
them
unique
as
notifications.
So
we
talked
of
the
next
step.
What,
if
you
have
many
clients,
observing
the
same
resource
on
a
given
server?
B
This
is
true
in
general,
the
moment
you
have
many
observers
on
the
same
server,
but
we
have
a
very
practical
use
case
that
was
discussed
at
the
hallway
meeting.
We
had
in
Prague
covering
different
aspects
of
pub/sub,
including
this
one
is
it
possible
to
make
it
more
efficient
through
multicast,
and
there
were
four
proposals
and
number
four
was
the
only
one
that
was
considering
in
fact
moved
the
cast
responses.
That,
of
course,
don't
exist.
They
all
have
the
advantage
not
only
to
use
multicast
for
the
sake
of
performance,
but
also
to
keep
subscribers
client
only.
A
A
Yeah,
of
course,
another
problem
with
observe
and
mighty
health
response
is
that
multicast
this
cannot
be
reliable.
So
it's
hard
to
do
remote,
your
consistency
without
doing
some
form
of
keep
a
live
thing,
but
I
think
that
that's
easy
to
fix
much
I
think
managing
the
token
space
is
more
difficult,
nd.
The
interesting
observation
years,
of
course,
that
the
client
of
a
multicast
response
is
the
group.
A
J
Stm's
is
on
that
particular
comment
on
the
client
management
of
the
tokens.
I
think
they
are.
What
matters
here
is
that
we
defined
tokens
for
I
mean
tokens
token,
and
the
the
scope
of
tokens
is
also
related
to
the
to
the
addresses
involved
and
so
far,
the
all
definitions,
that
for
tokens
related
to
addresses
where
the
client
is
the
unicast
and
things
are
a
bit
different
when
the
client
is
a
multicast
thing,
so
we
may
want
to
have
an
extended
definition
of
of
who
is
responsible
for
the
token
management
in
that
case.
E
K
Want
to
briefly
explain
why
this
slide
makes
a
lot
of
sense
to
me
as
an
approach,
and
when
we
define
the
original
group
comm
draft,
we
were
quite
possible
for
a
while.
Why
does
it
actually
mean
to
do
a
multicast
request?
I
mean
yes,
you
can
easily
send
a
multicast
message
that
contains
a
request,
but
what
does
it
mean
in
terms
of
rest
and
at
some
point
we
came
up
with
this
fiction.
K
That
is
basically,
we
are
sending
the
same
identical
request
unicast
to
every
member
of
the
group,
and
then,
of
course,
we
would,
as
per
normal
co-op
specification,
get
a
unicast
response
for
each
and
we
just
optimize
these
many
many
identical
unicast
requests
by
using
a
multicast
message
and
said
my
the
fiction
is,
is
actually
unicast
requests.
There
just
happened
to
be
so.
This
makes
a
lot
of
sense
to
me
because
it's
using
the
same
fiction.
K
Essentially,
there
are
lots
of
clients,
they're
going
to
receive
notifications,
and
so
each
of
them
would
observe
the
Resource
Center
request,
and
if
each
of
this
guy
on
sends
the
100%
identical
request,
including
the
token
then
you
can
optimize
that
using
a
multicast
message.
This
is
where
this
proposal
came
from
at
last,
ITF
I
think
we
had
this
discussion
in
the
heck
aslam
well
yeah.
A
A
B
Okay,
thanks
I'll
continue
giving
a
bit
more
details
on
the
two
aspects
separately,
so
I
first
thing
without
security,
focusing
on
the
token
synchronization
a
few
assumptions.
First,
we
are
assuming
here
that
the
client
knows
that
that
resource
observe
is
that
server?
We
assume
that
the
clients
note
the
right
multicast
IP
address,
to
listen
to
just
nothing
right
now
about
possible
discovery
problems
that
can
be
solved
somehow
differently
anyway,
and
thinking
also
grupos
core.
B
We
assumed
that
all
the
clients
and
the
server
have
already
previously
joined
the
right
of
score
group,
and
that
can
also
be
discovered.
Well,
you
saw
how
the
token
overriding
is
essentially
enforced
through
a
new
co-op
option
override
token
that
the
server
includes
in
the
first
unicast
notification
sent
to
each
client
of
course,
indicating
the
very
same
value
to
any
other
following
client
to.
E
B
Registering
to
that
resource,
so
it
essentially
replies,
of
course,
with
the
response.
Justö
can
value
matches
the
token
value
of
the
request,
but
then
it's
saying
from
now
on
you're
going
to
get
multicast
notifications
that
will
have
the
token
value
I
indicate
in
this
option,
and
this
is
the
token
value
for
this
observation.
B
Overall
I
don't
go
into
details
when
it
comes
about
proxies,
but
we
have
a
section
in
the
draft
describing
how
this
can
just
be
reapplied,
hope,
I,
hope
and
Yuki.
You
can
keep
consistency
all
the
way
back
to
the
clients.
This
option
needs
to
be
class
Hugh
for
a
score,
essentially
because
of
the
possible
presence
of
proxies
that
can
take
away
that
instance
and
include
their
own
one
and
of
course,
the
side
effects
of
that
is
just
the
same.
B
You
have
for
a
proxy
messing
up
with
a
main
token
field
of
the
coop
message,
an
example
here:
the
registration
of
the
first
client
approved
by
the
server
that
replies
indicating
a
value
of
F
in
the
override
token
option.
It
easy
a
client
to
registers
and
the
same
option
with
the
same
value
is
included
by
the
server.
And
then
you
have
a
multicast
notification
that
has
FF
s
token
value
and
all
following.
B
To
keep
things
a
bit
safer,
we
are
defining
a
tentative
set
of
ranges
of
token
values
that,
of
course,
are
open
for
discussion
and
changes,
servers
and
clients
that
support
these
mechanisms
should
consider
these
ranges
in
the
sense
that
the
server
must
use.
One
of
these
talking
about
is
to
be
specified
in
that
option
as
overridden
token
values,
while
the
client
must
never
use
one
of
these
token
values
for
outgoing
messages,
with
the
exception
of
the
observation
cancellation-
and
this
essentially
makes
it
possible
for
clients
to
keep
a
few
things
apart.
L
J
I'm
says
I'd
like
to
come
back
briefly
to
the
to
that
fiction
of
the
unique
custom
messages.
So
this
is
something
that
I'm
not
talking
about
the
range
of
token
values,
because
frankly,
I'm
a
bit
behind
on
reading
up
on
why
we
are
having
a
letter
in
there,
but
the
the
token
indicated
back
is
basically
the
server
saying
I.
J
Imagined
that
you
could
have
sent
this
man
from
a
multicast
source
address
and
would
have
used
that
token
and
of
course
you
can
send
from
the
multicast
source
address.
But
if
you,
if
you
had,
then
you
would
have
used
that
token
and
I'm
now
sending
I'm
also
sending
observations
they're,
based
on
the
assumption
that
such
a
message
has
such
an
original
message
has
arrived
earlier.
A
Yeah,
this
slug
really
raises
a
red
flag,
because
if
you
think
you
needed
that
then
you're
doing
something
wrong.
You
said
it's
just
a
little
bit
additional
safety
message,
but
really
the
fact
that
you
start
thinking
about
that
demonstrates
that
something
is
not
yet
right
in
the
architecture
and
I
think.
Basically,
we
have
to
think
about
this
group,
client
or
client
group
or
whatever,
that
that
is
tied
to
the
multicast
and
we
need
somebody
who
stands
in
for
this
group.
A
So
maybe
we
should
forget
the
other,
slides
and
then
revisit
that
issue,
but
I
think
that
the
main
point
I'm
trying
to
make
is
that
really
the
multicast
group
and
the
set
of
clients
would
have
joined
that
multicast
group.
That
is
the
entity
we
should
be
thinking
about
and
how
this
client
group
makes
decisions,
and
there
is
no
problem,
then
delegating
decisions
to
a
particular
entity,
but
it
really
needs
to
speak
for
the
whole.
C
Jim
John,
except
for
the
fact
that
I
have
no
idea
how
to
fix
the
process.
The
problem
is
there:
did
you
looking
at
the
possible
solution
of
the
server
advertises
in
the
resource
directory?
I
am
willing
to
entertain
this
observation
as
a
multicast
observation
and
here's
the
token
you
should
give
me
for
it.
K
So
that's
the
start
when
I
started
raising
my
eyebrows
and
if
I'm,
that
I
on.
If
we
have
all
these
considerations
of
like
what
custom
mentioned,
we
need
somebody
to
send
some
entity
to
manage
this
coordination,
and
we
also
have
questions
like
when
we,
when
all
observers
go
away
because
they
are
no
longer
interested.
K
How
does
the
server
know
that
it
should
stop?
And
then
this
simple
module
of
one
entity
that
it
stands
in
for
the
group?
It's
not
very
reliable
again,
because
if
that
one
entity
goes
away
because
of
the
network
error,
then
the
whole
group
breaks
down,
and
so
they
asked
us
to
of
problems
and
we
need
to
solve
all
of
them
and
it's
not
easy.
J
Christine
I'm,
just
we
briefly
earlier,
already
discussed
the
possibilities
of
having
the
reliability.
How
do
you
know
when
everyone
is
away
on
topic
that?
But
that
would
indeed
need
respond,
a
massive
to
multicast,
that
is
calm
that
will
be
sent
all
like
every
every
tenth
event
or
so
that
solicits,
sometimes
it
acts
from
still
interested
clients,
but
that
is
not
aligned
with
the
current
multicast.
The
current
multicast
reaches
the
doubtful
core.
A
Of
course,
it's
bit
more
complicated
and
also
it's
seeded
consumer
server
resources,
so
it
would
be
nice
to
find
out
so
in
various
reliable
multicast
protocols,
we
have
techniques
for
doing
route
management,
so,
for
instance,
you
have
random
members
of
the
group
respond
at
some
point
to
set
the
parameters
for
this
randomness.
You
need
a
group
size
estimate
that
group
size
estimate
can
be
derived
from
the
current
size
estimate,
plus
a
measurement
of
how
many
actual
responding
which
works.
A
A
K
Going
back
to
this
question,
how
do
you
as
a
client
find
our
to
depth?
A
notification
is
attended
for
him
and
what
request
relates
to,
if
we
add
the
security
layer
with
Oscar
and
all
that
stuff,
and
we
securely
manage
the
members
of
the
group?
Can
we
maybe
piggyback
on
that
to
identify
what
a
notification
relates
to?
Yes,
no
I,
don't
know.
J
Just
a
numbers
I'm
not
really
convinced
that
we
have
this
problem
because,
while
by
the
time
a
client
is
receiving
a
response
automatic
on
on
a
multicast
message
by
the
time
it
needs
to
it,
it
will
be
aware
of
having
requested
something
from
that
particular
server
and
if
it
hasn't
been
in
really
ignored,
because
it's
a
road
multicast.
But
it
will
come
from
a
particular
server
and
will
be
scoped
to
a
particular
multicast
address
and
with
that,
the
tokens
are
managed
within
the
server
or
with
an
whether
the
stand-in
is
and
I
don't
see
how.
B
K
E
B
Ok,
this
was
on
the
main
point
of
overriding
the
talk
and
then
building
on
this.
You
may
also
want
to
add
security
through
group
or
score,
and
the
whole
point
becomes
aligning
all
those
clients
to
be
able
to
process
the
next
coming.
Multicast
responses
and
the
approach
we
adopt
was
making
them
use
or
making
them
able
to
build
the
same
external
EAB.
This
way
we
have
a
new
co-op
option,
also
included
only
in
that
first
unicast
notification
to
the
client
upon
registration.
B
Secure
with
that
security
context,
given
this
fixed
in
time,
values,
x
and
y,
the
point
of
the
option
is
telling
all
the
clients,
when
you
get
a
secure,
multicast
notification-
and
you
want
to
verify
it-
build
your
external
ad,
considering
X
as
a
request,
KD
and
y
as
request
partial
ID
and
those
values
will
be
the
same
for
all
the
following.
Multicast
notifications
coming
from
that
server
for
that
resource-
and
this
can
definitely
be
a
must-
be
Class
E
for
score,
because
it's
really
intended
to
be
and
to
end
between
the
server
and
the
clients.
B
An
example
with
security
we
don't
need
to
go
line
by
line
through
this
traffic,
just
to
set
some
some
values
that
the
parameters
involved,
but
essentially
we
assume
a
client
one,
and
this
has
already
no
score
association
client
when
they
separate
you
know
score
security,
Association
and
C
1,
C
2,
and
s
are
already
member
of
the
same
Oscar
group.
So
building
on
the
example
of
above
the
token
of
the
writing
is
just
the
same.
We
have
a
second
option
that
the
server
includes
in
the
registration
response
to
the
client
specifying
five
five
zero
one.
B
Where
again,
five
is
the
sender
ID
of
the
server
in
your
group
and
five
zero.
One
was
the
sender
sequence
number
of
that
server
in
the
score
group
upon
getting
the
registration
from
this
first
client
fiant,
one
in
fact,
right
after
that
number
is
staffed
by
one.
So
it's
consumed
when
client
who
registers
in
fact
same
talking
of
a
writing
same
option
with
the
exact
same
values.
B
Then
the
multicast
notification
comes
protected
with
a
group
of
score.
The
red
frame
was
supposed
to
be
around
the
token
field
by
the
way.
Sorry,
the
point
is
that
the
clients
will
verify
this
response
building
and
externally
ID,
considering
five
and
501s
signaled
in
the
option
returned
in
the
response
to
the
registration
to
verify
this
multicast
response
and
all
the
following
ones
coming
from
this
server
for
this
resource,
so
essentially
at
the
first
unique
identification
to
each
client
is
also
bound
to
the
following
multicast
and
deviations
from
the
server
in
a
secure
way.
B
So,
as
a
summary,
this
was
about
introducing
multicast
responses,
especially
as
observed
notifications
addressing
two
main
points.
First,
one
really
co-op
related
synchronizing
all
the
clients,
on
the
same
token,
value
to
be
used
to
be
used
in
all
multi
identification
x'
and
also
enable
the
usage
of
Grupo
score
to
protect
those
multicast
notifications.
So,
of
course,
you
immediately
gain
the
benefit
coming
from
the
usage
of
multicast
and
in
the
particular
case
of
pub/sub
application,
you
can
keep
the
subscribers
clients
only
very
good
discussions
already.
We
look
forward
for
more
comments
or
reviews.
A
Yeah
we
have
had
the
most
important
parts
of
the
discussion
already
so
I
think
we
need
a
clearer
model
of
who
the
players
are.
Clients
of
group
multicast
group
but
may
or
may
not
be
exactly
the
same
thing.
And
if
we
have
clarified
the
model,
then
maybe
we
also
can
clarify
the
mechanisms
that
realize
the
model.
A
K
We
should
use
some
of
the
core
interims
yeah
to
this
and
since
many
of
us
are
based
in
Stockholm,
we
were
discussing
having
a
full-day
workshop
even
on
this
topic,
and
maybe
we
can
put
that
on
on
the
day
where
we
have
a
core
Durham.
So
we
could
first
try
to
clarify
things
and
then
go
into
that
interim
yeah.
But
everyone
disagree.
Then.
A
A
M
I
think
you
hear
me
well
again:
okay,
then
I'll
start
with
the
next
presentation,
so
from
Marcos
who
lost
money
now
going
back
to
basics
and
maybe
shirts
shirts
lines.
Yes,
thank
you
so
setting
me
up
date,
0
1!
This
is
also
just
a
recap
from
basically
the
previous
active
presentation
of
marco
gave.
So
we
have
this
draft
intended
as
a
normative
successor
of
the
experimental
ourseives
17.0.
M
M
Examples
are
shown
here,
so
this
kids,
californium
and
the
co
implementation
and
in
the
scope
of
this
draft
is
really
coop.
Group
communication
using
UDP
IP,
including
the
latest
development
sort
of
means,
for
example,
or
I,
shall
observe,
and
both
unsecured
and
also
a
group
Oscar
secured
location
is
covered
well
in
the
previous
draft
7390
that
security
of
nodes
in
the
present.
Yet
we
also
want
to
have
principles
for
secure
group
configuration
and
list
of
huge
cases,
so
we'll
go
to
the
next
slide
Thanks.
M
So
what
we
did
is
there
are
three
slides
on
the
progress
and
version
one,
the
drafters
updated
using
part
of
the
review
comments
and
more
updates
based
on
the
review
comments
are
pending
so
already
many
thanks
to
reveal
if
yours
for
that
I
think
it's
quite
useful
to
have
that
the
scope
has
been
clarified.
I
will
come
back
to
that
in
presentation
what
that
means.
We
made
a
decision
to
copy
over
some
content
from
chef
390,
and
this
also
gives
the
opportunity
to
update
that
content
wherever
it's
in
order
to
fix
more
issues
in
it.
M
M
Also,
we
have
a
bit
more
detail
on
the
different
type
of
groups.
That's
already
came
back
in
an
earlier
presentation
in
this
session.
Just
now,
so
there
are
different
types
of
groups.
You
can
have
what
is
called
now
a
co-op
group,
let's
find
out
the
network
level
using
multicast
address
and
port
there's
the
oscar
group
defining
the
security,
also
with
its
own
ID
and
an
application
group.
So
this
can
be
any
agent
specific
ID.
M
What
still
could
be
done
in
this
draft
to
also
detail
bit
more
the
relations
between
these
group
types,
one
example
is
already
shown
on
the
bottom,
so
Joe's
here
one,
a
co-op
group
is
basically
associated
one
oscar
group,
which
covers
two
application
groups
that
used
the
same
security
and
the
same
as
others
and
same
fourth
or
they
can
also
be
many
other
relations.
You
can
also
have
everything
one-to-one
or
many
different
from
so
I
think
that
will
be
useful
to
to
mention
that.
M
What
we
also
detailed
more
is
how
to
use
multi
cars
together
with
observe
and
together
way,
the
block
wise
transfer,
specifically
the
block
one
option,
so
this
slide
shows
two
kind
of
cases
of
that
top
one
chose
serve,
so
multicast
makes
an
observation
to
entire
group.
All
the
group
members
now
adds
the
client
to
the
service
list
and
start
sending
back
a
unicast
notifications
for
the
lower
part,
not
just
put
post
or
fetch.
The
use
case
is
basically
efficient
distribution
of
large
files,
specifically
software
constant.
M
So
you
can
imagine
client
pushes
a
block
to
a
group
and
then
individual
servers
respond
back.
While
writing
this.
We
found
this
to
be
a
non-trivial
case
and
many
exceptions
like
rotation
of
locked
eyes
that
get
lost
example,
and
so
it's
getting
already
rather
complex
with
some
yeah
open
items
in
the
drafts
currently,
so
we
have
to
make
a
decision
there,
so
tsuki
really
spin
out
is
behavior
to
a
new
idea
because
it
will
otherwise
slow
down
the
progress
of
the
current
one,
which
is
not
intended.
M
M
The
reason
to
do
this
is
that
it
was
remarked
at
standards
track
document
that
updates
an
experimental
RFC
would
be
kind
of
strange.
It
would
lead
to
an
clarity
what
is
actually
negative.
What
is
experimental,
because
the
previous
one
had
only
experimental
stages
so
to
make
it
clear.
We
should
start
you
document
that,
actually
it's
the
previous
one
and
then
we
should
copy
over
any
content.
M
We
wish
to
keep
and
update
it
as
well-
that's
at
least
most
clear
so
to
avoid
any
confusion
on
that,
we
can
still
point
to
the
experimental
rest
protocol,
but
it's
in
1790.
You
can
say
that
that
space
experiment
we
did
not
intend
to
make
that
normative,
and
people
can
still
experiment
with
that
from
that's
no
problem
at
all.
M
A
E
M
E
M
Have
other
updates
that
are
not
so
surf
and
ice
RC,
specifically
so
I
didn't
mention
already
before
what
these
are
plates
are.
So
there
are
specific
uses
so
multicast,
yet
with
block
wise,
we
have
to
put
post
or
fetch
will
work
on
option,
and
these
are
not
yet
defined
in
the
RFC.
So
that's
why
it
isn't
update
really
she's.
M
Also
articles
now
on
updates,
remarketing
72i
through
the
purpose
was
to
renew
our
client
request,
response
matching
rule,
but
I
think
it
will
likely
be
removed
again
because
after
I
read
it
again
with
the
definition
of
coop
client
I
think
it's
not
needed
to
make
any
of
it.
It's
already
working
in
the
intended.
By
itself.
We
don't
have
to
go
to
that's
character,
okay
and
then,
let's
move
on
to
the
next
site
oops.
M
So
what
we
want
to
do
is
complete
the
processing
of
the
all
the
review
comments
and
maybe
come
backwards.
More
fixes
or
questions
to
the
revealed
also
implement
the
decisions
of
also
resides
now
to
spin
out
this
one
function,
then
that
should
be
removed
from
the
kern
draft
and
made
in
circuit
now
and
on
the
lower
end
of
course
completed
document.
So
we
have
to
still
copy
over
remaining
sections
review
them
again
of
the
content
if
needed,
fill
in
some
open
interested
dvds
and
if
anything,
we
have
to
possibly
add
missing
points.
M
So
there
there
are
ways
constantly
asking
for
input.
So
if
everything
is
missing,
then
we'd
like
to
know
about
it,
I
think
there
is
no
direct
need
for
document
reviews.
Now
this
version
people
can
go
ahead,
but
I
think
the
coming
zero
to
update
where
some
of
the
above
things
are
implemented.
It
would
be
useful
to
have
again
more
reviews
of
this
okay.
So
this
concludes
my
presentation.
M
A
Few
nods,
a
few
slow
nods
but
I
think
the
overall
feedback
is
good,
so
I
think
we
are.
We
should
be
encouraging
you
to
continue
this
work,
and
maybe
we
actually
can
make
a
decision
in
the
next
few
weeks
that
we
consider
the
experimental
the
experiment
on
the
experimental
interface
for
group
management
as
completed,
because
we
are
not
aware
about
orientation.
But
of
course
we
should
do
that
on
the
list.
That
might
simplify
things.
M
A
I
So
for
those
of
you
who
probably
don't
remember
what
fire
is
all
about,
it's
an
alternative,
RTO
and
consistent
control
offering
for
co-op
so
as
an
alternative.
It's
just
like
cocoa,
it's
optional,
to
implement
so
for
those
implementers
who
think
they
may
benefit
from
from
more
efficient
of
recovery
in
in
presence
of
corruption,
as
well
as
more
safe,
consistent
control,
so
those
improv
implementers
made
in
implementing
it.
I
It's
in.
We
have
implemented
for
leap,
co-op
and
experiment
experimented
with
it,
and
we
have
published
the
results
in
kokum
december
last
year,
so
basically,
the
first
sanity
check
off
that
it
works
and
behaves
like
the
intended
and
and
provides
the
the
internet
results
that
have
been
done.
As
far
as
we
know,
there
is
at
least
one
independent
implementation,
upcoming
and
and
and
also
the
experiments.
Hopefully,
this
happens,
and
it's
all
welcome
to
get
more
experimentation
on
on
this
quick
history,
so
the
tea
was
first
published
about
a
year
ago.
I
So
the
pre
before
the
last
montreal
meeting
as
a
tradition,
is
in
the
transport
area.
New
consistent
contributed
in
the
ICC
Archie
for
review,
and
it
was
also
on
the
agenda
for
Corbett.
There
was
not
enough
time
to
present
it,
so
we
published
it
zero
one
person
in
just
before
the
Bangkok
meeting
we
added
zero
code
and
some
small
clarifications
and
presented
it
in
core,
so
it
was
discussed
here
and
then
waiting
for
the
baddy
group
eruption.
I
I
A
Yeah
we
discussed
this
at
the
last
meeting.
Where
do
we
do
mr.
meet
last
hug?
I
don't
and
we
we
had
said
that
the
problem
we
had
before
with
group
adoption
that
we
didn't.
We
know
what
what
the
IPR
declaration
really
was.
That
problem
had
gone
away.
We
now
had
a
detailed
IPR
declaration,
but
of
course,
still
everybody
had
to
figure
out
whether
that
detailed
IPR
declaration
was
something
they
want
to
live
with
or
not
so
that
that
was
the
kind
of
what
we
went
out
of
the
Prague
meeting
with
and
yeah.
A
We
could
have
done
a
wagon
road
option
call
right
away.
We
didn't
do
that,
so
people
have
had
about
four
months
of
time.
Looking
at
the
situation
and
I'm
just
wondering
do
we
have
new
data
or
we
already
get
new
data
by
actually
during
the
the
work
group.
Adoption
call,
so
has
anybody
looked
at
this
into
this
and
has
a
position
whether
this
is
an
IPO
declaration?
We
can
live
with
so
I
see
one
person
nodding
I.
N
N
So
it's
no
longer
just
arbitrary
data
makes
it
easier
for
especially
middle
boxes
or
other
systems
outside
of
this
single
sentiment,
exchange
to
I
understand
what's
going
on
in
the
data,
so
the
idea
is
that
we
add
this
new
field
called
city
where
we
can
indicate
the
content
format.
For
example,
here
you
have
basically
four
encoded
sibour
array
with
two
values
inside
it
and
because
it
says
city
is
60,
receiver
can
easily
figure
out
its
eeper.
It
should
be
decoding.
N
That
was
the
background.
What
we
discussed
already
in
the
last
IETF
that
it's
useful
to
have
not
only
the
content,
format
IDs,
but
also
the
string
format
that
then
you
can
express
any
kind
of
high
content
types
and
content
coatings
that
are
possibly
not
already
registered
as
content
formats.
However,
as
we
learned
in
the
discusses
the
previous
ideas,
if
we
do
the
obvious
thing
and
just
register
basically
three
different
fields
for
these
three
different
purposes,
it
gets
a
bit
complicated
on.
N
N
N
The
second
part,
it
would
have
been
again
natural
design
that
you
would
have
either
a
string
or
a
numeric
value
or
for
the
cinema
field
value.
However,
as
Colin
pointed
out,
there's
a
bunch
of
complications
in
that
approach,
so
one
of
the
kind
of
original
design
ideas
of
sentiment
was
that
all
fields
have
a
single
fixed
type.
So
that's
what
we
have,
for
example,
the
field
for
numeric
values
and
vs
through
field
for
string
values,
the
benefits
of
doing
it.
This
way
around
that
you
have
more
efficient
to
parse.
N
If
you
do
it
in
high
speed,
you
don't
need
to
do
type
checks
of
what
kind
of
values
the
string
or
ISTA
it's
the
integral
in
there.
In
the
value
part,
you
can
also
generate
parser
code,
more
efficient
for
different
languages
and,
if
you're
storing
this
in
a
database
with
a
simple
schema
again,
it
gets
it
it's
simpler
to
use
it
that
way.
So,
then
the
question
was:
how
could
we
go
with
this
numeric
and
string
formats
with
a
single
field?
Well,
the
obvious
solution.
N
N
However,
when
we're
thinking
about
this
more
kind
of
from
practical
engineering
point
of
view,
it's
rather
small
overhead
in
in
JSON
format,
basically
just
put
quotes
around
and
you're
done
in
Seymour
format.
Yes,
it's
going
to
be
a
string
and
instead
of
Ewing,
so
you
lose
a
few
bytes
efficiency
on
the
wire.
However,
these
values
you
at
least
how
we
envision
them
being
used.
You
don't
really
do
any
any
arithmetic.
Soren
like
that.
N
N
So
that's
basically
the
update
on
this
traffic
and
then
a
bunch
of
questions
to
the
group.
So,
first
of
all,
are
they
any
concern
so
using
this
string
value
for
content
formats,
so
we
are
using
both
the
numeric
value
and
the
string
value
in
the
same
same
field.
Also,
this
new
format
where
we'd
say
use
this
at
content
coding
soon,
that's
I
think
that's
the
first
time
we
are
doing
that
kind
of
a
design.
Is
there
any
concerns
on
that
style?
N
But
of
course
we
can
it's
a
nice
bike
sure
to
think
about
what
would
be
alternatives
for
that
and
finally,
one
minor
issue
that
we
discover
is
that
this
we
have
two
ways
of
expressing
fields
in
sin
ml,
the
ones
that
you
must
I
understand
and
once
the
ones
that
you
don't
need
to
understand
and
if
you
want
to
force
the
receiver
of
cinnamon
to
check
that
it
actually
understands
all
those
fields.
You
just
put
an
underscore
in
the
end,
so
we
were
not
sure
if
we
actually
need
this
underscore
format
in
this
case.
N
But
then
thinking
about
this
except
this
morning,
I
did
realize
that
you
may
have
a
case
where
a
single
sensor
is
ending
with
multiple
content
types
and
actually
alternating
between
sending
them
and
in
that
case,
actually
would
be
critical
for
the
receiver
to
see
to
understand
which,
which
type
it
is
it
this
time.
So
it
seems
reasonable
to
also
define
the
must
understand
field.
N
There
could
be
say
some
applications
where
you're
just
like
okay.
This
is
just
in
case
hint
and
if
there's
something,
let's
say
you
have
a
some
security.
Well,
let's
say
some
storage
box
in
between
that's
like
would
prefer
retest
or
everything,
but
then
wouldn't
need
to
actually
understand
whether
this
has
some
relevant
semantics
or
not.
L
N
N
A
Of
raised
the
same
problem
we
ran
into
was
a
web
where
we
have
elective
and
critical
and
then
at
some
point
we
found
out
that's
good
for
in
systems.
But
what
about
proxies?
And
we
came
up
with
safe
and
unsafe
for
proxies
and
use
use
him
to
believe
that
storage
nodes,
for
instance,
what
read
to
must
understand
fear
in
some
form
I
would,
depending.
A
N
Depending
on
the
application,
so
you
could
have
a
storage
system
and
Ali
said:
okay,
dump
everything
as
such
and
I
likened
or
storage
is
try
to
do
sanitization,
maybe
transformations
that
may
need
to
do.
But
now
you
would
have
at
least
the
capability
to
indicate
that
way,
depending
on
your
application
needs
just.
A
C
N
So
I
guess
we
have
a
violent
agreement
on
adding.
They
must
understand
because
we're
gonna
need
it
in
any
anyway
for
purposes
and
their
stall.
That's
not
really
cost
in
specifying
and
then
it's
up
to
the
application
application
logic,
whether
that
is
needed
in
in
certain
applications
or
not,
and
maybe
we
should
add
some
more
think
about
more
clarifications,
how
that
is
used
with
with
different
systems.
N
O
A
O
A
O
O
H
E
H
N
E
H
N
N
H
N
Very
good
point
that
was
our
previous
design.
Then
we,
then
we
realized
that
you're
running
the
problems
cause
there's
interesting.
How
waiting
is
how
interwork?
If
you
have
base
value
of
one
eight
one,
let's
say
from
the
numeric
area
another
then
you
have
later
a
new
base
value
from
the
string
kind
and
which
one
are
you
ten
supposed
to
be
using,
so
you
could
come
up
with
rules.
Okay,
this
one
has
the
precedence,
but
wonder
if
you
want
to
go
back,
no,
you
need
to
undo
the
one
that
has
precedence.
N
We
don't
really
have
simple
way
of
undoing
base
values,
yeah
you
could
set
it
into
undefined
value,
etc.
It
starts
to
get
a
little
by
little,
rather
complicated
rules
like
how
do
you
work
on
if
you
have
two
different
things,
defining
the
same
thing,
that's
why
we
went
in
this
version
of
the
craft
for
the
design,
where
it's
only
single
field,
defining
a
a
single
kind
of
parameter,
but
yet
that
was
the
one
you
can
check
out
the
previous
draft,
how
it
look
like.
N
So
yeah
pros
and
cons
and
and
yeah
I,
fully
agree.
I
mean
this
time.
This
number,
as
a
string
also
concerned
me
and
many
of
you
who
I
actually
talk
with
this
about
this
during
the
week,
but
that
seems
to
be
kind
of
there
and
I
hate
to
call
the
sweet
spot,
but
their
engineering
compromise
that
makes
more
sense.
A
L
N
I
can
I
can
talk
to
you
in
the
other
issue.
So
it's
it's
nothing!
It's
not
not
really
about
this
nml
city,
but
it's
about
base
values
and
must
understand
values
in
general.
There
are
some
potential
complications,
because
you
know
you
can
define
your
base
value
as
something
you
must
understand
or
not
and
not
don't
need
to
understand
and
your
regular
field
as
a
same
same
way.
N
N
A
A
A
A
P
This
is
my
own
slide,
so
this
is
one
issue
that
we
discovered
when
working
in
OMA
on
on
version
1.1,
where
we,
so
we
had
sentiment
already
in
the
original
version
1.0.
But,
as
you
know,
the
specification
in
the
ITF
central
specification
was
released
as
RC
and
everything
was
great
and
when
we
did
our
consistency,
reviews
as
part
of
the
what
we
call
one
that
one
that
one
we
found
out,
that
our
examples
were
not
correct
were
not
in
compliance
with
the
specification
and
the
way.
P
As
you
know,
the
way
how
we
use
out
or
the
data
model
works
is
we
use.
This
object,
object,
instance
and
resource
a
notation
with
a
numerical
ID,
so
you
see
that
in
the
example
below
and
what
we
missed
was
that
there's
this
base
name
concept,
which
always
has
to
be
unique
for
each
specific
sensor
reading
or
each
specific
sentimental
document,
and
so
you
see
you
see
an
example
on
the
top.
P
The
base
name
here
is,
for
example,
the
urine,
and
we
have
a
couple
of
ways
to
uniquely
identify
a
device,
and
then
there
would
the
resources
and
an
object
and
object
instance
and
resources
would
followed
and
afterwards.
But
the
consequence
of
this
is
of
this
design
decision
in
cinnamon,
which
we
unfortunately
didn't
realize
home
or
realize
much
much
too
late
was
that
we
now
have
to
carry
this
base
name
with
the
fully
identifying
the
endpoint
name
using
a
your
eyes.
P
P
Our
purpose
like
from
from
from
that
point
of
view,
because
it
allows
us
to
take
a
bunch
of,
for
example,
readings.
It
allows
us
to
put
a
couple
of,
for
example,
if
it
goes
into
the
other
direction,
a
couple
of
requests
into
one
into
one
cinema
document
and
ship
it
off
to
the
client
and
sort
of
there's
only
the
client-server
interaction.
So
we
don't
need
to
carry
in
each
payload,
uniquely
identifying
information,
so
we
had
a
chat
in
our
in
our
club
and
and
reached
out
to
some
of
you
last
week.
P
Okay,
with
the
consequence
being
that
we
save
a
lot
of
bytes
one
other
thing
which
I
don't
have
on
the
slides,
which
only
showed
up
very
recently.
It's
not
captured
in
the
document
and
we'll
need
to
do
a
little
bit
of
homework
with
Ari
and
Mochan
and
and
in
others
is
we.
We
have
cases
where
we
send,
for
example,
if
we
create
an
an
object
on
the
device,
then
we
would
send
that.
P
We
required
the
full
sort
of
like
the
complete
string
to
be
present,
but
we
don't
actually
necessarily
know
on
what
the
inst
object.
Instance
will
be
that
the
client
would
allocate.
So
the
server
sends
something
create
a
new
object,
so,
for
example,
that
an
object
could
be
let's
say:
I
want
to
instantiate
a
lightweight
m2m
server
resource
also
I
want
to
add
another
server
to
the
configuration
of
the
office
of
the
client.
P
P
So
that
creates
some
some
problems
with
the
current
resolution
scheme,
and
so
we
need
to
do
a
little
bit
of
thinking
there
as
well.
So
dia
there's
a
little
bit
more
than
than
what
I
just
said,
and
it
was
only
discovered
very
recently,
unfortunately,
so
here,
I'm,
basically
suggesting
to
enhance
cinema
with
this
local
base,
name
to
essentially
help
us
to
get
the
specification
in
in
in
line
with
the
RC
or
with
the
functionality.
N
A
Yeah
two
observations
here:
one
this
probably
would
need
to
be
simpler,
be
Landin,
not
a
bien.
All
just
effects
this
one
single
record
following
it
was
but
I
think
the
more
important
observation
is.
We
do
have
the
idea
of
base
UI
in
rest,
and
we
could
actually
tap
on
that
I
mean
cinema
has
judiciously
avoided
using
it,
but
that's
because
cinema
originally
was
meant
for
a
certain
area
of
replication
and
opening
a
new
area
of
application
may
require
doing
that.
N
Yes
fully
agree,
and
there
is
a
another
draft
I
suddenly
on
monitoring.
Chris
and
I
have
been
working
on
this
based
in
pointer
and
indication,
so
that
one
is
going
that
direction
that
you
could
indicate
what
should
be
the
based
based
thing
over
there
they're
having
it
posted
on
on
the
core
mailings.
There
is
an
upcoming
IPO
declaration
and
on
that
draft,
at
once,
once
that's
done.
N
I
can
I
can
post
it
on
the
core
mailing
list,
but
yeah,
but
there
you
can
basically
indicate
with
the
new
field
that
okay,
here's
what
should
be
before
this
base
name
and
then
it
becomes
unique
in
the
context
of
anyone
who
receives
that
and
then,
when
you
are
forwarding,
for
example,
to
let's
say,
like
I,
see
a
sentence,
you
said
I
understand
that
you
can
easily
test
our
resolve
those
records
that
then
it
becomes
a
unique.
So
that's
alternative
way
of
doing
that.
Maybe
something
we
should
be
exploring.
N
A
P
Ideally
yesterday,
but
you
understand,
like
we
obviously
need
to
work
on
the
details
and
and
look
at
the
alternative
ideas
to
make
sure
that
we
actually
get
something
working
right
now
and
we
didn't
have
to
create
another
sort
of
ref
of
a
bug-fix
release
of
our
specification
to
make
sure
that
this
is
in
line.
Because
currently
we
essentially
don't
properly
use
cin
ml.
And
I
was
it
just
didn't-
realize.
N
This
actually
is
violating
there,
but
the
reason
for
having
the
mosque.
There
is
something
that
we
don't
actually
get
in
in
light
within
them,
so
in
that
sense
we're
okay,
as
long
as
we're
confined
in
our
own
little
space,
of
course
long-term.
That
is
not
a
good
solution.
We
do
wanna,
expand
those
records
to
various
different
autofocus
and
a
standard
so
and
really
background
on
this.
Why
it
is
a
mosque
that
you
can
easily
use
in
various
contexts.
N
N
A
A
So
if
we
have
something
like
microseconds
or
micrometers,
milliseconds
or
micrometers,
it's
a
bit
inconvenient
because
you
no
longer
can
use
integers.
So
we
move
this
back
and
forth
and
at
the
end
we
decided.
We
don't
really
want
to
break
sentiments,
clean
approach,
but
instead
we
add
a
secondary
registry
of
secondary
unit
names
with
a
big
hood,
not
on
top
of
it.
You
should
not
use
that,
except
if
you
have
a
reason
for
to
use
it,
and
so
this
would
essentially
have
four
columns
a
secondary
unit
name.
A
So
this
is
the
relaxed
version,
a
cellular
unit,
name
a
scale
and
an
offset,
and
there
would
be
a
proscribed
from
your
how
to
translate
between
the
secondary
unit
and
and
a
cinema
unit.
So
the
details
are
in
the
draft
but
seem
to
me
that
this
is
a
good
way
forward
and
we
can
keep
cinema
clean,
but
we
can
also
have
this
little
backpack,
where
we
stuff
things
that
are
based
on
an
order.
Data
marts,
so
I
think
that's
about
it
on
this
I
see
nodding
so
yeah.
This
is
currently
an
individual
submission
by
me.
A
A
Of
hands,
so
can
you
please
all
have
a
quick
look
at
the
document,
it's
not
long,
the
three
pages
or
so,
and
and
see
whether
we're
on
the
right
track.
Thank
you,
yeah.
This
ends.
The
official
part
of
the
meeting,
but
Christian
had
a
few
ideas
for
things
we
maybe
should
be
discussing.
So
we
are
now
in
a
hallway
meeting
and
if.
J
Well,
the
hallway
meeting
is
the
perfect
place
to
discuss
those
things,
because
they
are
more
targeted
towards
people
typically
around
core
than
actually
being
things
that
would
become
working
group
items
or
if
so,
then
they
are
a
bit
far
from
that.
My
idea
here
is
to
give
just
inform
you
and
ask
feedback
from
you,
because
this
could
be
relevant
in
things
that
are
coming
up
later.
J
So
one
of
those
items
is
that
it
would
be
great
to
use
shake
for
for
compressing
co-op
options,
because
the
time
and
again
people
come
around
and
say
that
there
is
a
particular
thing
in
co-op
options
that
doesn't
really
express
nicely
for
me
or
that's
bloated,
so
that,
if
that's,
whether
that's
people
complaining
about
well-known
protocol
name,
bland
names
are
long.
I'll
rather
have
specifier
things
at
/c
and
then
get
into
big
discussions
on
art
or
whether
that's
protocols
that
include
numbers
in
path
options.
J
Those
could
all
be
generalized
if
we
use
the
work
that
is
in
Schick
and
just
give
guidance
on
how
to
derive
new
options
to
to
have
Schick
data
in
those
options
that
would
then
expand
out
to
existing
options
with
pretty
straightforward
semantics.
I
don't
have
a
draft
on
this
I,
don't
intend
to
start
one
unless
more
use
cases
crop
up
where
people
actually
say.
Okay,
I'll
need
this
for
that,
and
then
I'd
be
happy
to
kind
of
to
the
groundwork
part
and
whoever
comes
up
with
a
use
case
to
do
the
motivation
and
and
particulars.
A
J
Another
thing
that
came
up
and
that's
even
even
less
a
working
group
item
related-
is
that
I've
worked
with
a
quite
a
few
coop
libraries
and
there
seems
to
be
a
pattern
of
interacting
with
coop
messages.
So
this
is
not
about
the
kind
of
high
level
I'm
having
a
rest,
implement
a
rest
engine
there,
but
the
low
levels
of
I'm
processing
observation,
I'm
processing,
a
score,
those
things
I'm
gathering
I'm
gathering
those
those
kemon
methods
as
part
of
an
Oscar
implementation
in
the
context
of
the
rat
operating
system.
But
I'd
appreciate.