►
From YouTube: IETF-CORE-20220525-1400
Description
CORE meeting session at IETF
2022/05/25 1400
https://datatracker.ietf.org/meeting//proceedings/
A
C
A
C
A
Yeah
also
considering
the
time
constraints
for
thomas,
let's
start
the
meeting,
then
so
welcome
everybody
to
this
interim
meeting
of
the
working
group.
I
am
marketiloka.
My
co-chairs
are
jaime
jimenez
and
kirsten
moorman,
and
this
is
an
official
ipf
meeting,
so
we've
been
recorded,
the
not
well
applies,
please
be
sure,
you're
familiar
with
that.
It's
not
just
about
apr
and
patents.
A
It's
also
especially
about
our
code
of
conduct,
so
be
nice
and
professional
to
each
other,
and
the
agenda
for
today
is
about
two
documents:
problem
details
that
had
a
running
working
group
last
call
until
yesterday,
and
I
believe
we
can
close
and
then
group
com,
proxy
and
esco
also
would
cover
about
group
communication
with
proxies
before
we
start.
Anyone
has
any
agenda
bashing
or
additional
item
to
propose.
B
A
A
A
B
A
C
A
A
On
the
other
side
of
the
screen,
thomas
right,
it's
the
icon
between
the
hand
and
the
screen,
and
you
should
be
able
that's
right.
B
Cool
fantastic,
probably
it
is,
I
suppose
this
is
it.
B
Cool
okay,
wait
a
second.
B
Right
so
this
is
the
update
for
for
the
concise
problem
details
draft
that
went
through
working
group
school.
In
fact,
a
cross-working
group
was
called.
B
Involving
core
symbol
and
http
api,
which
seemed
appropriate,
given
the
the
footprint
of
this,
you
know
seemingly
anodyne
draft
which
instead
has
interesting
ramifications
and
the
working
group
was
called
concluded
on
tuesday
and
we
had
a
few
by
a
few.
But
but
I
would
say,
high
quality
feedback.
Thank
you,
marco
christian
harian
and
roberto
pauli
for
for
the
input,
and
we
are
addressing
all
all
the
comments
in
one
in
one
batch
on
the
wgl
dash
processing
branch
on
on
the
repo.
B
And
if,
if
you
click
on
that,
rfc
diff
bit
in
the
slides,
the
the
the
you
could
see
that
the
diff
between
zero
three
and
the
work
in
progress
at
the
moment.
B
We
had
a
parallel
discussion
on
the
tag
38
fix
up,
mainly
in
in
in
sibor
and
and
just
to
present
a
refresher
of
the
thing.
The
the
the
the
thing
that
we're
doing
here
is.
We
are
extending
the
semantics
of
38
to
add
the
language
direction
so
left
to
right,
right
to
left
indicator
to
the
array
as
an
optional
as
an
optional
element-
and
this
is,
I
would
say,
a
quite
a
bold
move,
because
there
is
clearly
th.
There
is
clearly
a
potential
backwards.
B
Compatibility
problem
that
is,
that
is
introduced
by
the
changes.
Any
old
receiver
will
not
be
able
to
interpret
the
l2r
signal,
if
included.
B
So
you
know
we,
there
was
some
debate
between
the
co-authors
around
this
on
a
late
friday
night
and
then
carsten
went
ahead
and
and
sent
this
nice
email
to
the
to
the
zebra
working
group.
You
know
giving
the
rationale
for
for
the
for
the
for
the
thing
and-
and
the
surprising
thing
for
me
was
that
we
had
no
pushback.
B
On
the
contrary,
there
was
some
appreciation
for
the
you
know,
no
clutter
aspects
of
the
change,
so
apparently
carsten
was
right
which
doesn't
come
as
a
surprise,
but
still
so
we
had
this
positive
comments
from
from
michael
and
and
christian
and
yeah
appendix
a
contains
the
the
fix
up.
Basically,
the
rewrite
of
the
of
the
registration
for
type
38.
B
So
these
were
the
two
basic
discussion
threads
we
had
so
shepherding
is
started
and
has
taken
the
lead.
Thank
you
very
much.
So
we
started
the
write
up
and
also
kicked
off
the
ayana
processing,
because
we
have
a
few
things
there.
We
have
a
new
media
type.
We
have
the
associated
content
format
and
a
couple
of
new
sub
registries
for
for
slotting,
the
new
extension
points,
and
as
of
this
morning,
there
was
already
his
co
providing
his
thumbs
up
on
on
the
content
format.
Registration.
B
So
we
seem
to
be.
You
know
in
good
shape
there,
but
but
the
thing
is
that
the
the
milestone
for
this
is
the
etas
is
june
2022,
which
seems
like
a
date
in
the
future,
but
is
in
fact
you
know
a
week
a
week
from
now
for
shipping
this
to
isg,
which
is
quite
tight
and
and
just
to
to
be
clear.
The
reason
for
this
acceleration,
sudden
acceleration
and
deadlines,
is
that
the
some
documented
some
documents
in
the
in
the
3gpp.
B
As
you
depend
have
taken
a
dependency
on
on
problem
details
on
concise
problem
details,
as
well
as
the
seven
eight
or
seven,
the
unconstrained
version
of
this
work
and
they
plan
to
publish
in
june.
So
that's
why
we're
trying
to
align
the
two?
B
B
But
what
I
wanted
to
discuss,
maybe
is
that,
given
the
you
know
the
stringent
timeline,
maybe
we
should
request
error
reviews
in
parallel
to
radio
review
instead
of
waiting
on
on
the
output
from
francesca.
But
you
know
this
is
just
the
my
two
cents
that
I'm
throwing
in
there
yeah.
I
think.
That's
it!
That's
it
from
from
me.
E
I
just
wanted
to
to
point
out
that
it's
not
us
who
are
usually
asking
for
error
reviews,
but
the
id
so
essentially
the
the
next
milestone
is
for
us
is
to
throw
the
thing
over
the
fence.
And
then
it's
all
francesca's
decision
how
to
handle
this.
But
we
might
very
well
suggest
that
she
should
request
error,
reviews
right
away.
A
Okay,
any
questions
or
comments
on
the
the
slides
I've
just
seen
for
thomas
because
well
I
know
carson
has
more
details
on
the
actual
changes
on
the
github
before
getting
into
that.
Maybe
there
are
more
high-level
questions.
E
Yeah,
so
we
did
this
relatively
quickly
with
few
of
the
usual
breaks
and
stops
since
on.
We
have
because
we
want
to
beat
this
june
submission
milestone.
We
want
to
do
it
this
week,
so
let
me
quickly
run
through
the
the
regular
blast
call
comments
and
see
how
we
handled
them.
So,
as
thomas
said,
this
is
in
a
branch
on
on
the
repo.
E
There
are
some
18
commits
in
this
pull
request
and
those
were
essentially
taken
right
from
the
discussion
in
the
mailing
list
without
creating
individual
prs
or
even
creating
issues
for
them.
We
also
have
a
few
abbreviations
that
we
have
been
using
between
the
authors,
but
not
not
in
the
document.
E
So
there
is,
there
are
concise
problem
details,
data
items.
These
are
the
things
that
we
are
standardizing
here
and
on
the
slides
I
will
use
cpddi
for
that,
then
we
have
standard
problem,
details
entries
which
are
one
kind
of
entries
in
the
data
item,
and
we
have
custom
problem
details,
entry
which
are
the
other
form
of
entries
in
in
the
map
that
that
constitutes
the
concise
problem
details
data
item
and
the
bug,
of
course,
is
that
both
the
word
concise
and
the
word
custom
starts
with
a
c.
E
So
if
you
hear
me
saying
the
wrong
thing
that
I
I
I
usually
mean
what
what
makes
sense,
I
should
be
saying,
of
course,
much
of
the
work
was
on
the
editorial
side,
so
11
of
the
18
commits
are
editorial
ones.
I've
listed
them
here.
If
you
want
to
cross
check
them,
and
one
of
them
is
consistently
using
concise
problem
details,
data
item
there
were
some
reference
tweaks
and
so
on.
E
There
was
one
technical
knit.
The
the
entry
in
the
registry
was
wrong
about
what
can
be
in
the
standard
probability
entries
one
and
two
and
we
changed
that
tag.
38
was
already
mentioned,
so
one
thing
that
I
added
very
recently
is
making
the
base
direction.
Auto
explicit
in
in
the
previous
version.
E
E
The
other
thing
that
I
think
is
really
important
to
understand
this
whole
attack.
38
thing
is
that
the
whole
issue
of
how
to
actually
handle
mixed
direction
text
is
still
under
ongoing
standardization.
E
E
So
we
are
defining
this
tag
38
in
into
a
landscape
that
is
somewhat
uneven
and
we
can't
really
define
the
meaning
of
this
tag
in
in
all
necessary
detail
without
defining
that
landscape
and
that
doesn't
make
any
sense
whatsoever.
E
So
the
purpose
of
the
tag
38
is
to
deliver
the
information
that
goes
into
those
algorithms
and
the
algorithms
will
be
defined
elsewhere,
and
we
cannot
have
normative
references
to
them
because
yeah
yeah
do
you
find.
Yet
there
is
a
pretty
good
understanding
between
the
people
who
who
are
working
in
this
space.
We
had
a
little
side
discussion
in
the
internationalization
directorate
about
that.
E
I'm
not
a
member
of
that,
but
but
I
could
get
some
responses
from
some
of
them
and
they
also
see
the
problem
that
that
right
now
there
seems
to
be
a
rough
consensus
on
how
to
handle
this.
But
it's
not
written
up
so
that
that's
the
the
the
space
into
which
this
tank
38
38
change
goes,
but
I
think
it's
better
to
to
be
prepared
for
what's
going
on
there
than
then
to
be
on
the
in
this
duration
of
10
years
ago.
E
We
actually
went
on
and
defined
a
term
for
problem
shape,
because
we
we
earlier
got
rid
of
the
problem
type,
which
is
the
the
simplistic
way
of
talking
about
what
the
problem
is
about.
So
the
7807
assumption
is
that
you
are
in
a
situation
where
you
can
enumerate
all
your
problems
you
might
be
having,
and
that
becomes
part
of
the
interface
and
that
that
doesn't
really
mesh
with
reality.
E
So,
typically,
if
you
define
an
interface
between
two
components
that
evolve
separately,
then
you
are
finding
new
kinds
of
problems
all
the
time
and
if
you
want
to
be
able
to
talk
to
other
instances
that
that
may
not
have
that
new
problem
type
in
mind,
then
you
do
this
in
terms
of
problem
details
and
that's
why
we
removed
the
problem
type.
Apart
from
the
fact
that
it's
a
big
registration
issue
there
and
the
next
dash
problem,
because
people
will
use
your
eyes
before
they
are
registering
things
and
so
on.
E
So
all
in
all,
the
thing
becomes
both
simpler
and
more
aligned
to
reality,
except
for
the
few
cases
where
you
actually
already
have
78
to
7
problem
types,
and
in
that
case
you
can
simply
import
them
from
there
and
we
have
defined
defined
a
custom
problem
details
entry
with
the
ominous
number
7807,
and
that
is
actually
meant
to
carry
this
kind
of
information
around.
If
you
have
it.
E
So
that's,
I
think
a
pretty
significant
editorial
change,
explaining
what
we
had
in
mind.
But
if
the
explanation
before
that
has
been
so
poor
that
you
didn't
quite
understand
what
we
are
doing
here
now
now,
it
should
be
much
more
clear.
E
But
as
soon
as
you
store
a
concise
problem
details
data
item,
it's
not
clear
that
you
stored
the
base
ui
with
that,
so
we
defined
base
uri
standard
problem,
details,
entry,
which
now
has
number
-5
and
explained
how
that
is
meant
to
be
used,
and
that
meshes
with
the
response
code
that
we
already
had,
because
that
is
another
thing
that
is
clear
from
from
the
rest
context,
from
the
request
response
context,
but
would
be
lost
when
you
store
just
a
problem
details
data
item,
so
one
one
comment
that
christian
just
made
on
the
list
was
that
we
really
should
be
thinking
more
about.
E
There
there
is
some
text
in
industrial
tool
that
requires
ignore
unknown
processing.
So
if
you
have
a
problem
details
entry
that
you
don't
know,
you
should
be
safe
to
just
examine
the
other
ones
and
make
up
your
mind
what
happened
from
from
the
other
entries.
So
you
can
ignore
unknown
entries
and
that's
a
common
json
extensibility
pattern
that
we
we
are
just
following
here,
and
this
provides
forward
compatibility
because
you,
you
can
put
new
stuff
into
your
problem
details.
E
While
you
still
have
old
systems
out
there
that
don't
understand
that
stuff
and
that's
a
pretty
important
part,
for
instance,
of
http
that
you
can
put
headers
in
there
that
header
fields
in
there
that
haven't
been
defined
before
before.
Without
breaking
everything.
If
you
break
everything,
then
you
are
not
going
to
do
that
and
then
you
don't
have
a
forward
compatibility.
E
E
Okay,
so
we
are
not
in
a
position
to
to
actually
write
up
the
ignore
unknown
principle
in
all
details
and
forever.
E
I
think
this
is
pretty
much
what
we
have
to
say
about
ignore
unknown,
but
there
is
one
more
detail
that
came
up
in
the
discussion
on
the
list:
what
if
we
are
not
just
adding
a
new
map
key
which
is
easily
detectable
as
one
that
you
don't
know,
but
if
the
data
given
for
a
map
key
look
different
from
what
they
should
and,
of
course,
if
you
are
using
internal
ignore
unknown.
If
the
data
you
supply
for
an
existing
map,
keep
internally
have
map
keys
that
are
new
and
you
ignore
them.
E
So
the
question
is:
do
we
need
to
define
this
part
of
j
of
the
json
ignore
unknown
pattern
as
well,
and
there
is
a
lot
of
assumptions
that
people
make
so,
for
instance,
if
you
have
a
new
enum
in
a
set
of
allowed
values
for
a
string,
usually
that
new
enum
is
not
understandable.
So
you
would
expect
to
ignore
that
if
you
have
something
that
says,
you
can
have
0
to
10
boxes
in
in
that
palette,
and
it
suddenly
has
the
number
20.
E
E
So
these
are
things
that
people
who
build
applications
in
this
space
do
intuitively
and
writing
up
all
this
intuitive
processing,
probably
what
would
take
years.
So
I
don't
think
we
should
include
text
on
this,
but
we
should
be
aware
that
this
is
something
that
is
not
really
fully
defined
in
the
extensibility
story
of
javascript
or
of
json.
E
Finally,
we
had
a
little
detail.
The
slide
is
wrong.
The
the
bottom
right
character
would
need
to
be
a
brace
not
a
bracket,
so
there
is
an
example
for
how
to
port
the
7807,
like
invalid
parents
construct
out
of
3gppts29
112
to
this,
and
the
example
uses
an
array
where
the
the
json
form
uses
a
map,
and
I
actually
find
this
attractive
because
it
allows
us
to
to
demonstrate
that
we
don't
have
to
do
this
exactly
in
the
way
the
json
specification
would
do
so.
E
I
would
prefer
to
keep
it
this
way,
because
it's
much
more
likely
that
you
will
do
this
in
in
a
zero
environment
than
the
braces
version.
But
but
of
course
it's
a
change
and
it
depends
on
on
the
the
actual
meaning
of
ts29
112,
whether
that
change
would
actually
be
desirable.
But
this
is
not
an
example
to
to
indicate
how
to
do
29
112
in
in
our
specification,
but
it's
an
example
to
show
the
use
of
custom
problem
details
entries
and
we
just
took
the
the
real-life
content
of
that
from
29
112.
E
A
B
Okay,
so
I
I
was
not
sure
about
the
base
uri
being
in
the
standard
space,
but
but
the
analogy
with
response
code
has
made
my
mind:
conversion
on
that.
So
now,
so
I
I
am
okay
with
that.
B
C
Yeah
on
the
slide,
six
on
the
topic
of
the
type-
I
don't
know
if
he
was
in
the
call
of
minutes
ago.
I
think
he
left,
but
we
were
discussing
it
at
least
with
the
three
p
colleagues
that
what
they
are
looking
is
kind
of
like
a
one
to
one
mapping
like
the
simplest
they
can.
They
can
see.
I
get
the
point
of
the
problem
shape.
C
E
We
have
a
whole
appendix
b
on
that,
so
that
actually
mentions
type.
C
Okay,
maybe
I
didn't
have
a
too
close
look
on
that
then
anyway,
I
can
take.
C
It's
not
a
problem
and
then
on
the
I
would
check
that
next
week
and
then
on
the
last
item
I
kind
of
agree
with
carsten
on
this.
One
like
it
makes
more
sense
to
have
the
not
have
the
array
of
objects,
but
I
guess
it's
I
mean
at
the
end
of
the
day
is
for
the
group
to
decide
so
yeah.
C
B
Hey,
do
you
do
you
want
some
change
in
the
in
the
draft
for
this
or
not
because,
as
kasten
has
mentioned
in
a
in
a
parallel
email,
this
is
just
an
example
right,
so
it
happens
to
be
a.
I
crafted
it
this
way,
because
I
I
took
the
29
112
and
then
you
know,
try
and
work
out
how
it
would
look
like,
but
it
was
just
you
know.
I
guess
so,
unless
you
want
this
to
be,
you
know
the
kind
of
blueprint
for
for
for
the
3gbp
work.
C
B
C
Thought
that
I
mean
if
it's
not
a
non-contentious
issue,
and
it's
like
a
bike
check
thing,
then
the
second
one
with
the
fixed
first
bracket.
Actually,
I
think
that
would
be
more
clear
for
the
people.
Just
you
know,
there's
usually
people
through
just
browsing
the
draft
and
they
may
get
confused
if
they're,
seeing
the
example.
So
if
it
is
not
a
problem
for
you,
the
second
one
actually
is,
let's
say
more
accurate
to
the
to
the
spec.
C
But
I
understood
forecast
from
carson's
presentation
that
actually
the
first
one
will
be
more
better
fit
from
zebra
point
of
view.
Yeah.
The
first.
E
B
So
that
was
my
poetic
license.
If
you,
if
you
will,
I
took
the
open
api
schema
and
translated
into
cyborg,
basically
the
the
the
way
it
is
right
now,
but
you
know
knowing
that
you
know
I
was.
I
was
making
that
choice,
but
it
seemed
to
me,
like
you,
know,
the
normal
choice
to
do
in
in
this
kind
of
environment.
So
it
really
depends
whether
you
want
this.
You
know
one-to-one
parity
or
not,
which
you
know
tails
into
the
the
discussion
around
where
where's
type
right.
C
C
But
you
know,
if
you
justify
the
way
you
have
done
in
the
presentation,
I
think
you
can
keep
the
the
one
you
like,
okay,
the
second
one
is
just
to
clarify
for
3gbp
folks
that
are
checking
this
pic.
C
A
C
The
technical
issues
I
would
like
to
know
more
or
less
that
I
mean
the
timeline
is
for
june.
So
how?
How
are
we
going
to
be
doing
this
in
the
coming
well
in
the
next
week
or
so
like
we
do
in
parallel?
We
confirm
that
we
check
with
francesca
right
and
she
does
the
80
part
in
parallel
and
is
there
anything
else.
E
G
C
I
will
have
a
last
look
if
that's
okay
on
the
last
version
on
the
editorial,
the
editor's
view
yeah,
I
can
do
it
today
or
friday
yeah
and
if
anybody
else
wants
to
have
a
look,
maybe
there
is
more
comments
coming
I
don't
know
I
would.
I
would
just
like
not
to
get
stuck
on
this
kind
of
like
little,
whether
we
use
array
or
object,
or
something
like
that,
like
that,
that's
my
hope.
A
Okay,
if
there's
nothing.
A
F
F
Basically,
I
think
we
repeat
a
couple
of
these
things,
sometimes
so
in
the
figure
on
the
right,
you
can
see
an
example
situation,
so
the
black
arrows
come
first.
So
it's
a
request
that
the
client
makes
the
proxy
proxy
performs
the
group
communication
requests
and
then
unicast
responses
are
sent
back
by
the
servers
and
then
collected
by
the
proxy
and
sent
back
to
the
original
client.
F
So
what
we
defined
for
this
here
there
was
a
problem
for
how
long
the
proxy
should
wait
to
collect
and
then
forward
these
responses.
So
we
address
that
with
a
new
co-op
option,
multicast
timeout
and
that
option
is
also
removed
by
the
proxy.
F
F
We
also
define
how
a
group
group
score
can
be
used
for
security,
also
for
the
situation
that
there
is
a
proxy
in
between
and
yeah.
We
also
have
a
pointer
here
to
another
draft,
so
that
was
core
capable
of
proxies
draft,
and
that
has
more
details
on
the
security
between
the
client
and
proxy.
If
you
use
oscor,
so
you
get
a
kind
of
oscor
within
oscor
type
of
security.
In
that
case,.
F
So
that's
the
short
summary
of
the
topics
yeah.
What
we
address
here
now,
I'm
going
to
talk
about
about
updates
since
the
last
version
that
was
presented,
so
that
was
version
5..
This
was
an
interim
presentation
and
we
did
already
earlier
submitted
version
6
before
the
itf
meeting,
but
this
wasn't
presented
yet.
F
F
The
length
of
the
uint
is
used
in
seconds
is
now
four
bytes
and
we
also
made
updates
for
the
response
forwarding
option
so
there's
some
changes
in
the
semantics
of
the
port
number.
So
basically,
the
proxy
will
provide
back
information
related
to
the
port
number
of
the
server
and
yeah.
Now
it
can
be
represented
in
a
more
compact
form.
Basically,
so
it
can
be
a
null
or
it
can
be
completely
absent.
So
in
that
case
the
the
data
element
is
completely
left
out
from
the
cbor
array.
F
So
for
now
we
have
the
semantics.
Now
that
it's
basically
the
same
port
as
the
destination
port
number
that
was
used
in
the
group
request
and
absent
means
that
it's
the
default
port
number
for
the
transport
protocol
that
was
used
in
the
group
request.
So
currently,
this
will
be
5683
because
we
only
define
the
co-op
scheme
for
multicast
group
requests,
but
this
can
be,
of
course,
for
other
schemes.
It
can
be
used
in
the
same
way
in
the
future.
F
F
And
in
this
case,
you
can
see
a
reverse
proxy
can
act
as
a
as
if
it's,
what
is
an
origin
server
so
and
it
can
be
specific
to
an
application
domain
as
well.
So
in
that
case,
it's
logical
that
it
could
have
a
default
timeout
as
well,
so
the
proxy
basically
determines
its
timeout
for
accepting
the
responses
to
a
request,
and
in
that
case
the
client
can
also
omit
omit
the
multicast
timeout
option.
F
F
And
this
should
be
okay
in
that
situation,
because
the
proxy
is
expected
to
apply
a
security
and
authentication
of
clients
so
that
it
will
they
will
have
a
relationship
set
up
and
configured
so
that
same
relationship
can
be
used
to
also
make
sure
that
the
client
is
aware
of
this
situation.
F
F
So
we
have
yeah
basically
put
a
note
in
there
and
I'm
not
sure
marco
has
any
further
details.
You
want
to
say
about
this.
F
So
then
the
final
slide
for
the
updates
that
were
made.
There
was
a
new
example
added
regarding
a
reverse
proxy,
so
we
have
that
in
the
appendix-
and
this
is
a
bit
different
than
the
existing
examples
we
have
now.
So
this
requires
one
basically
adders
as
a
proxy,
so
an
ip
address
in
the
past
examples
where
things
were
done
in
a
different
way.
F
You
could
have
yeah
like
something
like
one
headers
per
group
in
this
case
or
you
need
an
address
per
server
in
the
group,
and
this
is
of
course,
less
scalable,
because
you
need
lots
of
ip
address
addresses.
So
now
we
have
proxy
reciting
and
one
ip
address
and
the
request
target
is
expressed
within
the
uri
path
and
it
uses
the
format
from
rfc
8075.
F
F
F
So
other
updates
we
have
made
are
to
consider
http
to
co-op
reverse
proxy.
So
that's
in
section
9.10
and
there's
also
to
do
placeholder
notes
there
discussing
okay,
that
you
can
have
streamed
delivery
of
responses.
So
client
talks
to
the
proxy
in
http
and
then
you
can
use
the
streaming
using
the
transfer
coding
chunks.
You
can
basically
send
the
chunk
each
time
a
co-op
response
comes
in
to
the
group
request.
They
can
send
it
back
to
the
client.
F
E
The
problem
is
that
you
might
have
an
http
proxy
that
re-re-jungles
your
transfer
coding
chunks,
so
you
cannot
rely
on
the
chunks.
The
trunk
boundary
is
making
it
to
you,
so
you
have
to
have
something
in
there
that
actually
provides
steady.
Limiting.
I
mean
that
there
are
obvious
ways
of
doing
that,
but
you
have
to
choose
one.
F
G
F
F
And
I'm
moving
to
the
next
slide,
so
there's
a
sort
of
summary
slide.
We
have
here
of
the
current
features
at
the
glance,
so
some
little
bit
of
repetition
here,
but
we
have
basically
solved
the
issues
as
highlighted
in
the
core
group
on
this
there's
the
signaling
protocol
that
we
started
with,
and
we
basically
deal
with
caching
of
responses
at
the
proxy
in
this
draft,
and
there
is
basically
two
types
of
response:
validation
that
that
can
happen.
In
that
context,
that's
also
addressed.
F
It's
maybe
good
to
note
that
the
one
revalidation
between
the
client
and
the
proxy
we
have
a
new
co-op
option
for
that.
So
that's
the
group
etag,
so
it's
kind
of
a
validation
of
an
entire
group
response
at
once.
F
F
So
that
that's
why
we
mainly
focus
here
on
what
what
does
the
yeah,
the
caching?
What
is
the
caching
that
the
proxy
itself
has
to
do,
or
are
there
special
rules
for
that
and
when,
when
our
entries,
invalidated,
etc,.
F
And
we
consider
now
the
not
only
the
forward
proxies,
but
also
reverse
proxies,
so
that
was
added
later
on
and
also
the
http
to
co-op
case
is
considered
as
well
as
chains
of
proxies,
so
multiple
yeah,
basically
multiple
proxies
that
can
can
be
chained
together.
F
F
So
basically
we
we
are
in
this
in
this
case,
of
course,
so
we
have
a
client
making
a
single
request
to
the
proxy
and
then
getting
multiple
responses
back.
So
this
is
kind
of
one
case
of
that,
and
here
we
have
the
multicast
timeout
option
to
basically
provide
a
time
indication
to
the
proxy.
So
how
long
should
it
collect
and
yeah?
Basically
there's
the
draft
on
score
capable
of
proxies.
F
F
So
I
said
we
addressed
the
issues
from
coupon
biz
and
now.
Basically,
this
draft
is
providing
solutions
to
that
and
now
carson
provided
a
working
group
last
call
review
of
group
from
this
also
pointing
out
to
the
relation
between
these
documents.
So
we
basically
point
to
the
present
document
from
group
convis
to
address
these
proxy
issues,
and
so
we
also
refer
to
the
google
proxy
document.
F
F
So
there's
a
couple
of
things
we
still
want
to
do
here,
so
there's
an
alignment
that
can
be
made
with
terminology
and
concepts
specifically
from
the
core
responses
draft
and
in
the
options
now
we
use
basically
to
indicate
the
address
and
port
etc
of
the
server.
We
use
a
custom
format,
but
we
found
that
cris
can
also
be
used
for
that
as
a
more
maybe
more
standard
way
of
including
that
addressing
information.
F
So
that's
something
we
are
considering
to
to
add.
Next,
one
thing
is
cancellation,
so
this
is
not
considered
yet,
but
should
it
be
handy
if
clients
have
a
way
to
stop
the
proxy?
So
if
it's
collecting
for
a
particular
time,
is
there
also
a
way
to
cancel
that
so
before
the
timeout
expires?
F
Still,
I
need
to
think
about
that.
I
think
and
of
course,
the
part
I
mentioned
the
text
for
http
to
proxies.
That
is
not
not
yet
complete,
just
the
placeholder.
We
need
to
work
on
that
as
well,
and
while
we
do
that
for
http
to
co-op,
we
can
also
add
security
considerations
that
are
specific
to
the
group
case,
because
that's
those
were
not
yet
in
rfc8705.
H
I
just
wanted
to
make
kind
of
a
general
comment
that
I've
been
yeah
following
the
work
on
this
draft
and
I'm
also
actually
working
on
an
implementation
where
I'm
trying
to
set
up
a
forward
proxy
that
can
forward
a
unicast
request
from
a
client
to
multiple
servers
using
unicast,
so
using
multicast
according
to
how
things
are
refined
in
this
document,
and
I've
come
part
of
the
way
for
that
implementation,
and
this
is
also
based
on
the
work
I've
been
doing
in
the
california
co-op
library,
where
I
have
also
worked
on
oscar
and
groupos
core
support.
H
So
as
a
further
step,
I
want
to
enable
on
this
proxy
also
a
group
of
course
group
score
between
the
proxy
and
the
servers.
So
I
just
wanted
to
mention
that
as
a
as
a
piece
of
information.
G
Okay
and
then
christian
yeah,
thanks
for
this,
I
have
two
points.
I'd
like
to
come
back
to
could,
could
you
go
to
slide
five
yep
yeah
I've,
I
gotta
admit
I
missed
the
dash
of
five
version,
so
this
was
rather
new
to
me.
I
don't
think
that
having
a
default
on
a
reverse
proxy
is
such
a
good
idea,
because
a
reverse
proxy
will
might
not
need
much
custom
configuration
by
the
client,
because
that's
just
how
reverse
proxies
are
set
up.
G
I
think
this
should
be
more
a
matter
of
negotiation
and
possibly
advertisement
that
this
these
resources
there
are
are,
might
there
might
be
multicast
behind
it,
so
that
the
client
would
send
a
multicast
timeout,
because
if
the
server
sends
multiple
response
and
the
client
did
not
ask
for
them,
then
this
is
asking
for
for
token
disagreement,
so
the
clients
might
use
shorter
tokens
on
requests
where
they
expect
the
response
to
be
sufficient
and
longer
tokens
for
observations,
and
that,
like
so,
if
this
thing
these
things
get
out
of
sync,
I
think
that's
problematic.
G
So
I
think
it's
better
to
think
about
advertisement
here,
rather
than
than
defaults
and
micro,
I
wrote
some
of
this
up
already,
so
you
can.
You
don't
have
to.
F
Type
down
again
yeah,
so
so
it's
like
like
well
default
is
maybe
not
the
right
word
than
that.
It's
like
timeout,
determined
by
the
proxy
right
now.
G
Even
then,
if
it's
like,
if
the
proxy
sends
responses,
multiple
responses,
even
though
the
client
didn't
ask
for
it
that
I
think
that's
problematic,
so
if
request
comes
into
multicast
proxy,
then
the
safer
thing
might
be
to
say:
yeah,
sorry,
there
is
no
single
answer
or
anything
that
like
and
not
to
just
send
multiple
responses,
and
I
think
carson's
plus
one
on
the
chat
was
meant
for
this
comment.
F
Yeah,
I
think
I
must
say
I
don't
fully
understand
this,
because
what
we
have
here
is
not
just
a
random
client
going
to
random
resource
and
expecting
one
response.
G
F
Yeah
and
that's
what
we
basically
basically
want
to
enable
that,
so
it
it
looks
like
a
regular
server,
but
but
the
client
in
this
case
knows
basically
knows
already:
it's
not
a
regular
server.
F
I
think
that
I
would
have
to
say
that
I
mean
maybe
it
uses
a
particular
yeah
particular
resource
structure
that
is
determined
by
by
an
application
or
application
ecosystem
and.
E
The
problem
I
are
having
is
the
same
thing,
the
the
you
cannot
really
make
the
the
workings
of
of
the
state
machine
of
the
protocol
depending
it
depends
on
context
information
that
may
be
unevenly
distributed.
E
So
the
specific
thing
that
broke
me
up
here
was
that
christian
mentioned
token
retirement,
and
if,
if
I
send
a
request
to
someone
and
get
the
response,
then
I
might
want
to
reuse
that
token,
but
if
I'm
still
waiting
for
more
responses
to
my
original
request,
that's
not
so
great.
So
I
really
need
to
know
whether
what
I
just
did
is
is
going
to
get
me.
One
response
or
multiple
responses.
F
Maybe
you're
thinking
on
the
protocol
level
there.
So
that's
it's
kind
of
you
can
say.
Maybe
it's
independent
from
from
what
application
resources
are
being
used.
The
the
clients
I
said
called
clients
at
the
protocol
level
must
be
generating
the
right
tokens
as
well
and
then
yeah
and
and
we
don't
yeah,
we
don't
want
to
run
possible
risk
that
this
co-op
client
is
unaware
of.
Let's
say
the
group
comproxy
graph
and
then
uses
the
wrong
token.
For
example,.
F
Yeah,
so
in
that
case,
what
it
could
do
is
it
acceptable
if
it
would
include
the
option,
but
without
the
value,
let's
say
so,
it's
like
saying
to
the
proxy
you
choose.
I
think
that
that
could
be
still
an
option.
Then
a
client
may
not
know
necessarily
at
the
co-op
level.
It
doesn't
know
how
long
it
will
receive
responses
and
that
that
maybe
doesn't
matter
at
the
co-op
level
at
application
level.
G
One
might
certainly
consider
having
having
a
some
some
value
that
indicates
undefined,
but
again
this
this
might
this
might
go
through
this
might
go
through
process
in
between
and
if
it
that's
information
from
the
application,
then
that
application
that
information
is
not
available
to
other
proxies
on
the
path.
So
I
think
it's
better
to
be
explicit
here.
F
Yeah,
that's
basically
for
the
chain
case
you're
saying
that
if
the
information
is
included,
then
the
chain
can
properly
process
that
and
then
keep
the
state
for
for
exactly
that
time,
as
indicated
right
so.
G
If,
if
a
reverse
proxy
receives
a
request
that
doesn't
have
a
multicast
timer,
there
is
still
kind
of
there
are,
there
are
still
different
options,
and
that
and
those
will
depend
on
the
configuration
of
the
proxy.
So
that
might
be
something
like
sorry
show,
show
an
error
because
and
just
tell
them
in
plain
text
but
sorry
this
is,
you
have
to
be
multicast,
or
I
can
tell
you
something.
This
might
be.
G
The
multicast
might
really
be
more
of
an
anycast
and
it
might
be
in
this
particular
application,
which
is
configured
for
the
reverse
proxy
okay
to
just
send
whatever
comes
first
or
do
something
more
application.
Specific.
F
E
G
Could
you
elaborate
a
bit
on
on
on
why
why
these
why
the
address
gets
packed
into
the
I
mean-
and
I
know-
and
I
understood
this
a2
807
5
construction-
to
be
relevant
really
for
cases
where
a
proxy
doesn't
work
like
a
protocol
independent
proxy
as
we
have
it
in
co-op,
but
just
like
an
http
proxy
that
can
only
work
with
http
uris,
so
that
gets
cram.
So
the
address
gets
crammed
into
the
path.
G
What's
what's
the
problem
here
really
because
we
already,
we
also
have
the
uri
host.
So
the
request
could
indicate
the
group
in
the
uri
host
and
then
come
back
from
from
from
any
resource.
F
Yeah,
that's
basically
thinking
about
you
could
use
the
forward
proxy
for
that
right.
If
that
may
be
no.
G
You
can
you
you
can
have
a
uri
host
option,
even
in
both
in
a
forward
and
a
reverse
case,
so
especially
in
the
reverse
case
that
that
that
server
could
sit
on
one
ip
address,
but
have
all
its
groups
advertised
as
different
names
which
all
resolve
to
that
address
and
when
the
request
gets
sent
there.
The
request
contains
the
uri
host
option,
which
then
the
reverse
proxy
translates
to
whatever
the
multicast
or
any
cast
or
broadcast
address
on
that
medium
is
which
really
depends
on
on
that
precise
reverse
proxy.
F
Oh
yeah
and
I'm
wondering
about
that,
because
we
had
similar
these
questions
be
before
in
convince
about
using
the
uri
host
options,
for
particular
things
yeah.
I
think
you
do
run
into
a
problem,
then,
with
the
co-op,
uri,
encoding
and
decoding
process,
so
because,
if.
F
G
Maybe
let's
revisit
that
offline,
but
I'm
pretty
confident
that
uri
host
is
the
right
space
here
and
that
if
you
start
cramming
things
up
into
the
uri
path
option,
then
things
like
relative
reference
resolution
in
responses
get
really
weird.
F
C
E
Yeah,
if
there
are
no
other
technical
comments,
christian
took
a
little
bit
anticipated
a
little
bit.
What
I
was
going
to
say
so
I
watched
the
conversation
and
these
all
look
like
things
where,
where
we
are
doing
the
usual
tweaks,
that
the
working
group
does
when
working
on
a
working
document-
and
it
seems
that
we
do
agree
on
the
fundamental
approach
that
this
specification
is
taking,
and
it
also
looks
to
me
that
we
do
have
energy
for
working
on
this.
E
So
I
think
all
the
the
prerequisites
to
doing
regular
adoption
call
are
there
and
are
we
waiting
for
anything
specific
with
a
working
redemption
goal?
Should
we
simply
do
that
now.
F
Yeah,
I'm
not
waiting
for
anything
specific
now
and
now
there
is
indeed
still
energy
now,
so,
let's
hope
after
group
convince.
We
still
have
that
energy.
E
Good
marco
is
a
coarser
and
the
the
other
coach
here
has
dropped
out.
So
maybe
we
cannot
answer
that
question
right
now,
but
I
think
the
chairs
should
look
at
this
question
and
and
decide
whether
to
do
a
working
production
call
very
soon.
F
F
A
Okay,
then
we
get
into
a
b
territory
yeah.
I
just
wanted
to
to
make
a
reminder
that
we
actually
have
another
documenting
working
group
was
called.
The
original
plan
was
until
today,
it's
conditional
attributes,
but
as
far
as
I
could
see,
there's
only
my
own
review
on
the
list
that
I
sent
yesterday.
So
we
clearly
need
more
feedback
before
closing
the
working
group
last
call
and
proceeding
and
what
you
have
read
the
document.