►
From YouTube: IETF109-CORE-20201117-0500
Description
CORE meeting session at IETF109
2020/11/17 0500
https://datatracker.ietf.org/meeting/109/proceedings/
C
I
lost
the
connection
there
for
a
second
sorry
welcome
back
right,
yeah,
we
have
still
still
people
are
not
here,
but
I
have
a
funny
anecdote
yeah.
So
the
I
have
one
socket
right
here
where
I
have
the
mokula
connected
this
phone:
okay,
it's
like
a
small
mobile
mobile
router,
and
yesterday
I
unplug
it
for
a
moment.
C
A
C
C
D
C
C
C
Okay,
so
should
we
start,
we
are
already
five
minutes
past,
so
welcome
to
the
core
session
and
and
good
morning
to
everybody,
those
in
europe
and
good
good
evening
or
good
night
and
for
those
in
asia.
I
guess
it's
good
afternoon
or
or
it's
earlier
actually
anyways,
I'm
jaime
and
marco,
and
I
and
we
are
we're
having
marco
tilocca.
We
are
the
chairs
and
we
are
going
to
be
conducting
the
session
this
morning.
C
C
C
Well,
we
have
the
curate
request
in
imiteco.
We
have
also
some
new
features
for
doing
some
sort
of
humming,
which
is
the
show
of
hands
which
maybe
we
will
use
for
queuing
as
usual,
just
type
make
a
column
and
ask,
and
and
so
on,
and
the
meeting
will
be
recorded
and,
as
I
said,
the
blue
sheets
already
automatically
filled.
So
for
today's.
C
This
is
the
agenda.
We
will
start
with
rd
and
stateless
and
few
other
material
graphs,
the
drafts
and
then
move
to
group
com
and
oscore
and
friday
well,
friday
will
be
whatever
is
left
from
from
this
time.
As
you
can
see,
we
have
two
hours
each
time.
So
probably
there
won't
be
anything
left
out,
and
I
think
I
think
we
have
plenty
of
time
so
time
for
agenda
bashing.
C
C
The
vrn
we've
had
some
updates
by
jari
and
I
think,
also
pretty
much
ready
and
similarly
with
the
core
request
stack,
so
we
have
quite
quite
good
progress.
I
think
we
can
accomplish.
I
mean
this
can
be
done
very
quickly
and
let's
see,
let's
see
how
the
session
develops
for,
for
the
first
two
then
on
post
working
group
last
call
so
we
are
awaiting
the
write
up
on
on
the
core
conf
cluster
and
yeah.
That's
essentially
the
status.
I
believe.
C
A
C
B
B
I
won't
go
through
all
of
them
here,
because
there
is
a
detailed
changelog
and
if
you
have
anything
particular
then
please
look
it
up
there.
How
about
there's
four
things
that
I'd
like
to
point
out
first,
is
that
a
new
section
was
added
a
new.
Basically,
security
policy
was
added
for
previously
this
only
outlined,
however,
security
policy
means
what
a
security
policy
could
do,
and
now
we
have
a
concrete
example
which
may
be
chosen
by
implementations
as
a
default
policy.
B
It
turned
out
there's
no
really
good
reason
to
answer
that
that
question
that
came
about
that.
So
it
was
actually
changed
to
a
new
to
a
new,
well-known
resort
to
be
registered
resource
and
a
lot
of
the
examples
had
our
resource
type
values
that
were
based
in
in
the
core
interfaces
draft,
which
is
not
active
enough
to
really
warrant
having
using
registered
values
there
that
are
not
actually
registered.
B
So
this
all
the
next
slide,
please,
there
were
a
few
questions
that
we
did
address
as
the
questions
themselves,
but
there
was
follow-up
work
to
do.
There's
still
follow-up
work
to
do
that
has
not
wound
up
in
the
document
yet
and
there's
roughly
three
topics
around
this
first
is
the
the
topic
of
dtls
replays.
So
the
original
comment
here
was
that
we're
using
ptls
like
tls,
so
it
might
be
a
good
idea
to
to
enable
replay
protection,
but
really
the
same
thing.
B
So
the
the
one
thing
where
replays
can
be
problematic
is
where
the
is
is
not
immediately
mitigated
by
by
turning
on
replay
protection.
So
if,
even
if
we
turn
on
liquid
protection,
it
would
still
be
possible
to
exploit
something
like
a
device
registering
and
deregistering
repeatedly
and
then
injecting
a
message
in
which
the
devices
the
device's
registration
is
deleted
without
the
device
I
actually
haven't
authorized.
This
next
slide
base,
so
there
is
a
work
in
progress
text
to
mitigate
that.
B
B
Next
slide,
please
another
question
that
came
up
was:
how
much
can
you
trust
the
links
from
the
resource
directory
and
there's
a
simple
answer?
That
is
that
the
security
policies
tell
you
that,
but
from
the
white
space
of
the
on
the
bottom
of
the
slide,
you
can
tell
that
this
is
not
all
of
it
next
slide,
please
so
a
device
uses
the
authorizations
it
has
to
create
a
request.
Then
it
has
an
intention.
B
It
phrases
this
into
a
request
and
that
request
then
has
other
side
effect
which
gives
it
the
response
slightly.
In
concrete.
This
might
mean
that
a
device
wants
to
create
a
topic
and
then
discovering
a
property
of
a
particular
resource
phrases.
This
into
a
request,
let's
say
a
post
request
to
slash
topics.
Another
topic
that's
created,
and
while
the
process
between
the
request
and
the
action
is
well
protected,
we
don't
really
have
much
in
terms
of
how
does
the
device?
How
can
we?
B
B
So
in
terms
of
the
resource
directory,
I
don't
think
we
have
anything
much
more
to
do
so.
We
already
stated
in
earlier
versions
that
this
is
something
to
take
care
about
when
thinking
of
application
of
into
of
the
integration
between
the
resource
tracking
and
the
security
policies.
Due
to
the
latest
changes.
We
now
also
follow
that
same
advice
when
it
comes
to
how
the
resource
directory
is
discovered,
but
we
should
probably
have
some
more
discussion
on
on
how
this
was
mitigated
in
the
general
case.
B
So
one
way
of
doing
it
is
saying
that
a
server
should
really
only
use
one
have
one
function.
This
is
something
like
that
in
oauth,
but
that
means
we've
got
a
lot
of
security
context.
This
could
mean
that
we
introduce
a
way
of
verifying
statements.
The
resource
directory
this
would
all
or
any
other
means
of
discovery.
B
Next
slide,
please,
and
the
third
upcoming
change
for
dash
27
is
the
topic
of
examples
and
the
link
format
representation
again,
so
we
are
doing
two
things
with
respect
to
rfc
6690
link
format.
That
is
one.
We
described
that
there
is
a
subset
that
we
think
that
everyone
who's
implemented
it
can
can
actually
work
with,
because
there
is
there's
a
few
bits
of
misalignment
between
the
actual
implementations.
B
That
also
stems
from
ambiguity
in
the
original
document,
and
the
other
thing
is
that
we
prescribe
that
both
both
the
link
target
and
the
anchor
need
to
be
fully
expanded
on
the
next
slide.
Please
thing
is
the
kind
of
the
the
the
the
reading
of
the
duck
of
6690
that
caused
the
most
trouble
and
the
most
overhead
in
terms
of
bites
on
the
wire
was
my
reading
and
in
the
discussion.
B
I
think
that
from
the
discussion
I
take
it
that
this
reading
was
wrong
and
that
we
can
simplify
what
we
send
on
the
wire
a
lot
like
actor
f2
in
many
cases,
and
so
pending
a
check
of
the
other
implementations
which
I've
reviewed
but
two
years
ago,
which
I
need
to
go
over
again.
This
could
still
be
changed
to
not
prescribed
that
the
anchor
must
be
there
unconditionally,
but
give
a
still
simple
but
way
sharper
rule
about
when
it
needs
to
be
there
and
update
the
examples
accordingly.
B
Next
slide
guys.
So
that's
the
three
things
that
still
should
probably
change
in
a
follow-up
document.
So
the
mail
to
the
reviews
all
so
indicated
that
this
is
addressing
the
their
concerns.
As
they
were
phrased,
but
those
questions
raised
more
questions
and
they
will
be
answered
in
the
dash
27
on
how
to
have
this
in
a
submittable
state
around
the
start
of
december
questions,
comments.
G
E
D
I
saw
that
you
when
you
posted
26,
you
sent
a
note
to
the
to
the
three
ads
who
have
discusses
on
the
resource
directory
document
and
they
haven't
responded
yet,
which
is
now
about
two
weeks
ago.
It
would
be
good
to
follow
up
on
that
and
make
sure
it
doesn't
get
lost.
I'm
sure
they
were
busy
leading
up
to
the
meeting,
so
maybe
in
another
week,
ping
them
again
and
remind
them.
B
D
H
B
So
the
thing
is
the
the
client
has
something
in
in
mind
when
it
wants
to
send
a
request
and
it's
using
material
that
it
has
around
about
the
server.
So
that
might
be
that
might
be
a
link
that
might
be
attributes
on
a
link
that
might
even
be
a
form
that
might
be
something
that
it
got
from
from
a
401
you'll
need
to
register
with
that
es
response,
and
not
all
of
that
information.
B
The
client
will
have
with
with
another,
from
a
source
that
it
can
trust
as
much
as
it
can
trust
the
origin,
server
and
assembling
that
information
into
requests
means
that,
if
that
information
is
grossly
misleading,
the
request
might
be
not
what
the
client
intended,
but
will
still
be
executed
with
whatever
credentials.
The
client
has
so,
if
say,
you're,
trying
to
create
a
topic
and
you're
discovering
from
from,
for
example,
from
a
resource
directory
that
there
is
a
resource
with
that
property.
B
Then,
if,
if
that
information
is
wrong,
for
example,
if
if
actually
on
that
resource,
there
is
a
thing
that
says
please
do
you
ask
me
in
a
very
blunt
example,
then
the
client
would
authorize
that
action,
believing
that
it
means
something
different,
and
this
intention
is
not.
Trans
is
not
part
of
what
we,
what
we
authenticate
in
the
in
the
even
with
the
request
response,
violence
that
we
have
in
our
school.
B
H
B
B
B
B
B
B
B
B
A
A
C
B
Yeah,
the
question
is:
can
the
security
issues
be
addressed
with
link
layer
security
only
if
that
linked
late?
If
the
link
layer
security
extends
to
the
origin
server,
which
in
most
cases
it
will
not
so
link
layer,
security
would
might
might
get
you
to
the
resource
directory,
but
in
the
general
case
it
won't
get
you
to
the
origin
server
and
will
not
give
you
better
other
any
better
statements
about
the
any
better
verification
on
the
statements
that
the
client
will
act.
B
I
C
C
G
Now
yeah
now
it
works,
go
ahead,
reload
it
again,
so
it's
been
re
disconnected
about
three
times
since
we
started
the
meeting.
Okay,
so
core
stateless,
so
stuck
on
review
comments
since
may
next
slide,
please,
these
are
slides,
are
mostly
the
same
as
in
the
virtual
interim.
This
is
really
the
update,
so
a
bunch
of
these
were
marked
as
don't
won't
fix.
You
can
go
through
them
and
read
the
comments,
if
you
like
the
about
this-
and
there
are
some
emails
about
that
on
the
list
next
slide.
Please.
G
One
of
the
things
was
a
suggestion
to
use
automatic
key
management,
but
that
would
only
really
apply
if
in
fact,
there
was
another
peer.
So
in
this
case,
what
we're
talking
about
is
a
node
is
going
to
send
a
token
to
another
node.
The
other
node
is
not
going
to
decrypt
it,
but
rather
it's
going
to
echo
it
back
with
the
response,
and
so
actually
you
can
use
any
kind
of
randomly
generated
key
you
like,
and
you
just
encrypt
your
token
and
then
when
you
get
it
back.
G
You
decrypt
your
token,
so
you
just
basically
have
to
make
sure
that
you
still
have
the
key
around
and
that
it's
strong
enough
or
fast
enough
to
deal
with
the
fact
that
you
could
have
an
attacker
trying
to
send
you
lots
of
random
nonsense.
So
you
don't
want
to
burn
out
your
battery
trying
to
deal
with
that.
G
So
there's
a
preference
for
using,
for
instance,
whatever
hardware
accelerated
encryption
algorithm
you
have,
and
the
text
now
has
some
recommendations
and
some
issues
about
the
replay
window,
which
is
to
say
how
long
you
will
stick
around
and
allow
keys
to
sorry
responses
to
arrive
out
of
order
before
you
start
saying:
well,
wait
a
minute!
I
it
they're
they're,
probably
too
old,
and
I
won't
accept
anymore.
G
G
G
So
07
was
uploaded
on
the
on
the
12
on
november.
2.
08
was
uploaded
25
minutes
ago,
as
I
was
pointed
out
that
the
it
could
now
be
uploaded
and
ben
has
has
replied
actually
today,
just
or
whatever.
That
means
today
a
few
hours
ago
and
has
cleared
the
discuss
and
there
may
be
one
additional
cycle,
perhaps
about
some
tweaking
some
words,
but
I
don't
think
so
and
that's
it
any
questions.
G
D
C
G
G
C
C
C
Yeah,
okay,
I
mean
this
was
a
very
brief
presentation,
but
I
think
everything
has
been
pretty
much
covered
during
the
interim,
so
maybe
there
is
no
need
to
duel
any
longer
on
this
topic.
Another
comment,
sorry.
I
know
all
right:
there
is
no
okay,
then,
let's
move
on
to
the
next
topic,
just
a
second!
C
C
A
A
J
Okay,
maybe
let's
start
with
the
presentation
now
good
communication,
so
we
are
presenting
here
this
revision,
two
yeah.
This
is
just
an
overall
goal
of
group
communication
yeah
this
slide,
so
it's
intended
as
the
successor
of
rc7390
and
now
recast
as
a
standard
track
document
and
in
scope
is
co-op
group
communication
over
udp
ip
and
now
also
possibly
secured
with
groupon
score.
J
So
I'll
give
now
an
overview
of
the
status
updates
of
the
zero
two
revision
and
there's
also
the
tickets
linked
to
that,
and
so
the
first
thing
we
changed
well
was
to
clarify
the
messaging
and
endpoint
model.
We
had
some
discussion
that
the
server
might
actually
respond
from
a
different
udp
port
and
that
turns
out
to
be
a
legitimate
way
of
responding
to
multicast
in
co-op.
So
this
is
now
clarified
in
the
messaging
model
text
and
then
issue
number
two,
that's
a
very
small
change.
J
We
had
some
requirement
for
consistency
for
response
suppression,
so
now
it's
based
on
the
class
of
the
response
code.
So
if
a
server
typically
yeah
suppresses
a
response
of
a
certain
class
like
4.x
or
5.x
due
to
policies,
then
it
should
be
consistent
so
that
all
the
responses
of
that
class
are
also
suppressed.
J
It
was
some
a
big
piece
of
text,
so
this
is
now
expanded
into
sub-sections
and
we
have
more
details
on
the
relation
relations
between
the
different
group
types.
So
there's
the
co-op
group
application
group
and
the
security
group
yeah,
there's
also
the
option
added
after
discussion
that
we
could
use
the
uri
host
option
for
encoding
application
group
and
that's
a
possible
way
to
do
it.
But
on
the
other
hand
it
has
some
problems
of
its
own.
J
J
And
yeah
the
next
change
was
that
the
fetch
method
was
also
included.
Many
places
were
applicable
so
where,
before
it
said,
get
we
now
say
often
is
get
or
fetch
if
it
applies
also
in
the
observe
and
the
blockwise
is
included
now,
and
there
were
quite
some
changes
in
the
text
so
that
that
falls
under
the
various
enhancement
and
editorial.
J
J
J
Yeah,
so
what
are
the
next
steps
of
this
draft
yeah?
There
was
some
feedback
from
marco.
I
received
the
last
minute,
so
I
think
he
can
tell
more
about
it.
So
one
of
the
first
things
was
due
to
the
interrupt
experience
of
last
week.
It
was
the
idea
to
move
the
handling
of
multiple
cog
responses
from
the
co-op
layer
and
to
the
application
layer.
So
that
means
maybe
some
text
in
2.3.1
and
all
this
needs
to
be
changed,
and
the
second
point
was
the
proxy
operation
233.
J
It's
not
really
talking
about
much
about
caching
of
responses,
and
I
think
what
we
need
to
do
is
first
explore.
Maybe
some
scenarios
in
caching
so
suppose
a
client
sends
out
a
request
to
a
proxy
and
that
leads
to
a
group
communication
operation,
so
the
proxy
sends
out
the
multicast
and
receives
the
responses
to
that.
J
So
are
there
situations
where
the
proxy
can
actually
suppress
the
sending
of
the
multi-customer
quest?
So
what
if
another
client
comes?
Does
a
similar
or
the
same
request?
Can
it
actually
suppress?
In
that
case,
the
sending
of
multicast
requests
and
instead
serve
from
the
cache
and
also
yeah,
is
the
proxy
able
to
do
a
cache
refresh,
so
it,
for
example.
It
knows
it
already
has
a
90
of
the
responses
cached
and
they
are
fresh
as
well.
J
J
J
B
Kristen,
I'm
just
we've.
We've
brought
this
up
in
a
in
a
discussion
during
the
hackathon
and
I
don't
think
that
there's
anything
that
would
stop
this
from
working
other
than
the
server
needing
to
needing
to
react
on.
Oh
wait!
No
sorry!
I
missed
something
that
we
found
there
yeah
sure
on
the
server
wouldn't
know
if
there's
any
other
and
the
client
wouldn't
know
if
any
servers
had
collisions
on
their
e-text.
So
that's
the
that's
the
hard
point
there.
B
F
Okay,
yeah,
you
would
have,
you
would
have
to
include
some
server
identification
together
with
the
e-tag,
because
the
the
request
addresses
somebody
different
from
from
who
the
e-tags
are
associated
with.
So
that's
why
this
becomes
big
and
ugly
very
quickly
and
why
I
haven't
actually
made
a
proposal
out
of
that,
but
I
think
maybe
we
can
continue
to
think
in
that
direction.
J
J
A
A
Great,
so
this
is
an
update
of
the
group.
Score
document
now
needs
version.
10.
next
slide,
please
the
version
tender
we
submitted
right
before
the
cut
off
includes
updates,
mostly
addressing
comments
we
received
following
the
working
group
plus
call
that
closed
in
july
two
reviews
out
of
them
and
more
comments
that
came
up
around
itf,
108
and
right
after
so
I
have
an
overview
of
them
in
the
next
slides.
A
Otherwise
we
had
a
third,
I
think,
interrupt
set
of
tests
during
the
past
hackathon,
with
three
different
implementations
involved
and
for
the
first
time
we
also
tested
successfully
the
pairwise
mode
of
group
of
score,
considering
different
algorithms
and
and
different
combination
of
roles,
so
more
testosterone,
but
I
think
we
have
covered
all
the
main
functionalities
here
now
and
again
during
the
the
hackathon.
Last
week,
we
received
a
review
from
christian.
Thank
you
very
much
for
that
of
this
version,
10
that
will
process
for
the
for
the
next
round.
A
Right
an
overview
of
the
updates
in
this
version
10
some
regarded
the
the
security
context.
It
was
noticed
some
information
was
just
redundant,
so
we
removed
the
counter
signature
key
parameters
as
all
that
information
is
indicated
already
in
the
counter
signature
parameters,
entry
related
to
the
algorithm,
while
we
also
added
some
more
parameters
in
the
common
context
highlighted
in
red
here,
describing
the
algorithm
and
the
properties
for
the
pairwise
mode.
If
this
is
supported,
of
course,
as
a
suggestion,
also
around
working
group
call.
A
A
A
Right,
something
happened
also
for
the
sequence
number.
Eventually
we
convert
for
keeping
things
as
they
are
for
the
the
space
of
value.
So
we
keep
one
single
space
shared
for
both
the
group
mode
and
the
pairwise
mode,
but
we
introduce
the
change
so
that
whenever
the
context
is
updated
or
re-established,
meaning
a
new
sender
id
is
assigned
or
there's
a
whole
group
requiring
and
the
key
material
changes.
A
A
We
better
clarify
the
requirement
that
wasn't
to
clear
in
the
previous
version,
even
is
protected
with
a
latest
new
context,
which
happens
to
be
different
from
the
one
used
to
protect
the
request
because
of
an
interleaved
wrecking
well.
The
server
definitely
has
to
use
its
sender
sequence
number
as
partially
v
to
be
included
in
the
response
to
avoid
answer
usage.
A
Also
now
that,
as
I
mentioned
before,
the
sender
sequence
number
is
reset
in
case
of
raking,
and
we
still
want
to
have
observations
surviving
across
a
possible
raking,
and
we
need
to
do
something
to
be
sure
that
a
given
notification
cannot
match
with
more
than
one
original
registration
request.
Cryptographically.
A
That
means
that
all
observations
have
to
be
linked
with
the
same
original
observation
request,
also
by
the
original
group
id
that
was
used
when
the
registration
request
was
sent
and
that
practically
meant,
including
one
more
parameter
in
the
external
aed,
as
request
kid
context,
specifying
in
fact
the
original
group
id
value
used
in
the
registration
request.
So
this
is
beneficial
necessary
for
observations
only,
but
practically
it
ends
up
in
in
the
external
ids
for
all
messages.
Of
course,
next
slide,
please.
A
Okay
and
something
more
again
on
supporting
observation,
exactly
for
what
I've
just
mentioned,
we
were
saying
already
in
previous
versions
that
the
client
and
the
server
have
to
store
the
original
key
id
from
the
registration
request.
Now
they
just
have
to
do
the
same.
Also
for
the
original
group
id
and
to
clarify
some
comments
around
this
from
working
group.
Call.
A
A
A
There
was
one
main
point
that
we
discussed
for
several
hours
during
the
the
academ,
concluding
that
the
draft
should
be
a
better
distinction
between
the
the
anti-replay
and
possible
freshness
requirements
that
have
to
be,
of
course,
addressed
in
different
ways,
which
includes
also
better
clarification
of
what
we
mean
with
a
server
synchronizing
with
a
client
which
is
strictly
related
to
to
freshness
and
building
on
this.
We
have
different
approaches
for
synchronization
in
appendix
e
and
and
out
of
the
discussion.
A
We
could
understand
that
we
definitely
still
need
the
approach
on
appendix
e3,
based
on
the
echo
exchange
for
the
sake
of
making
replay
windows
valid
and
also
achieve
freshness.
Thanks
to
that.
But
then
that,
basically,
following
those
clarifications,
would
make
the
the
current
approaches
in
e1
and
v2
well,
basically
moot
as
not
contributing
to
freshness
and
not
contributing
to
under
replay
very
much
other
than
what
you
already
have
from
a
correct
and
valid
replay
window.
So
they
can
possibly
just
be
removed.
A
And
while
discussing
on
this,
we
found
also
one
more
possible
reason
to
have
a
loss
of
mutable
security
context
of
part
of
it
and,
and
especially
the
recipient
context.
That
can
happen
because
servers
have
memory
limitations
that
practically
set
a
maximum
amount
of
recipient
context
that
can
be
around
at
the
same
time
inside
the
group
context.
A
A
H
A
J
A
The
group
id
changes
if
the
key
material
changes,
because
the
group
manager
ultimately
takes
the
decision
to
rekey
the
group
when
the
group
id
changes,
and
that
happens
in
case
of
working,
we're
just
saying,
is
possible
that
sender
id
is
not
currently
used
really
at
the
moment,
can
also
become
free
for
reassignment
and
it's
safe
to
do.
Yeah.
A
Okay,
thank
you
and
next
other
point
was
about
the
external
aad
structure.
On
the
left.
You
see
what
we
have
now.
One
version
is
for
the
encryption
operation
and
one
version
is
for
the
signing
operation
for
the
group
mode.
Only
we
started
with
this
design
before
editing
in
the
last
version
request,
kd
context,
because
before
doing
that,
the
version
on
the
extreme
left
for
encryption
was
really
mirroring
the
version
from
oscore.
A
J
J
A
A
A
Okay,
a
little
bit
open,
also
to
discuss
on
the
list-
and
one
last
point
I
think,
is
still
related
to
the
external
ead
structure
and
right
now
we
are
covering
the
the
the
current
set
of
existing
and
register
cosy,
algorithms
for
each
of
which
the
only
algorithm
capability
registered
is
the
key
type
and
that
results
also
in
the
parking
design,
parameter
to
specify,
in
fact,
only
the
capabilities
of
that
key
type.
In
turn.
A
So
we
started
to
wonder
if
we
can
take
this
opportunity
to
generalize
this
format
a
bit
more
for
possible
future
algorithms.
That
cosi
would
theoretically
admit
that
can
have
zero
or
more
than
one
capability
and
then
require
more
information
to
be
expressed
there
as
capabilities
in
power
counter
sign-
and
there
is
a
kind
of
abstract
meta
format
that
we
can
consider
for
it.
But
for
what
we
have
today,
they
would
practically
become.
What
we
have
already
so
to
say
are
coded
in
detail
in
the
document.
J
A
J
E
A
Okay
yeah:
this
version
is
addressed
comments
for
working
group
last
coal
and
around
the
the
previous
meeting,
with
a
successful
test
at
the
akaton,
as
next
step
is
submitting
version
11
addressing
christian's
review
and
run
even
some
more
tests
again
in
pairwise
mode
testing.
Also,
some
error
conditions.
A
B
B
So,
to
recap
what
this
is
all
about
when,
when
a
device
enters
a
network
that
is
configured
to
join
a
group,
it
may
have
very
limited
information.
So
it
may
know
that
it
has
this
particular
application
group
and
it
will
probably
have
some
some
credentials
stored,
but
it
may
not
know
where
this
resource
director,
where
this
group
actually
is,
how
to
join
it,
etc
and
link
and
web
linking
can
generate
a
next
clip
history.
B
B
So
in
the
in
the
updates
that
were
published
before
this
itf,
we
basically
addressed
the
the
the
comments
that
came
in
and
closed
several
of
the
of
the
open
points.
So
we
we
now
state
explicitly
that
a
few
things
that
the
that
the
cozy
registry
theoretically
allowed
allows
can
just
not
be
done
with
this
with
link
format,
because
it
can
distinguish
between
a
literal,
minus
two
and
the
digit
minus
two.
B
Let's
type
this,
which
is
okay,
there's
a
few
more
updates
when
it
comes
to
to
the
precise
values
we're
using
for
resource
type
and
interface,
which
are
now
aligned
better
with
with
our
documents
where
they
are
partially
moved
or
where
they
are
taken
from.
So
we
don't,
we
don't
specify
any
of
this
ourselves
anymore.
B
Next
slide
is
what
we
do
currently
specify,
because
the
because
nothing
else
in
ace
is
doing
this
so
far
is
describe
how
those
web
links
can
be
used
to
discover
where
the
where
the
authorization
server
for
a
particular
resource
is
located.
So
when
the
registration
is
done
in
this
way.
With
this
additional
piece
of
information
on
the
left,
then,
in
the
discovery
process
on
the
right,
the
client
can
send
an
additional
resource.
Lookup
query,
to
find
where
the
authorization
server
is
now.
B
B
B
J
B
So
if
that
information
is
not
passed
to
the
group
manager,
then
someone
else
can
generally
put
it
in
the
resource
directory
and
register
those
statements
about
the
join
resource,
but
then
that
someone
else
needs
to
get
all
the
information
from
the
group
manager
about
where
the
actual
join
resource
for
that
security
group
is
and
what
its
properties
are,
and
they
would
need
to
put
that
into
resource
directory.
So,
yes,
in
in
principle,
listen.
This
doesn't
need
to
be
done
by
the
group
manager,
but
it
appears
now
that
this
is.
This
would
be
the
logical
choice.
B
J
I
J
C
B
This
very
this
very
point
of
the
very
point
of
this
slide.
Yes,
this
could
be
used
in
a
more
generic
way
and,
quite
frankly,
I'm
I'm
kind
of
still
hoping
that
this
is
getting
picked
up
in
ace,
and
then
we
can
do
what
we
did
for
the
other
for
the
art
resource
type
on
the
interface
and
just
say
that,
and
by
the
way
they
are
saying
how
it
is
done,
and
this
could
be
used
here
as
well,
but
right
now
this
has
not
been
picked
up.
C
Do
we
need
any
kind
of
communication,
in
particular
with
ace?
I
I'm
not
in
contact
at
least
with
these
people.
I
maybe
marco,
you
are
more
more
in
contact
with
them,
but
I'm
wondering
like.
Is
there
something
we
can
do
marco
and
I
to
to
help
to
to
help
for
for
a
folks
to
pick
this
up?
It
sounds
like
an
important
feature.
It's
very.
It
looks
very
useful
actually,
because
authorization
is
a
recurring
topic
on
on
rd.
I
guess
we
all
have
had
issues
with
that.
A
H
B
You
like
the
link
relation,
so
if,
if
ace
could
say
that
one
way
of
expressing
that
for
accessing
a
particular
resource,
you
would
need
to
get
a
token
from
this
particular
as
and
this
relation
is
expressed
with
the
link
relation
type
authorization
server.
Whichever
gets
picked,
then
that
would
be
a
small.
B
F
B
B
F
F
F
Yeah
yeah,
maybe
actually
it's
one
of
the
things
that
we
need.
This
iot
ops
group
four,
because
ace
is
kind
of
stuck
in
in
the
oauth
past
and
we
really
need
a
more
comprehensive
view
of
authorization
flows
and
I
think
the
the
onboarding
discussion
is
a
good
source
of
of
information
in
this
environment.
We
have
had
a
bit
of
onboarding
discussion
in
the
think,
research
group
and,
if
io
geops
actually
takes
off,
that
may
be
a
good
focal
point
for
for
getting
that
discussion
going
on.
K
I'm
just
very
clumsy
with
my
mouse
hi:
oh,
this
is
hank.
No,
there
is
no
formal,
iot
ops
meeting
this
week.
Unfortunately,
it's
a
timing
issue.
There
are
isg
meetings,
though
so,
but
but
there
will
be
a
presentation
on
iot
ops
in
the
ops,
awg
and
rob
will
talk
to
that,
and
I
think
that
is
a
point
where
to
ask
questions
about
when
where
why-
and
maybe
this
topic
here,
please-
and
I
also
can
bring
it
up
if
nobody
is
joining
unless
conflicts.
I
will
do
that.
Of
course,
thanks
thanks
a
lot.
C
C
C
C
C
B
B
B
So
we
introduce
multicast
responses.
We
define
how
the
token
space
here
works
in
that
it's
still
the
client
and
the
quotes
that's
responsible
for
the
token
space,
but
the
client's,
a
multicast
group
and
the
next
best
delegation
point.
There
is
the
server
with
whom
this
group
is
talking,
because
that's
part
of
what
fragments
the
token
space.
B
B
How
this
actually
works
is
that
the
server
sends
the
server
sees
that
people
are
interested
in
the
resource.
Whether
it's
on
the
first,
whether
it's
by
configuration
or
just
when
a
threshold
is
crossed,
creates
an
own
request
that
it
will
then
consider
the
consensus
request
or
the
configured
request.
B
It
can
send
what
we
call
an
informative
response
and
an
error
response
so
that
the
original
kind
of
the
the
individual
observation
request
is
declined.
But
in
the
error
response
there
is
information
how
to
how
to
hook
into
the
the
request
that
is
already
going
on
from
the
multicast
group.
Next
slide,
please.
B
So,
since
the
dash
03,
we've
updated
the
format
of
this
response
and
really
have
been
converging
on
in
one
part
of
this
design
space.
So
the
design
space
ranges
from
we
express
we
are
kind
of
taking
apart
the
whole
co-op
messages
and
then
in
older
versions.
We've
had
even
particular
co-op
options
expressed
as
fields
in
this
response
and,
on
the
other
hand,
of
the
design
space.
B
B
Please,
the
nice
property
about
this
new
field
is
that
we
can
make
it
work
with
proxies
so
the
especially
in
the
case
of
protect
of
oscar
protected
multicast.
So
in
in
in
such
a
situation,
the
proxy
has
no
way
of
knowing
what
the
what
what's
in
that
option,
because
what's
in
the
payload,
because
it's
encrypted
and
the
client
has
to
go
through
the
proxy
again
and
ask
it
to
join
that
multicast
group
and
the
way
we
are
proposing.
B
B
This
is
an
option
that
I
have
to
understand
and
if
it
understands
it,
it
can
then
not
send
out
the
request,
because
it
would
have
to
send
it
from
the
multicast
address
by
the
values
in
there
and
instead
join
that
multicast
group
and
forward
the
responses
to
the
to
the
original
client,
and
what
I
think
is
particularly
neat
about
this
is
that
the
original
client
doesn't
even
have
to
be
aware
of
what
udp
is.
So
if
say,
that
original
client
is
sitting
in
a
web
browser.
B
B
So
what
else
changed
since
since
dash
since
station
four,
since
dasho
three
we've
updated
the
mechanism
that
helps
us
that
helps
us.
Do
the
estimate
of
the
number
of
active
clients
based
on
the
suggestions
from
custom
on
comparing
the
last
bits
of
something?
So
we
still
go
with
randomness,
because
we
don't
necessarily
have
good
client
identifiers.
We
can.
B
We
can
use,
but
now
the
the
basically
the
factor
that
the
that
the
server
uses
to
control
how
many
responses
it
wants
to
get
back
is
now
expressed
as
an
exponent,
thus
much
more
compact
and
that's
also
easier
to
compute
for
the
client.
So
we
now
have
pseudocode
in
the
appendices
that
describe
how
this
can
be
done
very
easily
with
a
client
with
a
with
an
embedded
device.
B
Next
slide,
please
yeah!
I
think
I've
largely
mentioned
everything.
That's
that's
relevant
here,
yeah,
when,
when
proxies
are
used
without
entering
security,
this
whole
process
is
a
bit
can
be
a
bit
more
streamlined,
but
with
enter
and
security.
There
is
just
no
way
for
the
proxy
to
look
into
the
option
in
between
so
there
there
has
to
be
some
round
tripping
on
the
on
the
kind
of
on
the
downstream
and
involved
that
a
lot
that
gives
the
proxy
the
information
that
originally
passed
through
it
to
slide
forward.
Please.
B
So
what
are
our
open
points?
One
more
place.
We
we've
just
briefly
after
publicate
after
submission.
We've
noticed
that
there
is
still
a
few
odd
points
around
the
proxy
example.
So
if
you
want
to
review
this
right
now,
I'm
we're
happy
to
take
your
reviews,
but
please
be
aware
that
the
proxy
examples
probably
need
a
bit
of
more
work.
B
We
would
like
to
tackle
the
questions
in
the
next
revisions
of
where
and
how
we
can
negotiate
about.
This
was
the
main
question
being.
Is
there
any?
Is
there
any
point
in
negotiating
this?
If
the
only
possible
outcome
is
that
no,
you
can't
you?
We
can't
use
this
anyway,
because
if
the
server
decides
that
it's
too
cumbersome
for
it
to
manage
all
those
individuals
registrations,
all
those
individual
observations
and
the
client
can't
can't
join
a
group.
Then
really
those
two
will
not
find
together.
B
A
probably
easier
point
is
the
topic
of
whether
or
not
the
last
notification
needs
to
be
in
the
informative
response.
So
right
now
it's
mandatory.
We
think
about
making
it
optional,
because
that
would
roughly
mimic
what
the
what
an
observation
over
unicast
looks
like,
because
you
can
get
the
response
back
immediately,
but
you
could
just
as
well
receive
an
empty
act
and
whenever
the
server
gets
new
information
which
it
can
pass
on,
it
will
actually
do
that
and
the
first
response
will
just
have
to
wait
a
tad
longer.
B
B
C
J
B
Just
just
wondering
does
that
have
a
specific
advantage
in
this
case,
it's
from
so
the
thing
is,
it
would
save
a
lot
of
of
I
mean
that
group
would
only
be
used
between
that
server
and
the
clients
and
might
even
be
limited
in
terms
of
which
resources
on
the
server
are
accessible
by
this
group.
So
this
is
not
something
where
there
is
any
larger
audience
to
this
group
than
the
audience
of
that
server
itself.
Yeah.
J
B
B
C
B
Necessarily
so
what
if,
if
there
is,
if
we
have
roth
consensus
on
the
basic
workings
which
we
haven't
touched
in
a
while,
then
I
think
we
this
this
would
be
an
option
from
my
point
of
view,
there's
a
lot
of
details
that
still
can
be
that
still
need
to
be
hammered
out.
But
I
don't
see
why
this
couldn't
take
place
in
the
group
as
well.
E
C
Yeah,
that's
a
good
point.
Well,
we
can,
I
guess
we
could
we
could
marco,
please
let
me
know
if
you
agree
or
disagree.
I
guess
we
could
we
didn't
plan
for
for
a
specific
show
of
hands
today,
but
we
could
do
a
a
show
hands
on
the
on
the
on
the
chat
of
miteko
chat,
but
not
the
chat
but
the
application
next
to
it
and
see.
How
does
the
group
feel
for
adopting
this
document
now?
Otherwise,
I
my
understanding,
was
that
there
was
no
specific
urgency
on
this
one.
E
C
B
C
Yes,
so
we
can
do
we
can
do
if
it's,
okay
with
you
francesca,
we
could
do
a
quick
show
of
hands
virtual
hands
on
the
on
the
miteko
and
like
that,
without
any
confirmation
I
mean
anything
else
would
happen
on
the
main
list
as
well,
but
at
least
we
could
get
a
feeling
for
what
the
group
thinks.
If
that's,
okay
with
you.
C
C
C
C
G
C
F
C
So
I
guess
in
addition
to
those
I
will
ask
the
question,
but
let's
finish
the
session,
I
guess
nobody
else
is
raising
the
hand,
so
we
have
12
like
for
the
mini
takers.
We
have
12
that
had
voiced
positively
for
the
adoption
of
the
document
and
one
that
has
possible
is
negatively
out
of
31
participants
right
now
in
in
the
meeting.
H
C
Difference,
no
so
yeah,
that's
a
good
point.
The
options
available
were
to
raise
hand
or
not
to
raise
hands,
so
I
guess
race
hand
is
pretty
clear.
You
are
in
favor
of
adopting
a
document.
You
do
not
raise
your
hand
or
I
guess
you
raise
your
hand
negatively.
I
don't
even
know
actually
what
that
means
here.
I
D
D
J
F
C
F
C
Yeah
yeah-
I
was
just
thinking
about
that,
but
anyways.
I
think
I
think.
Basically,
we
we
got
mostly
positive.
All
positive
comments,
comments
with
the
with
the
with
what
esco
just
mentioned
in
the
in
the
call.
So
I
will
need
more
reviewers,
I
don't
so
we
we
do
have
joran
and
carsten
you'd
be
nice
to
have
all
the
potential
reviewers.
J
C
C
C
If
I
manage
to
make
this
thing
work,
it
should
work
for
one
more
presentation.
Yes,
okay,
so
I
guess
francesca
you'll
be
moved
to
friday.
If
that's
okay
with
you
like
right,
sorry
for
making
you
wait
and
we
okay,
thank
you
and
we
moved
to
esco
sorry,
it's
hard
to
track
the
the
chat
and
the
screening
and
everything
at
the
same
time.
J
J
So
recap
of
how
this
works:
there
is
a
client
sending
a
unicast
request
to
the
proxy
and
the
proxy
will
translate
that
into
a
multicast
group
communication
quest,
and
the
idea
we
have
is
that
the
client
should
indicate
that
it's
interested
in
and
capable
of
handling
multiple
responses
and
also
how
long
the
proxy
should
collect
and
forward
back
responses,
because
normally
the
client
determines
how
long
it
listens
for
responses.
Now
that
needs
to
be
done
by
the
proxy
and
we
use
a
new
car
option
for
that.
The
proxy
will
actually
remove
that
option.
J
Now
the
proxy
gets
back
the
responses
from
the
origin,
surface
and
yeah.
It
also
includes
for
each
of
these
responses.
A
new
co-op
option
responds
forwarding
to
indicate
to
the
client
which
server
responded
so
that
it
can
distinguish
the
individual
responses,
so
it
gets
an
ip
address,
also
from
for
each
responding
server,
and
also
here,
grouposcore
can
be
used
for
end-to-end
security
and
also
possible
is
to
use
dtls
or
oscore
security
between
the
client
and
the
proxy
directly.
J
I
J
That
we
did
was
well
editorial
reorganization
of
the
text
for
observation
now,
there's
some
more
dedicated
subsections
added
there
and
yeah.
The
observation
is
also
explained
in
more
in
detail,
so
the
idea
is
that
the
proxy
just
keeps
forwarding
the
notifications
back
until
the
observation
terminates.
So
this
will
extend
beyond
the
yeah
the
time
that
is
indicated
for
a
normal
responses
collection,
so
this
will
just
persist
basically
until
termination
security
considerations
are
updated.
J
J
J
J
So
sometimes
you
can
basically
get
some
information
on
the
client
already,
of
course,
from
the
payload
of
the
response
or
from
the
security
context
of
it.
But
this
also
is
a
basic
way
to
to
indicate
to
clients:
okay,
where,
where
is
this
server?
What
ip
address
did
it
respond
from,
so
that
helps
the
client
to
be
able
to
contact
the
server
in
unicast
one
to
one
if
it
wants
to
to
either
find
a
proxy
or
directly
if
possible.
J
J
So
usually
the
report
would
be
omitted
then,
before
it
used
to
be
an
absolute
uri
with
the
scheme
and
the
host
name,
and
now
we
have
made
it
smaller.
So
that's
a
positive
thing:
less
and
there's
also
less
parsing
to
do
for
the
client
useful
for
constraint
lines
yeah.
The
downside
is
that
it's
not
possible
for
the
proxy
anymore
to
to
insert
the
dns
hostname.
J
J
J
Slides
yeah.
So
this
concludes
the
chain
of
proxy's
explanation.
So
responses
go
back
each
time
to
the
previous
hop
and
in
this
case
only
the
yeah,
the
last
proxy.
So
that's
the
one
that
send
out
the
yeah.
Basically,
the
group
request
and
gets
the
actual
responses
that
will
add
the
response,
forwarding
options
and
these
other
proxies
in
the
chain
so
that
are
before
it
do
not
alter
or
remove
the
response
forwarding
option:
okay
and
then,
if
we
do
that
it
will
work
next
slide.
Please.
J
Yeah
then
we
can
have
oscor
also
between
clients
and
proxy
and
yeah
that
can,
at
the
same
time
coexist
with
grouposcore
used
between
the
clients
and
servers.
So
that's
the
end-to-end
usage
coupon
score
and
well.
We
get
some
particular
processing
things
that
come
up.
If
we
do
that,
so
we
need
to
treat,
for
example,
some
class.
U
options
that
are
unprotected
now
as
class
e,
and
these
are
listed
here
and
yeah.
There
was
a
bit
of
a
thing
that
could
be
more
options
in
future
co-op
options
that
also
need
to
be
yeah.
J
C
C
J
J
J
J
Let's
see,
let's
try
to
recall,
maybe
next
slide
to
see
if
we
have
a
conclusion
summary:
okay,
yeah.
So
in
summary,
we
define
proxy
operations
for
co-op
group
communication
and
we
define
two
new
core
options
to
have
that
working
correctly
and
next
steps
that
we
have
are
well
work
on
these
open
questions,
of
course,
and
also
the
idea
was
to
define
http
header
so
that
we
can
also
tackle
the
use
case
of
http
to
co-op
cross
proxies.
J
So
this
would
enable
a
hd
client
in
unicast
to
basically
talk
to
a
co-op
group
and
get
a
collection
of
responses
back
from
the
group
and
then
there's
the
need
for
reviews,
and
I
think
we
have
also
there
promised
from
an
earlier
meeting-
is
christian,
carson
and
francesca,
but
more
of
course
would
be
welcome.
Of
course,
thank
you.
C
B
On
the
on
the
topic
of
class,
due
to
class
e
option,
I
think
that
would
really
be
all
options
unless
the
proxy
needs
to
understand
them,
because
it's
it's
up
with
the
help
by
hop
option,
so
everything
that
comes
this
is
this
is
not
treating
treating
a
message
and
then
splitting
it
up
into
class.
You
can
see
this
is
really
taking
the
whole
message
unless
something
is
really
be
needs
to
be
unraveled
by
the
time
it
passes
through
this
hub
with,
which
is
the
the
help.