►
From YouTube: IETF108-CORE-20200731-1410
Description
CORE meeting session at IETF108
2020/07/31 1410
https://datatracker.ietf.org/meeting/108/proceedings/
B
A
Today,
well,
stay
in
the
shadows,
so
guys
it's
10
past
four,
I
think.
Maybe
not
everybody
has
joined
so
maybe
well.
At
the
same
time,
we
have
plenty
of
materials,
so
I
would
actually
like
to
start
on
time
just
in
case
right,
marco
we're
gonna
be
presenting
some
of
it.
So
yeah.
D
A
So,
let's
start
so
welcome
again
to
the
second
session
of
the
core
working
group,
I'm
jaime
jimenez,
and
there
is
marco
tiloca
and
we
are
your
chairs
for
the
day.
Welcome
and
and
last
day
of
the
ietf
I
I
guess
it
has
been
pretty
busy
for
everybody.
A
By
the
way,
yes,
thank
you
very
much
everybody,
so
please
at
the
know
that
the
note
well
applies.
I
see
some
comments
in
the
chat
already.
Yes,
thank
you
francesca.
The
minutes
will
be
there.
I
think
we
already
have
many
takers
for
the
day
right
francesca
and
michael.
Thank
you
both.
A
Thank
you
very
much
note
that
the
ipr
guidelines
apply
to
this
session
and
other
sessions
blue
sheets.
We
don't
have
to
worry,
because
meat
ecosystem
will
take
care
of
that
and,
as
jabber
described,
I
guess
I
can
be
the
jabra
scribe
while
marco
is
presenting
right,
marco
yeah
and
then
otherwise.
We
alternate.
C
A
So
yeah
node
well
applies
et
cetera,
et
cetera,
please
behave
well.
We
we
had
the
tuesday
session
with
already
several
of
the
items
and
clusters.
For
today
we
have
basically
two
big
clusters,
which
is
the
core
conf
cluster
and
the
group
communication
cluster,
so
group
core
conf.
You
already
know
that
we
had
the
issue.
The
working
blast
call
second,
one
that
ended
last
29th
of
july.
A
We
haven't
had
many
comments.
I
hope
that
means
that
people
have
read
it
and
are
happy
with
it,
but
for
the
to
have
closure
on
this
set
of
documents,
we
will
have
ivalo
presenting
them
now.
So
please,
I
believe
you're
around
and
you
are
yes.
A
You
can
go
ahead
any
time.
Sorry,
I
need
to
sorry
yep.
E
So
okay,
can
you
hear
me.
A
E
E
You
can
go
to
the
next
one,
okay
thanks,
so
I
will
start
with
the
changes
that
were
made
in
the
yangtze
board
draft.
E
It
had
one
new
revision,
maybe
the
most
important
change
to
that
document
was
a
slight
change
in
the
representation
of
bits
and
coding.
It's
fully
backward
compatible
with
the
previous
version,
but
now
it
is
possible
to
encode
more
efficiently
some
cases
that
we
don't
know
anyone
using,
but
it
it
is
safer.
This
way
and
the
other
change
that
might
be
interesting
for
implementers
is
that
in
the
hazybird
attack
registration
table
there
were
some
inconsistencies
with
the
text
that
words
before
it
and
values
from
the
text
or
the
correct
ones.
E
E
E
So
the
next
document
is
the
sit
draft.
After
some
discussions,
we
decided
to
rename
seeds
to
young
seeds
as
the
on
the
internet.
There
are
a
number
of
things
that
are
named
seats
and
it
could
lead
to
some
confusion.
E
E
Define
on
our
own
any
such
definitions
that
are
needed,
we
also
made
it
explicit
that
we
use
yank1.1
in
the
end
module
that
is
defined
in
the
seed
draft
and
improved
slightly.
The
descriptions
of
their
yank
modules
in
the
young
module
and
another
mission
that
was
brought
to
our
attention
was
that
we
needed
to
register
the
yank
module
namespace
in
an
ayan
register,
which
is
now
done,
and
the
last
change
that
was
requested
was
not
to
mandate
usage
of
predefined
sets
of
seat
range
sizes,
as
that
was
deemed
unusual,
and
rather
confusing.
E
So
I
believe
that
was
all
for
this
document
next
slide,
please
for
the
command
document.
We
received
feedback
that
the
usage
of
coreconf
and
comey
is
not
very
clear.
When
do
we
speak
about
korkov,
and
when
do
we
speak
about
comey?
E
E
E
So
that
is
so
the
important
changes
to
those
documents.
There
were,
of
course,
a
number
of
small
editorial
changes
as
well
next
slide,
please.
So
we
believe
we
have
processed
all
the
comments
that
we
have
received
so
now
we
would
like
to
ask
the
chairs
and
the
working
group
how,
yes,
what
do
they
think.
F
Yeah
right,
so
I'm
the
shepherd
for
these
documents,
and
I
must
admit
this
itf
has
been
a
little
bit
texting
for
me
with
two
buffs
one
dispatch
item,
several
new
working
group
drafts
and
a
couple
of
other
things.
So
I'm
a
little
little
bit
behind.
In
doing
my
shepherd
work,
the
working
glass
call
ran
out
the
day
before
yesterday.
F
So
the
next
thing
I'm
going
to
do
is:
do
my
shepherd
review
that
I'm
supposed
to
do
and
maybe
nag
a
few
people
to
actually
say
they
have
read
the
update,
because
getting
no
response
on
a
weapon
plus
call
is
not
a
good
thing,
so
that
should
actually
never
happen.
It's
a
little
bit
harder
to
avoid
that
if
it's
a
second
working
grass
coil
for
for
something
that
has
had
only
little
nits
being
fixed.
So
so
I
try
to
do
that.
F
I
don't
know
how
how
successful
that
can
be
when
it's
already
august.
But
then
I
I
send
a
shepard
report
to
the
list.
A
Thank
you
carson,
jaime
here,
just
on
the
needs
list.
I'm
noticing
that
in
the
young
library
there
is
some
junk
validation
warning,
so
you
guys
might
want
to
check
that
out
as
well
thing
is
for
the
the
normative
language
that
you
guys
use.
I
don't
know
exactly
what
the
error
is.
A
Yeah,
michael,
you
want
to
say
something
in
the
call
not
in
the
chat.
B
What
I
I
have
read
the
documents,
not
maybe
all
of
them,
but
I
have
read
the
ones
I
cared
about.
So
I
guess
I
haven't
read
the
last,
maybe
the
last
iteration
of
the
last
two
weeks
or
three
weeks
or
something.
But
I've
read
them
before.
A
Okay,
so
we
have
done
both
working
group
last
calls,
and
I
think
the
authors
agree
that
they
are
satisfied
with
the
current
state
of
the
document
and
basically
we
are
missing,
maybe
carson's
write-ups
and
a
few
other
needs.
But
after
that
I
think
we
can
just
conclude
the
working
blast,
call
and
ship
it
marco
any
thoughts
totally.
A
Yep
great
so
then,
and
thank
you
for
all
the
presentations
multiple
times
through
several
itfs.
Thank
you
so
much
for
for
the
for
spending
all
that
time.
A
And
then
well
then
carsten
do
you
have
a
because
you
mentioned
that
during
august
can
be
a
bit
tricky.
Do
you
have
a
timeline
in
mind.
F
A
Okay,
let's
say
we
catch
up
back
on
this
after
august,
is
that
around
september.
F
A
D
A
D
Yes,
thank
you.
So
an
update
to
this
working
group
document.
Congratulations
now
version
one
next
slide.
Please,
and
to
recap:
this
document
is
intended
to
obsolete
the
experimental,
rfc
73
90,
and
this
is
intended
to
be
instead
a
standard
track
document.
D
The
idea
is
also
to
update
co-op
rfc,
especially
as
to
the
endless
handling
of
the
tokens
on
the
on
the
client
side
and
observation
that
now
can
happen.
Also
targeting
a
group
of
servers,
so
what's
in
scope,
is
essentially
how
cop
can
work
over
udp
and
ip
multicast,
considering
also
the
latest
deal
functionalities
and
considering
both
a
secure
setting
with
group
score
and
an
insecure
setting
next
slide.
Please
right,
updates
in
this
latest
version
were
mostly
about
addressing
a
review.
D
We
got
from
jim
thanks
a
lot
for
that,
and
we
especially
clarified
several
details
about
group
memberships
of
nodes
in
the
group,
because
different
types
of
groups
are
involved
here
and
we
clarify
that
application
groups
and
co-op
groups
are
as
a
server
matter.
D
While
I
know
that
this
client
only,
for
instance,
doesn't
need
to
be
inside
an
application
group
as
a
server
sharing
a
resource
or
in
a
co-op
group
as
a
server
listening
to
a
multicast
address,
while
instead
it's
important
for
client-only
nodes
to
be
also
in
security
groups
related
to
an
old
issuing
github
that
we
closed
about
response
oppression.
We
don't
talk
anymore,
about
legitimate
requests.
D
It
didn't
make
that
much
sense
and
also
clarify
that
within
the
suppression,
policy
of
the
server
can
just
be
not
responding
because
there's
nothing
to
say
unless
it's
really
required
by
the
application
to
produce
a
response
anyway,
as
part
of
the
signaling
clarified,
also
about
the
the
token
reuse
on
the
client
side,
when
that
can
happens
with
more
fine-grained
timers
and
simplify
the
test.
Comparing
this
as
a
difference
with
the
base
unicast
case
next
slide,
please.
D
Also,
we
have
a
section
discussing
at
the
high
level
the
case
where
we
have
proxies
involving
the
picture,
and
we
clarified
also
the
feedback.
We
got
in
reviews
that
the
client
is
possibly
in
a
better
position
than
a
proxy,
definitely
to
judge
about
when
stopping
receiving
and
processing
responses
associated
to
a
single
group
request
and
forwarded
back
by
the
proxy.
D
Also,
it's
not
really
up
to
the
client
to
just
stand
up
and
decide
what
multicast
up
to
you
exactly
something
to
be
to
be
pre-configured
a
bit
more
detailed
clarified,
also
on
the
cancellation
of
the
group
conservation,
just
to
be
better
aligned
with
the
ideas
of
7631
and
on
the
security
part.
D
We
clarify
that
it's
essentially
in
scope
of
this
document,
the
membership
and
participation
in
a
security
group,
not
really
the
creation
and
the
management
that
actually
happens
in
other
document,
and
we
are
now
using
also
and
referring
the
the
cause
in
these
documents
and
the
relevant
registries
here
next
slide.
Please:
okay,
open
points
and
issues.
D
Now
we
have
a
few
more
still
on
github
and
the
issue
number
one
was
discussed
essentially
for
a
long
while
also
on
the
mailing
list,
and
it's
about
the
possibility
that,
following
a
multicast
request,
one
of
the
unique
house
responses
coming
back
from
the
server
can
have
a
source
port
number
different
than
the
destination
port
number
of
the
request,
and
I
went
through
the
thread
on
the
mailing
list.
Again,
it
seemed
to
me
we
were
converging
to
well
just
like
the
source
address
of
the
response.
D
D
So
in
accordance
to
this,
we
were
thinking
to
include
some
exclusive
text
in
the
draft
and
say
that,
indeed,
that
source
port
number
can
be
different
than
the
destination
port
number
of
the
request,
and
hence
the
client
must
be
able
to
handle
this
situation.
D
Then
I
think
we
can
adopt
this
change.
Okay.
Next,
please
right.
There
was
also
some
discussion
about
having
a
little
better
policy
and
set
of
criteria
for
response
suppression
on
the
server
right
now,
it's
based
on
the
response
code
to
be
consistent
across
different
different
responses,
but
we
were
thinking
actually
to
follow
what
it
has
been
doing
for
the
no
response
case
and
instead
consider
policies
for
consistent
suppression
based
on
the
response
code
class
instead,
so
we
were
planning
also
to
make
this
change
in
the
document.
D
D
D
We
wanted
actually
to
ask
for
more
opinions
on
this.
If
this
is
something
we
really
have
to
explicitly
admit,
cover
and
possibly
solve
a
bit
better
in
the
draft,
any
opinions
on
this.
G
D
Okay,
custom
also
in
java,
I
can
see
okay,
we'll
add
some
initial
text
next
slide.
Please
right.
There
are
a
few
more
open
points
other
than
the
issues
on
github
right
now.
The
client
is
list
to
support,
possibly
also
the
admin,
local
scope
and
jim
noted
in
his
review
that
that's
not
the
case
in
the
text
of
the
cooperacy
covering
multicast
traffic.
D
C
D
Okay,
you
made
us
discover
it
again
anyway.
The
7390
was
covering
that
too.
So
we
have
more
text
to
add
anyway.
Thank
you-
and
this
is
the
last
point
also,
if
I'm
not
wrong.
This
was
a
more
recent
discussion
that
was
started
by
christian
if
I'm
not
wrong
on
the
main
list
about
mapping
between
application
and
security
groups.
So
right
now,
this
is
bi-directional
with
many
too
many
in
principle
and
in
one
direction
the
mapping
is
fine,
so
many
different
application
groups
can
use
the
same
security
group.
D
That's
just
fine
on
the
other
direction.
It
can
be
delicate,
meaning
in
one
single
application.
Group
is
associated
to
multiple
security
groups
and
and
crystal
provided
two
examples
to
to
think
through
actually
and
case
a
is
pretty
good
to
consider.
Also
the
supportive
case.
One
may
want
to
have
multiple
security
groups
that
differ
in
their
configuration,
for
instance
the
algorithms
and
the
parameters
they
use.
So
in
such
a
case
to
give
more
flexibility
to
clients
with
different
capabilities.
D
Well,
the
server
would
have
to
join
all
those
groups
while
the
client
any
of
those
that
is
fine
to
it.
So
this
looks
good.
The
case
being
instead
can
look
a
bit
more
problematic,
especially
for
application,
and
there
would
be
an
attempt
to
have
one
security
group
for
each
possible
access
control,
property
and
some
voices
read
on
the
list
were
saying
well
for
something
like
that.
D
It's
totally
separate
it
should
go
on
resource
properties
and
instead
we
shouldn't
mix
access
control
to
the
medium
and
the
key
material,
with
access
control
to
the
resources.
So
out
of
this,
a
possible
proposal
can
be.
We
can
include
case
a
as
a
relevant
example
for
the
mapping,
also
in
that
direction,
and
mention
also
case
b,
as
something
not
recommended
to
do.
D
D
D
Peace
yeah,
that
was
it
we
plan
to
address
the
issues
on
top
and
point
in
the
next
version.
We
have
plan
for
some
interrupt
test.
Most
of
the
things
were
covered
already
in
the
test
of
group
score
itself,
and
we've
had
some
local
tests
with
them
without
security
and
about
observation
in
the
group,
we
want
to
do
some
more
tests
interrupting
this
part
and
also
considering
the
the
little
small
share
that
block
wise
can
also
have
in
a
multicast
context,
and
that's
it.
Thank
you.
A
Thank
you,
marco.
I
would
like
to
get
an
estimate
of
of
the
of
the
group
of
who
has
read
a
version
of
the
draft
already
other
than
I
mean
just
pl,
okay,
christian
jim
yeah.
I
forgot
to
mention
just
click
on
the
microphone
to
request
audio
and
we
will
see
your
name
there.
So
we
have
christian
jim
francesca.
A
Okay
and
who
would
be
willing
to
to
read
and
provide
a
review
or
who
is
interested
in
this
draft,
in
particular
in
some
okay
carson
yeah
go
ahead,
okay,
the
same
as
the
usual
suspects,
yes,
okay,
very
good,
so
there
you,
you
have
just
for
the
record
for
the
note
takers
that
in
a
way,
carson
jim
christian
volunteer
to
do
a
review
later
on.
I
would
like
to
see
all
the
participants
like
there
is
some
that
have
been
attending
for
quite
a
while.
A
I
mean,
if
don't
be
shy,
I
mean
any
feedback.
Any
review
is
welcome,
even
if
it
is
a
tutorial.
So
please
just
go
ahead
and
engage
okay.
So
then
we
move
to
the
next
ones.
You
have
other
slides
on
this
one
yeah.
D
Right
so
this
was
a
pretty
big
update
compared
to
the
latest
version
that
was
presented
at
the
april
virtual
meeting,
after
which
we
submitted
this
version
in
june.
Addressing
all
the
open
points
that
were
raised
in
april
plus
remaining
open
points
from
james
and
christian's
review,
and
this
version
went
in
working,
our
plus
call
that
was
concluded
ten
days
ago,
also
out
of
which
we
got
more
comments
from
jim
and
peter.
Thank
you
very
much
and
last
week
during
the
hackathon,
we
had
a
second
round
of
interrupt.
D
I
have
more
points
about
that
later.
We
plan
some
more
tests
anyway
in
the
near
future
and
during
the
hackathon.
There
was
also
a
new
proposal
from
jim
that
I
can
raise
also
today
about
the
possible
restructuring
for
partial
ivs
to
consider
next
slide.
Please.
D
Right,
the
main
update
was
restructuring
the
body
of
the
document
to
to
present
clearly
what
are
now
two
possible
modes
of
operation
of
group
score.
The
group
mode
has
always
been
around
as
the
main
one
to
use,
especially
for
request
sent
over
multicast.
It
must
be
supported,
and
this
is
about
encrypting-
the
message
with
group
sharky
material,
adding
also
a
counter
signature
for
the
sake
of
source
authentication.
D
Well,
one
goes
for
unicast
request
in
the
context
of
block
wise
transfer
or
or
echo
request
challenge,
and
in
this
case
the
message
is
encrypted,
with
pairwise
material
that
the
two
endpoints
derived
using
partially
the
grouping
material
and
their
own
asymmetrical
material,
and
the
advantage
is
that
there's,
no
signature
still
ensuring
source
authentication,
so
we
reduce
over
and
on
the
wired
and
with
signal
if
a
message
is
protected
in
one
mode
or
another,
using
a
new
flag
between
the
escort
option.
D
So
other
than
that,
that
was
again
the
the
major
thing.
It
was
a
about
an
editorial
revision
of
section
2
when
the
common
sender
and
recipient
context
are
presented
and
describe
the
procedure
to
derive
the
pairwise
keys
for
the
pairwise
mode
is
also
described.
You
can
just
use
summary
on
top
of
the
slide,
and
we
have
also
this
on
some
more
text.
Collecting
contributions
spread
a
bit
over
there
in
the
previous
version
about
how
to
handle
an
update
or
a
loss,
auto
security
context
or
the
mutable
part
of
it.
D
Next
slide,
please
yeah,
as
I
mentioned
before,
we
had
some
more
tests
last
week,
testing
our
own
rise,
implementation
and
and
and
gyms.
D
We
have
successfully
interrupts
again
of
message,
exchange
in
group
mode
and
derivation
of
the
pairwise
keys,
and
we
had
local
successful
tests
of
message
exchange
in
pairwise
mode
that
we
aim
to
also
interrupt
very
soon
next
slide.
Please.
D
Right
and
now
open
points,
mostly
as
comments
receive
from
the
working
group
last
call,
both
jim
and
peter,
raised
this
point
that,
right
now
in
the
common
security
context,
we
have
redundant
information
about
the
the
key
parameters
that
are
included
in
two
different
entries
of
the
security
context,
so
essentially
the
counter
signature.
Key
parameters
is
not
needed
as
purely
redundant
and
we
plan
to
to
remove
it
from
here.
It
has
essential
implications,
then,
on
the
storage
of
every
group
member,
any
objection
to
this
removal.
D
Okay,
then
about
the
pairwise
mode,
which
involves
the
derivation
of
the
fieldman
secret
right
now,
in
case,
eddsa
is
used.
That
means
converting
the
curve
to
the
montgomery
format
and
using
the
xt5509
function
to
compute
the
field
secret,
and
if
that
happens
well
that
curve
and
that
function
are
also
mandatory
to
implement
so
jim
was
considering
instead
was
suggesting
to
consider
a
remapping
to
the
short
viastras
curve.
Instead,
that
is
discussed
in
the
league
group,
and
we
wanted
to
clarify
what
you
are
more
precisely
suggesting.
C
D
C
C
D
Okay,
thank
you
we'll
add
some
text
along
these
lines
to
start
and
yeah.
The
next
point
was
another
request:
clarification
from
jim
in
his
working
classical
review
yeah.
We
discussed
the
possible
wraparound,
though
the
server
sequence
number,
and
he
was
asking
if
it's
about
the
senescence
number
or
the
partial
iv
instead
and
yeah,
we
believe
it's
the
center
sequence
number
that
then,
of
course,
is
used
as
partial
av.
Are
we
missing
any
detail
here
to
clarify.
G
Better
justin
answers:
why
are
we
talking
about
the
wrap
around
at
all?
We
are
incrementing
a
sequence
number
and
that's
not
an
operation
that
is
on
modular
arithmetic,
but
that's
on
an
integer
that
can
be
exhausted.
D
C
Sender,
sequence
number
is
not
what
I
was
was
thinking
I
was
using,
so
I
may
have
just
had
a
bad
point.
Okay,.
D
Please
yeah
another
question
for
jim
right
now
to
support
observation.
Also
in
case
the
key
material
is
changed
in
the
group.
We
are
already
saying
that
the
client
and
the
server
store
the
sender
id
of
the
client
when
the
observation
was
started.
So
the
sender
id
included
in
the
original
observation
request.
D
That's
fine
and
that's
in
fact,
going
to
be
the
value
included
in
the
external
id
used
to
protect
the
notifications,
so
all
of
them,
even
after
a
group
wrecking,
will
match
the
original
observation
request.
So
far,
so
good
jim
was
wondering
if
we
ever
really
consider
storing
also
the
caddy
context
of
that
original
observation
request.
D
Well,
we
think
we
well,
we
don't
store
it
right
now.
We
we
think
we
don't
really
need
to
because
at
least
for
that
same
reason
it's
never
part
of
the
external
ed.
C
D
D
B
You
go
so
I
I
believe
that
so
we
discussed
in
in
cosi,
this
rfc
8152
counter
signature
question
and
I
believe
it
was
claimed
that
it's
being
used
in
in
group
com
and
but
it's
being
used
in
a
way
that
has
no
preference,
has
no
impact
changes
in
how
we
do
it
has
no
impact
on
how
it's
used
here.
D
I
was
in
cozy
and
to
my
understanding
it
doesn't
impact
operations
happening
here,
because
we
are
counter-assigning
an
encrypt
zero
object,
so
you
should
be
okay,
but
from
an
editorial
point
of
view,
understood
if
we
have
to
point
at
a
document
describe
a
correct
way
to
counter
sign.
B
D
Now
we
are
already
pointing
to
the
base
struct
document
yeah,
just
to
avoid
referring
the
obsoleted
one,
but
so,
as
I
understood
that
when
when
this
document
was
raised
up
was
mostly,
for
the
sake
of
editorial
consistency,
to
point
to
the
right
to
the
right
thing.
Otherwise,
the
implementation
shouldn't
be
affected.
D
D
Okay,
then
jim
also
raised
the
proposal
to
to
change
her
mind
about
the
resetting
to
zero.
The
sender
sequence
number
in
case
the
key
material
is
changed
in
the
group.
So
right
now
it's
it's
not
reset.
We
just
let
it
grow
unless
the
application
decides
to
do
differently.
D
The
gene
claimed
that
well
having
it
reset
in
case.
The
group
working
happens,
make
life
easier
for
group
members
to
detect
the
wrecking
happening
in
case,
for
instance,
they
lost
suffrage
messages,
christian.
G
Wouldn't
that
mean
that
there
could
be
two
requests
that
have
the
same
kid
and
the
same
external
aad
that
would
match
to
an
that.
A
response
could
be
matched
to.
I
think
this
would
endanger
request
response,
binding.
G
In
the
master
secret,
but
we
already
just
just
in
the
point
above
we
said
that
an
observation
can
span
several
can
cancel
rivalry
keying.
So
then,
when
you
get
the
response
to
the
observation,
this
response
could
be
the
enco.
This
could
be
a
response
to
a
request
made
with
any
sequence
number
and
out
of
all
those
that
were
generated
with
that
key.
D
C
I'm
trying
to
figure
out
what
would
if,
if
I
understand
what
christian
just
said,
part
of
the
reason
to
look
at
this
is
it
makes
the
detection
of
exactly
what
you
mean
by
rolling
over
the
sequence
number,
because
it's
like
at
this
point.
Would
you
say
that
the
sequence,
the
center
sequence
number
rolls
over
when
it
gets
to
a
maximum
value
or
when
it
gets
back
to
the
starting
value.
G
Go
ahead,
I
don't
think
that
this
is
about
wrapping
the
sequence
numbers.
It's
just
about
the
sequence
number
going
back
to
zero
and
if
the
client
sends
an
observer
request
with
with
what
happens
to
be
the
same
sequence
number
in
both
before
and
after
the
re-keying
and
has
a
response
going
on,
then
a
response
from
the
one
observation
could
be
just
by
switching
over
the
token
mapped
to
that
other
observation,
and
they
share
the
same
data
that
is
authenticated
in
the
external
aed.
C
C
D
You
don't,
after
an
exhaustion,
the
idea
was
for
the
node
to
go
to
go
to
the
group
manager
and
get
a
new
sender
id.
C
C
C
G
D
Okay,
we
can
move
on.
Perhaps
we
were
already
at
the
next
yeah
here
now.
This
was
the
the
last
point
about
the
proposal
we
got
for
from
jim
to
consider
during
the
hackathon
right
now
on
every
node
we
have
a
single
sender
sequence
number
space,
so
a
fresh
value
is
used
both
in
group
mode
and
in
pairwise
mode
with
no
distinction.
So
the
proposal
from
dream
was
to
consider
two
spaces
in
state,
and
if
we
do
that
this
will
be
the
new
situation
on
every
node.
D
We
will
have
a
sender
sequence
number
to
use
for
the
group
mode
and
then
for
each
associated
recipient,
a
pairwise
sender,
sequence
number
for
that
recipient
and
then
on
each
associated
client
of
a
server.
You
have
the
group
replay
window
and
the
pairwise
replay
window.
So
what
are
the
pros
and
cons
on
this
next
slide?
Please!
D
Well!
The
pros
are
that
the
center
sequence
never
be
exhausted
much
less
frequently,
and
I
understood
also
for
gene.
They
will
have
some
advantage
in
terms
of
code,
reusing
from
a
bazel
score
footprint
and
scones
early
to
imagine
well
more
storage
to
keep
this
extras
in
the
sequence,
numbers
and
replay
windows
and
after
some
analysis
we
believe
this
can
turn
out
into.
D
Moreover,
on
the
wire
for
more
times
when
it
is
required
for
the
server
to
to
consume
a
fresh
partial
id
of
its
own
and
include
it
in
a
response.
So
we
made
some
analysis
on
two
points.
D
The
the
first
one
is
this:
having
fresh
partially
is
consumed
by
the
servering
responses,
and-
and
I
think
this
is
the
case
where
the
response
is
protected
in
a
different
mode,
at
the
request
and
then
issue
number
two
now
we
have
two
spaces
to
synchronize
and-
and
this
would
mean
some
adaptation
to
the
echo
way
to
do
that-
that
would
describe
in
appendix
e3
next
slide.
Please.
D
This
is
an
example
of
the
first
issue,
no
need
to
go
into
extreme
details
here,
but
at
least
building
this
example.
If
the
first
request
is
sent
in
group
mode
and
the
response
is
protected
in
a
different
mode,
so
the
pairwise
mode
in
case
we
don't
blue
like
like,
I
imagine
that
that
the
server
consume
a
fresh
partial
id,
but
just
goes
for
the
same
one
of
the
client.
Then
we
are
opening
up
for
a
problem
in
in
the
right
following
exchange.
D
Even
that
request
message,
number
three
now
in
pairwise
mode
accidentally
and
by
bad
luck.
The
partially
used
by
the
client
has
exactly
the
same
value
of
the
red
group,
partially
the
above.
D
That
will
end
up
for
for
the
server
later
on,
to
use
the
same
cipher
nouns
with
the
same
key,
and
we
don't
want
that,
of
course.
So
to
avoid
this
by
construction
in
in
message
two
already:
the
server
should
consume
a
partial
iv,
and
that
would
mean,
moreover,
on
the
wire.
Then
it
would
be
possible
otherwise
in
pairwise
mode
next
slide.
Please.
D
Yeah
on
the
other
issue,
as
I
mentioned,
this
would
require
some
adaptation
for
the
echo
challenge
way
to
synchronize
the
now
two
spaces
between
server
and
client,
and
if
the
first
request
is
in
group
mode
and
then
the
response
with
the
option
is
in
pairwise
mode.
D
Well,
the
third
message:
widget
option
has
to
be
in
pairwise
mode.
It
includes
a
pairwise
partial
iv
and
that
will
synchronize
the
pairwise
space,
but
the
group
space
is
not
synchronized
yet
so
that
requires
for
the
clients
group
piv
to
also
go
into
this
request,
and
the
question
becomes
where
and
well
if
you
explore
the
possible
option
and
things
they
require
in
turn,
it
can
get
even
more
complicated.
D
So
we
wanted
to
raise
this
up,
of
course,
and
and
we
think
we
can
even
have
a
separate
discussion
to
get
more
opinion
for
from
implementers,
especially.
H
D
Understand
that
this
overall
pays
off
are
there
early
opinions
already
about
this?
This
proposal.
F
Yeah
that
may
be
a
totally
stupid
question
when
I'm
sitting
in
the
group-
and
I'm
asking
has
anybody
had
a
drinking
problem
here,
and
I
want
to
get
confidential
responses
to
that.
The
fact
that
some,
some
sequence
numbers
move,
maybe
disclosing
something,
and
I'm
just
wondering
whether
that
that's
actually
a
problem
here
or
can
be
ignored.
A
I
Okay!
So
just
going
back
to
jaime's
question
here
about
issues
I
think
yeah,
we
talked
a
little
bit
about
issue
two
previously
and
I'm
still
that's
something
that
we
probably
can
solve,
although
it's
not
very
beautiful
with
the
the
transport
of
of
the
group
piv,
but
the
issue
one,
I
hadn't
thought
so
much
about
previously.
I
So
the
issue
with
that's
something
I
mean
if
there
is
this
leading
to
more
problems
about
related
to
nonce
reuse,
I
think
we
should
be
careful
and
also
remember
that
the
purpose
of
the
pairwise
is
to
reduce
overhead.
So
if
we
now
add
more
overhead
because
of
in
the
pairwise
mode,
that's
that's
somehow
taking
a
step
back
so
yeah.
So
that's
my
concern
about
separate
ssn
spaces.
G
Christine,
I
think
that
the
the
trouble
that
come
up
with
those
two
issues
show
that
the
at
least
for
the
purpose
of
code
reviews
and
saving
some
basically
one
bit
of
space
per
message.
The
the
separate
ssns
are
nothing
that
we
should
follow
any
further
on.
G
We
might
want
to
look
into
carson's
point,
but
I
think
that
this
is
too.
The
effect
is
too
minor
to
warrant
all
those
trouble
that
we
would
get
into
as.
F
D
D
D
Okay,
I
think
the
next
one
is
the
last
slide
yeah
addressing
as
much
of
these
points
as
possible
for
next
version.
More
discussion
of
this
last
point
more
tests
with
focus
on
the
pairwise
mode.
A
Pretty
good
that
was
a
very
productive
discussion,
I'm
thinking
so
we
have
about
50
minutes.
Then
four
drafts
10
10
10.
So
we
can
no.
We
have
40
minutes
actually,
okay,
but
then
I
would
like
to
save
the
local
next
time
from
tuesday
yeah.
That's
that's
a
good
point
too
yeah
so,
but
I
would
just
like
to
know
from
the
group
the
same
question
as
before.
So
who
has
read
the
version
of
this
draft.
A
Nope,
okay,
okay
and
who
will
be
reading
a
version
of
this
draft
in
the
coming.
Let's
say
coming
month
few
weeks,
let's
say
a
couple
of
months,
because
there
is
vacation
all
right,
okay,
very
good,
so
great,
okay!
Well,
I
think
we
are
making
progress.
There
is
a
lot
of
new
things,
lots
of
discussion,
that's
a
good
sign.
A
So
then
we
can
move
on
because
yeah
we
are
getting
a
bit
tight
on
time.
There
were
some
interesting.
I
don't
know
not
on
this
one.
There
were
no
other
slides,
sorry,
never
mind.
I
thought
you
had
some
implementation.
A
Yeah
so
then
we
moved
to
christian
and
to
raw
score
discovery
christian
you're,
requesting
to
share
screening.
I
guess
you
just
met
the
microphone
right.
All
right!
No,
I
was
requesting.
I
wasn't
meaning
to
share
video.
G
All
right
there
you
go
okay,
so
this
is
basically
continuing
on
the
on
the
topic
of
group
communication.
Next
slide,
please,
and
in
the
interest
of
time
I
will
not
start
with
when
marco
and
I
were
having
lunch
back
in
london,
but
just
summarize
the
the
the
what
this
is
about.
So
a
device
joins
a
device
is
joins.
The
network
is
configured
to
join
a
particular
group,
but
doesn't
know
a
lot
about
that
group.
G
Maybe
the
group
manager
hasn't
even
arrived
yet,
and
this
whole
document
is
about
how
web
links
typically
stored
in
a
resource
directory
and
can
be
used
for
the
device
to
find
the
join
resource
and
possibly
even
the
name
of
the
security
group
when
it
only
has
the
name
of
the
application
group.
I
might
also
use
this
to
find
the
multicast
address.
This
is
joining
on
next
slide,
please.
G
So
what
happened
since
the
since
the
last
since
this
was
last
presented,
we've
received
a
lot
of
comments
from
jim
thanks
for
that
we've
aligned
terminology
with
what
is
now
in
group.
Combis.
We've
already
talked
here
about
the
topic
of
what
is
an
application
group
and
what
is
the
security
group
and
how
they
can
interact
so
wow
this
this
is
part
of
this
discussion
is
coming
from
here,
we've
run
into
a
slight
trouble,
with
the
difference
between
the
serializations
we're
using.
G
So
the
cosine
registry
is
strongly
typed,
meaning
that
in
theory,
someone
could
register
an
algorithm
with
a
name
string
out
of
three
characters:
minus
digit,
one
digit,
zero
link
format
doesn't
really
like
this.
Now
we're
clarifying
it
next
slide.
Please,
and
by
the
way,
the
clarifications
you
just
can't
use
such
such
algorithms.
Here
we
have
a
quite
extensive
example
of
how
this
could
be
used
in
application.
That
is
oriented.
Well,
that's
modeled,
by
a
bacnet
application
brought
in
through
peter
from
from
the
fairhead
organization.
G
This
used
to
have
some
things
in
there
that
are
common
in
those
kinds
of
setups,
but
not
really
documented
here
and
not
relevant
here
either,
so
those
were
removed
from
here
yeah.
The
next
point
is
basically
all
the
things
that
we've
talked
about
so
next
slide.
Please
we
now
next
slide.
Please
thanks!
We
now
have
all
our
examples
in
coral,
as
well
as
the
examples
from
the
fair
hair
part
in
a
separate
appendix
because
otherwise
the
text
would
just
be
too
too
hard
to
read.
G
If
there's
one
example
in
this
way,
and
one
example
in
that
way,
so
this
should
now
be
be
aligned
with
future
use
of
resource
of
a
curl
based
resource
directory.
Even
though
the
it's,
it's
not
fully
clear
how
how
this
will
look
in
all
detail
on
the
lookup
site.
This
is
making
a
few
assumptions,
but
at
least
there
is
syntax
there
that
explains
how
this
maps
to
to
crawl
next
slide.
Please
on
the
open
issue,
side
and
much
of
them
is
also
coming
from
from
jim's
review.
G
There's
the
question
of:
where
does
the
information
about
the
authorization
server
relevant
for
for
joining
resource
come
from
right?
Now
we
see
that
the
group
manager
is
putting
it
in
there
and
I
still
think
that's
the
way
it
should
with
the
place
it
should
come
from,
because
the
group
manager
in
the
end
needs
to
know
how
which
as
it's
talking
to,
but
if
there's
any
more
feedback
on
that
I'd
appreciate
it.
G
One
way
for
this
to
come
into
play
is
by
the
way
next
slide,
please
the
same
as
for
here.
So
another
piece
of
information
that
whose
origin
is
a
bit
unclear
is
the
application
groups.
Now
the
the
group
manager
doesn't
deal
in
application
groups
itself,
but
it
somewhere.
Somehow
we
need
to
get
that
information
into
the
resource
directory,
and
the
way
it
looks
like
right
now
is
that
the
group
manager
will
be
provisioned
with
that
information
at
the
time
the
group
is
created
by
the
actual
administrator
for
all
for
the
group.
G
So
that's
the
way
this
information
is
moving
into
the
group
manager
and
from
there
can
be
propagated
into
the
resource
directory
next
slide.
Please
another
thing
that
another
point
where
we
could
use
some
input
is
the
is
the
actual
way
we
are
advertising
those
resources.
Right
now
we
say
that
this
is
advertised
as
a
membership
resource
in
form
of
a
resource
type.
G
Now,
there's
this
long,
lasting
and
always
resurfacing
discussion
of
what
is
what
is?
What
is
a
resource
type?
What
is
an
interface,
but
I
think
that
we
can
bypass.
We
can
put
this
on
the
shelf
for
the
moment,
because
the
because
the
bcp
190
discussion
around
the
join
the
group
joining
doc.
G
The
ace
group
communication-
sorry
about
the
ace
profile
for
groups,
will
result
in
something
that
we
can
put
in
there
anyway,
because
the
hard
coded
paths
are
making
place
making
way
for
for
resource
discovery,
as
in
the
similar
way
that
we
are
doing
it
in
resource
directory
next
slide
piece
now,
so
we
have
those
open
points.
G
I
think
the
things
that
where,
in
the
reviews
we
got
so
far
that
are
not
in
the
list
of
open
points
are
addressed,
and
we
would
like
to
have
a
bit
more
feedback
on
on
those
above
things
and
otherwise
wait
for
other
documents
and
align
with
other
documents.
That
is,
group
administration,
as
well
as
the
the
upcoming
updates
to
ace
key
group,
comma
and
getting
another
pair
of
eyes
would
be
on.
This
document
would
be
quite
nice,
especially
in
the
light
of
possible
further
interest
of
the
working
group
next
slide.
G
So
that's
it
from
me
about
this
is
questions.
A
I
haven't
read
this
draft,
yet
I'm
thinking
the
new
link,
attributes
that
are
defined
is
this
something
that
we
should.
Is
there
that's
right,
so
we
have
been
working
on
this
document
that
we
should
gather
all
of
the
new
parameters
that
have
been
registered,
and
this
one
has
also
what
like
another
dozen
of
parameters
right.
B
A
Maybe
we
should,
at
least
on
that
side
note
we
should
sync
in
order
to
have
them
have
them
together
in
the
same
dock,.
G
G
But
of
course,
in
the
end,
if
they
are
used
both
in
link
forward
and
in
coral,
then
there
will
need
to
be
some
authoritative
place
where
it's
described,
how
how
they
are
transferred
transformed
and
that
could
just
as
well
be
that
registering
document
that
is
coming
up.
So.
A
Which
I
mean
actually
I'm
not
sure
if
it
is
coming
up.
I
don't
remember
anymore,
who
was
working
on
that
at
the
moment.
If
anyone
we
could,
of
course,
just
use
coral
only,
but
I
don't
know
if
that's.
A
To
support
this
all
right,
yeah,
so
yeah,
but
that's.
G
Maybe
maybe,
let's
bring
this
up
briefly
when
later
on,
when
we
know
where
how
coral
is
advancing,
because
I
think
this
is
later
on
this
late
later
today,.
A
No,
no.
No
quarrel
was
last
tuesday
unless
it's
inaudible,
I'm
very
mistaken,
yeah.
Sorry,
then
yeah
I
mean
coral
was
slotted
last
tuesday,
but
there
was
no
new
updates.
Okay
clouds,
you
can
chip
in.
If
you
are
in
the
call
and
mention
you
know,
plans
ideas
on
on
this
topic.
If
you,
if
you
are
there.
A
Otherwise,
yeah,
I
agree
with
you
that
we
can
see
later
on
yes
and
another
question.
I
have
sorry
for
monopolizing
the
questions
you
mentioned:
fair,
hair
and
bacnet,
and
for
the
examples
right
all
right,
so
it
could
be
great
to
I
don't
know
if
this
is
something
the
core
should
do
core
working
group,
but
if
there
is
any
special
I
don't
know.
Where
was
the
slide?
Yeah
one
photo
yeah
yeah
there,
for
instance.
A
G
Yeah,
I
think,
there's
been
a
few
changes
in
in
how
things
are
going
over
there.
So
I
don't
know
whether
there's
anything
that
can
actually
be
interoperated
on
anymore
peter
could
probably
save
bit
more,
but
I
just
him
the
courser
all
right.
A
A
Yeah,
well,
I
think
I
think
maybe
it
needs
a
bit
more
work
right,
yeah.
So
then
we
are,
you
have
some
backup
you
you
want
to
use
them.
I
mean
yeah.
G
G
The
motivating
case
for
this
was
where
francesca's
original
thoughts
about
how
pubs
up
could
be
done
in
a
more
could
be
done
with,
in
a
more
say,
in
better
alignment
with
resources
with
a
resource
with
your
eyes
as
it
I
defies
in
that
we
wouldn't
so
rely
so
much
on
putting
on
putting
data
but
could
actually
observe
them.
G
And,
of
course,
observing
data
to
a
multicast
address
is
something
that
original
co-op
does
not
allow,
because
multicast
is
only
used
for
requesting
of
responses,
and
this
document
explores
the
way
how
to
change
this
next
slide.
G
Please
so
we
defined
in
the
first
place
that
response
can
be
sent
to
multicast
address
and
because
the
token
assignment
there
is
a
bit
trickier,
we
say
that
the
token
space
between
a
particular
server
and
the
multicast
group
as
a
client
belong
belongs
to
the
group,
but,
as
the
group
cannot
do
anything
on
its
own,
it
entrusts
the
server
with
the
token
management,
and
thus
the
server
gets
to
pick
a
particular
token
for
a
particular
observation.
G
G
So
what
happens
is
that
we
introduce
a
phantom
request
which
is
created
by
the
server
at
the
time.
The
observation
is
started
now,
whether
that
happens
at
dawn
of
time,
which
is
around
1970
or
whether
that
happens
when
the
server
decides
that
there
are
too
many
individual
observations
that
that
it
would
prefer
to
switch
to
multicast
is
up
to
the
server,
but
at
some
point
in
time
the
server
says.
This
is
a
request
that
we
are
that
I
imagine
was
made.
G
So
that's
why
it's
named
phantom
requested
never
actually
hits
the
wire,
but
the
server
creates
the
request
kind
of
internally
loops
it
back
to
itself
and
there
it
has
all
the
freedom
to
send
it
from
the
multicast
address,
and
it
will
also
pick
a
toke
pic
sender,
sequence,
number
and,
and
the
sender
id
for
this
request.
G
When
now
the
unicast
requests
come
in
from
a
client
that
wants
to
join
this
group
or
doesn't
even
know
he
wants
to
join
the
group
but
wants
to
observe
that
resource
the
server
sends
back
an
error
response
because
it
does
not
want
to
handle
all
those
individual
observations,
but
it
says
no,
you
can't
observe
this,
but
instead
there
is
an
observation-
and
this
is
the
very
the
very
data
item
that
the
server
created
in
the
first
place.
It
hands
it
in
an
encapsulated
form
to
the
client.
G
This
data
item
includes
all
the
information
about
the
group,
so
the
client
can
join
this
group
and
then
the
server
can
later
on
send
all
the
notifications
back
to
the
group
and
the
clients
in
the
group
know
what
to
expect
next
slide.
Please
now,
in
the
process
of
refining
that
whole
thing,
we've
recently
redefined
the
parameters,
so
we
used
to
have
the
co-op
message
completely
dissected
into
all
its
components:
payload
and
sequence,
and
observation
number
and
content
format,
and
so
on
and
now
we've
chosen
an
expression.
G
G
The
last
notification
is
a
co-op
message
just
protected
the
same
way,
and
this
allows
the
client
to
have
an
immediate
representation
of
what
it
is
observing
now
without
waiting
for
the
next
multicast
to
be
sent
out,
and
we
do
consider
making
this
optional
so
feedback
from
on
the
topic
of
whether
you
think
that
it
makes
sense
for
the
server
to
always
have
a
last
representation
versus
the
client
having
to
wait
for
the
next
multicast
notification
would
be
much
appreciated.
G
Another
thing
we
recently
introduced
is
the
counting
of
clients,
so
the
the
responses
to
multicast
are
all
unconfirmable,
because
otherwise
we
would
quickly
overload
the
network
and
run
into
all
the
kinds
of
trouble.
So
the
document
now
includes
a
way
for
the
server
to
express
how
much
feedback
it
would
like
to
get.
G
And
then
the
document
says
that
the
clients,
if
they
receive
when
they
receive
this
option
and
a
random
event,
indicates
that
they
are
one
of
those
selected
clients.
Then
they
can
inform
the
server
that
they
are
still
interested,
and
thus
the
server
can
maintain
an
estimate
of
the
number
of
observers.
G
There
is
now
code
that
pseudo
code
that
describes
how
this
is
handled
on
the
server
side
and
it's
rather
trivial.
On
the
client
side,
we
do
consider
changing
the
precise
expression
of
this
from
giving
a
divider
back
to
the
client
to
giving
basically
the
binary
logarithm
of
a
divider
to
make
calculation
easier
at
the
cost
of
losing
some
granularity
for
the
server
to
to
configure
the
amount
of
response
that
you
expect,
but
I
think
either
will
work,
and
this
should
be
kind
of
good
enough.
For
the
current
document
state
next
slide,
please.
G
What
we've
also
elaborated
on
now
is
how
the
client
could
obtain
this
phantom
request
in
alternative
ways.
So
this
is
now
all
expressed
in
corolla
and
could
be,
for
example,
used
in
a
pub
sub
context
where
the
pubs
are
broker,
keeps
a
copy
of
the
phantom
request
and
all
the
addresses
and
thus
helps
the
client
to
basically
join
the
group
without
ever
bothering
the
original
server
two
more
things
that
we
changed
is
that
we
now
have
updated
considerations
for
for
congestion.
D
G
D
G
G
How
would
this
even
work,
which
is
relevant,
especially
when
there
is
cross-protocol
proxies
involved,
because
the
the
the
original
client
might
not
even
be
able
to
talk
co-op
over
udp,
but
some
some
proxy
in
between
would
be
able
to
leverage
the
optimizations
that
can
come
from
this,
and
also
the
cachable
oscar
document
that
I
will
talk
about
later,
provides
some
generalization
of
this.
So
we,
I
think
that
we
can
align
terminology
between
those
to
the
point
where
this
is
you.
G
This
is
not
introducing
everything
that
it
needs
on
its
own,
but
can
build
on
the
concept
of
a
consensus
request,
rather
than
introducing
phantom
request
right
out
of
it
and
as
before.
If
someone
could
look
at
this
with
another
pair
of
eyes,
that
would
be
great.
Thank
you.
I
I
just
like
to
say
that
I
think
this
is
a
fantastic
piece
of
work.
I
hope
it's
not
too
complicated.
I
haven't
really
looked
at
it,
yet
I
I
just
really
like
how
you
managed
to
to
solve
the
problems
that
we
we
didn't
manage
to
do
when
when
people
asked
us,
how
do
you
do?
How
do
you
do
caching,
and
how
do
you
do
proxying
with
oscar,
so
yeah,
I'm
I'm
a
big
fan.
I
haven't
read
it
yet
so
I'll
get
back
to
you
when
I
have
thank
you.
A
Can
you
hear
me
now?
Yes:
well,
there
were
some
strange
audio
issues
on
my
side.
Sorry,
for
that
I
was
talking
and
then
I
realized
nobody
was
listening.
Sorry
francesca
for
jumping
over.
I
just
wanted
to
very
briefly
mention
the
pops
up
because
of
is
related
to
this
draft.
So
we,
the
authors
of
the
pops
up
draft
and
klaus
also.
We
is
also
an
author
now
because
he
did
the
pop
sub
version
with
that
uses
coral.
So
we
are
trying
to
merge
the
two
drafts.
A
G
I
think
the
the
pub
sub
could
especially
profit
from
this
when
describing,
when
kind
of
competing
with
the
other
pubs
up
protocol,
in
the
sense
that
this
could
be
used
to
completely
spare
the
actual
broker.
Any
interaction
at
all
with
the
clients.
A
G
Francesco
was
just
trying
to
express
carson's
written
expression
of
support.
A
Okay,
so
does
it
mean
that
we
have
volunteers
to
read
the
draft
and
provide
feedback
formally.
A
D
A
D
No
10
will
be
enough.
Hi,
marco,
here
this
is
a
recent
new
work.
We
started
with
esco
to
support
proxies
in
your
communication
next
slide.
Please.
D
So
we
have
the
group
confis
document
that
we
presented
earlier
today
that
focuses
on
your
communication
with
co-op
over
ip
multicast,
and
it
has
a
big
part
already
describing
at
the
high
level
the
case
where
proxies
are
used
and
highlighting
at
a
high
level,
some
big
things
to
be
aware
of
and
and
possible
issues
even
upper
areas
to
be
addressed
in
detail
and
among
them.
Well,
the
client
is
going
to
receive
multiple
responses
forwarded
back
by
the
proxy
to
what
is
technically
unicast
request
sent
to
the
process.
D
The
client
would
be
in
a
position
not
to
distinguish
the
different
origin
servers
producing
those
responses,
and
the
proxy
may
have
no
idea
when
to
stop
getting
these
responses
to
be
forwarded
back
to
the
client
and
ingroup
completes
already
well,
two
hello
strategies
are
drawn
by
the
way
the
proxy
either
forwards
back
individual
responses
to
the
client
or
aggregates
next
slide.
Please.
D
And
yeah
here
we
take
the
first
approach
and
describe
a
complete
solution
in
a
sense
that
describes
how
things
can
work
with
that
first
approach
and
we
believe
addressing
all
the
related
issues
that
are
documented
in
group
combis,
so
practically
with
a
final
signaling
protocol
protocol
between
the
client
and
the
proxy
based
on
two
new
cop
options.
They
would
fulfill
those
requirements
and
again
we
take
the
approach
of
individual
responses
forwarded
back
to
the
client.
D
The
proxy
has
to
be
aware
of
this
and
properly
configured,
of
course,
and
this
version
one
is
the
result
of
processing
comments.
We
got
from
christian's
review
thanks
a
lot
about
that,
and
especially
about
the
properties
and
the
processing
of
the
two
options
and
a
very
nice
suggestion
that
we
call
nested
score
now
in
an
appendix
that
can
be
very
useful
in
case
we
have
all
score
between
client
and
proxy
more
on
that
later
next
slide.
Please.
D
So
the
overall
rational
is
that
when
the
client
sends
a
request
to
the
proxy
to
be
forwarded
to
a
group
of
servers,
essentially
with
a
new
first
option,
the
client
will
indicate
that
it's
fine
with
all
this
and
it
will
give
the
proxy
an
indication
for
how
long
this
back
forwarding
of
responses
should
go
on.
Well.
D
Instead,
in
each
response
rewarded
back
to
the
client
by
the
proxy,
there
will
be
information
included
by
the
proxy
that
are
essentially
the
addressing
information
of
the
server
so
that
the
client
can
learn
about
the
servers
and
distinguish
the
different
responses.
And
of
course,
if
security
has
to
be
ensured,
we
can
have
it
end-to-end
between
client
and
servers
using
group
score
next
slide.
Please.
D
So
this
is
the
first
new
option:
multicast
signaling,
intended
only
for
the
unicast
request
sent
by
the
client
of
the
proxy
to
be
forwarded
to
the
group
of
server,
and
the
value
gives
a
time
indication
to
the
proxy.
So
for
how
long
it
should
get
responses
matching.
With
that
request
to
be
forwarded
back
to
the
client
and
taking
chris
a
suggestion
in
this
new
version,
the
proxy
will
remove
the
option
from
the
request
before
forwarding
it
to
the
servers
next
slide.
D
Please
and
the
second
option
response
forwarding
this
is
intended
only
for
the
responses
forwarded
back
to
the
client,
the
production.
The
option
includes
addressing
information
of
the
origin,
server,
producing
the
response
and
based
on
the
recent
review.
Also
now
it's
the
proxy
adding
the
option
to
the
response
before
forwarding
it
to
the
client
next
slide,
please
so
an
overview
of
the
workflow.
D
The
client
prepares
the
request
it's
intended
as
unicasted
the
proxy,
but
it
has
a
group
uri
indicating
where
to
forward
over
multicast
the
request
to
and
the
client
prepares
the
new
first
option
to
be
included
in
the
request
to
give
the
time
indication
to
the
proxy
and
this
time
indication
takes
into
account
well
token,
reuse
time,
local
to
the
client
plus
processing
at
the
proxy
and
round
three
times
involved
on
the
way
the
option
is
included.
The
request
is
sent
next
slide.
Please.
D
Yeah,
the
proxy
has
to
identify
the
client,
presumably
through
some
kind
of
secure
session,
to
verify
it's
a
whitelist
client
and
the
proxy
extracts.
That
option
is
aware
of
a
time
limit
and
for
how
long
this
should
go
on.
It
removes
the
option
and
it
forwards
the
request
to
the
servers
over
ip
multicast.
So
as
long
as
the
timeout
doesn't
expire,
the
proxy
is
available
to
accept
responses
to
forward
back
and
well.
Observation
is
an
exception
here.
If
an
observation
is
actually
ongoing,
the
matching
and
forwarding
back
will
go
on.
Of
course.
D
And
after
the
changes
in
this
latest
version,
the
nice
thing
is
that
the
server
doesn't
really
have
to
do
anything
special
here,
just
processes,
the
request
and
responds
to
the
proxy
and
the
proxy
now
produces.
The
new
second
option
includes
it
in
the
response
indicating
the
the
uri
of
the
server
essentially
next
slide.
Please.
D
And
finally,
the
proxy
sends
back
the
the
response
to
the
client
again
subject
to
that
possible
local
timeout.
The
client
gets
the
response,
finds
the
option
there
and
can
learn
what
the
origin
server
is
also
to
possibly
contact
it
individually
later
on
directly
or
through
the
proxy
again,
when,
eventually
the
timeout
client
side
expires
well,
that
stops
all
together
also
on
the
client
next
slide.
Please.
D
And
find
out
about
this,
I
said
already,
as
we
said
in
group,
convince
the
proxy
has
to
recognize
the
client
as
well,
at
least
so.
It
has
to
identify
it,
and
that
has
to
involve
some
kind
of
security
session
and
at
the
beginning
we
immediately
talk
of
well
a
detailed
ascension
client
to
proxy,
which
is
a
pt.
D
You
have
also
group
of
score
involved
between
client
and
servers,
so
the
suggestion
that
came
from
euron
was
that
well,
if
group
of
score
is
used,
the
proxy
can
check
the
the
counter
signature
in
the
request
and
identify
the
client
correct.
That
requires,
of
course,
the
proxy
to
have
the
set
of
public
keys
of
the
clients
in
this
group
and
to
keep
this
set
up
to
date.
D
We
should
mean
some
kind
of
synchronization
with
the
group
manager
for
the
score
group,
yet
another
alternative
can
be
having
all
score,
also
for
the
sake
of
code
reusage
between
client
and
and
proxy.
But
then
how
can
things
work
if
we
have,
at
the
same
time,
group
of
score
between
client
and
servers
and
all
score
between
client
and
proxy,
and
christian
kind
of
saw
this
in
his
review
as
a
possible
use
case
enabling
what
we
are
calling
now
nested
score
now
in
appendix
a
and
in
principle,
you
work
this
way.
D
The
client
first
of
all
protects
the
the
request
to
send
to
the
proxy
for
forwarding
with
group
score
so
using
the
context
share
with
the
servers
and
after
that,
the
resulting
protected
message
would
be
further
protected
with
the
second
layer,
so
with
oscor,
using
the
context
between
client
and
proxy.
D
It's
documented
in
the
appendix,
but
in
principle
it's
about
running
all
score
with
the
difference
that
some
class,
u
options,
are
processed
as
class
e
options,
and
this
include
also
the
oscar
option.
That
was
the
result
of
the
group
of
core
processing.
Well,
the
process
is
just
reversed
on
the
way
back
when
responses
come.
So
you
appreciate
feedback,
especially
on
this
possible
new
thing
that
maybe
has
even
broader
applicability.
D
Next
slide.
Please
so
yeah
signaling
protocol
between
client
and
proxy
to
have
proxies
working,
supporting
group
communication
based
on
the
approach
of
individual
responses
forwarded
back
to
the
client
and
as
next
test.
We
want
to
cover
the
more
general
case
of
a
chain
of
proxies,
as
and
as
jim
suggested,
in
some
comments
in
group
convicts.
Actually,
we
would
like
to
investigate
about
the
definition
of
http
headers
as
equivalent
of
the
two
new
crop
options
for
handling
cross
proxies
involved.
Here
we
much
appreciated
more
comments
and
reviews.
D
A
A
Okay,
so,
in
the
sake
of
for
the
sake
of
brevity,
actually
we
have
the
minute.
So
christian,
please
go
ahead.
Thank
you.
I
almost
forgot
that
yeah.
G
Hello
again,
I'd
like
to
tell
you
about
another
time,
marco-
and
I
had
lunch
this
time
in
montreal
next
slide.
Please
so
thing
is
oscore
by
itself
is
not
really
nice
towards
caches,
because
everything
is
not
cachable.
This
came
up
in
the
context
of
multicast
notifications.
G
This
was
something
that
was
in
the
original
back
then,
was
co-op
drafts
as
us
corn
to
to
some
extent,
and
we
now
also
also
have
a
research
paper
that
documents
how
this,
how
icns
can
perform
a
lot
better
compared
to
co-op-based
networks,
because
they
enable
caching
next
slide
please.
G
So,
let's
look
briefly
into.
Why
is
oscore
not
cachable?
There's
two
things
that
make
it
troublesome
first,
is
that
there
is
the
there
is
a
post
and
and
a
changed
code
in
the
requests,
at
least
on
the
wire.
So
this
makes
them
uncashable
and
also
there
is
a
key
id
and
a
partial
iv,
that's
different
in
any
request.
G
That
also
makes
a
difference
in
the
cache
key
and,
last
but
not
least,
the
announce
code
context
is
always
always
only
valid
for
a
particular
pair
of
devices,
so
caching
doesn't
help
a
lot
in
there
next
slide.
Please
so,
let's
look
into
what
we
can
do
against
this.
First
of
all
use
grouposcore,
which
is
kind
of
the
the
obvious
thing
to
do.
When
there
are
multiple
devices
involved
in
those
core
communication,
then
we
can
easily
switch
to
fetch
and
content
for
things
that
are
conceptually
cacheable.
G
There
is
at
least
the
way
I
read
the
oscore
document,
nothing
in
there
that
forbids
that.
It
just
says
it's
used
for
it.
It's
used
when
it
thank
you
and
that
should
probably
be
204.
G
I
happen
to
mix
those
things
up
in
fetch
and
content
because
they
are
already
in
use
for
observations,
so
I
don't
really
see
any
reason
why
they
couldn't
be
used
and
then
say
we
had
a
way
of
magically
still
hitting
the
cache,
with
a
no
response
with
a
new
request,
but
then
still
verification
would
fail,
because
the
client
would
try
to
unprotect
it
with
its
own
request
in
the
in
the
request
key
id,
rather
than
whatever
populated
the
cash
next
list.
G
So
the
thing
that
we
introduced
in
this
document
is
that
there
is
a
consensus
request,
which
is
the
the
single
request
for
a
particular
resource
that
every
client
that
wants
to
obtain
it
has
to
has
to
know,
and
in
that
consensus,
request
the
kid
and
the
partial
iv
are
picked,
and
then
everything
can
be
can
be
decrypted
and
verified
again
when
there
is
when
this
origin,
when
the
origin
server
produces
that
consensus
request,
we
call
it
ticket
request
and
next
slide.
G
Please,
these
ticket
requests
actually
are
the
precise
thing
that
we
have
in
the
in
the
multicast
notifications
so
far.
So
how
would
that
work?
The
client
sends
a
get
protected
with
its
own
security
context,
with
its
own
sequence
number
and
from
the
server
get
back.
No
sorry,
I
won't
tell
you
what
I've
already
told
various
others,
but
use
this
precise
request
that
I
protected.
This
is
the
consensus
request.
This
is
the
ticket
to
the
cash
try
again
with
that,
the
client
signs
that
it
hits
the
proxy.
G
G
This
is
also
great
when
you
have
large
resource
representations,
but
we
try
in
osco
to
avoid
having
those,
at
least
at
the
at
the
level
of
protected
messages,
because
that
would
mean
that
the
client
would
have
to
get
the
whole
thing
and
then
I'm
protected,
rather
than
getting
things
in
in
what's
called
in
a
blockbuster,
so
the
use
cases
are
a
bit
limited
as
long
as
we
do
it.
That
way,
next
slide
is
so
there
has
to
be
a
better
way.
G
So
let's
continue
on
the
track
of
magically
hitting
that
cache
key,
because
if
we
can
convince
the
proxy
to
give
us
a
result,
then
maybe
we
don't
need
that
first
round
trip
and
by
the
way
this
is
not
in
the
duck
in
the
draft.
Yet
this
is
an
addition.
G
I
came
up
with
the
last
few
days,
so
don't
expect
to
find
this
in
the
text,
but
if
we
could,
I
think
it
helps
in
the
in
setting
this
up
if
the
client
were
to
include
as
an
unprotected
option,
a
hash
of
that
request
that
it's
sending
and
the
proxy
knew
that
option
and
knew
that
on
any
request
it
got
with
that
particular
option.
It
could
send
an
old
response
that
contains
in
the
sense
of
non-traditional
response
that
response
4
option.
G
G
It
reveals
to
the
proxy
that
the
class
of
request-
but
this
is
what
this
is
all
about,
because
otherwise
the
proxy
couldn't
serve
a
response.
So
this
would
also
get
us
a
bit
further,
provided
we
have
a
good
way
of
coming
up
with
a
deterministic
hash.
That's
the
same
for
every
request:
that's
ever
generated
by
all
those
different
clients,
which
is,
I
think,
something
that
should
be
easily
possible
because
we
can
hash
the
the
plain
text
on
the
aad
and
come
up
with
something
next
slide.
Please,
but
maybe
we
can
do
better.
G
So
if
we
already
have
that
hash,
we
could
just
put
that
hash
in
that
not
necessary
there,
but
a
client's
request.
Partial
iv,
thus
come
up
with
a
nonce
that
is
unique
over
all
requests,
provided
there
are
no
hash
collisions
which
there
are,
but
nobody
can
produce
them.
So
that's
kind
of
provided
we're
using
an
adequate
hash
put
that
into
the
partial
iv
and
then
send
that
to
the
proxy
and
every
client
that
sends
an
identical
request
would
come
up
not
only
with
the
identical
plaintext.
G
Of
course,
the
plaintext
varies
only
slightly
everything
fails,
but
that's
okay
in
this
setup
that
has
this
very
precise,
partial
iv
and
key
id
and
then
send
that,
and
we
it's
not
really
non-reused.
If
we
do
the
same
encryption
and
use
the
same
authenticate,
additional
authenticated
data
and
plain
text
or
is
it
and
and
this
or
is
it-
is
a
very,
very
important
question
that
I
myself
can't
with
certainty
answers.
G
So
that's
that's
where
I'm,
where
I'm
helping
to
get
feedback
here
but
provided
it
is
then
the
proxy
sees
a
deterministic
request
that
could
be
generated
by
any
client
in
the
group
and
returns
the
data
provided,
the
cache
is
populated.
Otherwise
it
sends
it
to
the
server.
So
we
can
verify
it
and
populate
the
client's
cache
other
proxies
cache
slide.
Please!
G
So
there's
a
few
caveats
here.
A
the
partial
iv
length
is
limited
to
40
bit
with
the
birthday
paradox
that
gives
us
2
to
the
power
of
20
requests
until
we
get
actual
months
reuse,
which
is
probably
not
enough.
G
G
It's
kind
of
below
the
kid
context
and
below
the
kid,
not
above
the
kid
like
the
kid
context,
so
so
that
should
not
be
so
so
this
this
should
work
here,
and
the
other
hard
part
here
is
that
oscor
requires
requests
to
be
signed.
So
the
two
ways
to
go
about
this
is
either
to
create
a
group
member.
We
also,
we
already
have
to
create
a
group
member
for
those
deterministic
operations
that
would
being
be.
G
Could
that
could
be
any
client
so
either
we
give
this
group
member
a
private
key
with
which
it
can
sign
the
requests
and
give
them
by
construction.
This
whole
thing
only
works
for
safe
requests.
Anyway,
there
wouldn't
really
be
a
reason
for
the
server
to
even
validate
the
signature,
but
formally
it
needs
to
be
there
or
we'll
have
to
introduce
some
way
of
producing
group
requests
that
are
not
signed,
and
this
is
something
that's
not
really
accounted
for
in
co-op,
so
that
I
know
score.
G
So
this
is
why
the
current
document,
the
current
draft,
suggests
that
there
is
just
a
group
member
that
is
the
consensus
client
that
can
be
executed
by
by
any
participant.
So
next
slide,
please.
G
So
I'm
not
sure
whether
this
will
stand
the
test
of
practicality.
I
think
it
will,
but
the
group
has
much
better
expertise
in
this.
These
things
I
don't
know
yet
whether
this
is
cryptographically
valid
and
I
serious,
I
think,
there's
already
comments
on
the
chat
on
the
chat
on
this,
and
the
last
thing
is
whether
core
is
the
right
place
to
to
work
on
this
or
to
present
updates
on
this.
G
So
thanks
for
your
attention
and
I'd
be
happy
to
start
reading
over
the
chat,
but
please
come
to
the
mic
with
questions.
J
So
francesca
here
as
to
the
question,
if
corey
is
the
right
place
in
my
opinion,
yes
absolutely
and
I'm
willing
to
read
and
review
this
document,
I'd
like
to
do
it
after
the
next
update.
If,
since
you
seem
to
have
an
update
planned.
J
G
So,
just
just
to
comment
on
the
topic
of
the
update.
Some
of
this
is
really
to
kind
of
make
it
easier
to
explain
and
to
lead
the
way
towards
the
final
thing,
where
you
only
have
the
consensus
request
that
everyone
comes
together
on,
so
the
update
just
adds
an
intermediate
step.
If
you
are
already
understand
how
it's
playing
together,
the
update
won't
help
a
lot.
A
G
A
G
G
One
two
more
yeah
I
mean
this
is
this
is
not
something
that
I'm
I'm
actually
proposing.
So
this
is
this
is
about
how
it
works
with
with
multicast
notifications.
G
A
G
A
And
jim,
I
think
he
mentioned
something
about
the
a
class
of
encryption
algorithms
for
which
this
wouldn't
be
doable.
Can
you
elaborate
a
bit.
G
C
C
I
think
there
may
be
one
or
two
in
cfrg,
but
I
actually
have
to
go
back
and
reread
them
other
carefully
to
figure
out,
if
that's
actually
true,
there's
another
class
of
algorithms
which
we
won't
be
able
to
use
at
all,
because
they
don't
have
an
iv
to
any
real
extent.
G
Funny
funny
detail
here
all
those
on
the
on
the
last
slide,
but
one
all
those
consensus
request.
All
those
deterministic
requests
will
actually
have
the
partial
iv
of
zero
because
the
id
detail
goes
into
the
key
derivation,
which
unfortunately
needs
to
be
done
every
time,
but
that's
a
trade-off
that
comes
from
the
choice
of
non
length
versus
versus
input
life,
so
yeah.
A
Okay,
there
are
other
people
in
the
queue
or
any
any
more
comments,
because
we
are
a
bit
five
minutes
over
time
and
I
would
just
like
to
give
room
for
everybody
else
to
say
the
words.
A
Okay,
very
good,
sorry
christian,
please
feel
free
to
wrap
up
on.
G
The
nose
thanks
for
that
feedback,
there's
there's
a
few
things
that
I
can
work
from
and
I'll
inform
you
when
there's
an
update.
Thank
you.
A
Great
well,
thank
you
very
much
and
I
think
that
finishes
it
all.
We
have
had
two
great
sessions.
Remote
participation
has
worked
pretty
well
and
yeah.
I
think
we
are
satisfied
with
the
output
and
the
outcome.
Thank
you
for
those
to
those
who
who
stayed
even
this
long
and
hope
you
have
a
great
summer
on
a
great
location
yeah.
So
we
will
have
interims
coming
back
in
september.
I
believe,
and
we
are
trying
to
sync
between
ace
so
so
there
is
multiple
sdos
and
working
groups.
D
With
we'll
alternate
with
seabor
and
avoid
the
monday
to
avoid
ace.
A
Yes,
but
but
we
haven't
come
up,
we
will
send
a
doodle,
but
we
haven't
come
up
with
the
right
dates,
because
there's
also
people
are
attending
1dm,
oma
and
ex.
You
know
a
lot
of
other
organizations
that,
because
of
the
coronavirus,
they
are
having
also
a
lot
of
virtual
meetings,
so
we
thinking
is
a
bit
harder
than
it
used
to.
So
we
are
trying
to
either
collocate
or
have
back-to-back
meetings,
but
we
will
send
info
on
the
car
mainly
list
more
questions.
Please.