►
From YouTube: IETF97-PERC-20161115-1330
Description
PERC meeting session at IETF97
2016/11/15 1330
B
D
E
All
right,
it's
about
that
time,
welcome
to
the
park
meeting
here
at
IETF
97.
If
that
is
not
the
journey,
you're
looking
to
go
on
today,
you're
in
the
wrong
room,
so
we've
been
an
action
for
a
while.
You
are
auto
plank
note.
Well
by
this
point
of
the
week.
You've
probably
seen
this
once
or
twice.
If
you
have
any
IPR,
please
disclose
it
and
read
all
those
referral,
Inc
documents
or
have
your
lawyer
read
than
for
the
details.
E
So
where
are
we
as
working
group?
We've
got
a
few
milestones
since
the
last
meeting
see
us
and
I
looked
at
these
I
think
one
of
these,
the
last
we
talked
was
in
September
of
2016,
which
is
clearly
past,
so
being
optimistic.
We
went
ahead
and
push
them
all
out
to
june
of
next
year
figuring.
I
could
probably
meet
that
milestone.
F
A
E
Thanks
for
our
kind
ad
for
not
noticing
when
we
did
that,
so
where
are
we
so
we
are
in
about
the
same
state
in
terms
of
a
doctor
documents,
as
we
were
last
time
cos,
I
haven't
spent
a
few
minutes
talking
about
you
know
where
we
might
want
to
go
with
this
group
and
we'll
have
some.
Where
do
we
go
from
here
discussion
at
the
end,
because
progress
has
slowed
down
a
little
bit?
We
put
some
stars
here
next
to
drafts
that
we've
adopted.
E
We've
talked
about
for
a
while
and
I've
kind
of
started
to
stabilize
and
we've
had
some
rounds
of
comments.
We've
done
comments
address
the
latest
versions
and
we
might
now
be
willing
to
consider
last
call
on
so
we'll
circle
back
to
this
at
the
end
and
discuss
what
we
wanted
last
call
what
we
think
needs
more
time,
and
you
know
what
we
should
spend
more
effort
on
or
not
at
the
end
of
this
meeting.
So
look
at
the
stars.
E
G
G
So
the
major
change
since
the
last
time
is
you
remember,
we
always
had
in
this
draft
text
that
there's
things
that
that
they're
Indian
encrypted
things
are
hop
to
hop
encrypted.
There
are
certain
headers
that
may
have
been
inserted
by
the
media
distributor
and
your
question
is,
is
which
ones
with
us?
In
the
end?
Point
trust,
and
we
discussed
the
last
meeting-
that
really
the
only
one
of
those
that
we
had
a
use
case
for
and
thought
was
important.
B
B
G
G
G
G
A
B
Okay,
I
think
I
looked
it
up.
I
think
what
this
is
saying
that
if
it
could,
if
the
originating
endpoint
you
know
right,
what's
a
ten-point
was
itself
a
mixer
and
put
it
in
the
header
in
the
first
place,
think
you
can
forward
it.
Okay,
I
think,
that's
all
that
saying
which
that
would
make
sense.
Oh,
ish,
ish.
G
We
do
have
some
systems
that
are
like
sort
of
hybrid,
but
I
agree
with
you
is
not
making
a
lot
of
sense.
I,
don't
think
problem
with
it.
That's
the
change.
I
may
give
some
thought
to
that
change.
It
may
be
that
change
is
complete,
gibber
ish
and
who
knows
what
we're
thinking
at
the
last
meeting,
I
fixed
more
than
a
few
typos
and
there's
basically,
no
other
issues
or
things
have
been
raised
since
since
really
about
eight
months
ago
on
this
one.
So
I
think
that
this
one
that's
where
it
is.
G
So,
let's
move
on
to
the
next
one
ekt,
where
there's
actually
a
lot
of
changes
happened.
So,
first
of
all,
like
huge
thanks
to
Russ
I
got
probably
like
one
of
the
best
reviews
I've
ever
gotten.
If
any
draft
it
was
like,
I
knew
what
to
do
with
them.
It's
very
concrete
I
went
through
with
them,
but
this
resulted
in
a
lot
of
changes.
Nick
slide
here
on.
G
So
a
couple
of
these
things
we're
fixing
fairly
small
things
or
are
being
able
to
deal
with
issues
like
how
you
know
which
direction
you
truncate
salt
information
on
the
big
change
was
moving.
Some
implicit
sizes
too
explicit
I'll
talk
more
about
that.
A
second
just
added
some
missing
things
like
I
animas,
like
Diana
tables
and
made
it
a
little
bit.
You
know
cleaned
up.
G
G
So
what
we
do
this
is
just
like.
You
know,
added
a
one-bite
length
header
onto
this
field.
It
makes
it
very
clear
and
simple
on
how
this
stuff
goes.
I
think
some
people
are
concerned
say
like
look.
We
don't
need
that
would
prefer
to
not
add
this
bite
that
there's
another
way
to
implicitly
figure
this
out.
G
My
feeling
is
that
this
bite
only
gets
added
to
the
EK
teeth,
long
message,
which
only
goes
in
some
of
our
RTP
packets
rights
when
we
put
in
periodically
and
it
expands
it
slightly,
and
it
just
reduces
the
number
of
ways
you
can
cause.
A
lot
of
confusion
probably
makes
this
much
easier
to
extend
later,
so
I
think
that
this
is
just
a
really
simplifying
change
at
a
very
low
cost.
So
I
think
that
you
know
this
was
the
biggest
open
issue
to
me
is
whether
we
want
to
keep
this
one
or
not.
G
B
D
G
G
And
that's
pretty
much
it
on
open
issues
of
this,
so
next
slide
on
this
one.
So
my
feeling
of
where
we
are
on
this
one
is
it's
ready
for
a
first
working
group.
Last
call
I
mean
there's
really
not
many
issues.
You
know,
there's
no
known
issues
open
with
it
right
now,
I
think.
If
people
go
through
and
read
it
carefully,
will,
maybe
people
will
decide?
No,
no,
no!
There's
some
really
big
issues
here.
Calling
your
nuts
many
people
inside
are
there's
some
small
things.
G
So
you
know
that
I
don't
know
any
other
things.
People
want
to
talk
about
with
the
with
these
two
decks,
but
I
mean
we're
at
a
fairly
low
energy
point.
I,
don't
think
we're
going
to
get
a
lot
of
I
think
that
this
is
the
right
step
to
get
to
the
next
level
of
review,
figure
out.
What's
done
and
move
this
stuff
on
it,
so.
E
G
Hi,
I'm
I'm
paul
jones,
I'm
here
to
talk
about
the
towel
wrap.
Actually
do
we
have
is
paul
remote
kinda.
He
wants
to
a
song,
okay,
good.
He
wants
to
be
available
for
this
and
I
might
have
to
lean
on
him
a
little
bit
for
the
final
slide.
Let's
go
and
get
started
so
there
were
a
few
small
changes
in
tunnel
this
time
around,
and
these
are
all
based
on
the
discussions
that
we
had
at
the
last
ITF,
where
we
switched
the
tunnel
transport
from
dtls
back
pls.
G
We
introduced
a
conference
identifier
field
and
that's
actually
thing
that
I
am
probably
going
to
lean
a
little
bit
on
Paul
to
help
describe
the
rationale,
and
then
we
switched
back
to
what
we
had
in
the
first
version
of
the
wrap,
which
was
a
TLS
style
syntax
for
describing
these,
as
opposed
to
sort
of
the
traditional
pluses
and
lines
with
fixed
fields.
Just
because
this
is
a
lot
easier
to
work
with
a
lot
easier
to
read
a
lot
easier
to
write
next.
G
So
we
probably
it
probably,
is
not
really
a
good
use
of
our
time
to
step
through
these
other
than
to
point
out
that
we
also
have
in
the
process
of
this
added
some
additional
message
types.
I
think
we
had
three
before
and
now
we
have
five.
We
added
specifically
a
error
message
for
indicating
that
the
versions
that
are
on
both
sides,
this
connection,
don't
match
and
that
we
need
to
do
something
to
recover.
G
Now
we
probably
do
want
to
engage
into
some
conversation
about
exactly
what
those
recovery
procedures
look
like,
because
it's
a
little
bit
weird
to
figure
out.
You
know
once
you
disconnect
and
reconnect,
or
what
have
you
exactly?
How
you
indicate
now
I
need
to
do
something
different
than
the
last
time,
so
we
succeed
and
we
also
have
an
endpoint
disconnect
message
that
the
mixer
uses.
Well,
the
media
distributor
uses
to
tell
the
key
distributor
that
someone
has
left.
You
need
to
rekey
things
like
I
said
we
probably
can
more
or
less
skip
through
these.
G
All
right
so
I
think
we
can
probably
just
scroll
through
very
quickly
the
next
four
or
five
slides.
That
sort
of
show.
Oh
wait
actually
this,
and
this
is
somewhat
illustrative.
It's
it's
the
new
diagram
of
the
document,
the
basis
points
out.
We
set
up
a
TLS
connection
and
then
the
media
tribute
is
going
to
say
here
the
profiles
of
support
you
can
use
as
part
of
the
dtls
establishment
with
endpoints
as
they
join
the
dtls.
The
handshakes
with
all
of
the
clients
proceed
as
normal.
G
They
are
encapsulated
in
these
tunnel
messages
between
the
media
distributor
and
the
key
distributor
with
a
couple
of
indications.
One
is
who
is
this
like?
Which
of
the
associations
that
we've
established
is
this
and
which
conferences
correspond
to
that's
the
conference,
ID
that
we've
added.
So
if
this
has
any
questions,
if
not
keep
going
syntax,
we
can
skip
this.
G
G
So
the
the
one
big
thing
that
we
probably
do
want
to
to
highlight
here
is
that
when
we
were
trying
to
work
through
some
of
the
information
flow
about
how
you
indicate
to
a
kmf,
what
conference
someone
should
be
in
like
which
keys
they
need
to
have
access
to
that
was
kind
of
missing
from
the
previous
protocols.
So
what
we've
added
here
is
an
explicit
indication
of
the
conference
ID.
Now
we
probably
need
to
talk
about
exactly
who
generate
these
who's
in
charge
of
them.
G
The
way
it's
laid
out
in
the
spec
right
now,
it's
as
as
people
join
the
key
distributor
basically
tells
the
media
distributor.
Oh
that
person
goes
in
this
conference,
but
I
think
until
we
actually
work
through
what
the
information
flows
are
with
things
like
sip
and
web
RTC.
It
might
not
be
obvious
whether
that's
exactly
the
right
direction
for
things
to
go
at
this
point,
I'm
actually
going
to
ask
Paul
to
put
himself
in
line
to
see
if
he
can
explain
this
final
slide,
11
issue.
E
A
J
Hello,
hello,
so
on
behalf
of
Paul
Jones,
so
the
the
different
alternatives
we
have
here
for
the
conference.
Id
basically
comes
down
to
the
question
of
how
and
who
needs
to
have
the
knowledge
about
the
conference.
Id
option
number
one
is
basically
that
when
we
set
up
a
conference
on
the
media
distributor,
we
tell
the
media
distributor.
This
is
conference
x.
These
are
the
participants
and
then
the
media
distributor
with
his
first
tunneled
DTLS
message
towards
the
kmf
can
basically
transfer
that
knowledge
over
to
the
key
management
function.
J
That's
option
number
one
option
number
two
on
the
table
is
basically
the
the
signaling
does
not
tell
the
media
distributor
anything
about
the
conference
ID.
It
just
tells
it
like.
I
want
to
create
a
new
conference,
and
this
participant
goes
into
that
conference
arm
and
go,
go
talk
to
this
K
MFPs
for
this
participant
and
then
once
the
the
kmf
has
basically
given
access
to
the
participant
once
it
sends
the
media
keys
back
to
the
to
the
media
distributor.
J
The
kmf
basically
says
like
here's,
the
conference
ID
for
this
participant
and
that
way
the
the
media
distributor
learns
which
conference
IDs,
which
participant
has
which
conference
ID
and
therefore
to
to
whom
to
forward
the
media
and
the
last
option
on
the
table
actually
to
go.
One
slide
back.
The
one
of
the
problems
with
the
with
the
approach
of
with
the
second
approach
is:
if
a
participant
wants
to
join
two
conference
calls
at
the
same
time
and
the
media
distributor
just
forwards,
the
the
dtls
packets
to
the
kmf.
J
So
if
we
make
the
requirement
that,
if
a
client
wants
to
join
two
conference
at
the
same
time,
he
has
to
use
two
different
certificates,
then
it
is
no
longer
a
problem
for
the
kmf
to
distinguish
these
two
different
conferences
for
the
same
participant.
So
if
we
make
that
requirement,
then
potentially
we
could
even
eliminate
the
whole
conference
ID
field
as
part
of
the
tunneling
message,
because
then
the
the
signaling
could
basically
go
and
say
to
the
media
distributor.
Here's
a
conference
x:
these
are
the
participants,
obviously
for
the
signaling
itself.
J
We
could
set
up
some
conference
ID,
but
it
doesn't
really
matter
and
then
you
do
the
same
thing
with
the
day
kmf.
You
also
signal
it
like
here's
the
conference.
These
are
the
participants
on
now
the
the
km
f
and
the
media
distributor.
Don't
need
to
talk
about
which
conference
this
is
about,
because
they
only
need
to
know
to
forward
which
details
packets
and
for
the
for
the
media
distributor.
He
cannot
forward
packets
to
the
actual
participants
and
unless
he
has
received
the
media
keys
for
the
participant.
J
So
that's
like
kind
of
the
I,
don't
know
stateless
option.
Basically
we're
like
the
the
video
distributor
and
the
key
management
function
both
have
a
knowledge
about
who
goes
into
which
conference,
but
they
don't
not
as
part
of
the
protocol.
They
don't
exchange
that
these
are
the
three
options.
I'm
I
guess
like
this,
probably
confusing,
no
matter
how
I
put
it
but
I.
G
G
J
J
J
Here,
though,
is
that
if
we,
if
we
don't
want
to
make
it
a
requirement
that
a
client
needs
to
use
two
distinct
certificates
to
be
able
to
join
to
conference,
at
the
same
time,
then
the
the
option,
with
no
conference
ID
on
the
table,
wouldn't
work
and
the
second
option
where
the
kmf
tells
that
the
mvd
would
also
not
work,
because
the
client
would
come
twice
to
the
mvd.
Both
was
the
same
DTS
fingerprint
because
he
only
uses
one
certificate
in
that
case.
J
Basically,
the
only
option
is
that
the
MDD
needs
to
signal
towards
the
km
f.
This
duty,
LS
connection,
is
for
conference
a
and
this
tunnel.
Dtls
message
is
for
conference,
be
so
I
guess
that's
the
the
main
question
is
whether
we
want
to
make
it
a
requirement
that
that
a
client
who
wants
to
participate
in
two
conference
at
the
same
time
that
he
needs
to
use
to
distinguish
certificates
or
whether
we
want
to
leave
it
open
to
to
reuse
an
existing
certificate
multiple
times
and
just
personally.
J
G
G
I
think
that
the
question
of
who
could
actually
be
given
the
really
the
only
people
who
can
really
authenticate
the
endpoint
is
probably
the
kmf
because
of
the
only
people
that
terminate
DTLS
connection
I.
Think
that
leaves
me
a
little
bit
like
wow
that,
whoever
no
matter
which
direction
this
flows
from
the
md
zoo,
the
KD
or
from
the
KD
to
the
md.
The
katy
has
to
verify
that
it's
correct
and
reject
the
connection.
G
If
it's
not
correct,
like
that's
the
important
part
to
me,
so
I
sort
of
want
to
provide
end
up
with
different
people
want
to
do
this
different
ways
and
we're
just
going
to
support
it,
blowing
both
both
directions
or
or
not
it
or
not,
used
at
all
like
I
guess
what
I'm
saying
is:
there's
a
force
option
of
do
all
three
of
the
above
and
don't
worry
about
it.
I
think
that
would
likely
make
this
work
take
significantly
longer
than
it
already
is.
Yes,.
J
Would
be
so
so
I
think
it
would
make
it
very
complicated
in
terms
to
express
all
the
different
options
on
the
table
for
an
implementer
regarding
the
the
concern,
whether
you,
whether
you
let
someone
into
a
conference
or
not,
I,
think
for
the
option
number
three.
Basically,
we
could
leverage,
basically
the
media
keys
as
the
the
token
of
authentication
from
the
kmf.
J
Basically,
if
the
video
distributor
sits
there
and
like
forward
like
some
tunnel
dtls
to
the
kmf
and
the
kmf
never
sent
him
back
like
media
keys
for
this
participant,
the
media
distributor
can't
do
anything
with
the
purpose
it
in
any
way.
He
like
he
will
receive
traffic
from
it,
but
he
like
he
can't
like
decrypted.
So.
E
Richard
burns
out
the
form
I
I
mean
I,
am
sort
of
inclined
as
usual
to
not
do.
Work
here,
like
I,
am
highly
in
agreement
with
Colin
I
think
when
you
take
sit
down
and
try
and
integrate
this
thing
into
a
real
conferencing
system
or
a
suite
of
real
conferencing
systems.
You're
going
to
have
different
answers
to
this.
How
do
we
assign
associations
to
conferences
in
different
scenarios,
but
I'm
not
sure
we
need
to
burden
this
protocol
with
all
of
that
complexity,
I
think.
E
As
long
as
these
two
participants
of
the
two
participants
in
this
protocol
that
kmfdm
d
can
v
can
state
clearly
what
conference
they
believe.
What
conference
of
what
association
they
believe
this
packets
belong
to?
They
can
arrange
those
conferences
and
associations.
However,
they
like
at
the
signaling
layer
and
this
protocol
can
just
do
do
its
thing
and
they
can
pass
things
back
and
forth
as
long
as
it
says
how
it
provides
an
anchor
for
the
signaling
to
talk
about.
E
So
my
inclination
here
is
just
to
have
everything
identified
as
conference
and
association,
probably
in
both
directions
and
not
really
do
anything
beyond
that.
I.
Don't
think
that
entails
a
I
guess
you
have
a
conference
I'd,
be
there
anyway,
so
I
don't
think
that
would
entail
the
the
requirement
that
Nils
stated
about
having
different
certificates
and
I.
Think
if
we
arrive
in
a
state
where
we
think
there's
a
requirement,
they
have
different
certificates.
We
should
engineer
our
way
out
of
that
state
because
that
it's
not
really
a
tenable
requirement.
G
So,
no,
no,
what
I
ki
sorry!
No
the
bit
that
I
was
going
to
preserve
was
that
because,
because
even
if
the
md
might
the
segment
base
going
to
be
broken,
MD
is
broken
right.
If
the
MD
decides
is
going
to
send
the
media
to
the
wrong
place,
then
your
conference
is
broken
anyway,
but
there's
no
security
problem
here,
because
the
key
won't
be
there.
G
Ok,
ok,
so
I
think
we
had
an
argument
against
you
against
option
3
of
using
certificates
and
against
every
option
under
the
sun
and
I
think
the
direction
Ronnie
proposed
actually
makes
the
most
sense.
To
me,
I
mean
I.
I
tried
to
pick
one
right
now.
I
would
say
like
let's
have
a
conference
ID
from
KD
to
md
and
and
if
somebody
comes
up
with
a
use
case
where
they
say
we
can't
solve
it
with
just
that
we
can
go
do
it,
but
it
just
all
falls
back
to
work.
G
That
sounds
approximately
correct
to
me.
So
one
of
the
things
that's
been
on
my
plate
and
pushed
under
a
different
pile
of
work
is
putting
together
something
to
talk
about
signaling
for
web
RTC
I'm,
not
trying
to
discourage
anyone
else
in
doing
that
account
as
cycles.
Please
grab
it
and
run,
but
I
think
that
once
we
start
that
exercise
it'll
be
a
little
bit
clearer.
G
E
All
right,
so
this
is
one
of
the
documents
we've
been
talking
about
for
a
while
that
we
have
not
formally
adopted
as
a
working
group
and
I
think
that
was
largely
because
we
there
was
some
thrash
in
terms
of
our
using
btls,
TLS
I.
Think,
judging
by
some
their
reactions
and
we've
gotten
here,
I
think
we've
kind
of
stabilized
and
TLS
of
course
occurs
not
here
to
disassemble
it
this
time
that.
G
E
L
Okay,
I'm
presenting
this
on
behalf
of
David
and
for
who
I
can't
be
here
at
the
meeting.
So
they've
asked
me
to
present
these
slides
for
them.
So
next
slide.
So
there
weren't
a
lot
of
changes
in
the
latest
version,
as
it
mentioned
there
they're
mainly
to
do
with
the
administrative
things.
There's
a
to-do
list
that
needed
to
be
addressed
and
as
mentioned
there,
that's
being
moved
to
github,
but
that's
a
bit
of
a
misnomer
because
there's
actually
nothing
in
github,
except
I,
think
Helen
put
something
in
about
four
hours
ago
or
side.
G
L
That
link
takes
you
to
that.
That's
not
even
on
this
draft
so
bicycle.
They
are
all
closed
off
and
they'll
be
discussed
in
later
slides
the
Security
section
that
was
emptying
the
last
version
and
to
solve
that
problem
would
change
the
title
to
up
text
from
attacks
on
perk
to
security
considerations.
Don't
address
next
slide.
L
L
Okay,
basically,
there
is
issue
with
the
conference
ID,
but
we've
just
discussed
that
previously,
so
we
basically
just
point
to
the
double
draft
giving
those
details,
so
that
will
be
need
to
be
reflected.
What
are
we
discussed
leading
to
the
trust
section?
We
basically
point
the
WebRTC
draft
and
the
list
of
headed
RTP
header
extensions.
L
E
L
E
E
So
the
question
is:
how
much
more
work
do
we
want
to
do
at
this
point?
We've
got
our
media
layer
kind
of
stable,
the
key
management
layer,
kind
of
stable,
and
the
next
thing
to
launch
into
would
be
the
signaling
layer
where
we
decide
how
we
arrange
such
a
conference
in
these
various
environments
and
sip
contexts
in
with
RTC
context
and
context,
and
so
at
this
point
I
just
kind
of
wanted
to,
since,
where
you
have
kind
of
the
media
layer
approaching
completion.
E
I
wanted
to
stop
and
take
a
look
at
what
our
energy
is.
What
our
implementer
interest
is
and
see
whether
we
want
to
now
proceed
to
launch
into
the
signaling
work
or
whether
we
want
to
try
and
close
out
these
media
Larry
documents
and
then
come
back
to
let
people
experiment
with
how
they
can
put
that
together
and
come
back
to
the
signaling
questions.
Later
so,
I
think
ya.
Could
I
solicit
any
feedback
from
implementers,
but
folks
in
the
group
about
what
we
are
interested
in
doing
at
this
point,
for.
G
A
full
perspective,
the
missus
Ida's
Adam
Roche-
and
this
is
kind
of
echoing
what
I
said
earlier-
I-
think
that
once
we
start
writing
down
how
the
information
needs
to
get
among
nodes
with
the
signaling,
we
may
learn
some
things
about
what
we've
done
here.
That
makes
that
more
difficult
than
necessary.
So
it
would
be
very
hesitant
to
put
this
front
of
the
iesg
and
then
have
to
go
away
that
didn't
work.
We
need
to
add
a
feel
to
remove
a
field
to
move
something
around.
G
So
I
think
we
probably
I
mean
these
are
in
pretty
good
shape,
go
ahead
and
say
we're
going
to
stop
working
on
these
for
now,
they're
just
gonna
sort
of
sit
there
until
we
have
a
good
shape
for
the
signaling.
We
don't
have
to
be
done,
but
you
know
just
good
data
flows,
a
notion
of
how
these
things
get
from
one
place
to
another,
and
then
we
can
go
ahead
and
start
calling
these
finish
once
we're
comfortable
they're
going
to
satisfy
the
needs
of
the
signaling,
that's
what
I
would
recommend
so.
E
G
G
There
are
some
decisions,
we're
going
to
have
to
make
around
things
like
ekt,
where
I
know
that
there
are
differing
opinions
about
whether
that
should
be
an
application-level
thing
or
something
that
actually
goes
inside
TLS
we're
going
to
want
to
nail
down,
but
we
definitely
it's
there's
interest.
We
don't
have
people
assigned
to
it
and
we'll
both
try
to
keep
pushing
it
forward.
As
we
can
I,
don't
know.
If
that's
the
answer,
you
want
that's
from
a
client
perspective.
What
I
would
love
is
if
there
were.
H
Hi
I'm
Shawn
Turner
I'm,
not
an
implementer,
so
take
it
for
what
that's
worth
I
think
you
should
just
drive
forth
and
try
to
get
this
stuff
done
so
I'll.
Take
the
opposite
of
approach
from
what
I
am
suggested
is
that
it
seems
like
an
art.
We
start
and
we
kind
of
do
some
things
with
that
sit
for
a
while
write,
a
bunch,
another
other
documents
and
they
all
kind
of
like
change
everything
and
we
never
get
done
so.
My
theory
is
just
drive
forth.
If
you
think
this
is
right,
that's
great
get
it
done.
H
G
G
G
One
thing
move
on
to
the
next,
even
if
that
puts
us
at
high
risk
of
needing
to
go
back
and
redo
something
and
I'm
willing
to
leave
the
things
we
think
are
done
sitting
on
a
shelf
waiting
to
confirm
that
they
actually
worked
like
we
hope
we
were
because
Adams
right,
we're
gonna
find
stuff
to
like
it
and
I'm.
Not
our
I.
Don't
disagree
with
your
overall
view.
G
Yeah,
but
I.
Don't
I,
don't
I,
don't
want
to
be
I.
Don't
want
to
have
just
everything
open
I
want
to
take
a
bunch
of
pieces
of
this
tent
and
pin
them
down
hard,
and
unless
it's
proven
that
we
need
to
move
those
pins.
Just
leave
them
pinned
down
as
much
as
we
can.
So
we
can.
We
move,
move
on
face,
I,
I!
Think
that's
what
I
proposed.
We
might
have
some
sort
of
disagreement
about
exactly
what
that
means
in
terms
of
like
I
ATF
document
state.
It's
aight,
I
mean,
are
you
proposing?
G
G
We're
gonna
run
to
this
five
digit
problem
pretty
soon
I.
I
don't
I'm
not
exactly
sure
where,
where
I
proposing
that
they
they
said
what
I'm
proposing.
Is
there
not
an
open
work
item
that
the
working
groups
dealing
with
and
that
means
they're
you
know,
sitting
with
the
with
the
chair,
is
waiting
to
do
a
pub
request
on
them.
I'm
perfectly
fine.
G
If
they
sit
there
something
else,
but
I
will
say
that
the
web
RTC
chairs
have
been
sending
everything
to
sit
in
the
RFC
editor
queue,
and
when
we
find
it's
wrong,
which
we
often
do,
we
can't
get
back
again.
It
may
not
be
the
best
principle,
but
you
can
let
this
stuff's
it
anyway.
I
didn't
want
to
comment
on
I
appreciate
your
perspective
on
this,
but
perk
is
nowhere
near
as
large
as
web.
Rtc.
E
E
M
Technically
I
guess
I,
am
it
really
to
me
comes
down
to
how
likely
you
think
it
is
to
need
to
do
short-term
changes?
Obviously,
there's
uncertainty.
There
I'll
take
the
working
groups
assessment
of
what
that
uncertainty
is,
if
you
think,
you're
going
to
have
to
pull
it
out
of
the
RF
theatre
too
few
or
you
think
you're
gonna
have
to
visit
visit
three
months
down
the
line
that
I
would
probably
rather
not
a,
but
if
you
think
this
is
what
we
you
know,
this
is
our
best
best.
We
can
do
right
now.
M
D
K
Not
even
I
didn't
hear
anyone
being
trying
to
volunteer
to
do
the
signaling
pot,
so
we
don't
have
a
choice
on
that.
On
the
other
hand,
I
think
it
would
be
good,
at
least
when
people
read
it,
you
awake
in
class
call.
They
should
see,
at
least
if
it
makes
sense
in
the
way
they
think
about
how
this
all
architecture
works
and
that's
published.
Should
we
should
say
when
we
do,
the
work
last
call
to
ask
the
people
also
to
look
at
that
also
yeah.
E
N
Cooper
yeah
I'm
just
agreeing
with
Ross.
I
think
I
like
to
think
about
this
in
terms
of
like
who
in
the
community
has
signed
up
to
do
what
and
so
like.
Generally
speaking,
the
IHG
has
signed
up
to
review
your
document
once
so.
You
don't
really
want
to
send
it
back
to
them
and
kind
of
the
same
thing.
Variety
of
last
call
like
most
documents.
N
If
they
don't
receive
a
lot
of
feedback
in
the
first
round,
they
don't
get
multiple
ITF
last
calls
and
we
shouldn't
like
bird
in
the
whole
community
with
having
to
review
something
twice,
whereas
the
working
group
normative
chairs
have
signed
up
for
more
than
that,
and
so
you
know
for
you
to
do
to
you,
know,
declare
consensus
and
ride
right,
pub,
rock
and
send
it
to
Ben
and
and
for
him
to
value
you
ate
it
and
then
have
it
sit
there.
If
you
end
up
on
you
back,
and
you
have
to
do
that
again.
I
H
G
Actually,
that
was
what
I
came
to
talk
about
is
that
I
think,
on
draft
by
draft
basis,
they're-
probably
a
very
different
decision
she
made
here.
I
think
you
know
we
can
probably
feel
pretty
confident
the
framework
we
can
probably
feel
pretty
good
about
double
e
katie
needs
more
work
in
the
working
group
because
we
have
like
I
said.
Unfortunately,
Ecker
is
not
here,
but
he.
G
E
G
Higher
layers,
that
was
a
point
that
I
was
making
is
that
the
the
defect
with
ekt
is
isolated.
It's
going
to
be,
you
know
how
do
we
want
ekt
to
work
in
general
and
know
what
the
documents
going
to
modify
that
tunnel
I
think
has
to
wait
on
the
protocol
document.
The
signaling
documents
to
be
further
along,
which
is
to
say,
exists.
E
G
So
AI
mean
if
you,
if
you
want
me
to
pay
the
property
tax
for
this
thing,
to
sit
inside
perk
for
a
few
more
months,
I'm
happy
to
do
that.
I
mean
the
prospect
that
you're
worried
about
having
one
additional
document
sitting
there.
You
know
missing
milestones
from
time
to
time
seems
little
academic
well.
G
G
E
Yeah
for,
for
example,
like
if
I
think
in
some
of
the
scenarios
at
least
I've
seen
mooted
from
the
endpoints
point
of
view,
the
signaling
looks
pretty
much
like
standard
SD
p,
except
you're,
going
to
negotiate
double
and
Dewey
que
te
on
the
wire.
So,
if
you
have
this,
you
can
implement
an
endpoint.
They
can
imprint
interoperate
with
all
sorts
of
conferences.
However,
you
do
this
signaling
as
long
as
you
have.
That
kind
of
you
know
standardization
property,
so
that
you
know
you
can
make
some
progress
with
just
this
document.
Sup.
F
G
A
I
G
Think
I
think
the
two
of
us
in
a
copy
editor
will
get
together
and
and
try
to
come
up
with
something
that
works
here.
Do
you
think
we
can
have
something
for
Chicago
yeah?
It's
realistic,
ok,
so
I'm!
Sorry
we're
going
to
throw
something
in
the
middle
of
this
working.
If
it's
going
to
cause
you
to
continue
to
do
work
as
a
chair,
but
I
believe
that
we
have
just
committed
to
having
something
at
least
in
either
sip
or
WebRTC,
probably
web
RTC
for
the
signaling.
K
Ronnie,
what
I
heard
from
Colin
I
mean
it's
not
from
colin.
Is
that
the
one
that
we
need
I
mean
the
two
things
that
we
need
to
clarify
the
first.
This
is
how
do
how
do
the
endpoint
know
that
it
has
to
do
this
double
double
scription
and
the
other
thing
is
how
how
the
MK
f
and
the
media
distribution
connect
to
each
other
and
learn
about
each
other.
I,
don't
think
it's
complicated,
but
I,
don't
think
you
can
have
a
solution
without
having
this
this
title.
K
E
L
E
So
maybe
like
the
three
or
four
you
guys
could
be
able
get
something
started
there.
So
yeah
so
of
saying,
I
think
I'm
hearing
coalescence
around
a
plan
of
roughly
the
following
form.
We
can
take
the
e
Katie,
double
and
framework
drafts
and
start
progressing
them
on
ekt
may
be
lagging
a
little
bit
behind,
but
start
getting
those
last
called
and
into
the
queue.
K
Yeah
I
think
I
think
ability
because
you're
going
to
cost
to
reviewers
any
on
all
documents,
not
also
on
the
tunnel.
So
whether
you
call
it
working
group
last
call
as
a
reviewer
do
review
prayer
working
class
call
I,
don't
think
it
makes
much
different.
You
can
do
it
a
new
class
call
on
all
of
them.
If
you
want
I
mean
it's
the
same
thing,
because
you
know
we
need
to
reviews
now.
Yeah.
A
E
Those
are
all
going
to
progress
more
or
less
we'll,
probably
go
ahead
and
start
pushing
ekt
double
and
framework
through
the
iesg
process.
Once
we've
gotten
done
with
working
group
stuff
and
tunnel,
we
will
leave
open
pending
signaling
discussion,
Thank
You
mo,
so
we
have
four
drafts:
we're
looking
for
reviewers.
Let's
start
with
E
Katie
could
I
have
a
couple
of
viewers
for
ekt
Sean
you're
in
the
front
row
and
your
TLS,
confident
person
and
Russ
sort
of
you
too
good
great
thanks,
guys.
E
E
E
Yeah,
roughly
it
in
that
brief
period
of
work
time
in
December,
so
yeah
I
think
that's
about
all.
We
have
for
today,
I
look
forward
to
seeing
what
the
signaling
geniuses
come
up
with
again,
don't
leave
it
until
Chicago.
If
you
make
some
progress
earlier,
maybe
I
will
even
schedule
a
virtual
interim
in
january
or
so
it's
a
inspire
progress
and
I
think
with
that
we
are
at
the
end
of
our
agenda,
any
other
business
for
now.