►
From YouTube: IETF114-MOQ-20220727-1400
Description
MOQ meeting session at IETF114
2022/07/27 1400
https://datatracker.ietf.org/meeting/114/proceedings/
C
C
Okay,
folks,
let's
get
started
for
those
of
you
who
haven't
seen
gritty
before
the
delightful
figure
in
front
of
you
is
the
mascot
of
the
philadelphia
flyers
and
a
beloved
figure
there
in
philadelphia.
I
regret
that
I'm
not
able
to
join
you
myself.
Unfortunately,
I
managed
to
blow
out
my
back
right
before
getting
on
the
plane
and
the
combination
didn't
seem
like
a
good
one.
B
C
Somebody
noted
in
the
chat
that
it
appears
they're
getting
a
little
bit
of
distortion
from
my
mic.
I've
moved
it
a
little
bit
further
away.
Hopefully
that
helps.
This
is
the
note.
Well,
since
we're
wednesday
of
the
week.
You've
probably
seen
it
before,
but
just
as
a
reminder,
please
note
that
you
are
responsible
for
maintaining
your
conduct.
According
to
each
of
the
bcps
you
see
listed
below.
C
C
The
second
thing
to
remind
you
is
that,
because
this
is
a
buff,
there
will
be
a
set
of
buff
questions.
You'll
see
a
preview
in
just
a
moment.
That
means
that
we
will
be
using
the
question
tool.
That's
part
of
the
the
system,
the
show
of
hands
tool
if
you're
on
the
the
desktop
system.
It's
between
the
bell
and
the
file
folder
looks
like
a
little
chart.
C
C
Seeing
none
here
is
a
preview
of
the
buff
question,
so
these
are
the
questions
that
we'll
be
asking
the
community
after
we've
gone
through
the
charter.
So
each
of
you
please,
as
you're
considering
the
charter
or
changes
you'd
like
to
see
in
it
or
discussion
about
it,
make
sure
that
you
keep
in
mind
these
questions.
Does
the
community
think
that
the
problem
statement
is
clear,
well
scoped,
solvable
and
useful?
C
C
So
the
first
part
of
the
chart
reads:
media
over
quick
will
develop
a
simple
low,
latency
media
delivery,
solution
for
ingest
and
distribution.
This
solution
may
address
use
cases,
including
live
streaming
gaming
and
media
conferencing
and
will
scale
efficiently.
The
solution
will
support
both
web
browsers
and
non-browser
endpoints.
C
C
Media
will
be
mapped
onto
underlying
quick
mechanisms,
quick
streams
and
or
quick
datagrams
and
can
be
used
over
raw,
quick
or
web
transport.
The
proposed
solution
will
provide
extensibility
for
supporting
different
media
formats
and
shall
specify
a
mandatory
to
implement
media
format
to
ensure
interoperability.
C
Support
for
multiple
media
types
and
media
encodings
shall
be
proposed.
The
solution
will
specify
a
simple
method
of
authentication
to
access
media,
as
well
as
a
mechanism
for
carrying
information
enabling
additional
decryption
of
media
payloads.
Where
required,
the
working
group
will
define
moq
such
that
the
media
publication
protocol
can
leverage
coordinating
relays,
caches
or
replication
points
wherever
applicable,
to
improve
the
delivery
performance
media
will
be
encrypted,
possibly
end
and
encrypted
for
certain
use
cases.
C
C
This
working
group
will
not
propose
changes
to
the
underlying
quick
transport,
but
may
propose
requirements
for
quick
extensions
to
the
quick
working
group.
This
working
group
will
not
define
signaling
mechanisms
for
discovery
of
relay
or
media
producers
or
consumers.
This
working
group
will
coordinate
with
a
quick
and
web
transport
working
groups
as
needed.
It
will
liaise
with
mpeg-dash
forum
and
the
w3c
web
transport
as
appropriate.
C
D
C
So
there's
a
little
bit
of
discussion
on
the
list
and
the
reason
that
it's
worded
this
way
at
the
moment
is
because
it's
may
address
use
places,
including,
and
so
the
including
may
there
may
also
be
use
cases
which
are
not
included,
so
it's
not
more
definite
than
that.
So
if
we
want
to
make
it
more
different,
we
could
update
this
to
say
I
may
address
use
cases
which
shall
include
at
least
and
then
include
these
and
then
leave
open.
What
what
else
is
included?
Would
you
prefer
that
wording.
D
B
E
E
Okay,
is
this
better,
oh,
so
the
regarding
on
the
second
slide,
there
is
a
part
where
we
say
request:
encode
media
form
as
an
encoding,
but
request
is
a
pull
operation
which
is
probably
more
complicated
than
something
we
want
in
a
baseline
push
protocol
because
often
for
push
cases.
I
just
have
one
format
and
I
want
to
peer
know
what
that
format
is,
but
I
might
not
necessarily
want
to
request
or
negotiate
it.
C
F
C
Push
is
making
some
implications
for
you
and
I
guess,
as
the
other
folks
come
to
the
mic
line,
please
consider
whether
there's
a
different
phrase
than
push
that
captures.
What
you
believe
that
protocol
is
likely
to
do,
because
I
I
do
agree
that
there
are
some
aspects
of
what's
described
here
that
are
not
purely
push
protocol,
but
I
think
are
intended
to.
E
B
H
Colin
colin
johnson,
cisco,
the
I
think
when
we
talk
about
the
the
push
like
one
of
the
use
cases
like
on
the
ingest,
you
might
only
have
one
thing
to
push,
but
on
the
distribution
sort
of
approach,
like
one
of
our
very
one
of
our
key
use
cases,
is
be
able
to
request
bit
streams
at
different.
You
know
bit
rates
effectively
at
some
level
right,
that's
a
key
fundamental
part
of
this
stuff.
H
So
I
think
the
fact
that
though
it
is
a
push
protocol
does
not
mean
there's
no
information
flowing
in
the
opposite
direction,
telling
something
what
to
push.
So
I
think
we
just
need
to
phrase
this
in
a
way
of
you
know,
there's
some
information,
you
know
you,
you
could
say
what
you
want,
pushed
in
some
sort
of
way
right
and
we've
sort
of
described
in
the
outline
here.
So
I
just
I,
I
don't
think
people
can
take
push
protocol
to
mean
that
information
only
goes
one
direction.
H
It's
not
like
our
congestion,
our
security,
nothing
would
work
with
that.
It's
it.
It
is,
there's
a
certain
information
you
can
indicate
about.
What's
what's
being
pushed
to
you,
and
sometimes
there's
only
one
thing
to
push
that's
fine,
but
other
times
there
might
be
a
little
bit
of
information.
That's
like
even
the
sort
of
correlating
uri
name
of
what
which
one
of
many
streams
a
server
might
support
that
it
needs
to
push
to
you
thanks.
So
I
I
think
the
text
in
the
charter
is
pretty
good
right
now.
I
I
It
really
feels,
like
I
mean
so,
for
instance,
gaming
is,
is
something
that
wants
to
be
low
latency
in
one
direction,
but
doesn't
require
interactivity.
Media
conferencing
is
requires
interactivity.
Low
latency
interactivity
in
both
directions
live
streaming,
can
have
an
arbitrarily
high
hand
wave
latency
depending
on.
What's
what
is
acceptable
to
the
to
both
customers,
and
you
know,
viewers
and
and
content
providers.
I
It
seems
like
one
of
the
reasons
why
the
quick
working
group
was
successful.
Is
they
picked
a
particular
use
case,
which
was
http
and
implemented
that,
and
that
seems
like
a
better
approach,
is
like
pick
a
single
use
case
and
have
other
people
in
the
room
with
future
use
cases
that
you
know
will
basically
say:
okay,
let's,
let's
make
sure
that
whatever
we
do
here
doesn't
preclude
these
future
use
cases
but
just
kind
of
scale
it
back
a
little
bit
rather
than
trying
to
boil
the
ocean.
That's
my
two
cents.
J
J
You
could
feasibly
have
you
know
the
other
end
request
and
I
think
that
there's
a
whole
lot
of
room
there
and
there's
gonna
be
debate
in
the
future.
If
you
say
push
protocol
like,
is
this
technically
a
push
protocol,
but
I
said
I
want
something,
so
I
would
just
remove
that
from
the
charter.
Remove
push
versus
pull
just
it's
a
protocol
for
sending
media.
It
doesn't
matter
who
asks
for
the
data.
F
F
E
Hello
again,
so
to
elaborate
on
push
versus
pull.
I
think
the
fundamental
distinction
I'm
trying
to
make
here
is
that
there
is
a
part
of
the
protocol,
that's
responsible
for
getting
media
from
one
point
to
another
and
like
specifying
how
it's
actually
transferred,
and
then
there
is
all
of
the
negotiation
and
side
channel
and,
to
some
extent
the
reason
we're
trying
to
kind
of
draw
the
line
between
different
drafts.
Is
that
the
part
where
you
send
media
and
the
exact
method
is
approach?
E
K
Mozzanaty,
cisco,
I
think
I
agree
with
luke
that
the
push
versus
pull
is
probably
you
know,
not
something
that
needs
to
be
flushed
out
in
the
charter.
It's,
I
don't
think
it's
just
a
nuance.
I
think
it
is
going
to
be
a
lot
more
technical
detail
and
I
think
people
have
different
ideas
in
the
room
and
like
what
victor
calls
push,
I
don't
think
some
others
would
call
push.
I
think
it's
correct
to
have
the
text
about
requesting
receivers
requesting
in
the
charter.
I
think
that
that
makes
sense.
K
I
don't
think
we
should
have
something
that
says
you
know,
publishers
push.
I
think
that
that
goes
too
far
and
we
need
to
work
in
the
you
know
work
the
details
of
what
does
it
actually
mean
to
to
publish?
Is
it
a
request
from
the
server
to
tell
you
to
go
ahead?
You
know
you
can
start
publishing
and
do
we
want
a
symmetric
protocol
where
it's
the
same,
whether
you're
publishing
or
subscribing
it's
a
request
and
a
response
and
the
response
can
be
not
immediate
or
synchronous,
but
long-lived
it
could.
K
It
could
send.
You
know
objects
over
seconds
in
response
to
that
request.
I
think
those
details
need
to
be
flushed
out
in
documents
and
not
in
the
in
the
charter
and
one
final
point
on
what
julius
mentioned
for
svc
and
various
encodings.
I
think
the
current
text
already
captures
the
rated
adaptation
strategies
with
different
codecs
codec
rates
and
qualities
and
encodings.
I
think
that
already
captures
all
that
we
want
for
the
different
media
formats
that
that
people
are
interested
in.
L
Yeah
I
support
kyle's
comment
that
this
is
boiling
the
ocean.
The
use
cases
that
are
described
are
extremely
different
and
I
think
my
personal
view
is
that
the
focus
here
should
be
on
live
streaming,
which
in
particular,
you
know,
needs
to
low
latency,
but
also
can
benefit
from
caching
and
the
gaming.
Some
of
the
gaming
use
cases
are
extremely
different.
They
don't
use.
Caching
and
and
conferencing
is
another
whole
whole
problem
of
real-time
conferencing.
L
M
Two
things:
first,
I
support
what
kyle
and
bernard
said.
I've
said
that
before
the
second
thing
is,
I'm
I'm
worried
about
specifying
a
mandatory
media
format.
Given
the
current
political
climate,
I
mean.
Realistically,
the
choice
nowadays
is
between
the
vp9
av1
world
and
the
hvc
vvc
world
for
the
video
stuff.
M
B
N
So
I'll
I'll
try
second
technique.
So
the
point
I
was
trying
to
say
is
that
there's
a
lot
of
new
use
cases,
that's
coming
where
the
streaming
world
is
trying
to
move
towards
bringing
in
interactivity
aspects
and
and
interactive
world
is
trying
to
bring
you
to
the
scaling
aspects
and
and
that's
driving
the
mock
work.
That's
that's
what
way,
where
I
felt
that
the
today's
solutions,
either
the
webrtc
being
complex
on
one
side
or
the
the
existing
low
latency
dash
or
or
the
other
speaking
solutions.
N
They
are
not
able
to
meet
the
interactivity
requirements
and
most
of
the
use
cases
that
have
been
written
there.
They
have
a
common
theme
of
having
low,
latency
and
interactivity
and
scale
in
common
in
there
can
all
does
all
these
use
cases
need.
Caching
may
not,
but
most
of
them
do
need
to
do
benefit
from
having
cash
in.
N
So,
even
though
I
do
feel
like
it
might
be
boiling
the
ocean,
but
they
are
only
these
things
are
need
to
be
solved
for
today's
and
tomorrow's
use
cases,
and
hence
a
new
working
group
and
mock,
I
think,
would
be
a
good
place
for
that
and
on
the
push
versus
school.
It
might
be
technical
at
this
point
in
time,
but
I
I
tend
to
agree
with
what
victor
was
pointing
out,
saying
that,
regardless
of
how
the
media
is
asked,
how
the
media
is
delivered
should
be
common
across
both
ingest
and
distribution
side.
N
C
Okay,
so
ellen-
and
I
have
discussed
this
a
little
bit
in
a
side
channel
and
it
seems
like
the
discussion
of
whether
the
phrase
push
should
be.
There
is
kind
of
rat
holing
a
little
bit,
and
so
I
think
what
we'd
like
to
say
as
chairs
is
that
we
accept
that
this
is
a
design
decision
to
be
made
by
the
working
group
and
that
the
exact
phrasing
to
describe
the
protocol
could
be
filigreed
or
something
very
different
than
push.
C
But
we're
going
to
set
that
aside,
functionally
accept
the
pr
that
was
just
filed
to
remove
the
push
from
the
charter
and
and
move
on
to
the
more
substantive
discussions,
because
that
seems
to
be
a
bit
of
a
rat
hole.
It
doesn't
seem
to
be
a
bit
of
a
rat
hole
to
talk
about
how
many
use
cases
we're
going
to
support.
C
But
leave
the
the
will
support
there
to
to
be
a
little
bit
vaguer
than
that,
and
so
I
think
it
would
be
very
useful
if
folks
could
focus
on
whether
picking
one
of
these
wouldn't
have
bad
long-term
consequences,
because
I
think
in
the
in
the
chat
it's
been
raised
by
a
couple
of
people
that
it
might
be
restrictive
and
then
picking
two
might
be
better
than
one
picking
three
might
be
better
than
two.
So
I
think
some
additional
discussion
on
that
is
probably
needed.
D
Hi
this
is
sanjay
mishra
from
verizon.
I
also
have
questions
as
I
was
reading
the
charter.
I
also
struggled
with
the
with
the
use
cases
that
are
so
divergent
in
nature,
each
of
those.
So
I
think
I
agree
that
it
makes
sense
to
have
a
charter
that
basically
scopes
out
all
the
relevant
work.
That
needs
to
be
done,
but
I
think
it
might
be
helpful
once
if
the
working
group
is
formed,
that
some
discussion
happens.
That
sort
of
says
you
know
what
is
the
priority?
D
Can
we
can
we
take
a
live
streaming
use
case,
as
the
first
example
of
that
working
group
will
take
on
or
versus
you
know,
media
conferencing
or
live
streaming
or
live
gaming,
because
each
of
these
are
very
different
use
cases
and
have
their
own
different
requirements
in
terms
of
what
the
latency
really
means
and
and
so
so
forth.
So
I
think
it's
probably
worth
looking
at
it
that
there's
some
prioritization
made
and
working
group
as
a
whole
decides
that
this
is
the
use
case.
D
O
B
O
Get
a
little
bit
closer
to
the
mic,
please!
Personally,
I
wanted
to
second
the
point
that
stefan
made
personally,
I
don't
care
too
much
about
media
encoding,
but
it
seems
to
be
hard
to
pick
to
agree
on
a
single
one.
We
had
had
issues
with
that
before
and
especially
given
the
zoo
of
use
cases
that
we
currently
have.
It
may
not
be
even
possible
to
pick
something
sensible
that
would
make.
I
would
make
it
across
all
these
cases
beyond
the
political
stuff
that
stefan
pointed
out.
P
P
P
I
I'm
informed
by
cullen
behind
me
that
I
have
not
said
anything
yet
so
I
will
I
will.
I
will
take
a
shot
at
saying
something
which
is
basically
the
definition
of
the
of
like
I
say,
the
definition
of
the
use
cases
can
or
could
point
to
live
media,
as
defined
in
the
mock
requirements,
draft
which
is
an
individual
draft
and
has
no
standing.
P
H
That
was
concrete
thanks,
vince
cullen
jennings.
I
I
sort
of
want
to
address
this.
This
use
case
thing.
I
think
that
the
the
people
that
have
been
working
on
this
for
the
past-
you
know
a
couple
years
and
six
months
and
having
lots
of
conversations
on
this,
you
know
we
sort
of
tried
to
think
about.
Do
we
just
want
the
way
we
split
up
the
different
ways
of
splitting
apart
the
work
we're
going
to
do?
H
Do
we
just
do
ingress
or
do
we
just
do
distribution
or
do
we
do
both
do
both
and
then
the
thing
is:
there's
huge
efficiency
gains
of
what
you
want
to
do,
and
so
you
can
look
at
that
list
of
things
and
go.
Oh
wow,
that's
a
wide
list
of
use
cases
they're
very
different,
but
what
we
do
at
ietf
is
trying
to
create
a
single
generic
tool.
That's
pretty
simple
and
I'll
talk
about
what
the
tool
is
that
this
is
creating
here.
That
covers
multiple
things
I
mean
http.
H
You
can
use
it
for
banking
websites.
You
can
use
it
for
news
websites,
you
can
use
it
for
gaming.
I
mean
you
can
even
send
you
know
machine
calls
over
it.
It's
a
generic
tool,
so
the
tool
that
we're
trying
to
create
here
is
a
low,
latency,
highly
scalable
video
system,
and
we
do
both
ingress
and
distribution,
because,
if
you
don't
do
both,
you
end
up
with
mapping
problems
between
the
two.
H
You
know
one
of
those
use
cases
you
end
up
with
there's
already
better
solutions
in
the
marketplace
for
it
you
could
use
webrtc,
you
could
go
use
hls
dash.
The
thing
is
when
you
want
to
combine
these
things
together
and
have
a
unified
tool
and
way
of
doing
it.
That's
when
you
get
to
this
work
making
sense.
So
I
don't
really
care
if
people
remove
some
of
those
use
cases
or
whatever
that's
not,
we
can
remove
all
the
use
cases
and
mention
of
them
from
the
charter.
H
But
the
important
thing
to
me
is
the
tool
we're
creating
is
going
to
end
up
being
useful
for
all
of
those
use
cases,
no
matter
what
we
say
in
this
right,
like
that's,
that's
the
tool
we
want
to
create
here.
So
it's
really
important
to
me
that
we
keep
the
scope
of
the
work
in
the
in
the
charter
that
you
know
as
it
is
that
we
don't
just
try
and
great
greatly
scope
it
down,
because
it
has
no
value.
H
If
you
take
a
smaller
piece
than
this
and
people
just
the
people
doing
the
work
just
aren't
going
to
be
willing
to
work
on.
It
is
not
it's
not
a
huge
value
thing
and
we
need
it
to
be
common.
We
need
to
meet
a
bunch
of
these
use
cases
so
that
we
can
get
the
synergy
of
the
different
groups
of
people
that
all
need
to
work
on
this
to
bring
something
together.
So
I
think
it
really
needs
to
proceed
as
it
is
thanks.
Q
Hey,
can
you
hear
me?
Yes
awesome,
I
came
to
say
almost
the
same
thing
that
colin
said
so
I
in
terms
of
use
cases,
I
think,
if
we
go
with
just
like
a
live
streaming
use
case
right.
So
it's
very
easy
to
there's
already
like
dash
hls
all
these
different
solutions.
That
sort
of
works
right
so,
but
I
think
it's
important
to
build
a
solution
that
works
for
different
use
cases
and
we
already
see
the
requirements
even
within
live
streaming.
Q
There
are
use
cases
where
latency
of
10
seconds
is
fine,
but
there
are
requirements
where
latency
of
subsequent
is
needed
for
interactivity
right
so
and
like.
Where
do
you
draw
the
line
where
it's
like
yeah
like
at
this
latency?
You
need
a
different
protocol
and
it's
also
very
difficult
to
build,
deploy
and
run
the
services.
Q
If,
for
every
single,
like
for
for
very
similar
use
cases,
you
have
to
essentially
use
different
protocols
with
different
infrastructure
so
having
something
that
works
for
a
variety
of
cases
is
would
be
very,
very
beneficial,
and
I
understand
there's
definitely
it's
hard
problem.
Hopefully
we
can
at
least
try
to
solve
it.
The
second
point
I
want
to
like
related
to
charter
phrasing-
I
you
know,
I
think,
in
the
beginning
of
the
charter,
there
is
a
phrase
about
interval
way
to
request
median
encodings.
Q
I
have
slight
problem
with
wording
requests
because
I
think
it
sort
of
implies
that
someone
is
asked
like
that.
Someone
has
to
ask
about
the
the
quality
the
encodings
that
being
sent,
but
I
think
it's
important
to
support
the
cases
where,
like,
for
example,
whoever
is
sending
media
can
decide
what
the
quality
to
send
so
like.
Basically,
what
I'm
talking
about
the
server
server
server,
driven
decisions
versus
client
driven
decisions,
and
we
need
to
support
both.
R
Hi,
jonathan
rosenberg,
five,
nine
two
comments.
First
wanted
to
respond
to
stefan
wenger
and
disagree.
I
do
think
we
should
make
sure
we
produce
something
that
has
a
minimum
mandatory
codex.
I
think
we
are
at
the
point
now
on
the
internet,
where
we
can
do
that
largely
due
to
the
very
painful
work
that
happened
before
that
many
of
us
went
through
opus
and
av1
being
the
result.
So
that's
comment.
Number
one
comment
number
two
on
the
wording
on
the
charter.
R
One
thought
or
a
possible
suggestion
is
to
think
of
this
as
a
published
subscribe
system,
because
the
where
the
publishing
effectively
takes
care
of
the
push
and
subscribers
on
the
receive
side,
I
think,
if
you
frame
it
as
publish
subscribe,
a
lot
of
the
problems
that
we
need
to
address
with
the
protocol
become
very
clear,
naming
and
identification
how
you
create
and
establish
subscriptions,
how
you
choose
amongst
formats
or
all
the
things
buffering
and
re-transmission
caching
from
the
publisher,
the
subscriber
all
become
fairly
clear
and
understood
concepts.
So
I
apologize.
B
S
S
So
I
don't
want
to
have
that
argument
here,
but
I'd
like
to
defer
it
so
that
working
group
can
have
it.
So
if
we
make
that
in
may,
so
that's
the
first
tweak
I'd
like
to
make
and
then,
when
we
go
to
the
where
it
mentions
end
to
end
encryption,
I
don't
know
which
slide
that's
on,
I'm
afraid
I'd
like
to
make.
S
I
want
to
be
able
to
encrypt
it,
and
I
want
to
have
that
in
the
first
version
of
the
spec,
rather
than
coming
back
for
abyss
or
a
new
charter
group
just
to
be
able
to
encrypt
the
metadata
which
should
have
been
encrypted
all
along.
So
I'd
like
to
the
charter
to
recognize
that
there's
a
plurality
of
ends
and
the
encryption
mechanism
should
allow
for
that.
B
J
J
Definitely
there
should
be
a
mandatory
container,
but
mandatory
codec
is
kind
of
a
deal
breaker
for
distribution,
at
least
because
a
lot
of
the
times
we
don't
have
control
over
whether
it
was
encoded,
and
you
end
up
just
having
a
lock-in.
You
know
you
just
force
this
one
old
codec
to
be
used
till
the
end
of
the
day
end
of
days.
J
J
J
But
we
definitely
want
to
avoid
the
current
situation
where
you
have
to
pick
a
protocol
per
latency
budget.
It's
it's
awful
that
one
viewer
has
to
get
webrtc
because
they
need
real
time
and
then
somebody
else
needs
to
get
hls
because
they
have
a
poor
network.
So
that's
the
big
thing.
I
think
that
we
want
to
want
to
solve
is
try
and
spread
out
the
use
cases,
and
unfortunately,
that
means
tackling
more
areas.
T
T
B
T
Are
certainly
some
mops
people
here
and
that's
a
good
thing
tm,
however,
comma
again,
damn
commas,
however,
we're
we're
actually
trying
to
draw
more
people
from
the
sva
cta
other
organizations
into
the
ietf
in
general.
So
you
know
we
can
help
be
a
conduit
if
you
will,
but
just
don't
don't
suffer
from
the
closed
world
assumption
and
think
that
that
everything
that
all
necessary
opinions
have
been
represented.
T
C
U
Magnus
yeah
magnus
wesley
and
erickson,
I
want
to
talk
about
the
media
format.
I've
probably
partly
blamed
for
some
of
this
formulation
because
I
think
at
fostered
a
view
in
some
discussions
with
the
proponents
here
at
last.
My
thing
and
my
intention
was
really
enough
from
my
perspective.
It
is
we're
talking
about
isobase,
media
files,
cms
or
things
like
that
or
potentially
are
you
using
rtp
payloads
in
general,
with
some
metadata
around
this
to
make
it
work?
U
But
I
kind
of
see
that
probably
should
soften
the
welding
here
about
because
it
does
depend
on
the
usage
where
you
deploy
it,
etc
and-
and
there
are
a
few
different
cases
here
which
might
have
different
choices
on
how
they
want
to
use
it.
So,
but
it's
definitely
I
mean
the
general
aspect
of
you
need
to
take
the
media
formulas
into
account.
This
work
is
clear
and
I
think
it's
crucial
to
ensure
that
multiple
can
be
supported.
W
A
few
points
I
agree
with
luke
that
it's
important
to
specify
whether
this
is
really
for
you
know.
This
is
for
video
conferencing
type
applications
or
for
streaming
applications.
They
are
different
and
I
understand
jdr's
point
that
they
kind
of
trade
in
each
other,
but
like
they're
different,
so
knowing
what
we're
targeting
is
important.
I'm
I
went
through
the
text
on
this
about
encryption
and
I
find
it
extraordinarily
puzzling.
W
So,
first
of
all,
quick
is
always
encrypted
and
quick
has
his
own
king
king
exchange.
So
I
don't
understand
like
what
any
of
this
text
really
means.
It
appears
to
be
something
about
an
encryption
on
top
of
quick,
but
it
makes
some
major
revisions
or
actually
sell
something
that,
like
like
people,
can
understand.
So
I
also
understand
really
what
a
simple
method
of
authentication
to
access
media
is
or
for
enabling
additional
descriptions.
W
So
perhaps
someone
can
fix
that
stuff,
but
I
think
the
charter
needs
to
be
I'm,
and
maybe
it's
all
and
I'm
I'm
not
saying
that
like
structurally,
what
he's
being
supposed
to
do
is
fine,
because
I
don't
understand
it,
but
I'm
saying
that
I
don't
understand
it.
That's
problematic
and
finally,
please
do
not
write
ends
to
ends.
Nobody
knows
what
that
means.
V
So
what
I'm
trying
to
say
is
that
this
charter
seems
like
a
super
set
of
a
few
things
that
may
not
necessarily
work
all
the
time
together
and
maybe
it's
worth
clarifying.
The
intention
is
this
the
case
of
working
group
that
will
oversee
several
solutions
that
do
not
will
not
work
together
or
is
the
intent
to
actually
try
to
make
make
it
possible
to
cache
real
quick.
B
Okay,
I
think
if,
if
you
asked,
is
the
intention
to
cash
raw
quick,
I
don't
think
that's
necessarily
the
the
goal,
but
maybe
somebody
who's
closer
to
cashing
or
has
thought
about
the
text
about
relays
and
caches
and
cache
friendliness
can
talk
about.
Maybe
what
that
means
a
little
bit
more
and
how
it
relates
to
http.
H
Colin
telling
jason-
let
me
just
speak
to
both
the
previous
two
speakers,
questions
there
and
see
if
I
can
answer
them,
so
I
would
start
with
the
the
security
stuff
ecker
point
well
taken.
That
needs
to
be
clarified
in
here,
but
I
think
that
the
the
proponents
of
this
buff
have
a
fairly
clear
understanding
of
what
we
mean
and
let
me
try
and
explain
what
that
is,
and
then
we
can
try
and
work
to
get
the
charter
to
reflect
that.
Certainly
to
put
this
in
http
terms.
H
Yes,
all
the
connections
are
fully
quick.
Normal
interpreted
to
that,
like
just
like,
http
is
encrypted
to
the
cdn,
it's
exactly
the
same,
but
we
don't
want.
We
want
to
have
optionally
the
ability
to
inside
of
what's
being
tricked,
so
that's
hot
by
hop
encryption
between
the
client
and
the
cdn,
the
client
and
the
server
if
there
is
no
cdn
and
then
from
the
server
back
down
to
the
other,
receiving
client
is
also
that's
all
encrypted.
H
So
what
the
end
to
end
talking
here
is
about
is
the
data
inside
of
that
can
also
be
optionally
encrypted.
So
some
things
wouldn't
do
it,
but
the
intention
is
to
use
mls
to
kid
and
to
be
able
to
incu
encrypt
the
blocks
there
and
the
metadata,
which
is
always
a
bad
word.
There
has
to
be
some
envelope,
data
that
is
authenticated,
but
not
encrypted.
H
That
was
very
media
specific
and
very
similar
to
what
they
already
do
with
quick
http
cdns
to
be
able
to
you
know,
terminate
the
quick
connection,
grab
the
data
and
cache
it
and
do
whatever
was
needed
by
the
the
work
that
was
done
out
of
this.
So
it's
well,
I
think
when
we
say
cash
friendly,
I
mean
that's
completely
vague
term.
What
does
that
even
mean
right?
It's
hard,
but
I
think
what
people
are.
H
Imagining
is
a
protocol
that
was
designed
from
the
beginning
to
enable
people
to
build
caches
for
deployments
that
want
that
type
of
thing.
There's
certainly
deployments
that
don't
need
that
there's
deployments
that
have
completely
their
own
caching
network
and
everything
and
it's
not
defining
how
caches
talk
to
each
other.
It's
just
designing
the
protocol.
The
work
here
such
that
caches
can
be
used.
You
can
build
a
cache
type
environment
if
you
want
to.
I
think,
that's
what
people,
what
the
proponents
of
this
were
largely
thinking.
P
P
I
wonder
if
there
are
any
constraints
about
how
just
any
constraints
on
this
protocol
based
on
how
people
expect
to
be
able
to
find
sources
and
sinks
and
relays
and
stuff
like
that.
If
people
have
something
clearly
in
mind
that
that
would
you
know,
that's
that's
cool,
but
I
just
you
know
if
we're
trying
to
talk
about
interoperability,
I'm
a
little
concerned
about
that.
Thank
you.
P
I
so
base
so
basically,
basically,
as
I
read
the
charter,
if
you,
if
you
wanted
to
have
an
interoperable
solution
using
this,
there's
no
guidance
from
this
charter
about
how
we
expect
this
protocol
to
be
used
at
at
a
minimum
and
recognizing
that
you
know
anybody
can
do
anything
to
locate
anything
in
their
special
case.
But
you
know
dude
do
do
we
want
do.
P
We
have
at
least
one
thing
in
mind
that
people
could
use
to
to
locate
the
things
that
they
need
to
locate
and
the
reason
I
mention
that
probably,
is
because
I
would
expect
the
next
conversation
we
have
to
be
about
privacy
concerns
for
senders
and
receivers,
and
you
know
it's
like
the
best.
The
best
way
for
privacy
concerns
to
be
resolved
is
that
senators
and
receivers
can't
find
each
other.
So
you
know
that's,
probably
not
the
goal.
E
E
W
So
I
think
victor's
point
first,
I
did
not
expect
there
to
be
I'm
trying
to
find
this
text
now,
but
I
didn't
read
that
text
as
being
mandatory
to
use
format.
I
interpreted
management,
implement
format
just
like
vp8
and
264
for
rtc,
and
I
do
think
those
are
useful.
I
think
this
great
interoperability
and
I
think
we
have
yeah
empty
military-
implements
exactly
what
that's
expected
to
say.
So
I
think
this
is
very
useful
and
I
think
it's
a
good
idea.
As
for
the
encryption,
thank
you
colin.
W
That
was
very
helpful.
I
guess
two
points
about,
so
I'd
be
happy
to
work
with
you
make
the
interpreter
say
that
two
points
I
would
be
happier
if
it
said
it
will
always
be
ending
encrypted,
but
maybe
we
can
argue
with
that
outside
the
charter.
Second,
I'm
still
a
little
unclear
about,
and
I
obviously
understand
why
you'd
want
to
have
some
metadata
clear
for
you
know
for
for
thing
really
the
way
to
do
things.
W
We
talked
about
that
in
srtp
as
well,
but
authenticating
that
is
actually
quite
a
tricky
problem.
So
I
think
we
may
have
understand
what
that
means
a
little
better
to
underst
to
be
able
to
talk
about
that.
It's
like
an
srtp
right.
The
the
metadata
is
in
the
clear
and
it's
authenticated
and
end,
but
it
can't
be
verified
by
people
in
other
cryptographic
keys
and
maybe
that's
what
you
want.
Maybe
it's
not
what
you
want,
but
to
be
clear
what
we're
trying
to
say.
C
L
B
K
I'll
have
to
do
get
ted
to
do
one
of
his
chants
again
to
get
everybody
calm
and
mellow,
but
on
the
mandatory
formats
I
think
it's
important
for
people
to
realize
that
trying
to
make
an
exception
for
some
use
cases
or
or
having
text
which
says
this
is
mandatory.
Only
in
this
use
case,
I
don't
think
anything
in
the
protocol
will
actually
ever
be
able
to
distinguish
the
use
cases,
I'm
not
imagining
any
protocol
bits
or
semantics.
That
would
actually
tell
someone.
This
is
live
streaming
or
this
is
interactive
or
this
is
vaude.
K
So
I'm
kind
of
at
a
loss
of
how
a
publisher
or
subscriber
would
even
know
that
this
is
going
to
be
mandatory
in
this
context
or
not.
So
while
I
think
it's
well
intentioned
to
limit
the
mandatory
formats
to
some
use
case,
I
don't
think
it's
practically
feasible
to
to
do
that
and
I
think,
having
a
fallback
that
everybody
always
implements
is
becoming
possibly
less
and
less
relevant
over
time.
K
Especially
if
you
try
to
use
a
fallback
like
webrtc
did
that's
most
likely
to
be
ancient
by
the
time
that
this
protocol,
you
know,
sees
widespread
adoption.
So
if
we
had
vp8
and
h.264
in
there,
I'd
be
very
sad
as
those
mandatory
to
implement
formats.
So
I
don't
think
we
should
copy
prior
charters
on
on
that
softening
the
language
should
just
say,
may
choose
a
mandatory
format.
K
I
think
you
know
may
get
us
further
down
the
road,
but
I
would
not
add
the
text
that
has
suggested
about
specific
use
cases,
because
I
don't
think
that's
going
to
be
feasible
to
implement
and
then
one
point
on
the
security
is.
I
I
agree
with
ecker
that
reading
the
charter
now
with
fresh
eyes,
it's
very
confusing
and
doesn't
really
convey
what
people
that
were
working
on
this
for
a
while
have
already
had
in
the
back
of
their
heads.
That
cohen
suggested
so
really
everything
that
is
done
by
quick.
K
We
should
explicitly
say
in
the
charter
that
media
will
be
encrypted
per
quick,
but
there
will
optionally
also
be
an
end-to-end
encryption,
and
the
protocol
is
not
doing
that.
I
think
it's
clear
to
specify
that
we
are
not
specifying
any
of
the
protocol,
not
just
the
not
just
the
keying,
but
the
actual
use
of
those
keys
to
encrypt
media
mock
is
not
involved
in
any
of
that,
but
what
is
important
is
to
identify
the
protocol
needs
to
be
able
to
identify
what
is
and
encrypted
and
what
the
context
is
for
that.
K
You
know
how
do
you
know
where
do
you
get
the
drm
keys
or
end-to-end
keys
for
that?
I
think
that's
important
to
specify
that's
really.
What
the
protocol
is
going
to
do
is
identify
that
some
things
are
end
and
encrypted
and
what
the
context
is
for
that
encryption
and
that
there
is
a
separate
context
for
transport
metadata
that
will
the
relays
will
have
access
to.
D
I
just
wanted
to
respond
back
to
what
cullen
was
saying
earlier
on
the
use
cases,
so
I
think
I
I
don't
think
there's
any
quants
about
use
cases
and
and
charter
is
the
right
place
to
have
all
those
you
to
to
be
able
to
call
out
that
moq
mock
will
support
these
use
cases.
I
think
the
question
is
that
each
other
use
cases
have
to
look
differently,
for
example
that
for
live
streaming
really.
Caching
is
not
really
something
that
you
would
do,
but
you
know
maybe
for
vod.
D
That
would
make
sense
to
do
that.
The
the
common
denominator,
of
course,
is
that
each
of
these,
for
each
of
these
applications
will
benefit
with
the
low
latency.
So
low
latency
applies
universally,
but
there
are
other
parameters
you
know,
for
example,
caching
will
not
apply
to
live
streaming,
so
I
think
that
really.
The
point
is
that
these
are
all
valid
use
cases
that
should
be
addressed,
and
this
is
the
right
forum
to
do
that.
D
D
B
J
Hi
luke
from
twitch
again
so
with
mandatory
formats.
One
of
the
things
that
comes
up
on
the
distribution
side
is
caching.
If
we
have
a
thousand
people
watching
a
stream,
we
we
want
them
to
all
watch
the
same
format.
We
don't
want
to
have
this
case
where
we
have
two
people
have
this
legacy
format
that
the
initial
draft
specified
to
not
like
invoke
flame
wars.
You
could
imagine
if
the
draft
said
you
must
support
gif,
but
in
the
future
we're
all
using
pngs.
J
You
don't
want
one
person
using
an
old
client
to
request
a
gif
and
forcing
you
in
coding
and
spin
up
a
new
encoder
and
then
force
you
to
have
a
new
cache.
So
I
don't
at
least
for
the
broadcasting
side.
You
can
make
a
case
for
mandatory
formats.
You
must
support
this
codec,
but
at
least
in
the
distribution
side.
J
It's
we
want
just
one
it's
too
expensive
to
support
multiple
ones
in
a
lot
of
cases,
and
we
don't
want
to
leave
it
up
to
the
the
viewer
to
decide
if
they
want
to
make
it
expensive
for
us.
So
the
mandatory
for
some
use
cases,
I
think,
is
just
toothless
like
there's
no
point
saying
that
if
you
can
just
opt
out
of
it
by
saying
I'm
not
that
use
case,
so
I
would
just
leave
it
in
the
air
like
we
have
codex.
S
S
S
So
I
want
that
that
that's
why
I
want
to
have
that
in
the
chat
I
mean
yeah,
we
don't
need
to
call.
It
ends
two
ends
or
whatever,
and
I
think
that's
you
know,
there's
some
wordsmithing
that
can
go
into
the
rest
of
the
thing,
because
I
don't
think
you
need
the.
However,
outside
the
scope
of
the
working
group
as
it's
a
bit
chatty.
B
P
So
we've
had
discussion
a
bit
on
the
mailing
list.
I
think,
most
recently
with
about
metadata
not
being
monolithic
that
some
metadata
is
as
we've
talked
about.
It
is
helpful
for
relays
and
things
like
that
to
figure
out
how
to
how
to
best
forward
packets
and
things
like
that
and
other
metadata
is
not
that.
P
C
B
I
just
wanted
to
respond
to
one
thing
spencer
said
at
the
beginning,
which
was
about
metadata
and
that
there
was
some
attempt
in
the
charter
to
to
at
least
clarify
the
kinds
of
metadata
that
would
be
useful
for
transport
relays
and
and
whatnot.
And
but
I
I
think
I
heard
you
say
you
wanted
more
description
or
distinction
distinguishing
the
kinds
of
metadata
that
wouldn't
be
available,
or
that
would
be
something
for
the
working
group
to
hash
out.
P
The
the
thing
I
was
trying
to
say
was
for,
and
maybe
the
answer
is
that
the
charter
recognizes
that
metadata
is
not
monolithic
and
that
the
you
know,
a
working
group
responsibility
will
be
to
figure
out
what
kind
you
know
how
to
treat
different
kinds
of
metadata
for
different
reasons
I
I
would
be.
I
would
be
happy
with
that.
You
know
other
people
can
do
the
right
thing.
Also.
C
Yeah,
so
we
ellen-
and
I
were
kind
of
going
in
the
side
channel
to
talk
a
little
bit
about
how
we're
gonna
handle
the
mandatory
day,
implement
media
format,
discussion
and
it
occurred
to
us
that
it
might
be
good
to
get
a
sense
of
the
room.
Obviously,
that
we've
had
some
good
comments
at
the
at
the
mic,
but
what
we're
going
to
do
is
use
the
show
of
hand
tool.
C
The
question
that
will
be
in
the
show
of
hand
tool
is:
the
charter
should
specify
a
mandatory
to
implement
media
format
either
on
a
use
case,
specific
basis
or
generally
raising
your
hand
would
be
a
yes
to
this
and
choosing
not
to
raise
your
hand
in
the
tool
would
be
a
no.
The
session
is
starting
now.
B
C
B
H
H
C
Okay,
we
don't
seem
to
be
getting
a
lot
more
so
through
the
tool.
What
I
see
is
do
not
raise
hand
63,
raise
hand
20.,
that's
clearly
not
consensus
in
in
either
direction,
but
it
is
definitely
trending
toward
concern
toward
specifying
a
mandatory
to
to
implement
media
format.
So
I
think
what
we
probably
need
to
do
here
is
to
think,
if
there's
something
else
that
that
reaches
us
for
that
interoperability,
that's
the
desired
goal
of
that
mandatory
to
implement
format,
but
perhaps
doesn't
use
that
particular
method.
H
Go
ahead,
thank
you,
ted.
I
I
was
probably
just
confused,
but
I
may
not
be
the
only
person
in
the
room.
You
were
hard
on
your
mic's
really
over
loud
and
I
actually
took
your
question
to
be
about
mandatory,
implement
codex,
not
formats
when
you
ran
that
poll.
But
you
know
my
mistake
anyway.
I
may
not
have
been
the
only
one
confused.
H
H
I
don't
think
things
I
wanted
to
come
back
to
the
metadata
for
a
minute,
because
I
think
that
that's
the
other
one-
and
I
my
my
strong
belief,
is
the
only
thing
that
should
go
in
this
not
encrypted
stuff
is
stuff
that
the
protocol
mandatory
won't
work
with.
If
you
encrypted
it
right,
there
should
be
nothing
that
you
could
encrypt
that
you
don't
encrypt
for
the
indian
encryption
type
stuff.
H
So
we're
talking
about
the
you
know
it
to
put
this
in
ip
terms
is
to
be
like
you
can't
encrypt
the
destination
ip
address,
like
the
network
can't
function.
If
you
do
that
right-
and
this
is
the
same
thing,
what
is
the
absolute
stuff
that
the
caches
have
to
be
able
to
see
or
the
the
middle
servers
need
to
be
able?
The
server
needs
to
be
able
to
see
so
that
it
can
make
the
right
decisions
about
what
to
forward
next.
What
media
to
flow
congestion
control
those
types
of
things.
H
H
W
Yeah,
I
I
think
that'd
be
a
fine
suggestion
from
cullen,
though
I
suspect
we'll
find
this
thing
as
extensible
and
then
all
kinds
of
creepy
privacy
stuff
can
be
sent
in
it.
So
richard
barnes
and
I
independently
produced
two
pr's
that
attempt
to
like
encode
this
discussion
about
encryption.
I
think
either
would
be
fine,
so
please
take
a
look.
Those
are
59
and
60,
probably
60s,
which
is
his
a
little
stronger.
I'm
still,
I
think,
a
little
confused
about
the
the
the
the
text
about.
W
W
Oh
okay,
oh
yeah,
yeah!
Here
we
go
so
this
last
this
last,
so
I
think
this
first
sentence
I
tried
to
read
I
I
I'm
trying
to
rewrite
about
because
I
think
it
just
means
a
way
to
demonstrate
to
the
relay.
You
should
get
the
media
or
the
way
to
demonstrate
the
relay
that
you
should
be
enabled
in
just
media.
So
that
seems
easy
and
I
can
fix
that.
W
N
B
N
We
need
to
help
that's
the
only
way
we
can
make
this
relays
to
be
really
casual
and
also
performance
and
scalable
as
well
and
on
the
thing
about
relay
discovery
and-
and
I
I
personally
feel
that
dash
kind
of
should
be
outside
the
scope
of
this
working
group.
Maybe
an
architecture
document
could
specify
some
of
some
of
the
like
informal
ways
to
do
that.
V
X
Alyssa
cooper,
I
was
just
reflecting
a
little
bit
about
the
relationship
between
the
webrtc
charter
and
what
happened
in
webrtc
with
the
codex
situation.
To
try
to
think
about
this
in
that
frame,
and
you
know
we
ended
up
with
different
requirements
for
different
kinds
of
endpoints
webrtc
browser,
webrtc,
non-browser
and
webrtc
compatible,
something
or
other
endpoint,
and
I
was
just
wondering
if
thinking
about
that
thinking
about
it
from
the
client
perspective
might
cut
through
this
a
little
bit
because
it
sounded
like
when
luke
was
talking.
X
It's
it's
really
about
this
difference
between
a
situation
where
you
want
the
node
serving
the
media
to
be
able
to
dictate
what
the
format
should
be
and
it's
acceptable
to
have
a
loss
of
interoperability,
whereas
other
situations,
where
it's
very
important
to
be
able
to
have
that
authority
live
with
the
clients
that
you'll
you'll
cut
out
a
lot
of
opportunity
for
independent
clients
to
be
part
of
the
ecosystem.
If
there
isn't
a
baseline
specified,
and
so
maybe
that's
a
way
to.
X
I
find
the
concept
of
doing
it
on
a
use
case
by
use
case
basis
a
little
bit
unsatisfactory.
But
I
still
do
think
that
you
need
to
have
common
baselines
in
some
of
these
cases,
so
maybe
that's
a
way
to
cut
through
it.
But
then
I
was
also
thinking
that,
had
we
specified
tried
to
specify
these
categories
of
clients
in
the
webrtc
case
ahead
of
time.
That
never
would
have
happened
because
it
took
like
many
years
to
come
to
that
sort
of
compromise.
So
I
feel
like
you
need
something
in
the
charter.
B
K
I
don't
know
mosinetti,
I
think,
elizabeth's
a
good
point
about
the
different
device
types
rather
than
use
cases,
and
what
may
not
be
clear
in
the
charter
is
there's
clearly
two
different
device
types.
There's
subscribers
and
publishers,
that's
one
type
of
device
and
there's
or
entity,
let's
not
say
device,
and
then
there's
servers,
relays
and
caches
which,
for
the
most
part,
should
not
know
or
care
what
the
media
formats
are.
If
we
do
our
job
right,
it's
just
the
transport
protocol.
K
K
It
should
only
impact
the
subscribers
and
publishers
and
not
anything
else
in
the
chain
and
on
on
the
encryption,
I
think
there
was
a
suggestion
that
I
put
on
the
mailing
list
about
explicitly
defining
naming
the
word
transport
metadata
as
what
the
protocol
operates
on
and
can
see
and
access,
and
we
may
not
we'll
probably
probably
won't
be
able
to
describe
it
in
detail
in
the
charter.
I
think
it's
going
to
be
something
for
future
work
in
the
actual.
K
You
know
documents
that
come
out,
but
I
think
it
may
be
useful
to
have
something
in
the
charter
to
nail
the
concept
of
transport
metadata
that
is
accessible
to
the
relays.
I
think
right
now
it
just
says
a
method
of
you
know
of
accessing
some
data
such
as
and
gives
examples,
I
think
just
having
a
word
for
it,
transport
metadata
and
then
all
all
other
data.
K
Publishers-
and
subscribers
know
this
is
drm
content,
and
this
is
not
drm
content
and
then
I
think
we
also
need
to
have
some
people
that
liaise
with
the
the
mpeg
forms
about
common
encryption,
because
there's
been
a
lot
of
work
done
among
publishers
and
device
makers
to
not
have
to
have
multiple
formats
and
input
common
encryption
may
be
useful
for
that,
and
that
may
be
something
that
we
can.
We
can
leverage
in
this
in
this
work
too.
E
C
C
So
thanks
everybody.
There
were
a
lot
of
good
suggestions
for
updates
to
the
charter
during
the
course
of
today's
discussion.
It's
good
to
see
so
much
energy
in
the
queue,
whether
it's
a
remote
or
in
in
the
room.
There
were
a
couple
filed
here
and
I
believe,
two
of
them
kind
of
overlap,
I'm
going
to
show
60
rather
than
59,
based
on
some
comments
in
the
chat,
but
I'm
just
going
to
go
through
these
very
quickly.
P
F
C
C
C
Okay,
so
I
think
what
that
is
telling
us
is
that,
at
the
end
of
this
meeting,
we'll
we'll
be
accepting
those
prs
and
we'll
now
go
on
to
to
ask
some
of
the
questions
that
are
the
buff
questions.
So
I'm
going
to
stop
the
screen
share
now,
but,
as
you'll
see
in
the
chat,
there
is
a
link
to
the
the
polls
and
a
related
set
of
things.
Sorry.
H
C
C
C
C
C
C
Okay,
I've
now
discovered
that
you
cannot
actually
unmute
yourself
once
you've
started
a
poll.
Thank
you
to
whoever
it
was.
That
actually
said,
the
poll
is
up
now
so
spencer,
as
is
clear
in
one
of
the
later
ones.
When
we
talk
about
the
problem
statement,
we
mean,
after
after
the
discussion
in
the
room,
that's
also
clear
when
we
will
start
talking
about
the
charter,
so
give
us
a
second
for
the
next
buff
question.
C
C
C
C
All
right,
so
that
was
62
folks
raised
their
hand
that
they
were
willing
to
review
documents
or
comment
on
the
mailing
list
of
working
group
should
be
formed.
Nine
people
deliberately
did
not
raise
their
hand
indicating
they
would
not
be
willing
and
I'll
point
out
that
there
are
152
people
in
the
aggregate
here.
So
there's
definitely
quite
a
few
people
who
are
choosing
not
to
answer.
C
C
The
final
question
really
isn't
a
show
of
hands
style
question:
it's
for
anyone
who
does
not
think
a
working
group
should
be
formed.
Do
you
wish
to
address
the
the
both
addressing
your
concerns
and
I
did
notice
that
there
was
one
person
who
apparently
raised
and
then
lowered
and
raised
and
then
lowered
and
raised
and
then
lowered
their
hand
a
number
of
times.
So,
if
you
feel
wishy-washy
about
it
and
wish
to
address
the
buff
with
your
concerns,
you're
also
welcome
to
join
the
queue
now.
C
C
R
C
N
H
N
C
C
Hopefully
those
of
you
in
philadelphia
are
having
wonderful
hallway
conversations
to
do
that,
but
that
we
might
want
to
schedule
some
sort
of
interim
meeting
on
online
or
in
person
to
try
and
get
those
technical
discussions
kicked
off
again
pending
the
decision
of
the
isg
and
the
and
and
any
final
charter
changes.
Does
that
make
sense
to
folks
look
like
spencer.
P
C
Yep,
if
it
turns
out
that
the
the
community
needs
to
discuss
charter
changes
that
the
iasg
or
the
broader
community
requires,
we
can
definitely
do
that
as
well.
But
I
was
also
thinking
that
the
technical
discussions
would
be
a
great
type
of
conversation
for
a
get
together
online
or
in
person
sometime
between
now
and
115,
if,
if
that
made
sense,
so
if
there,
if
there's
no
comments
on
that,
we
can
let
people
go
off
to
lunch.