►
From YouTube: IETF115-CDNI-20221111-1200
Description
CDNI meeting session at IETF115
2022/11/11 1200
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
I
think
it's
noon.
Let's
get
started.
This
is
the
Friday
the
last
set
of
meetings,
so
brave
souls
are
here
and
if
you
are
for
Content
delivery,
Networks
interconnection
working
group
session,
then
you're
at
the
right
place.
A
Let's
start
with
the
note:
well,
as
you
are
all
familiar
with
it,
and
you've
probably
seen
this
all
through
the
week
and
just
a
couple
of
points
just
to
still
remind
you
that
you
but
participating
here,
you
agreed
to
follow
the
idea
of
processes
and
policies
with
respect
to
contributions
and
if
you
have
any
patent
on
anything
that
you
are
working
on,
you
must
declare
that
and
also
code
of
conduct
is
you've
got
to
follow
that,
as
laid
out
in
the
note.
Well,.
A
Okay,
that
said,
let's
move
on
to
a
couple
of
tips.
Again,
this
is
really
redundant.
If
you've
been
here
all
week,
then
you
know
everything
here
and
just
a
reminder,
though,
that
you
got
to
wear
your
masks
unless
actively
speaking
at
the
microphone
here
and
also
so
you've
got
some
rules
for
the
in
in
person.
Participants
make
sure
that
you
use
the
meat
Echo
and
to
make
sure
that
you
are
signed
on
I.
Don't
think
we
have
that
on
a
display
here
and
I.
A
Didn't
include
that
in
my
meeting
presentation
that
that
you
can
scan
that
outside
the
room.
If
you
enter
the
room,
there's
a
scanner
there
that
you
can
scan
in
and
also
if
anybody
that's
remote
you're
already
in
so
you
already
are
pretty
familiar
with.
You
know
your
audio
video
functions
and
if
you
have
any
questions,
make
sure
that
you
raise
hence
to
get
into
the
queue.
A
Okay
and
again,
a
couple
of
other
resources
that
if
you
need
to
go,
find
and
then
with
that
said
Kevin
we
want
to
walk
through
this
or
shall
we
just
go
through
the
agenda
first
and
then
come
back
here.
B
Yeah
so
since
last
time
we
met
in
Philadelphia,
we
did
submit
the
cdni
footprint
types
draft
to
the
isg
Francesca.
Welcome
back
we're
glad
to
see
you,
you
hopefully
saw
the
the
shepherd
right
up
and
for
the
footprints
draft
awesome.
Thank
you,
and
we
also
did
the
call
for
adoption
for
the
capacity
draft.
B
Andrew
and
Ben
are
here
to
talk
about
it.
Otherwise
we're
hoping
to
get
the
Acme
star
delegation
done
very
soon.
I
saw
the
new
draft
is
out
from
Frederick
I,
provided
some
comments
this
morning.
B
Back
again,
we
still
have
a
couple
of
other
things:
work
in
progress,
the
the
other
delegation
draft,
as
well
as
the
update
to
the
triggers
interface,
which
I
think
Sun,
is
going
to
talk
about.
B
A
I
think
we've
covered
it
all.
Okay,
all
right,
but
that
said
I
I,
don't
think
I
actually
called
out
my
name
so
I'm
Sanjay
Mishra
and
my
co-chair
Kevin
is
remote.
As
you
see
him
all
right.
So
let's
look
at
the
agenda
here.
We've
got
a
pretty
packed
agenda,
so
we've
covered
the
note
well
and
we
do
need
jabber,
scribe
and
minute
takers
or
taker
if
anyone
that
will
volunteer
for
it.
A
All
right,
Kevin,
thank
you,
okay,
so
that
being
said,
we've
got
four
working
group
drafts
that
are
active,
so
we
want
to
walk
through
these
four
and
then
we've
got
a
update
from
Chris
lemons
on
streaming,
media
tracing
he'll
talk
about
it
and
we've
also
allocated
some
time
on
open
mic
and
I
see
Ellen
Earl,
which
has
joined,
so
he
might
be
able
to
use
that
time
to
for
a
couple
of
items
that
he's
working
on
that
he
wants
to
bring
to
the
working
group,
but
he
didn't
have
enough.
A
He
was
not
in
time
to
submit
the
draft
before
the
cutoff,
so
we'll
we'll
have
some
time
for
you,
Alan
at
the
open
mic
for
you
to
talk
so
anything
on
on
the
agenda
bashing.
Anything
anybody
has
any
questions.
Anything
you
want
to
add,
remove
or
have
questions
on.
B
Great
and
then
just
a
reminder,
presenters,
please
turn
on
your
cameras.
Other
folks,
please
turn
off
your
cameras.
Just
help
save
the
bandwidth.
A
All
right
with
that
said,
so,
let's
look
at.
Let's
walk
through.
Let's
spend
some
time
on
the
working
group
documents,
we've
got
about
60
minutes
and
we
have
about
four
different
working
work
streams.
So
the
first
one
is
the
https
delegation
using
star
so
Fred.
Actually
we
have
you.
First
sorry,
I
didn't
realize
that.
But
yes,
we
have
you
first.
D
So
hello,
everyone
I,
will
make
a
quick
update
on
the
draft.
We
are
go
through
ring
now
for
quite
a
few,
a
lot
of
time
on
HTTP
delegation
for
Acme
star
next
next
slide.
Please.
D
We
clarify
the
abstract
into
better
give
an
overview
on
the
Acme
delegation
when
you
rename
the
object
that
we
are
dealing
with
in
the
in
the
draft.
We
change
also
the
figure
on
the
bootstrapping
or
flow.
So
hopefully,
now
it's
getting
clearer
on
that
too,
and
we
collected
various
typos
next
time.
D
Also
we
made
we
made
the
quite
a
few
changes,
also
on
the
on
the
object
we
are
dealing
with
according
to
discussions
with
the
RFC
8739
authors,
so
they
are
authoring.
The
draft
on
Acme,
star
So,
based
on
those
discussions.
So
first
we
added
the
draft
on
the
GitHub,
but
we
also
added
some
properties
in
the
Acme
delegation:
objects
to
indicate
certificates
validity
window.
D
We
also
supported
now
non-star
Acme
delegations
which
were
missing
and
the
first
versions
of
this
of
the
drafts,
so
it
means
that
we
are
meaning
to
support
long-term
certificates
by
by
adding
so
Lifetime
and
lifetime
adjust
properties.
So,
according
to
the
rrc
8739.
D
D
So
what's
next
so
now
we
are
proposing
to
change
the
draft
name
to
cdni
metadata
for
mitigations,
which
seems
more
accurate
than
the
current
Drive
name,
and
also
we
are
asking
now
for
a
bit
of
time.
The
working
roof
last
call.
So
hopefully
now
it's
it's.
We
are
reaching
the
good
good
end
of
the
of
the
work,
and
so
I
saw
that
Kevin
already
reviewed.
The
draft
so
to
meet,
should
be
now
very
quick
to
to
take
them
into
account
to
take
the
the
comments
into
account
so
normally
yeah.
A
Great
I
I
gotta
go
back
in
because
I
was
trying
to
scan
here.
Log
me
out
so
give
me
one
second
here
so
Fred
based
on
I
I
did
see
email
from
Kevin,
where
Kevin
has
responded
back
with
some
nits,
and
there
are
a
couple
of
key
comments
also
on
some
of
the
design.
So
I
guess
you
gotta
follow
up
on
that.
Yeah.
D
I
think
it's
it's
doable
for
for
the
next
few
few
weeks.
B
Okay,
yeah
I
I
did
this
pre-sheperd
review
I
I
think
it's
in
pretty
good
shape.
It's
it's
much,
it's
much
better
than
the
previous
version.
So
thank
you
for
that
there
there
were
a
couple
of
comments.
I
had
the
Json
example
doesn't
match
what
is
specified.
So
we
need
to
clean
that
up
and
then
I
think
we
could
still
beef
up
the
security
considerations
a
little
bit,
but
otherwise
I
think
it's
in
pretty
close
shape.
B
A
Okay,
I
think
next
on
the
agenda.
A
B
E
E
So
yeah
I'm
presenting
the
this
contribution
on
behalf
of
Christoph
that
could
not
join
today
by
the
way
in
France.
Today,
it's
a
half
day.
It's
a
holiday
okay.
So
let's
go
with
this
draft,
so
can
I
can
I
control
the
rust
the
slice
from
a
remote?
How
does
it
work.
E
E
Yeah,
okay,
so
we
have
a.
We
have
had
our
a
couple
of
six
changes
between.
There
have
been
a
couple
of
exchanges
between
Christoph
and
Kevin
I
think
I'm.
E
They
ended
up
with
this
Drive
ITF
cdnis
GPS
delegation
subset
zero
zero
and
there
was
something
it
was
not
completely
satisfactory
because
it
somehow
used
FCI
for
something
that
was
not
designed
for
so
yeah,
because
with
FCI
with
the
object
delegated
credentials,
we
we
expect
from
the
fcis
to
announce
I
mean
to
use
FCI
each
time.
The
delegated
credential
expired,
which
wasn't
not
very,
not
really.
The
way
we
should
have
used.
E
Fci
FCI
is
used
for
enhancing
exposing
the
capabilities
and
not
really
to
you
know,
to
use
as
a
channel
for
for
entire
kind
of
interactive
protocols
or
such
kind
of
things.
So
that
was
not.
This
was
not
really
satisfactory,
right
and
yeah,
and
anyway
we
had.
That
was
a
state
last.
That
was
a
step
so
far,
and
there
has
been
a
proposal
to
to
try
to.
You
know
correct
this:
this
main
default.
If
I
can
name
it
like
that,
so
can
you
go
to
the
next
slide
yeah?
E
So,
basically,
that's
what
we
have
today.
We
have
two
objects
in
FCI.
We
have
a
currently
in
the
in
the
draft
right.
We
have
an
FCI,
an
object
that
is
used
to
to
express
for
for
the
downstream
CDN
to
Express
the
needs
or,
let's
say
the
need
of
I
mean
the
the
capacity
of
inject
of
ingesting
a
certain
number
of
delegated
connections.
So
that
means
here
free
means.
You
can
sign
me
up
to
free,
dedicated
credential
and
I.
E
I
will
know
how
to
deal
with
it,
that's
more
or
less
what
it
means,
but
and
and
the
only
on
the
other,
on
the
delegated
credential
object.
The
Mi
object,
the
configuration
object
that
was
up
to
the
mcdm
to
send
this
delegated
credentials
right,
according
to
the
number
requested
by
the
by
the
downstream
CDN
I,
mean
requested,
yeah
and
announced
exposed.
E
Yeah
so
as
I
told
as
explained
so
in
slide,
I
yeah
I'll
explain
it's
a
it's,
not
SEI
should
not
be
used
as
a
kind
of
signaling
protocol.
It's
not
it's
more
about
signaling
and
announcing
the
capabilities
and
more
than
using
it
for
signaling.
So
that's
that
was
the
drawback
of
this
method.
Kevin
purpose.
One
thing
was
to
completely
remove
the
FCI
object
and
instead
he
proposed
to
rely
on
on
well
only
on
dedicated
credential
objects
and
operating
yeah,
and
it
was
well.
E
The
proposal
from
Kevin
was
based
on
the
fact
that
the
metadata
Mi
metadata
results
on
the
Upstream
side,
and
it
was
its
proposal,
was
based
on
the
fact
that
the
downstairs
CDN
can
download
and
fetch
the
the
configuration
at
any
time.
This
is
and-
and
it
was-
and
this
proposal
was
also
based
on
the
fact
that
we
could-
we
could
let's
say-
relates
objects
in
the
configuration
metadata
we
can.
We
can
operate.
How
do
we
call
that
links?
I?
E
Don't
remember
exactly
the
names,
but
it
was
based
on
this,
but
we
are.
We
have
a
problem
with
this
proposal
because
first
in
svta
we
don't
we
don't
support,
links
reference
links,
at
least
in
the
first
version
of
it,
and
furthermore,
we
have
two
ways
to
configure
a
downstream
CDN.
E
It
can
be
either
the
pull
mechanisms
like
like
Kevin
was,
you
know,
assume,
but
we
can
also
use
the
push
mode
where
the
dance,
the
app
stream
CDN
push
the
configuration
using
a
particular
API
to
do
that,
and
in
that
case
the
the
anyway
the
the
references,
the
the
link
methods
you
know
to
reference
object
between
them
are
not
supported
or
even
forbidden.
E
So
basically,
your
proposal
Kevin,
cannot
work
with
svta
1.0,
at
least
not
in
all
modes.
That's
my
problem.
So
instead
we
have
proposed
something
else:
to
remove
the
drawback
brought
by
operating
FCI
Beyond,
its
original
design.
So
we
keep.
We
propose
to
keep
this
FCI
object
but
changed,
but
instead
we
would
change
the
sematic
attached
to
this
SCI
object,
so
the
sci
object
would
now
in
our
new
proposal
would
would
be
used
to
announce
the
maximum
delegated
credential
that
we
support
right.
E
So
this
is
ready
and
that's
it
and
the
FCI
won't
be
used
anymore
for
announcing
that
the
delegated
corrosion
need
to
be
refreshed
like
like
it
was
like
it
is
today
like
it
is
described
today
in
the
in
the
in
the
current
draft.
No
FCI
object
only
used
to
announce
the
maximum
number
of
delegated
credentials.
E
Then
the
Upstream
CDN
will
use
this
Mi
object
to
configure
a
certain
number
of
delegated
credentials.
It
can
be
apt,
it
can
be.
It
can
corresponds
to
the
maximum
number
advertised
by
the
by
the
transfer
CDN
through
SCI,
or
it
can
be
less
right.
E
It
can
be
only,
for
example,
one,
so
it
doesn't
change
from
what
we
have
described
already
in
this
in
the
spec
and
the
when
the
when
the
the
credentials,
the
delegated
commercial
is
going
to
expire.
It's
not
the
downstream
cdns
to
manage
that.
It's
up
to
the
Upstream
cdns
to
manage
this
and
to
a
recent
reconfigure,
the
downstream
cgn.
With
a
new
delegate.
We
will
refresh
our
new
dedicated
credential.
E
You
know
because
the
previous
one,
because
it
knows
the
absence
DN-
is
supposed
to
know
exactly
the
the
live
situation
of
the
validity
of
a
of
a
delegated
commercial
and
it
is,
it
will
be
up
to
the
Upstream
CDM,
to
refresh
it
and
to
re
reconfigure
it
that's.
Basically
our
proposal.
E
Hopefully
I,
was
clear
enough
for
you
to
understand
and
now
I'm
open
to
questions.
Oh.
F
What
is
the
method,
how
the
sorry.
B
E
It
used
the
basically,
we
call
it
the
configuration
method
in
svta.
We
have
two
ways
to
configure
the
downstream
CN
right,
so
either
you
can
use
the
trigger
interface
or
you
can
use
this
simple.
What
we've
defined
as
a
simple
configuration
interface,
which
is
basically
a
you
know,
a
put
interface
and
it's
a
rest
put
interface
right,
where
you
just
provide
the
the
complete
configuration
structure
or
a
part
of
the
configuration
structure
right.
E
The
interface
allows
to
it
allows
to
remove
and
it
allows
to
modify
the
configuration
yeah.
The
downstream
configuration.
A
All
right,
I
I'm,
transferred
I'm
in
the
queue
next
I'll
go
near
you
good,
okay,
the
the
only
question
I
have
is
that
asking
the
ucdn
to
know
the
renewal
period.
A
That
might
be
a
little
bit
more
tricky
for
the
ucdn
to
kind
of
try
to
keep
track
of
this
I'm
I'm
just
wondering
if
the
design
should
take
into
consideration
where
the
downstream
CDN
is
responsible
for
knowing
when
the
certificate
expires,
and
it
makes
a
request
to
fetch
a
new
certificate
rather
than
relying
on
the
Upstream
CDN.
To
remember
this
and
send
it
down.
E
Yeah
I
understand,
and
that
was
part
of
the
problem
right.
We
have
to
find
a
compromise
right.
It's
a
trade-off
and
we've
been
against,
created
and
and
and
designing
a
new
interface,
because
for
what
you,
what
you
are
saying,
Sanjay,
we
need
a
new
interface
and
at
the
beginning,
we've
proposed
this
new
interface,
but
it
was
too
much.
We
thought
that
we
could
do
without
this
new
interface.
E
Then
we
have
this
IDs
of
operating
the
FCI
as
a
kind
of
return
channel,
for
a
kind
of
you
know
like
a
bit
that
we
used
to
do
that
for
also
for
capacity
inside,
for
example.
So
but
it
was
FCI
has
not
been
designed
for
that
and
again,
I
agree
with
this.
As
a
as
with
this
with
this
conclusion
with
this
remark
and
then
then
we
have
this
problem.
It
means
it
requires
the
Upstream
CDN
yes
too,
but
frankly
the
opportunity
then
asked
to
know
what
he's
doing
right.
E
So
if
it's,
if
it's,
if
it's
as
created
delegated
credential,
it's
a
it
has
to
manage
that
right.
You
cannot
let
credentials
like
you
know
without
you
know.
So
that's
a
that's
a
trade-off.
If
you
watch
the
the
downstream
cdns
to
to
take
care
of
the
of
the
refresh
by
the
way,
I
think
the
downswing
CDN
will
take
care
anyway.
E
So
if
the
dance
team
CJ
knows
that
the
that
the
the
the
negative
connection
is
going
to
expire-
and
that
is
nothing
has
been
sent
for,
you
know
refreshing
that
dedicated
credentiality
will
take
care
of
it.
Don't
worry.
The
thing
is
that
we
don't
have
mechanisms
to,
because
we
don't
want
a
new
interface,
so
we
just
have
to
you
know,
rely
on
the
Upstream
CDN
just
to
do
its
job,
and
if
you
cannot
do
it
in
time
there
will
be
something
else.
E
You
know
probably
I,
don't
know
how,
but
exactly,
but
we
have
we
have.
We
have
a.
We
have
different
methods.
It's
it's
more
about
implementation
issue
here,
right.
If,
for
example,
a
dedicated
only
one
delegated
connection
is
renewal
and
on
the
overs,
then
we
can
share
the
delegated
credential
among
all
the
servers.
For
example,
it's
one
way
to
cope
with
the
problem
of
having
the
option
CDN
just
late
or
just
you
know
such
kind
of
things.
So
we
we
may
have
methods
right,
but
yeah
I
won't
I.
E
We
thought
that
we
should
try
to
be
simple
as
simple
as
possible,
so
this
proposal
is
quite
simple:
doesn't
solve
everything
it?
It
has
some
burden,
it
provides
some.
It
has
some
disadvantages
because
for
the
swims
again
that,
like
you,
said
this,
obliged
to
follow
it
to
track
this
and
this
refresh
period
and
to
resonate
but
anyway,
the
absence
then
will
have
to
work
anyway.
We'll
have
to
provide
new,
even
if
the
downswing
CDN
manage
this
expression
and
request
somehow
to
the
options
here.
A
Okay,
yeah
thanks
Kevin
I.
B
Guess,
I'm
I'm
still
not
understanding.
If
the
why
the
metadata
doesn't
work
by
itself
right,
the
the
downstream
CDN
can
re-request
the
metadata
or
the
Upstream
CDN
can
use
triggered
pull
we
support
triggering
refresh
of
metadata.
So
there
are
mechanisms
built
into
cdni
to
do
this,
whether
or
not
they're
they're
your
preferred
method.
There
are
mechanisms
and-
and
if
you
want
to
build
a
separate
mechanism
outside
of
it
and
have
a
different
configuration
interface,
that's
fine!
B
That's
that's
not
really
within
scope
here,
but
but
it
doesn't
really
matter,
but
I
guess
I
still,
don't
understand
why
pulling
the
metadata
itself
is
not
enough
now,
I,
don't
mind,
I!
Think
if
you
have
a
new
FCI
object
that,
but
that's
not
really
the
issue
here
right.
E
Well,
putting
the
metadata
is
one
of
the
things
that
has
been
the
basis
of
dcdni
RFC,
but
we
are
adding
a
new
possibility
that
will
also
be
part
of
cdni,
somehow
I
think
because
it's
part
of
our
proposal
to
modify
to
add
some
features
in
cdni
and
this
one
of
the
feature
is
that
the
metadata
is
not
only
pull
is
also
pushed
right.
So
that's
that's
enchant
that
much
right,
it's
just
that
pooling
is
just
an
option.
It's
not
the
only
one!
That's
that
that's
that's
my
problem.
E
E
That's
the
concretely
when
we
start
to
develop
the
the
fact
that
the
Upstream
CDN
needs
to
keep
I
mean,
keep
the
metadata
and
and
continuously
and
await
the
the
pull
method.
I
mean
the
pull
request
to
served.
It
was,
it
was
viewed
as
a
sometimes
problematic
and
the
first
implementation
does
did
not
do
that
see
just
the
reliably
on
the
yeah.
B
I
guess
I'm
still
not
understanding
how
that
affects
this
particular
draft
right.
Even
if
you
had
push
support
for
metadata
to
force
it
to
update
the
metadata
object
itself,
doesn't
change
necessarily,
and
so,
if
we
did
add
that
support
later,
whether
you
implement
the
outside
cdni
or
cdni
implements
the
ability
to
push
new
metadata.
It
shouldn't
change.
This
particular
object,
or
this
particular
use
case.
F
E
B
E
I'm,
okay,
with
that,
it's
I'm
just
it
can
be
an
option.
So
then
we
can
have
two
ways
as
two
ways:
I
have
no
I
have
no
problems.
We
just
wants
to
bring
our
option
here.
I
still
have
valid
options.
That's
my
point
right!
Okay!
So
so,
if
I
went
understood,
you
are
saying
that
we
should
keep,
maybe
both
as
two
possibilities
to
control
the
the
refreshing
of
the
delegated
commercial
right.
E
E
That
great
comment
right
now
it
was
based
on
what
I
wait.
I
tried
to
explain
what
which
what
we
put
the
change
that
we
propose
to
bring
in
this
ground
draft.
So
basically
what
we
are
saying
that
FCI
object
is
still
there,
but
it
is
not
used
to
manage
the
exploration.
It
is
just
used
to
announce
the
maximum
number
of
delegated
credential
that
the
downstream
CNC
port
all.
A
Yeah
I
think
Alfred
also
has
a
comment,
so
maybe
it's.
It's
certainly
I
think
this
issue
we
need
to.
You
know
maybe
reply
back
a
little
bit
more.
You
know
in
the
mailing
list
and
talk
through
this
to
to
make
sure
it's
clear.
The
path
you
know,
I
understand
that
FCI
is
making
requests.
You
know
FCI,
why
you're
using
it,
but
we
still
are
not
clear
on
some
of
the
the
design
that
you
have
in
number
two.
So,
let's,
let's
take
it
on
the
mailing
list.
Also.
D
A
I'll
I'll
respond
to
that
at
least,
and
Kevin
can
also
chime
in
I.
Technically,
it
would
be
easier
if
this
draft
follows
the
how
the
delegation
is
is
using
these
Acme
delegation,
where
you
have
the
FCI
and
also
using
the
metadata
interface
to
request
updates
from
Upstream
CDN.
So,
logically,
it
seems
like
you
know,
the
delegated
credentials
can
follow
the
same
mechanism,
but
I
don't
think
we
want
to
make
a
decision
about
that.
A
Here
particularly
definitely
need
to
talk
this
through
more
in
the
mailing
list
to
see
if
other,
there
are
other
ideas,
but
it
seems
like
it
would
be
easier
if
this
this
draft
also
follows
the
the
previous
version.
I
mean
the
the
other
draft.
B
D
E
A
I
think
to
be
clear:
Fred
is
not
not
asking
to
merge.
He
was
sort
of
suggesting.
If,
if
could
this
delegated
credentials,
follow
the
the
pattern
for
the
Acme
delegation,
but
it
it
could,
but
it
doesn't
have
to
but
I
so
I
I'm,
not
sure
just
to
be
clear.
Fred
is
not
asking
for
merge,
so
I
was
not
sure
if
you're
no.
B
A
B
Think
Fred's
question
is:
can
you
also
get
away
with
just
using
the
existing
metadata
object
to
it,
advertise
enabling
disabling
without
the
need
for
passing
the
parameter,
the
max
credentials.
E
Course
no,
but
we
can't
right.
We
need
this
maximum.
For
the
moment,
I
mean
if
we
end
up
with
removing
these
parameters,
then
of
course,
but
for
the
moment
we
need
this
parameter
right.
E
G
All
right,
everyone
hear
me
clearly.
A
G
All
right
so
Sanjay,
thanks
for
putting
together
the
slide
deck
appreciate
it
so
I'm
on
here
with
Ben
Rosenbloom
as
well,
we're
here
to
discuss
some
updates
on
the
our
progress
on
the
capacity
signaling
component
that
we're
proposing
next
slide.
Please
Sanjay.
G
So
I
mean
just
to
highlight
without
reading
through
the
slide.
The
the
overall
goal
here
is
to
allow
a
mechanism
for
delegation
Partners
to
understand
how
much
traffic
is
appropriate
to
delegate
I
think
this
was
a
topic
that
was
deferred
from
some
of
the
original
cdni
specifications,
probably
due
to
some
of
the
complexity,
but
it's
definitely
in
practice,
something
that
is
identified
as
being
a
key
component
to
making
sure
that
the
traffic
steering
is
done
in
in
an
intelligent
manner.
G
G
G
So
some
of
the
the
points
that
have
been
raised
on
the
mailing
list
are,
you
know,
points
that
have
come
up
in
some
of
the
discussions.
The
one
main
point
of
contention,
I
think
with
this
model
is
we've
identified,
is
what
we've
declined
as
a
subscope
within
an
FCI
payload,
so
to
take
a
quick
step
back.
G
What
we're
proposing
how
we're
proposing
to
accommodate
this
workflow
is
we're
creating
a
new
FCI
payload,
and
the
reason
why
we
wanted
to
take
this
approach
is
FCI
was
very
aligned
with
the
concept
of
of
capacity
signaling,
particularly
the
fact
that
the
FCI
object
is
tied
to
a
footprint
and
the
footprints
are
very
readily
tied
to
infrastructure,
underneath
that
the
downstream
cdns
would
be
advertising
or
supporting
capacity
from
so
it.
There
was
a
very
strong
case
to
leverage
FCI
for
this
purpose.
G
When
we
got
into
some
of
the
use
cases,
though,
we
found
that
the
FCI
footprint
may
not
be
as
granular
as
we'd
like
a
particular
use
case
is
if
you've
got
a
Upstream
CDN,
who
is
attempting
to
delegate
a
wide
portfolio
of
traffic
to
the
downstream,
for
example,
the
Upstream
CDN
is
dealing
with
a
game
download
company
a
streaming
company,
a
website
company,
all
of
which,
though
all
of
those
traffic
portfolios,
are
very
different,
whereas
the
downstream
CDN
may
want
to
provide
limits
specific
to
that
traffic
to
a
particular
traffic
type
I.E.
G
You
know
you
will
allow
x
amount
of
gigabits
per
second
of
your
game
traffic,
but
if
you're
going
to
start
sending
us
and
delegating
low
latency
hls
traffic
to
us,
which
would
have
you
know,
potentially
a
much
higher
request
per
second
portfolio,
that
may
be
something
the
downstream
cdns
want
to
signal
in
a
more
granular
manner.
G
To
accomplish
this,
while
we
proposed
in
the
new
FCI
capacity
limits,
object,
we're
creating
is
the
definition
of
a
of
a
scope
and
that
scope
would
essentially
live
within
inside
of
the
the
payload
it
would
be
encompassed
within
the
footprint.
G
As
Kevin
has
pointed
out.
That's
you
know
not
necessarily
A
I,
guess
a
standard
practice,
there's
some
ambiguity
in
there
or
there's
a
sense
of
ambiguity
in
there.
We
tried
to
address
that
in
the
specification
by
kind
of
coming
up
with
guidelines
on
how
this
scope
object
should
be
evaluated,
and
it's
you
know
it.
The
end
of
the
day
is
really
boils
down
to
all.
Requirements
need
to
be
evaluated
and
accounted
for.
G
It's
not
an
order
of
Precedence
per
se.
It's
not
a
or
a
logical,
or
it's
an
and
you
know
everything
has
to
be
to
be
met.
At
this
point,
we
provided
on
the
the
mailing
list.
G
An
example
of
you
know
a
payload
what
it
would
look
like
with
some
of
the
scoping
defined
so
I
guess
the
that
seems
to
be
one
of
the
biggest
points
of
discussion
here
that
we're
hoping
to
kind
of
raise
up
and
solicit
some
feedback
on
Sandra
I'm,
not
sure
if
there's
any
additional
slides
at
this
point,
but
I
think
that
was
probably
one
of
the
biggest
things
we
wanted
to
talk
about
here.
Oh
okay,
here
we
go
sorry,
sorry
I
jumped
ahead
and
your
slide
deck.
G
So
at
this
point
I
I
guess
we
opened
the
floor
for
conversation,
Kevin
I
think
particularly
you
in
particular.
B
B
I
was
actually
just
thinking
with
the
new
footprint
Union
type
and
the
clarification
we
do
have
the
ability
to
now
specify
this
as
Footprints
I,
think
right
and
if
we
added
a
new
footprint
type,
which
was
you
know,
the
the
host
or
or
some
something
related
to
how
it,
how
it's
being
retrieved,
it
would
be
really
nice
I
agree
if
it
related
to
the
metadata
host.
B
That
would
be
cool,
I,
don't
know
if
there's
a
good
way
to
hard
link
that
it's
possible,
because
we
do
have
the
the
link
references
from
metadata
or
if
we
just
wanted
to
make
it.
You
know
this
should
match
up
with
something
and
figure
out
how
to
do
it.
We
could
always
put
that
in
there
and
that's
a
detail.
We
can
figure
out,
but
I
think
that
I
I
think
that
makes
sense.
B
It
makes
it
makes
a
lot
of
sense
and
we
didn't
consider
it
originally
I
think
there's
probably
still
a
way
we
can.
We
can
do
it
with
Footprints
I.
Think
I
originally
was
thinking.
It
wasn't
a
footprint
thing,
but
now
that
I
understand
what
we're
talking
about
it
feels.
Okay,
it
seems
somewhat
natural,
so
I
I
would
be
in
favor
of
exploring
that
route.
G
I
I
mean
I,
don't
want
to
speak
for
the
larger
group,
but
I
I
feel
like
that
makes
sense
as
well,
because
the
it
makes
sense
and
the
only
other,
Counterpoint
I'd
say
where
it
could
be
challenging
right,
is
when
we're
dealing
with
what
is
the
delegation
model
now?
Typically,
like
we've
been
highly
focused
on,
like
the
DNS
delegation
model,
at
which
the
most
granular
delegation
element
would
be
DNS,
we
really
can't
get
in
a
host
at
that
point.
G
So,
for
example,
if
there's
a
client
where
there's
multiple
traffic
types
served
under
the
same
public
shows
like
slash
live,
you
know,
LL
live
is
low,
latency
live
and
you
got
regular,
live
alongside
it
and
website
delivery
that,
within
that
delegation
model
there
really
is
no
option
anyway.
So
you
kind
of
have
to
give
a
Car
Blanc
you
would,
you
would
have
to
the
most
granular.
G
The
downstream
CDN
would
be
able
to
make
a
delineation
on
would
be
the
DNS
name,
but
when
we
start
dealing
with
https,
you
know
302
redirection
models,
then
the
path
could
become
relevant.
Then
I,
guess
where
I'm
going
with
this?
Is
there
there
there's
a
little
bit
of
a
Nuance
there,
including
it
in
the
footprint,
but
actually
now
that
I'm
talking
it
out
loud
I
still
think
it's
it's
relevant
and
it
does
make
sense
to
try
and
add
that
identifier
into
the
footprint
as
well.
C
H
In
many
cases
you
won't
have
enough
information
to
determine
exactly
where
in
the
footprint
someone
Falls,
but
that's
not
unique
to
just
what
kind
of
content
they're
requesting
there's
a
number
of
cases
where
you're
never
going
to
be
100
certain
where
in
the
footprint-
and
you
just
have
to
do
your
best.
So
I
think
this
approach
makes
sense
and
the
the
footprint
solves
the
problem
more
neatly
than
the
other
Solutions
we've
looked
at.
H
B
Anyone
else
have
any
comments
on
on
this.
If
not
I
encourage
you
to
read
through
the
the
comment
thread
on
the
list.
I
didn't
know,
it
was
late
last
night
early
this
morning
for
folks
get
in
on
that,
but
otherwise.
I
I'll,
just
I'll
just
come
up
and
say
that
I
also
like
the
footprint
solution
and
I,
think
it's
just
that
we
just
didn't
consider
it
at
all
when
we
were
initially
dropping
this
I
think
you
know
when
we
started
on
this.
The
footprint,
extensions
and
footprint
unions
weren't
a
thing
yet
so
I
I
I
do
think
that
it
would
fit
into
that
model
very
nicely.
B
I
C
Sorry
I
apologize
when
we
say
Footprints
do
we
mean
I
think
there
are
two
interpretational
footprints
that
we
use
in
cdni
and
one
is
that's
a
kind
of
a
set
of
cash
resources
and
another
set
of
users
or
users
which
one
of
those
is
being
used
here.
G
This
is
the
the
footprint
that
is
the
the
part
of
the
definition
of
an
FCI
payload.
So
it's
literally
that
you
know
in
the
Json
object
right.
You've
got
the
FCI
components
at
the
top
and
then
the
footprint
underneath
it
and
it's
you
know
the
whether
it's
the
cider
slash.
You
know
the
decider
address
the
ASN,
the
geoip
or
the
the
geolocation
component
of
it
right
down
on
the
slide
to
the
the
right
there
Alan
on
the
bottom,
the
footprints
component.
That's
what
we're
talking
about
there.
C
I
get
it
what
I
said,
what
I'm
saying
we
never
really
disambiguated
this
distinction
and
and
that's
something
we
discussed
in
the
in
our
kind
of
name
Footprints.
The
discussions
in
the
CTA
is
that
really
in
cdni,
they're
implicit
to
different
Footprints,
one
is
a
footprint
of
users
that
are
being
addressed
right
and
you
define
them
the
way
you
define
them
asns.
What
have
you
right
or
you
define
a
set
of
caches,
so
I
just
want
to
make
sure
that
really
is
a
first.
C
G
Yeah,
okay,
I
see
what
you're
saying
about
is
the
Nuance
right,
so
the
the
down
in
this
case
right
it's
the
downstream
CDN,
is
saying
we're
allowing
for
is
really
a
nuance
and
I
think
this
is
kind
of
the
point
that
Chris
was
coming
up
with
right
is
you're,
either
kind
of
explicitly
all
of
this
at
the
end
of
the
day
is
really
measured
by
where
the
user
is
located
right.
So
even
when
the
downstream
is
saying
I'm
advertising,
you
know
support
on
this
ASN
or
this
slash
24.
G
At
the
end
of
the
day,
it
really
is
tied
back
to
a
geoip
lookup
of
the
end
users,
information
right
or
if
there's
some
other.
You
know
method
that
you
can
discern
from
where
the
eyeball
is
right.
It's
I,
I
kind
of
see
where
you're
saying,
though,
is
that
it's.
It's
really
there's
a
hard
definition
of
here's
the
capacity
available
in
this
data
center
right
in
in
wherever,
but
at
the
end
of
the
day,
the
the
footprint
is
really
the
based
on
the
eyeball
definition
right
and
we're
we're
kind
of
mashing.
C
Yes,
so
I
think
that
kind
of
again
this
is
for
this.
You
know
nascent
name
footprint.
Discussion
of
that
I
think
the
realization
would
come
to
is
that
we
really
are
using
the
eyeball
definition,
cdni
literature
kind
of
actually
not
very
definite
on
this
until
you
come
to
some
very
obscure
kind
of
draft,
really,
not
even
RFC.
C
That
says
well,
when
we
say
footprint
really
mean
two
different
things:
it's
either
set
of
caches
defined
by
IP
addresses
or
a
set
of
users,
and
I
really
saw
that
in
all
of
our
discussions
that
when
footprints
come
up,
we
really
mean
the
eyeball
so
I'm,
just
making
sure
that
when
you
think
about
the
capability
here,
you're
also
thinking
eyeball
footprint
and
not
cache
footprint,
because
to
me,
the
ladder
really
kind
of
meaningless
kind
of
across
the
board,
so
I'm
just
making
sure
that
that
we
on
the
same
page,
looks
like
we
are.
B
Cdni
is
always
based
off
the
user.
We've.
The
the
intent
was
never
to
to
try
and
describe
the
cash
infrastructure
because
we
don't
want
to
expose
any
cdn's
internal
infrastructure
they
can
serve.
However,
they
want,
if
they
say
they
can
serve
in
in
London,
they
can
serve
in
London
if
they're
serving
it
out
of
Japan
to
serve
London.
That's
you
know
not.
Our
problem,
I
think
it's
probably
a
bad
idea,
but
you
know
we
don't
want
to
take
that
into
account.
So
we
have
always
said
that's
kind
of
out
of
scope.
B
I,
don't
I,
think
it's
written
somewhere,
but
I'd
have
to
go
and
look,
but
if
it
is
Unwritten,
then
you
know
we
we
are
trying
not.
We
are
trying
to
avoid
exposing
anything
about
the
CD
and
physical
infrastructure
and
focused
on
you
know
the
end
users.
What
we
believe
is
the
end
users,
location,
obviously
tunneling,
and
that
sort
of
thing
maybe.
G
I
do
believe
that
is
specified
in
this
draft
as
well
as
one
we
have
to.
We
can't
advertise
Carl
Blanc,
all
capacity.
We
can
just
give
you
here's
the
capacity
available
for
you,
Upstream
CDN,
because
of
restrictions
just
like
that.
We
we
don't
want
to
allow
for
someone
to
reverse
engineer
like
the
actual
capacity
of
a
downstream
CDN
per
se,
and
then
two
we're
not
we're
explicitly
saying.
We
cannot
provide
slas
on
service
like
this
is
a
a
guidance.
G
C
Kevin
I
I
fully
agree,
I'm,
not
sure
that
is
universally
done.
This
way,
I
think
there's
at
least.
But
again
this
is
a
different
conversation.
I
don't
want
to
to
kind
of
the
grass
but
I'm
not
sure
that
Footprints
are
University
and
the
students
you
know
as
being
eyeballs,
but
that's
that's
for
another
day,
mostly
so,
but
not
not
universally.
I
H
It's
just
briefly,
you
mentioned
that
this,
the
way
in
which
this
is
related
to
business
Arrangements,
that
entities
might
have
with
one
another
and
I
think
we
have
agreement
that
that's
entirely
out
of
scope,
I,
hope,
okay,
I
see
heads
Notting
good,
the
the
question
of
whether
someone
makes
a
business
agreement
that
this
will
have
some
sort
of
penalties
or
enforcers
that
SLA
related
thing
is
an
agreement.
Someone
could
make
completely
outside
of
this,
but
it's
not
related
to
this.
G
100
correct
yeah
we
like
once
again
like
we
explicitly
call
out.
We
are
not
addressing
any
component
of
SLA
or
reservation
at
all
with
it
with
this
model.
This
is
really
a
model
to
signal
a
happy
path
that,
if
we
have
a
downstream
CDN,
has
a
reasonable
expectation.
If
that,
if
the
Upstream
delegates
the
traffic
within
the
limits
they
are
advertising
performance
would
be
acceptable,
but
there
is
no
definition
really
of
performance.
This
is
just
a
loose
agreement
of.
G
G
It's
probably
something
that's
going
to
come
down
the
line,
though,
but
that's
not
something
we're
tackling
at
the
moment
here.
A
Okay,
I
think
we
have
Anand
in
the
queue
now
and
Kevin
Anand.
J
Hey
Anand
from
ago
Limelight,
the
advertised
capacity
from
the
downstream
CDN
is
that
the
Ingress
capacity
is
advertising
or
is
that
the
amount
of
egress
it
can
support,
because
the
egress
is
a
function
of
the
request
rate
right
like
a
50
gig
file,
the
option
seating
doesn't
really
know,
what's
going
to
amount
to
the
egress
capacity.
So
what
is
the
downstream
CDM?
Actually
advertising
here?
Maybe
I'm
missing
some
context.
G
So
the
the
in
this
model
here,
what
we're
talking
about
here
right,
is
the
amount
of
traffic.
The
downstream
CDN
is
willing
to
allow
the
Upstream
CDN
to
delegate
towards
it
right.
So
in
this
case
the
eyeballs,
where
previously
they
may
have
come
to
the
Upstream
CDN
or
like
edio.
Now,
let's
just
say
that
ego
decides
to
delegate
that
traffic
towards
broad
Peak.
G
What
we're
talking
with
this
advertisement
would
essentially
be
broad.
Peak
would
be
telling
agio
I've
got
100
gigabytes
gigabits
per
second
capacity
on
Orange
in
Italy,
or
something
like
that.
You
can
delegate
your
tracking
how
much
you're
delegating
over
to
us
send
up
to
100
gigabits
per
second,
so
that
would
be
egress
as
measured
from
broad
Peak.
J
I
see,
okay
and-
and
that's
done
like
the
decision
is
done
by
the
option.
Cdn
on
a
per
request
basis,
then.
G
B
G
We're
not,
we
have
not
put
Provisions
into
the
capacity
API
to
advertise
any
limit
on
Ingress.
That
would
be
more
of
a
function
of
the
the
cash
fill
Source
or
I.E
the
origin,
or
something
that
would
be.
That
was
that's
outside
of
this
scope.
That's
not
a
that's!
Not
a
limit
that
the
downstream
would
really
want
to
ever
well
would
readily
advertise.
G
Unless,
for
some
odd
reason,
we
want
to
account
for
the
fact
that
the
downstream
CDN
only
has
you
know
a
10
gig
Uplink
out
of
the
world,
or
so
like
I,
don't
know
that,
isn't
something
we've
considered
in
terms
of
signaling
of
the
capacity
we're
mainly
dealing
with
outward
based
on
the
relationship
of
the
end
user,
eyeball
to
the
downstream
CDN,
not
necessarily
from
the
downstream
to
any
origin
source.
G
I
I
That
the
that
the
Telemetry
is
there
specifically,
because
the
Upstream
doesn't
necessarily
have
an
exact
understanding
of
the
effects
on
egress
from
the
delegated
traffic.
I
You
know
particularly
something
like
video
streaming,
where
you're
delegating
a
session
and
then
all
subsequent
requests
are
going
to
the
downstream.
The
Upstream
may
not
know
exactly
how
much
egress
is
consumed
by
those
sessions.
So
that's
why
this
is
explicitly
associated
with
a
Telemetry
source
so
that
the
Upstream
can
monitor
that
and
use
that
to
inform
its
traffic
delegation
decisions.
I
A
Thank
you
I
think
we're
a
little
bit
on
tight
on
the
time,
so
we're
gonna
move
on
just
before
I
close
the
queue
on
this
any
other
questions.
G
F
Okay
so
hi
everybody
happy
to
be
back
here
and
we
and
let's
say
I
would
like
to
discuss
the
three
years
interface
and
the
rewrite
of
the
RFC.
We
haven't
made
much
progress
in
the
last
since
the
last
meeting
I
was
less
available
to
pushing
through,
but
we
hope
to
make
a
significant
policy
now
and
Sanjay
and
I'm
working
on
that.
Can
you
please
I'll
do.
A
F
Let's
stay
like
that,
so
a
quick
recap:
what
is
the
cdni?
What
is
this
in
a
Traders
interface?
It's
the
interface
particularly
allows
the
absence,
then,
to
control
the
down
ccdn,
to
manage
and
control
down,
seasonal
content
and
metadata.
F
Sorry,
Friday
afternoon
and.
F
Do
we
haven't
changed
anything
in
that
in
this
website
in
this
purpose
and
perspective,
but
we
worked
on
the
entire
structure
on
the
structures
the
3D
object.
Next,
please.
F
So
so
far,
the
radio,
the
triggers
object,
was
built
of
a
type,
a
CDN
path.
In
the
last
draft
we
had
we
added
in
sometimes
we
saw
the
huge
extensions,
OE
and
Sanjay
mostly
worked
on
that,
and
then
we
had
a
a
set
of
properties
that
the
purpose
was
to
specifies
which
objects
the
trigger
should
be
applied
on,
and
one
of
the
issues
with
this
set
is
that
every
time
you
we
would
like
to
propose,
a
new
property
is
a
new
way
to
select
content.
F
We
would
need
actually
a
new
version
of
it
of
the
triggers,
so
what
we
popularity
practically
did
is
pushing
it
to
a
generic
list
of
trigger
specs
next
weeks.
F
F
Okay,
both
of
those
lists
are
now
flexible
and
Engineering.
We
can
register
small
types
to
work
on.
Next
is.
F
F
F
So
if
we
look
at
the
entire
figure-
and
it's
you
in
the
trigger
V2
in
the
new
structure,
it
has
an
action.
It
has
a
list
of
specs
that
whatever
element
matches,
one
of
the
specs
would
be.
The
action
would
be
applied
on
okay.
So
in
this
case,
where
we
would
work
on
a
metadata
with,
we
will
preposition
the
metadata
with
this
URL
and
content
with
those
two
area.
F
F
F
So
what
we
would
like
to
present
to
suggest
and
change
is
making
for
consistency
and
of
the
instruction
for
structural
consistency.
F
We
would
like
to
consider
to
move
a
all
objects,
also
the
URLs
to
a
dictionaries
style,
a
list
and,
to
be
honest,
only
a
an
hour
ago
when
I
we
first
ago,
I
went
again
over
the
presentation.
I
started
to
think:
maybe
they
also
they
block
before
that
is,
is
not
needed.
If
can
I
pointed
at
the
URLs
and
the
patterns
a
token
can
be
removed,
so
just
have
a
list
of
values
of
of
dictionary
similar
to
the
footprint
API
and
with
what
we
have
in
the
footprint
API
and
I.
F
Don't
I'm
not
sure
you
are
following
what
I'm
saying
here,
because
it's
not
in
the
in
terms
of
the
presentation
but
I
think
it
might
be
even
cleaner
to
do
that
and
to
remove
the
URLs
and
patterns
to
those
tokens
and
just
have
the
list.
C
Does
the
dictionary
mean
that
you
can
support
multiple
like
free
kind
of
custom
values
in
those
or
not.
F
The
the
structure
of
the
of
the
dictionary
is
is
well
defined,
a
pair,
a
spec
type
and
and
that
that
it's
not
it's
the
fact
that
the
perspective
you
can
actually
argue,
okay,
push
the
Specter
itself
into
the
dictionary,
but
I
think
it
would.
It
would
be
less
sick,
less
comfortable
here.
C
My
guess,
my
question
is,
maybe
you
address
it
later
or
the
different
spot
is
that
we
see
a
need
for
basically
custom
values
for
triggers
custom
attributes.
Is
it
something
that
this
will
address
or
not.
F
And
can
you
give
an
example?
It
won't
invest
that,
but
we
can
add
an
open
list
of
something
or
if
there
is
specific
specs
that
needs
this.
The
flexible
attribute
list.
We
can
just
add
a
dictionary
within
it
additional
within
the
dictionary,
but
if
you
I
would
be
glad
to
if
you
have
a
good
an
example
for
that.
C
Yeah
so
so,
for
for
in
in
kind
of
we
were
looking
at
the
as
part
of
the
kind
of
content
management,
cash
management
spec
again
at
svta,
we're
looking
at
various
ad
hoc
or
custom
attributes
that
would
be
added.
For
example,
bandwidth
policies
around
prepositioning
right
right
do
preposition,
but
do
it
only
on
Sundays
per
position,
but
use
no
more
than
100
gigabits
or
100
megabits
per
position
by
then
they
do
this
by
in
seven
days.
C
F
It's
I'm
glad
to
use
the
term
extend
them,
because
this
is
basically
what
the
trading
trigger
extensions
does
and
I
haven't
referred
to
that
because
it
didn't
want
to
overload
the
session,
but
the
first
when
we
started
to
work
on
the
on
this
on
the
LFC,
and
we
actually
had
the
draft
that
we
was
a
standalone
draft
with
that
adding
the
trigger
extensions,
and
that
allows
you
to
specify
that
you
want
want
that.
F
We
got
to
be
called
to
run
to
be
executed
on
a
Friday
night
at
2
am
only
in
Brazil,
okay
and
the
extension
is
also
generic
and
you
can.
We
can
redefine
more
and
more
extension
extensions.
This
is
part
of
it
was
integrated
into
this
RFC
and,
if
you
see
you
I
would
I
would
be
glad
if
you
will
review
that
and
if
you
had
any
additional
idea
for
additional
extensions.
Let's
add
them,
let's
already
add
them,
add
them
into
this
RFC
and
that
would
be
valuable,
I.
C
You
actually
take
into
different
directions
than
I
was
thinking
I.
Think
I
was
thinking
kind
of
I
stand
the
attributes
of
this
trigger,
which
you,
you
kind
of
you
say,
hey.
We
want
to
restructure
the
way
we
do
this.
We
wanted
the
dictionaries,
let's
kind
of
Define
trigger
payload
different
kind
of
differently
and
I
was
thinking
hey.
We
want
to
provide
a
way
to
to
easily
add
values
to
the
triggers
of
specific
types.
C
Without
you
know,
changing
respect,
but
you're,
saying
also
something
else
that
maybe
that
maybe
I'll
actually
a
whole
different
Dimension
is
how
do
you
run
triggers
I
want
to
run
triggers
repeatedly.
I
want
to
run
triggers
a
certain
time,
which
is
not
what
what's
in
the
trigger.
But
how
do
you
run
that
which.
F
So
this
is
also.
This
is
also
the
already
in
the
draft.
It's
a
presented.
It
is
presented
there
and
if
we,
you
see
what
the
spec
practically
needs
to
come
to
specify
what
to
run
so
if
you
have,
and
there
are
patterns
and
vertexes,
and
what
about
eight
types
of
specs,
if
you
think
there
is
a
need
to
an
additional
spec
of
one
of
those
specs
to
be
extended
with
an
open
list
of
properties
or
something
like
that,
we
can.
F
Items
to
continue
there
yeah,
so
what
ahead
of
us
and
what's
we
first
of
all
over
I,
would
like
to
make.
We
would
like
to
make
the
change
of
of
the
structure
of
the
specs
of
the
URL
and
the
ccid,
and
then.
F
C
By
the
way,
thank
you
Kevin
for.
F
The
shepherding
in
the
footprint
RC
putting
type
of
thing,
I'll,
see
you're.
B
Welcome
looking
looking
forward
to
reading
the
updated
draft
and
I
encourage
everyone
when
they
see
it
come
out
on
the
list
to
please
review
it,
there's
a
lot
of
good
stuff
in
there
and
we
want
to
try
and
get
it
right.
This
time.
H
In
today's
episode
of
hot
drafts
from
the
CTA,
we
have
the
streaming
media
tracing
next
slide
talk
about
who
they
are,
if
you're
not
familiar
already,
and
what
we're
working
on
and
why
you
might
care
next
slide.
H
So
this
is
work
being
done
out
of
the
CTA,
the
consumer
technology
Association,
their
wave
or
web
application.
Video
ecosystem,
the
wave
subgroup
and
the
primary
motivating
use
case
for
this
is
streaming
media,
but,
as
you
will
see,
it
may
find
itself
more
broadly
useful
or
it
may
not
depending
is
the
work
develops.
H
The
ultimate
goal
of
this
particular
group
is
interoperable
tracing,
specifically
interoperable
tracing
for
streaming
media,
but
it
turns
out
that
streaming
media
isn't
that
different
when
you
just
do
it
over
HTTP,
so
there
may
be
some
interesting
utility
next
slide.
H
So
right
now
we're
near
the
very
beginning
of
the
process.
We've
scoped
out
the
work
that
we
want
to
accomplish,
and
we've
determined
that
there
are
basically
three
big
legs
of
this
work.
There
is
the
pole,
the
push
and
the
export,
so
Paul
is
the
stage
of
a
request.
H
H
The
second
piece
is
a
little
bit
less
well
understood,
but
the
basic
idea
is
that
Origins
don't
get
their
content
from
nowhere.
Usually
their
content
comes
from
some
sort
of
a
processor
that
may
or
transcoder
something
that
that
modified
the
data
and
that
got
it
from
some
sort
of
a
source.
H
Very
often,
if
we're
talking,
for
example,
video
content,
it
may
have
come
from
a
camera
if
we're
talking
about
audio
content,
a
microphone,
and
we
would
really
like
a
interoperable
way
to
move
this
data
around
in
a
way
that
moves
with
the
data
as
metadata
on
the
on
the
envelopes
and
lets
us
measure
latencies
identify
problems.
H
H
We
aren't
quite
sure
what
this
is
going
to
look
like.
There's
a
solid
chance,
it's
going
to
look
a
lot
open
telemetry-ish,
but
the
work
group
hasn't
actually
started
really
digging
into
that.
So
that's
just
a
just
a
guess
at
this
point
next
slide.
H
So
right
now
we're
at
the
beginning
of
the
poll
part
of
the
stage,
which
means
we're
defining
requests
and
response
headers
for
HTTP.
In
particular,
we
have
a
request
header
that
provides
visibility
into
the
request
chain
so
that
when
An
Origin
receives
a
request,
it
knows
roughly
speaking
what
route
it
took
to
get
there.
We
have
a
response
field
that
provides
visibility
under
the
response
chain
when
a
client
gets
a
response.
H
The
client
then
knows
what
the
entities
responsible
for
preparing
that
response,
for
it
are
they
both
use
structured
field
values
and
they
represent
a
graph
of
the
trace,
and
this
graph
concept
turns
out
to
be
really
important
because
all
of
the
existing
processes
and
and
headers
that
we
would
talk
about
like
this
things
like
the
cache
status,
header
and
the
proxy
status
header
and
the
cmsdynamic
header
and
the
Via
header.
Even
those
are
all
the
glutenative
headers.
H
They
just
add
up
as
you
go
and
that's
fantastic
and
it's
valuable,
but
it
only
captures
the
successful
part
of
the
trace.
It
captures
one
linear
representation
of
how
the
data
got
from
origin
to
client
or
vice
versa,
and
so
one
of
the
things
that
we
want
to
make
sure
that
we
support
here
in
this
particular
work
is
we're
trying
to
represent
the
graph
of
the
trace,
which
includes
the
unsuccessful
flows.
Next
slide.
H
So
the
format
that
we
have
and
to
be
clear,
our
group
has
not
fully
reached
consensus.
This
is,
in
fact,
a
work
in
progress,
so
this
structure,
this
uses
structured,
headers
and
the
field
is
a
list
of
sub-lists.
H
Each
element
of
the
list
is
a
server
intermediary
or
client.
Basically,
a
participant
in
the
HTTP
flow.
H
Each
element
of
the
sub
lists
represents
one
of
their
requests,
which
may
or
may
not
have
been
successful
a
h,
an
intermediary
that
simply
attempts
to
make
a
request,
upline
and
never
gets
a
response
to
the
ACT.
That's
useful
information
would
like
to
be
able
to
store
it
in
the
flow,
and
so
just
because
there's
a
request
doesn't
mean
there
was
a
response,
for
example,
sub-list
elements,
so
these
are
the
elements
of
the
sub
lists
are
relative
indices
that
indicate
the
target
of
the
request.
H
I
am
not
going
to
go
into
deep
detail
on
this,
but
this
is
what
a
full
chain
might
look
like
if
it
were
exported
from
a
client.
You
kind
of
read
it
bottom
to
top.
The
client
is
at
the
bottom.
You
can
see
that
it
has
one
element
of
its
sub
list:
zero.
That
says
it
made
one
request.
That
request
was
to
the
thing
directly
above
it
the
in
the
the
the
element.
The
item
marked
intermediary.
H
That
has
two
elements
in
its
sub
list:
zero
and
one
that
tells
you
that,
in
order
it
requested
zero,
which
is
to
say,
origin,
a
and
one
origin
B.
It
didn't
give
us
any
information
as
to
why
it
requested
multiple
things
or
or
why
originate
failed
or
any
of
that,
but
it
tells
us
what
the
shape
of
things
looks
like,
and
you
can
see
if
you
were
to
draw
that
out
in
a
graph
what
it
might
look
like
on
the
right
next
slide.
H
You
can
add
data
to
this
lots
of
data,
we're
not
going
to
dig
into
this,
but
you
can
see
timestamps,
you
can
see
durations.
You
can
see
times
to
cancel.
You
can
see
that
some
of
the
things
might
have
been
synthetic
because
I
never
reached
them
in
the
first
place,
lots
of
good
information
and
we're
considering
you
know
we're
currently
scoping
out
what
all
of
the
types
of
information
we're
going
to
store.
Obviously,
timings
and
latencies
are
super
valuable.
H
H
So
we're
still
near
the
beginning
of
the
poll
stage
we're
working
on
the
details
of
the
data
format.
Nothing
is
set
in
stone,
I'm,
not
even
sure
it's
set
in
mud,
yet
we're
starting
with
the
timing
data,
but
we're
expanding
to
store
many
more
additional
formats
of
data.
H
We
are
looking
at
the
aforementioned
glutenative
headers
to
see
what
for
what
pieces
of
those
data,
it
is
useful
to
define
whether
we
can
simply
delegate
to
those
headers
and
their
formats
and
their
their
definitions,
because
we'd
like
to
not
reinvent
anything
that
doesn't
require
Reinventing
and
we'll
be
defining
more
as
we
go
next
slide.
H
Why
do
you
care?
Why
am
I
talking
in
front
of
this
room?
There
will
be
eventually
configuration
elements.
Cb
and
I
may
find
it
useful
to
allow
these
elements
to
be
configured
it
may
not.
That
will
be
something
that
will
be
useful
to
determine
at
some
point
in
the
future.
This
streaming,
media
tracing
will
eventually
offer
export
logging.
H
These
interfaces
are
likely
to
be
of
interest
it's
hard
to
tell
what
they're
going
to
look
like
they
may
fit
in
to
see
the
uni
shape
logging
things.
They
may
look
open,
telemetry-ish,
we're
not
sure,
but
we
want
to
make
sure
that
you
can
be
part
of
the
conversation.
If
you
wish
next
slide.
A
I'm,
sorry,
we
can't
have
questions.
We're
gonna
have
to
take
it
in
the
mailing
list.
I
do
want
to
give
some
time
to
to
Alan,
as
he
had
requested
some
time
on
the
open
mic
to
see
what,
in
a
few
minutes
that
he
has
thank.
J
C
Thanks
Andre,
so
I
share,
slides
kind
of
kind
of.
Did
you
get
that
on
Sanjay.
C
C
Yes,
right.
C
A
A
C
Yes,
do
you
I
really
want
to
share
my
screen?
Yes
share:
okay,
it's
kind
of
recursive
and
that's
a
topic
so
very
quickly.
C
C
So
I
just
wanted
to
look
at
a
quick
heads
up
on
the
work,
we're
doing
and
that's
coming
up
a
problem
statement
and
why
we
are
doing
what
we're
trying
to
do
is
number
of
group
members
kind
of
came
to
to
the
front
saying
that
kind
of
we
need
to
include
embrace
our
cursive
request:
routing
httpr
and
the
open
caching,
implementations
and-
and
there
are
a
number
of
motivations
one-
is
a
latency
reduction.
C
You
can
see
on
the
right
kind
of
schematic
description
of
delegation
today,
let's
say
a
practical,
open.
Caching
implementations
utilize
iterative
process
which
requires
the
user
to
go
to
ucdn,
and
then
you
see
the
end
in
some
shape
or
another
depending
on
the
method.
Redirects
the
users
to
dcdn.
So,
by
using
recursive,
we
seek
to
reduce
latency
so
that
we
fewer
round
robin
trips
kind
of
rtt's
kind
of
back
and
forth.
C
Additionally,
the
motivations
are
around
ucdn
wanting
to
retain
control
over
what
get
delivered
to
the
user
in
iterative
approach.
The
content
gets
served
by
the
user
by
the
dcdn
and
without
any
visibility
and
ucdm
may
Implement
some
logic
that
it
wants
to,
for
example,
server
side
ad
insertion
where
the
they
want
to
utilize
some
control
over
what
gets
delivered.
Ultimately,
I
want
to
consult
the
dams
from
CDN,
but
want
to
be
in
control,
and
last
motivation
is
session
by
session.
C
The
mission
control,
where
kind
of
ucdn
dcdn,
wants
to
admit
a
session
by
session,
as
opposed
to
kind
of
bulk
about
delegation
that
happens
in
the
iterative
approach.
So
that's
a
motivation
when
we're
looking
at
what's
cdni
specified
until
now,
it's
RFC
7975
and
it
Embraces
both
DNS
recursive
and
HTTP
recursive,
and
the
way
it
works.
A
very
high
level
is
that
UCD
and
dcdn
exchange,
kind
of
Json,
encoded
requests
and
responses
over
some
control,
plane
and
kind
of
it
has
several
deficiencies.
C
So,
first
of
all
that
only
delivers
basic
fields
of
the
request.
In
many
cases
we
want
to
see
all
of
the
requests
to
make
a
decision.
C
They're
really
no
latency
reduction
because
kind
of
there's
no
ability
for
dcdn
to
deliver
the
response
to
be
sent
right
away.
So
usually
that
would
mean
dcdn
tells
you
CDN,
oh,
go
to
this
destination,
send
the
user
to
this
destination,
so
really
no
latency
gain
still
has
to
be
redirection,
pretty
complex
to
implement,
because
that's
you
kind
of
really
encoding
requests
over
some
custom
protocol.
C
Many
situations
not
desirable,
so
you
just
really
want
to
forward
request,
as
opposed
to
pre-encoded
in
some
kind
of
ad
hoc
format,
and
it
only
delivers
requests
to
the
dcdn
and,
as
you
will
see
next,
in
some
cases,
responses
needed
as
well.
So
out
of
this
we're
proposing
a
kind
of
updated
request,
routing
interface-
and
these
are
the
key
features.
First
of
all,
we
kind
of
common
HTTP
s
based
open
caching
interface.
C
It
will
provide
backward
compatibility
for
RFC
7975
flare
of
the
this
kind
of
Json
messaging
only
is
because
we
want
to
support
dnsr,
and
this
is
the
way
to
do
this
kind
of
I.
Don't
know
how
much
practical
value
there
is,
but
I
think.
Certainly
we
want
to
support
both
DNS
and
HTTP
recursive.
C
The
main
difference
or
change
is
that,
as
opposed
to
encoding
requests
and
some
format,
we
want
to
actually
forward
you
see
in
the
dcdn
exchange,
requests
and
responses,
as
is
so
latency
can
be
reduced,
so
kind
of
request
forwarded
to
dcdn
dcn
can
respond
and
ucdm
can
send
the
request,
as
is
down
to
the
user.
So
we
were
gaining
the
latency
and
simplify
implementation.
C
Really
something
can
be
done
in
a
kind
of
in
a
pretty
standard
kind
of
cache,
cache
proxy
chain
mode,
as
opposed
to
kind
of
creating
some
form
of
control
plane
protocol,
which
is
what
RFC
7975
proposes.
So
ucdn
may
forward
the
dcdn
response
to
the
user
without
change,
because
the
implementation
makes
it
easier
and
then
straightforward.
C
We
saw
two
different
modes
that
are
needed
for
operation
kind
of
depending
on
how
dcdn
is
provisioned
and
configured,
and
then
one
is
in
request
mode
where
a
ucdn
gets
request
from
the
user
sends
a
request
to
to
dcdn
dcdnx
on
it
and
usually
that
will
require
dcdm
to
have
independently
configured
to
get
content
from
somewhere
from
the
origin
from
ucdn
and
so
on
and
so
on,
and
there
is
kind
of
so
there
is
a
kind
of
a
really
a
proxy
chain
that
gets
created
in
response
mode,
a
situation
where
dcn
doesn't
have
independent
access
to
the
content,
or
there
is
some
custom
logic
that
is
is
happening
on
your
CDN.
C
So
in
this
case,
ucdn
will
supply
not
just
a
request,
but
also
the
response
as
ucdn
would
send
it,
and
then
the
CDN
would
act
on
that
and
the
spec
proposes
kind
of
support
for
both
and
also
Dynamic
change
from
one
another.
You
can
ask
you
can
start
by
asking
for
for
giving
the
request
and
this
again
say:
well:
hey
yeah
and
I
got
it
I,
don't
have
enough
information.
Please
give
me
the
response
you
would
have
given
to
the
user.
C
So
then
I
can
tell
you
how
to
change
that
or
or
and
or
can
I
support
that
not
going
into
a
lot
of
detail
here.
Take
a
lack
of
time
or
something
I
guess
we'll
we'll,
hopefully
do
the
next
next
session.
But
there
is
a
detailed
kind
of
diagram
of
the
request.
Mode
kind
of
will:
support,
HTTP,
302
redirection
and
manufactory
right
from
the
dcdm,
so
ucdn
can
give
the
request
to
to
the
DCd
and
the
dcdn
can
just
respond,
yeah
sure
kind
of
get
it
here
is
a
response.
C
Please
provide
it
for
me
or
and
including
change
of
the
content
and
can
be
302.
It
can
be
also
error.
Conditional,
like
I
I,
cannot
support
that
sorry
kind
of
that's
not
a
session
I
can
support,
but
we
talked
about
granular
session
control.
That
would
provide
a
way
to
do
that
and
it
can
also
provide
dynamically
say
well,
get
it,
but
I
don't
have
enough
information.
C
Please
give
me
the
response
as
well,
which
takes
us
over
to
the
next
mode,
where
a
ucdm
provides
a
response
to
dcdn
and
then
dcdn
makes
a
decision
decision
on
any
of
the
changes
it
wants
to
do.
Let's
say
manifest:
rewrite
or
content
compression
or
decisions
for
delegation
redirection
that
are
based
on
the
response
request.
Not
enough.
You
can
understand
that
what
kind
of
size
the
objects
are
you
know
maybe
mine
type,
and
you
can
decide
whether
you
want
to
to
redirect
this
content
to
dcdn
or
not.
C
So
that's
a
high
level
right
again,
we
will
bring
you
forward.
The
the
spec
it's
in
final
form,
now
going
to
svta
review
as
well,
and
we'll
welcome
comments
and
now
working
with
the
group
to
to
getting
this
into
cd9.
A
Okay,
so
I
think
we
are
a
few
minutes
over.
So
I
really
appreciate
everybody's
time.
I
know
it's
Friday,
it's
it's
late
here
in
the
UK
and
late
afternoon
and
I
know
it's
early
in
the
morning
in
some
of
you
are
that
are
in
the
US
and
probably
late
in
the
day
somewhere
else
that
you're
on
the
east
side
of
the
continent,
but
I
really.
Thank
you.
A
Everybody
great
session
and
I
I
really
encourage
that
those
who
could
not
ask
questions
to
go
onto
the
mailing
list-
and
you
know,
put
your
question
in
on
any
of
the
drafts
that
you
heard
or
or
presentation
from
Chris
and
from
Alan
so
feel
free
to
do
that
and
Ellen.
A
A
Shortly,
yes,
Kevin
anything,
you
want
to
add
nope.