►
From YouTube: IETF111-CDNI-20210727-2130
Description
CDNI meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
All
right,
let's
get
started
pretty
good
group,
so
this
is
cdni
content
delivery
network
interconnect,
if
that's
the
group
you're
expecting
to
be
in
welcome,
if
not
you're,
also
still
welcome.
First
up
the
notewell.
Everybody
should
have
seen
this
before.
These
are
the
rules
by
which
you
agree
to
participate
in
the
ietf
and
how
deals
with
intellectual
property.
So
if
you
haven't
read
it,
you
should
read
through
all
this,
but
well
that
you
agree
to
all
of
this.
A
So
this
is
cd
and
I
we
haven't
met
since
bangkok,
so
it's
been
a
while
ietf103,
but
we're
happy
to
be
back
with
a
live
session.
As
you
all
know,
from
the
list,
phil
sober
sorber
stepped
down
and
he
was
replaced
by
sanjay,
mishra
and
so
we'd
all
like
to
thank
phil,
for
you
know
the
work
that
he
put
in
and
thank
sanjay
for
stepping
up
to
be
our
new
co-chair.
A
So
we
have
one
session
today
we
only
have
an
hour
and
we
have
a
lot
of
stuff
to
get
through,
so
we'll
try
and
get
through
it.
Quick
blue
sheets
are
taken
care
of
by
me,
echo.
If
anybody
wants
to
volunteer
to
be
a
jabber
scribe
or
a
minute
taker,
that
would
be
great.
I
will
also
be
taking
notes
as
well,
but
I
will
get
us
to
the
agenda.
A
Oh
first
working
group
milestones
so
actually,
interestingly
enough,
we
we
have
been
doing
work
even
though
we
haven't
been
meeting
since
the
last
iatf.
We
did
finish
the
request,
routing
extensions
and
it
was
published
as
rfc
8804.
A
You
can
see
that
we
have
three
additional
milestones
that
we
agreed
to
uri
signing
has
been
submitted
to
the
iesg
and
phil's
gonna,
give
us
a
quick
update
and
then
last
time
we
adopted
two
new
drafts,
which
were
the
https
delegation
which
frederick's
going
to
talk
to
us
about
and
the
cdni
control
interface
the
triggers
updates,
which
nier
is
going
to
talk
about
today.
B
Wants
to
just
just
a
quick
thing:
can
we
get
someone
to
do
the
scribing
for
us?
Did
we
get
confirmation
as
to
anybody
who's,
taking
the
notes
for
the
meeting
any
volunteer.
A
B
B
A
I
I'll
I'll
handle
the
notes
afterwards,
if
no
one
else
really
wants
to
do
it,
but
I'm
gonna
try
and
keep
moving
this
board
since
we
we
do
have
a
packed
agenda,
so
phil
will
give
us
an
update
on
uri.
Signing
frederick
will
give
us
an
update
on
hbs
delegation.
A
E
Good,
thank
you
all
right,
uri
signing
the
never
ending
story.
It
was
in
last
call
back
in
february
we
had
some
feedback
from
mnot.
E
E
They
were
very
concerned
about
client
ip.
I
have
four
asterisks
there,
because
there
were
actually
four
different
people
that
had
something
different
to
say
about
that
primarily
about
the
usefulness
and
privacy
concerns.
So
usefulness
is,
like
you
know,
somebody's
behind
that
or
they
switch
from
wi-fi
to
mobile
or
stuff
like
that.
You
know.
Was
this
something
really
useful
and
then
also
privacy
concerns?
Obviously
people
were
happy
that
we
were
encrypting
things,
but
they
still
were
concerned
about
it.
E
We
do
also
have
public
key
crypto,
but
we
we,
I,
I
think,
really
the
problem
that
it
comes
down
to
is
that
we
talk
about
client,
ip
and
shared
keys
at
the
forefront
and
then
kind
of
also
talk
about
other
things,
and
I
think
they
would
prefer
that
it
would
be
the
other
way
around
like
okay.
We
know
you
guys
need
to
support
this,
because
people
want
it,
but
let's,
let's
de-emphasize
it
and
also
you
know,
insecurity
concerns
really
detail.
E
They
asked
why
wasn't
it
must
and
and
what
what
was
some
advice
to
implementers
as
to
when
they
could
ignore
the
should
so
I
I
think
I'm
gonna
have
to
look
through
those
and
and
either
come
up
with
reasons
why
people
would
want
to
ignore
them
or
upgrade
them
to
must,
and
there
was
also
a
lot
of
concern
about
the
advice
to
the
designated
experts.
I'll
be
honest:
personally,
I
had
a
lot
of
trouble
coming
up
with
what
kind
of
advice
we
would
want
for
when
adding
new
claims
in.
E
So
if
anybody
has
any
any
input
there,
that
would
be
helpful.
The
other
feedback
we
got
was
from
a
member
of
this
working
group.
Chris
lemmons
lemons,
so
part
of
the
mnot
feedback
was
about
removing
the
way
we
specified
the
the
uri
attribute
in,
and
so
we
removed
that
and
basically
just
said,
use,
pastel
or
query
style
parameters.
E
Chris
is
concerned
about
the
fact
that
we
have
this
as
a
must,
but
we
don't
actually
have
points
any
document
that
talks
about
how
to
parse
those.
So
I
think
we
came
up
with
the
solution
where
we're
basically
going
to
reference
the
output
of
the
uri
template
roc,
I
I
don't
see
a
problem
with
it.
It
I'll
be
honest.
It
feels
a
little
weird
because
we're
we're
there's
nothing
in
there
that
talks
about
how
to
actually
interpret
that,
but
at
least
it's
something
more
tangible,
so
yeah
and
also
the
timeline.
E
I
didn't
put
a
bullet
for
this,
but
I
so
I'm
I'm
working
on
this
now
completely
on
my
on
my
own
time.
Work's,
not
supporting
me
they're,
not
paying
me
to
be
here
today
and
being
able
to
get
out
this
summer
and
not
be
stuck
in
a
house,
was
much
more
attractive
than
working
on
this
draft.
So
it's
it's
been!
E
That's
why
it
has
taken
so
long
after
last
call
to
get
to
these
things,
so
I'm
still
planning
on
working
on
it
but
yeah.
That's
where
I'm
at
any.
A
Questions,
so
do
you
think
that
do
you
have
a
time
frame
in
which
you
think
we
can't
get
to
this?
Can
we
get
this
done
by
next
ietf.
E
Yes,
I
think
I
mean
that's
three
months
from
now
four
months
from
now
right
yeah.
I
think
we,
I
think,
that's
reasonable.
I
mean
I
really
it's
been
about
me
not
having
enough
side
time
and
being
able
to
go.
Do
things
this
summer,
while
the
weather's,
nice
and
everything
and
four
months
from
now,
I
don't
think
that's
going
to
be
a
problem.
In
fact,
we
might
not
even
be
able
to
go
out
four
months
from
now
the
way
things
are
looking
some
places.
F
D
H
A
That
would
be
great
if
anyone
has
suggestions
that
they
want
to
submit
a
pr
for
any
help
that
we
can
give
phil
would
be
awesome.
E
And,
and
also
if
anybody
looked
through
the
comments
from
last
call
from
the
iesg
and
has
any
any
feedback
or
anything
that
they
wanted
to
share
with
me
to
respond
to
them
or
to
make
changes
in
the
document
feel
free
to.
Let
me
know.
A
All
right,
there
are
no
other
comments
thanks.
Thank
you.
Phil
next
up
is
frederick
share,
some
slides
for
you,
and
you
have
five.
D
Okay,
hi
everybody,
so
I'm
presenting
the
status
of
our
drafts.
D
Cdna
interfaces,
https
delegation
next
slide
piece,
just
a
quick
reminder
today,
at
the
currently
at
the
ietf,
we
have
a
bunch
of
delegation
methods
ongoing
which
are
the
rfc87,
which
is
star
the
star
delegation.
D
So
our
draft
basically
is
using
those
I
mean
try
to
refer
to
those
dedication
methods,
so
this
draft
we
are
presenting
here
is
to
allow
the
bootstrapping
of
the
content
delivery
delegation
for
those
certificate
based
content,
negation
methods
between
a
ucdn
and
a
delegate
gcd.
D
D
So
we
have
an
example
below
here.
We
can
see
that
the
past
metadata
is
extended
with
a
generic
metadata
type
which
you
can
on
which
you
can
provide
the
acme
star
delegation
method.
In
this
example,
then
you
provide
a
bunch
of
parameters
that
will
be
able
to
that
will
be
needed
for
the
ucdn
to
bootstrap
the
delegation
to
a
dcdn.
D
Next,
like
this,
so
what's
next
about
that,
we
have
in
mind
of
prototyping
this
draft
to
increase
a
bit
the
to
reinforce
the
draft
a
bit,
and
for
that
we
need
some.
Maybe
some
additional
people
and
the
second
step
would
be
the
working
group
lascaux.
So
I'm
pretty
confident
that
the
draft
is
he's
quite
ready
for
that.
So
but
yeah
it's
up
to
it's
up
to
you.
A
On
that
last
point,
do
we
think
that
we
are
ready
for
last
call,
I
think,
the
last
time
we
talked
about
this,
we
were
still
wondering
about
the
dependencies
for
the
for
the
metadata,
the
protocols
for
which
we
are
adding
metadata
and
what
was
their
maturity
status
and,
if
they're
already
or
whether
some
need
to
be
split
out
of
this
draft,
or
is
it
just
the
acting
star.
D
Yeah,
the
acme
star
is
rfc,
so
it's
a
pretty
yeah
finished
but
yes
for
the
delegated
credentials
is
concerned.
I
don't
know,
I
don't
know
whether
the
the
draft
will
be
I'll
see
soon
or
not,
but
yeah.
I
agree
with
this.
A
I
H
Okay,
go
frederick
question:
why
do
you
attach
the
new
objects
to
the
path
match.
D
Well,
it
was
our
first
idea
was
to
I
mean
to
restrict
the
scope
of
the
delegation
into
a
specific
pass
on
the
url,
but
so
far,
if
you
have
any,
I
mean
better
idea
for
extending
the
scope,
then
it
would
be
pleased
to
to
add.
H
Okay,
it's
just,
I
don't
think
it
should
be
mutually
exclusive.
I
mean
you
can
you
can
do
that
for
the
path
match,
but
why
not
having
the
options
to
select
a
method
for
also
the
entire
the
entire
horse
meter
that
a
horse
match.
H
D
H
Could
explain
so?
Is
it
still
the
times
to
bring
to
you
some
modification
or
because
I'm
not
very
familiar
of
about
the
status
of
this
of
the
draft,
because
you
were
saying
that
it's
almost
done.
H
A
H
No,
I
think
the
this
subject
was
part
of
the
svm
and
it
wasn't
in
the
one
of
the
sva
points
or
subject
of
interest
anyway
and
and
and
merbra
pick.
We
are
very
interested
in
in
that
topics
also,
so
that's
why
I
maybe
bring
some
suggestions
to
it
and
answer
a
bit,
the
the
actual,
the
current
draft
yeah.
Thank
you.
Excellent
thanks.
B
Yes,
real
quick
without
the
the
chair
head
on.
I
just
wanted
to
circle
back
that
we
may
have
to
split
this
document,
because
the
delegated
credentials
is
still
waiting
for
for
the
chair
for
the
the
tls
chair
to
go
ahead,
and
you
know
propose
that
into
a
standard,
so
not
sure
what
the
timing
is
and
what
the
hold
up
there
is.
So
potentially
this
could
be
split
and
then
revisit
again
when
the
tls
is
out
of
seat.
A
I
would
encourage
the
authors
to
to
take
that
suggestion
and-
and
we
can
discuss
that
yeah-
I'm
going
to
have
to
cut
you
off
because
we're
five
minutes
behind
already
and
I
want
to
get
to
the
rest
of
the
presentations
I
apologize.
Okay,
but
near
is
up
next
with
triggers.
I
Hi
there,
hello,
hi
hi,
all
thank
you
for
joining,
so
my
name
is
affair.
I'm
a
software
engineer
at
quilt
and.
I
Okay,
let's
just
start
as
part
of
sitting
a
quilt
is
part
of
the
founding
member
of
the
sva
and
actually
in
the
context
of
open
caching,
and
we
we
got
to
some
experience
within
implementing
some
of
those,
the
offices
we
rely
heavily
on
and
found
some
thing
to
improve
some
items
to
improve
and
specifically
in
rfc
807
in
the
cdna
control
interface.
I
So
just
a
quick
recap:
the
cdna
control
interface
allows
the
option
cdn
to
manage
content
and
metadata
held
by
the
dance
see
then
it,
for
example,
preposition
or
a
purge
of
content
and,
as
you
can
see
in
the
visual,
the
basic
flow
starts
with
the
absolute
and
approaches
approaching
the
dancing
cdn,
with
a
request
for
creating
a
trigger,
which
is
actually
the
command
to
be
done
to
be
executed.
I
The
downloaders,
as
well
as
generating
the
twigger
id
and
reply
to
the
option
sitting
with
the
id
that
which
allows
the
ops
incident
to
keep
on
monitoring
the
trigger
execution,
while
done
by
the
dance
recident
and,
as
you
may
already
know,
sanjay
and
ori.
I
worked
on
a
in
a
draft
that
had
some
improvements
today
and
this
control
interface.
This
the
draft
was
already
adopted
right
by
this
forum.
I
So
the
first
edit
functionality
and
with
this
draft
is
the
trigger
extensions.
The
a
rc807
they
trigger
a
trigger
object.
Object
is
built
of
a
close,
closed
set
of
two
properties,
and
there
is
no
mechanism
for
adding
additional
information
or
instruction
instruction
on
how
to
execute
the
two
different
triggers.
I
I
So
the
drafts
suggest
a
new
generic
extension
mechanism,
similar
to
rfc
806
with
the
generic
metadata
and
where
the
twitter,
the
version
2
of
the
trigger
alden,
is
a
property
of
having
a
list
of
extensions,
and
this
is
an
open
list.
So
and
once
we
define
more
and
more
extensions
and
we
don't
need
to
change
the
interior,
object,
a
format
or
create
a
new
version
of
it.
We
just
we
need
just
to
register
the
new
extensions
and
the
first
two
extensions
to
be
registered
are
the
time
and
location
extensions.
I
And
the
second
addition
by
this
rfc
by
this
draft
is
adding
the
cdn
id
to
the
error
when
properly
when
a
returned
as
part
of
the
status
request,
and
as
can
as
you
can
see
in
the
visual
in
the
sequence
diagram,
there
are
situations
that
the
trigger
needs
to
be
propagated
from
one
or
more
cdn
to
the
others
to
another,
and
in
this
case
the
absence
cdn
and
send
the
trigger
to
the
trial
to
a
transition
that
send
that
propagates
it
to
a
a
downstream
sedan
and,
in
the
case
the
trigger
fails
at
one
of
the
domestic
cities.
I
I
I
And
the
last
addition
in
the
in
the
adopted
draft
is
new
content,
selection
methods,
I've
seen
the
origin
rfc
already
defined
quite
a
few.
A
content
or
method
select,
metadata
selection
method,
urls
patterns
and
the
dwarfs
suggest
two
new
methods
methods,
one
since
the
regular
expression
and
the
other
is
the
playlist
hls
dash
just
following
the
manifest,
and
so
the
twiggle
v2
object
is
now
a
new
property,
which
is
the
content
regex
or
the
content
playlist,
which
which
actually
brings
me
to.
I
We
will
need
to
change
the
to
create
a
new
version
of
the
trigger
object
and
I
think
it
would
be
preferable
to
all
the
an
object
list
that
can
be
an
open
list
that
that
all
that
old
generic
trigger
objects
that
specify
which
content
or
method
that
we
need
to
work
on
that
we
can
need
to
be
executed
on,
and
this
will
give
us
the
benefit
that
every
time
a
new
content
selection
method
is
introduced,
it
will
not
would
just
need
to
add
it
to
the
registry
and
not
change
the
trigger
object.
I
And
please
note
that
this
is
a
new
suggestion
suggestion.
It
was
not
adopted
by
the
walking
group
before
and
I
would
be
happy
to
further
discuss
it.
But,
first
of
all
I
would
like
to
adopt
the
new
the
new
task
we
have
please.
I
Okay
and
so
implementing
all
the
proposed
modifications.
The
next
step
is
to
publish
a
second
edition
of
this.
The
control
interface
rfc,
as
all
changes
were,
were
integrated
in
integrated
and
merged
into
the
original
rfc,
and
that
and
we
create
a
current
and
simple,
a
more
simple
document
that
can
be
followed
and
it
should
be
safe
to
obsolete
rfc
807,
as
all
the
information
would
be
in
the
new
draft.
I
So
before
I
open
these
four
questions,
I
would
like
to
ask
the
chairs
whether
these
tasks
can
be
accepted
as
a
working
working
group
draft.
A
I
think
that
it
makes
sense.
We
we
agreed
that
you
know
that
it
made
more
sense
as
a
replacement
for
807
than
it
did
as
an
extension
to
807.
So
I
don't
see
why
we
wouldn't
accept
this.
The
the
content
is
essentially
the
same
though
we
are
proposing
some
additional.
You
know
upgrades,
but
I
think
we
do
have
to
go
through.
We
probably
have
to
go
through
a
re-adoption
on
the
list.
The,
but
I
don't
know
if
francesca
has-
has
an
opinion
on
this.
One.
A
A
C
This
I
can
move
through
this
pretty
quickly
see
I'm
glenn
goldstein,
I'm
in
the
cdn
product
team
at
lumen.
You
may
know
lumen
from
its
former
names
of
centurylink
and
before
that
level.
Three,
so,
within
the
streaming
video
alliance,
we
took
on
the
need
for
an
industry
standard
for
configuring
cdns,
both
in
the
open
caching
sort
of
use
cases
and
in
the
traditional
use
cases
of
content
providers
managing
one
or
more
cdns.
C
C
What's
out
there
in
current
commercial
cdns,
we
identified
many
extensions
required
to
the
metadata
model
itself
and
that'll
be
the
focus
of
this
discussion.
C
In
addition,
we
identified
things
we'd
like
to
extend,
at
least
for
the
sva
use
cases
for
the
api,
how
we
actually
publish
the
metadata
model
between
entities
and
that
really
isn't
the
topic
of
this
discussion.
But
it
is
part
of
the
overall
sva
work
to
extend
the
interface
as
well,
but
we'll
focus
here
just
on
the
model
itself,
so
move
ahead
yeah.
C
So
all
the
extensions
we're
talking
about
here
fall
into
the
categories
listed
listed,
not
kind
of
just
teamed
through
them,
but
all
of
this
will
be
realized,
essentially
with
a
set
of
new
generic
metadata
objects.
C
Enhancing
the
source
definitions
was
a
key
area
focus
for
us,
I'm
enabling
the
specification
to
load
balance
between
multiple
origins
and
to
specify
rules
for
how
you
might
fail
over
from
one
origin
to
another.
We
added
some
authentication
methods
that
we're
proposing
to
deal
with
amazon,
s4,
aws,
v4
off
simple
header,
authentication.
C
There's
a
series
of
additions,
we're
making
to
allow
for
more
refined
cache
control,
specifically
for
a
content
provider
to
instruct
their
cdns
or
for
an
upstream
cdn
to
instruct
downstream
cdns
about
how
they
might
handle
requests
for
stale
content.
So
there's
policies
that
can
say
if
the
content
is
stale
go
ahead
and
serve
it
and
then
a
for
some
period
of
time
and
then
asynchronously
go
back
to
an
origin
to
refresh
you
might
do
this
to
prevent
a
sick
origin
from
being
flooded
with
additional
requests.
C
We've
got
positive
and
negative
cash
control
policies.
You
know
what
to
do
about
caching
errors.
We've
got
controls
in
there
to
allow
you
to
say
that
a
cache
should
be
bypassed.
That
may
be
useful
for
testing
or
benchmarking
purposes
and
there's
a
capabilities
here
to
dynamically.
Generate
cache
keys.
An
example
here
may
be
if
a
response
header
from
an
origin
contains
information
that
needs
to
override
the
cache
key,
which
typically
would
just
be
from
the
request
path.
C
We've
got
capabilities
added
for
dynamically,
generating
and
interpreting
course
headers
traffic
type
metadata.
This
will
be
hints
saying
whether
the
traffic
type
is
live
streaming
on
demand
streaming
large
object.
Download
no
rules
are
specified
about
what
to
do
with
that,
but
it
can
be
implementation,
specific
instructions
that
a
downstream
cdn
might
find
quite
helpful
within
their
own
implementations.
C
The
idea
to
tag
certain
configurations
with
service
or
property
ids,
maybe
on
a
path,
inspection.
If
the
path
begins
with
a
certain
route,
you
want
to
tag
it
with
one
service,
identifier
versus
another,
for
billing
or
log
control
purposes.
Within
a
multi-tenant
cdn,
there's
several
open.
Caching
configuration
metadata
objects.
We
put
in
here
to
control,
request,
routing
ocd,
no
node
selection.
C
We
get
into
those
a
little
bit
later
private
features,
so
while
private
features
can
certainly
be
implemented
by
adding
your
new,
your
own
new
generic
metadata
objects
as
we
as
we've
done
here,
we
want
to
have
a
formal
process
for
specifying
private
features,
then
on
the
right
side.
Here,
there's
a
whole
suite
of
of
enhancements,
we'll
get
into
that
are
all
in
the
category
of
what
we
call
processing
stages,
basically,
at
various
stages,
within
the
request
processing
pipeline,
you
may
want
to
rewrite
uris.
C
You
may
want
to
inspect
http
headers
and
modify
http
headers.
You
may
want
to
generate
a
synthetic
response
and
to
do
all
this
you'll
need
some
sort
of
an
expression
language
to
say
hey
if
the
user
agent
is.
This
type
of
browser
then
set
these
cache
control
policies
or
ignore
this
status
response
from
an
origin
and
replace
it
with
another
status
response
and
again
this
is
all
driven
from
use
cases
we
see
regularly
in
the
cdn
industry
next
slide.
Please
yeah!
You
may
want
to
zoom
up
larger,
to
see
this
better.
C
Here
we
go
yeah,
so
what
it
comes
down
to
if
this,
the
top
part
here
is
the
cdni
structural
model,
as
documented
in
806,
and
we're
not
touching
that
there's
no
changes
proposed
there.
Really.
The
changes
here
are
15
new
generic
metadata
top
level
objects
under
that's
the
ones
in
red
here
and
in
the
current
draft
we've
submitted
to
the
ietf
we
list
out
these
15
objects
with
just
a
very
high
level
definition.
C
Many
more
details
will
come.
The
existing
generic
metadata
objects
from
8006
the
ones
listed
here
on
the
right.
We
have
not
touched
those
go
ahead,
next
slide
yeah.
So,
as
I
mentioned
before,
one
of
the
major
extensions
here
is
this
idea
of
processing
stages.
C
The
idea
that
metadata
and
rules
can
be
applied
at
any
one
of
these
four
stages
that
we
see
typical
in
a
cdn
request,
processing
pipeline
processing,
really
on
the
inbound
as
requests
come
in
from
the
client
processing
on
the
outbound
as
things
come
from
the
origin
before
they
go
into
cash.
That's
this
origin
response
see
here
in
the
picture
when
processing
possibly
is
you
take
items
out
of
the
cache
and
you
want
to
adjust
the
response
in
some
way
before
you
send
them
back
to
the
client?
C
Go
ahead
next
slide,
so
the
processing
stages
model
again
we'll
you
know
this
will
all
be
included
in
the
rfc
and
the
draft
is
a
all
a
model
built
within
a
generic
metadata
object
of
processing
stages,
and
this
really
allows
you
to
say
at
each
processing
stage
what
rules
you
want
to
apply
so
within
the
existing
host
match
and
path
match
structure,
you
can
now
say
great
now
that
I've
matched
at
that
level
when
responses
come
from
the
origin
and
I'm
matching
on
this
particular
http
status
code
go
ahead
and
adjust
the
cache
values,
possibly
overriding.
C
There's
ability
to
do
a
transform,
often
we
find
in
the
cdn
world
we
need
to
add
headers
or
we
need
to
suppress
response
headers
coming
from
an
origin
for
maybe
for
certain
user
agents,
because
it
will
break
some
bad
client
code.
So
there's
a
rich
ability
here
to
generally
inspect
and
manipulate
http
requests
and
responses
next
slide.
Please.
C
And
just
to
kind
of
complete
the
discussion,
the
capabilities
interface
is
defined
in
807
is
a
great
starting
point
within
the
sva.
We
plan
on
making
some
extensions
to
that
on
the
capability
side.
Excuse
me,
as
we
add
all
the
new
capabilities
I
just
highlighted
for
metadata
objects.
Not
all
cdns
will
support
them.
The
fci
metadata
object
is
perfectly
well
suited,
as
is
to
just
add
the
names
of
those
new
generic
data
objects.
C
To
say
you
support
them,
and
we
may
we're
also
going
to
look
at
add
some
capability
for
a
fine-grained
advertisement
within
a
generic
metadata
object
for
a
downstream
cdn
to
say
I
support
this
portion
of
it,
but
not
the
next
portion
of
it
next
slide.
Please
yeah,
and
this
is
extending
the
metadata
interface,
which
I
was
just
touching
on
within
the
sva.
We
will
work
to
extend
the
interface
as
defined
in
8007.
C
Excuse
me,
n806,
and
then
we
will
be
adding
an
advanced
api
to
deal
with
more
of
the
lifecycle
management
workflow
around
publishing
and
versioning.
These
configurations,
keeping
extending
the
hrev
concept
to
have
names
listed
of
generic
metadata
objects,
can
be
reused
that
work
may
or
may
not
find
its
way
into
the
ietf,
but
it
just
kind
of
rounds
out
our
general
metadata
enhancement.
C
Okay,
that's
it
for
the
presentation.
Is
there
interest
in
this
work
either
going
forward
as
an
extension
to
rfc
8006
or
it
can
be
a
standalone
because
it
really
doesn't
change
anything
in
806
effectively,
it's
a
new
set
of
objects
right.
I
think.
A
This
is
exactly
this
is
exactly
what
we
intended
when
we
designed
the
metadata
interface
right.
It
has
a
generic
object
and
you
can
extend
it
and
you
can
add
new
things
and
we
really
wanted
the
industry
to
come
up
with
what
we
needed
to
add
in
order
to
make
this
more
usable,
we
added
the
basics.
I
think
that
you
know
we've
already
done
the
request,
routing
extension
strap,
which
was
two
or
three
new
metadata
objects.
I
think
this
falls
into
that
same
bucket
and
it's
exactly
the
type
of
thing
we
want
to
see.
A
I
think
the
draft
is
very
light
on
details
currently,
and
so
we
would
need
a
lot
more
information.
I
think
some
of
these
are
questionable
the
private
features
and
processing
stages.
You
know
we
may
want
to
split
out
because
they
are,
they
may
be
more
contentious.
I
don't
know
we'll
know
more
once
we
have
more
details,
but
I
think
that
yeah
update
the
draft
and
and
there's
a
discussion
started
on
the
list.
I
think
that's
that's
a
great
next
step.
A
A
Awesome,
if
there's
nothing
else,
we're
even
further
behind
now,
so
I
will
kick
it
over
to
andrew.
F
Hello,
all
right,
so
I
I
know
we're
behind
time,
so
I'm
gonna
try
and
keep
this
quick.
This
is
a
very
chewy
subject
and
I'm
expecting
there
to
be
a
lot
of
questions,
so
I'm
gonna
really
try
and
speed
through
to
leave
time
for
questions.
So
once
again,
my
name
is
andrew
ryan.
I'm
a
principal
architect
in
limelight
networks,
similar
to
glenn.
F
What
I'm
gonna
be
presenting
here
today
is
the
result
of
a
working
group
from
the
streaming
video
alliance
similar
to,
and
my
presentation
is
gonna
look
like
lens,
because
I
took
his
template
and
I
copied
it.
So
thank
you,
glenn,
but
the
draft
we
have
submitted
a
draft
surrounding
what
I'm
going
to
be
presenting
today.
F
It
is
once
again
also
very
light
because
we're
while
we
have
a
good
concept
of
the
high
level
and
the
intention
of
what
we
want
to
accomplish
we're
still
working
through
some
of
the
logistics
of
the
the
json
payloads
and
just
validating
that
it
works
correctly
in
the
whole
spirit
of
the
ecosystem.
F
So
the
mission
of
what
I'm
representing
is
we
want
to
be
able
to
provide
an
interface
that
allows
content
providers,
service
writers
upstream
downstream
cdns
of
a
way
to
understand
what
is
an
appropriate
level
of
traffic
to
delegate
in
the
first
place,
while
maintaining
certain
levels
of
performance
and
we'd
really
like
to
adhere
to
the
great
foundation
that's
been
laid
out
already
by
cdni,
and
particularly
the
fci
and
metadata
interfaces
next
slide,
please.
F
F
These
this
information
should
be
scoped
to
a
cdni
footprint,
so
it
similar
to
fci
capabilities.
The
scoping
will
also
be
restricted
or
allowable
to
be
filtered
by
a
host.
The
information
that
we're
going
to
be
signaling
in
terms
of
capacity
are
going
to
be
specific
to
the
delegation
relationship.
It's
going
to
be
specific
to
the
upstream
cdn
and
the
downstream
cdn.
It's
not
going
to
be
the
case
that
the
downstream
cdn
is
going
to
be
advertising
all
available
capacity.
F
It's
going
to
be
basically
a
not
to
exceed
or
nte
it's.
How
much
am
I
willing
to
allow
you
upstream's
cdn
to
have
this
next
part
is
actually
very
important,
we're
going
to
go
into
a
little
bit
later,
but
we
want
to
define
limits
in
an
unambiguous
and
mutually
understood
terms,
and
then,
lastly,
we
want
to
support
the
various
phases
of
the
communication,
including
bootstrapping,
and
then
we
also
want
to
make
sure
that
you
know
the
upstream.
We
can
support
upstream
continuously
pulling
the
downstream
for
this
information.
F
We
want
to
allow
the
downstream
to
tell
the
upstream.
There
have
been
changes
to
this
information,
and
we
also
want
to
kind
of
add
in
this
newer
phase
of
allowing
the
upstream
to
ask
the
downstream
cdn
to
reconsider
limits
that
may
have
been
previously
advertised
next
slide.
Please
so,
starting
off
we've
kind
of
touched.
I
kind
of
touched
on
the
relationship
that
the
downstream
and
the
upstream,
the
signals
back
and
forth
are
going
to
be
specific
to
them
and
they're
going
to
be
basically
not
to
exceeds
or
capacity
limits.
F
So
we'd
like
to
treat
this
capacity
limit
as
an
fci
capability.
F
A
F
Called
fci
capacity
limits
the
the
structure
of
the
of
the
json,
as
we
kind
of
roughly
sketch
it
out
today,
is
outlined
in
the
in
the
zero
zero
draft
next
slide.
Please
now
the
key
part
and
where
I
alluded
to
earlier
about
the
mutually
understood
terms.
This
is
where
we're
gonna
kind
of
come
into
that
in
that
the
we're
intending
in
that
last
payload,
the
capacity
limits
payload
to
say,
here's,
how
much
your?
F
How
many
gigabits
per
second
you're
allowed
to
delegate
to
us
as
a
hard
not
to
exceed
limit
that
doesn't
necessarily
have
meaning,
though
what
is
a
gigabit
per
second.
How
do
I
know
how
much
I'm
actually
delegating
that's
where
the
telemetry
is
going
to
come
into
play?
F
What
we
intend
to
do
in
that
fci
capacity
limits
payload,
is
to
link
out
or
provide
a
direct
source
of
data
which
will
provide
near
real-time
telemetry
to
show
how
much
usage
via
an
upstream
cdn
is
currently
being
delegated
to
a
downstream,
and
they
should
be
should
and
that
telemetry
sure
should
share
all
the
same
scoping
that
we're
providing
in
the
capacity
limit,
including
which
would
really
be
the
footprint
and
the
host.
F
So
we
in
order
to
at
the
same
point
this
would
also
have
to
cut
necessarily
require
advertising
that
we
support
this
particular
capability.
So
we're
proposing
that
we're
going
to
add
in
a
new
another
payload
of
fci
capabilities,
to
say
that
we
support
certain
amounts
of
telemetry
objects
right
off
the
bat.
I
think
the
goal
that
we're
coming
up
with
is
to
kind
of
define
more
of
a
generic
telemetry
source,
with
the
hopes
that
down
the
line
we
could
discover-
or
I
guess,
explore-
formalizing
more
of
a
formalized
telemetry
interface
itself.
F
Now.
This
is
once
again
going
to
be
a
debatable
item,
because
there
already
is
a
the
logging
interface,
that's
defined,
but
there's
not
necessarily
a
clear
path
to
using
the
logging
interface
to
gather
near
real-time,
aggregated
metrics
that
we
would
need
to
associate
with
some
of
these
typical
capacity
limits.
We're
looking
to
advertise
next
slide.
Please,
and
this
last
component
is
really
meant
to
facilitate
one
of
the
data
communication
workflows
in
that
the
upstream
cdn
would
like
to
query
or
info.
F
Ask
the
downstream,
or
so
us
downstream
cdn,
to
reconsider
capacity
limits
and
provide
suggestions
of
what
limits
they
might
want
to
consider
in
order
to
do
this,
we're
proposing
a
new
generic
metadata
object
which
would
allow
or
facilitate
this
communication.
F
So
once
again,
this
is
a
very
bare
bones
diagram,
but
it's
really
just
meant
to
give
a
very
high
level
view
of
what
we're
trying
to
outline
here,
which
is
the
upstream
cdn,
would
look
towards
the
downstream
cdn,
get
the
capabilities
advertised
through
the
fci
interface.
One
of
those
new
payload
items
would
be
a
capacity
limit
which
would
define
a
particular
metric,
such
as
gigabits
per
second,
and
also
outline
which
telemetry
source
is
going
to
be
provided
that
will
outline
how
much
current
usage
of
that
metric
is
being
delegated.
F
Then
the
upstream
cdn
would
go
pull
that
telemetry
source
understand
what
the
current
utilization
is
then
compare
that
to
what
the
limit
that
was
provided
to
it
was
and
adjust
the
traffic
delegation
decisions.
Based
on
that.
So
I
sped
through
that
extremely
fast,
because
I
know
we're
light
on
time.
The
draft
itself
is
very
light
on
details,
so
I'm
I
guess
we
wanted
to
bring
this
forth
for
consideration
commentary
and
to
see
if
there
is
interest
in
commenting
on
what
we're
proposing
here.
A
A
If
there
is,
you
know,
interest
within
the
working
group
to
take
that
up,
I
think
that
that's
okay,
the
the
interesting
part,
is
because
the
cdni
working
group
does
not
have
the
protocol
for
fci
if
we're
defining
metadata
objects
and
we're
defining
fci
objects.
I
think
that's
within
our
scope.
A
If
we
are
talking
about
changes
to
the
protocol
itself,
since
we
all
agreed
previously
that
alto
owns
that
protocol
there's,
you
know
there's
some
amount
of
discussion.
We
probably
have
to
have
there,
but
I
think
yeah.
The
the
draft
is
a
little
light.
I
didn't
I
haven't
commented
on
it
yet,
but
you
know
some
additional
details
around
that
I
think
would
be
interesting
and
I
would
be
interested
in
having
you
know.
Others
in
the
working
group
comment
as
well.
F
100
agree
in
terms
of
the
alto,
yet
we
explicitly
didn't
talk
about
the
transport
mechanism.
F
This
was
mainly
whether
we
use
alto
or
you
know,
as
the
open
caching
initiative
in
sva
is
intending
to
use
another
framework.
We
still
need,
I
think
we're
gonna
still
need
to
define
these
payload
types
or
just
the
encapsulation
of
the
data.
So
that's
why
we
wanted
to
bring
forth
at
least
these
three
items
that
we're
looking
to
formally
define
within,
as
particular
payloads
or
metadata
items,
so
that
they
could
be
transported.
F
And
yes,
the
draft
is
very
light
once
again
similar
to
glenn.
We
have
a
larger
working
document
on
the
sva,
where
we're
stepping
through
a
lot
of
this.
As
that
fleshes
out,
we
will
be
updating
the
draft
to
include
a
lot
more
information,
a
lot
of
context
of
why
we
may
have
chosen
certain
paths,
etc,
etc.
A
A
I
Okay,
so
let's
run
to
it
I'm
now
in
this
session
I
would
like
to
go
over
new
footwear
types.
We
would
like
to
suggest
so
again
a
quick
recap.
Rc8006.
It
defines
the
footwind
types.
I
We
have
ipv4
subnets
a
sense
country
code,
and
it's
also,
it
also
defines
the
footprint
object,
which
specifier
type
and
a
list
of
values
of
these
types
and
after
the
filter.
The
client
needs
to
match
this
filter.
So
a
rc808
text
uses
this
definition
of
a
footprint
of
a
footprint
object.
It
allows
the
specification
of
each
corresponding
of
each
copper
allows
to
set
a
for
each
capacity,
the
corresponding
footprint,
and
so
in
this
example.
I
The
capacity
is
available
at
the
the
asn
644996,
but
only
for
a
client
residing
in
the
u.s
next,
please
so.
The
new
footwin
type
you
would
like
to
add
is
that
is
based
on
a
iso
31662,
this
isotect
a
country
code
and
actually
go
down
one
level
geographical.
I
Geographically,
it
can
be
states
in
the
us,
as
in
the
visual
province
in
canada,
metropolitan
in
france,
et
cetera,
and
so
we
build
a
new
footprint
type,
which
is
which,
which
starts
with
the
country
code
and,
like
example,
us
and
then
dash
and
the
a
subdivision
code,
and
in
this
example,
it
will
be
ny
for
new
york.
I
I
So,
let's
focus:
let's
move
to
the
next
side:
let's
focus
again
on
a
rfc8
on
the
capability
footwear
capability
mechanism
and
on
the
knowing
the
mounting
of
it.
Okay,
as
I
said
before,
in
order
for
a
a
client
to
be
match
the
footprint
filter
here
and
say
the
capabilities
available
for
this
client.
I
I
Next,
please
so
now,
I'm
simplifying
the
example.
In
this
case,
the
the
client
should
only
reside
in
the
us
next.
Please,
and
what
happen
if
I
want
the
capability
to
say,
the
capability
is
valid,
is
available
for
all
clients
in
the
u.s
and,
additionally,
a
client
in
nova
scotia
in
a
province
of
canada.
I
I
The
rate
it
is
solved
by
rfc
808
is
by
redefining
the
same
capability
twice:
okay,
we
once
defined
the
capability
for
the
u.s
clients
and
once
they
define
their
capability
for
a
nova,
scotia,
client.
Okay.
Next,
please.
I
They
know
there
is
also
an
other
additive
semantics
in
there
in
the
a
footprint
object
which
is
built
on
the
footprint
value
list.
Okay,
if
we
want
to
say
that
that
the
capability
is
available
for
current
in
the
us
and
canada,
we
could
have
will
use
the
additive
list.
I
That
is
part
of
the
footprint
of
the
footwind
valve
okay,
so
I
they,
as
I
see
the
narrowing
semantic,
is
a
bit
constraining
and
we
need
some
additive
additive
semantics
and
I
I
would
would
like
to
suggest
to
use
this
additive
already
existing
additives
in
semantics
and
in
order
to
create
a
larger
and
more
complicated
structures
by
using
by
defining
a
new
footprint
type,
which
is
the
footwind
union
and
the
phobian
union
is
actually
a
new
footprint
type,
whose
values
are
a
footprint
object.
I
So,
in
the
following
example,
will
first
go
to
the
northwest
area?
The
asn?
The
client
must
be
belong
to
the
specific
asl
and
then
the
next
filter
says
the
clients
must
reside
in
one
either
in
the
us
or
nova
scotia,
because
we
have
an
additive
semantics
between
the
footman
values
in
the
in
the
list
and
name
is
still
debatable
and
that's
it.
I
would
be
happy
if
we
can
discuss
this
if
anyone
have
other
ideas
of
how
to
solve
the
issue
and
if
not
to
adapt.
This
draft
is.
A
So,
as
the
author
of
all
of
the
footprint
stuff,
I
agree
that
both
of
these
are
useful
and
necessary,
and
I
apologize
for
missing
this
additive
semantic
footprint
union
piece
when
we
did
it
originally.
A
I
personally
think
that
this
this
makes
sense
for
us
to
do,
and
I
don't
see
that
I
don't
know
if
anyone
has
any
objections
to
it.
It's
pretty
straightforward,
but
if
folks
have
thoughts
on
this,
I
would
encourage
you
to.
A
I
guess,
take
it
to
the
list,
since
we
only
have
20
seconds
left,
but
if,
if
not,
I
think
that
you
know
maybe
we
can.
We
can
go
ahead
and
consider
adopting
this,
but
we
can
take
that
to
the
list
and
offline.
I
appreciate
everybody
showing
up
to
the
cdni
session.
Thank
you
so
much
it's
great
to
be
back
at
ietf.
A
I
guess
we
will
follow
up
with
all
of
these
things
on
the
list
and
if
you
have,
if
you
have
thoughts
or
anything
that
you
want
to
say,
please
send
mail
to
the
list
and
we'll
see
you
next
time
in
madrid,
hopefully
in
person
all
right.
Thank
you,
everybody
thank
you
have.