►
From YouTube: IETF103-CDNI-20181106-1120
Description
CDNI meeting session at IETF103
2018/11/06 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
C
A
A
So
chairs
are
Kevin
whose
remote
and
myself
and
Francois
we
have
one
session
it's
just
today
and
just
in
this
room,
I
already
have
minute
takers
minute.
Taker
I
already
have
jabber
scrub
and
blue
sheets
are
going
around.
So
this
is
the
note,
well
I'm
sure,
you've
seen
this
as
everybody
like
to
say,
please
note
it
well,
anything
you
say
in
here
is
a
contribution.
So
all
right.
A
Here's
our
agenda
for
today
the
agenda,
bashing
and
introduction
from
chairs
a
document
status,
update,
I'm
gonna
talk
about
URI
signing
for
a
little
bit,
and
then
we
will
Frederic
will
talk
about
HTTP
delegation
and
then
orys
going
to
talk
about
the
SV
AOC
drafts,
one
of
which
is
now
a
working
group
document
and
then
we're
going
to
talk
a
little
bit
about
reach
are
during
at
the
end
and
if
we
need
to
or
not
and
conclusions
the
next
steps.
So
before
we
go
any
further,
is
anybody
wanna
bash
this
agenda?
Oh.
B
B
On
the
next
slide,
we
have
our
beyond
working
group
milestones,
CD
NIH
DPS
delegation,
which
Frederick
is
going
to
talk
about,
and
we
have
an
adoption
call-out
currently
which
it's
looking
like
we're,
probably
going
to
get
an
adoption
there.
The
CD
and
I
request
drawing
extensions
as
Phil
just
mentioned.
We
did
adopt
that
and
then
there's
the
CD
and
eye
control
interface
triggers
extensions,
which
last
time
we
discussed,
might
need
a
charter
update.
But
we
will
talk
about
that.
B
At
the
end,
we
will
be
adding
milestones
for
the
new
documents
that
are
not
currently
that
have
been
adopted
or
will
be
adopted,
but
are
not
currently
milestones
and
we're
not
currently
pursuing
the
rate
pacing
at
this
time.
Unless
someone
in
the
working
group
has
a
strong
feeling
about
the
need
to
add
rate
pacing
metadata,
so
next
slide.
A
A
There
we
go
much
better,
alright,
so
right
now
we're
sitting
on
draft
16.
That's
that's
been
that
was
uploaded
right
before
the
deadline,
so
we
had
another
one
15
that
was
just
there
was
a
small
goof
in
it.
So
I
just
did
a
16,
so
basically
the
changes
since
14
added
the
critical
claim
set.
This
is
something
we
talked
about
in
Montreal.
A
We
also
talked
a
lot
about
the
sign
token
death,
and
this
was
actually
what
took
the
longest
I
took
the
most
amount
of
work
to
get
right.
So
we
had
some
conversations
in
Montreal
and
on
the
mailing
list
and
on
the
issues
about
this
and
the
the
final
consensus
on
it
was
that
we
would
go
sign
token
depth.
So
I
didn't
hear
any
more
issues
on
that,
so
I
merged
that
one
in
removed
the
simple
URI
container
that
was
non-controversial
that
we
talked
about
in
Montreal
and
some
small
knits.
A
D
A
E
A
D
The
second
thing,
I
actually
opened
a
pull
request,
yes,
github
and
made
a
comment
on
the
mailing
list.
I
found
in
practice.
403
is
not
always
the
best
answer.
Sometimes
when
the
token
is
out
of
date,
there
is
a
value
in
redirecting
the
client
to
somewhere.
They
can
get
a
better
token
or
have
a
more
useful
error
message
or
really
a
whole
bunch
of
different
use.
Cases
I
think
the
the
language
I
put
up
is
a
potentially
simple
way
to
handle
that.
D
A
D
So
the
idea
is,
if
your
token
is
bad,
we
want
to
know
normally
we
just
send
you
a
403,
but
if
your
token
is
bad
in
some
cases
we
want
to
send
you
back
to
where
you
can
get
a
good
token
or
maybe
an
alternate
version
of
the
content
that
doesn't
require
the
token
or
some
fallback
a
whole
bunch
of
use
cases
that
came
up
in
practice.
But
we
can't
allow
that
to
happen
if
the
token
is
not
signed
properly,
because
otherwise
we
allow
an
amplification
attack
exactly.
A
Yeah,
so
that's
what
I
was
trying
to
point
out
so
there
there
was
no.
There
was
no
other
feedback
on
that.
So
I
don't
know
discussion
yeah.
There
was
no
discussion
on
the
mailing
list
and
no
discussion
on
the
issue.
I've
prodded
some
people
to
see
if
we
could
get
some
feedback,
but
I
I,
don't
know
so.
My
my
feeling
on
it
is
that
it's
it's
kind
of
an
over
complication,
but
I'm
not
opposed
to
getting
it
in.
A
It
just
seems,
like
I,
think
I
feel
like
we
discussed
it
at
some
point
and
we
said
wow.
This
is
this
is
gonna,
be
a
lot
of
extra
detail
to
put
in,
but
since
you've
already
done,
the
wording
I
think
it's
worth
talking
about,
but
I
would
love
to
hear
more
feedback
on
that
and
whether
or
not
we
need
to
add
that
before
working
group
last
call
or
not.
So
that's
that's
my
thoughts
on
it
agreed.
D
B
D
A
as
I
have
it
currently
worded,
it's
a
pair
of
optional
claims,
a
one
claim
for
what
code
to
return
and
one
claim
for
what
what
the
location
parameter
should
be,
and
the
goal
is
to
make
it
as
simple
as
possible
for
implementers
to
handle.
So
it's
an
optional
claim
on
signing,
but
processors
must
implement
it.
D
A
Other
my
other
concern
about
it
is
having
to
have
enough
state
to
be
able
to
have
continuity
for
the
user.
So
if,
if
you
redirect
them
back
to
some
sign-in
page
or
whatever,
there's
got
to
be
enough
context
in
that
URL
that
you
in
that
URI
that
you
redirect
them
to
to
also
then
get
them
back
to
where
they
were.
So
it's
not.
It's.
D
D
A
D
D
A
D
A
little
bit
higher
I
don't
see
a
way
around
that
because
the
receiver,
a
receiver
and
a
parser
of
the
token
has
to
be
able
to
accept
anything
any
valid
token.
That's
handed
to
it
right,
there's
no
way
for
a
receiver
to
say:
I
only
implement
half
the
spec,
so
if
we
put
it
in
their
receivers,
have
to
have
to
be
able
to
accept
it.
Although
a
signer
is
obviously
allowed
to
implement
any
subset
of
claims
that
it,
it
feels
is
useful
for
its
use
case,
but.
D
And
there
may
be
security
reasons
why
one
CDN
or
another
use
case
may
choose
to
refuse
to
do
so
right
right.
It
might
feel
that
for
for
excuse
case
leaking
that
information
is
as
a
security
concern,
and
so
it's
going
to
to
refuse
to
comply,
and
certainly
an
implementation
needs
to
have
the
flexibility
to
define
their
own
policies
around
exactly
what
they
do
once
they
understand
it.
B
A
C
A
Don't
have
any
other
actions,
it's
not
blocking
on
anything
so
waiting
a
week
or
two
for
people
to
talk
about
it
and
I.
You
know
if
we
decided
to
go
with
it,
I
merge
it
and
make
a
17.
If
not
you
know
you
can
you
can
still
start
a
Shepherd
review
or
whatever
on
it.
If
that's
the
direction,
we
think
we
want
to
go
with
it.
So
I
I,
don't
I,
don't
think
we
have
to
decide
it
right
now,
but
I
think
that's
kind
of
my
feelings
on.
It
is
I'm
kind
of
minus
zero.
B
Right
I'm,
I'm
gonna
propose
as
the
chair
that
I'm
gonna
go
ahead
and
do
the
Shepherd
review
on
version
16
and
there's
gonna
be
some
period
of
time
where
I'm
that
we're
going
to
give
me
to
do
that
and
during
that
time.
If
we
want
to
discuss
this
new
pull
request,
we
can,
if
we
decide,
we
want
it
and
there's
support
for
it.
Then
we
can
add
it
in.
If
not,
then
we
can
move
forward
with
16.
B
F
F
A
B
Thoughts
on
that
I
think
I,
agree.
I,
think
we've
seen
a
lot.
We
can
do
a
hum
if,
if
people
would
like
I
think
the
draft
looks
good.
The
updated
draft
I
sent
you
a
couple
of
comments
Fredrik
on
the
list,
but
if
you
want
to
take
care
of
those
before
in
the
next
Rev,
when
you
switch,
do
we
want
to
go
ahead
and
just
do
a
hum.
I
could
definitely
do
one
all.
A
B
D
A
All
right,
please
hum
now,
if
you
would
not
elect
like
to
adopt
this
draft
all
right.
That
was
pretty
clear.
There
were
there
were
no
hums
against
adoption
and
quite
a
few
for
adoption,
so
I
think
the
the
mailing
list
will
leave
it
to
the
end
of
the
week.
I
just
want
to
give
it
enough
time
to
give
everybody
a
chance
to
get
feedback,
but
I
think
it's
good
to
go.
Okay,.
A
G
G
D
G
The
first
path
segments-
and
there
was
a
proposal
from
Kevin
I-
think
that
we
might
consider
instead
of
having
those
explicit
fields
having
some
kind
of
an
area
of
construction.
So
this
is
kind
of
a
question
for
this
forum,
if,
if
you
think
it's
more
appropriate
to
have
something
which
is
more
generic,
because
maybe
an
F
instead
of
this
object,
so
basically
that's
it
Kevin.
Maybe,
since
you
proposed
that,
maybe
you
can
share
your
view,
I.
B
B
C
About
a
B
and
F
I
haven't
read
the
document,
so
I
probably
shouldn't
voice
an
opinion,
but
this
is
the
type
of
comment
I
might
raise
during
very
direct
this
review.
So
I
hope
it's
not
you
know,
but
this
you
know
if
it's
unclear
I
will
I
will
tell
you
basically
I,
don't
think
it's
going
to
be
big
deal
either
way.
Okay,.
G
Thanks,
so
maybe
a
general
question
before
I
move
on
to
the
triggers
is
that
we
have
multiple
new
ideas
for
new
metadata
objects
and
footprints
or
object
the
same
as
in
this
document,
and
the
question
is:
how
do
we
have
introduced
more
numerated,
a
data
objects
in
their
footprints
as
they
come
along.
Should
we
have
different
and
separate
drafts
for
each
and
every
one
or
what?
What
do
you
think
should
be
the
way
to
go?
I.
B
I
tend
to
think
it
depends
on
how
quickly
you
want
to
get
these
through.
We
can.
We
can
do
them
as
individual
drafts.
If
you
have
them
all,
and
you
know
what
they're
going
to
be
and
you
want
to
get
them
all
out
together.
It's
it's
a
little
bit
less
work
on
our
side
to
have
to
push
a
one
draft,
as
opposed
to
five
drafts
through
right.
B
H
Think
yeah
I
this
a
Sanjay,
Mishra
I,
agree
with
Kevin
I
think
it
may
be
just
easier
to
work
on
these
individually,
just
so
that
you're
focused
on
what
the
topic
is
and
what
we're
working
on
so
we're
not
holding
up
on
lot
of
different
different
things,
and
then
you
know
if
we
have,
if
you
feel
like
we
have
multiple
drafts,
you
know
it's
easy
to
combine
it
that
at
some
point
later
on.
Okay,
thanks.
B
G
G
We
added
the
ability
to
select
the
content
that
the
children's
to
using
regular
expression
or
video
playlist,
and
we
added
the
ability
to
add
the
generic
extension
objects
that
pretty
much
like
the
metadata
generic
objects.
It's
kind
of
a
list
of
generic
objects
that
one
can
implement
or
introduce
new
new
types
of
objects
that
would
control
or
restrict
the
trigger,
depending
on
your
what
you
want
to
do,
and
we
introduced
the
first
two
generic
object.
G
We
were
requested
to
replace
the
ABR
protocol
type
with
a
media
protocol
type.
So
we
do
that
and
there's
an
issue
to
consider
and
I
bring
it
here
if
we
weaken
if
we
want
to
keep
on
handling
also
MSS
within
this
draft,
because
as
far
as
I
know,
when
it
says,
is
it's
not
being
used
also
entirely
in
the
industry?
So
maybe
we
should
just
keep
it
with
HLS
and
I.
Don't
have
any
strong
feeling
about
that,
but
maybe
others
do.
G
There
was
an
issue
of
implication
of
reg,
X
complexity,
attacks
and
I've
added
it
to
the
security
consideration
section.
One
more
issue
was
adding
the
ability
to
use
local
time
within
the
time
policy.
It's
kind
of
tricky
and
I'm
going
to
discuss
this
in
a
minute
in
a
moment
and
the
ability
to
propagate
errors
and
other
issues
from
all
these
things
along
the
trigger
delegation
path.
So
you
could
do
back
tracing
of
those
and
understand
where
the
problem
was
in
which
the
options
in
there.
G
So
adding
the
work
on
time
through
the
time
policies,
so
this
is
kind
of
tricky,
because
the
rationale
here
is
that
when
you
execute
the
trigger
things
like
repositioning
or
other
heavy
stuff,
you
might
want
them
to
happen
in
specific
time
slots.
But
since
CD
ends,
I'll
distribute
it
across
many
regions.
In
many
cases
you
may
want
to
do
that
in
specific
time
sorts,
but
in
local
times
of
those
regions,
not
in
your
car,
not
in
your
local
time
or
any
specific
time.
Just
like
saying,
I
want
to
do
that
between
2
a.m.
G
and
5
a.m.
in
your
specific
regional
time
so
currently
without
ads.
That
could
be
achieved
by
having
a
combination
of
time
policy
together
with
location
policy.
It
has
the
drawback
that
it
requires
multiple
triggers.
You
have
to
have
different
triggers
for
every
every
region
and
there
was
a
proposal
to
add
the
ability
to
have
a
local
time
flag.
That
indicates
exactly
what
you
want
execute
at
these
hours
at
your
local
time.
So
that
was
the
rationale.
G
Possibly
we
can
add
a
new
time
slot
object,
something
which
will
be
different
than
the
time
window,
and
the
question
is
how
exactly
to
represent
that
time
and
I
I.
Don't
have
a
good
answer
for
that,
because
if
we
follow
our
3:9
internet
time
since
there's
no
notation
for
your
local
time,
this
notation
for
UTC
and
there's
limitation
for
a
specific
there's.
Nothing
like
that
5:00
a.m.
at
your
local
time.
So
it's
kind
of
an
open
question
because
I
don't
have
a
good
answer
for
that.
G
G
B
C
I,
don't
know
of
any
anything
to
help
you
in
this
space,
so
I
think
inventing
your
own
is
fine.
As
long
as
it's
reasonable,
I,
don't
know,
it's
can
be
a
separate
boolean
attribute
or
you
just
do
variation
on
our
teeth.
3
3,
3
9,
just
for
your
force
no
times
on
case,
but
local
local
times
our
case,
because
you
have
very
specific
application.
Rejection
requires
this
most
applications.
A
B
Think
if,
if
we
can
borrow
as
much
as
we
can
from
33:39
as
far
as
the
formatting
there,
there
a
B
and
F
that
sort
of
thing
and
then
just
modify
it
to
whatever
degree
we
need
to
ignore
timezone
and
tell
tell
them
to
use
local
time.
We
can
make
it
as
close
as
we
can
and
then
maybe
somebody
will
want
it.
C
G
So
error
propagation,
so
we've
added
a
new
error
description
version.
Two
errors
may
happen
in
any
day
now
since
at
the
end
and
on
the
trigger
litigation
path.
So
this
was
kind
of
an
issue
even
before
introducing
the
extensions.
But
now
since
we
have
an
extensions
and
extensions
may
or
may
not
be
supported
by
different
and
options
in
the
ends,
it
becomes
more
of
an
issue.
G
Status
version
two,
so
a
recap:
we
already
have
the
status
version
two
from
the
previous
draft
provision,
because
we
have
a
trigger
v2
and
they
start
to
speak
to
include
the
trigger
e2.
Instead
with
children
and
now
the
trick
is
this.
A
status
version.
2
must
also
include
the
earliest
version.
2
of
the
error,
description.
A
D
A
B
B
B
B
A
B
Okay,
so
so
last
time
we
talked
about
the
need
for
recharging.
If
we
wanted
to
do
the
the
triggers
extension
for
those
who
were
there
back
in
IETF
84,
we
had
made
a
decision
not
to
pursue
any
type
of
hass
optimisation
used
to
be
adaptive
streaming
optimizations
at
that
time,
in
an
attempt
to
try
and
get
all
of
the
base
specs
out
quicker.
B
There
was
an
RFC
69
83
that
listed
out
all
of
the
pass
optimizations
that
were
considered
at
the
time.
Interestingly
enough,
pre
positioning
of
past
content
was
not
one
of
them.
One
of
them
was
retrieving
sim
files,
but
not
specifically,
pre
positioning
manifests
through
triggers,
and
so
it's
not
really
covered
there
in
terms
of
what
would
be
necessary
or
how
it
impacts
the
interfaces.
B
Our
existing
Charter
does
say
that
in
the
event
that
any
protocol,
extensions
or
new
protocols
are
necessary,
we
will
recharter,
and
so
we've
been
looking
at
the
Charter
and
we
discussed
it
with
Alexi.
The
Charter
itself
doesn't
preclude
us
from
doing
house
optimizations
to
the
triggers
interface.
We
have
existing
text
in
the
Charter
for
doing
a
control,
interface
and
and
adding
some
fields
to
make
it
more
HTTP
adaptive
streaming
seems
to
fit
within
that.
It's
not
in
any
of
the
things
we're
not
allowed
to
do
in
this
working
group
list.
C
Well,
I
was
he
have
no
objections.
I
read
the
way
protocol
extensions.
What
region
may
maybe
it's
ambiguous,
but
I've
I
thought
it
was
about
HTTP
extensions
and
because
young
you
know,
I
suppose
the
text
is
slightly
ambiguous,
but
you
know
it
allows
you
just
to
add
this
and
continue
working
I.
Think
that's
fine,
but
if
you
want
to
take
other
items
which
doesn't
clearly
fit
you
know
you
might
as
well
reach
other
ones
right.
It's
supposed
to
reach
out
to
multiple
times
right,
I.
B
Think
one
that
one
question
is,
would
we
want
to
tackle
any
additional
HTTP
adaptive
streaming
issues?
One
of
the
big
ones
was
manifest
rewrite
which
we're
not
doing
and
I.
Don't
think
that's
in
our
Charter
today
and
I.
Don't
know
if
this
is
leading
us
down
that
road,
but
just
simply
sending
a
URI
with
an
extension
of
m3u8
and
hope
and
expecting
the
downstream
CDN
to
understand
it
and
support
it.
I,
don't
think,
is
terribly
far-fetched
for
what
the
triggers
interface
was
intended.
H
Just
a
quick
question
here
on
the
text
that
you
have
now
when
we
say,
submit
enhanced
CDN
a
control
interface.
Should
the
word
enhanced
be
qualified
as
to
what
what
specifically
the
the
Charter
would
include
so
that
the
reader
understands.
You
know
what
the
the
new
Charter
is
actually
going
to
be
inclusive
off,
because
enhanced
by
itself
is
not
giving
quite
a
to
a
reader
as
to
what
what
it
is
that
we're
looking
to
do.
B
No,
no,
so
there
will
be
other.
There
will
be
separate
as
charter
of
miles
separate
milestones,
added
for
the
other
documents,
and
once
we
adopt
HTTP
delegation
once
we
adopt
her
and
for
the
request
routing
those
are
just
additional
metadata.
Those
have
always
been
considered
something
we
would
do
right.
The
meditator
interface
is
there
and
it
is
extensible
and
we
agreed
to
be
the
you
know,
standardizing
body
for
new
metadata,
so
within
the
context
of
what
they
currently
contain.
A
E
A
A
A
A
A
B
A
B
I
A
Yeah,
just
just
to
summarize
we're
not
shutting
down
the
chartering
discussion
indefinitely.
It's
just
that
we
for
the
documents
that
we
currently
have
that
we're
talking
about
adoption,
for
we
don't
need
to
so
in
the
future.
If
something
comes
up
and
we
we
want
to
reach
Artur
for
it,
we
can
reopen
that
discussion
and
talk
about
it,
then,
but
as
of
right
now,
there's
no
concrete
documents
out
there
that
we
think
we
need
to
reach
our
tour
for
so
all
right.
Amigo.