►
From YouTube: CORE WG Interim Meeting, 2020-11-05
Description
CORE WG Interim Meeting, 2020-11-05
A
A
Okay,
welcome
all
to
this
core
interim
meeting
last
of
the
series
before
one
line
it's
mark
on
high
maturing
not
well
applies,
please
get
aware
and
confident
with
them.
If
you
are
not
already-
and
that
said,
we
can
switch
to
the
presentation
from
christian
call.
This
document
then
yep.
C
So
I'd
like
to
go
with
you
through
what
I
think
is
other
next
steps
for
for
making
oscore
cachable
and
for
accessing
yeah,
basically
to
get
deterministic
requests
here
next
slide,
please
so
the
just
to
get
everyone
on
the
boat
again.
This
is
coming
from
the
work
out
of
the
work
about
multicast
notifications.
C
There
we
have
the
case
that
the
server
can
tell
the
client
that
there
is
already
already
a
request
that
is
being
actively
responded
to,
and
the
server
can
tell
that
client
that
request
and
all
is
fine
for
for
that
matter.
So
the
client
still
needs
to
verify
that
request,
but
that's
that's
not
too
big
of
an
issue,
and
there
is
no
need
for
determinism
there,
but
that
only
flies
well
when
we
are
in
a
situation
where
there
are
many
response
to
a
single
request.
C
So
for
today,
I'd
like
to
focus
this
on
the
deterministic
requests,
part
of
cachable
oscar,
which
really
is
the
thing
where
I'm
trying
to
get
at
there.
So
there's
a
lot
of
things
like
token
requests
in
there
that
basically
abstract
away
from
the
mod
from
the
multicast
notifications
but
determination
request
is
the
core
of
the
thing
and
that's
what
I
like
to
talk
about
and
not
lose
get
lost
in
details
about
all
the
steps
for
getting
there.
C
Yes,
ticket
requests,
and
this
probably
is
wrong
the
same
all
over
the
slides.
If
I
start
making
such
a
mistake,
then
I'm
very
consistent
in
doing
it
thanks.
Yes,
ticket
request.
D
C
Next
slide,
please
sure,
so
this
is
what
I
imagine
this
will.
This
should
look
like
in
the
end,
the
client
sends
a
request.
That
is
a
regular
oscar
request,
that's
in
a
in
a
fetch
rather
than
a
post,
because
it
might
be
observable,
and
because
this
is
generally
what
enables
all
the
caching
oscore
doesn't
forbid
that
it
uses
a
pre-setup
member
on
key
id
from
within
a
group
I'll
get
to
the
group
later.
C
C
Is
the
remainder
of
a
request
message:
the
kid
detail
in
order
to
get
these
deterministic
requests
that
we
want,
where
many
clients
can
produce
a
request,
and
that
is
by
identical
to
the
point
where
it
doesn't
even
count
as
nonce
reuse,
because
it
is
just
the
same
message
and
to
on
to
to
avoid
using
the
same
key
for
different
requests.
C
We
have
to
find
a
way
to
use
a
different
non,
so
what
I
originally
planned
to
and
what
just
doesn't
work
out
because
of
the
size
constraints,
is
to
use
that
hash
in
here
that
I'm
I'll
talk
about
right
away
as
a
nonce.
We
can't
use
it
as
a
nouns,
because
the
nouns
in
is
quite
limited
in
this
application.
So
we
have
so.
This
goes
really
into
the
key
derivation.
C
This
would
be
so
so
what
what
what
the
client
would
do
is
it
constructs
the
request
as
a
kind
of
the
inner
request,
hashes
that,
along
with
the
with
the
aad
and
puts
that
had
that
hash
into
the
kid
detail
that
goes
into
the
key
derivation
process,
the
key
gets
derived
it
sends
the
it
encrypts.
The
request
sends
it
to
the
server
and
the
server
uses
the
same,
the
same
key
to
respond
to
that
request,
so
yeah
and
next
slide.
Please.
B
So
what
do
we
need
for
this?
We
need
yeah,
how
I
I
think
you
were
ready
with
the
explanation.
We
should
understand
why
this
is
cachable.
Now.
Yes,
if,
if,
if
it's
not,
please
explain
carefully.
C
Why
this
is
cash
up
now?
Okay,
this
is
cashable
now
so
on
the
technical
side,
this
is
cachable,
because
it's
using
fetch
and
as
long
as
the
server
in
the
response
chooses
not
to
send
the
max
age
to
a
ridiculously
small
number,
then
the
proxy
will
buy
the
option
properties
that
are
in
here
and
cache
that
response.
C
On
the
practical
side,
this
is
cachable,
because
many
clients
that
send
the
same
that
send
the
intention
that
send
the
same
request
by
what
they
mean
will
also
arrive
at
the
same
request
in
terms
of
bytes
that
are
in
there,
because
what
they
mean
is
encoded
in
the
inner
option.
That
is
the
get
the
temp
the
uri
and
any
other
inner
options
and
everything,
and
because
everything
else
is
deterministic
on
the
group
that
this
is
set
up
with,
which
will
largely
gloss
over
here.
But
there
needs
to
be
a
group.
C
B
B
C
B
C
C
No
or
do
we
have
any
so
so
the
thing
that
prevents
the
server
from
any
other
client
from
faking
server
responses
is
that
usually
with
grouposcore-
and
this
is
all
grouper
and
it's
I'll
get
to
why
it's
not
here
here
in
this
line
that
at
the
end
there
is
a
signature.
C
So
while
the
while
any
client
can
send
requests-
and
they
are
not
even
distinguished
so
if
it
says
kid
equals
client
here-
that's
literally
client
in
the
sense
that
there's
one
key
id
that
everyone
every
client
is
using,
but
the
server
is
using
a
different
sender
id
to
respond
and
the
server
will
use
the
regular
signatures
that
are
there
for
for
group,
scroll.
F
Yeah
they
just
said
gerand
saying
you
can't
cash
unless
you
are
in
the
group,
the
proxy
does
the
caching
and
the
proxy
is
not
necessarily
in
the
group.
So
I
think
what
what
you
meant
to
say
is.
You
cannot
be
part
of
a
successful
caching
transaction
as
a
client
or
a
server
unless
you're
in
the
group.
You
can't
hit
the
cache
without.
B
B
Could
I
realize
that
I
should
join
the
group
or
maybe
this
is
this
goes
beyond
the
discussion
here?
But
so,
if.
C
If
you
don't
already
know
that
you
should
join
the
group,
then
you
will
try
to
get
to
send
the
request
in
a
regular
way
and
we
might
apply
the
concept
of
multicast
core
to
redirect
that
client
towards
joining
the
group
and
doing
it
in
the
deterministic
way.
But
in
all
cases
but
those
special
cases
we
can
just
respond
as
well.
So
the
client
has
to
have
some
pre-configured
or
discovered
knowledge
of
that.
It
should
use
cache
of
our
score
for
this.
B
C
C
This
could
be
well
usable
for
firmware
updates
when
the
client,
when
a
lot
of
clients
access
the
same
resource
and
then
they
can
just
all
send
their
requests,
and
they
know
that
others
will
do
this
too,
and
they
will
know
the
bit
of
the
about
the
firmware
server
and
will
join
that
group
first
and
then
they
all
hit
the
same
cache
at
the
at
the
border,
router
or
even
within
the
network.
C
C
I
think
it's
still
the
oh
that
I've
uploaded
last
is
that
we
would
you
that
basically,
every
client
would
get
access
to
the
private
key
material
that
is
associated
with
that
client
and
then
deterministically
arrive
at
the
signature
that
construction
was
put
in
there,
primarily
because
the
syntax
of
group
of
core
does
not
allow
for
no
signature
to
be
here
and
also
because
there
was
this.
There
were
previous
discussions
around
groupos
call
that
where
the
participants
insisted
very
heavily
on
source
authentication,
the
thing
is
by
now.
C
I
don't
think
this
is
a
good
idea,
because,
while
it's
technically
avoiding
all
those
pitfalls,
practic,
it's
practically
just
a
workaround
for
for
the
core
questions
that
there
is.
C
That
is
why
do
we
not
need
source
authentication
here
and
if
we
can
argue
that
we
don't
need
source
authentication
which
we'll
have
to
do
if
we
want
to
sell
to
anyone
who
objected
not
having
that
that
we
are
now
sharing
private
keys,
we
can
just
as
well
explain
to
them
that,
for
these
particular
cases,
no
source
of
authentication
is
necessary
because
in
the
end,
if
there
were
source
authentication,
this
would
all
not
be
cacheable
anymore
and
on
the
other
hand,
everything
that
we
see
around
where
this
can
be
used
will
very
precisely
state
that
this
can
only
ever
be
used
if
the
requests
have
no
side
effects
on
the
survey.
C
Yes,
so
what
I
propose-
and
what
I
think
should
be
easily
doable
with
actual
implementations,
is
that
this
particular
participant
of
the
group,
that
is
the
client
picks
a
different
signing
algorithm,
then,
is
generally
used
with
that
group,
and
that
signing
algorithm
is
the
null
algorithm
in
which
nothing
is
actually
signed,
and
the
signature
is
0.
Bytes
long
and
I
understand
this
algorithm
exists,
but
it's
not
talked
much
about,
because
it's
not
actually
doing
anything,
but
it
might
still
have
a
number
somewhere.
F
So
effectively
the
request
is
still
marked
by
the
group
key
right.
Yes,
so
that
needs
to
be
part
of
the
explanation.
C
C
That
means
that,
if
someone
finds
a
way
to
exploit
something
in
the
message
processing
it,
they
can't
even
get
there
without
being
part
of
that
group,
but
that's
an
additional
security
mechanism
against
implementation
errors
and
not
a
requirement
for
the
for
the
confidentiality
of
anything
in
here
or
for
the
for
the
side
effect
that
side
effects
that
could
be.
F
C
Work
avoidance.
The
max
max,
certainly
does
a
thing
yes
much
better
than
a
signature.
B
C
B
C
So
yeah
we've,
I
think,
we've
talked
about
the
group
group
members.
Other
prerequisites
here
are
that
we
have
to
have
a
deterministic
aeid
algorithm,
and
I've
mentioned
that.
The
last
time
I
presented
about
this,
we
can
probably
have
a
flag
in
the
oscore
registry.
That
says
is
this:
is
this
algorithm
suitable
for
this
thing
or
not,
and
chances
are
that
no
algorithms
will
work
for
oscar
anyway
that
well?
C
This
is
not
the
case,
but
I
I'm
not
sure-
and
I
don't
wouldn't
require
that
and
yeah
the
the
other
thing
is
no.
No
two
messages
must
ever
use
the
same
key
with
the
same
nonce,
because
many
of
our
algorithms
will
behave
very
badly
if
we,
if
we
allow
that,
but
given
that
everything
that
that
goes
into
the
into
the
later
encryption
process
is
also
part
of
the
key
derivation
it
will,
it
will
not
provide.
C
C
And
the
last
point
here
is
sure
this
all
depends
on
the
clients
all
arriving
at
the
same
in
the
request.
But
if
they
don't
yes
or
what,
then
there
will
be
a
few
variations,
can't
can't
be
avoided
or
if
it
can
that's
out
of
scope
for.
C
B
B
B
C
B
And
maybe
we
would
like
to
have
that.
I
mean
ad
hoc
to
set
up
something
which
you
transport
cozy
objects
between,
and
then
you
you'd
like
to
have
similar
features
as
I'll
score
with
yeah,
the
replay
protection
and
the
non
generations,
and
so
on.
So
that
might
be
another
reason
why
we
should
revive.
C
It
I
mean
this:
this
will
not
help
with
replay
protection,
so
the
the
server
side
handling
of
this
pretty
much
relies
on
replay
protection
being
switched
off,
which
can
only
happen
if
the
if
the
request
is
safe,
which
is
a
prerequisite
way,
so
it
works
here.
But
if,
if
there's
re,
if
anything
else
wants
oscars
replay
protection,
it
probably
won't
go
through
this
channel.
B
Okay,
that's
a
good
point.
So,
let's
see
what
what
is
the
right?
What
kind
what
you
need,
except
the
I
mean
oscar-
was
simply
essentially
doing
doing
the
things
we
did
in
oscore,
but
not
taking
into
account
that
this
was
necessarily
restful
operation.
This
was
just
the
payload.
E
Hello,
michael
richardson
co-chair,
who
is
that
guy.
C
C
Once
a
client
is
rather
confident
that
this
request
is
probably
already
in
someone's
cache,
at
least
in
the
at
least
in
the
servers
cache,
which
means
the
server
could
have
an
internal
cache,
then
it
might
be
an
option
to
really
practically
only
transport
that
hash
at
all
elide
all
the
other
options
and
payload,
and
for
this
this
would
additionally
require
that
the
proxies
in
between
recognize
this
particular
flag
in
the
oscar
option
and
treat
this
as
the
soul
cache
key
as
opposed
to
taking
the
payload
into
account.
C
C
But
that's
I.
I
briefly
thought
that
this
might
this.
This
might
be
relevant
as
a
way
of
avoiding
the
the
signature
situation,
but
really
doesn't
help
here.
B
Sorry,
christian,
I
I
didn't
catch
this
oscar
option
with
this
flag
set
could
be
used
as
standalone
shot.
What
which,
what
is
this
flag?
The
the?
What
did
I
call
it
kid.
C
B
Is
that
the
is
that
an
oh,
that
is
a
new
that
is
the
new
that
is
the
new
oscar,
that
is
the
new
there's,
a
new
flag,
yeah,
that's
the
flag.
Okay,
I'm
introducing
right.
Okay,
so.
C
With
that
said,
and
technically
we
we
might
consider
using
another
flag
here
to
to
ensure
that
the
client
other
proxy
really
only
does
this
when
it's
a
good
idea,
I
don't
know
yet,
but.
C
So,
usually,
the
cash
key,
the
cash
key,
is
composed
of
all
the
options
that
are
cash
key,
plus
the
request.
Payload.
C
Yes-
and
this
would
this
option
with
this-
the
oscar
option
would
get
a
special
handling
by
a
proxy
in
the
sense
that
the
proxy
may
use
this
option
alone
as
the
cash
key,
as
opposed
to
using
all
those
other
things
which
means
that
enough
that
a
request
that
only
consists
of
the
hash
of
the
request,
as
opposed
to
the
full
request,
including
the
hash,
will
hit
the
same
cache
key
and
will
thus
inhabit
the
same
place.
The
cache
okay,
thanks.
C
E
I
have
a
question
on
the
fetch
semantics
like
does
it
need
some
sort
of
specific
semantics
like
samuel,
fetch
or
cinema
eye
patch
did,
or
it's
kind
of
like
a
assumes
that
the
semantics
are
understood
or.
C
So
this
fetch
is
already
part
of
us
core
for
regular
request
for
for
kind
of,
as
as
it
is
now,
it's
just
only
used
for
observation
because
you
can't
observe
a
post,
but
you
can
observe
a
fetch.
C
C
And
there's
no
there's
no
real
semantics
too
much
of
it,
because
the
the
semantics
layer
is
only
is
only
there
when
you,
when
the
oscar,
when
the
oscar
layer
is
removed
and
by
then
it
has
a
pro
it
has
the
proper
get
or
fetch
code
of
the
inner
message.
Where
then,
any
cml
fetch
semantics.
C
Yes,
but
that
would
be
about
the
inner
code,
so
the
if
you
go
back
to
slides
okay,
so
the
the
oh
okay,
sorry
one
more
right,
yeah,
so
there's
the
inner
code,
that's
in
the
in
the
second
line
from
the
bottom.
That's
the
get,
and
this
is
where
all
the
regular.
C
E
E
A
A
Well,
I
stopped
sharing
this
and
we
can
then
switch
to
the
other
topic.
Stateless,
but
michael,
has
a
comment,
in
fact,
in
the
chat.
D
I've
just
really,
since
I
missed
half
the
conversation,
I'm
just
asking.
If
I
understood
correctly,
if
for
item
potent
actions,
the
request
is
blinded
that
is
encrypted
or
something
so.
The
cache
can't
see
the
request
response,
but
can
still
cache
it.
That's
what
I
understood
the
whole
point.
Yes,
yes,
cool!
That's
really
neat.
D
D
D
Okay,
yeah,
it's
line.
923,
I
think,
is
the
relevant
part.
F
D
F
D
F
Yes,
if,
if
you
go
into
a
seven
two
five,
two,
it's
not
a
default!
It's
when
you,
when
you
compute
what
max
transfer
weight
needs
to
be
with
the
default
parameters
in
seven
two,
five,
two,
you
arrive
at
93.!
D
Seven
two:
I
have
twice
cited
the
wrong
rfcs
by
typos
of
dyslexia
and
had
80s
ask.
Why
are
you
citing
that
and
I
went.
G
I
don't
know:
oh
it's
it's
section
482.
I
can
put
this
in
into
the
request
form
it's
in
the
it's
in
the
minutes,
too,
I'm
taking
the
notes
as
well.
Okay,.
D
If
you
hit
reload
you'll
get,
I
think,
maybe
you
have
to
go
to
files
change
to
get
hit
to
get
the
suggestions.
D
D
Okay,
so
you're,
basically,
basically
coming
up
with
the
same
statement
that
32
is
plenty
and
in
fact
it's
even
better
than
plenty,
because
the
nice
part
about
it
being
larger
at
least
eight
bigger
than
20,
is
that
it
means
you
can
shift
it
by
bytes
rather
than
bits
as
you
increment,
your
your
your
your
low
water
mark.
A
Just
an
editorial
comment:
the
value
of
max
transmit
weight
alone
should
be
sufficient
to
understand
that
any
request
not
answered
within
three
seconds
will
be
considered
to
have
failed
right.
Yeah.
Yes,
so
we
may
rephrase,
as,
for
instance,
given
a
copy
transmit
weight
of
93
seconds,
any
request
that
blah
blah
blah.
D
F
F
A
D
D
A
A
I
checked
the
whole
document
again
and
this
looks
are
very
good
actually
and
I
think
there
are
still
two
open
issues
on
gita,
but
one
is
one
fix
and
the
other
one
I
think
was
addressed
in
the
document.
So
probably
they
just
have
to
be
closed.
D
A
Another
point
I
had
in
the
back
of
my
head
is
for
kirsten:
how
are
we
with
the
shepherd
right
up
of
the
core
conf
documents.
A
A
A
109,
no
okay,
so
this
was
the
last
interim
for
this
series
and
we
actually
planned
to
have
a
new
series
starting
around
mid-january,
ideally
until
1
10..
Otherwise,
we
have
two
sessions
for
core
plan
for
109
on
tuesday
and
friday,
and
we
have
a
draft
agenda.
Please
provide
feedback
if
you
want
to
give
more
input
or
propose
changes.
C
Hello,
christian!
Yes,
just
if,
if
you,
if
you
still
have
the
allocated
remaining
time
of
the
meeting,
we
could
go
through
the
shepherd
stuff
right
away.
If
you,
if
you.