►
From YouTube: IETF100-CDNI-20171116-1810
Description
CDNI meeting session at IETF100
2017/11/16 1810
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
B
B
B
A
A
Okay,
so
drop
to
draft
13,
lucky
number
13,
here's
what
we
changed
on
here.
We
added
a
registry
for
CD
ni
s,
TT.
That
was
to
do
support
so
that
they
could
add
different
values.
In
that
we
added
back
the
text
about
the
key
usage
symmetric
versus
asymmetric.
This
was
brought
up
on
the
mailing
list.
Relatively
no
big
deal
stated
that
key
distribution
is
out
of
scope.
I
also
went
and
made
the
HTTP
adaptive
streaming
support
more
generic
and
I
was
asked
to
not
call
it
token.
A
A
A
A
A
A
B
B
requires
a
kind
of
deal
or
we
could
put
it
in
the
actual
token
renewal
section
and
describe
that
to
properly
do
it,
you
need
to
have
both
so
it's
kind
of
a
trivial
change,
but
wanted
to
get
the
wording
right
for
it
number
30,
changing
subclade
to
CD
and
I.
You
see
and
introduced
new
sub
claim.
This
is
kind
of
related
to
number
28
and
I
have
exercise
about
this,
but
both
of
those
are
kind
of
unfortunate
parts
of
the
JWT
RFC
number
31
is
clarify
the
definition
of
parameter.
A
This
has
to
do
with
the
fact
that
query
parameters
are
not
actually
specified
anywhere,
they're,
just
kind
of
a
convention
that
everybody
uses.
So
we
figured
we
could
explain
how
we
intend
to
use
them
in
the
document.
Number
32
is
chicken-and-egg
problem
with
uri
containers.
This
is
how
we
need
to
specify
to
strip
off
the
uri
signing
parameter
before
we
validate.
A
I
think
it
was
something
that
we
kind
of
thought
was
obvious,
but
didn't
you
know
took
for
granted,
but
when
somebody's
implementing
it
they
need
to
need
to
know
that
and
limit
number
33
limiting
globs
in
the
URI
container.
So
let
me
go
on
to
the
next
ones
here,
so
replacing
the
odd
claim,
with
the
CD
and
IP
claim
this
all
this
laser
pointer
yeah.
A
So
this
is
from
the
JWT
spec
and
it
says
that
the
the
principle
intended
to
processor
JWT
must
identify
itself
with
a
value
in
the
audience
claim,
and
we
were
using
this
for
the
client
IP.
So
the
CDM
is
clearly
not
going
to
identify
itself
with
any
value
in
that
audience
claim,
and
it
says
if
it
does
not
do
that,
it
must
be
rejected.
So
there's
very
specific
usage
for
the
audience
claim
and
we're
just
kind
of
misusing
it.
A
A
A
A
A
A
A
Limiting
the
globs
in
the
URI
container,
basically,
the
glob
can
be
because
the
way
they're
specified
they're,
overly
greedy
and
you
can
make
them
match
a
URI
that
they
weren't
intended
to
by
adding
a
query
parameter
and
then
putting
the
matching
string
on
the
end
and
it'll
match
any
URI
on
the
front
end.
So
the
change
that
was
put
in
this
PR
from
Chris
made
it
a
bit
more
strict,
but
I
wanted
to
bring
up
the
issue
again
on
whether
we
need
this
container,
because
we
have
the
full
regex
support
there
was
there.
A
Was
we
added
the
regex
support?
The
feeling
was
why
get
rid
of
the
globs,
because
they
were
simpler
to
implement
and
simpler
on
CPU,
but
in
light
of
security
issues
and
ones
that
we
might
not
find
in
the
future.
I
was
just
wondering
if,
with
everyone
thought,
we
still
needed
this.
We
could
just
add
this
text
and
keep
or
we
could
remove
it
entirely.
E
Gently
yeah
gee
I,
assumed
this
is
the
simple
pattern
case
right
that
the
one
sir.
E
Okay,
the
microphone
yeah,
so
the
glob
that
you're
talking
about
this
is
a
simple
I
mean.
Basically,
there
are
three
cases
right.
So
this
is
not
the
red
X
all
right.
This
is
correct.
It's
a
simple
one:
okay
yeah,
like
he
said
I,
think
I
mean
I,
can't
sit
in
the
mailing
list
right,
it's
more
of
a
historical.
You
know
that
initially
we
had
something
well,
we
we
call
it
simple
right
for
the
reason
that
it
didn't
require
the
full
where
I
gets
and
all
that
stuff.
So
I,
don't
know.
E
A
I
think
it
was
the
original
one
and
then,
when
we
added
reg
X
we
said
well.
Is
there
a
good
reason
to
remove
this
one
and
I?
Don't
think
there
was
so
we
just
said
well,
why
not
we'll
give
people
the
option
it'll
be
in
the
draft?
People
can
implement,
implement
it
if
they
want
or
use
it
if
they
want,
but
now
it
seems
like
there
might
be
a
reason
to
remove
it
and
I'm
I'm
kind
of
on
the
fence
on
it.
But.
D
D
A
Yeah,
so
he
did
some
research
because
it
wasn't.
He
can
correct
me
if
I'm
wrong,
but
he
did
some
research
and
there
wasn't
anything
specific
in
JWT.
The
JWT
RFC
I
didn't
find
anything
in
there
either,
but
he
looked
at
other
usage
in
other
RFC's
and
found
that
to
generally
be
the
case,
so
I
don't
think
that
that
was
anything
that
we
had
to
change.
But
if
we
wanted
to
be
in
line
with
the
way
other
people
used
it,
we
should
but
I
think
I.
D
A
A
B
B
If,
if
folks
are
okay
with
the
matrix
I,
don't
really
see
a
good
reason
that
we
have
to
keep
the
limited
glob
we
had
originally
done
just
to
make
it
simpler
our
end
and-
and
it
was
partially
because
we
decided,
we
didn't-
want
the
regex.
But
if
we're
gonna
take
the
regex,
then
I,
don't
really
personally
see
a
huge
point
in
keeping
the
other.
A
A
E
So
yeah
I
just
want
my
comment
that
I
think
there's
silence,
because
I
think
I
agree
with
pretty
much
what
what
you
present
it.
Basically
right.
It's
just
the
last
one
on
the
simple
as
lawanda
I
had
Olympic
on
the
fence
issue,
but
I
agree
what
I
think
they
wake
or
go
forth
right,
I
just
probably
create
you,
know,
delete
it,
publish
it.
Thank
you.
Yes,
one
last
chance
people
say
I,
don't
like
it
I.
Otherwise,
that's.
B
A
Well,
we
we
have
an
implementation
now
and
we
will
actually
so
the
the
use
case,
for
it
will
be
in
February.
You
can
figure
out
what
that
might
be
Comcast
NBC,
so
I'll
be
able
to
publish
after
we
get
real
usage
and
and
before
London,
and
so
in
London.
I
will
feel
really
good
about
saying
yes
and
right
now,
I
would
say
I'm
really
optimistic
about
saying.
Yes,
all.
B
B
E
E
C
So
I
will
start
with
providing
some
insight
of
the
date
we
have.
Next
I
will
explain
what
which
you
bought.
We
we
I
did
for
the
delegation
methods,
particularly
on
ik
mister,
in
today's
subsets
draft.
Then
we
I
will
talk
about
the
definition
of
security
negation
metadata.
We
have
two
options
that
we
consider
in
this
draft
and
which
need
to
be
discussed
actually,
so
we
have
some
pros
and
cons,
and
finally,
we
consider
other
area
for
study.
C
So
to
record
a
bit
goal
of
this
document
is
to
propose
some
extension
to
the
c2c
dni
metadata
interface
to
exchange
metadata.
This
version
two
updates,
the
the
delegation
object.
We
we
defined
in
the
version
1,
so
we
in
the
version,
when
we
add
support
for
short
term,
automatically
renewed
certificate,
the
ik
mr.
draft,
and
in
this
version
we
consider
delegate
it
will
ensure
for
Tila
subsets.
So
the
JIRA
subset
draft,
which
has
been
recently
adopted
by
the
jealous
working
group,.
C
So
to
recall
a
bit
acme
star
draft
did
the
use
cases
that
you
CDN
delegates
delivery
to
the
CDN,
requesting
the
CA
to
issue
a
shortened
automatic
automatically
renewed
certificate,
and
we
hear
we
had
a
new
metadata
object
to
support
this
method,
basically
by
adding
some
properties,
namely
star
proxy
and
Acme
server.
So
these
two
proxies
to
properties
should
allows
the
CDN
to
contact
the
you
CDN
and
to
renew
politically
the
certificate.
So
basically,
this
could
be
used
at
initially
initialization
phase
and
at
the
renewal
phase.
C
So
here
we
add
a
new
metadata
object
to
support
this
method,
and
so
we
have
two
subsets
delegation
method
with
a
bunch
of
properties.
The
credential
delegating
entity,
the
credential
recipient
entity,
credential
location,
where
I
and
parody
city
and
those
property,
so
the
credential
delegating
entity
will
be
fine.
Stones
will
be
the
you
CDN.
C
C
One
important
object:
we
we
defined
also
is
the
secure
delegation
objects?
Why
do
we
need
such
an
object?
It's
because,
in
the
case
that
the
you
CDN
delegates
so
deliver
to
the
CDN,
we
need
to
convey
delegation
information
about
how
the
delegation
will
be
enforced,
and
to
do
so,
we
propose
to
model
to
the
two
options
that
could
also
you
see
the
end
to
describe
a
secure
delegation
for
the
CDN.
So
the
first
option
is
a
secure
delegation.
Object
define
as
the
top
object
so.
D
C
Means
that
we
try
here
to
specify
the
delegation
once
we
define
the
decision
for
all
pass
and
domain
of
the
city
and
interconnection
in
in
in
a
global
object.
But
currently
we
can
say
that
this
method
doesn't
exist
in
the
RFC
806
and
thus
it
requires
a
new
delegation,
a
new
object.
Here
we
call
we
call
security
Legation,
so
we
have
in
this
object.
We
have,
of
course,
the
delegated
domains.
We
have
the
past
patterns
that
are
concerned
by
the
weather
delegation
and
we
also
support
in
methods
a
delegation
method
for
the
further
delegation.
C
The
second
option
we
have
is
to
provide
an
extension
to
pass
metadata
that
is
already
defined
in
the
RFC
806,
and
this
methods
involve
the
definition
of
delegation
metadata
for
each
pass.
Url
of
the
delegates
identity.
So,
basically,
is
the
ideas
to
indicate
for
each
bus,
which
has
a
delegation
delegation
methods
that
are
supported
so.
C
C
So
we
consider
the
option
one
as
as
interesting,
because
we
can
provide
easily
information
about
the
delegation
in
one
shot.
But
drawback
is
that
it
extends
a
bit
the
CDN
cDNA
metadata
model.
So
maybe
it's
not
that
quickly
how
to
use
it.
For
now.
The
option
two
is
obviously
fits.
Obviously
inside
the
RFC
806,
but
the
drawback.
We
can
say
that
it
may
require
us
to
repeat
the
pass.
The
pass
dedication
metadata
for
each
pass,
so
maybe
it
could
be
more
greedy.
C
There
was
a
point
is
to
possibly
discuss
all
the
delegation
solution
for
cDNA,
so
here
we
have
listed
lakh
and
OB,
so
such
solutions
are
not
not
yet
accepted
in
the
IETF,
but
anyway
they
can
be
good
candidates
for
delegation,
and
we
have
also
the
next
presentation
that
could
be
used.
Also
interesting.
D
B
Can
can
I
insert
myself
yeah
I
I
also
think
that
listing
the
pads
in
an
object
versus
having
the
pads
listed
elsewhere.
I,
don't
know
that.
There's
a
lot
to
be
saved
there
I
agree,
you
could
link
it
and
where
to
save
on
the
object
itself,
but
it
seems
to
be
from
my
personal
opinion
as
an
individual
and
as
a
metadata
author.
It's
it's
making
a
custom
object
just
for
this
one
thing
and
that
wasn't
the
goal
of
the
metadata
interface
right.
B
We
tried
not
to
duplicate
that
data
like
past
data,
because
that
the
paths
apply
to
other
metadata
objects,
and
so
the
the
structure
of
it
would
be
significantly
changed
by
this
and
I'm,
not
sure
that
it's
that
it
is
a
change
in
a
good
way.
But
if
there
were
more
details
on
why
it's
why
it
would
be
necessary.
That
would
be
helpful.
B
F
Caching
is
so
maybe
we
can
go
to
right.
So
we'll
start
with
the
easy
stuff
just
a
bit
about
request.
So
the
first
thing
we
would
like
to
discuss
is:
how
do
we
discover
the
request
out
or
Alice?
Currently,
this
is
not
defined
by
CD
and
I,
and
the
second
one
is:
what
do
you
do
when
you
have
to
do
fall
back
from
the
D
CDN
back
to
the
you?
Cdn
looks
like
this.
F
So,
let's
start
with
them
request
I'll
to
address
so
there
are
quite
a
lot
of
use
case
is
why
we
need
that
two
of
them
is
that
we
want
to
have
different
request,
auto
addresses
for
different
footprints.
Some
CD
ends
have
global
or
nationwide
presence,
and
we
want
to
have
different
request
authors
for
a
different
location.
Another
use
case
is
scaling
by
adding
more
request
routers.
F
So
again,
this
should
be
by
footprints.
So
the
what
we
propose
here
is
to
add
a
new
FCI
object,
called
request,
auto
address
and
just
give
that
address
the
footprint.
All
our
proposal
here
are
not
very
fine-grained
I
think
we
can
discuss
a
lot
about
it,
the
syntax,
it's
just
very
initial
proposals
for
your
references
and
feedback.
D
F
F
F
Okay,
have
your
stuff,
so
content
management,
so
we
define
of
content
management,
all
the
stuff
that
has
to
be
done
on
content.
Basically,
that
means
per
evaluation
in
invalid
in
validation.
Everything
is
covered
by
RFC,
eight
zero,
zero,
seven,
so
I
think
new
here
from
the
operation
point
of
view,
but
along
the
way
we
found
that
we
need
to
add
more
stuff
to
the
art,
the
interface
or
to
the
RFC,
in
order
to
implement
everything
that
we
wanted
to
do
on
content
management.
F
So,
first
of
all,
the
RFC
proposed
on
the
global
pattern
matching
in
order
to
match
against
the
content
and
the
requirement
for
a
regular
expression
came
a
few
times
in
order
to
something
more
specific
needed
to
catch
more
specific
assets
and
not
to
do
overreaching
around
delivering
more
content
than
is
needed.
So
first
proposal
here
is
to
add
a
content.
Reg
X
for
the
trigger
specification,
I
know
that
it
actually
changes
the
trailer
interface.
F
Focus
on
on
video,
and
when
we're
coming
to
do
things
like
pre
positioning,
we
find
out
that
we
need
to
give
there
the
DCB
and
a
list
of
URLs
for
preposition,
possibly
the
the
full
list
of
the
objects
in
the
arm
in
the
in
the
manifest.
So
it
really
makes
sense
in
order
to
instead
of
passing
the
full
list
within
the
trigger
spec,
to
give
a
URL
for
the
playlist,
because
that
would
be
the
most
natural
solution
for
a
video
CDN.
So
what
we're
proposing
here
is
to
add
the.
G
F
F
Geo
limits
so
trigger,
as
it
is
specified
right
now
is
applies
to
the
full
D
CDN
again,
since
this
idiom
can
be,
if
it's
an
ISP
CD
and
it
can
be
in
a
nationwide
ins
or
sometimes
even
even
wider,
and
we
want
to
be
able
to
limit
the
operation
to
specific
footprints.
A
good
example
for
that
would
be
from
regulatory
reason
or
business
reason
you.
You
can't
really
put
some
object
and
specify
the
location
that
are
controlled
by
the
content
provider.
F
So
our
proposal
here
is
to
add
a
location
object
to
the
to
this
trigger
spec.
We
could
possibly
use
the
MA
location
ACL
there.
The
issue
here
is
that
ma
location
ACL
was
designed
to
be
ACL
on
the
client
locations,
and
here
we
are
talking
about
caches
locations
which
is
different,
so
I'm
not
sure
if
it
would
be
the
right
idea
to
use
that
same
object,
and
maybe
we
should
create
a
new
object
for
that.
F
Neck
schedule
triggers
so
it
turns
out
that
sometimes
what
you
want
to
do
is
you
want,
especially
in
in
preposition
use
case.
You
want
to
trigger
the
downstream
see
the
end
to
preposition,
but
you
want
it
to
be
done
in
specific
times.
For
example,
if
you
want
to
pull
a
new
episode
of
Game
of
Thrones,
you
want
it
to
be
done
in
the
middle
of
the
night,
rather
than
9:00
p.m.
because
that's
the
whole
idea
to
do
it
before
the
peak
time.
F
So,
first
of
all,
you
would
like
to
tell
the
DC
DN
I
want
you
to
preposition,
but
I
want
you
to
reap
reap
addition
at
that
time.
So
next
question
could
be,
and
so
why
I
want
the
you
CDN
just
wait
for
that
time
and
then
send
the
trigger.
So
first
we
want
the
trigger
not
just
to
have
a
start
time,
but
also
have
an
end
time.
F
F
So
again,
we're
proposing
to
add
a
new
time.
Windows
object
to
the
trigger
spec
and
again,
there's
the
question
here.
If
we
could,
if
you
could
use
the
time
the
time
window,
ACL
of
the
metadata
and
I
think
that
in
that
case,
we
can't
just
because
we
need
to
add
the
local
and
the
local
option,
but
also
because
that
object
initially
was
designed
to
do
to
limit
or
to
create
an
ACL
on
data.
D
F
A
F
So
it
should
be
in
epic
or
a
possibly.
What
we
can
do
is
do
an
epic
plus
an
offset
in
order
to
to
define
the
local
I.
I
didn't
mean
to
to
have
like
a
full
final
thing.
That's
here
just
to
get
the
idea
that
we
need
to
have
something
that
can
say
we
want
it
to
be
nine
or,
let's
say
3:00
a.m.
at
local
time.
So
we
need
to
discuss
how
we
can
do
that.
Syntax
was,
but
so.
F
But
that
the
problem
is
that
three
I
am
is
different:
UTC
in
different
locations,
so,
let's,
let's
just
imagine,
I-
have
to
tell
the
a
and
a
nationwide
CDN
that
I
want
them
to
pull
the
next
episode
of
Game
of
Thrones,
but
I
want
them
to
do
that
in
3
a.m.
depending
on
the
local
time.
So
how
would
they
do
that?
Well,.
A
If
you,
if
you're
passing
your
timezone,
presumably
you're
gonna,
have
to
tell
them
multiple
times
anyway,
right,
I,
guess:
I!
Guess
if,
if
you're
doing
it
per
time
zone
anyway,
then
setting
a
different
time
isn't
a
big
deal
and
if
you're
not
then
you're
still,
you
still
have
the
same
problem.
I
think
so.
F
D
H
F
H
H
I'm,
not
sure
this
does
that
yet,
but
it's
close
so
III
I'd
suggest
maybe
just
take
it
and
tweak
it
to
do
that.
That
policy
that
it's,
a
local
you
want
to
apply
the
local
serving
time
against
this
generic
representation
that
can
be
sent
out
against
any
CDN,
so
I
get
that
you
wanna
have
the
start
in
the
end
to
be
applicable
to
any
CDN.
No,
that's
receives
this,
but
you
then
want
it
to
interpret
it
locally
to
the
client
as
it's
being
served
out.
Turkish.
F
H
You
know
it
back,
you
want
per
client
right,
you
want
it
served
out.
So
it's
also
if
I
send
a
a
a
pre
position
to
Denver
and
I
say
serve
this
at
3
amp
for
Denver
clients.
You
want
a
serve
a
3
amp,
but
if
it's
a
client
gets
redirected
for
load
balancing
to
that
cache
from
Boston,
you
want
to
actually
interpret
against
the
Boston
3m,
not
the
Denver
3m.
It's
a
it's
a
client
side
request.
Isn't
it.
F
Well,
III
didn't
think
of
it
like
that
until
now,
but
once
now
that
you
say
that
that's
possible
that
I
I
think
the
whole
idea.
The
reason
it
was
raised
to
begin
with
was
that
pre
positioning
comes
to
serve
the
the
purpose
of
content,
which
is
going
to
be
massively
used
to
be
repositioned
ahead
of
time
and
at
off-peak
hours.
So.
H
Content,
release
and
and
that
I
think
it's
actually
a
very
useful
addition
to
CD
and
I
as
an
so
by
the
way.
I
did
include
declare
myself
for
the
whoever's
yeah
blending
I'm
cast
NBCUniversal
but
I.
So
I
think
this
is
a
good
requirement.
I'm,
not
sure,
that's
capturing,
quite
yet
the
the
notion
that
it's
a
localized
time,
whether
it's
localized
to
the
client
or
localized,
to
the
cache,
because
the
cache
may
sir,
our
clients
and
other
time
zones.
H
F
H
H
G
H
F
G
G
I
think
Glenn
is
making
a
good
point,
but
I
think
the
requirement,
as
we
have
thought
about
it
is
the
restriction-
is
on
the
local
cache
that
is
actually
serving
the
content.
So
the
instruction
was
meant
to
tell
the
local
cache
that
if
you
are
a
cache
serving
content
in
Denver
area,
then
you
are
restricted
for
that.
3
p.m.
right
right.
F
B
Horry
this
is
this:
is
Kevin
I'm,
just
gonna
serve
myself
here
as
chair,
we've
only
got
about
thirty
minutes,
left
and
I
know
you're
only
about
a
third
of
the
way
through.
So
we
may
need
to
just
pick
it
up
a
little
bit
and
then
we'd
like
to
get
through
all
of
the
proposals
from
the
SVA
just
that
we
all
have
a
idea
of
what
it
kind
of
changes
we're
looking
for
and
then
at
the
end
the
chairs
are
going
to
ask
whether
or
not
we'd
won
this.
F
I'll
just
run
through
and
just
make
sure
that
everybody
knows
what
I'm
talking
about.
Then
we
can
see
how
cool
time
is
later.
So
another
requirement
is
that
we
came
by
is.
If
you
look
back
on
the
previous
requirement,
it
turns
out
that
when
you
do
triggers
sometimes
you
know
you
need
more
functions.
You
need
more
abilities
to
to
pass
something
from
the
DCD
and
to
the
UCD
and
and
currently
that's
not
possible.
So
what
we
are
proposing
here
is
to
do
some
kind
of
mechanism.
F
F
Lets
say:
I
want
you
to
do
some
invalidation,
but
under
a
given
scope
or
I
want
to
do
an
invalidation,
but
only
to
stuff
that
you
acquired
in
the
last
two
hours,
because
something
happened
in
those
two
hours.
These
kind
of
requirements
keeps
coming
up
when
we
started
to
do
specification
and
integration,
and
that's
not
something
that
we
cannot
do
right
now.
So
that's
a
requirement
for
the
armatures
to
see
if
we
can
add
something
like
that
to
triggers.
F
Next,
so
when
coming
to
do
all
those
stuff
to
triggers
to
adding
more
and
more
functions,
or
maybe
generic
or
extendable
functions,
it
turns
out
that
it
would
be
good
if
we
can
have
the
in
the
foot
in
the
FCI
as
capabilities,
because,
of
course
we
are
not
planning
everybody
to
support
anything
so
the
same
mechanism
that
applies
to
me
that
I
tell
by
FCI
telling
I'm
supporting
that
metadata
object.
Would
it
be
good
if
we
can
have
the
same
for
triggers
to
say
that
FC
I
says
I'm
supporting
that
trigger
object.
D
D
F
And
this
again,
this
is
and
cannot
implement
whatever
it
is.
You
can
find
in
the
market
right
now
that
goes
between
content
providers
and
commercial
CD
ends,
and
some
of
those
algorithms
are
on
the
other.
Nba
and
most
of
them
are
using
symmetric
keys,
which
cannot
be,
cannot
be
provided
to
the
d
CDN,
and
eventually
we
needed
to
think
of
some
kind
of
a
generic
mechanism
that
will
be
able
to
accommodate
all
that.
So
I'll
talk
about
a
little
bit
about
what
we
came
up
with
and
I
know
that
Phil
here
has
a.
F
F
C
F
F
So,
basically,
that's
the
whole
idea.
It
does
require.
Maybe
next
slide.
It
requires
metadata.
It
requires
new
metadata
because
in
the
metadata
we
will
need
to
tell
the
cache
that
for
that
specific
service
or
that
specific
metadata,
the
fields
which
should
be
used
in
for
the
session
are
those
specific
fields.
So
it
is
different
than.
F
A
Yeah,
so
this
Phil
schwarber,
so
I
think
this
is
really
clever.
The
surrogate
authentication
part
so
that
you
can
do
stuff
and
not
have
to
basically
pre-negotiate
make
sure
everybody
can
do
everything,
but
the
extra
metadata
adds
a
dependency,
because
the
URI
signing
can
be
mostly
implemented
without
the
other
CDI
pieces.
And
then
this
is
also
putting
like
metadata
relative
to
content,
and
you
know
it's
having
to
put
like
the
the
cache
key
directives
in
there.
F
So
if
I
get
it
right,
the
idea
is
that
we
keep
the
original
URI
signing
logic
between
the
content
providers
and
the
you
CDN
at
the
you
CDN
and
put
some
new
logic
in
order
to
do
the
surrogate
between
the
you
CDN
and
the
D,
the
D
CDN,
and
that
logic
will
be
with
some
kind
of
a
TTL.
So
the
DC
do
end
will
have
to
repeatedly
go
and
do
a
relay
to
the
UCD
and
once
in
a
while,
possibly
once
in
a
long.
A
A
With
the
TTL,
and
when
that
TTL
expires,
then
it
has
to
go
and
redo
the
surrogate
validation
and
start
that
process
over,
and
then
you
get
all
the
benefits
of
the
claims.
Like
the
what
was
formerly
the
subject
claim
and
stuff
like
that
to
do
what
you're
talking
about
here
and
you
know,
TTL
and
client
IP.
If
you
want
that,
doesn't
have
to
go
into
metadata,
it
can
all
go
into
the
into
the
your.
I
signing
token.
B
F
I'm
passing
the
mic
to
Andre.
G
Sanjay
Mishra
I'll
be
really
quick
here,
so
the
CD
and
I
spec
actually
does
talk
about
the
logging.
But
what
is
different
here
is
that
there
are
a
couple
of
motivations
that
we
had
for
proposing
a
alternative
method.
One
is
that
Syrians
have
largely
done
implementations
with
the
logging
already
in
place,
and
they
are
currently
using
this
quit
based
logs.
So
we
wanted
to
make
sure
that
we
can
keep
that
flexibility.
That
already
exists
for
the
Syrians
to
be
able
to
use
the
logs.
G
So
the
intent
was
that
for
anything
that
the
d
CDM
delivers
on
behalf
of
the
you
CDN,
we
leverage
the
existing
logging
mechanism,
so
we
wanted
to
just
keep
this
quit
logs
as
it
is.
The
second
question
that
came
up
was
that
is
there
a
way
for
us
to
also
leverage
the
transport
mechanism
that
may
exist,
but
that
may
already
be
supported
by
the
Syrians.
G
So
we
thought
we
can
add
a
sort
of
mechanism
for
a
CDN
and
you
CDN
to
negotiate
what
kind
of
transport
mechanism
that
is
already
in
place.
So
we
can
leverage
that
so
we
added
a
provision
here
to
allow
CD
ends
to
be
able
to
negotiate
transport
method
which
could
be
logstash
or
it
could
be
a
you
know,
SFTP
type
or
any
other
method
that
might
already
exist
next
slide.
So
I'm
just
gonna
be
really
quick.
9J.
G
B
B
But
given
the
the
stuff
that
was
discussed
today,
I
think
we've
definitely
gone
beyond
the
scope
of
our
existing
Charter.
So
I'd
like
to
get
an
idea
of
if
this
stuff
that
we
would
like
to
work
on
that.
That
working
group
would
like
to
work
on
and
if
so,
then
we
can
start
thinking
about
how
we
need
to
address
the
Charter
address
reach
our
during
in
order
to
take
on
this
work.
B
So
the
first
question
I'd
like
to
do
a
hum
on
is:
do
we
have
interest
in
doing
HTTP
delegation
I,
don't
think
I
can
hear
the
hum.
So
this
is
gonna,
be
all
you
if
you,
if
you
think
that
we
should
take
on
HTTP
delegation
understanding
that
there's
a
lot
to
be
worked
out
there
and
we'll
decide
that
as
a
working
group,
please
hum
now
and
if
you're
opposed.