►
From YouTube: IETF103-RTCWEB-20181108-1610
Description
RTCWEB meeting session at IETF103
2018/11/08 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
A
At
least
I
know
the
minute
taker
will
know
what
all
the
acronyms
mean.
That's
always
nice.
The
blue
sheets
are
already
circulating.
If
you
have
not
already
seen
a
blue
sheet,
please
find
one
as
it
passes
you
and
add
your
name
and
affiliation
some
reminders.
When
you
come
up
to
the
microphone,
please
remember
to
state
your
name,
or
at
least
a
plausible
pseudonym
or
alias.
A
Please
keep
it
professional
at
the
mic.
I
realized
that
here
in
the
late
stages
of
our
TC
web,
with
no
video
codecs
in
front
of
us
we're
we're
pretty
much
mellowed
out,
but
please
should
tempers
flare,
take
a
step
back.
Remember
you
get
to
enjoy
Bangkok
without
another
working
group
meeting
in
front
of
you
and
keep
it
professional
at
the
mics.
A
A
B
A
Carefully,
indeed,
please
do,
however,
remember
that
you,
by
participating
either
by
Jabbar
by
mideco
or
here
in
the
room.
You
agree
to
be
bound
by
the
IAF's
policies,
as
they
relate
to
ITF
to
IPR
working
group
process,
the
anti-harassment
procedures,
the
code
of
conduct,
our
copyrights
and
especially
our
willingness
to
just
work
together
and
a
consensus
driven
way.
A
This
is
our
agenda
for
today,
at
ministry
via
this
is
the
part
year
in
now.
We
have
30
minutes
480
comments
on
the
security,
security
architecture
and
IP
handling
drafts.
We
have
some
slides
on
those,
but
we
also
have
the
relevant
ad
in
the
room
to
answer
questions.
There'll
be
20
minutes
to
go
over
the
jsf
changes
and
20
minutes
for
the
mdns
candidates
discussion.
Is
there
any
bashing
to
the
agenda.
D
B
A
The
the
the
chairs
have
decided
that
what
that's
really
called
for
were
two
presents
to
him:
one.
This
nice
forecast,
blended
whiskey,
which
represents
his
his
presence
through
the
buff
through
the
the
craziness
of
building
JSF
through
a
long
video,
codec
discussion
and
now
the
mellow
age
of
RTC
web.
We
thank
you
very
much
and
we
present
you
with
this
I
look.
A
A
Nose
presents
with
hints
of
Pete
within
a
framework
of
juicy
red
apples,
cherry
jam,
dried
apricot
and
soft
vanilla.
The
width
of
new
make
emerges
after
a
while
relatively
acceptable
with
what
smells
like
a
fair
bit
of
higher
alcohols
and
tales
from
a
distilling
run
on
the
palate.
The
spirit
takes
on
a
gelatinous
texture
and
then
the
flaws
emerged.
The
acrid
burn
of
alcohol
seems
very
much
neutral,
like
a
cheap
vodka,
and
that
is
stringent
bitterness
lingers
into
the
finish
with
the
taste
of
chemicals
and
nail
polish
remover.
A
D
G
D
D
They
they
went
a
little
bit
beyond
editorial,
so
the
reberty
security
and
IP
handling
graphs
are
ready
to
go
modulo
updating
to
ice.
This
one
of
those
has
already
been
updated,
I
presume
the
other
one
will
be
fairly
soon
and
then
the
security
arch
document
is
the
one
that
has
some
ambiguities.
That
I
think
we
need
to
clear
up
before
we
put
it
in
diet
Skol.
D
So
the
first
issue
that
I
came
across
is
the
behavior.
When
you
have
an
invalid
identity,
an
initial
answer
all
right
now
the
text-based
EDA
says
do
what
you
do
when
you
have
an
invalid
offer.
The
answer
to
that
is
you
you
reject
the
offer,
but
you
can't
really
reject
answer
is
not
the
way
that
most
of
the
state
machines
work.
D
So
what
I'm
proposing
here
is
that
we
adjust
the
language
to
say
that
the
session
is
torn
down
if
the
identity,
verification
in
an
initial
answer
fails,
I
see
a
thumbs
up,
I
see
no
one
coming
up
to
microphone
going
once
going
twice.
I
think
we
like
this
answer.
Yes,
you
too,
so
invalid
identity
and
an
updated
offers.
Is
you
have
a
session
going
on?
Someone
sends
you
a
new
offer.
It
has
a
new
identity
that
it
nd
fails.
Now,
in
theory,
we
have
a
few
different
options
for
handling
this.
We
could.
D
We
could
reject
the
offer,
keep
the
session
up
and
going
and
any
of
the
requested
changes
to
the
session.
Just
don't
happen.
We
could
terminate
the
session
by
accepting
the
offer
and
then
sending
something
to
to
tear
down
the
session,
or
we
could
explicitly
leave
it
up
to
the
application.
My
suggestion
is
that
we
just
explicitly
say
that
we're
going
to
tear
down
the
session
under
these
circumstances,
something
is
obviously
fishy
going
on,
and
none
of
those
circumstances
is
better
to
not
have
the
session
continue
happy.
F
I
That
we
say
explicitly
already
is
that
you
have,
if
you
have
identity
or
you
have
an
expectation
of
having
an
identity
than
this
is
a
terminal
condition.
But
we
don't
say
anything
about
the
case
where
you
don't
have
identity
pre-existing
and
you
update
the
session
and
there's
an
attempt
made
to
add
identity.
So.
D
I
I
D
D
So
the
third
issue
is
an
invalid
and
being
updated
answer
right.
So
here
we've
got
session
going
on.
We
send
an
offer.
You
get
back.
An
answer
has
a
change
that
Indian
that
fails.
I,
don't
think,
there's
really
much
choice
here,
other
than
to
terminate
the
session
there
I
mean
we
could
theoretically
design
some
pretty
fancy
stuff.
If
we
wanted
to
add
more
complications
to
JSF,
we
do
not
want
to
add
more
complications
to
J's
up,
so
I
would
propose
that
we
just
make
the
text
explicit
that
this
terminates
the
session.
I
I
D
G
F
D
D
He's
right,
functionally
I
wasn't
thinking
from
the
API
perspective
from
an
API
perspective.
What
happens
here
is
that
you
try
to
set
the
remote
description
and
that's
just
gonna
fail
and
at
that
point
it's
up
to
the
the
web
app
to
figure
out
what
to
do,
whether
you
tear
down
the
session
or
or
try
to
recover
or
just
go
on
right.
I
And
and
the
web
RTC
specifications
are
structured
in
a
way
that
if
you
fail
to
set
up
a
remote
description,
you
essentially
wind
back
to
the
previous
state
that
you
had
or
you
remain
in
that
state
you
never.
You
never
advance
the
state
machine
forward
as
a
result
of
a
failure
in
that
in
that
attempt
right,
okay
right!
So
if
you,
if
you're
in
the
PRN
so
state,
then
you
remain
there
and
so
on
and
so
forth.
B
I
So
Krista
you
and
I,
we
talked
about
this
one
right
and
the
decision
that
we
had
was
that
it's
sort
of
the
STP
description
layer
of
things
we
would.
We
would
say
that
what
the
application
does
in
that
in
that
context
will
depend
on
its
own
logic.
The
WebRTC
specification
very
clearly
says:
if
you
had
identity
and
then
you
suddenly
have
none,
then
that's
a
fatal
condition
and
you.
D
A
B
F
I
think
maybe
I'm
confused
here,
but
why
answer
so
if
I
get
an
answer,
that's
okay
and
so
right.
So
my
point
is:
why
is
update
I
think
updated
processing
should
be
the
same
as
it's
our
processing.
So
that's
exactly.
The
text
I
have
here,
which
is
to
say,
is
the
same
as
in
for
processing,
namely
if
it's
an
offer
you
rejected.
If
it's
an
answer,
you
turn
of
a
session.
D
K
The
problem
is,
if
you,
if
you
then
roll
back
to
the
latest
date,
well,
I
mean
then
then,
basically,
everything
with
ID
handling
identity
handling
is
different
from
the
rest
of
whatever
I
see
right.
Where
like.
If
you
reject
an
answer
or
or
an
offer,
you
basically
stay
in
the
last
stable
state.
So
then
we
would
have
to
explain
that
in
this
case
you
actually
terminate
the
whole
peer
connection.
L
Allah
Allah
Allah
strong
and
the
WebRTC
documents
are
trying
to
specify
the
same
state
machine
as
this
document,
which
means
that
we
have
a
synchronization
problem
when
the
state
machine
is
in,
have
local
offer
and
you
receive
an
answer
and
that
answer
cannot
be
accepted.
The
state
machine
if
they
took
if
the
stuff
is
total
garbage
STP
or
have
any
other
area
that
causes
it
to
not
wash
the
state
machine
remains
in,
have
local
offer.
L
M
D
So
it
occurs
to
me:
I'm
thinking
through
this
part
of
the
problem
is
I.
Think
the
fact
that
we're
trying
to
use
a
structure
based
on
32
64,
where
the
32
64
handling
for
JSF,
is
up
in
the
JavaScript
application,
and
we
can't
really
constrain
that
in
this
specification.
Right
I
think
we
probably
want
to
do
is
take
five
one,
four
or
five
six
and
no
sorry,
five,
one
four
and
five
one
five
collapse
them
into
a
single
section.
That
basically
says
if
an
identity
shows
up
that
cannot
be
validated.
D
K
D
I
I
Target
peer
identity
differs
from
the
one
that
we
get.
We
close
the
peer
connection,
okay,
see
anytime,
that's
the
only
way
in
which
that
that
happens.
The
other
thing
is
if
we
fell
it
at
the
end,
we
we
validate
the
identity
in
parallel
to
applying
the
the
remote
description
and
so
that
my
description
can
be
applied
yeah.
C
D
I
When
we're
in
the
process
of
turning
off
taillights,
1,
0
and
1
1,
this
is
tail
s11
that
we're
talking
about
right
here.
I
would
suggest
that
we
mandate
DTLS,
1,
2
and
don't
say
anything
about
the
rest
of
them
and
maybe
point
maybe
if
you
like,
we
can
point
to
the
deprecation
thing,
but
everyone
supports
1,
2
now
and
I,
don't
see
any
problem
with
actually
making
that
a
must
so.
F
F
And
then
assume
that
when
bla
bla
bla
is
like
is
like
standardized,
it
can
update
this
document
today
that,
when
dot
the
die
died
over
his
deprecated
is
that
over
Africa
is
published.
It
can
update
our
document
as
every
other
document
like
as
well
of
well
as
every
other
document
which
site
which
size
details
one
out.
The
the
other
option
is
to
independently
deprecated
one
L
in
this
back
right.
D
F
Sure,
I
guess
what
I'm
saying
is
like
that
we
could
that
we
could.
We
could
mandate,
no
one,
oh
right,
like
ourselves
without
reference
to
this
letter
document
that
difference
the
old
versions,
that
I
document
and
or
we
could
not
mean
that
not
Oregon
or
you
could
not
forbid
one,
oh
and
then,
and
then
when
died
when
all
verses
deprecated
is
published,
it
can
update
this
this
document,
as
it's
like
updating
every
other
document
that
has
like
one
o
in
it
like
it's.
F
D
P
P
Unfortunately,
there
are
fortunes
of
builds
that
are
very
old
and
I.
My
concern
would
be
that
turning
off
that
this
would
effectively
turn
off
that
large,
the
law,
the
world's
largest
provider
of
web
RTC
on
services,
I,
think
people
know
who
I'm
talking
about
I,
don't
want
to
mention
the
name
now
that
some
might
consider
that
to
be
a
good
thing,
but
I
just
want
to
put
that
out
there
I
don't
know
if
maybe
other
people
know
whether
they've
upgraded
to
one
too
but
I.
That
wasn't
the
case
as
last
time.
I
I
D
Colonies,
1
4,
so
it's
not
confused
two
different
issues,
which
is
what's
the
MTI
from
what's
deprecated
right
and
from
updating
our
Mt
eyes.
I
could
certainly
imagine
moving
forward
from
1.0,
but
given
everyone's
been
relying
on
1.0,
first
I
don't,
and
there
are
several
large
deployments
that
are
1.0
based
right.
Not
just
one
I
would
not
just
casually
do
that
at
the
very
last
minute
now,
I
wouldn't
mind.
D
F
D
F
Keep
going
and
we'll
do
it
so
I
was
trying
to
take
it
so
like
there
right
now,
there's
two
levees
there's
a
muster
one!
Oh
and
I
should
one
to
my
proposal
right
now.
I'm
just
saying
is
anybody
object
to
changing
the
11.2
to
must
and
then
we
can
talk
in
a
second
about
how
we
handle
them,
that
the
must
one-up
like
they
may
not
think
we
should
require
1.2.
F
We'll
have
to
confirm
it
on
the
list,
but
I
don't
see
an
objection
so
so,
okay,
so
now,
let's
bring
ourselves
to
the
1.0
issue
on
there
are
a.
There
are
a
number
of
implementations
as
Colin
brown
just
I
wish
the
1.0
on.
There
are
two
things
we
could
do.
I
think
we.
We
obviously
would
like
to
do
so.
So
one
thing
we
could
do
is
we
could
actually
discourage
them
from
doing
so.
F
In
sum,
well,
three
things
we
could
we
could
leave
it
like
it
is
you
have
to
do
one
out
we
could
we
could
actively
discourage
them
in
some
in
some
way,
whether
sure-sure
or
must,
and
then
we
could
just
say
nothing
and
I
guess
the
question
like
I
think
my
preference
will
be
just
saying,
I,
think
kind
of
that
entire
clause
and
my
question
is
we're
already
calling
live
with
that.
So.
A
F
F
Q
F
D
Colin
James,
no,
obviously
I
think
we
should
encourage
people.
Do
1.2,
no
question
about
it.
I
just
feel
that
we
have
this
habit
of
wishing
people
would
be
to
do
ipv6,
so
we
deprecated
ipv4
and
it
doesn't
mean
they're
going
to
move
from
4
to
6
right,
and
this
is
a
we
have
old
codecs
in
here
that
we
have
for
equate.
We
say
we
should
use
g.711
support
in
this,
even
though
we
wish
people
would
use
opus.
We
have
you
know,
like
I,
think
on
some
of
this
stuff.
D
D
:,
but
that's
so,
but
I,
don't
think
we
should
just
go
and
deliver
it
unless
there's
a
good
reason
to
break
stuff
I
think
we
should
ask
what
gives
us
maximal
compatibility
and,
yes,
everyone
should
use
the
latest
best
thing,
no
question
about
that.
It
would
be
best,
but
I
don't
see
a
really
good
reason
for
deprecating
the
older
ones
right
now.
So
if
we
just
remained
silent
on
the
point,
would
that
be
good
enough.
D
Honestly,
I,
don't
think
it
really
matters
in
the
slightest
what
any
of
the
spec
stay
at
this
point,
because
the
browser
is
what
the
browser's
going
to
implement
is
no
longer
irrelevant,
relatively
impacted
by
the
specs,
because
we
do
stuff
like
this
right.
So
question
is:
what
will
the
browser's
do
and
I
think
that,
given
what
the
large
deployments
are
going
to
do,
which
will
not
be
to
move
as
quickly
as
the
old
version
deprecated
wishes,
they
would
move
for
a
bunch
of
good
reasons
right,
which
and
we're
not
gonna
debate.
D
The
station
the
question
like
whether
we're
going
to
have
any
statement
about
whether
you
may
should
must
have
met
one.
Oh,
it's
pretty
unfortunate,
III
guess
it's
I,
obviously
think
we
should
do
the
must
on
one
too
I
think
it's
a
little
bit
unfortunate
to
be
removing
this
right
at
this
point
in
time,
but
maybe
I
can
live
with
that.
A
P
Some
of
these
large
deployments
have
been
very
slow
to
update,
on
other
grounds
as
an
example.
As
far
as
I
know,
they've,
not
even
supporting
ECDSA
yet,
which
has
created
all
kinds
of
complications
in
you
know
requiring,
for
example,
offering
both
RSA
and
AC
DSA
and
lots
of
other
stuff
like
that.
So
in
some
ways
the
statement
of
RFC
7525
is
stronger
than
sorry
in
old
versions.
That's
stronger
than
anything
any
individual
spec
could
do.
P
Basically
by
my
thing
that
you
know
this
whole
thing
is
on
its
way
out
in
every
use,
so
I
guess
what
I'm
saying
is
that
I
think
I'm
probably
agree
with
that
Kerr
to
say
nothing
and
let
individual
browser
vendors
decide
whether
they're
gonna
pull
the
plug.
I
can
say
it's
not
an
easy
decision,
because,
given
how
big
some
of
these
people
are,
if
you
pull
a
plug
you'll,
see
large
changes
in
browser
market
share
immediately.
I
I
For
the
time
being
in
the
back
there,
I
guess
even
the
foreseeable
future
will
will
retain
the
ability
to
do
detail
s1.
Just
we
have
the
ability
to
do
g.711
and
all
of
those
other
terrible
things
that
we
wish,
perhaps
that
we
didn't
have
to,
but
we'll
do
it
anyway
and
we'll
only
pull
it
out
at
the
time
that
we
think
that
that's
safe
to
do,
and
that
will
mean
very
small
proportion
or
traffic
will
we'll
be
using
it.
So
I
don't
think
it's
a
big
deal
means.
F
Don't
like
I've
got
an
eye
color
problem,
the
I
think
so
I
feel
like.
There
are
two
competing
values
in
tension
here
on
the
the
the
one
when
competing
value
is
that
we
would
like
to
encourage
people
to
do
the
thing
that
we'd
like
them
to
do,
which
is
to
move
to
one
too
and
I.
Think
that
and
at
some
level
to
say
before
no
but
on
the
third
really
want
to
do
is
encourage
me,
be
the
one
to
so
that
that
is
achieved
by
saying
must.
Must
you
want
to
the
second
value?
F
Is
we
would
like
to
tell
people
what
the
what
the
requirements
are
for
in
our
ability,
like
as
a
puzzle,
matters
life
that
works
properly?
Well,
not
well
I.
So
what
I
suggest
is
a
slightly
slightly
modified
variant.
What
I
said
previously,
which
is
that
we
require
one
put
two,
and
we
say
you
know
previous
versions,
the
specification
effectively
previous
verses
specification.
Previous
deployments
had
to
fat,
had
1.0
as
a
requirement
and
as
a
practical
matter
for
the
time
of
this
writing
for
maximum
compatibility.
You
need
to
do
like
no
motive
tax.
F
Like
only
just
advice
you
need
to
do,
you
need
to
do
1.0
with
the
following
set
for
sweet
or
you
have
or
you
have
the
poor
gonna
have
deployment
problems.
So
I
think
that
that
that
that
splits,
the
difference
between
like
like
and
we're
not
gonna,
say
you
shouldn't
do
in
point.
Oh,
that's
gonna
come
like
in
six
months,
but
we're
gonna
say
like
it's
a
practical
matter
right
now.
A
A
A
If
you
would
prefer
to
say
nothing
hum
now,
if
you
would
prefer
to
give
a
deployment
advice
hum
now,
all
right
we'll
confirm
it
on
the
list,
but
that
seemed
relatively
straightforward.
I
heard
no
one
for
the
first
position,
one
hum
on
Java
or
and
say
nothing:
ok,
so
not
unanimous!
That
I
still
think
a
pretty
strong
rough
consensus
for
including
the
implementation
advice
as
jests.
A
D
Thanks,
let's
see
this,
one
should
be
pretty
easy,
because
I
think
the
answer
is
kind
of
obvious,
but
so
the
section
eight
one
says
that
the
domain
portion
of
an
identity
is
an
ID
n
and
points
to
RFC
5890.
But
5890
has
two
different
encoding
z',
you
have
a
labels.
I
have
an
example
here
of
an
a
label
and
then
an
example
here
of
a
you
label
of
exactly
the
same
name.
D
D
Okay,
if
mine
is
mine,
is
more
matter
of
this
seems
easier
to
debug
it
literally
just
driven
by
if
I
pull
a
string
out
of
you
know
like
the
JavaScript
console,
and
it
renders
is
the
second
thing
instead
of
the
first,
that
makes
my
life
easier,
but
that's
a
pretty
weak
argument.
So,
if
you
have
the
rationale
for
a
labels,
I'd
love
to
hear
it.
A
So
the
pinna
code
and
coding
does
more
than
just
an
ACM
ASCII
compatible
encoding.
It
also
gets
rid
of
PEEP
invalid
characters
and
other
things
where,
if
you
do
the
a
label,
you
are
pretty
much
guaranteed
that
it
has
passed
through
the
entirety
of
pinna
code
and
therefore
is
only
P
valid
characters.
So
I
would
personally
suggest
the
a
label
on
that.
A
D
D
A
D
I
Okay,
someone
told
so
long
I'm
not
entirely
against
what
Ted
suggests
here,
but
I
would
note
that
we're
just
we're
just
comparing
these
against
existing
domain
names
that
existing
labels
that
we
get
from
loading
resources.
So
maybe
maybe
the
concern
is
less
in
that
context,
I'm
not
going
to
throw
my
cell
phone
right
on
a
pyre
over.
I
D
L
A
L
Then
we
should
just
use
that
there
are
lots
of
trouble
with
allowing
me
random
unicode,
including
right-left
labels,
my
favorite.
But
if
you
require
that
it's
a
you
label,
then
you
require
that
it's
you
label
anyway.
So
anything
it's
changed
in
there
and
there
I
DNA
processing
is
not
not
a
valid
you
label,
but
it's
a
slight
preference.
Well.
D
L
L
J
A
A
F
A
Given
that
we
seem
to
have
reached
a
point
where
there
are
a
couple
of
people
expressing
mild
preferences,
but
not
a
long
mic
line,
I'm
going
to
beg
the
intelligence,
the
room
to
get
to
a
little
bit
more
humming.
If
you
were
one
of
those
people
who
raised
your
hand
that
you
understand
it
enough
to
be
afraid
of
it
and.
D
A
B
A
D
I
C
A
D
D
The
coffee-
and
this
is
going
into
ITF
last
call
I-
might
make
a
point
of
just
highlighting
this.
For
people
who
have
you
know
internationalization
experience,
you
just
really
want
to
cause
yourself
that
much
pain
well
or
if
we
think
there's
a
bad
idea.
I
can
pass
on
that.
We'll
talk
offline.
Incidentally,
this
is
the
this
is
the
website
for
the
th
neck
information
page.
If
you're
interested.
D
G
D
So
it's
my
suggestion
here
is
in
order
to
allow
user
agents
to
actually
unescape
this
and
display
it
in
a
reasonable
fashion
that
we
go
ahead
and
say:
yes,
we
specifically
mean
the
euro.
Our
percent
escaping
as
specified
in
the
HTTP
document,
cite
it
and
go
on
from.
There
say
you
must
escape
at.
You
must
have
8%.
I
Not
in
Thompson
I've
thought
about
this
a
lot.
Unfortunately-
and
this
is
not
that
simple
part
of
the
problem
we
have
here
is
this-
this
issue
of
confuse
ability,
and
one
of
the
things
that
we
have
here,
is
the
ability
for
a
particular
origin
or
particular
domain
to
make
assertions
about
the
identity
of
individuals
and
the
way
that
we
have
structured.
This
is
that
that
domain
has
complete
control
over
their
their
namespace
and
if
they
can
put
an
ad
in
that,
then
example.com
can
make
an
assertion
about
Adam
at
Nostrum,
comm
and
that's
confusing.
I
D
D
I
D
So
in
terms
of
that,
what
I
would
propose
is,
if
we
add
some
guidance
along
the
lines
of
making
clear
that
the
domain,
it's
the
you
know,
Firefox
comm
is
saying
this
is
Adam
at
Nostrum
com
I
think
that's,
not
a
difficult
semantic
to
convey
I
may
be
a
little
naive
about,
but
it
seems
that
freezing
it
that
way
effectively.
However,
you
want
to
render
that
in
new
UX.
We
clarify
things
in
the
way.
It
is
not
as
hostile
and
wouldn't
make
people
wonder
like
what
is
this
gobbledygook
I'm
like
boss,
Oh?
I
I
D
F
D
A
D
A
D
F
T
We
just
can
we
actually
just
start
the
ITF
last
call
and
note
that
this
is
an
outstanding
issue
and
we
have
a
pull
request
on
it.
More
yeah
I
think
you
can
I
feel
like
if
we
have
ones
that
we're
stuck
on
I
think
we
can
do
that
to
narrow
it
down.
Maybe
we'll
get
some
great
input
from
them
from
somebody
outside
of
the
solve
the
problem.
I'd
rather
high.
D
D
U
D
A
D
Bernard,
do
you
have
an
art
if
you're
in
line
come
back,
please,
if
not
yeah?
If
he
gets
in
line,
we
can
pop
back
to
this.
Alright,
so
I
think
that's
that's
everything.
I
do
planned
all
the
documents
involved
and
have
been
updated
for
ice
and
I
need.
The
updates
for
this
document
to
finish.
I
really
want
these
to
go
into
ITF
last
call
looking
as
much
as
possible
like
we
want
them
to
look
in
the
final
form,
and
then
these
are
all
gonna
go
into.
D
F
D
V
D
So
film
James,
here
speaking,
is
one
of
the
co-authors
and
I'll
drag
a
car
up
right
early
too.
So
we've
got
a
few
changes
that
we
just
wanted
to
review
with
people
on
some
of
these
drops,
so
one
of
them
is
across
the
board.
All
of
the
ice
references
have
been
moved
to
point
at
84
45,
instead
of
50
to
45.
If
you
missed
the
discussion
on
the
list
on
this,
then
you
probably
didn't
care
enough.
If
you've
got
any
objections
to
this
now
leap
to
the
microphone.
D
L
I
have
argued
about
this
subject
for
a
long
time.
I
have
computed
that
the
working
group
has
reached
a
conclusion.
I
don't
agree
with,
but
I
have
confused
that
the
working
groups
are
definitely
reach
a
conclusion.
So
my
only
question
in
this
matter
is:
should
we
update
the
msid
draft
to
actually
allows
keeping
the
Heidi.
L
L
D
L
D
You
the
context
back
into
the
chain.
W3C
had
this
problem
with
removed
track,
add
track.
So
we,
a
large
argument,
happened
there.
The
current
summarizing
the
working
group
chair
behind
there.
They
have
consensus
to
room
to
change
to
remove
this.
We've
got
a
PR
to
update
that
in
jasa,
which
is
trivial.
It's
what
we're
discussing
here,
what
we
thought
we
were
discussing
here
and
then
Herald
pointed
out
the
issue
that
the
msid
spec
is
in
conceived
to
be
changed
to
be
consistent
with
all
of
these
okay.
A
R
U
O
D
D
F
P
P
K
T
G
F
He's
like
really
long
when
the
answer
selects
to
offer
a
tagged
and
section.
It
first
checks
this
gesture
to
offer
a
tagged
M
section.
There
are
much
check
with
M
secures
and
falsifying
criteria,
one.
The
answer
will
not
move
the
end
section
out
of
the
bundle
or
group
2.
The
answer
will
not
reject
the
M
section
and
three,
the
M
sections
that
contain
AZ
report
value
if
all
the
criteria
fulfilled
blah
blah
blah.
If
one
or
more
the
return
also
fulfilled.
F
G
I
have
to
say
I'm
a
little
I
haven't
read
this
issue
in
at
least
I.
Think
the
question:
if
you
have
a
multiple,
multiple
tagged,
M
lines
in
in
the
offer
I
mean
you
have
multiple,
which
are
not
bundle
only
if
you
don't
accept
the
first
one
you
can
accept
it
either
one
because
that
will
also
have
transport
parameters,
but
the
thing
is
even
in
your
in
your
bundle
group,
if
you
only
have
one
M
line
weight
with
transport
parameters
and
everyone
else
is,
you
know,
bundle
only
in
that
case.
G
F
G
S
F
B
R
F
Mean
so
I
mean,
what's
a
month,
my
like
renewing
with
the
Texas
like,
like
the
the
weight,
the
way
that,
like
the
the
way,
the
bundle
is
supposed
to
work
is
that
ever
is
that
for
all
the
non
bundle,
only
like
M
sections
have
to
complain
have
to
complaint,
contain
complete
parameters,
because
otherwise,
because
you
don't
have
their
side
supports,
bundle
at
all
right
and
it's
clearly
the
case
that
I
can
simply
object.
Bond
won't
take
any
and
take
any
proper
subset
or
any
subset
of
others.
F
You
obviously
have
to
keep
the
bundle
tag,
one
or
you're
screwed,
but
I.
Don't
understand
why
you
would
not
be
able,
if
you
have
two
sections,
a
and
B
a
B
and
C
two
that
we're
all
there
already
dependent
be
validated,
why
you
could
not
throw
away
a
and
take
B
and
C
and
keep
the
bundled
I
think
way.
You
just
said
it
actually
replicates
what
I
think
the
intent
was
here.
A
If
you
throw
away
the
first
one
where
you
had
the
offer
tagged
and
the
rest
are
bundle
only
this.
This
is
a
polite
or
pr4,
saying
you're
screwed
right,
because
you
have
no
transport
parameters
and
and
no
way
to
go
forward
because
you've
rejected
the
only
thing
that
enabled
you
to
go
forward
with
all
of
them.
Now.
I
agree
that
if
you,
if
you
were
doing
something
where
you
then
had
other
m
sections
that
had
transport
parameters,
then
you
could
go
forward.
But
that's
not
what
this
is
talking.
F
But
but
I
mean
I
perhaps
but
like,
but
the
key
distinction
is
bundled
versus
bundle
only
and
so,
and
so
if
things
are
merely
bundled,
then
you
can
accept
any
subset.
You
wish,
if
some
of
them,
but
if
they
are
bundle
only
then
I
mean
like
you
month.
Your
order
set
the
bundle
group.
There
must
be
at
least
one
M
section
that
does
not
bundle
only
or
your
script,
and
so
the
problem
is
that
this
text
appears
to
apply.
F
D
F
L
Hollow
this
film
and
we'll
sorry,
I
was
trying
to
read
this
again
and
I
think.
But
the
reason
why
a
7-3
one
are
73
are
consistent
is
that
71
is
actually
about
how
you
pick,
which
section
is
the
offeror
target
section
which
is
kinda
weird
that
the
answer
fixed,
which
is
the
offeror
type
section?
And
suddenly
she
says:
okay,
if
you
pick
them
off
for
taxation
and
you're,
going
to
reject
you're.
A
F
That's
what
Christopher
nodding
when
I
was
talking
so
I
think
Krista
and
I
agree
what's
supposed
to
happen
and
things
no
matter
of
fixing
it.
So
it
says
that
I
only
spent
like
30
seconds
reading
it
so
I'm,
not
one
I.
Don't
want
to
push
in
that
point,
but
I
think
we
agree
on
the
behavior
then,
when
they
just
put
to
exhibit
well.
A
A
L
T
T
A
F
F
So
this
this
issue
comes
out
of
a
lot
of
my
complaining
about
some
other
document
which
I
can't
remember.
This
is
at
this
point
that
oh
I,
remember,
BF,
CP
and
so
so
so
be
FCP.
Right,
Adam
will
probably
be
awake
here
now
in
a
second
like
they,
basically
that
they
had.
It
was
like
older
ice,
where
you're
supposed
to
actually
attempt
to
match
the
proto
field
to
like
in
subsequent
offers
to
see
what
you
de
go.
F
She
ate
it
and
but
JSF
just
like
says,
always
always
always
use
blah
blah
blah
UDP,
TLS,
blah
blah
right
and
yeah.
Okay,
so
just
actually
just
actually
gets.
This
gets
us
right.
The
documents
just
look
through
issues
wrong
and
so
on,
and
so
we
and
so
the
this
is
the
conflict
right
here
between
basically
on
say
you
negotiated
is
TCP.
P
F
F
My
recollection,
we
already
note
that,
but
we
are
overriding
perhaps
but
anyway.
So
if
everyone
agrees
that
the
JSF
behavior
ought
to
be
like
never
change
it,
then
we
can
make
sure
that,
like
the
spec
says,
never
change
it
and
I
can
see.
If
we
do,
if
we
do
say
it
to
sip
SDP
we're
writing
it.
If
we
don't
like
exams
now
one
would
argue:
is
you
fix
SGP
as
well,
but,
like
I
don't
want
to
get
into
that
at
the
moment?
Is
he
you
know
discussing.
F
A
T
K
The
problem
is
that
there
are
two
fields:
the
session
and
diversion
the
session
is
the
one
which
should
be
to
to
to
the
63,
because
it
never
increments.
It's
just
like
a
stable,
unique
identifier,
whereas
the
version
is
2
to
262
to
leave
it
enough
room
so
that
when
we
renegotiate
the
number
can
increment
and
does
not
overflow.
Ok,
some
of
the
text
in
the
spec
seems
to
have
copied
the
text
relevant
for
the
version
number
into
the
session.
Can
you
produce
a
PR?
S
P
L
It
would
be
nice
to
delete
the
text
in
Jessup
that
says
that
we
can't
include
the
information
about
what
the
were
that
when
we
receive
the
text
in
place.
That
currently
seems
to
say
that
when
they
receive
an
of
an
offer,
that
of
that
offer
cannot
include
information
about
what
simulcasts,
the
or
Ferrari
is
going
to
accept.
That
seems
a
bit
silly
I,
just
like
the
Dreaming
silly
I.
D
Mean
I
really
I
think
we
explicitly
agreed
that
you
know
MCU,
controlled
bridges
would
be
able
to
send
an
offer
that
did
similar.
That
cause
similar
has
to
happen.
Even
though
we
couldn't
do
simulcast
fully
from
the
browser
and
version
100.
Is
that
match
your
recollection,
Harold,
so
I
think
this
text
I,
don't
know
what
this
text
exactly
is
but
seems
like
it's
wrong.
It's
there.
The.
L
A
A
A
A
A
H
So
that's
why
we
ended
up
with
trying
to
use
mdns
instead
of
IP
addresses
so
back
in
Montreal,
we
presented
the
idea,
and
we
decided
then
at
the
time
to
split
the
work
in
several
parts.
So
basically
IP
handling,
v1
stable,
is
not
changing
anything
ambi
NSA's
candidates,
if
basically
just
defining
the
technique,
use
mdns
and
that's
what
we
will
talk
about
in
this
presentation
and
IP
handling
with
you
in
the
future
might
actually
integrate
new
modes
to
update
IP
handling
v1
to
use
VN
dns
ice
techniques
wherever
useful,
so
I
can
link.
H
We
want
no
change
except
to
that
to
improve
the
description
of
this
issue
and
mention
the
possibility
that
in
the
future
something
will
happen.
Maybe
new
modes:
let's,
let's
see
okay,
so
yep,
so
that
the
spec
the
gate
is
on
even
github,
so
anyone
is
free
to
file
issues
and
and
so
on.
Okay,
so
the
techniques
is
basically
two
parts.
One
is
you
generate
candidates,
but
Mike
using
DNS
and
the
other
part
is
to
receive
candidates,
but
might
also
be
ambience
paste.
H
So,
let's
start
my
generation,
so
you
a
nice
agent,
you
generate
hosts
high
score
date.
Just
before
going
to
the
GS
level.
You
ask
use
yourself.
The
question
should
I
conceal
from
DNS
this
host
candidate.
There
might
be
a
good
reason
to
not
do
that.
For
instance,
you
know
that
the
IP
address
is
public
or
you
know
that
getusermedia
prompt
is
actually
has
been
clicked
by
the
user.
So
you
think
that
privacy
is
gone
anyway,
so
whatever,
but
maybe
you
think
that
there's
still
some
nice
tease
about
canceling,
concealing
IP
friendliness.
H
So
in
that
case
you
generate
basically
a
UI
Evo
version
for
enviousness
name,
your
register
v,
endianness
name,
and
once
done,
you
are
actually
exploiting
with
us
hostage
candidate
in
the
case
that
so
you
will
not,
of
course,
register
DNS
name
for
every
host
eyes
candidate.
It's
only
where,
whenever
useful
that
you
will
generate.
X
S
X
X
H
That's
a
very
good
question.
In
fact:
I
don't
mean
anything
except
that
maybe
you
realize
when
you
generate
it,
the
UID
that
you
don't
have
any
interface,
that
except
multicast.
So
then
you
will
say
whoops
sorry,
so
you
will
skip
it
in
general.
What
will
happen
is
that
you
will
generate
the
UID,
expose
it
and
if
generation.
H
Okay,
so
when
to
use
and
yell
for
us
candidates
and
will
not
use
it,
basically,
we
talk
about
getusermedia,
but
there's
also
the
case
of
public
IP
addresses
it's
difficult
to
know
whether
an
IP
address
it's
public
or
not,
but
you
can
use
ipv4
ipv6
turn
servers
for
that
purpose.
So
what
can
happen
in
practice?
Is
that
no
matter
whether
the
address
is
public
or
not,
if
you
do
not
know
it,
you
actually
send
VM
DNS
candidate,
it's
it's
fine
and
later
on.
H
K
K
D
H
G
G
G
H
Y
H
So
in
what
if
it
may
be
issue
yeah,
it
should
be
masked.
The
thing
is
that
in
a
browser,
it
makes
sense
to
do
masked,
but
this
technique
might
be
used
by
something
else.
Like
some,
you
have
an
endpoint,
but
actually
just
want
to
obfuscate
the
network
topology
and
that's
all
and
invite
just
want
to
use
exact
again
and
again,
the
endianness
name,
no
matter
privacy
or
tracking.
So
it's
really
a
browser
issue.
There.
S
S
Y
S
G
A
H
D
So
the
color
change-
this
is
just
a
question
about
my
ignorance
about
mdns,
so
I'm
thinking
about
in
networks
where
you
have
relays
and
wireless
devices
they're
cashing
these
responses
and
things.
How
quickly
can
you
delete
these
names?
I
mean
how
I
mean
we're
claiming
here
we
need
these
guy.
We
tell
you.
X
Do
it
again
so
asking
me
privately
earlier
how
quickly
this
can
be
done
normally
when
a
device
advertises
a
new
name
on
the
network,
and
you
can
do
this
with
the
command
line
tool,
TNS
SD,
on
the
max
or
with
Windows.
If
you
install
Bonjour
for
Windows,
when
you
advertise
a
new
name,
it
will
send
three
queries
a
quarter
of
a
second
apart
to
verify
that
that
name
is
not
already
in
use
and
then,
if
it
doesn't
get
a
reply,
it
will
then
begin
using
it.
H
We
have
a
slide
about
connection
setup,
latent
subjects,
to
measure
this
there's
some
work
potential
workarounds
another
option
which
has
be
to
say:
hey.
We
think
it's
UUID
that
is
automatically
generated,
so
there
should
be
no
conflict,
so
we
plan
to
actually
use
it
and
and
broadcast,
like
maybe
bypass
this
mechanism,
so.
X
That's
right,
the
other
option
is,
you
can
skip
the
checking
for
uniqueness
but
you're
taking
the
risk
there,
especially
if
you're
using
host
names,
it's
unlikely,
but
at
least
in
principle.
Anybody
in
this
room
could
have
picked
that
as
their
host
name
and
then
you
go
and
stomp
all
over
them
yeah.
We
hope.
X
Oh
I
agree:
it's
statistically
very
unlikely.
The
other
option
you
could
use
is
to
use
a
different
record
type
or
use
an
SRV
record,
because
you're
not
expecting
anybody
to
ssh
to
this
host
name.
You're,
not
expecting
anybody
to
use
this
as
a
host
name
in
any
normal
context.
Right,
you
have
your
own
software.
That'll
do
the
query,
so
you
could
move
all
of
this
off
in
two
consecutive,
it's
own
namespace,
where
it
can't
conflict
with
anything
else,
and
that
was
actually
my
earlier
question.
X
G
G
X
X
I
D
I
So
that
sounds
like
a
pretty
good
suggestion:
I'm
gonna
go
back
to
the
the
question
of
scope
and
make
a
recommendation.
There
I
think
we
want
a
must
and
I
think
we
want
a
must
based
on
communication
peer,
so
in
the
general
set
in
the
general
case,
we
we
would
want
to
have
different
identities
for
different
peers.
So
if
you
think
about
the
case
where,
where
you're
talking
about
the
SIP
setup,
that's
using
this,
for
instance,
if
I'm
making
a
call
to
Ted
or
making
a
call
to
Shawn.
H
I
N
H
I
H
I
I'm
gonna
go
a
little
further
than
that,
and
there
are.
There
are
two
entities
in
this
situation
that
you
care
about,
potentially
providing
unlink
ability
for
one
is
the
one
that's
doing
the
signaling,
which
is
the
web
application
or
sip
signaling
servers
whatnot.
The
other
is
your
communication
peer
and
your
communication
peer
will
see
your
SDP
and
the
web.
App
won't
be
able
to
mask
your
identity
from
your
communication
peers.
If
this
identity
is
is
linkable.
Q
T
M
H
H
I
X
X
Something
very
similar,
which
is
the
reason
it
announces,
is
because
of
the
race
condition.
If
the
query
happens
first
and
then
half
a
second
later,
you
register
it.
Then
the
gratuitous
announcement
goes
and
the
query
says:
oh
that's
the
answer.
I
was
looking
for.
If,
if
it
right,
if
you
can
ensure
that
you've
generated
the
name
and
registered
before
you
pass
it
to
the
pier,
then
you
avoid
that
race
condition.
So
that's
something
that
we
could
consider
adding
to
the
API.
D
H
G
D
I
mean
I
think
that
I
think
we
I
think
we
need
to
do
the
analysis
to
figure
out
whether
or
whatever
rate
limits
we're
going
to
put
in
or
going
to
actually
work
and
I.
Think
that
the
MDS
doc
would
you
know,
specs
were
probably
designed
with
rate
limits
where
people
who
are
not
thinking
about
hostile,
drive-by
pages
being
able
to
create
these
and
we're
changing
that
so
I
think
we
should
just
I'm
not
saying
this
a
problem.
I
just
said
from
the
beginning.
R
H
G
H
L
I
D
S
The
worst
one
of
the
things
we
wanted
to
allow
is
that
the
application
can
actually
pre-allocate
me
and
of
mdns
notes,
just
keep
a
bucket
of
them,
and
then,
when
you
need
them,
you
you
start
using
them
so,
rather
than
creating
them
and
destroying
them.
On
every
clear
connection,
we
wanted
to
leave
that
up
to
the
you.
D
H
G
F
Do
is
on
a
Spanish
to
peerconnection
I,
pull
one
one
dye
sample
by
commas
and
appear
condition
to
get
this
process
going.
Then
I
said
that
I
set
window
a
location,
it's
a
tutorial
like
a
girl
and
I.
Just
keep
going
like
like
I
I
mean
I,
don't
know
like.
Maybe
this
is
fixable
but
like
I
feel
like
I
feel
like
like.
This
is
like
lipstick.
Her
is
hard,
and
if
these
are
real
threats,
then
we
have
Lake
deal
with
them
and,
like
a
that,
requires
probably
more
thinking
about
this
than
link.
T
I
H
Okay,
let's
keep
this
one.
Given
time,
can
you
resolution
you
might
have
seen
it's
roughly
the
same,
you
receive
a
remote
ice
candidate.
Should
it
be
resolved
for
mdns.
You
just
look
at
whether
it's
a
blood
alcohol,
then
either
you
do
the
normal
processing
or
you
resolve
mdns
name.
If,
yes,
this
is
not
successful,
then
you
skip
it.
Otherwise,
you
replace
the
immunised
name
might
be
a
progress
and
you
continue
a
regular
flow,
so
nothing
very
special
there.
H
There
was
one
question
in
Montreal
about
multiple
IPS
for
a
single
analyst
named
and
Dana's
name
if
we
may
late
to
actually
go
through
only
UUID
version
for
host
candidate
and
meanest
candidate
that
actually
generated
as
per
spec.
It's
not
an
issue
in
case
there's
more
than
several
address.
We
prefer
to
pick
whatever
single
address.
It
is
because
it's
the
simplest
way
to
actually
tie
this
implementation
with
authorized
implementation.
L
H
H
H
This
might
actually
create
some
issues
if
we
actually
expose
that
through
getstats,
which
is
an
API
for
from
the
briefly
seen.
So
we
decided
to
not
expose
prefix
if
candidates
addressed
in
we're
at
his
stats,
and
this
would
help
this
proposal
and
in
general,
it's
it's
good
to
as
long
as
you
do
not
know
whether
the
other
guy
wants
to
expose
the
IP
address,
it
should
not
be
exposed.
So
that's
where
we
went
and
the
working
group
on
the
girl.
She
is
okay
with
that
turn
server
eight
leakage.
H
Again.
If
you
register
on
any
Ana's
name,
you
send
it
to
your
party.
Your
party
resolve
the
immunised
name
to
an
IP
address
and
then
it
will
try
to
match
this
IP
address
to
return
server
and
it
will
actually
need
to
leak.
This
IP
address
to
a
transfer
in
practice.
It's
not
really
useful
because,
usually
you
do
not
want
to
tie
house
candidates
with
turn
candidates,
so
we
believe
that
we
should
just
say
no
don't
use
an
remote
mdns
candidate.
We
to
allocate
real
a
candidate
pairs,
just
use
server,
reflexive
or
over
host
candidates.
H
We
should
have
no
impact
on
connectivity.
We
believe
network
interface
enumeration.
If
you
have
six
in
faces,
then
you
might
have
six
eyes
candidates.
It
might
be
a
fingerprinting
issue
if
we
limit
that
to
default
hood
candidates,
as
is
currently
in
the
draft,
then
it's
it's
fine,
because
browsers
websites
can
already
identify
whether
you
have
ipv4
IP
before
ipv6
or
ipv4
and
ipv6.
So
our
proposal
is
every
time
we
validate
this
technique
and
that
we
go
forward
on
it.
H
Then
we
will
try
to
check
whether
we
go
expand
this
technique
to
non-default
hood
and
Venus
candidates,
and
we
will
probably
need
to
identify
mitigations
where
mdns
message
flirting
interesting.
I
guess
we
can
skip
s1m,
DNS
name
the
denial.
Of
course
you
might
have
an
endpoint
in
the
network.
That
is
not
very
cooperative,
so
in
that
case
sure
and
Eunice
might
fail.
That's
right.
H
We
think
that
it's
part
of
using
mdns,
so
it's
outside
of
the
scope
of
this
document-
radius,
connectivity,
yeah.
This
is
something
that
is
true.
We
want
to
gather
experimental
data
if
we
are,
if
you're
going
to
from
a
world
where
you
using
I,
all
I
PR,
assist
you
using
mdns,
then
in
some
cases
like
big
networks,
you
might
not
be
able
to
actually
get
a
connectivity
or
you
will
only
get
connectivity
for
turn
which
has
its
own
drawbacks.
H
X
I
yeah
some
I'll
be
very
quick.
Its
RFC
sixty
seven
sixty
one,
two
three
sixty
two,
its
IETF
standard,
it's
recorded
in
the
yarn
especially
used
to
my
name,
is
registry
and
I
was
going
to
make
a
comment
on
this
that
the
wording
I
would
not
use
that
wording.
Networks
don't
have
to
support
mdns
MBS
uses
multicast
a
piece
of
wire
supports,
multicast,
it's
it's,
so
networks
may
choose
to
block
it.
I
mean.
D
Adam
wrote
I
just
wanted
to
make
an
observation
about
the
suggestion
that
we
gather
experimental
data
to
assess
how
how
bad
this
issue
is.
This
issue
is
predominantly
going
to
arise
in
enterprise
environments
and
I
know,
at
least
for
Firefox.
A
lot
of
enterprises
choose
to
turn
off
the
lemon
tree,
and
so
they
are
vastly
underrepresented
in
the
data
that
we
collect
so
I'm,
not
sure.
That's
particularly
feasible.
K
The
until
my
on
the
default
Road
I
believe
we
actually
have
changed
it
so
that
it
says
the
default
route
is
equal
to
the
road
from
where
you
fetched
the
webpage.
So
you
will
not
end
up
with
like
one
mdns,
but
you
will
end
up
with
n
ND
messes
/,
where
you
fetch
your
web
pages
from
which
usually
shouldn't
be
that
high.
But
who
knows
the
other
one
is
the
the
idea
of
the
pre-war
ring
of
with
like
gathering
m
dns
names
beforehand.
K
Don't
do
that
when
you
actually
advertise
the
network
right,
because
then
you
are
actually
like
making
the
problem
worse,
because
then
I
only
need
to
create
peer
connections
to
start
flooding
the
network
before
it
actually
even
starts
gathering.
So
that
only
works.
If
we
do
go
down
the
route
of
like
doing
empty
nests
without
advertising
I
mean
only
then
it
helps.
D
Countries
I
I,
just
think
that
we
should
do
about
this
flooding
analysis
and
the
timing
that
stuff
that
we
should
figure
out
some
of
that
data,
at
least
since
it's
a
sort
of
network
safety
issue
before
we
start
experimenting
on
large
corporate
networks.
You
know
I
mean
I,
know
it's
great
sound,
let's
just
examine,
but
this
is
a
congestion
control
issue
right.
That's
you
guys.
H
F
D
H
X
One
thing
maybe
I'm
not
understanding
something
but
I'm,
not
sure
why
you'll
consider
about
picking
one
address,
because
every
mac
in
this
room
has
a
dot
local
host
name
that
names
all
of
its
addresses
on
all
of
its
interfaces.
So
you
only
have
to
pass
one
name
to
the
peer
that's
connecting
and
when
it
resolves
it,
whether
it's
on
whatever
interface
it's
on,
it
will
look
up
and
another
quick
point
on
the
announcing
topic.
X
If
you
create
a
random
name
and
advertise
it
and
then
pass
that
to
the
peer,
if
it's
announced
by
multicast
on
the
local
network,
all
the
peers
will
opportunity
opportunistically
cache
that
so
by
the
time
the
peer
comes
to
do
the
query
it's
already
in
the
cache
and
that
becomes
a
zero
milliseconds.
Zero
around
free
pay.
I
already
have
the
answer
so
for
the
people
of
counting
the
milliseconds
for
the
connection
setup
time,
you
should
already
be
in
the
cache
by
the
time
the
query:
how.
S
A
We
are
four
minutes
over
time,
but
I
have
one
last
thing
to
say:
we
would
like
to
close
this
working
group,
so
we
thank
everybody.
Who's
already
generated
the
PR
as
we
discussed
today.
We
encourage
the
rest
of
you
who
signed
up
to
produce
PRS
to
produce
them
expeditiously
so
that
we
can
get
through.
A
We
remind
you,
however,
that
cluster
238
is
one
big
hairy
ball
of
documents,
so
the
working
group
will
have
a
bit
of
a
wait
until
everything
emerges
as
RFC,
but
please,
let's
push
it
on
to
Heather's
plate
as
fast
as
we
can.
Your
chairs,
both
the
stepping
down
Collin
Jennings,
the
Shawn
Turner,
who
had
to
come
late
and
leave
early
and
myself.
Thank
you
for
your
attendance
assistance
and
consensus.
So.
F
J
A
Okay,
so
the
short
answer
is
no,
because
Ben
wants
to
hit
me
we'll
discuss
offline
where
it
belongs,
but
this
working
group
definitely
cares
about
the
result,
so
the
working
group
mailing
list
should
be
kept
in
apprised
of
new
versions,
etc.
Even
if
we
move
it,
this
has
been
the
reason
for
the
wanting.