►
From YouTube: IETF94-RTCWEB-20151105-1520.webm
Description
RTCWEB meeting session at IETF94
2015/11/05 1520
C
We've
had
10
take
care.
Thank
you
very
much
bow
and
we
have
h
a
prescribed
Joe
Hall.
We
could
use
another
secondary
backup,
note,
taker
and
taste
bo
needs
to
walk
to
the
restroom
or
needs
to
get
up
and
speak
at
the
microphone.
So
is
there
anybody
in
the
room
who
would
like
to
volunteer,
for
example,
drama
Paula
to
be
a
secondary
note-taker.
Anyone.
C
D
So
cool
the
ITF
note
well
you've
been
here
all
week,
you'll
see
miss
a
lot
note.
It
well
Sarge
end
of
day,
one
which
we
already
did
and
its
agenda
for
day
two
I
guess
we
do
a
little
basher
at
the
beginning,
which
is
some
administer
of
your
stuff.
D
Some
we're
gonna
do
some
administrative
minister,
some
administrivia
stuff
Magnus
has
pointed
out
to
us
that
are
the
audio
draft
timed
out
and
it
actually
was
supposed
to
go
out
to
working
group
last
call
so
we're
in
the
process
of
requesting
the
author
to
spend
a
new
version.
So
it's
not
expired
and
then
we're
going
to
working
group
last
call
it
and
get
it
to
Alyssa.
The
audio
interrupt
draft
is
basically
in
a
stable
state
and
we're
also
going
to
work
into
a
blast
call.
B
E
C
E
Mud
to
be
honest,
it's
just
where
a
documents
go
into
so
I
wasn't
sure
why
she
needed
to
discuss
it
anymore.
It
we
all
ready
to
discuss
the
actual
problem
in
detail
on
Monday
right.
C
C
E
C
For
Eddie,
do
we
need
in
order
to
take
on
board
the
the
result
of
the
discussion
around
IP
handling?
Is
the
right
approach
simply
to
put
that
into
the
drafts?
Remember
the
what's
happening
at
this
point
is
option
one
and
and
get
experimental
results
on
the
implementation
of
option
one
or
do
we
need
to
progress?
The
draft
in
which
that's
described
and
which
way
is,
is
the
best
way
forward.
Well,
why
don't
we
take
the
color
at
the
microphone
and
then
we'll
come
back
to
you
for
your
thoughts
on
okay.
E
I'm
97
the
collar
now
I'm,
sorry.
E
The
other
thing
I
wanted
to
mention
is
progressing.
The
FEC
draft
published
a
new
version
of
the
FEC
document.
There
not
a
whole
lot
of
updates
in
there.
That
will
need
to
be
discussed
other
than
just
responding
to
comments
that
I
received
on
the
list.
At
this
point
in
time,
I
considered
to
be
almost
complete,
there's
one
more
to
do
to
deal
with,
but
I'd
like
to
get
another
set
of
reviews
so
that
we
can
advance
this
at
a
less
cost.
We.
E
C
C
C
B
G
H
Alyssa
cover
gonna
pretend
like
the
second
most
momentous
decision.
This
group
is
made,
so
my
advice
would
be
to
keep
the
keep
the
IP
stuff
in
a
separate
draft,
because
J
sub
will
finish
one
day
and
and.
H
And
then
there
will
be
experimentation
and
this
piece
may
change
right,
like
that's
the
whole
point
of
putting
it,
you
know
just
documenting
it
then
running
some
experiments
right.
So
so
you
don't
wanna
have
to
update
the
whole
document.
After
that
happens,
I
would
say
so.
I
would
say,
keep
it
separate.
Okay,.
C
E
E
C
F
H
F
I
So
Mosin
addy
we
had
some
decisions
made
in
the
amuse
accession
they're,
not
fully
reflected
in
the
latest
of
the
reversion
to
simulcast
draft
yet,
but
within
the
next
couple
of
weeks,
we'll
get
all
those
decisions
put
in
there.
Basically,
the
main
change
is
that
there's
a
new
new
draft
called
a
music
rid
the
bottom
one,
that's
not
going
to
become
mandatory
for
simulcast,
and
so
simulcast
layers
are
going
to
be
identified
by
this
new
rid
its
RTP
stream
identifier
and
the
the
older
payload
type
based
identifiers
are
going
away
from
simulcast.
I
So
it's
very
clear,
very
simple:
there's
only
one
thing
to
implement
rids
are
mandatory.
It's
the
only
way
to
negotiate
simulcast
and
we'll
get
all
those
updates
in
probably
within
the
next
few
weeks
and
I,
don't
believe,
there's
any
remaining
large
open
issues.
There's
a
few
loose
ends
about
syntax
that
will
clear
up
and
we'll
get
more
things
from
the
stp
Directorate
once
it
actually
goes
out
for
review,
but
I
think
it's
mostly
loose
ends
now.
J
I
E
J
E
D
Ok,
so
I
did
recently
upload
these
slides
about
like
an
hour
ago,
so
probably
need
to
refresh,
and
I
sent
them
to
the
authors
of
the
drafts,
probably
about
30
minutes
ago,
so
I
did
actually
get
a
quick
review.
This
is
probably
gonna
be
a
little
bumpy.
Please
bear
with
us.
We
do
need
to
go
through
the
drafts,
so
the
status,
basically
is
the
dress
we
went
through
when
been
through
working
group.
D
Last
call
and
they're
kind
of
chilling
out
in
the
waiting
for
working
group
chair
go
ahead,
but
we
found
some
stuff
that
we
kind
of
missed.
So
we
pulled
it
back.
I
think
bernardo
boba
caught
some
things
at
ITF
92
there
were
suggestions.
Some
there
was
a
presentation
that
Martin
did
I
guess
to
include
maybe
Erika
Erika
tit
to
do
some
things
for
the
hash
algorithm
to
be
used
for
them.
D
Fingerprint
was
to
change
to
use
shell
56,
and
there
were
some
mass
des
stuff
that
was
still
kind
of
lingering
in
the
draft,
and
there
was
some
WTF
cipher
suites
that
were
listed
there
and
basically
agree
the
last
time
to
nuke
them.
Nothing.
None
of
that
got
done
so
that's
still
on
tap.
Then
I
actually
went
through
the
github
repo
there's
one
PR
in
there,
which
is
basically
the
swap
out
RSA.
Is
the
signature
algorithm
to
switch
to
ecdsa
the
question
at
the
time?
D
Was
you
know
what
is
TLS
working
group
going
to
do
because
that's
like
that
are
not
mandatory,
implement
algorithm,
but
TLS
is
in
the
process
of
moving
all
of
the
all
of
the
EC
supported
cipher
Suites
to
standards
track
and
like
for
TLS.
1.3
ecdsa
is
actually
one
of
the
required
ones
and
there
is
actually
kind
of
wide
get
more
widespread
supported.
You
see.
De
DSA's.
Things
are
progressing
and
as
as
as
other
cas
start
to
initiative,
ecdsa
certs
diddle
that
are
free,
there'll,
be
more
of.
B
D
K
D
I
think
the
question
was,
you
know:
do
we
think
we
need
to
do
a
consensus,
call
to
adopt
this
change
for
the
pr
I
think,
just
to
be
clear,
it
probably
would
make
sense
you
did
do
so
to
kind
of
knock
it
out
like,
of
course
again
we're
running
this
by
my
work.
My
working
group
chairs
as
well
so
I
guess
I
would
like
do
you
if
you
understand
that
the
question
at
hand
about
the
PR
for
adopting
easiest
ecdsa
instead
of
RSA,
please
hum
now
as
MTI?
D
D
Okay,
that's
what
I
wanted
to
know.
K
D
F
K
B
L
C
M
K
Terms,
interns
intern
to
interrupt
on.
There
are
two
questions
which
algorithms
you
are
going
to
generate
and
verify
in
which
algorithm
is
you
actually
generate
by
default
on?
So
the?
What
we
validated
is
that
pretty
much
everybody
will
accept
ecdsa
if
you
generate
it
and
give
it
to
them
on,
and
so
it
seems
to
be
relatively
okay
to
switch
the
defaults
I.
Suppose
if
you
were
concerned
that
people
were
going
to
I
suppose
you
were
concerned
the
people
we're
going
to
stop
supporting
our
essay,
then
you
might
have
enter
our
problem
on
okay.
L
So,
madam
Thomson,
we
actually
went
ahead
and
just
did
this
and
we
did
discover
a
few
problems.
The
first
one
was
that
the
very
old
versions
of
the
WebRTC
door
code
failed
to
make
one
small
call
in
to
openssl
that
enabled
the
use
of
ec
d
h,
which
the
ephemeral
key
exchange
stuff,
which
doesn't
relate
to
this
that
much,
but
it
did
affect
the
psycho
sweet
selection
and
we
have
had
reports
from
one
of
our
partners.
L
E
Ya
man,
the
main
thing
is
that
you
need
to
be
able
to
support.
You
know
in
order
to
be
considered
to
be
old
enough
to
ride
the
web
RTC
ride.
You
need
to
support
receiving
ecdsa
from
a
browser
like
that's
the
critical
thing
and
then,
like
you
know,
must
implement
ecdsa,
so
somebody
can
choose
it
if
they
want
it,
which
I
assume
most
people
want
it
by
default.
It
seems
it.
The
other,
only
salient
piece.
F
B
K
You
say
what
you
mean
to
say
is
how
much
equipment
impact
if
endpoints,
actually
removed
RSA
as
opposed
to
for
making
it
non-mandatory
right.
Yeah,
yeah,
yeah
I
mean
I.
Want
me
out,
I
mean
so
again.
I
wouldn't
be
shocked.
If
there
are
people,
only
support
old
people
old,
the
motivation
always
support
our
essay
on
and
I
suspect
that,
if
I
suspected
it
in
well,
if
that,
if
every
browser
took
out
our
essay
someone
with
absolute
interview
any
way
to
use
it,
some
would
have
a
bad
day
and
so
I'm.
K
F
So
my
preference
would
be
not
to
leave
our
essays
MTI
if
that
doesn't
cause
any
any
harm,
because
it
makes
it
so
much
easier
decision
to
analyze.
I
don't
have
to
analyze
anything
I
know
it
works
right.
I'm.
D
D
Line,
don't
worry
about
us,
it's
that's
an
that's
internal
Mozilla
stuff,
so
one
of
the
other
steps
that
we
have
to
one
of
the
other
steps
that
we
have
to
jump
through
is
to
get
director
reviews.
So
we
went
ahead
and
got
to
early
director
reviews.
We've
got
an
appt
week.
D
Let's
say
this
is
kind
of
aim
to
you
write
a
lot
of
the
it
sits
on
the
mailing
list,
we'll
try
to
figure
out
what
we're
going
to
do
to
make
it
easier
to
read
and
more
understandable
and
work
through
some
of
them,
but
they're
like
I,
don't
think
we're
going
to
rewrite
both
of
those
documents.
H
D
All
right,
fair
enough,
we
also
the
sect.
The
sector
reviews
are
a
little
bit
more
challenging
and
that
often
they
turn
into
discusses.
So
basically,
when
I
we've
got
one
review
of
this
security
architecture,
draft
from
Tobias
gun
trim,
the
other
one
is
done
by
dkg.
He
got
the
other
draft.
The
interesting
thing
is
that
we
actually
deal
a
lot
with
dkg
in
TLS
and
Ian.
D
Acker
spent
like
three
hours
today,
working
on
stuff,
so
I
think
that,
as
things,
progress,
we're
gonna
be
able
to
get
informed
comments
on
the
other
draft
as
well.
So
basically,
we're
going
to
do
now
is
try
to
go
through
the
the
the
comments
that
we
got
from
Tobias
on
the
architecture
craft.
There's
like
ten,
more
slides
or
something
it's
like
we're
trying
to
get
a
sense
of
the
room
of
how
we
should
try
to
address
them.
H
D
Alright,
so
this
is
the
first
one
he
marches
to
discuss,
which
probably
means
it's
fodder
for
a
discussed
and
if
there's
a
there's,
a
the
the
column
on
the
left
is
a
statement,
that's
in
section
4.1
about
initial
signaling
and
then
his
comments
on
the
right
I
did
forward
these
finally
to
the
email
to
the
list.
So
you
take
them,
but
maybe
take
a
couple
minutes
to
look
at
this
I
know.
Martin
has
already
thought
about
this
little
bit.
Yeah.
K
You
eat
the
only
thing
you
can
do
with
whoever
to
about
luxury
means.
I
flooded
the
people
call
request
right
but
which
bit
decision
is
specifically
designed,
so
you
don't
get
a
lot
of
data
from
people
when
you
didn't
read
it
when
you'd
agree
to
send
it,
and
so
I
mean
it's
just
incorrect.
Okay
from
the
point
number
one
is
basically
exactly
the
point
we
spent.
You
know
45
minutes
on
on
about
IP
address
privacy,
yeah.