►
From YouTube: IETF96-CDNI-20160720-1400
Description
CDNI meeting session at IETF96
2016/07/20 1400
A
G
C
G
I
P
K
J
J
P
J
J
The
usual
note
well,
which
I
will
not
read,
but
you
can
have
a
quick
look
and
you
know
it
right.
So
it's
got
to
do
with
IP
on
you
know
anything
but
I
PR
read
the
note
while
and
then
you'll
decide
whether
that
matches
or
not
the
agenda,
and
it's
fits
on
one
page
this
time
it's
all
here,
so
we
had
planned
to
start
with
the
gym.
The
bashing
and
introduction
then
give
a
our
usual
document
status,
update,
which
you
know,
there's
been
quite
a
lot
of
progress
since
last
time.
J
J
So,
with
respect
to
the
agenda
we'd
like
to
change
one
thing,
which
is,
we
would
like
to
n'rae
that
matters
to
you,
we'd
like
to
probably
start
with
your
I
signing,
because
matt
was
present
here,
we'd
like
him
to
be
part
of
the
discussion
and
he
has
to
leave.
Oh
you
don't
have
to
so
we
can.
We
should
ingest
it
to
that
agenda.
Okay,
so
we'll
don't
have
this
requirement
anymore.
Does
anyone
have
any
comment
on
the
agenda?
Anything
you
would
like
to
change
anything.
That's
missing!
Oh
everybody
happy
with
it.
J
Okay,
everyone's
happy
with
it.
So
let's
give
the
update
of
the
documents,
so
then
has
no
change
since
last
time.
These
are
all
our
RFC's
already
seven
of
them.
What
has
changed
is
that
we
now
have
three
documents
which
are
virtually
done:
they
close
the
iesg
review
process
and
they
are
in
RFC
id2q.
J
Two
of
those
have
a
dependency
on
CDN
I'm
meta
data,
so
they
are
sitting
there
waiting
for
that
document.
Anyways
I
will
see
that
we
have
good
hope
for
the
meta
data
document
to
progress
shortly.
So
hopefully,
that
will
unleash
the
flood
of
CDN
I
documents
and
there's
also
the
seed
and
I
logging
interface,
which
is
not
waiting
on
any
reference,
but
it's
just
waiting
for
the
RFC
editors
to
get
onto
it.
So
that's
all
over
budem.
J
Now
the
remaining
documents
are
obviously
we'll
discuss
them,
but
just
to
give
the
high
level
status
the
city,
no
meta
data
is
under
eye.
As
you
review
document
comments
are
being
addressed
and
Kevin
will
give
us
an
update
on
that
redirection,
same
story,
it's
under
eye,
as
you
review,
there's
already
lots
of
commands.
A
lot
of
them
have
been
addressed
and
we'll
hear
about
how
the
remaining
ones
should
be
addressed
shortly
from
new
ray
right,
yeah,
but
foot
making
capabilities,
advertisement
interfaces
for
so
remember.
The
semantics
document
is,
is
done.
J
One
is
currently
a
working
group
document
which
defines
you
are,
I
signing
for,
let's
say
non
segmented
content,
and
then
we
have
a
document
that
discusses
I,
guess
extensions
to
that
to
deal
with
adaptive,
straining
and
there's
some
IPR
update
around
that
document,
which
would
be
presented
in
details
now,
there's
two
pieces
of
work
that
are
beyond
our
charter
or
at
least
beyond
the
milestone.
The
list
of
milestones,
I
should
say
one
is
a
city
in
Iraq
pacing.
J
We
just
talked
to
the
main
author
of
that
document,
and
you
know
he
was
waiting
for
the
key
specs
to
finalize
the
rate.
Pacing
document
itself
is
quite
it's
basically
a
small
extension
which
allows
the
ability
to
request
that
a
CDN
paces
when
you
delivers
a
piece
of
content.
So,
rather
than
just
you
know,
stream
as
fast
as
possible,
you
can
tell
that
CDN.
Well,
you
know
don't
go
faster
than
that
sort
of
right,
which
is
a
capability
that
exists
in
some
Syrians
and
would
be
interesting
to
have
in
our
CDN
I
solution.
J
So
Matt,
the
main
author
has
agreed
to
you,
know,
read
the
document
up
now
that
the
key
specs
are
frozen
and
we
should
get
an
update
and
I
guess
we
take
it
from
there
see
if
we
want
to
make
it
to
work
in
the
document
and
get
it
to
the
process.
But
in
any
case
it's
fairly.
You
know,
contain
simple
document,
but
we
won't
talk
more
about
it
today
about
HTTPS
delegation.
J
You
know
this
is
I,
guess
evolving.
As
the
the
background
work
inside
ITF
evos
Frederick
had
written
a
new
document
on
that
topic
and
which
was
discussing
how
luck
could
be
used
for
CDN
I,
and
you
know,
there's
been
a
lot
bath
with
some
likely
directions
and
for
the
lake
will
update
us
about
that.
Ok,
so
that's
a
I
think
on
a
half
for
the
document
status.
Is
there
any
any
question
comments
on
the
document
where
they
are
on
high
level?
No
good.
N
J
Q
That
document
was
sort
of
I
was
wondering
about
it
already
how
to
document.
What
is
that
goes
now,
given
that
dessert
in
itself
do
not
take
off
with
you
know,
and
this
whole
different
story:
I,
don't
call
it
here
and
why
they
do
not.
They
got
let
you
know,
but
there
are
some
good
work
down
there,
including
the
CD
and
I
HTTPS
navigation.
So
della
document
gets
40
years
from
now
or
what
happens
I.
C
J
C
C
We
removed
all
the
dot
V
ones,
as
we
discussed
in
Buenos
Aires
and
I
tried
to
clarify
the
versioning
text.
It's
not
so
much
versioning
as
we
need
to
know
what
version
of
the
spec
these
objects
were
defined.
In
so
I
tried
to
clean
that
up.
We
added
more
text
about
different
threats
to
the
security
considerations
that
were
brought
up
by
security.
A
DS
we
fixed
all
the
must
text
must
use
text
around
TLS
so
that
the
looks
the
same
as
triggers
and
logging.
C
Those
both
went
through
a
lot
of
review
and
I.
Think
we're
all
happy
with
that.
Now
there
were
a
number
of
questions
from
the
80s
about
why
we
have
an
empty.
You
are
ice.
Are
you
off
object
and
I
tried
to
clarify?
I
added
some
text
in
there
saying
that,
in
a
reference
to
the
to
the
uri
signing
document,
though,
if
there's
an
informative
reference
to
your,
I
signing
document,
does
that
hold
up
its
publication
and
therefore
hold
up
all
the
other
documents
that
are
waiting
for
it,
yeah,
okay,
so.
C
Okay,
went
through
and
added
a
bunch
of
references
and
fixed
a
bunch
of
examples,
added
more
examples
and
fixed
a
bunch
of
random
typos
and
grammar
problems.
There's
a
bullet
down
here
about
alexys
last
comment,
which
I
talked
to
about
yesterday
and
I
think
we'll
have
fixed
shortly
after
the
draft
updates
reopened.
It
was
about
which
methods
were
allowed
to
use,
get
and
head
versus
post
in
all
the
rest,
but
we'll
clean
up
that
text.
C
There
were
two
kind
of
big
decisions
that
were
made
as
we
were
reviewed
revising
the
document
that
we
wanted
to
make
the
working
group
aware
of
we
remove
the
CDN
I
metadata
authtype
registry.
So
we
got
a
lot
of
questions
as
to
why
there's
an
empty
registry
and
the
answer
to
why
there's
an
empty
registry
is
because
you
are
I
signings
not
done
yet,
and
has
it
populated
it.
But
in
looking
at
it
some
more,
we
didn't
actually
need
the
auth
type
registry.
C
The
reason
we
had
it
was
before
we
went
to
using
P
types
for
all
our
objects.
We
had
separate
registries
for
the
different
types
of
metadata
objects
and
this
one's
just
kind
of
left
over
for
off
Jack's.
So,
since
every
object
is
now
in
the
p-type
registry,
we
didn't
really
need
a
shadow
registry,
a
duplicate
registry
just
for
auth
objects,
so
we
decided
to
remove
it
unless
anyone
has
any
thoughts
on
that.
If
anyone
objects
and
thinks
we
really
need
a
second
registry
to
register
the
auth
objects
twice,
please
speak
now.
C
Okay,
the
other
comment
that
came
from
alyssa
was
that
for
all
of
our
ACL
objects,
we
have
a
default
of
deny
and
the
whole
list
is
a
deny.
So
you
have
to
explicitly
put
in
and
allow
if
you
want
and
allow
for
the
ACL.
We
did
that
for
safety
reasons,
so
that
you
couldn't
screw
it
up
by
just
forgetting
to
put
that
in
the
JSON
or
forgetting
to
specify
it.
We
felt
that
that's
the
better
way
to
go
and
that
having
to
put
allowing
the
JSON
didn't
really
add
that
much
more
overhead.
C
So
there's
one
open
issue
that
we
have
that
I
found
when
I
was
revising
the
versioning
section.
The
structural
metadata
does
not
have
explicit
versions
in
the
JSON,
and
originally
we
didn't
have
extensibility
for
the
structural
metadata
at
all,
but
now
they
all
have
p-type,
so
they
all
technically
have
some
type
of
version
associated
with
them.
C
So
the
question
that
came
up
was,
you
know:
do
we
need
to
have
explicit
versions?
Do
you
need
to
be
able
to
link
two
different
versions
and
understand
it?
I,
don't
know
if
we
care
I,
don't
think
we
really
care,
but
we
could
add
some
text
to
say
you
know
if
you're
going
to
change
structural
metadata,
it
should
never
have
to
change.
But
if
you
do
please
change
them
also
that
it's
co
here
it.
C
That
would
be
my
preference,
but
if
we
wanted
to
in
some
way
make
inside
the
JSON
explicit
what
the
p-type
is
for
each
of
the
structural
objects,
we
could
do
that.
I,
don't
know
if
anyone
here
has
an
opinion,
if
not
I'm
just
going
to
say
structural
objects
are
their
version
them
as
a
group.
If
you
ever
want
to
change
this,
be
very
careful
not
to
screw
up
the
pad
stuff
and
just
do
them
all.
If
no
one
has
any
problem
with
that,
I'll
send
an
email
to
the
list
as
well
all
right.
C
R
So
we
are
basically
the
main
issue
was
that
the
word
down
drafts
which
I
didn't
call
out
in
ITF
last
call
because
I
didn't
get
the
shepherding
right
up
and
I
didn't
check
myself,
so
I
think
collectively
it's
our
fault
so
anyway,
I'm
I,
think
all
of
your
changes,
I'll
just
double
check
that
it's
nothing
particularly
significant
I,
don't
think
more
most
realistic
case
is
I'll.
Just
email
is
g
saying
there
are
some
minor
changes
to
the
document
he
already
all
approved
it
I'll
just
to
prove
it.
C
C
There
have
been
two
revs
I've
been
trying
to
keep
it
in
line
with
metadata,
as
we
meditate
and
logging,
as
we've
been
revising
them
through
the
iesg
comments.
So
here's
a
list
of
changes,
I
updated
a
lot
of
the
stuff
related
to
P
types,
but
then
also
as
we
went
through
the
isg
comments
on
semantics,
we
changed
it
from
informational
to
proposed
standard
and
moved
a
lot
of
the
object.
C
So,
as
as
next
steps,
I
still
need
to
update
those
with
the
latest
changes
that
happen
to
metadata
last
week,
and
then
the
security
considerations
section
is
out
of
date
as
well.
I
was
going
to
update
that,
but
ultimately
I
think
at
this
point.
Yawns
up
next,
but
yeah
and
I've
been
talking
about
how
we
can
merge
the
two
drafts
together.
C
N
S
Yeah
then
there's
an
expired
draft
called
zero
CDN
request,
routing
Alto,
which
is
the
one
you
were
just
talking
about
so
next
slide,
and
so
just
a
reminder-
and
we
haven't
been
talking
about
this
for
for
y.
So
here's
just
a
reminder
of
the
history
we
used
to
have
three
documents.
One
was
the
semantics
draft
and
then
Kevin
had
a
draft
that
specifies
the
JSON
object
and
I
had
a
draft
that
specifies
how
to
transport
that
JSON
object.
S
The
fci
Jason
object
via
al
Joe,
as
kevin
was
just
mentioning
and
very
up
to
now
we
were
basically
focusing
on
the
semantic
strap
you
wanted
to
get
that
one
done.
So
we
actually
I
haven't
updated
this
draft
and
quite
a
while.
You
have
recently
started
to
update
yours,
but
basically
we
were
focusing
on
that
one.
S
So
next
slide
now
that
one
is
done
the
semantics
document
and
then
at
the
same
time
originally
we
thought
it
would
be
an
informational
document,
but
in
the
process
it
turned
out
and
I
think
this
was
actually
explicit
feedback
from
the
isg
right.
So
they
actually
told
us,
and
why
don't
you
move
all
the
specifications
into
that
document
which
basically
makes
your
document
now
very
skinny,
so
to
speak,
and
that's
why
we
had
the
idea
we
both
agree
on
this.
S
We
should
merge
these
two
documents,
because
all
that's
really
need
to
all
that's
left
to
be
done
is
really
specify
the
transport
of
the
JSON
object.
The
fci
JSON
object.
That's
specified
in
this
document.
That's
currently
in
the
RFC,
editor,
editor
queue
and
yeah,
and
that's
what
we
want
to
get
down.
So
we
want
to
merge
these
documents
and
I
think
we
don't
have
to
discuss
any
more
that
this
is
going
to
be
a
new
algin
service,
because
that
we
have
discussed
and
agreed
on
in
the
working
group.
Previously.
S
Your
document
also
talks
about
also
all
the
time
and
so
another
question
that
came
up
with.
Should
we
continue
this
work
in
the
CDN
I
working
group
or
in
the
outer
working?
We
are
currently
discussing
with
the
air
directors,
and
we
have
an
email
thread
on
that
and
probably
mere
Mayor
was
the
area
director
for
alto
needs
to
decide
this
more
than
you
I
guess
so
we're
talking
to
her
and
yeah
I.
Don't
have
any
strong
feelings
but
again
remind
mind
yourself.
S
The
JSON
object
is
really
see
deny
specific
and
we
did
the
work
here
now.
The
transporting
at
vnu
aljo
service
is
probably
more
address
specific,
so
it
actually
makes
a
lot
of
sense
to
move
that
to
the
algebraic
in
group
and
that's
our
proposal
anyway.
If
anybody
has
comments,
feed
break
now
would
be
the
time
to
to
to
speak
up.
I
guess
yeah.
I
guess.
C
I'll,
throw
in
my
two
cents
in
I
I
also
don't
have
a
strong
feeling,
but
it
seems
like
most
of
it
is
much
more
Alto
specific
now,
so
it
seems
like
it
makes
more
sense
and
push
it
over
to
the
alto
groups
that
it
gets
the
right
eyes
on
it.
The
objects
are
all
ready
to
find.
They
just
got
transport
them.
Hile.
T
Albert
sprint,
I'm
just
wanted
to
say,
I
think
you're,
probably
on
track
with
it.
Moving
a
bit
over
to
Alto,
we
actually
at
sprint
implemented
the
sei
map
in
the
process
in
April,
took
about
four
days
or
so
doing
well
in
terms
of
the
design
and
everything
else
working
with
a
few
partners,
we
won't
go.
You
know,
I
won't
go
into
detail
who
they
are,
but
at
this
point
it
is
very
much
inside
the
altar
server
and
any
issues
we
have
or
pretty
much
all
tow.
At
this
point,
yeah.
That's.
E
S
J
E
S
S
S
Had
to
have
one
issue,
though,
so
in
the
CD
and
I
working
group,
the
fci
specification
is
a
chartered
working
group
item.
So
charter
milestone.
We
split
it
now
into
one
thing
that
is
done
and
we
try
to
move
the
other
one
into
the
algebra,
so
I'm,
discussing
with
Mia
that
if
it
moves
to
the
outer
working
route
needs
to
be
a
mais
from
there
as
well.
Yes,
yes,
so
that's
a
that's!
Basically,
what
we're
discussing
is
yeah.
M
U
So
the
in
this
case
we
have
the
redirection,
Ross
version
18.
It's
currently,
can
you
connect
I
page,
it's
firmly
under
it's
been
in
the
review.
I
think
for
quite
some
time.
When
I
arrived,
it's
been
to
meetings,
we
have
won
a
major
thing
left
and
let's
do
with
privacy
I'm.
As
you
guys
are
aware,
I
think
we
presented
it
in
the
last
meeting.
One
of
the
things
is
that
what
this
broth
actually
does
is
it
specifies
an
interface
that
allows
an
option
CDN
to
tell
the
downstream
CDN
I've
gotta
a.
U
So
what
we
discussed
yesterday
with
Stephen,
if
you
go
to
the
next
slide
Kevin
we
had
a
meeting
with
bristles
and
Brian
criminal
I'm,
not
sure
where
they
are
in
the
boom.
No
I,
don't
think
so
and
to
see
what
we
can
do
about
that
and
I
think
we
all
agreed.
That
is
it's
not
an
option
to
just
say
in
the
draft.
You
shouldn't
send
anything
to
the
downstream
CDN,
because
I
hold
effectively
mean
that
the
doubting
Sheamus
is
not
able
to
make
a
good
informed
routing
decision.
U
So
what
we
need
to
do
is
we
need
to
come
up
with
some
sort
of
text
that
basically
says.
Okay,
you
should
only
tell
a
b
c
d
and
the
information
they
should
actually
need
for
this
specific
type
of
request.
Then
not
anything
else.
So
we
had
a
talk
with
Steven
yesterday
and
we
came
up
with
some
text.
It's
all
mammalian
list,
if
you
want
to
if
you,
if
you
want
to
check
it
out
and
included
here
on
the
slides
that
you
can
check
it
out.
I
think
it's
a
it's
not
that.
U
It's
not
a
problem,
I
think.
Basically,
what
it
says
is
what
it
says
over
here,
and
you
should
only
send
information
that
this
young
definitely
requires
to
be
able
to
make
a
redirection
decision
and
one
of
the
information
is
we
can't
specify
within
the
draft,
since
it
depends
on
what
type
of
content
you
want
to
redirect.
U
But
what
we
will
do
in
the
draft,
it
will
will
sort
of
highlight
some
especially
vulnerable
fields
such
as
cookies,
that
you
probably
shouldn't
send
to
the
dcd
and
former
security
point
of
view.
I
will
stuff
like
this,
so
the
UC
and
should
convey
as
much
information
as
possible.
We
will
take
it
out
of
the
graph
completely.
L
U
Yes,
another
issue:
there
was
a
comment
from
stephen.
I
think
a
fair
point.
Basically,
what
we
have
currently
in
the
draft
is.
We
have
certification
objects
in
which
we
include
certain
header
fields
from
the
DNS
Jordan
children,
fields
from
dns
and
we'll
send
them
in
the
request
to
the
DC
DM,
but
we
didn't
include
there
yet
was
any
kind
of
recommendations
on
how
you
should
deal
with
weird
character,
so
characters
that
are
not
in
the
Oski
set.
U
V
O
V
U
Exactly
there
was
one
comment
on
the
list
of
thing
from
somebody
on
monster
would
was
who
said
it
you?
What
you
could
do
is
you
could
transfer
to
you
label
first,
because
injection
you
can
transfer
that
sort
of
characters,
but
I
don't
really
see
the
point
there
I
mean
you
might
as
well.
You
see
a
level,
it's
a
label
in
a
posterior
yeah,
so
yeah
ill.
U
U
R
J
U
So
you're
I
signing
your
writing
history
and
we're
going
to
law
school
for
two
weeks
now.
I
think
we've
got
some
pretty
good
comments,
so
I'll
go
through
the
comments
and
now
and
then
we
have
a
more
important
question
to
ask
at
the
end
sort
of
an
elephant
in
the
room,
but
we'll
get
to
that
later.
There's
two
nevis
I.
U
We
have
two
new
verses
posted
since
Buenos
Aires.
Basically,
the
most
important
things
we
addressed
there
were
a
lot
of
comments
from
lethal
and
gun
show
based
on
what
did
it
is
that
he
actually
implemented
this
thing
in
a
party
traffic
surfer
and
he
had
some
good
recommendations
on
how
to
improve
certain
aspects
on
output
increased
performance.
So
we
have
that
back
in
the
in
the
drafts
and
will
be
what
we
added
in
09
was
the
sea
and
I
metadata
off
I'd
registration.
U
The
water
in
sent
from
Kevin
is
left
to
take
it
out
again
so
next
slide.
Please
so
then
met
in
the
room
here
kindly
agreed
to
review
the
document
from
a
secure
security
point
of
view,
and
he
had
some
really
good
comments
and
I
can
present
them
here,
Matt
or
if
you
want,
you
can
get
your
opinion
on
the
current
status
you're
here.
So.
H
I
mean
the
TLDR
here
was:
this
is
looking
like.
It
was
trying
to
reinvent,
am
a
new
crypto
container,
so
there
was-
and
you
know
it's
taking
a
lot
of
the
mistakes
that
happen
early
on
when
you,
when
you
don't
know
what
you're
doing,
because
this
stuff
is
kind
of
hard.
So
there
were
things
like
you
know.
There
was
a
lot
of
well.
We
can
just
assume
this
algorithm,
but
there
was
a
lot
of
places
where
you
could
assume
the
algorithm.
There
was
mixing
of
hash
types.
There
is
some.
H
U
C
U
So
next
time
please
Kevin,
so
then
we
have
some
other
comments
from
work.
New
blasco
comments.
There
were
I
think
a
less
important
for
now,
but
I
will
briefly
go
through
them.
There
was
a
proposal
from
been
basically
to
to
only
make
the
shower
256
hashing
make
that
mandatory
and
to
make
it
easy,
DS
aid
to
the
a
sort
of
an
optional
thing,
and
there
was
discussion
of
Lisbon
I,
think
we
didn't
receive
any
comments
of
people
who
didn't
agree
with
that.
U
So
if
there
are,
let
us
know-
or
else
we'll
probably
make
it
optional,
then
what
we
had
is,
if
you
read
in
the
draft
will
have
to
information
elements.
We
have
a
key
ID
and
we
have
a
key
ID
num
and
it
was
introduced
some
time
ago
to
increase
performance
any
case
where
use
a
Justin
in
Turkey
ID.
But
given
that
we
now
use
this
mandatory
packaging
of
the
information
elements,
there's
less
need
to
have
that.
U
So
there
was
a
proposal
from
Kevin
to
sort
of
mursi's
to
back
together
and
just
have
one
string
bass,
key
ID,
where
you
can
put
in
a
number
I
can
put
in
anything
you
want.
And
again
I
don't
think
this
very
controversial
topics,
our
nobody
see,
which
we
can
sort
of
do
that.
The
same
is
true
for
the
merging
of
the
hf
and
DJ
fields.
There
are
two
fields
that
are
used
to
sort
of
signal:
the
algorithm
that's
being
used,
whether
ccd
is
a
shout
256
or
whatever.
U
We
can
leave
two
fields
depending
on
where
you
use
a
symmetric
algorithm
or
so
from
a
symmetric
algorithm.
We
might
as
well
merge
those
two
into
a
single
information
element
and
it
would
also
solve
one
issue
that
met
race
was.
That
is
not
always
clear
which
other
el
cajon
is
being
used
since
you
sort
of
have
a
default
algorithm,
as
it
is
right
now
ready
to
put
solve
that
issue
as
well,
and
the
same
goes
for
the
md
and
es
fields
are
just
two
alternatives,
depending
on
which
algorithm
you
used.
U
When
you
become
aight,
we
might
as
well
merge
them.
Have
a
single
information
element
which
would
reduce
the
namespace
a
little
bit
then
the
most
important
question
that
we
have
to
discuss
today
in
the
next
slide
is,
as
you've
seen
met
said.
We
get
some
security
issues
and
we
had
a
lot
of
discussion
the
past
few
days
of
what
to
do
it
is.
We
can
either
try
to
solve
them
in
the
current
broth,
which
will
require
somewhere,
but
I
think,
is
doable
another
way
that
will
suggest
it.
U
I
think
one
from
our
fill
originally
was
to
basically
adult
Jason
web
token
thing,
so
what
it
would
do,
then
that
case
is
we
will
sort
of
realized
the
draft
as
it
is,
but
base
the
container
completely.
Only
JSON
web
token
thing
and
the
benefit
that
we
would
have
is
that
we
would
basically
gain
the
security
reviews
that
the
document
already
had.
We
don't
have
to
reinvent
the
wheel
so
that
we
sort
of
speed
of
the
security
part
of
the
document.
U
On
the
other
hand,
it
would
require
significant
rewrite,
as
a
document
I
mean
quite
now,
it's
the
documents
quite
far
along
or
in
the
world
who
Glasgow,
but
this
will
basically
mean
it.
We
have
to
go
back
a
few
stages
and
from
from
a
serve
an
implementation
perspective,
both
options
have
benefits
on
the
awana
round.
On
the
one
hand,
we
have
a
lot
of
JWT
implementations
already
out
there.
U
J
A
minor
comment
on
the
statement
and
probably
delayed,
so
it's
not
obvious
to
me
in
a
sense
that
on
some
document
in
this
working
group
going
through
is
g
review
has
been
the
longest
part
of
the
processor,
and
so
you
know
getting
the
document
ready
from
the
working
group
is
not
necessarily
the
most
difficult
step.
It
would
suddenly
arguably
delay
the
document
coming
out
of
the
working
group,
but
not
obvious
that
that
translates
into
a
coming
out
later
of
the
whole
process
yeah,
but
so
marginally.
You
know
myself,
I
don't
have
a
strong
opinion.
O
J
U
Of
the
question
and
the
amount
of
time
it
would
take
to
get
the
current
document
up
to
a
security
level
that
security
guys
can
agree
to
it
and
I
don't
Matt.
Maybe
you
can
give
any
open.
Isn't
that
how
much
effort
it
will
be
to
sort
of
reference
the
same
security
principles
that
we
have
in
the
JWT
in
this
document
as
well.
H
U
H
For
anybody,
that's
so
remote,
so
my
feeling
from
looking
over
it,
I
mean
okay,
so
caveat
emptor.
I
started
looking
at
this
yesterday
right
so,
but
I
don't
think
it
would
take
much
to
from
from
awarding
sper
spective
any
from
implementations
perspective
to
get
to
JWT.
I
think
you
could
certainly
get
you
could
probably
write
the
text
either
way
about
the
same
amount
of
time.
H
R
J
J
Now
practical
question
is:
who
would
be
willing
to
do
that
and
by
huayna,
because
you
know
it
may
be
all
nice
and
well
that
we
could
do
it,
but
the
key
question
about
going
somewhere
and
fastest?
Who
can
do
that
with
the
right
expertise
and-
and
you
know
he's
willing
to
commit
to
that
Oh
a
volunteer.
W
Volunteer
I
was
too
close
to
the
speaker,
so
I
definitely
be
willing
to
help
write
up
text
and
work
with
ray
and
get
the
document
more
towards
a
JWT
side.
Matt
said
he
would
help
with
the
JWT
specific
stuff
and
and
he's
very
familiar
with
that
out
of
the
hose
a
working
group
and
he
works
for
blocks
down
the
street
for
me,
so
I
can
go
twist
his
arm,
so
I'm
willing
to
do
that.
I'm
willing
to
do
the
legwork
on
that
helped
and
and
ray.
Are
you
willing
to
jump
on
effort.
J
And
okay,
so
you
know
how
that
sounds
like
a
nap
propriate
team
there
and
now
could
we
ask
or
some
sort
of
a
you
know,
commitment
in
terms
of
timing.
It's
so
good
to
be
a
chair.
You
know
you
just
put
action
items
to
people,
I
just
love
it,
but
something
reasonable.
You
know,
I
think,
if
we
don't
fix
time
frame,
this
is
gonna
drive
on
and
we'll
meet
at
the
next
meeting
or
talk
and
we'll
be
at
the
same
point.
So
I.
J
U
Work
with
you
guys
on
the
text
for
C&I
specific
tip,
but
I
agree
need
you
help
with
the
you
know
the
JWT
thing
so
I
mean
I'm
happy
with
saying
a
first
version,
and
maybe
we
can
go
for
a
month
or
something
six
weeks,
sort
of
like
that,
because
I
would
like
to
get
the
document
sort
of
all
sort
of
a
crackhead,
at
least
during
the
next
meeting.
We
have
something
considerable:
where
is
there?
Maybe
we
don't
necessarily
to
go
finish
it
all,
but
it's
sort
of
relatively
stable.
J
H
U
U
Yeah
you're
right
signing
specific
thing
for
segmented
content,
so
I've
been
presenting
this
topic
for
a
couple
of
meetings
now
and
appended
now.
We've
had
a
long
description
about
IPR
before
we
get
to
that.
Let
me
first
recap
what
the
IDS
of
this
document.
Basically
your
eyes,
hunting
as
we
specified
it
right
now
in
the
menu
rice.
I'm
specification
does
not
work
for
segmented
content,
so
that's
HLS
that
the
sort
of
thing-
and
it
has
to
do
with
the
fact
that
you
sort
of
a
manifest
file
where
you
do
the
redirection
form.
U
U
So
what
we
did
is
that,
since
the
0
free
version
we've
restructured
their
algorithm
sex,
basically,
what
I
can
do
I
can
explain
what
we
changed
here.
But
the
important
thing
is:
what
was
the
change
again,
I
think
for
a
JSON
web
token
thing
so
I,
don't
think
it's
really
makes
a
lot
of
sense
to
go
through
the
details.
Changes
here.
What
is
important
is
that
we've
got
a
new
IP,
our
disclosure
sort
of
an
update
on
the
last
one,
which
is
royalty
free.
U
U
U
C
C
U
What
is
important
is
that
indicates
where,
if
you
look
at
the
drafts
in
a
way
it's
written
right
now,
you
either
use
the
the
chain
thing
or
use
the
non
chain
thing.
It
doesn't
make
sense
to
use
the
chain
thing
in
a
case
where
you're
not
going
to
have
segmented
content,
so
they
are
mutually
no
matter
of
yeah.
You
won't
use
them
at
the
same
time.
I
guess
right,
so
that
there's
still
a
reason
to
usually
one,
even
if
you've
already
you
implement
v2.
U
If
you
go
over
to
Jason
web
token
thing,
I'll
have
to
go
back
and
see
if
this
still
makes
sense
or
if
it's
more
of
a
thing
where
you
can
use
where
you
basically,
the
same
algorithm,
is
used
to
generate
the
segment
to
generate
the
token.
The
only
thing
that
will
be
different
between
the
main
version
and
and
editor
streaming
version
is
the
way
you
transport
it.
U
In
the
main
you
are
signing
spec,
you
transported
a
sort
of
any
query
string
within
the
editor
streaming
cases
that
that's
not
possible,
so
you
will
transfer
it
in
cookie,
for
example,
that
part
will
still
be
different
right
bits
on
the
to
use
case,
but
Billy
algorithm
is
the
same.
So
we
can
merge
that
bag
back
in
right.
J
But
I
mean
it's
kind
of
a
moot
point
whether
we
bring
it
back
into
the
existing
working
group
document,
since
we're
going
to
likely
replace
it
by
another
document.
So
I
think
the
question
is:
when
you
guys
work
on
the
JWT
version
of
your
I
signing.
Should
you
include
that
right
at
the
same
level
so
and
to
me
one
question
that
impacts
on
that
is,
you
know:
does
it
make
the
work
a
lot
more
complicated,
a
lot
more
unstable,
or
do
you
feel
it's
you
know
to
the
same
level
of
stability?
U
Me
is
it's
just
another
way
of
transporting
the
thing
and
it
will
probably
be
its
own
section,
so
whether
we
place
that
section
in
the
main
spec
or
why
we
split
it
out
into
a
separate
Specter,
doesn't
make
that
much
of
a
difference.
I'll
think
we
just
have
to
see,
and
let's
try
to
see,
if
you
can,
we
can
move
in
the
same
document
and
if
its
own
point,
we
figure
that.
Well,
maybe
this
is
delaying
the
thing
or
making
more
complicated
as
it
needs
to
be.
Then
we
can
always
that's
a.
J
J
U
We
decided
right,
I
mean
we
can
do
anything,
we
can
make
it
as
a
sort
of
a
new
individual
document
or
we
can
just
post
it
as
it
then
version
them
of
the
menu.
Like
anything
I
mean
we
don't
necessarily
to
Macon,
because
a
lot
of
texts
will
be
the
same,
the
entire
you
know
the
introduction,
the
use
cases,
the
information
as
much
little
will
be
the
same.
It'll
mostly
be
the
sort
of
algorithm
which
will
be
different,
but
I
expect
the
first
would
say
eight
or
nine
pages
to
be
the
same
as
well.
J
V
J
So
then
you
know
just
for
expediency,
then
maybe
you
know
we
sort
of
reuse,
the
current
working
group
document
container
and
just
change
it
to
that,
and
then
I
mean
unless
someone
objects
were
given
that
the
IPR
issue
is
resolved.
The
objective
would
be
to
try
to
get
the
segmented
contact
back
in
at
the
same
time,
and
you
know
we'll
have
a
document
which
has
that
as
well
and
I.
C
C
O
J
U
M
M
X
X
X
So
this
interface
this
basically
this
lock
interface,
but
anyway
it
can
be
other
kind
of
interfaces
with
ro.
U
CDN
our
decision
to
request
to
you
CDN
for
credentials
or
for
home,
let's
say
maybe
some
short
short
left
keys
for
example.
Instance:
here
we
have
two
possibilities:
either
way
we
can
provide
the
credential
while
establishing
the
cheerless
connection,
meaning
that
so
you,
the
UA,
will
request
the
dcen
for
for
virtualization,
and
during
that
time
we
will.
I
will
require
you
CDN,
that
we
lost
the
certificate.
X
X
And
before
any
art,
LS
LS
connections,
it's
gone,
so
we
have
basically
true.
We
had
to
use
cases
that
I
already
presented
the
last
time.
The
first
one
is
origin
certificate
under
the
ucen
authority.
So
here
the
decision
will
request.
Are
you
CDN
and
the
second
one
is
basically
the
roach
in
30,
58
and
also
party
authority.
X
So
as
a
conclusion
and
next
step,
we
can
say
that
lucky
server
will
not
be
specified,
unfortunately,
but
we
may
think
of
other
approaches
that
can
that
will
be
discussed
at
the
ITF
to
provision
find
Sansa
doc
certificates,
meaning
the
short-lived
the
certificate
instead
of
the
of
the
credential.
Also
keen
information
so
took
to
question
for
the
for
the
working
group.
Look,
so
could
those
approaches
be
considered
by
the
CDN
or
cdna
working
group
in
a
further
walk
and
do
we
do
we
all
get
updated
rat
with
those
approaches.
C
I
I
think
that
you
know
we
we've
said
that
we
are
interested
in
figuring
out
a
way
to
do
delegation
with
HTTPS,
but
that
this
working
group
is
not
going
to
be
the
one
that
should
decide
how
that
should
be
done
in
a
cryptographically,
secure
way,
sharing
keys
or
sharing
certs
or
getting
short-lived
starts.
Or
what
have
you
right?
Okay,.
X
C
That,
if,
if
we
had
a
concrete
solution
for
how
to
do
it,
then
yeah
we
could
probably
define
but
I.
Don't
it's
not
clear
to
me
after
sitting
through
the
lirc
bought
that
of
the
disparate
methods
proposed,
we
could
concretely
come
up
with
what
CD
and
I
would
have
to
do
it
generically
right.
Each
one
of
those
methods
would
have
something
specific
in
terms
of
metadata
or
how
we
have
to
configure
things
right,
I'm,
unless
other
people
have
an
opinion
that
was
just
my
take
on
the
Lark
versus
short-lived
certs.
C
X
Y
Okay,
hello
telling
you
what
I
heard
is
that
the
Acme
working
group
is
going
to
recharter
and
zag
Z
understand
the
disease
looking
for,
they
are
willing
to
to
add.
You
see
a
short-term
certificate
in
the
scope
of
the
work
third,
and
so
we
can
discuss
with
Acme
working
group.
If
you
have
a
solid
or
agreement.
C
H
The
biggest
issues
that
came
out
this
is
matt
miller
again.
The
biggest
issues
that
came
up
with
short-term
suits
are
with
revocation.
Well,
you
don't
have
to
worry
about,
revocation,
because
the
cert
doesn't
live
long
enough
for
you
to
actually
get
a
revoke
through
as
far
as
certificate
transparency
in
and
the
CT
logs,
it
can
make
them
bigger.
Y
O
Y
J
Right
so
just
to
make
sure
everyone's
on
the
same
page.
So
what
I'm,
when
I'm
hearing
is
you
know,
acne
is
going
to
read
you
their
charter
to
for
that
short
short
little
short
on
shortly
certificates
and,
among
other
things,
okay
and
I
mean
at
this
stage.
It
doesn't
look
like
this
solution
is
not
suitable
for
CDN
I
might
be
suitable
good
candidate.
So
we
are
encouraging
people
from
this
season,
our
working
group
to
12
mg
father
requirements.
J
O
This
is
sanjay
dist,
true
at
sanjay
mishra
from
verizon.
Just
to
add
to
what
Matt
was
saying,
I
believe
the
motet
Hardy
had
said
that
approximately
September
timeframe
is
when
they
would
be
looking
to
reach
order.
So
timeline
wise.
You
know
you
have
through
September
to
do
that.
Now
it
was
recommended
to
to
Iran
sheffer,
who
actually
wrote
the
short-term
certificate
draft
to
take
it
to
the
Acme
working
group.
O
So
my
suggestion
would
be
that
you
should
you
know
sync
up
with
Iran
and
see
if
he
indeed
plans
to
submit
the
draft
into
acme
or
not
so
that
would
that
would
be
the
first
thing
and
work
with
him
on
on.
You
know
going
over
the
this,
the
short
certificate
you
know
and
how
that
might
you
know,
need
to
be
changed.
O
I,
don't
know
for
the
CD
and
I
specific
in
a
scenario
so
work
with
him,
and
if
he,
if
he's
willing
to
do
the
work,
then
he
could
take
that
draft
into
the
Acme
working
group
when
it
recharges
in
September
and
then
I
think
we
can
look
back
here
and
see.
You
know
whether
or
not
that
fits
into
the
cdna
working
group.
M
W
X
W
L
X
C
Don't
know
either
I
said
I
have
read
the
drafted:
it's
certainly
possible,
we
would
you
be
willing
to
I
I,
guess,
there's
two
there's
two
things
here:
one
is
summarizing
approaches
and
whether
or
not
there's
value
in
doing
that
and
the
other
is
if
we
think
that
acne
is
a
good
approach
at
least
submitting
a
draft
over
there
with
our
use
case,
so
that
they're
aware
of
it,
gets
under
consideration.
Yes,.
X
C
Y
C
C
J
J
You
knocked
me
and
we
said:
let's
go
on
that
and
then
you
know,
there's
a
new
thing
coming
up
and
we'll
follow
so
I
mean
one
thing:
that's
clear
to
me
is
that
there's
limited
expertise
in
in
this
group
about
what's
the
right
security
solution
at
high
level,
you
know
I
think
we
can
work
on
looking
at
a
solution.
That's
good
idea
for
proof,
solution
and
trying
to
adapt
it
or
maybe
feed
our
requirements
into
it.
J
J
We
just
pause
a
little
bit,
I
mean,
and
when
there
is
a
sort
of
stable
solution
for
something
that
looks
like
it's
addressing
most
of
the
problem,
we
can,
you
know,
resume
the
work
now
in
the
meantime
there
I
think,
there's
good
individual
things
that
can
be
done
by
individuals.
Like
you
know,
if
some
of
you
are
following
the
acne
work,
work
and
attack
me,
you
know
that
this
short-term
certificate
is
a
good
possible
candidate.
Then
feeding
our
requirements
into.
That
is
a
good
idea.
J
All
right,
if
you
guys,
are
willing
to
track
the
current
work.
You
know
right
a
little
document
which
says
these
are
the
two
or
three
possible
solutions
that
could
be
used
for
CD
and
I,
and
these
are
the
well
their
status
in
the
HTF,
and
these
are
the
major
pros
and
cons
at
this
stage.
I
think
it's
useful
work,
I
mean
we.
You
know
it
would
have
that
working
group
keep
tabs
on
what
happens,
but
I
don't
think
we
can
make
any
hard
decision
about
that.
Y
J
Think
you're
asking
whether
or
maybe
I
think
you
you
get
into
a
comment,
which
is
that
we
cannot
just
wait
without
doing
anything
because
now
may
be
a
good
time
to
feed
our
requirements
so
ugly.
You
know
this
is
what
I
try
to
capture
by
saying
those
would
be
more
individual
initiatives.
You
know
like
going
to
acme.
I
don't
think
we
can
say
sit
in
our
working
group
believes
that
this
is
the
right
solution
for
us.
Therefore,
we
would
like
you
to
do
this
and
that
right.
J
An
example
better:
well
I'm
saying
I
don't
know
who
is
we
and
I'm
saying
I
don't
think
you
can
go
to
them
and
say
we,
the
city
now
working
group
know
that
you're
working
on
the
right
solution
for
us.
Therefore,
we
request
that
you
do
this
and
you
do
that
I
think
as
a
meal,
you
can
go
there
and
say
the
Cena
working
group
needs
a
solution.
This
may
be
a
good
solution.
If
you
want
to
address
that
solution
with
well.
The
season
are
working
group
problem
with
your
solution.
X
J
C
C
J
What
any
I
meani
mean,
I
just
be
pragmatic,
I.
Think
your
concern
is
that
you,
maybe
you
seem
to
think
that
the
shortwave
certificate
is
a
good
potential
solution.
I
mean
you
know
what
why
don't
you
go
there
and
maybe
I
think
if
you
were
just
able
to
articulate
the
relationship
between
the
CNI
working
group
and
their
work.
You
know
at
in
saying
this
is
what
city
and
our
needs,
and
maybe
your
solution
could
fit.
He
roughly
that
way.
So
it's
a
potential
use
case
for
the
acne
new
work
item.
J
I,
think
that
would
be
receptive
to
that
and
if
you
say
we
would
have
such
and
such
requirements,
they
would
listen
to
that.
So
I
would
encourage
you
to
do
that,
but
I
don't
think
we
can
come
up
and
say
you
know
the
working.
The
CD
networking
group
has
decided
that
this
is
the
right
solution.
Therefore,
you
must
do
this
for
us.
That's
what
I
feel
remember
not.
H
Thanks
so
one
thing:
so,
if
you
guys
are
going
to
require
changes
to
user
agents,
that's
not
an
ACME
thing!
That's
a
TLS
thing
because
that's
negotiation!
There
me,
if
you're,
going
to
require
new
bits
in
the
Tila
in
what
goes
into
a
pickax
certificate,
you're
going
to
need
to
get
make
sure
that
they
may
at
that
point
its
user
agent.
That
means
it's
TLS,
client
you're,
going
to
need
to
make
sure
to
let
you
know.
We've
got
TLS
on
board
for
that.
P
O
J
J
Much
faster
than
then,
you
know
we
we
can
follow
so
I
think
as
a
way
to
keep
track
on
the
relevant
IGF
work,
that's
happening
around
us
and
how
we
could
use
it.
I
think
that
would
be
useful
and
in
fact,
I
mean
you.
You
might
want
to
use
that
document
and
fit
it
into
the
acne
working
group
and
say
you
know,
listen.
This
is
our
you
know.
J
Maybe
one
document
where
you
you,
you
explain
the
CD
and
I
problem
that
we're
trying
to
solve,
and
you
said,
we've
identified
this
piece
of
working
idea
that
piece
of
work.
This
is
how
each
of
them
could
be
used.
It
is
what
we
understand
eyes,
good
and
bad
about
it.
Just
for
information,
and
if
you
were
to
you
know,
you
could
also
identify
the
missing.
If
you
have
specific
requirements
from
this
solution,
you
could
say
what
we
think
the
solution
doesn't
do,
that.
That
would
be
a
limitation
for
us.
J
J
R
So
I
was
telling
people
that
I
probably
spent
you
know
quarter
to
one
third
of
the
time
on
CD
and
I,
but
it
was
for
a
good
reason.
I
think
we
got
three
or
four
documents:
Roy
SG,
so
I
was
actually
really
impressed.
How
quickly
editors
and
chairs
and
Shepherds
reply
to
all
the
comments
and
how
quickly
comments
were
dealt
with.
So
thank
you
for
that.
I
think
we're
right
well
done
collectively.
R
J
J
C
People
feel
like
we
need
at
this
point:
we're
assuming
footprint
and
capabilities
will
fall
off.
The
agenda.
Metadata
will
fall
off
the
agenda.
Request,
routing
will
fall
off
the
agenda.
All
right,
you
are,
I
signing,
will
still
be
on
the
agenda,
hoping
we
get
at
least
one
rewrite
in
between
and
I
I
do
think
it's
it's
useful
to
keep
talking
about
HTTPS,
even
though
the
solution
keeps
changing
on
Frederick
every
single
meeting,
he
gets
to
have
a
new
draft
every
single
meeting,
but
do
we
think
that
we
need
a
meeting
for
URI
signing
in
HTTPS?