►
From YouTube: IETF105-MBONED-20190725-1550
Description
MBONED meeting session at IETF105
2019/07/25 1550
https://datatracker.ietf.org/meeting/105/proceedings/
C
D
D
C
D
D
F
F
G
D
H
Okay,
we're
ready
to
get
started,
welcome
to
M&D,
get
to
know
your
neighbor
introduce
yourself
to
everyone.
You
know
hopefully
you're
all
meant
to
be
in
a
Modi.
Here's
a
note!
Well,
you
probably
haven't
seen
this
yet,
but
it
actually
can
be
read
in
iambic
pentameter,
yes,
yeah,
that's
a
fun
fact:
it
was
written
in
iambic,
pentameter.
H
H
H
The
first
two
drafts,
the
Dryad
draft
jakes
triad
draft
did
just
complete
working
group
last
call
it
is
in
the
hands
of
the
Shepherd,
and
we
would
like
to
thank
Tim
toon
town
for
volunteering
to
Shepherd
that
one
the
EM
cast
problems
draft
did
complete
work.
Last
working
group
last
call
with
there
were
some
minor
revisions,
we'd
like
to
kind
of
go
through
Charlie's,
going
to
provide
an
update
on
all
the
changes
that
made
most
of
them
were
textual
somewhere.
H
You
know
everything
was
minor,
but
there
are
a
few
additions
and
let's
decide
if
we
think
we
need
another
working
group
last
call
for
that.
One
based
on
those
last
few
changes
that
were
made
and
whenever
that's
ready,
though,
because
it
did
seem
to
successfully
complete,
we
had
enough
support
for
it
to
move
on.
Thank
you
to
Jake
for
volunteering
to
be
the
shepherd
of
that
one.
H
Here's
your
opportunity
as
a
reminder
to
please
provide
feedback
if
you
support
or
do
not
support
working
group,
the
advancement
of
these
documents,
please
speak
up
we're
running
that
last
call
for
the
next
few
weeks,
but
we
wanted
to
run
it
through
IETF
so
that
we
could
remind
everyone
in
the
room
that
hey
here
now
would
be
a
good
opportunity
to
if
you
forgot
the
send
hit
the
send
button
on
your
email
that
you
have
feedback
on
these
drafts.
Now
is
the
time
to
do
it.
H
The
last
active
work
draft
is
the
yang
models
and
Sandee
wanted
me
to
bring
this
one
up,
because
she
is,
she
is
looking
for
feedback
as
well.
Is
this
ready
for
working
group
last
call
first
what
what
what?
What
is
the
Stig
or
Warren?
What
exactly
is
the
process
for
the
young
doctors?
Do
we
send
it
to
them
after
working
group
last
call?
Do
we
send
it
to
them
for
feedback
prior?
How.
I
H
I
B
K
Yeah
Jake
Holland
I
asked
sandy
about
this
because
my
opinion,
it
was
basically
if
it
works.
It
looks
okay
to
me,
I
read
it
also,
and
she
said
that
yes,
they've
been
running
it
and
it's
in
it's
in
testing,
so
I
don't
know
how
to
incorporate
that
feedback
into
the
consensus
process,
but
I
feel
like
that
is
the
you
know.
If
it
actually
works
for
deployed
systems,
then
we
probably
should
drop
her
stamp
it
and
get
this
out
the
door.
I
M
G
H
K
Yeah
Jake
Holland
I
have
not
implemented
this
yet,
but
but
that
is
the
plan
it's
gonna
be
necessary.
It
will
I
will
touch
on
it.
Briefly
in
my
hackathon
update
I'd
be
happy
to
take
questions
about
it
and
I.
Think
I'll
have
my
slot
has
plenty
of
time,
then
so
yeah
please,
it
is
I'll
just
say
it
is
still
highly
relevant
and
will
be
coming
up
again.
O
H
I
F
I
I
I'm
not
sure
how
much
I
need
to
explain,
but
basically
traceroute
uses
like
hundred
ports
yourself,
but
they
only
got
one
port,
a
sign
from
Ayane,
which
is
in
the
port
registry,
the
the
the
port
numbers
coming
after
that
the
next
several
hundred
pores
are
just
Markus
unassigned
and
M.
Chase
was
the
first
application
or
service
that
got
the
port
number
in
that
range,
and
the
problem
you're
seeing
now
is
M
trace
is
actually
working
just
fine,
but
if
someone
does
a
trace
route,
what
trace
wrote
does
is
I.
I
Think
it's
like
the
first
packet
has
like
the
lowest
port
number.
The
next
one
with
a
higher
TTL,
has
the
next
higher
port
number
and
so
on.
And
then
you,
you
expect
from
routers
on
the
path
to
get
an
ICMP
message
back,
because
there's
nothing
listening
on
that
port
and
you
can
then
mark
the
TTL
show
that
the
round-trip
time
and
stuff
to
that
router.
I
I
P
P
H
So
I
have
a
patient
but
Lenny
Juliana
Jennifer.
So
here's
what
I
don't
get
I
mean
Windows
doesn't
do
this
windows
sends
an
ICMP
echo
reply
and
with
a
TTL
and
the
important
part
is
it
sets
it
with
a
TTL
and
it
expects
a
TTL
expired.
The
fact
that
UNIX
is
sending
it
with
a
TC
with
a
UDP
port
and
a
different
port.
What
does
it
matter?
It's
waiting
to
hear
back
what?
Why
isn't
behaving
the
same
way,
which
is
I,
can
pick
out
any
port
I
want.
It
doesn't
need
to
go
anywhere.
H
H
I
R
Warren
Kumari,
as
far
as
I
understand,
UNIX
uses
multiple
port
numbers,
because
otherwise
you
have
to
send
one
traceroute
packet,
wait
for
it
to
come
back.
Send
the
next
one
wait
for
it
to
come
back.
If
you
spread
it
across
multiple
port
numbers,
you
can
fire
a
bunch
of
them
and
get
your
response
as
fast
as
what
I'd
understood.
Whatever
the
case,
traceroute
has
been
around
for
so
long
and
is
so
widely
implemented
according
to
the
unix
way
that
I,
don't
really
think
we
can
say
you
know
all
implementation
should
go
and
fix
themselves.
R
I
No
I'm
sure
there
are
some
reasons
for
this,
but
yeah
I
spoke
to
Jana
in
a
break
and
they
were
saying
yeah.
It
should
be
possible
for
us
to
get
a
different
port
number.
They
may
need
our
ad
to
sort
of
approve
of
it
or
something
I'm,
not
sure,
but
but
I.
Guess,
though,
if
you
were
to
change
the
port
number,
it
means
that
we
need
to
update
the
existing
RFC,
maybe
even
obsolete
it,
to
make
sure
that
people
don't
implement
the
old
one
with
the
wrong
port
number.
P
I
P
H
K
R
Something
similar
kind
of
happened
in
sorry,
Warren
Kumari,
still
something
similar
happened
with
home
net,
where
there
was
some
advice
which
turned
out
to
not
necessarily
be
great
I'm,
not
saying
that.
That's
what
happened
here
but
I
think
the
right
thing
to
do
is
to
file
an
errata.
Errata
can't
be
used
to
actually
update
an
RFC,
and
so
it
would
have
to
be
rejected
or
'rock
document
update.
R
But
we
can
pointed
it
and
there's
some
warning
I'm
and
then,
at
the
same
time
there
should
be
a
new
RFC
like
a
new
draft,
could
move
to
RFC
ready
he
being
like
identical
to
the
last
one
with
the
string
change.
So
we
would
need
a
new
RFC.
We
couldn't
just
use
errata
and
just
say:
I've
changed
the
court
through
that
yeah.
R
I
I
I
J
S
H
I
H
M
D
O
T
H
T
All
right
well
so
after
it
goes
like
after
the
last
ITF
and
during
the
discussion
in
idea.
There
are
quite
many
comments.
Some
of
them
were
generated
at
the
hackathon
and
after
that
I
submitted
revision.
Number
five
on
April,
15th
and
requested
working
group
last
call
next
slide.
Please!
So
here's
a
list
of
some
of
the
changes
there
was
a
new
section.
Essentially
Jake
Holland
just
gave
you
the
text
for
a
conversion
of
multicast
a
unicast
and
included
a
MT
as
an
existing
solution
and
described
some
future
applications.
T
There
were
several
places
all
along
in
the
text
that
were
a
generative
sort
of
mean
needed
to
be
more
generic
instead
of
referring
to
specifically
IETF
conference
solutions
and
so
that
those
been
sort
of
caught
more
and
more
over
time
and
I
hope
it's
old
done,
but
it
could
still
be
interpreted
perhaps
from
a
two
specific
way
sent
places.
But
added
UPnP,
universal
plug
and
play.
T
Is
a
representative
multicast
protocol
incited
the
bridging
code
for
people
who
wanted
to
convert
multicast
a
unicast
and
then
there's
a
lot
of
bibliographic
citations
and
actually
there's
more
updates
are
needed
which
I'll
get
to
that
a
little
later
and
then
more
editorial
improvements
and
grammatical
Corrections.
The
next
slide,
please.
T
So
that
was
submitted
on
April
15th,
and
then
there
was
some
more
discussion
on
the
mailing
list.
It's
been
some
really
good
discussion.
Geoffrey
zhang
made
a
comment
about.
I
think
it
was
a
superuser
webpage.
It
had
a
lot
of
discussion
about
the
problems
in
this
draft
and
mentioned
some
more
things
that
hadn't
been
considered
specifically
about
how
Wireless
failures
can
really
complicate
problems
with
multicast
group
membership.
T
So
the
way
of
handling
that
comment
was
to
update
the
security
considerations
and
really
ended
up
just
sort
of
summarizing
some
of
the
text
that
was
on
the
webpage.
The
other
big
change
that
was
done
was
really.
There
was
a
lot
of
comments
from
Bill
Atwood,
who
made
a
extremely
detailed
and
appreciated
you
review
of
the
document,
and
he
also
suggested
included,
including
Dryad
as
a
relay
discovery.
A
possibility
next
slide,
please.
T
So
in
that
all
those
things
resulted
in
submitting
a
revision
number
six
I
think
that
was
done
in
the
early
part
of
July.
So,
as
I
mentioned
news
hacked
into
security
considerations
and
also
including
Dryad
at
the
discovery
mechanism
and
I
actually
did
an
English
refresher
course
learning
about
when
to
use
which
versus
that
and
a
mouth
versus
number
and
a
few
other
things,
and
then
more
bibliographic
updates
and
editorial
improvements.
T
Well,
since
then,
there's
been
some
more
email
from
Bill
Atwood,
pointing
out
a
few
other
things
that
need
to
be
taken
care
of
him
plus
email
from
Jay
Colin
and,
interestingly
enough.
Jake
is
arguing
that
Dryad
should
not
be
listed
as
a
discovery
mechanism,
because
it's
really
useful
from
the
remote
side
and
also
a
few
other
minor
Corrections
on
the
draft.
So
that's
pretty
much
it
but
I
have
for
now.
The
next
document
I
thought
I
would
try
to
get
it
out
this
week.
T
T
So
that's
what
I
just
said:
I
will
produce
a
new
draft
quite
soon
and
if
there's
any
additional
reviews,
oh
and
by
the
way,
I
guess
special
thanks
to
a-1
Kumari
for
motivating
people
to
submit
some
reviews
for
the
draft.
That
was
very
helpful.
So
that's
it
for
my
presentation
and
I'll
be
happy
to
answer
questions,
but
I
just
want
to
mention
that
sometimes
yeah
I
think
you
have
to
be
close
to
the
mic,
because
sometimes
the
echoes
in
the
room
make
it
hard
for
me
to
hear
what
you're
saying
otherwise.
H
Thank
You,
charlie,
so
I
think,
given
the
changes,
you've
described,
I
think
after
you
get
that
last
that
next
Rev
out
I
think
we
should
have
a
brief
another
working
group
last
call
because
these
are
you
know
some
substantive
additions,
so
we'll
run
another
quick
last
call
just
so
that
folks
have
an
opportunity
to
review
what
the
changes
have
been
made
and
make
sure
there's
no
objections
to
those
changes.
Okay,.
T
R
In
kumari,
that's
batino
house:
if
you
do
another
well,
when
you
do
another
working
group
last
call,
is
it
going
to
be
one
where
you
expect
replies
or
will
Simon's
be
taken
as
consent,
or
how
do
you
want
to
run
it?
Just
gloucester
was
really
hard
to
get
any
comments.
I
would
be
fine
with
doing
silence.
H
R
H
That's
how
we'll
frame
it
yeah.
Please
speak
up
if
you
have
any
objections
to
these
changes,
so
so
charlie,
when
you
do
submit
it,
send
to
the
working
group
just
kind
of
maybe
a
diff
between
that
that
shows
specifically
so
the
folks
don't
have
to
Day
card,
but
that
they
can
specifically
see
the
new
text
that
was
added
since
the
original
working
group
last
call,
and
that
way
it's
easy
for
people
to
review,
and
if
they
have
an
objection,
they
can
speak
up.
Okay,.
T
T
A
A
There
we
go
so
in
say,
video
delivery,
for
instance,
which
is
kind
of
the
target
application
for
this.
They,
the
the
data
that's
received,
has
some
properties
that
are
important.
First,
is
of
the
payloads,
have
a
deadline.
If
you
don't
receive
a
particular
payload
by
a
certain
point,
then
you
might
as
well
just
throw
it
away.
You
may
as
well
not
not
have
gotten
it
at
all,
so
in
some
sense,
retransmits
are
not
are
not
interesting.
The
other
problem,
the
other
big
problem
is
that
is
that
with
multicast
video
delivery,
there
are
many
receivers.
A
So
one
of
the
things
that
TLS
relies
on
for
efficiency
in
its
in
its
encryption
is
that
it
only
uses
asymmetric
crypto
to
negotiate
a
symmetric
key.
The
symmetric
key
is
then
known
only
to
the
sender
and
the
receiver,
or
you
know,
they're
known
it's
known
to
each
peer.
So
if
you
didn't
originate
a
message
encrypted
and
signed
with
that
symmetric
key,
you
know
that
the
other
party
did-
and
you
know
not
notwithstanding
key
exfiltration
attacks
and
whatnot.
A
The
other
problems
with
with
video
that
are
or
with
with
unreliable
delivery,
are
that
datagrams
are
lossy
and
that
retransmits
are
not
appropriate
because
in
multicast
you're
not
I
mean
how
would
you,
how
would
you
retransmit
a
multicast
packet
right?
You'd
have
to
you'd
have
to
have
it
transmitted
to
you
via
a
unicast.
You
need
some
signaling
mechanism
and
you
don't
even
know
who
the
sender
is
most
of
the
time.
So
so
the
the
naive
solution
to
this
is
to
sign
individual
packets
right.
A
So
you
have
you
send
you
know
you
divide
your
video
into
into
individual
packets.
You
leave
enough
room
for
signature,
you
sign
it
using
an
asymmetric
signature
algorithm
and
you
append
that
to
the
packet.
So
the
pros
for
this
approach,
being
the
naive
approach
is
that
you
can
verify
every
packet
that
you
receive
so
big
con
here
is
that
it's
very
CPU,
very
CPU
intensive
four
receivers.
A
It
may
also
be
CPU
intensive
for
the
sender,
but
that's
not
the
case
that
I'm
targeting,
because
typically
the
sender
is
also
the
sending
infrastructure-
is
also
involved
in
video
encoding,
which
is
much
more
CPU
intensive.
But
the
client
may
have
dedicated
hardware
for
video
decoding.
It
probably
doesn't
have
dedicated
hardware
for
doing
some
for
doing
signature
validation.
A
So
tesla
tries
to
solve
this
problem
not
by
using
asymmetric
crypto,
but
it
introduces
asymmetry
by
doing
a
by
holding
back
the
key,
the
symmetric
key
that
is
used
to
sign
the
packets
and
releasing
it
after
it
expects
all.
The
receivers
have
received
the
packets
that
were
signed
with
that
key
right.
A
So
essentially,
as
you
can
see
in
the
diagram
here,
there
are
three
packets
that
were
signed
with
key
k1
there's
a
deadline
at
which
all
receivers
must
have
received
that
key,
and
then
it
releases
key
k1
and
the
receivers
can
use
it
to
verify
the
packets.
Then
it
has
to
use
a
different
key
for
any
subsequent
packets.
This
is
a
this
is
a
good
scheme
in
certain
circumstances,
but
it
does
have
some.
It
does
have
some
cons.
A
The
other
big
problem
that
we
have
is
that
if
you
try
to
use
this
inter
domain
by
using
say,
NTP
well,
even
with
even
with
n
TS,
which
hasn't
even
been
standardized
yet
I,
don't
know
that
I
as
an
as
an
enterprise
or
I
as
a
as
a
CDN
employee,
would
want
to
trust
NTP
as
a
security
mechanism
for
the
streams
that
I'm
publishing.
So
once
the
keys
been
released,
all
bets
are
off
and
any
receiver
can
then
can
then
inject
a
packet
signed
with
k12
any
receipt
to
any
other
receiver.
P
A
This
isn't
this
isn't
an
encryption
scheme.
This
is
an
authentication
scheme.
The
the
idea
is
that
is
that
the
the
publisher
I
mean-
and
this
is
not
the
algorithm-
that
I'm
that
I'm
talking
about
in
the
rest
of
my
talk
right.
But
the
idea
here
is
that
is
that,
in
order
to
keep
a
one
of
the
receivers
which,
in
order
to
authenticate
the
signature,
has
to
know
k1
from
injecting
packets
into
the
stream,
it
can't
it
cannot
get
k1
until
after
all
the
packets
have
been
received.
I
A
Well,
the
problem
is
that
an
attacker
that
is
trying
to
target
you
can
delay
that
can
delay
the
packets
in
a
way
that
causes
you
to
authenticate
something
that
you
wouldn't
have
authenticated.
If
it
were
just
if
it
were
expected
network
delay,
I
don't
want
to
get
too
far
into
analyzing.
This,
though,
since
this
is
sort
of
where
I'm
going
with
this
is
that
there
are
situations
in
which
you
really
do
want
a
symmetric
crypto
to
provide
your
asymmetry.
A
So
one
approach
that
I
tried-
and
we
actually
went
to
sect
dispatch
with
this
year
ago,
was
a
sign
manifest.
So
essentially
you
send
a
bunch
payloads
and
then
every
so
often
you
have
a
manifest
that
is
signed,
and
this
manifest
contains
hashes
of
all
the
payloads
that
you
sent
previously.
So
the
pros
of
this
is
that
it's
lots
of
lots
of
fast
hashes.
Only
one
signature
per
you
know
n
packets,
but
the
cons
are
well
what,
if
you
lose
a
manifest?
A
A
The
other
problem
is
kind
of
a
conceptual
problem,
which
is
that
the
which
is
that
the
fate
of
the
authentication
information
is
separate
from
the
fate
of
the
data
payloads,
so
you
can
receive
all
the
data
payloads
and
not
receive
the
authentication
payload,
and
that
would
be
a
perfectly
normal
situation
to
expect
on
the
Internet,
and
in
that
case,
all
of
the
data
you
receive
is
now
useless
because
you
can't
verify
it.
So
a
different
approach
is
to
use
change
integrity
right.
A
So
here
you
have
a
series
of
a
series
of
packets
where
each
packet
contains
the
hash
of
the
previous
packet
and
then
occasionally,
you
have
a
signature
that
allows
you
that
acts
as
the
as
the
trust
anchor
for
that
sequence
of
packets.
So
the
pros
of
this
are
again
sparse
signatures.
You
only
have
a
signature
every
so
often
and
there's
tolerance
for
signature
loss,
because
if
you
lose
this
signature,
you
just
have
to
wait
for
the
next
one.
A
As
long
as
you
receive
all
the
packets
in
the
meantime
that
form
a
chain
back
to
whichever
one
you
haven't
been
able
to
haven't,
been
able
to
authenticate
the
problem
with,
that
is
that
one
loss
breaks
the
chain.
So
so
it's
it's
not
tolerant
to
loss
in
a
way.
That
is
interesting,
but
it
is
better
in
some
sense,
because
the
authentication
information
is
does
share
fate
in
in
a
limited
way
with
the
data
that's
being
transmitted.
A
A
Last
year,
Eckerd,
just
like
out
of
the
blue,
remembered
some
paper
from
like
you
know,
17
years
prior,
that
described
a
solution
to
the
exact
problem
we
were
we
were
having,
and
this
is
the
golian
mode
of
dugu
paper.
This
provides
a
dag
of
hashes
with
periodic
signatures,
the
the
so
in
in
this
diagram,
the
the
arrows
are
directed
in
such
a
way
that
that
a
hash
of
a
packet
is
contained
within
the
the
packet
at
the
end
of
the
directed
arc
right,
so
a
sense.
A
So
in
this
case,
for
instance,
the
hash
of
b0
would
be
contained
within
the
packet,
a
for
right,
I'm
not
going
to
go
through
this
believe
it
or
not.
It's
a
dag.
This
is
actually
a
simplified
version
of
what
what
the
algorithm
is
actually
doing,
but
it's
it's
a
little
bit
complicated
to
read
the
paper
to
understand
how
to
do
how
to
do
the
construction,
but
it's
actually
fairly
easy
to
implement
the
construction
because
they
almost
provide
a
an
algorithm
in
the
paper
itself.
A
So
the
pros
here
that
you,
you
always
get
two
chances
to
get
each
packet
hash,
but
they're
better
distributed
in
such
a
way
that,
even
if
you
lose
both
packets
that
are
that
contain
a
hash
of
one
of
the
packets
in
the
stream.
You
are
very
unlikely
to
lose
many
other
packets
as
well,
because
there's
additional
redundancy.
There
are
many
ways
to
get
from
a
signature
to
any
particular
packet
and
I've
proved
this.
With
with
some
running
code.
A
The
cons
are
it's
complicated
as
I
said,
and
there's
also
a
variable
number
of
hashes
per
packet,
which
means
that
you're
the
data
that
you're
transmitting
you
must
be
able
to
segment
it
into
into
variable
length
pieces
which
might
be
a
problem
for
some
payloads,
but
not
for
the
use
case
that
Jake
and
I
are
working
on.
So
the
key
properties
of
this
are
that
it
has
optimal
resistance
to
bursty
packet
loss.
A
There's
a
nice
proof
of
this
in
the
paper
and
as
I
said
it
has
tolerance,
your
signature
loss
just
like
the
the
other
chained
algorithms,
because
you
can
just
wait
for
the
next
signature
to
come
through.
One
of
the
other
nice
features
there
that
it
follows
on
from.
That
is
that
if
your
receiver
is
smart,
it
doesn't
have
to
authenticate
every
signature.
A
You
can
send
more
signatures
than
you
expect
the
receiver
to
actually
authenticate,
and
it
can
just
skip
some
of
them
as
long
as
it
as
long
as
it
knows
it's
going
to
get
one
eventually
within
its
deadline.
So
the
next
steps
are
our
running
code.
I
have
code
that
is
running
now.
It's
not
public,
yet
I
hope
to
make
it
public
in
the
next
like
week
or
two
just
have
to
go
through
the
legal
department,
Akamai
and
then
there's
a
bunch
of
design
choices
that
need
to
be
made.
A
I
put
one
issue
in
the
in
the
github
repo.
That
would
be
interesting
to
get
some
feedback
on
I'm
about
opacity
versus
overhead.
So
the
way
that
I
currently
have
it
implemented,
it
is
not
possible
with
access
to
out-of-band
metadata.
That
tells
you
how
long
specific
fields
are
I,
don't
know
whether
people
feel
strongly
about
making
it
possible,
even
without
that
metadata
and
then
just
in
general,
we
need
to
flush
out
the
draft
but
I'm
curious
if
other
people
have
if
people
have
questions
or
if
they're
interested
in
doing
this
work.
P
P
Understanding
the
relevance
the
authentication
comes
for
free
with
the
crypto.
We
can
look
at
the
overall
complexity
of
the
system.
Gcm
seems
to
be.
You
know
something
that
that
I
said
is
working
fairly
extremely
fast
in
you
know,
crypto
hardware,
so
basically
that
if
I
haven't
tried
to
analyze
what
it
means,
if
you
have
velocity
channel
but
otherwise
the
question
really
is
why
don't
we
just
use
crypto
with
GCM,
because
that's
help
authentication
yeah.
A
Sorry,
I'm
not
I'm,
not
sure
how
that's
how
that's
relevant
to
to
loss
right
to
the
issue.
The
the
issue,
the
issue
with
the
issue
with
authenticating
a
lossy
stream,
is
that
if
you,
if
you
don't
include,
if
you
don't,
if
you
can't
authenticate
individual
a
segments
of
data
that
you
receive
and
you
need
to
have
the
whole
like
all
of
the
data
in
order
to
authenticate.
I
Thanks
Jake
Jake's
volunteered
to
help
sighs
one
for
the
one
thing
I'm
wondering
about
maybe
stupid
question
again,
but
you
know
you
can
do
like
a
manifest,
as
you
said,
those
every
flight
packets
whatever
with
signatures.
So
it's
kind
of
wondering
if
you
take
that
manifest
of
hi
packets,
then
they
use
some
redundant
coding
of
that
and
you
include
you
know,
parts
of
that
in
each
of
the
next
five
packets
or
something
like
that.
So.
A
That's
actually
that's
very
similar
to
what
Jake
is
proposing,
so
we
were
not
actually
the
way
that
we're
the
way
that
we
are
intending
to
use.
This
is
not
to
actually
put
the
video
into
this
payload,
but
actually
to
use
this
stream
to
distribute
a
manifest
a
rolling
window
manifest
of
hashes
of
video
packets.
K
K
U
P
The
notion
of
you
know
the
need
the
requirement
to
do
something
like
this,
because
I
would
say
the
fundamental
reason
why
you
know
a
fast
mechanism
for
a
symmetric
transmission
like
that
exists,
a
lot
more
than
multi
casting
than
unicast
E
right,
because
in
in
in
the
in
the
unicasting
way
kind
of
all
these
symmetric
things
have
a
lot
of
good
solutions,
whereas
the
asymmetric
stuff
is,
you
know,
effectively
reduced
and
then,
basically
here
your
whole
argument
would
be
in
multicast.
We
can't
do
it
in
the
same
way.
We
need
the
asymmetric
stuff.
P
So
if,
basically,
this
working
group
is
required
to
produce
something
that
says,
you
already
must
do
this
and
then
some
other
working
group.
That
really
knows
what
crypto
means
would
basically
standardize.
Whatever
is
needed
in
this
case
right
but
I
mean
this
is
not
a
product
called
work,
working
group
right
so
and
him
wouldn't
be.
What
protocol
working
group
either
right
this
would
have
to
go.
A
I
think
you're,
probably
right,
I
kind
of
I
kind
of
skipped.
Part
of
the
skill
that
I
had
prepared
and
I
probably
should
have
included
that
which
was
which
was.
Does
it
make
sense
for
embo
need
to
take
on
this
work?
The
reason
I
brought
her
here
was
that
this
is
the
group
of
subject
matter.
Experts
about
the
application
that
we're
planning
to
use
it
for,
but
do
we
need
to
reopen
m/sec,
should
I
go
back
to
sect
dispatch?
What
is
you
know?
What
are
the
next
steps
for
this.
K
J
holin
what
we
took
this
to
SEC
dispatch
last
time-
and
this
is
where
we
got
the
feedback-
we're
happy
to
do
it
again
and
to
open
a
working
group
for
it.
Their
feedback
was
that
we
need
to
get
support.
So
that's
part
of
what
we're
doing
here
is
this
being
the
the
application
experts
that
can
talk
about
the
need
for
it.
K
P
Don't
know
the
security
area
well
enough
to
say
how
they
want
to
run
their
stuff
right.
In
terms
of
to
me,
this
looks
like
whatever
ESP
or
whatever
other
stuff
is
defining
you.
You
know
form
of
crypto
profile
for
that
that
would
effectively
do
this
stuff,
I'm,
not
sure
about
the
additional
complexity
with
the
metadata
or
something
but
I
think
it's
very
viable
for
them
to
say
we
need
to
see
some
interest,
so
the
question
is:
what's
the
best
type
of
interest
we
can
express
right
so
so.
F
R
F
Is
Craig
I,
just
I,
don't
disagree
with
you,
but
I
think
it
would
frame
it
differently.
I
wouldn't
say
more
valuable,
I
would
say
additional
value.
The
use
case
is
just
as
important.
They
they
don't
see
a
reason
to
do
it.
We
do
so
together,
yeah
right,
so
you
know
requirements
are
clear.
There's
a
solution
here
that
may
be
enough
even
getting
their
sanity
check
on
something
is
uses.
F
F
A
I
would
so
one
thing
I
would
say
is
that
as
I've
presented
it
here,
there's
nothing
novel
crypto
wise
there,
although
there
are
some
things
that
we
would
like
to
do,
that
probably
would
you
know
probably
raise
the
hairs
on
the
you
know
the
back
of
Ben's
head
if
we
actually
implemented
them,
such
as,
like
truncating
hashes
right?
How
much
can
we
do
that
and
still
have
a
security
margin
right?
So
that's
the
kind
of
thing
where
we
would
definitely
need
security
area
input
well,.
P
P
So
there
were
these
parameters
that
he
said
right
so
I
don't
know
anybody
here
who
could
and
that
may
impact
whether
you
need
a
metadata
channel
or
whether
we
feel
oh,
we
can
get
to
statically
define
a
profile
that
will
be
fine
forever
and
then
somebody
comes
around
and
says:
crypto,
agility
and
so
I
mean
there
there's
a
lot
more
stuff,
which
you
know
I
think
if
we
do
it
with
review
afterwards
towards
the
end
right.
We
do.
We
do
everything
working
for
class
call
and
then
core
issues
come
up
right.
P
K
K
To
that
end,
I
published
a
Lib,
em,
CRX
library,
BSD
license
I,
have
it
running
with
basic
SSM
receive,
and
it's
compiling
on
Mac
and
Linux
and
in
fact
receiving
data.
My
intent
is
to
add
the
empty
gateway
with
Dryad
discovery
with
the
local
DNS
SD
discovery.
So
the
the
you
know
it's
it's
critical
to
the
use
case
of
deploying
multicast
that
we
get
that
when
you
can
discover
a
local
relay,
you
use
it
so
that
a
locally
capable
multicast
network
actually
provides
multicast.
K
If
you
just
connect
to
a
remote
relay
you
will
you
will
sort
of
ossify
multicast
before
you
can
get
the
actual
replication
it
has
to
go
over
the
access
network?
That's
my
that's
my
view
of
it.
You
know
the
the
place
you
get.
The
most
games
is
in
those
fiber
networks
and
in
the
cable
networks,
where
you
wear,
there's
physical
bits
on
the
wire
that
don't
you
have
to
get
transmitted
because
you
did
it
in
multicast.
So
that's
what
I'm
trying
to
accomplish
with
this
and
the
other
piece
is.
K
That
is
the
authentication
which
you
know
on
the
internet.
We
have
to
send
over
untrusted
networks
and
in
in
actual
deployment,
it's
going
to
be
critical
to
get
that
working.
That's
why
we've
started
this
work,
we're
gonna,
try
and
make
it
run,
and
it's
gonna
go
into
that
library
with
the
same
API
or
a
small
extensions
to
the
API.
K
That's
there
now
for
how
to
do
the
receive
and
the
application
side,
it
will
be
relatively
invisible,
so
at
the
hackathon
over
the
weekend
we
did
I
got
it
running
and
integrated
in
the
upstream
for
the
app
for
the
taps.
Reference
implementation,
it's
a
Python
implementation
of
taps
taps
is,
is
working
on
a
sort
of
replacement
API
for
socket
libraries,
so
I've
been
participating
with
that
group
and
I
have
now
integrated
this
multicast
receive
library
into
that
reference
implementation.
K
It
was
running
it's,
it
is
research
code,
so
this
is
not
super
deployable
on
its
own,
but
it
was
heartening
to
see
it.
You
know
be
successful
with
the
API
that
was
there
and
I
think
it
does
represent
an
worthwhile
proof
of
concept.
The
other
thing
is
the
upcoming
idea,
which
is
I,
have
a
prototype
running
which
uses
the
same
API
and
runs
under
chromium,
providing
a
JavaScript
API,
which
you
issue
a
joint,
and
now
you
start
receiving
UDP
payloads,
once
we've
integrated
the
discovery
and
the
and
the
authentication.
K
This
is
going
to
mean
that
you're
going
to
receive,
authenticated,
payloads
and
you'll
be
doing
it.
Whether
or
not
you
have
multicast
capability,
but
if
the,
if
the
local
network
does
provide
multicast
capabilities,
then
you
would
be
getting
it
with
multicast.
So
that's
the
basic
idea.
This
also
is
running
and
it's
gonna
need.
This
is
going
to
need
a
lot
of
work.
In
fact,
yes,
this
is
my
to-do
list.
K
There's
the
this
is
not
going
to
be.
You
know
done
in
November
I
doubt
it
will
be
done
in
April,
but
I
don't
know
depending
if
I
can
get
any
support.
I
I
can
type
all
of
this
I
think
I
know
what
to
type
I.
Think
I
know
how
to
make
this
go,
but
it's
there's
a
lot
of
pieces
to
put
together
and
and
before
it
can
really
be
deployed.
I
think
all
of
this
or
you
know
appropriate
substitutes,
that
simplify
are
going
to
have
to
be
there
so
yeah.
K
K
I
K
That
is
an
interesting
idea,
so
the
socket
API
is
arguably
a
poor
choice.
For
some
of
this,
you
need
to
you
know,
I'm
using
a
socket
API
underneath
it.
Of
course,
it's
not
really
cross-platform.
It
doesn't
work.
Cross-Platform,
there's
different
sock
hops.
You
have
to
do
to
actually
issue
the
join
there's.
K
I
K
Group
right,
so
that's
that's
kind
of
what
the
the
role
that
this
library
is
trying
to
fill.
You
do
have
a
relatively
simple
SSM
join
API
and
your
you
know
the
the
hope
is
that
that
the
receive
side
use
cases
for
applications
actually
can
work
with
this
app
with
this
API
and
that
that's
going
to
be
somewhat
simpler
than
the
then
trying
to
use
sockets.
K
Know,
sockets
or
so
like
one
of
the
lessons
from
taps
is
that
if
they're
working
loop
is
formed
because,
like
three
different
groups
tried
to
do
this,
not
for
the
more
complicated
cases
of
multicast
with
like
extra
features
but
but
just
for
regulars,
you
know
ease
of
use
on
sockets
and
ended
up
deciding.
Actually,
this
is
kind
of
complicated
and
now
they've
been
hammering
out
of
for
a
couple
of
years
and
maybe
they'll
have
a
good
API
for
long.
I
V
D
Q
W
H
Q
W
So
since,
since
your
cognitive,
Chicago
is
kind
of
overwhelming,
with
number
of
people
in
the
room,
we
went
to
a
much
smaller
group,
throw
less
formal,
called
the
video
interest
group.
That's
the
median
every
ITF
since
then,
and
which
has
been
pretty
good
as
a
slob.
They
sort
of
the
the
nascent
ideas
to
sort
of
form
and
say
well
what
would
you
work
on?
W
How
would
you
tackle
things
and
I
think
we've
developed
a
really
good
community
of
interested
parties,
both
individuals
and
and
organizations
that
would
support
the
topic
space,
but
now
it's
time
to
maybe
make
it
a
little
more
formal
and
do
a
little
bit
more.
That's
why
we
called
for
the
media
ops
both
to
sort
of
open
it
up
to
the
rest
of
the
world
and.
Q
So
people
who
were
in
the
bath
have
heard
this
part
of
the
song
and
dance
before
so
part
of
what
we
were
hoping
to
do.
That
was
to
highlight
the
fact
that
there
are
many
video
activities
that
are
ongoing
at
the
ITF
that
don't
actually
fit
in
any
one
particular
place
and
identify
gaps
in
IETF
work
in
areas
of
incompatibility
with
video
technology,
development
efforts
being
carried
out
elsewhere.
So,
for
example,
gran
gave
a
presentation
about
the
the
sim
Tirek
dependencies
on
IETF
standards.
Q
W
W
W
So
often
you
guys
did
they're
starting
to
be
I'm
dependent
upon
IP
networks
and
so
part
of
the
takeaway.
That
up
for
me
on
this
is
that
there
is
this
new
set
of
parties
that
are
really
dependent
upon
us
and
they're
really
interested
in
stuff.
We
do
here
there's
an
opportunity
here
to
fire
up
some
working
the
ITF
and
bring
these
guys
in
as
well,
because
they
have
stuff
they
want
to
talk
to
us
about
and
it'd
be
us.
P
P
If
they
have
any
questions
about
the
technologies
that
they're
using
so
I'm,
just
wondering
you
know,
what's
what's
the
process
by
really
because
we've
we
have
adoption
of
IP
technologies
and
all
these
different
technologies
for
such
a
long
time
and
there,
and
always
the
ongoing
pain
that
everybody
would
ops
it
thinks
they
understand
this
stuff
better.
So.
Q
I
think
yeah,
so
I
think
part
of
the
problem
is
that
for
the
people
who
are
working
in
those
groups,
it's
even
if
they
ever
looked
at
an
IETF
schedule
or
at
the
ITF
webpage.
Heaven
forfend
never
would
have
no
idea
where
to
plug
in
right,
I
mean
maybe
they
would
understand,
while
I'm
using
v6
technology
and
I'm
gonna.
Do
it
this
way.
I!
Look!
Here's
a
v6
working
group,
it
was
like
none
of
the
work
items
are
relevant
to
what
they're
doing
so.
The
point.
P
F
P
Q
W
Well,
specifically,
to
this
point,
you
know
as
me
as
an
IT
effort
when
I
go
and
work
with
my
colleagues
in
these
other
groups,
which
I'm
a
member
of
simpie
and
I'm
on
the
board
of
the
streaming
video
alliance.
I
will
tell
you
I've
received
vocal
feedback,
many
a
time
from
people
who
have
tried
to
come
in
and
engage
with
us.
W
We
do
have
a
bit
of
a
reputation
of
not
being
the
friendliest
crowd
to
open
the
door
and
welcome
people
and
part
of
the
idea
that,
behind
this
is
it
could
provide
a
safe
video,
a
group
that
understands
video
concerns
and
also
understands
the
IGF
and
could
help
bridge
them
into
it.
So
how
that
might
work
in
practice,
for
instance,
would
be
hey.
I've
got
a
problem.
That's
video
related
that
I
think
such
as
IP
networks,
okay,
first
step
step.
W
Number
two
I
would
like
to
find
a
bunch
of
like
people
at
the
ITF
who
understand
this
problem
space
and
who
would
work
with
me
to
create
sort
of
an
essence
of
ID's
that
could
eventually
either
create
work
in
this
space
or
could
get
take
it
over
into
another.
Working
group-
that's
working
on
the
specific
stuff,
such
as
mbone
d1
fields,
ideas
are
allowed
to
be
developed
and
refined
so
that
they're
ready
to
be
brought
into
a
group
like
mo
D
or
some
other
group
within
the
ITF.
W
Q
Didn't
mean
to
I
didn't
mean
to
imply
that
nobody
succeeds
in
bringing
their
stuff
in
I.
Think
that
you've
you're
identifying
that
you
have
successfully
helped
bring
some
people
in
and
sort
of
smooth
their
their
access
to
getting
the
right
answers
and
and
we're
saying
there
are
some
people
who
don't
succeed.
Maybe
they
haven't
found
you
but
I
mean
the
point.
Is
there
are
people
for
whom
this
doesn't
work?
Maybe
the
gentleman
behind
you
would
like
to
make
a
remark.
B
Hi
family
come
on
love,
Harry
stone,
it
works,
I,
agree,
I,
think
this
is
very
much
needed.
I
know
from
talking
to
customers
in
the
kind
of
media
or
world
that
even
a
concept
like
an
IP
address,
it's
quite
keen
or
scary
to
them,
and
they
always
want
to
try
to
avoid
a
lot
of
cannae
technical
details.
So
I
think
we're
suggesting
mix
our
saying
so
I'm
very
useful.
Q
So
in
terms
of
the
boff
we
had
about
a
hundred
people
in
the
room,
100
something
people
in
the
room
yeah.
There
are
a
lot
of
people
there
and
there's
general
support
that
there
is
work
here
that
is
IETF
appropriate,
a
reasonable
number
of
people
who
are
willing
to
sign
up
to
the
mailing
list.
Here's
a
plug
the
mailing.
This
is
the
mop
set
IETF
done
org
mailing
list,
we've
just
set
it
up,
because
we've
been
camping
out
on
a
different
mailing
list
until
now.
Q
So
please
do
sign
up
if
you're
interested
and
don't
be
surprised
if
there
isn't
yet
a
lot
of
traffic,
but
also
an
outcome
is
that
clearly
we
were
not
clear
in
scoping
the
problem
space,
partly
because
this
is
not
a
traditional
ops
group
for
a
particular
protocol.
So
we
heard
that
we're
willing
to
work
with
that
and
we
will
be
back
with
some
creative
solutions
at
some
point.
Q
P
W
P
Q
P
Q
What
we
really
wanted
was
to
do
something
like
an
interest
group.
That's
why
we
were
informally
calling
it
a
video
interest
group
when
we
were
meeting
informally,
but
the
problem
was
trying
to
meet
informally.
Is
you
don't
have
bounds
on
your
discussion
right,
so
no
charge
no
charter
boundaries
and
also
no
possibility
to
actually
answering
the
question
because
he's
gone
off
to
take
a
call?
W
What
I
did
want
to
make
one
point
in
the
video
interest
group
that
we
ran
for
two
years
and
and
and
the
notes
from
it
are
online.
The
presentations
that
were
done
are
online
and
there
were
repeatedly
we
ran
basically
a
little
mini
workgroup,
so
people
did
come
and
give
presentations
and
actually
have
things
hey,
I'm
working
on
stuff
here,
that's
relevant
to
the
IETF,
and
this
is
work
I'd
like
to
do,
and
we
have
a
kept
haven't
say:
well,
that's
awesome,
but
we're
not
a
were
actual
working
group,
but
it's
Austin
you've
got
work.
R
So
yeah
I
mean
this
doesn't
look
like
a
normal
working
group,
but
I
don't
think
that's
necessarily
a
problem
right.
It's
fairly
clear
that
there
are
a
lot
of
people
who
want
to
do
some
sort
of
stuff.
It
doesn't
fall
into
the
regular
working
group
type
design,
but
that
doesn't
mean
that
it's
not
worth
doing
I
think
that
might
just
be
a
signal
that
we
need
something
else
other
than
working
groups,
I.
R
Think
for
now
we're
gonna,
try
and
leverage
it
into
a
working
group
because
redesigning
stuff
and
or
something
else
is
a
really
big
job.
I
think
there
is
some
sort
of
precedent
for
this,
which
is
things
except
dispatch.
Sec
dispatch
doesn't
always
do
its
own
work.
It
looks
at
things
and
sins,
then
both
other
places
and
that
kind
of
seems
like
a
model
that
we
could
have
used.
P
P
Q
And
so
that
actually
brings
us
to
why
we're
here,
because
we
were
invited
to
come
and
tell
you
all
about
this
work,
and
indeed,
given
this
this
sort
of
dispatched
like
structure
or
intention
of
the
other
work,
we
could
certainly
see
we
well.
The
mocks
might
working
group
might
attract
people
to
come
in
and
talk
about
video
challenges.
We
can
certainly
vector
participants
to
come
and
take
actual
multicast
issues
here
for
discussion
amongst
people
who
actually
will
be
able
to
point
them
more
precisely
at
solutions.
Q
W
H
H
He's
like
you
know,
we
do
have
a
solution
here,
yeah
so
so
yeah
we
would
love
the
you
know,
play
role
because
we've
been
trying
to
solve
a
lot
of
these
problems
and
we'd
like
to
know
you
know
we
would
love
to
have
better
feedback
from
the
relevant
groups
that
would
consume
it.
That
is
this
helpful.
Is
this
not?
Is
this
something
they're
they're
aware
of
you
know
we're,
were
you
know,
working
somewhat
assiduously
trying
to
come
up
with
solutions
and
tools
to
solve
these
problems
so
right.
Q
So
I
mean
this
is
what
I
throw
up
on
on
slide
in
preparation
for
this
discussion,
I'm
happy
to
take
suggestions
for
other
bullet
points
and
one
that
pops
mine
just
now
as
you're
describing
that
is,
you
know
we
might
want
to
make
sure
to
have
sort
of
a
standing
item
depending
on
the
scheduling
of
you
know,
hey
the
other
working
group
is
meeting
later
this
week.
Here's
some
topics
should
be
covered
or
hey.
We
met
earlier
this
week,
and
this
is
what
we
went
over
this
relevant
to
this
working
group.
H
H
F
So
I
guess
what
I
should
have
done
was
like
have
a
slide
with
the
RFC's
and
status
and
we're
moving,
but
I
think
I
want
to
throw
it
is
I.
I,
see
sure
I
mean
that's
a
that's
a
chair,
update
of
the
group
itself,
but
what
I'd
say
looking
around
the
room
of
people
who
I
don't
see
in
the
beer
room,
each
I
think
it's
time
to
start
paying
attention
from
an
ops
level.
There's
a
lot
of
pox
taking
place
out
there.
There's
a
lot
of
discussions.
F
Some
quick,
too
early
deployments
and
I
think
we're
gonna
see
a
lot
of
discussion
around
transition
mechanisms,
goodness
so
what
I'm?
Looking
for
this
type
of
draft?
That's
a
best
practices
use
cases,
things
that
are
starting
to
come
out
quite
a
bit.
So
if
nothing
more
pay
attention,
maybe
pay
attention
to
the
beer
list
itself.
Use
cases
would
be
interesting
to
take
a
look
at
and
see.
If
you
know
it's
well
representative
of
what
you're
working
on
nothing
better
but
ops
inputs
are
always.
B
F
U
P
K
P
Wondering
if
the
context
was
really
from
M
Bundy
or
from
him
earlier,
but
so
the
the
the
traceroute
stuff
is
also
question
of
the
API.
So
I
was
talking
with
genuine
and
so
in
in
the
ICMP
reply.
The
question
is
always
depending
on
us.
How
are
many
information
you
get
back?
You
always
get
the
port
number
back.