►
From YouTube: IETF-MOQ-20221021-1500
Description
MOQ meeting session at IETF
2022/10/21 1500
https://datatracker.ietf.org/meeting//proceedings/
A
Hi
folks,
thanks
everybody
for
being
here,
we
will
get
started
in
just
a
moment.
We
are
expecting
a
couple
more
people
at
the
very
least,
some
more
of
the
people
who
sent
us
inputs
like
Luke.
So
in
the
meantime,
I
will
start
the
administ
trivia
question
by
asking,
if
there's
anybody
who's
willing
to
take
notes.
A
We
really
do
need
a
note
taker
remember.
This
is
not
a
he
said.
She
said
style
note-taking,
it's
just
record
any
decisions
that
get
made.
So
in
this
case
we'll
probably
have
the
decision
on
which
style
of
GitHub
slack
yes
or
no
and
recording
which
personal,
which
technical
questions
to
tackle
and
the
incoming
personal
drafts
so
shouldn't
be
onerous
notes,
just
seven
or
eight
lines,
but
we
really
do
need
somebody
to
do
that.
A
A
A
A
Okay,
so
the
next
thing
is
to
remind
you:
this
is
our
very
first
working
group
meeting
as
the
media
over
a
quick
working
group
as
opposed
to
a
buff,
and
so
it's
a
time
to
remind
you
of
the
note.
Well,
there
are
various
ietf
ITF
policies
which
it
calls
to
your
attention,
the
set
of
BCPS
being
at
the
bottom.
A
So
you
are
in
fact
expected
to
follow
the
anti-harassment
procedures,
the
code
of
conduct
and
to
be
aware
of
both
our
copyright
and
our
patent
policies
as
part
of
the
iitf.
If
you,
if
you
have
any
questions
about
those,
please
understand
that
once
you
start
participating,
we
will
expect
you
to
follow
them.
So
you
can
be
watching
if
you're
a
little
bit
confused
or
need
to
go
talk
to
a
lawyer,
but
please
don't
contribute
unless
you
agree
to
these.
A
A
So,
as
people
remember
from
the
mailing
list,
discussion,
RFC
8874
discusses
a
couple
of
different
modes
in
which
a
working
group
can
operate,
so
some
of
them
are
issue
tracking
mode
and
another
is
issue,
discussion,
mode
and
I.
Guess
the
biggest
question
for
the
working
group
at
this
point
is:
do
we
want
to
use
it
at
all
and
presuming
that
we
do
which
of
the
modes?
Are
we
simply
storing
the
documents
there?
A
Are
we
using
the
issue
tracker
there
to
to
to
raise
issues
but
discussing
them
on
the
mailing
list,
and
or
do
we
want
to
have
some
of
the
issued
discussion
in
the
tracker?
The
difference
between
having
some
of
the
issue
discussion
in
the
tracker
and
having
it
on
the
mailing
list
is
primarily
how
early
the
mailing
list
gets
involved
in
the
decision.
Making.
The
mailing
list
is
always
the
place
where
the
current
version
of
a
document
is
approved.
A
D
The
the
one
thing
that
I
would
say
in
addition
to
what
Ted
was
saying
was
that
I'm
expecting
that
the
okay
repository
activity
for
any
of
the
repositories
that
are
involved
here
are
being
reflected
to
the
mailing
list
weekly.
So
it's
not
like
it's
not
like
the
people
in
GitHub
are
invisible,
you're,
just
not
getting
notification.
B
A
A
Okay,
that's
a
little
bit
less
discussion
on
this
than
I
was
expecting,
but
maybe
everybody
just
agreed
with
everything
that
Alan
and
sorry
that
Spencer
and
Victor
said
so.
The
the
upshot
of
what
I
hear
is
there's
nobody
who
is
advocating
for
working
without
GitHub
and
that
both
of
the
people
who
spoke
positively
were
doing
it
in
the
mode
where
issue
tracking
is
done
primarily
in
GitHub
issues.
A
A
A
An
ad
hoc
process
by
any
individual
working
group
I
think
the
working
group
that
uses
it
most
extensively
is
quick
with
a
quick,
Dev,
slack
and
I'll
point
out
there
that
the
quick
Dev
slack
has
one
serious
issue
for
some
members
of
that
working
group,
which
is
the
default
slack
client.
The
unpaid
version
of
it
only
keeps
a
certain
amount
of
History,
so
you
pretty
much
either
have
to
pay
for
it
or
be
aware
that
the
history
is
always
incomplete.
A
B
Just
we
once
again
follow
what's
a
quick
working
update,
which
is
slack
yes
for
interop
and
implementation
discussion,
but
generally
no
for
design
decisions,
and
it's
not
just
because
the
free
version
of
slack
is
not
archived,
but
even
if
it
is
Media
slack,
inherently
hard
to
search
things.
Inside
of
so.
If
we're
going
to
have
a
serious
design
discussion,
it
should
be
somewhere
that
is
trivially
searchable
and
linkable.
C
So
there's
many
ways
we
could
solve
this,
but
I
don't
think
we
should
have
I
mean
I'm
all
for
using
slack
or
a
tool.
I,
don't
really
like
slack,
but
some
tool
like
that,
like
that,
would
be
fine
I
think
we
should
use
a
tool
like
that.
However,
I
don't
think
we
should
use
any
tool
where
a
hundred
percent
of
it
does
not
end
up
in
a
long-term,
publicly
searchable
archive
that
ITF
can
use,
because
that's
critical
for
our
legal
process
I
strongly
object
to
things
other
than
that.
C
So
that
might
happen
just
due
to
you
know
being
mirrored
onto
an
email
list
or
something
like
that.
Like
the
same
way
we
do
with
the
PRS
or
with
the
the
get
the
GitHub
stuff,
but
I
think
one
way
or
another.
There
needs
to
be
a
long-term
public
Archive
of
this
stuff,
because
it
turns
out
to
be
really
important
later
when
there's
a
patent
argument
and
somebody
patents,
something
that
the
working
group
did
and
the
working
group
wants
to
show.
C
A
D
Thank
you
before
I
start
talking,
so
I
asked
this
I.
Think
I
was
the
one
that
asked
this
question
and
I
agree
with
what's
been
said
so
far,
the
the
one
thing
that
I
would
add
at
this
point
is
I'm
having
the
impression
that
we're
planning
to
do
with
more
with
zulup
in
the
future
than
we
are
with
slack
as
an
ITF,
so
we
might
just
want
to
keep
an
eye
on
whether
that's
a
better
answer
than
slack
as
a
the
free
version
of
slack
as
it's
used
today.
A
C
E
To
kind
of
qualify
that
question
saying:
can
we
use
slack
for
like
what
Victor
said
interrupt
and
implementation
like
clarification
discussions,
but
not
design
discussions
and
outcome
for
of
the
working
group
decides
what
to
do
next,
it's
very
easy
to
kind
of
get
into
a
mode
where,
as
part
of
the
discussion,
we
are
all
enthusiastic
and
we'll
start
this
design
discussions
there.
We
need
to
somehow
make
sure
that
it's
some
reflector
or
you
know
archived
so
that
you
can
be
searchable
at
some
point.
A
F
Okay,
yeah,
so
chair,
hop
off
for
a
second
I,
just
want
to
say
that
I.
Second,
a
lot
of
the
comments
about
having
for
interop
and
the
sort
of
like
technical,
real-time
discussion
for
quick
and
other
groups
has
been
super
useful,
so
I
think
having
a
channel
like
that
is
important.
I
also
want
to
just
bring
to
folks
attention
that
inside
the
quick
Dev
slack,
there
is
an
moq
Channel.
Now,
where
there
is
some
coordination
happening
between
the
authors
of
individual
drafts
there.
F
D
F
D
D
A
A
I
also
heard
pretty
strongly
concerns
about
the
The
Disappearing
nature
of
slack
in
particular,
I
I
believe
that
Cullen
Ali
and
myself
all
mentioned
that
so
I
believe
that
possibly
we're
not
looking
at
slack
itself.
So
what
I
propose
to
do
here
is
to
say
look
if
a
design
team
wants
to
use
a
channel,
then
it's
not
formally
part
of
the
working
group,
that's
cool!
A
So
I
think
what
that
means
is
the
the
slack
answer.
Isn't
yes,
or
no
so
much
as
it
is
not
right
now
and
we'll
work
on
seeing
if
we
can
find
one
that
meets
the
archival
properties
relatively
quickly,
but
that
the
understanding
is
even
when
it's
in
place
it's
for
informal
Communications,
but
those
informal
Communications
would
be
retained.
C
Just
like
saying
we're
going
to
confirm
it
on
the
list,
but
I
I
think
that
actually
we
need
to
be
sort
of
realistic
that
design
decisions
will
happen
on
this
stuff.
You
know
I'm
not
trying
to
change
people's
take
on
that
I'm.
Just
noting
that
it
happens
and
that
we
should
keep
that
in
mind,
When
selecting
a
tool.
A
F
Those
would
always
be
reflected
then
into
issues
in
GitHub,
with
discussion
happening
there
afterwards
and
I,
don't
think
by
any
means
that,
like
slack,
became
the
last
word
so
I
sort
of
expect
that
the
same
process
and
as
Spencer
would
say,
people
will
do
the
right
thing
here,
but
I'm
not
arguing
against
that.
You
know
having
a
long-term,
archival
and
searchable
history
isn't
is
also
important,
so
foreign.
A
D
A
Sure
Cullen
said
that
he
was
concerned
about
us
saying
that
we
would
look
I
either
how
to
take
things
out
of
slack
so
that
they
were
archived
or
we
would
look
in
zulip
since
it
seems
to
be
the
ITF
replacement
for
chapper,
and
his
comment
was
that
he
he
felt
it
would
be
wise
for
us
to
kind
of
pull
the
room
on
usage
of
zulip
because
he
felt
like
he
did
not
currently
himself
use
it
and
wasn't
particularly
keen
on
doing
so.
So
I
think
that's
a
a
question
here.
A
He
mentioned
Discord
as
well
as
another
option,
so
we
can
go
and
look
and
say
we
could
go
and
set
up
a
Discord
for
this.
It
has
the
same
sort
of
Disappearing
properties
for
some
people,
but
we
have
to
be
a
little
bit
aware
of
of
the
setup
of
too
many
tools
if,
if
people
are
using
slack
for
quick
and
Discord
for
Mock
and
zulip
for
HTTP
Biz
we're
we're
kind
of
all
over
the
map
there
and
that's
a
bit
hard
to
track.
D
Okay,
yeah,
okay,
so
the
prize
working
groups
can
do
the
right
thing
also.
So
whatever
the
right
thing
to
do
is
the
the
one
the
one
suggestion
I
would
make
about,
that
is
I,
don't
have
a
huge
amount
of
experience
with
Sula
I've,
mostly
used
it
during
medeco
meetings,
which
you
know
what
we
haven't
had
many
of
and
a
couple
of
months.
D
So
also
you
know
that
that
might
be
an
invitation
for
people
to
go.
Take
a
look
at
Google
up
and
see
what
the
what
they
think
about
that.
Also
a
reasonable
thing
to
do
would
be
to
ask
the
tools
team
if
our
understanding
of
the
Direction
with
zulup
matches
their
understanding
all
right.
If
I
remember
correctly,
we
had
a
test
with
zulub
and
some
other
similar
mechanism
that
they
they
pick
zulup
over
the
other
mechanism.
D
A
Okay,
I
I
believe
that
the
Tulip
is
the
direction
we
can
confirm
that
it
hasn't
been
changed
and
I'll
take
the
action
item
to
do
that.
In
the
meantime,
may
I
ask
somebody
to
take
the
action
item
to
see
if
they
can
find
a
mechanism
that
would
allow
us
to
create
a
digest
or
digested
archive
of
a
slack
Channel,
and
if,
if
we
can
identify
one
of
those,
then
the
major
objection
to
using
slack,
which
is
that
it's
a
disappearing
medium
for
the
free
client
would
go
away.
A
A
A
A
F
D
A
A
D
D
So
the
working
group
is
chartered
to
adopt
a
use
cases,
a
requirements
document.
The
draft
we've
been
working
on
is
a
potential
candidate,
James
and
I.
Think
he
was
draft,
would
be
a
useful
starting
place
for
Bach,
but
recognizing
that
the
author's
pre-both
opinions
or
what's
in
the
draft
now
not
what's
in
the
approved
Charter.
D
D
So
we
think
so
we
had
started
on
use
cases.
We
thought
that
use
cases
would
drive
requirements
which
would
require
drive
work
on
protocols.
The
charter
includes,
but
is
not
limited
to
these
use
cases
quoting
live
streaming.
Gaming
and
media
conferencing
section
for
the
individual
draft
describes
these
three
use
cases,
and
so
we
had
three
questions
that
we
were
hoping
to
get
guidance
from.
D
D
D
Let
me
say
a
lot
of
the
work
on
this
was
done
before
the
the
trash
was
done
before
the
first,
not
not
a
working
group
forming
buff
on
Mock,
and
so
anybody
who's
been
paying
attention
since
then
may
not
be
familiar
with
the
draft
and
I
don't
know
how
much
time
people
have
spent
looking
at
the
slides
before
the
meeting
so
I
can
def.
I
can
definitely
ask
these
questions
on
the
mailing
list.
D
B
And
and
the
example
that
that
has
been
cited
on
quite
a
few
occasions,
is
the
the
Staff
All
Hands
meeting,
where
there
may
be
hundreds
or
even
thousands
of
viewers,
but
only
a
small
number
of
active
people
being
interactive,
both
producing
sending
media
as
well
as
receiving.
And
it's.
Whereas
you
know
it's
the
vast
majority
of
purely
just
receiving
and
consuming.
D
E
Thank
you,
Spencer
for
bringing
this
I
think
some
of
the
discussions
with
the
unified
work
that
we're
also
trying
to
do
has
this
aspect
of
how
do
we?
Let
viewers
like
Luke,
would
also
talk
talking
about
it
more,
but
it's
more
about
how
do
we,
let
users
say
the
con
or
viewers
say
the
latency
they
would
expect
and
and
having
the
the
delivery
protocol
meet.
E
D
Discussion
that
would
happen
after
you
know
we're
moving
forward
with
this
draft
of
the.
If
it's
okay,
if
the
working
group
moves
forward
with
it,
is
making
sure
that
we
have
enough
descriptive
material
in
the
use
case
section
to
explain
why
we
have
certain
requirements-
and
you
know,
as
as
suhas
was
just
was
saying,
there's
certain
require.
You
know
certain
use
cases
with.
That
would
say
this
is
you
know,
because
we
support
this
aspect
of
this
kind
of
use
case.
This
is
why
this
is
a
requirement.
D
D
D
D
We
asked
anybody
for
an
option
of
this
draft
by
the
working
group
and
in
proposing
an
initial
structure
of
the
requirements
section
based
on
implicit
requirements
that
are
in
the
approved
Charter
and
at
this
point,
if,
if
this
rolls
the
way
I
was
thinking
it
might,
the
working
group
would
be
controlling
both
the
use
cases
and
requirements
for
for
mock.
At
that
point,
any
comment,
comments
or
questions
on
this
Cullen.
C
C
If
there's
Parts,
you
know
delete
as
much
like
there's
a
lot
of
history
in
there,
let's,
let's
like
yeah
intense
it,
make
it
easy
for
everyone
to
read,
but
also,
if
there's
stuff,
that's
just
not
agreed
upon
on
the
working
group,
but
there's
a
range
of
opinions.
We
can
express
that
and
then
adopt
it
as
a
working
group
document
with
the
issue
not
resolved
but
an
issue.
You
know
we
have
a
range
of
options
we
could
go
here.
There
isn't
yet
working
group
agreement.
C
D
Guys,
yeah
yeah
yeah,
so
so
I
I
think
that
I
think
that's
I
think
that
there
are
things
in
the
draft
that
are
not
in
scope,
but
I've
not
done
a
quick
I've,
not
done
the
past
in
the
last
20
minutes
for
what
what's
in
there.
That
is
not
agreed
upon
yeah
that
obviously
agreed
upon,
but
that
is-
and
you
know
that
the
answers
would
be
in
scope
so
that
that
that
helps
me.
You
know
that's
a
very
helpful
comment
to
me:
Colin.
Thank
you.
D
E
B
D
Yeah
and
and
James
James
says
for
about
what
James
said
is
reminding
me
my
interest
at
least
my
understanding
of
what
it
means
to
adopt.
This
is
that
the
working
group
thinks
that
this
is
a
document
that
is
a
reasonable
basis
for
working
group
work,
so
any
other
any
other
comments.
I'm
gonna,
I'm
gonna
have
a
question
for
the
chairs
and
and
the
working
group,
of
course,.
A
D
Yeah
I
I
was
not
really
thinking
about
when
we
did
when
we
did
the
when
we
did
the
first
version
of
the
slides
for
this.
For
this
talk,
I
was
not
really
thinking
about
adoption
now
and
you
know,
as
the
slides
reflect
but
I'm
wondering
you
know.
If,
if
you
know
Cullen
said
you
know,
he'd
be
okay
with
adopting
it
now,
with
this
work
plan
as
part
of
that
and
would
other
people
would
other
people
be
okay
with
that,
so.
A
With
chair
hat
on
since
that
wasn't
one
of
the
decisions
we
announced
would
be
part
of
the
the
interim
I
I
would
prefer
not
to
do
that
at
this
interim?
If
you
guys
produce
the
document
with
the
revisions,
we
can
take
that
up
in
London
in
London
for
itf-115,
but
I'm
I'm
a
little
bit
uncomfortable
with
doing
it
at
this.
This
interim,
we
could
do
it
on
the
list
as
well.
Yeah.
A
A
C
C
It's
not
working
group
consensus
for
the
parts
that
aren't
in
the
dock
before
we
adopt
it
for
for
working
group
consensus,
but
I
felt
bad
for
you
presenting
and
getting
zero
feedback,
and
it's
like
do
people
love
this
I
think
you're
on
the
right
track.
Please
do
the
work!
Thank
you
like
that's.
What
I
was
really
trying
to
say.
D
And,
and-
and
thank
and
thank
you
for
thank
you
for
clarifying
as
well
so
like
I,
said
what
you
just
said
is
kind
of
what
I
was
thinking.
We
were
going
to
be
doing
between
now
and
London,
I
think
so.
The
the
ID
cutoff
is
like
Monday
right
yeah,
so
so
it
is
not
super
likely
that
we
would
that
we
would
produce
and
submit
a
draft
by
Monday.
D
D
A
E
Okay,
I
can
hear.
Can
everyone
hear
me
yes
or
not?
Okay,
great,
so
the
the
main
idea
behind
this
slide
deck
is
not
going
deep
into.
How
do
we
solve
each
of
the
things
that's
been
listed
in
the
slide,
but
basically
looking
at
the
charter
and
Distilling
it
one
level
down
to
see
what
kind
of
questions
that
we
would
like
to
answer.
It
might
turn
into
requirements
that
would
help
like
Spencers
on
James
document,
or
it
might
turn
into
a
task
list
that
the
working
group
would
want
to
follow.
E
So
keeping
that
context
in
the
mind
I'll
jump
to
the
next
slide.
Please,
okay,
topics
that
will
will
be
talking
about
here,
which
is
basically
rocked
from
the
charter.
We
need
to
work
on
a
common
published
protocol
between
ingest
and
distribution,
and
we
need
a
way
to
name
or
address
things
whatever
we
call
it
as
to
identify
things
and
so
that
we
can
request
them
appropriately
and
also
we
need
a
way
to
kind
of
package.
This
media
we
have
different
formats
there
like.
E
E
Published
protocol
required
it
needs
to
be
common
between
the
contribution
and
distribution
side
of
the
picture,
and
we
need
a
way
to
support
to
specify
different
kinds
of
media
types
like
it's
an
ad
audio,
video
or
subtitles,
or
it's
an
ad
or
something
and
also
different
qualities.
So
those
media
types
correspond
to
and
also
different
codecs.
Those
are
some
of
the
things.
At
least,
we
need
to
be
able
to
kind
of
specify
as
part
of
the
protocol
and
on
the
things
that's
being
published,
and
these
things
need
to
be
added.
E
We
need
to
be
able
to
identify
them,
uniquely
so
that
on
the
consumer
side,
you
should
be
able
to
kind
of
retrieve
that,
and
also
when
you're
publishing
the
media
can
be
published
at
various
granularity.
For
example,
if
you
take
about
the
Via
to
talk
about
the
video,
a
video
can
be
published
as
individual
individual
frames
that
comes
out
of
the
encoded
encoder
or
it
could
be
group
of
frames
like
the
group
of
pictures
that
we
usually
to
see
in
the
video
encoding
or
something
different.
E
We
need
to
kind
of,
say,
group
decide
on
on.
What's
the
right
way
to
go
about
it,
and
some
of
these
things
will
also
be
addressed
when
Luke
presents
about
unified
draft,
but
here
I'm
putting
it
here
so
that
we
need
to
address
this
technical
detail
next
slide,
please,
and
once
once
the
media
has
been
published
under
the
transport
in
order
to
make
a
relay
the
first
class
citizens
in
the
architecture.
E
E
Helping
this
kind
of
relays
or
the
middle
boxes
make
decisions
without
having
to
look
into
the
actual
media
payload,
which
will
be
encrypted
and
also
which
the
protocol
should
enable
to
configure
to
support
various
use
cases
that
James
just
meant
mentioned
about
live
streaming
or
interactive,
media
or
media
conferencing.
We
need
to
be
able
to
kind
of
specify
that,
in
the
protocol
and
and
whatever
we
send
should
be
able
to
map
on
the
quick
stream
or
quick
streams
or
quick,
datagrams
or
datagrams
is
something
we
are
for.
E
E
E
Given
we
are
working
in
the
web
model
with
cdns
and
kind
of
relays,
and
also
the
origin
in
the
picture.
We
need
to
make
sure
that
water
being
published
is
in
the
scope
of
an
application
domain
or
the
origin,
and
that
would
that
basically
means
that
a
somehow
it's
tied
to
a
billing
relationship
that
happens
with
a
company,
that's
kind
of
actually
producing
the
media.
It
might
not
be
a
direct
goal
of
this
protocol,
but
this
architecture
works
that
way.
E
We
need
to
kind
of
keep
that
in
mind
and
the
naming.
What
naming
basically
does
is
identifies
these
Elemental
streams
or
the
variations
of
those
things.
So
that
way,
it's
it's
very
easy
for
the
consumer
to
kind
of
request,
the
right,
quality
or,
or
or
or
the
consumer,
to
kind
of,
or
or
consumers
kind
of
pick
between
different
qualities,
all
right
and
for
the
final
scenario,
scenarios
from
the
CDN
and
to
multiple
subscribers.
We
are
talking
about
like
millions
or
like
hundreds
of
thousands
of
subscribers.
E
E
Next
slide,
please
on
packaging
media,
while
we're
transporting
there
are
multiple
options
that
we
want
to
package
media,
some
of
the
contenders
that
we
have,
or
some
of
the
options
that
we
can
the
can.
They
coexist
or
something
like
using
existing
container
format
like
cmaf
and
also
supporting
Rock
container
format.
E
E
And
on
also
on
on
the
requirements
of
what
a
relational
caches
should
do,
the
the
basic
functionality
is
to
kind
of
they
should
allow
caching
and
distribution
of
the
media
data
as
applicable,
and
also
they.
They
basically
store
data
based
on
the
trust.
That's
been
set
up
by
the
origin.
Again
this
course
without
saying
that,
and
also
like,
like
how
the
publisher
and
consumer
kind
of
work
on
quick
streams
or
quick,
datagrams
or
or
whatever
we
come
beside,
the
protocol
should
be.
E
E
But
these
are
some
of
the
things
we
need
to
explore
as
we
design
the
protocol
and
relay
should
be
able
to
kind
of
make
their
cash
or
drop
decisions
just
based
on
the
metadata
and
nothing
and
and
not
being
able
to
access
the
actual
payload.
The
mock,
payload
and
I
really
should
be
able
to
kind
of
push
the
data
based
on
the
consumers
asking
for
the
data
push
the
data
whenever
it's
available
to
fan
out
to
the
any
number
of
consumers.
E
Something
like
that.
We
we
need
to
kind
of
talk
about
that
as
well.
I,
think
that
should
be
all
this.
This
kind
of
a
laundry
list
of
things
that
we
might
might
want
to
do
and
I
would
like
to
kind
of
encourage
working
group
to
kind
of
think.
Through
these
questions,
either
we
create
a
list
somewhere
where
we
can
go,
discuss
further
and
kind
of
see.
How
can
we
build
our
solution?
That
kind
of
fits
the
requirements
that
we
have.
F
Thank
you
has
so
I,
just
so
a
few
minutes
to
discuss
here
and
I
think
the
what
might
be
interesting
is
to
try
to
surface
the
topics
that
we
think
we
could
put
on
an
agenda
in
London
to
have
like
a
deeper
discussion.
There's
obviously
a
lot
of
topics
that
we
have
to
cover
in
this
working
group
over
time,
but
think
about
what
are
the
first
ones
that
we
want
to
really
dig
into.
That
will
maybe
have
more
Downstream
implications.
D
So
one
of
the
so
one
of
the
things
I
was
going
to
suggest
that
we
focus
on
early
is
getting
a
clear
specification
of
what
we
think
a
protocol
stack
looks
like
this
was
discussion
that
was
happening
in
the
email
thread
that
Luke
started,
and
there
were,
you
know,
there's
at
least
three
different
variations
that
I
can
think
of
that
people
seem
to
have
had
in
their
heads
when
they
were.
You
know
when
we
were.
D
D
E
But
but
thanks
Spencer
valid
points,
I
I,
I,
I
think
having
having
a
GitHub
Wiki
where,
but
because
most
of
the
things
I've
listed
down
kind
of
is
a
digital
down
version
of
what's
in
Charter,
some
might
be
my
personal
opinions,
which,
which
is
definitely
open
to
change
having
this
as
a
backlog,
or
something
would
definitely
help
doing
that
and
I
also
agree
with
Alan.
What
Helen
said
is
that,
yes,
we
have
Charter
says
we
have
to
do
15
things.
E
D
F
D
Whatever
the
right
document
is,
and
it
may
be,
the
protocol
document
you
can,
you
can
replace,
you
can
create
the
repo
for
it
now
and
then
we
can
be
putting
these
in
as
issues
and
using
labels
on
you
know.
This
is
for
ITF
115.
This
is,
for
you
know
it.
You
know
this
is
for
later
kinds
of
things
to
to
manage
the.
So
we
don't
have
so
we
don't
start
out
with
500
issues,
but
just
just
to
just
to
give
us
a
place
to
get
started
and
get
organized.
E
I
know
if
I,
if
I
may
suggest
like
since,
since
one
of
the
first
deliverables
we
have
on
along
with
use
case
document,
is
the
the
common
media
publication
protocol.
If,
if
you
take
that
as
the
the
category
that
we
want
to
kind
of
solve,
first
and
and
and
some
of
these
things
will
move
out
or
move
out
automatically
from
from
from.
E
If
you
take
that
as
a
goal,
maybe
when
you
create
a
Wiki
or
somewhere,
we
basically
go
by
by
that
categorization
saying
that
we
start
with
common
media
protocol
media
publication
protocol,
and
for
that
these
are
some
things
we
have.
We
we
might
want
to
see
if
you
can
address
this,
these
technical
questions
for
those
things,
maybe
that
might
be
the
first
start.
F
Okay,
I
saw
a
comment
from
Luke
in
the
in
the
chat
about
prioritization,
but
also
referencing,
his
upcoming
slides,
so
I,
don't
know
if
Luke
you
want
to
jump
in
and
Echo
that
the
room
or,
if
other
folks
have
different
opinions
like
I,
think
what
sue
us
just
said
about
well
I.
Think
writing.
The
common
publication
protocol
is
like
the
higher
like
one
of
the
highest
priorities,
so
we
should
take
that
and
then
work
on
subtopics
from
there.
First.
H
H
Yeah,
the
most
important
part
of
a
media
transport,
or
just
a
network
transport
in
general,
is
making
sure
the
data
gets
there
correctly.
So
I
mean
it.
It's
really
tempting
to
start
like
nitpicking
like
how
do
we
support
DRM,
but
at
the
same
time
it's
like
how
do
we
make
sure
that
media
gets
from
point
A
to
point
B
in
reliable
fashion
such
as
it
can
be
decoded
and
there's
a
few.
B
I
just
wanted
to
agree
with
Luke
that
packaging
of
the
media,
I
think,
is
the
most
important
thing
to
tackle.
First,
because
I
think
that
quickly
shows
the
differences
that
people
are
assuming
and
it's
it's
critical
for
the
transport
of
the
media
to
understand
the
the
protocol
boundaries
of
fragments.
B
F
B
F
E
F
F
F
A
I
was
just
going
to
say,
Ellen
I
think
our
next
topic
is
actually
polling
to
see
who's
going
to
be
presenting
drafts
between
now
and
and
London.
Obviously,
the
draft
deadline
is
Monday.
So
if,
if
you
haven't
got
your
fingers
to
the
keyboard,
get
them
on
now,
I
know
we're
expecting
something
from
Spencer
and
James
I
believe
we're
expecting
something
from
Luke.
Are
we
expecting
any
others?
Is
the
next
big
question.
A
B
G
Yeah
I
I
just
submit
a
dropped.
His
name
is
a
design
Choice.
The
design
is
based
on
analysis
of
the
moq
and
all
the
the
Renee
is
kind
of
the
first
first
class
citizen
of
the
mop.
But
there
are
a
lot
of
things
about.
The
Renee
is
not
very
clear.
For
example,
how
do
you
organize
the
RNA?
How
do
you
choose
the
stream
from
producer
to
Consumer
which
Renaissance
rule
if
it's
like?
The
city
is
like
a
tree
tree
topology,
but
we
have
other
choice.
G
For
example,
we
can
do
some
kind
of
overly
routing
between
between
the
renes
and
there
are
other.
There
are
other
things,
such
as
the
that
the
media
is
and
to
end
encrypted
and
the
Renee
cannot
access
a
media
or
or
Renee
can
decode
can
decrease.
The
queer
connection
I
think
I
think
the
drop
is
just
just
analysis,
so
I
would
like
to
discuss
with
people
yeah.
A
B
Yeah
hi
yeah,
my
co-author
and
I,
think
presents
an
approach
of
estimating
some
metrics
of
live
streaming,
like
Twitter
latency
on
some
packet
loss
and
related
metrics.
So
as
usual,
we
do
it
almost
the
last
date
or
tomorrow.
We
are
thinking
to
publish
it,
but
we
would
like
also
to
request
some
time
to
share
the
you
and
here,
what's
the
group
things
on
it,.
A
So
so
Maxima
I
think
that's
background
information
at
a
sufficiently
deep
level.
That
is
probably
best
if
you
send
that
to
the
working
group
mailing
list.
We're
gonna
have
a
pretty
tight
agenda
in
in
London
and
it
sounds
like
that
sort
of
Jitter
having
not
not
read.
The
draft,
of
course,
might
be
a
more
generic
interest
than
specific
to
the
design
space
from
moq.
So
if
you
could
send
it
to
the
mailing
list
now
we
can
take
a
look
at
it
as
as
a
group
and
and
go
from
there.
A
A
G
No
that's
yeah
yeah,
we
tried
thank
you.
So,
yes,
we
we
plan
to
propose
to
publish
a
draft,
maybe
today
that's
on
on
the
type
of
relay
that
you
would
have
at
the
Ingress
point
of
g-networks
and
and
other
wireless
networks,
and
that
would
need
to
deal
with
the
congestion
and
you
know,
energy
saving
techniques.
So
then
we
need
certain
type
of
metadata.
G
So
I
think
this
can
contribute
to
the
discussion,
like
maybe
in
terms
of
of
use
case,
to
know
if
this,
this
type
of
use
case
would
be
suitable
and
also
potentially
in
terms
of
metadata.
And
you
know
what
time
of
you
know
what
time
of
what
type
of
data
data
and
where
this
meta
that
I
would
be
needed
in
the
in
the
flow.
A
A
H
You
go.
Thank
you
so
I
know
this
interim's
not
meant
to
be
too
technical.
So
this
is,
you
know
not
going
to
be
too
much
of
a
discussion.
This
is
going
to
really
be
covering
a
little
bit
of
the
background
of
the
previous
drafts,
even
before
the
working
group
was
formed
and
just
a
little
bit
of
progress
on
how
we're
trying
to
combine
them
come
on,
go
for
it.
So
the
number
one
goal
I
think-
and
this
really
relates
to
the
last
slides
that
suhas
have
I
think.
H
C
H
So
the
first
thing
we
need
to
really
cover-
and
this
is
one
thing
that
it
would
be
nice
to
have
in
maybe
even
a
requirements.
Draft
I,
don't
know
this
is
like
a
background
of
media
is
how
is
Media
even
encoded?
What
are
we
dealing
with
here?
What
are
we
trying
to
put
over
the
network
so
at
the
top
I
have
a
very
simple.
This
is
what
webrtc
typically
does
or
like
really
simple,
encoders
or
even
iframe,
effectively
a
static
image
and
then
P
frames
will
reference.
H
H
H
So
one
way
of
doing
this-
and
this
is
what
meta
has
been
doing
for
a
while
now-
is
to
use
a
quick
stream
for
frame,
and
the
idea
is
there's
kind
of
this
implicit
dependency
that
this
stream
depends
on
this
stream.
So
you
should
deliver
them
in
order
during
congestion,
and
if
a
stream
is
taking
too
long
and
it's
not
high
priority,
you
can
send
a
reset
stream
frame
to
effectively
drop
it
during
congestion.
H
H
H
And
the
the
third
notable
draft
that
we're
trying
to
combine
is
a
quick
R.
It's
a
concept
of
it's
far
more
complicated
than
this.
By
the
way,
it's
a
effectively
a
pub
sub
network
with
the
important
distinction
that
there's
a
header
in
the
front
of
each
stream
that
informs
a
relay
on
how
it
should
that
that
stream
should
be
delivered,
such
as
identification,
prioritization,
timestamp.
H
H
So
my
goal
is
being
to
try
and
combine
the
parts
of
the
draft
that
all
agree
with
each
other
to
try
and
find
a
single
approach
that
can
do
either
Style
at
least
either
rush
or
warp
style
of
delivery,
and
this
I'll
have
this
ready
by
Monday
I'll
at
least
have
a
draft
published,
but
just
a
little
teaser.
The
idea
is
that
you
can
have
a
stream
for
any
number
of
frames
is
effectively
the
compromise.
H
So
you
can,
you
can
do
Rush
where
you
can
have
a
stream
per
frame,
and
you
can
do
warp
when
you
can
have
multiple
frames
per
stream
and
then
there's
a
middle
ground
where
you
can
just
pick
and
choose
whatever
frames
are
on
the
stream.
The
important
caveat,
though,
is
that
there
is
a
header
within
each
stream
that
says
that
this
stream
depends
on
the
stream
or
like
some
information
for
both
relays
and
also
to
know
what
streams
should
be
delivered
in
what
order
to
best
respond
to
congestion.
H
Next
slide
so
yeah,
like
I,
said
London
draft
I'd
love
to
talk
more
about
the
technical
details,
I,
don't
wanna
I,
don't
have
the
time
to
to
talk
too
much
of
this
interim
and
the
big
thing
I
really
want
to
plant
in
people's
head
is
kind
of
alluding
to
what
I
think
a
sort
of
chat
just
earlier
is
how
will
CDN
support
this
in
general?
I?
Think
that's
an
ongoing!
That's
just
something!
I
I
just
want
people
to
start
thinking
about
it.
H
Do
you
want
a
pub
sub
model
or
are
we?
Is
there
some
way
we
can
map
these
streams
to
a
traditional,
pull-based,
CDN
yeah
and
that's
not
yeah
I.
Think
that's.
Probably
one
of
the
next
bigger
things
to
to
identify
is,
if
you're,
trying
to
combine
all
the
use
cases
in
one
protocol
next
slide
and
yeah.
A
lot
of
people
have
helped
with
this
draft.
H
A
Very
much
and
just
for
the
folks
here,
I
think
we.
We
are
counting
this
as
a
preview
of
London.
Rather
than
opening
this
for
discussion
today,
we
only
have
like
six
minutes
left,
so
definitely
not
enough
time
to
dive
into
the
details
there.
So
here
it
looks
like
you're
in
queue.
Is
it
to
dive
into
the
details,
because
if
so
I'm
going
to
ask
you
to
hold
your
water
until
the
draft's
out
and
then
take
to
the
list.
D
A
That
is
very
encouraging
and
we
really
appreciate
the
work
on
that.
I
will
encourage
you,
as
you
put
the
draft
together
to
think
about
what
folks
you
need
to
reach
out
to
whether
they
be
other
folks
who
do
similar
things
like
the
Youtube
crew
or
the
CDN
folks,
or
any
of
our
video
Codec
Posse
here
at
the
ITF,
because
we
may
want
to
get
early
review
from
quite
a
variety
of
people
if
this
is
going
to
be
kind
of
the
the
basis
of
ongoing
work
here.
A
B
A
H
A
That
would
definitely
be
great,
so
I
think
that
brings
us
to
the
end
of
our
agenda.
I
want
to
thank
the
note
takers,
especially
I,
really
appreciate
it
for
work
they
put
into
to
grab
some
notes
for
us.
Is
there
anything
else
we
need
to
cover
today
before
we
adjourn
and
start
getting
everybody
ready
for
their
final
run
at
drafts
for
London.