►
From YouTube: IETF106-CORE-20191120-1000
Description
CORE meeting session at IETF106
2019/11/20 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
Three
minutes
and
as
you
can
see,
we
have
streamlined
this
a
little
bit,
so
you
know
only
can
be
a
chair
of
this
working
group.
If
you
have
a
12
character,
email
address
so
Jaime
has
to
it
had
to
change
this
yeah.
It
turns
out
that
Ericsson
has
standardized
an
odd
lookit
I'm,
not
going
to
explain
further
from
this
point
yeah.
This
is
an
ITF
meeting
and
there
is
a
note
right
slide
which
you
can
look
at
and
we
have
blue
sheets
who
are
the
note
takers
today,
Sneaky's
so
you're
using
visa
pad
great.
A
A
So
this
is
the
agenda
for
today,
which
is
essentially
based
around
three
subjects:
the
conf
work,
where
we
essentially
need
to
issue
working
with
blast
codes
at
the
moment
and
Android
just
asked
whether
there's
anything
in
the
way,
the
the
various
ideas
on
how
to
use
the
group
communication
and
properties
that
we
now
can
achieve
with
Oscar.
So
we
have
four
segments
here
and
finally,
we
will
talk
about
sin
ml
and
because
there
is
one
document
in
India
is
reprocessing
right
now
all
that
we
want
to
get
unstuck.
A
Something
might
fall
off
here
at
the
end.
Let's
see
how
we
managed
to
do
this,
because
on
Friday
we
actually
have
some
some
buffer
space
that
we
can
fall
into
also
things
we
don't
get
to
today,
we'll
move
to
Friday
and
the
main
subject
of
Friday
we'll
be
discussing
the
outcome
of
yesterday's
core
application
side
meeting
and
the
the
related
draft.
A
But
of
course
we
will
need
that
that
buffer
to
handle
everything
that
falls
off
today.
So
two
things
are
missing
here.
One
is
the
resource
directory
draft,
which
is
also
in
history.
Processing
right
now,
actually
a
devaluation
right
now,
so
that
might
also
come
up
on
Friday
and
there's
also
a
draft
that
expired
and
we
want
to
resurrect
and
why
we
were
trying
to
resurrect
it.
We
found
a
minor
problem
with
the
a
B
and
F
that
that
actually
is
not
that
easy
to
fix.
A
A
So
we
we
had
our
hallway
discussion
already
that
was
yesterday
in
in-room
butterworth
in
in
the
afternoon,
and
I
understand
that
some
people
couldn't
go
there
because
SEC
dispatch
was
conflicting
with
it
yeah
it's
hard
to
organize
site
meetings
here,
but
we
had
some
good
discussions
and
I.
Think
laws
were
a
report
on
those
on
Friday.
A
A
B
C
A
B
B
A
So
I
think
we
had
this
discussion
already
a
couple
of
months
ago
and
the
result
of
that
discussion
and
I'm
not
sure
if
Adam
is
part
of
the
consensus
of
that
was
that
we
had
a
solution
now
for
the
the
co-op
side
and
we're
happy
with
that,
because
that's
solving
the
problem,
there's
that
dots
has
and
doing
something
that
actually
spans.
Both
sides
is
more
complex.
A
C
B
A
A
So
the
resource
directory
work
is
just
in
the
phase
where
we're
Alexei
is
making
number
of
comments
and-
and
the
authors
are
working
on
those
comments,
so
that
is
all
mirrored
to
the
core
mailing
list.
So
you
should
be
able
to
follow
that
discussion,
and
if
you
think
that
that
discussion
is
going
in
the
wrong
direction,
then
it
would
be
really
useful
if
you
speak
up,
but
it's
not
clear
right
now
that
we
actually
need
to
talk
here
about
that,
and
if
we
do,
we
will
draw
it
on
Friday.
A
A
One
is
about
the
more
units
proposer
for
cinema
I
think
we
have
some
progress
there
and
we'll
talk
about
that
later.
We
have
a
couple
of
drafts
that
are
still
in
the
workgroup
last
call
still
in
the
working
group
they
have
passed.
Last
call
one
is
the
stateless
draft,
where
we're
close,
we're
close
by
the
way
and
someone
break
him
up
where
Klaus
hasn't
provided
the
update
to
the
draft
after
the
last
call
input
so
yeah.
A
A
A
We
put
that
out
yesterday,
belatedly
and
I
have
to
apologize
for
that,
and
we
also
have
the
corrections.
Clarifications
draft
that
went
through
adoption
call
but
didn't
get
much
feedback,
even
though
people
in
the
room
said
this
might
be
a
good
idea.
So
maybe
we
have
to
reconsider
that
how
we
go
forward
with
this.
C
Okay,
hello,
everyone,
my
name
is
Eva
Petrov
and
I
will
be
presenting
the
advancements
in
quorum.
So
basically
not
much
has
changed
since
the
last
IDF.
The
documents
are
pretty
stable
for
the
C
draft.
There
are
no
updates.
What
we
did
was,
as
it
was
requested
that
the
last
IDF
we
merged
the
seed
generation
2
with
the
young.
C
Ok,
so
yes,
that's
the
status
of
this
document
for
the
young
sea
board
document.
We
updated
it
I
think
in
September.
There
are
few
changes
that
are
worth
mentioning
like.
There
was
a
conflict
with
this
massive
attack
that
we
made.
We
were
made
aware
of
after
some
discussion.
We
agreed
to
change
the
support
act
that
we
were
using
and
we
went
ahead
and
made
this
modification
in
version
11.
C
C
C
Added
some
previously
missing
examples,
for
example,
related
to
live
encoding
with
names
or
any
xml,
and
we
updated
the
examples
not
to
point
to
obsolete
RFC's,
but
doors
are
very
minor
editorial
changes.
Nothing
significant
was
changed
here.
We
believed
to
that.
The
document
is
much
easier
to
I'm
it's
more
consistent
now,
so
we
also
believe
that
it's
ready
for
working
group
last
call
the
next
document.
C
It
was
just
very
at
core
rank
library
which
was
adopted
during
the
last
IDF.
So
it
was
resubmitted
us
draft
IDF
korean
Kleiber
e.
There
0
0
the
lasts.
We
didn't
receive
any
new
comments
from
the
last
version,
so
there
are
no
changes
to
this
document
or
the
comments
that
were
submitted
before
were
already
applied.
2-0
5.
C
C
C
C
C
Another
minor
change
was
that
some
places
we
were
giving
the
recommended
values
/c.
Instead
of
saying
that
it's
a
generic
thing
that
users
can
change
with,
we
believe
was
clear,
but
it
could
have
been
a
little
bit
confusing
for
some
people.
So
now
we
use
the
more
generic
form
and
we
removed
the
plus
signs
from
examples,
as
it
was
discussed
during
the
last
idea.
C
D
Robertson
Cisco,
so
a
question
actually
back
on
the
seats
draft
and
I've
made
a
comment:
I
think
from
the
alias
before
I.
Don't
I
can't
seriously
the
lease
document
that
drafts
defining
the
SIDS
as
60
unsigned
64-bit
integers
mm-hmm,
but
if
they
have
been
put
in
as
Delta's
in
the
files
that
are
still
being
done
in
the
actual
mysteries
I,
think
you
want
us
to
be
unsigned
63
bit,
integers!
I'm,
sorry
that
when
you
subtract
them,
you
still
end
up
with
in
a
assigned
64-bit
integer
value.
C
A
A
Think
the
important
thing
about
networking
last
call
is
that
it
actually
will
include
the
net
mod
and
net
conf
work
group,
so
we
will
send
out
to
working
with
us
called
to
the
three
groups,
with
a
request
to
actually
have
the
discussion
on
the
core
mailing
list,
but
I
think
it's
important
that
these
other
groups
actually
part
of
this
work.
New
brass
core.
A
Ok,
so
everybody
agrees
about
that.
A
quick
poll
who
cares
about
yang
for
people
for
people
in
this
room
I
know
that
there
are
other
people
who
are
not
in
this
room.
Maybe
he'll.
We
have
a
conflict
with
some
some
management
group
I,
don't
know
didn't
check.
Ok,
so
I
think
we
will
go
ahead.
Thank
you.
E
Hi
hi-
this
is
marco
de
la
confirm
rise
for
the
next
four
presentations.
First,
one
group
of
score,
yet
another
advanced
update.
This
was
mostly
related
to
addressing
the
comments
we
got
from
a
not
weeks
review
thanks
a
lot
for
that
and
a
quick
overview
of
those
we
clarified.
The
group
medina
must
be
unique
for
a
set
of
groups
under
the
same
group
manager,
which
is
also
directly
and
clearly
responsible
for
validating
the
public
keys
used
in
the
group
since
from
the
joining
as
to
their
format,
relay
parameters
and
coney
and
so
on.
E
So,
what's
ongoing
a
few
things,
we
still
would
appreciate
to
get
feedback
on
what
we
should
actually
Monday
to
implement
as
a
preferred
count.
The
signature
algorithm
right
now,
it's
EDD,
say
with
a
25,
509
Jeff.
This
is
just
about
feedback
from
vendors
and
use
case
deployers
and
so
on.
In
still
an
open
question,
then
one
particular
point
from
Jim
very
latest
comments
that
we
discussed
last
week.
E
Thanks
for
that,
there
is
a
corner
case
related
to
the
case
where
recipient
node
can
keep
for,
while
the
the
old
previous
recipient
context
and
key
material
where
a
request
is
essentially
protected
with
the
old
key
material
and
when
the
recipient
receive
it.
Well,
it's
still
in
a
position
to
decrypt
it,
but
it
also
has
the
new
context
ready
to
go
and
it
should
use
the
latest
context
to
protect
the
response,
but
just
to
give
a
confirmation
to
the
client
that
then
they
are
aligned.
E
Again,
we
are
going
to
include
the
group
ID
as
ID
context
at
the
response
in
this
first
response
to
the
client
and,
at
the
very
least
in
this
first
following
notification
in
case
observers
use.
So
we
plan
to
include
this
node
also
in
the
next
update.
Also
right
now,
we
are
still
defining
two
new
Ayana
registers
in
this
document
for
indicating
the
structure
to
follow
when
indicating
parameters
for
the
use
conditioner
algorithm
in
keys.
E
So
as
immediate
next
steps,
we
plan
to
integrate
the
totally
non
critical
comments
we
got
from
Jim.
We
can
discuss
with
him
already
and
it's
relatively
easy
to
incorporate
them
and
removals.
The
IANA
registers
I've
just
mentioned,
but
considering
the
very
advanced
status
of
the
document
that
got
many
reviews
so
far
and
and
this
relatively
easy
in
comments
from
Jeanette,
we
know
already
how
to
address
and
the
many
interrupts
have
gone
through.
We
think
this
can
actually
be
considered
to
move
on
to
work
in
Reverse
call.
Now.
A
Well,
maybe
a
little
bit
too
little
time
since
the
deadline,
who
has
read
a
version
of
this
document,
you
Trish
great,
thank
you.
Yeah
I
agree
with
that
and
two
two
hands
and
job:
oh
okay.
So
it
would
be
nice
if
the
people
who
previously
supplied
reuse
would
send
a
quick
notice
to
the
mailing
list.
Yes,
this
is
where
Alaska
already
I
mean
we're
still
going
to
have
a
working
class
called
there,
but
it
would
be
nice
to
hear
from
the
reviewers
that
they
are.
A
F
E
A
E
E
E
This
was
also
recently
disgusting,
one
of
the
latest
core,
inter
him,
and
a
few
people
were
asking
for
having
widely
shared
a
diagram
along
these
lines
where
the
whole
lifecycle
flow
was
shown,
and
this
document
is
in
fact
on
on
the
very
first
step
where
the
client
discovers
essentially
a
link
to
the
join
resource
at
the
group
manager,
and
then
things
move
on
on
the
ACE
domain.
When
you
get
authorized
to
in
fact
join
the
group
through
the
general
resource
now
group
membership
resource
at
the
group
manager
and
then
back
to
core.
E
When,
after
having
joined
the
group,
you
can
use
grupos
core
to
communicate
inside
the
group.
So
suggestions
are
welcome
on
the
best
way
to
make
this
diagram
circulating
where
to
include
a
wiki,
a
separate
document
whatever
well.
Of
course,
this
document
is
covering
step
one,
but
except
for
the
color,
we
can
now
put
it
in
an
RFC
as
well.
E
This
approach
on
the
problem
for
the
device
is
discovering
the
groups
to
join
and
properties
of
the
groups
and
how
to
join
them,
and
we
are
mapping
this
to
the
problem
of
discovering
links
that
grant
access
to
the
group.
So
the
problem
becomes
discovering
the
links
in
their
description,
and
it
happens
that
there
is
an
approach
for
doing
that
in
core,
which
is
the
resource
directory.
So
let's
just
use
it
in
order
to
find
out
the
links
to
join
the
group.
E
Innocence
editorially,
if
we
rename
general
resource
to
be
called
group
membership
resource
consistently
with
the
works
in
a
scuzz.
This
is
not
about
joining
anymore.
It
also
has
meaning
for
the
the
notes
that
are
already
members
in
the
group
later
on
and
can
interact
with
the
group
manager.
As
current
members.
E
Like
that,
in
the
ACE
document,
we
redefined
this
sec
GP
parameter
to
be
a
simply
an
invariant
plane
name
of
the
oscar
group.
That
is
not
related
anymore
at
all,
with
the
actual
oscar
group
ID
or,
as
we
were
doing
before,
a
zero
epoch,
oscar
group
ID.
So
it's
just
much
easier
to
handle,
and
it's
just
a
plain
identifier
of
the
oscar
group.
We
made
also
a
minor
change
in
in
how
values
are
defined
for
the
target
attributes
ascribing
properties
of
the
group
and,
in
particular
the
signature,
algorithms
and
related
parameters.
E
We
were
before
considering
taking
value
from
the
name
column
of
the
corresponding
cause.
We
registries
we
switch
to
the
value
column
cuz.
The
definition
of
those
registers
say
that
value
in
the
value
column
must
be
unique,
rather
than
so,
it
just
seemed
to
be
a
better
choice
consistently
with
all
these
updates.
E
We
also
update
in
the
examples
that
I
remember
include
also
a
real-world,
step-by-step
life
installation
provided
in
supported
by
bug
net,
to
open
points
that
I
can
mention
the
first
one
is
actually
moving
forward
that
was
discussed
before
we
have
a
number
of
target
attributes
here.
You'll
be
good
to
register
them
through
there's,
currently
no
registry
for
target
attributes.
As
I
said,
this
is
moving
forward
and
apparently
there
is
going
to
be
at
some
point
working
progress
document
not
published
yet
called
core
attributes
tentatively,
which
is
also
going
to
cover
the
creation
of
such
registry.
A
You
should
add
that
this
hasn't
happened
already
in
2012,
because
at
the
time
the
document
we
were
depending
on
there
is
no
such
residency.
And
now
the
update
RFC
82-88
actually
says.
If
a
serialization
of
weblinks
wants
to
define
such
a
registry,
it
can
go
ahead
and
do
so,
and
so
we
can
go
ahead
and
do
so
and
probably
should,
and
it's
just
that
somebody
has
to
do
the
work
and
that
somebody
has
to
hatch
that
egg.
E
Right
and
has
started
in
fact,
and
speaking
of
target
attributes.
We
have
postponed
this
for
a
while,
but
I've
been
thinking
of,
in
fact,
adding
one
more
target
attribute
in
the
link
description
specifying
the
URI
of
the
authorization
server
that
is
supposed
later
on
in
the
ACE
phase
of
the
full
lifecycle
of
the
device
to
provide
an
access
token
to
grant
access
to
the
joint
resource
at
the
group
manager
to
proceed
with
the
joining.
E
This,
of
course,
is
for
the
client
to
continue
anyway
experiencing
an
unauthorized
access
out
of
wish
you'd
get
that
URI
anyway,
eventually
from
the
group
manager.
So
it's
a
matter
of
optimization
and
we
don't
see
any
particular
problem
in
including
also
this
link
as
for
the
target
attribute.
So
unless
there
are
strong
objections
against
that,
we
plan
to
do
that
in
the
next
update.
A
E
A
E
Okay,
yeah,
to
summarize
most
of
the
updates,
were
clarifying
the
rationale
of
this
approach
in
introduction,
mostly
and
encoding
of
target
attributes
and
new
additional.
Why
we
can
include
updating
example.
Accordingly,
we
think
the
document
is
already
in
pretty
good
shape,
actually
to
move
forward,
and
it
went
through
I
would
say
a
review
process
during
that
design
workshop
we
had
in
Stockholm
and
and
again
during
the
following
interim
still.
E
Okay,
next
then,
this
work
was
also
presented
for
the
first
time
at
the
last
meeting
in
montréal
Montreal.
We
are
in
for
defining
multicast
responses
as
observed
notifications
and
just
as
a
recap,
this
is
in
general
useful.
The
moment
you
have
multiple
clients
of
all
observing
a
same
resource
on
the
server
that,
rather
than
replying
with
many
individual
responses
to
each
of
those
clients
would
instead
said,
send
a
single
multicast
notification,
and
the
very
practical
use
case
we
consider
is
reffering
use
case
from
the
beginning
is
pub/sub.
E
Where,
then,
you
have
a
number
of
subscribers
all
interested
in
observing
same
request
on
the
broker,
server
and
other
than
the
performance
benefit
of
multicast
here
you'll
be
able
then,
to
keep
those
subscribers
as
pure
clients.
Only
so,
of
course,
multicast
responses
are
not
defined.
Now
you
can
imagine
why
it's
mostly
because
of
problems
related
to
the
binding
of
talking
values
between
requests
and
responses,
not
to
mention
security,
and
this
document
is
exactly
about
filling
this
gap
and
described
how
this
multicast
responses
can
work.
E
The
approach
we
had
in
the
previous
version
was
pretty
much
resigned
more
on
that
later,
but
21
of
the
most
critical
question
from
the
previous
meeting
on
the
handling.
On
the
token
space,
we
ended
to
something
like
this.
The
token
space
formally
belongs
to
the
group
of
observers,
but
then
practically
the
group
is
entrusting
the
protocol
management
of
that
space
to
the
server
bottom
line.
E
The
result
is
that
all
clients
will
be
aligned
to
a
very
same
token
value
that
will
appear
over
and
over
in
all
notifications
for
the
same
group
of
serration
and
like
before,
it
is
possible
to
have
security
using
group
of
score
to
protect
all
those
multicast
notifications
and
when
that's
the
case,
the
clients
will
be
synchronized
in
using
all
the
same
externally
ad
for
well
protecting
a
very
fine
those
multicast
responses.
This
is
at
the
high
level
a
number
of
assumptions.
E
The
clients
have
already
discovered
the
exact
resource
they
want
to
observe
on
the
server
and
the
server
knows
already
the
multicast
IP
address
and
port,
where
to
send
all
teca's
notifications
to
if
group
of
score
is
used
to
protect
the
notifications.
At
least
the
server
must
be
already
in
the
right
Oscar
group,
not
necessarily
the
client
from
the
beginning,
but
there's
a
way.
I
can
show
you
so
that
the
server
can
help
the
clients
to
understand
on
the
run,
was
the
right,
Oscar
group
to
consider.
E
E
We
concluded
that
it's
the
server
that
can
practically
start
the
group
of
servation
on
behalf
on
the
group
at
any
point
in
time,
but
practically
in
case.
One
of
these
two
things
happen.
First,
there
is
no
observers
yet
on
that
resource,
a
first
client
comes
and
the
server
decides
right
away.
Then,
to
start
the
group
observation-
or
there
are
already
a
number
of
clients
observing
that
resource
in
a
traditional
way
and
the
server
decides
no,
it
is
just
better
that
they
all
switch
as
observers
participating
in
a
group
observation.
E
But
how
does
the
server
predict?
We
start
this
group
observation.
It
has
to
do
that
like
on
behalf
of
the
group
and
to
that
end
the
server
generates
what
we
call
a
phantom
observation
request.
So
it's
an
observation
request
for
registration
that
the
server
generates
itself
and
sends
to
yourself
without
hitting
the
wire.
Of
course
it's
like
if
it
is
sent
by
the
group
so
like
from
the
multicast
IP
address.
E
So
practically
the
server
decides
to
start
the
group
observation.
It
was
this
phantom
request
sends
it
to
itself
and
when
building
it,
it
has
to
choose
a
token
value.
Well,
it
chooses
it
from
the
token
space
that
practically
the
server
manages
and
this
token
space
is
related
to
messages
that
are
like
coming
from
the
multicast
IP
address
of
the
group
and
address
to
the
target
resource.
So
the
server
has
all
the
ability
to
to
keep
the
uniqueness
of
the
all-news
token
values
from
that
space.
E
The
server
process
is
this
phantom
request
like
if
coming
from
the
group
from
the
multicast
IP
address
I'm
from
then
on
that
token
value
T
the
server
chose
is
the
one
used
Observation
practically
in
responses.
The
phantom
request
is
stole
and
that
doesn't
have
to
be
a
response
right
away,
a
notification
right
away.
That
can
just
happen
when
the
resource
value,
in
fact
changes.
E
But
what
about
the
clients?
The
server
has
to
tell
the
client
that
this
is
happening
as
a
new
client
comes
or
in
case
clients
already
observing
in
a
traditional
way
are
switched
to
the
group
observation
in
either
case.
The
server
sends
to
the
clients,
an
error
response
that
includes
some
information
and,
in
particular
the
IP
multicast
address
and
port,
where
the
notifications
will
be
sent
a
serialization
of
the
phantom
request,
from
which
the
client
can
take
all
the
little
information
they
need
and
a
current
representation
of
the
target
resource
cause.
E
Clients
were
interested
in
knowing
that
value
already
in
the
first
place,
and
it's
a
bit
unfair
to
push
them
to
send
yet
another
request.
We
can
include
the
current
value
right
there
already
then
later
on.
Of
course,
when
the
value
of
the
resource
changes,
the
server
can
send
multicast
notifications
to
that
IP
multicast
address
with
the
token
value
it's
selected
for
the
final
request
and
in
fact
the
phantom,
the
multicast
notifications
will
be
a
response
to
the
phantom
request.
E
But
when
getting
an
error
response
of
this
kind,
the
client
will
essentially
start
or
configure
on
inside
an
observation
for
that
resource
on
its
own
client
end
point
associated
to
that
multicast
IP
address
and
we'll
accept
notification
address
the
debt
multicast
address.
With
that
token
value,
T
that
the
client
retrieved
from
the
serialized
phantom
request
delivered
in
the
error
response.
E
As
an
example.
Here
we
have
a
server
that
has
no
observers
at
all
at
the
beginning
on
this
resource
as
lee-char
and
first
client,
one
sends
the
traditional
observation
request
and
the
server
decides
right
away.
No
we'll
go
for
a
group
of
servation
here
with
this.
First
client
participate
in
it,
so
the
server
decides
to
allocate
the
token
value.
Ff
creates
a
phantom
request.
E
Essentially,
the
message
in
the
green
box
says
that
talking
value
is
selected,
send
it
to
himself
in
a
way
like
if
coming
from
the
multicast
address,
now
replies
to
the
client
with
an
error
message,
we
went
for
the
error
code.
5:03
does
seem
the
most
appropriate
to
consider
here
and
the
payload
of
these
error
messages
I
said
includes.
Remove
the
cast
address
to
be
considered
for
notifications,
the
serialization
of
the
whole
phantom
request
and
the
current
resource
value
and
well
something
identical
happens
when
a
next
client
CTO
comes
other
than
well.
There's
no
need
anymore.
E
For
yet
another
fan
to
request.
The
observation
is
ongoing
already,
but
the
response
to
the
client
is
exactly
the
same
as
for
the
other
one,
but
eventually
the
value
of
the
resource
changes
and
then
it's
when
the
server
can
finally
send
the
multicast
notification
to
the
group
address
to
that
multicast
address
and
with
the
token
value
chosen
for
this
group
observation.
So
the
binding
here
at
the
co-op
level
is
between
the
multi
class
notifications
and
the
phantom
request.
E
E
This
one
to
request
will
then
have
an
oscar
option,
of
course,
which
will
include
the
sender
ID
of
the
server
and
the
consumed
sequence.
Number
value
of
that
sender.
Let's
say
as
x
and
y.
The
point
here
is
that
then
every
single
following
multicast,
if
occation,
will
be
protecting
using
as
external
a
ad
structure,
including
X&Y
as
Raggedy
Ann
Wragby
heavy,
which
is
consistent.
They
are
the
ones
from
the
phantom
requests.
E
In
fact,
and
since
this
phantom
requests
protecting
the
group
of
score
will
be
still
included
in
the
error
response
to
the
clients,
they
will
be
able
to
retrieve
this
information
to
and
to
build
correctly
that
externally
ad
for
every
single
multicast
notification
coming
later
on.
So
here
you
have
a
secure
tie
between
again
the
notifications
and
the
phantom
request,
based
also
on
grupo
score
optionally.
There
is
the
possibility
for
the
server
to
give
some
more
information
in
that
error
response.
E
E
So
after
that
the
sequence
number
of
the
server
is
stepped
forward.
Of
course,
the
5-0,
the
error
response
includes
also
the
funder
request
as
a
group
of
core
message.
Serialized
and
more
information
on
this
error
response
how
to
join
the
group,
essentially
the
the
link
to
the
join
resource
and
the
name
of
the
group
same
thing
for
the
second
client,
of
course,
with
no
need
for
yet
another
phantom
request.
E
Finally,
when
it's
about
sending
the
multicast
notification,
this
is,
of
course,
also
protected
with
group
of
score
deals:
corruption,
as
this
time
I
partially
5:02,
the
latest
Sigma's
number
to
be
consumed.
But
the
point
is
this:
notification
is
protecting
using
as
external
ad
rec
ID
5,
but
rec
IV
5:01,
so
to
ensure
the
secure
binding
with
the
original
phantom
request.
E
E
G
A
F
E
A
E
Right
was
for
me
today,
at
least
this
is
a
work
led
by
s
code
and
me
the
presentation
today
and
it's
an
update
or
actually
an
attempt
to
obsolete,
if
approved
7390.
That
was
the
fun
in
group
communication
for
coop,
in
fact
over
IP
multicast,
and
this
is
going
to
be
yeah
a
normative
reference
to
group
of
score,
speaking
of
which
we
have
improved
the
nature
of
update
or
absolution
of
all
7390.
A
I'm
just
wondering
about
this
absolute
success,
except
for
the
experimental
protocol,
so
experiments,
of
course,
can
can
run
forever.
But
then
you
never
get
a
conclusion.
So
normally
we
try
to
have
a
point
somewhere.
We
say:
okay,
this
experiment
was
successful.
This
experiment
was
not
so
successful
and
to
me
it
seems
this
experiment
was
not
so
successful.
A
A
Yeah
I'm
just
talking
what
the
part
that
you
you
have
in
your
except
for
and
I
would
imagine
that
at
this
point
we
would
say
this:
this
experiment
has
concluded
and-
and
nothing
came
out
of
it-
I
mean
we're
not
going
to
do
a
replacement
for
this
protocol
and
some
farm
or
anything.
It's
just
an
experiment
that
is
concluded
so
to
me
it
seems
we
actually
can
obsolete
seven,
390
and
all
together.
E
A
E
So
what
happen
from
last
time?
Well,
we
mostly
process
the
many
comments
from
the
reviews
from
Jim
and
Thomas
for
Satya
thanks
a
lot
for
that,
we
reconsider
all
the
content
from
73
90.
In
this
new
light,
we
had
a
number
of
TBD
items
left,
especially
in
the
final
person,
the
document
describing
how
moon
seekers
can
practically
work
in
different
multicast
transport
or
internet
working
among
different
protocols,
and
so
on.
E
We
had
a
huge
number
of
issues
and
on
the
way
they
were
all
closed
up
a
few
two
or
three
ones
you
find
now
came
up
actually
after
the
resignation,
but
it's
minor
things.
So
we
substantially
concluded
the
document,
and
this
will
be
readable
on
the
new
content
we
provide.
We
clarified
a
bit
better
how
coop
works
in
detail
with
such
model,
with
respect
to
request
response
interaction,
we
gave
indication
on
meaningful
good.
Where
is
the
server
can
consider
for
possible
response?
E
Suppression,
and
then
it
is
recommended
in
fact
supports
the
no
response
option
just
as
long
as
this
improved
the
the
the
suppression
policies
in
the
interest
of
the
client.
We
discuss
what
happens
the
pros
and
cons
of
a
client
repeating
multicast
requests
with
the
same
token,
either
changing
or
not
changing
the
value
of
the
message
instead,
so
that
that
can
be
useful
for
being
sure
that
all
the
servers
that
are
reachable
are
on
the
same
page
with
the
client.
E
E
They
should
be
non
confirmable
like
the
request,
but
it's
in
particular
impact
is
possible
to
have
the
confirmable,
and
that
should
happen
here
and
there
for
the
sake
of
liveliness
check
on
possibly
updating
block-wise.
Instead,
we
took
a
step
back
and
we
are
not
really
updating
it
anymore.
We
are
expanding
a
bit
more,
especially
on
the
block
to
usage,
but
all
in
all
along
the
line
all
of
79
59,
but
we
are
just
adding
considerations
on
the
fact
that
block
1
would
be
really
problematic
in
the
multicast
contest.
E
So
we
are
highlighting
the
problems,
but
we
are
not
really
proposing
how
to
solve.
Them
seems
like
a
bit
exaggerated,
an
otoscope
for
this
draft,
possibly
if
there
is
enough
interest
that
can
be
a
topic
for
a
totally
separate
document.
So
because
of
this,
essentially,
we
are
not
really
updating,
79
59
anymore,
as
it
was
intended
originally,
but
this
can
be
discussed,
possibly
if
more
important.
E
Then,
of
course,
you'd
be
interesting
to
start
considering
one
of
those
implementations
supporting
coop,
/,
multicast
I
can
immediately
think
of
californium,
of
course,
and
well
Coco's.
The
multicast
itself
just
worked.
We
used
it
for
a
group.
Mouskouri
Interop
would
be
interesting
to
test
over.
It
is
also
additional
coop
services
and
especially
observe
all-in-all,
considering
the
current
status.
E
A
A
It's
the
the
only
experimental
protocol
that
the
experimental
ever
see
that
that
we
have
produced
here
if
I
remember
correctly,
and
it
would
be
nice
to
get
this
weeks
but
repaired.
But
of
course
you
can
only
do
this
if
we
get
the
reviews
forces
already,
not
that
bad.
So
that
makes
me
is
partially
happy.
F
E
A
F
A
The
question
is:
does
this
cover
all
of
what's
in
the
draft
right
now
and
that's
maybe
something
we
should
ascertain
before
we
actually
go
for
it,
nope
a
score
so
that
that
would
be
one
of
the
reviews
looking
at
implementation
status
and
and
see
how
confident
we
are
yeah.
But
apart
from
that,
I
think
this.
This
is
a
good
work,
so
anybody
else
who
would
argue
for
adoption
of
this
document.
A
A
So
next
is
sin.
Well,
as
I
said,
we
have
have
two
documents
in
the
is
G
right
now
and
we
have
two
documents
that
are
in
various
stages
in
the
working
group
and
what
we
will
do
is
we
will
look
at
all
four,
but
maybe
we
are
going
to
look
at
units
in
the
end,
because
the
inventor
of
sin,
ml
and
founding
chair
of
this
working
group
isn't
here
yet
Helen
Jennings
and
he
has
some
some
interest
in
getting
this
fixed.
So
we
start
with.
H
The
other
things
okay,
so,
let's
start
with
its
impacts
with
10
ml
arm.
So
this
draft
is
all
in
iese
review.
It's
currently
state
that
it
needs
a
revised
draft.
There
was
no
updated
person
for
this
idea,
because
I
wanted
to
have
all
the
updates
in
the
front
is
reviews
in
the
same
person,
but
you
can't
find
the
Inga
Topsail
requests.
Those
latest
changes,
so
that's
very
good.
H
One
of
the
recurring
comment
we
got
from
my
ESC
was
this
fragment
ID
section
was
a
bit
confusing,
so
I
did
a
rewrite
for
that,
and
also
I
did
some
examples
and
at
least
I
haven't
got
any
complaints
on
the
new
version
so
far,
also
added
but
expansive
clarifications
that
what
are
they
really
the
mandatory
parts
you
need
in
every
fetch
and
patch?
There
needs
to
be
at
least
one
record
at
each
record
needs
to
have
at
least
a
name
it,
etc.
Also
that
co-op
is
used
for
securing
these
operations
cause.
H
So
how
currently
both
veteran
patch
work
that
you
always
include
a
name
of
the
record,
and
you
may
include
a
time
to
select
the
records
either
for
fetching
or
for
patching
and
the
reason
for
doing
a
design
like
that
only
including
a
few
fields
there
is
that,
then
you
can
use
these
few
fields
or
find
the
record
and
every
other
field
for
patching
them.
Like
90%
of
cases,
you
actually
want
to
patch
only
the
value,
but
there
is
you
know,
usefulness
for
appeals
also
add
new
fields
to
the
records.
H
What
we
didn't
actually
pay
attention
to
that
is
already
in
the
RFC
examples.
Quite
often
unit
is
used
to
also
disambiguate
on
records,
so
you
may
have
same
name
for
a
source
of
data
but
read,
for
example,
say
this
is
latitude.
This
is
longitude
and
only
unit
tells
you
apart,
which
record
is
the
relevant
part
for
which
part.
So
obviously
we
do
need
to
also
add
unit
to
the
list
of
selectors.
So
the
proposal
here
is
to
update
that
and
say:
yes,
you
always
have
name,
and
you
may
have
time
and/or
unit.
H
A
H
Yes,
so
the
way
we
chose
to
form
whole
Pat's
FX
record.
Has
this
downside
that
what
is
wherever's
use
a
selector
cannot
be
used
as
patcher,
so
you
have
to
choose
one
way
or
the
other.
That's
all
so
we
got
the
question.
So
where
do
you
draw
the
line?
Well,
this
is
what
we
want
to
draw
the
line,
get
the
very
minimal
set
that
you
really
need
that
name
time
and
unit
to
select
uniquely
records.
H
H
Then
another
thing
that
Adam
pointed
out
that
we
should
probably
clarify
that
the
record
order
matters
in
the
patching.
So
what
what
may
happen
that
you
have
multiple
records
that
are
operating
on
fields
with
similarities,
so,
for
example,
if
you
have
two
records
that
both
end
up
removing
the
same
record
in
the
target
pack,
that's
that
should
be
an
error.
But
you
don't
really
know
until
you
actually
handle
the
fact
you
are
actually
handing
handling
them
both.
H
So
what
Adam
was
suggesting
as
a
solution
that,
first
of
all
clarifying
that,
if
Pat's
record
matches
more
than
one
cinema
record,
that's
immediately
an
error,
that's
something
we
may
want
to
consider,
but
that's
more
on
the
next
slide,
and
if
this
one
of
the
signature,
if
any
of
the
patch
records
fails,
then
you
don't
change
anything.
So
the
whole
patch
needs
to
be
atomic
and
then
you
would
apply
all
the
records
sequentially
I
mean
this
seems
to
me
a
very
reasonable
thing
to
clarify
on
the
graph
that
it
need
to
be
addressed.
H
H
Alternative
design
here
would
be
that
you
can
match
multiple
records
with
a
single
patch
record
and
you,
for
example,
be
able
to
delete
multiple
records
when
this
was
first
suggested
to
me,
I
think
was
close.
Okay,
that's
it
that's
a
good
idea.
I
did
a
bit
more
thinking.
I
found
a
whole
bunch
of
complexities,
there
corner
cases,
so
it
might
be
just
simple
to
go
for.
Okay,
you
don't
want
to
do
this,
you
if
you
need
to
modify
something,
put
a
separate
hats
record
for
every
single
modification.
H
You
want
to
do
and
and
be
done
with
it.
So
this
is
basically
a
request
for
you
guys
if
you
have
a
use
case
in
mind
that
you
would
think
of
matching
multiple
records
for
patching
is
a
must,
please,
let
me
know
as
soon
as
possible,
otherwise
I'm
leaning
towards
it's
an
error,
if
attach
record,
happens
too
much
multiple,
such
a
simple
thing
to
handle,
and
then
II.
You
really
did
that
by
being
more
specific,
which
record
you
need
to
apply
to
any
immediate
reactions
on
that.
H
A
H
I
H
Okay,
so
presenting
on
behalf
of
Carsten,
he
straps
I
may
have
been
also
active
contributor
for
this
draft.
So
quick
reminder
about
the
Sentinel
unis
registry:
it's
basically
it's
a
sorts
ring
source
strings
to
represent
units
of
measurements,
so
we're
not
defining
units,
I
mean
there's
other
organization
who
actually
do
that
work.
What
we
are
defining
here
is
that
how
do
you
express
those
in
cen
ml,
so
M
stands
for
meters,
etc,
and
s
for
seconds.
In
the
original
cinema
RFC,
we
had
a
rather
restrictive
registration
policy.
H
So
if,
in
order
for
those
models
to
use
only
the
units
we
had
originally
in
the
central
registry,
they
would
have
to
change
a
large
amount
of
existing
models
which
can
be
very
impractical
and
also
in
many
uses.
There
is
a
natural
scale
offset
or
a
unit
that
is
used,
for
example,
millisecond
in
some
use
of
time,
micro
micrometers
for
particle
size,
even
though
ad
meters,
for
it
usually
always
missing
micro,
micrometers
or
Gore
kilowatt
hours,
if
you're
doing
our
power
stuff.
H
So
a
proposal
that
we
had
at
last
IETF
is
to
have
this
secondary
registry
of
Sentinel
units,
so
it
would
be
another
Ruby
C,
with
slightly
different
kind
of
rules.
That
would
be
accepting
also
the
scaled
units,
but
they
would
be
mapping
rules
always
to
the
original
cm
central
units
and
there's
a
few
example
from
kilometer
and
and
DBM
on
how
that
works
in
practice.
H
There's
also
a
long
discussion
on
the
email
list
that
I
think
Colin
initiated
on
that
and
really
like.
Is
this
right
right
right
way
to
do
things
and
how
do
you
work
still
one
actually
maintain
the
interoperability
but
still
accommodate
on
some
of
the
need
needs
on
the
industry.
So
what
the
draft
that
Carson
wrote
currently
says
is
that
we're
not
commanding
the
use
the
secondary
units?
It's
really
that
the
case.
You
really
have
to
do
it
and
and
then
basically
used
use.
You
use
the
first
table
if
you
at
all
can.
H
If
you
cannot,
then
here's
a
way
you
can
still
deal
with
its
nml.
But
of
course
there
were
some
concerns.
Are
we
actually
now
creating
two
different
kind
of
sentinels
and
how
do
how
do
we
deal
with
interoperability
when
there's
gonna
be
much
more
units
than
maybe
a
lot
of
implementations
were
expecting
for
anything
else?
You
don't
say
on
this
one.
A
Yeah
I
think
there
are
several
facets
to
this.
One
is
the
editorial
one
to
say
may,
but
should
not.
This
sounds
almost
like
an
RFC
sixty
nine
one,
nine
keywords,
but
it's
really
not
meant
that
way,
and
the
other
one
is
is
the
way
we.
We
are
updating
eight
four
to
eight
the
right
way
by
simply
saying
we
are
putting
in
that
secondary
registry
and,
of
course,
a
few
implements
anywhere
you
implement
that
secondary
registry,
but
still
its
use.
It's
not
it's
not
recommended.
So
these
are
two
different
levels.
A
G
Challenge
eggs
I
mean
this-
is
all
this
won't
change
anything
in
what
happens
in
the
real
world
right
like
whether
we'd
maze
made
me
out
you
should,
but
we
know
you
will
whatever
right
like
I'm,
not
really
that
I
think
that
we
need
to
hit
the
core
problem
and
then
may
will
come
back
in
tune
these
words
a
little
bit
but
I
just
wanna
know
one
thing
on
the
framing
of
this.
This
is
not
something
new
we
discovered.
G
We
knew
all
of
this
information
about
units
long
before
we
set
up
the
current
registry
in
the
current
RFC.
We
discussed
all
of
this
extensively,
so
this
and
I'm
not
saying
we
shouldn't
really
and
change
and
and
which
I
think
is
the
proposal
already
has
here
or
both
of
you
have
but
I
don't
think
it's
like.
G
We
suddenly
discovered
that
people
used
milliseconds,
yeah
I
also,
don't
think
it's
and
we
have
a
trade-off
between
what
will
help
us
achieve
interoperability
of
this
data
in
where
it's
used,
not
just
the
focus
of
what
would
be
convenient
to
generate,
and
we
need
to
think
about,
though,
both
of
those
we
go
forward
on
this.
That
make
sense.
A
G
And
that
was
a
well
known
in
the
previous
version
of
this
argument
and
discussed.
We
made
the
previous
discus
decisions
that
is
not
new
information
either
and
so,
and
so
anyway.
My
recommendation
on
this
slide
is
this:
isn't
the
right
time
to
worry
about
the
details
of
that
we
should
go
figure
out
what
our
real
solution
looks
like
on
the
stuff
and
then
come
back
to
what
advice
I
mean
clearly,
if
we're
making
a
table
it's
because
we
intend
people
to
use
it.
That's
why
we're
making
this
whole
thing.
G
H
And
one
one
thing
I
think
would
make
a
lot
of
sense
to
do
is
I
mean,
instead
of
just
saying
may,
but
should
not
like
write
down
that
rationale.
That
I
mean
lot
of
that
was
documented
in
the
email
discussion
that
we
had
on
the
mailing
list
like
why
using
table
1
actually
makes
makes
a
lot
of
sense,
and
there
are
a
lot
of
non-obvious
aspects
there
putting
those
in
the
draft.
H
But
then,
yet
that
we
had
a
good
discussion
this
morning
with
Colin
and
Carsten,
starting
at
7:00
a.m.
that's
how
committed
we
are
so
based
on
that
I
guess
we
kind
of
yeah.
We
do
want
to
do
this
accommodating
for
their
more
units,
that's
kind
of
where
we
agreed
on
what
we
have
in
the
end,
quite
a
bit
of
discussion.
Okay,
so
how
do
we?
How
do
we
handle
this
registry
of
within
new
units?
So
we
did
discuss
some.
Some
proposed
expert
review
guidance
for
now
what
we
call
table
to
more
relaxed
units.
H
So
one
way
to
phrase
is
what
thinking
would
be
that
units
are
founding
existing
scientific
literature
or
specification,
and
that
you
can
point
to
a
a
specification
that
uses
this
unit.
You
know
whether
is
some
industry
consortium
or
or
my
a
suspect,
then
pretty
much
would
be
accepted.
Of
course,
if
there's
the
already
same
unit
for
that
thing,
so
we
shouldn't
have
two
strings,
meaning
the
exact
same
thing.
H
That
would
make
much
sense,
but
sometimes
there
are
cases
where
actually
it
really
deep
down,
it
is
the
same
thing
but
they're,
two
different
industries
that
are
using
different
quote-unquote
unit
describe
that
then
maybe
that
actually
make
sense
to
have
have
the
same
same
unit.
So
a
different
unit.
Identifier
for
the
same
underlying
SI
unit
and
also
checking
when
there
is
a
new
registration
I
mean
it
would
be
kind
of
towards
first
on
first-served.
H
You
would
check
that
okay,
if,
if
that
someone
wants
to
register
cm
for
meaning
something
else
in
centimeter,
probably
should
advise
them
to
go.
You
know
find
another
identifier
for
it
and
also
what
we
actually
have
right
now
is
we
have
these
two
things
were
same
a
scientific
reactive,
apparent
power.
We
may
want
to
move
some
of
these
things
to
the
table
to
that
when
people
originally
proposed
for
for
a
table.
One
though,
and
we
should
think
about
the
naming
syntax.
One
thing
that
was
recently
proposed
was
this
evens
per
hour
per
square
meter.
H
In
the
original
guidance
we
had
like.
Okay,
you
shouldn't
have
more
than
1/4
watchlist
in
the
units,
but
for
that
kind
of
unit
two
forward
classes
may
make
sense,
produces
an
initial
draft,
unlike
the
guidance
on
the
table
to
cause
them.
Current
guidance
in
in
the
grass
was
rather
maybe
what
wasn't
wasn't
quite
adequate
and
maybe
even
conflicting.
G
So
:
James,
could
you
say
a
little
bit
more
on
this
I
mean
you
know
I.
This
makes
a
very
open
register
and
just
to
provide
some
examples
intent.
This
makes
very
open
registry.
If
somebody
is
asking
for
micro
fortnight's
as
a
unit
of
time,
we
probably
give
it
to
them
right
and
definitely
miles
per
hour
and
everything
else
for
sure
and
it's
you
know
it's
to
try
and
give
people
what
they
want,
and
we
I
mean.
G
We
have
examples
that
are
already
in
the
draft,
like
the
heart
beats
per
minute
unit
that
you
know
it's
hard
to
justify
some
of
these
things
right
and
this
that
would
be
fine
in
this
table
would
allow
exactly
those
types
of
things.
One
other
thing
that
I
really
want
to
highlight
for
people
is
this
reactive
apparent
power?
We
have
lots
of
things
where
people
really
want
to
use
units
for
something
that
is
not
units
at
all,
but
tags,
additional
semantic,
meaning
to
them
and
I.
Think
this.
G
You
know
the
different
types
of
power
measurements
are
excellent
examples
of
a
good
use
of
that,
and
we
should
allow
that.
But
that
opens
the
slippery
slope.
I
think
this
will
totally
open.
Also,
you
know
in
in
minion
Street
parts-per-billion
of
carbon
dioxide
and
parts-per-billion
of
oxygen.
They
consider
those
two
different
units
and
that's
no
different
than
the
power
one,
so
I
think
we've
got
to
be.
G
Okay
with
that
and
III
think
this
would
I
can
see
many
advantages
of
having
the
second
type
of
registry
that
had
that
very
open
type
of
idea,
particularly
with
the
machine
readable
way
of
mapping
it
back
to
Table
one.
So
I
just
want
people
good
with
that
type
of
openness
to
this
table.
I
mean
I.
Think
that's
one
of
the
things
that
re
aren't
trying
to
get
feedback
on
here.
J
Hi
I'm
I'm
Matt
Gilmore
I
work
with
Itron.
To
your
point,
though,
quite
frankly
we
do
not.
We,
my
company
makes
electric
meters
we've
shipped,
probably
200
million
smart
meters
across
the
world.
We
all
right
so
I
get
it
that
you
can
represent
kWh
and
it's
just
a
scalar
unit
of
joules,
but
we'll
never
ship
joules
over
the
air,
its
kWh,
so
I
mean
there's
got
to
be
some
means
where
an
industry
has
a
standard
and
we're
just
trying
to
bring
it
out
to
the
IOT
and
that's
why
we
went
to
secondary
registry
I.
G
Mean
I'd
say
heard
loud
and
clear
and
you're,
not
the
first
people
to
say
exactly
that
right.
It's
not
the
only
example.
We've
had
other
people,
you
know
have
said
when
they
sit
when
they
set
a
house
temperature
in
Fahrenheit
or
Celsius
they're,
not
converting
it
they're,
setting
it
to
what
it's
either
21.5
or
79
degrees.
But
it's
it's
not
something
else.
H
So
I
think
we
have
a
pretty
good
agreement
that
okay,
we
will
have
more
units
and
it's
more
on
the
details
like
how
do
we
organize
the
whole
thing
and
then
the
expert
review
guidance
is
kind
of
one
key
part
there.
So
all
the
feedback
here
would
be
very
much
appreciated
and
if
and
of
course
anyone
volunteering
to
be
the
expert
I
mean
those
are
also
highly
appreciated.
Someone
you
know
background
on
these
kind
of
things.
I
think
would
be.
It
would
be
very
good.
H
Okay,
there
one
more
slide,
or
you
want
to
comment
right
on
this
one.
Oh
okay,
then
one
issue
we
couldn't
quite
get
agreement
on
or
we
could
we
still
need
to
do.
Some
more
analysis
on
is,
should
be
used,
the
same
you
field,
or
should
we
have
a
new
field
for
the
units
in
the
second
table?
And
now
that's
called
the
YouTube
field,
so
in
the
first
process,
over
you're
using
the
same
unit
for
both
I
mean
they
both
go
in
same
X
new
field.
H
There
are
some
downsides
to
it,
for
example,
that
if
you
wrote
software
that
is
kind
of
expecting
things
in
table
one
you
may
have
assumed
that
this
is
rather
stable
registry.
Of
course
there
will
be
new
units,
but
not
like
in
masses,
so
those
assumptions
may
might
be
broken
once
you
get
like
you
know,
100
new
units
in
in
the
table
to
also
in
some
cases
it
might
be
used
with
a
clear
indication
on
the
wire
is
the
stuff
from
the
table.
One
or
table
to
the
top
would
actually
then
make
a
youtube
proposal
potential.
H
On
the
other
hand,
having
a
separate
field
for
this
units
from
table
to
it
does
create
in
importance
nm
a
lot
of
complexities,
different
feel
for
similar
things
and
that's
what
we
hit
when
we
were
discussing
the
content,
type
string
and
a
numeric
value,
we
okay,
it's
a
simple
thing:
let's,
let's
make
them
separate
fields,
cause
they're
different
values.
No,
it's
you
need.
A
lot
of
complex
is
a
lot
of
a
lot
of
corner
cases,
how
base
values
overwrite
each
other,
and
you
just
bunch
of
complex
logic,
which
you
can
easily
avoid.
H
H
Anyone
interested
in
this
and
willing
to
chat
a
bit
more
feedback
could
be
highly
welcome.
We're
planning
to
talk
about
bit
more
during
the
week,
and
maybe
we
can
a
quick
one
on
the
coarsest
on
Friday.
Two
on
our
conclusions,
where
we
may
land
during
this
week
and
actually
have
a
proposal
for
wayforward
right
now.
We
don't
have
clear
one.
A
G
Yeah
I,
just
so
I'm,
not
sure
that
the
you
or
you
I'm,
not
sure
that
you
two
is
the
only
way
to
skin
this
cat,
but
the
the
thing
that
I
feel
very
strongly
about
is
we
have
these
two
options
of
spectrums:
they
have
pros
and
cons
and
the
spectrum.
What
we
chose
in
cinnamon
al
was
very
much
in
favor
of
what
made
it
easy
to
do
analytics
and
combine
this
data
and
use
it
in
our
operable
way
and
I.
Don't
think
that
we
can
just
I
think
we
need
to
find
a
backwards
compatible
way.
G
If
we're
going
to
change
this,
we
can't
just
we're
too
late
to
just
change
it.
There's
too
much
software
written.
That
assumes
that,
if
it's
dealing
with
the
units,
it
will
understand
them
and
be
able
to
process
it.
So
I'd
like
us
to
find
some
way
that
it's
very
clear
whether
we're
using
the
new
units
or
the
old
units
I,
don't
I,
don't
believe
that
any
amount
of
you
should
or
should
not
use
this,
or
that
I
mean
we
just
heard
the
answer
to
how
that
conversations
gonna
go
right.
G
It
doesn't
so
I
think
that
we
need
to
to
think
about
all
the
things
that
went
with
the
assumption
of
our
current
RFC.
We
have
to
not
break
why
they
did
that
and
what
what
they're
doing
it,
and
this
would
do
it
there
might
be
other
ways
to
do
it,
but
I
think
we
need
to
find
some
way
of
not
breaking
that
type
of
interoperability.
Yep.
G
H
H
H
B
B
Maybe
you
should
talk
to
him.
I
think
I
might
be
incorrectly
proxying
his
comments,
but
he
thinks
that
one
registry,
with
an
extra
column,
saying
whether
it's
recommended
or
not,
would
be
better
was
confusing
to
people.
But
again
you
know
I
personally
sort
of
don't
care,
but
some
people
feel
strong
is
another
I
suggest
you
talk
to
him
and
see
if
it's
fab
boxing
of
his
comments
or
whether
very
smart,
read.
H
Think
it's
really
administrative
thing
and
I
I
agree
with
Carsten
that,
like
the
separate
tables,
make
mix
makes
a
sense
from
administrative
point
of
view,
but
yeah
it's
good
point.
Let's,
let's
check
with
Peter
explicitly
on
that.
At
least
he
didn't
react
on
the
later
comments
where
we,
where
we
were
converging
on
this
way
of
doing
things
like
a
calling
was
in
the
in
the
end
favor
of
the
two
tables
and
as
everyone
else
yeah.
G
K
G
I
mean
it's
definitely
a
very
minimum.
A
Rev
of
the
draft
is
definitely
needed.
That's
for
sure,
on
the
on
the
splitting
and
moving
things
forward,
I
am
NOT
I'm,
not
really
very
ok
with
that,
because
if
we
are
going
to
use,
I
would
rather
not
have
these
new
units
than
have
them
in
the
you
field
with
no
solution
to
the
problem
posed
here.
So
if
we're
going
to
add
these
new
tables,
there
has
to
be
some
way
of
dealing
with
this
problem.
G
I'm
not
so
be
very
clear
on
that
I'm,
not
okay
with
if
we
know
how
we're
going
to
do
it,
but
it's
not
finished
yet.
That's
fine
I,
don't
care,
but
we're
not
going
to
agree
on
the
units
before
we
agree
whether
we
are
breaking
the
whole
design
of
the
currents
in
ml
on
a
non
backwards
compatible
way
right.
H
We're
going
to
at
least
those
different
options
on
up.
You
know,
he's
a
paper
or
a
screen
and
think
about
that
once
I
think
we
have
many
ways
to
solve
this
and
I'm
sure
we
will
find
a
way,
but
I
think
like
in
order
to
make
things
move
us
as
fast
as
possible.
I
think
if
we
could
like
prepare
for
the
pre-registration
of
these
units
that
it
doesn't
have
to
wait
until
you
know,
there's
an
RFC
mark
on
it.
I
think
that
would
be
very
good
for
for
everyone,
depending
on
these
new
units.
H
Just
basically
right
now,
since
I,
oh,
oh
ma,
we
kind
of
chose
to
use
these
units.
We
are
working
new
registrations
of
objects
before
we
get
these
units
ready.
So
there
is
some
some
urgency
in
that
sense,
otherwise
we'll
need
to
find
a
way
around
it
and
that
could
just
get
messy
in
the
end.
So
it
would
be
much
more
clear
to
have
the
units
in
a
registry
and
then
we'll
figure
out
how
we
have
to
deal
with
that
good
I
think
that
was
my
last
slide
on
that
topic
and
the
next
one.
H
Okay,
data
value
content,
format,
indication
just
a
quick
reminder:
what
this
draft
is
about,
it's
about
giving
content
format,
information
about
the
things
that
you
wouldn't
send
ml
include
in
your
VD,
this
data
value
field.
So,
for
example,
the
example
on
the
top.
That's
on
putting
C
bore
array
in
a
senemo
data
and
the
second
one
would
be
putting
basically
comma
separated
values
run
through
Z
gzip
for
compression
in
the
data
value.
H
The
change
is
what
we
had
done
since
the
last
IETF.
What
we
agreed
over
there
is
that
we
are
now
used
in
the
same
field
and
string
values
for
both
the
content,
format
and
cone
type
encoding,
so
we
used
to
have
different
field
for
this
shrink
type
and
the
integer
type
that
resulted
in
all
the
complications
that
I
refer
to
earlier.
So
now
we're
just
using
string.
H
Even
though
there's
a
numeric
numeric
value,
you
put
it
in
a
string
because
it's
a
simpler
and
there's
a
white
or
two
of
overhead,
but
that
seems
to
be
well
worth
it.
Also.
We
added
this
mandatory
to
understand
version
of
the
CT
supposed
to
see
the
underscore
or
base
city
underscore,
and
we
also
had
a
bunch
of
examples
about
alexei
was
was
asking
for
to
actually
validate.
Does
this
way
that
we
form
the
string
versions
made
make
sense
so
there?
H
You
can
now
see
a
few
examples
that
are
listed
in
the
current
Kraft
I
think
in
particular
out
the
last
one
and
the
second
to
last.
One
Burgess.
Also
the
content
coding
included
are
the
interesting
ones
so
using
now
this
new
format
of
having
the
cone
encoding
separated
by
at
sign
as
part
of
the
string
that
allows
us
to
use
a
single
field
for
all
of
these
piece
of
information
and
avoiding
some
of
the
complexities
with
multiple
fields.
H
However,
they're
still
the
same
complication
that
we
briefly
discussed
last
time,
how
do
you
handle
mixing
base
fields
and
mandatory
to
understand
fields?
What
is
the
really
the
field
that
ends
up
being
used
after
you
have
resolved
the
records
and
it's
important
to
go
take
case
number
one.
That
is
a
tricky
that
you
have
a
base
value
for
foo,
that
you
say
it's
mandatory
to
implement,
implement
and
I
understand
and
later
on.
You
would
have
a
food
that
is
not
mandatory.
H
So
currently,
so
this
is
nothing
specific
to
this
graph.
It's
a
cinema
feature
at
large,
but
this
is
the
first
graph
where
we
actually
hit
this
issue.
So
current
text
is
that
okay,
they're
mandatory
to
understand
field
overrides
the
regular
field
and
you
shouldn't
be
mixing
them
and
shouldn't
be
mixing
the
max.
It's
a
very
sensible
thing
overall
and
but
you
may
not
be
able
to
avoid
that
if
you're
combining
send
email
from
multiple
sources,
so
one
source
used
to
monitor.
H
Do
you
understand
the
other
one
used
regular
fields,
you
want
to
put
them
in
the
same
pack?
How
do
you
deal
with?
We
thought
we
had
a
resolution
on
it?
Then
we
realize
it's
actually
more
complicated
than
you
think
so.
Arsene
1925
rule
8
applies
also
here.
So
we're
planning
to
have
a
one
more
closer
look
on
these
rules.
How
does
it
actually
should
be
resolved
again?
H
H
H
The
final
sentiment
draft
the
base
prefix.
So
this
is
a
draft
I
wrote
together
with
Christy,
announces
the
idea
there
is
that,
since
a
memo,
we
have
this
requirement
for
COBOL
unique
names.
For
example,
in
the
RFC
week,
I'm
only
use
ipv6
prefix
in
the
previous
of
the
name
in
order
to
get
Discovery
unique
names
and
the
whole
idea
there
is
that
it
puts
global,
unique
names.
They
facilitate
information
exchange
across
multiple
systems,
because
you
have
a
global,
unique
identifier.
You
can
always
point
to
regardless
of
the
source
where
you
actually
got.
H
The
information
from
the
downside
of
this
choice
is
that
you
sometimes
have
a
long,
and
this
is
long
in
quotes.
Cuz
I
mean
depends.
How
are
you
mister
to
long
names
can
end
up
some
tens
of
bytes
of
overhead
for
a
pack
its,
and
so,
if
you
are
in
a
very
constrained
Network,
something
like
Laura
one
for
perhaps
it
accident
may
make
a
big
difference
for
you
and
you
want
to
release
squeezed
out
there.
The
remaining
bytes.
H
H
So
the
proposal
in
this
draft
is
that
you
would
be
able
to
indicate
how
should
you
construct
the
base
name
based
on
the
information
that
is
available
out-of-band
and
then,
when
this
information
is
no
longer
available,
for
example,
after
the
first
hop,
you
then
put
replace
this
this
pointer
with
the
information
that
you
are
using
and
therefore
be
able
to
use
again
like
standard
RFC,
SN
ml.
There
is
an
IP
r
declaration
on
this
draft.
There
number
360
you
can
go
and
check
it
out
that
for
more
details,.
H
Then,
of
course,
a
question
is
like
what
kind
of
values
can
you
use
for
BPI?
Here's
our
current
proposal,
so
it
would
could
be
used.
I
P
address,
as
in
the
previous
example,
potentially
with
the
port.
Also,
what
seems
to
be
rather
common
thing
is
used
a
request
base
URI
so,
depending
where
you
did
the
request
on
that
could
be
used
to
form
the
global
unique
base
name.
Also,
if
you
have
security
association
on
your
connection,
are
you
using
TLS
or
something
similar?
H
You
could
use,
for
example,
your
public
key
or
the
fingerprint
of
the
public
key
there's
a
nicely
defined
format
in
RFC,
69,
20,
or
how
you
could
do
that
or
you
could
use,
for
example,
tsk-tsk
identity
or,
if
you're,
using
a
core
resource
director,
your
endpoint
identifier,
or
often
already
usable
for
this
purpose.
So
you
just
say:
okay,
you
use
my
endpoint
I
need
fire
as
the
base
name,
prefix
and
you're
done.
H
The
current
status
of
this
work,
Hannes
ja,
panic
actually
presented
at
the
last
IETF.
Another
draft
was
addressing
the
same
problem.
This
problem
was
originally
discovered
in
the
OMA
or
we
may
work
or
related
to
light
with
NPM,
because
they
were
actually
using
using
something
like
this,
but
not
being
explicit
about
it.
So,
basically
in
in
love
the
case,
you
only
sent
the
path
component
and
not
actually
the
prefix
component,
as
we
generally
having
an
insane
ml.
So
what
this
method
would
be
doing
is
making
that
information
explicit.
H
So
then
you
can
use
things
from
the
omiai
within
the
metro
system
and
things
from
outside
in
an
intrical
fashion.
The
key
difference
compared
to
the
harnesses
proposal
was
that
there
was
a
new
field
instead
of
base.
Name
of
these
relaxed
rules
are
based
on
or
local
based
name
that
relaxes
the
rules
for
uniqueness.
Different
approaches
are
for
the
same
case,
however,
as
Hannes
pointed
out
on
the
mailing
list,
I'll
seems
that,
at
least
within
the
OMA
sphere,
the
stuff
seems
to
be
interoperable.
H
Even
without
this
addition,
so
we
should
have
a
closer
look
like
in
what
kind
of
cases
would
we
actually
need?
This
I
think
it's
gonna
be
mostly
valuable
when
you
do
go
outside
of
a
let's
say,
for
example
like
within
the
ecosystem,
and
you
actually
need
to
exchange
information
in
sending
a
format
outside
of
ecosystems.
But
you
still
want
to
have
this
good
compression
inside
techo
system,
but
we'll
be
looking
into
more
details
on
that
and
and
reporting
in
the
upcoming
IETF
meetings.
H
I
said
I
will
have
a
closer
look
and
I
think
we'll
know
at
the
next
idea.
Unfortunately,
a
bit
along
your
vacation
before
this
I
didn't
have
time
to
do
that
analysis.
So
we'll
have
a
closer
look
and
see
what
direction
makes
sense
I
mean.
Should
we
potentially
combine
the
mechanics,
Newton
is
proposed,
or
is
this
one
way
or
better
or
the
other
I
think
like
from
author's
point
of
view?
Closer
look
is
needed
so
consider
this
as
more
as
a
heads
up
and
intro
to
the
problem
and
and
potential
solutions.
Okay,.