►
From YouTube: IETF106-QUIC-20191119-1000
Description
QUIC meeting session at IETF106
2019/11/19 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
Okay,
let's
get
started
Ben,
I'm,
sorry
or
engineer,
it'll
work
out.
Okay,
this
is
quick
I'm.
One
of
your
chairs
mark,
Nottingham
Lars,
couldn't
make
it
here
this
week
and
he
may
join
us
remotely,
but
I'm
not
I,
don't
see
him
yet
it
is
quite
early
for
him.
Yes,
this
is
the
note.
Well,
hopefully,
you're
familiar
with
it.
This
is
the
terms
under
which
we
participate
in
the
ITF,
because
you
know
you're
taking
a
picture
of
the
note
well
that
thank
you
good,
especially
regarding
not
only
intellectual
property,
but
also
especially
our
behavior.
A
As
we
engage
in
these
discussions,
we
need
to
make
sure
we
treat
each
other
with
respect.
So
we
have
a
code
of
conduct.
We
have
anti-harassment
procedures.
We
also
have
various
structures,
the
ITF,
to
make
sure
this
is
followed
and
give
people
help
if
they
need
it.
So,
if
you
have
any
concerns,
please
talk
to
myself
Lars
next
time,
perhaps
or
other
ITF
leadership.
A
Blue
sheets
are
circulating,
please
sign
those
as
they
come
by
you.
There,
blue
Brian
has
so
graciously
offered
to
scribe
for
us.
Thank
you.
Brian
your
cane
and
dkg
is
jabber
scribing
I.
Just
checked
the
bridge
between
jabber
and
slack
is
not
functioning
terribly
well
right
now,
so
don't
assume
that
what
you
say
and
select
will
be
seen
in
jabber
and
vice
versa.
So
let's
just
use
jabber
for
now,
since
that's
what
everybody's
familiar
with
I.
B
A
No
idea
why
you
would
be
not
hearing
me.
Yes,
the
agenda
today
we're
going
to
talk
briefly
about
the
hackathon,
give
people
update
of
where
that
got
us,
and
then
we're
just
going
to
talk
about
issues.
We've
gotten
to
the
point.
Where
are
our
issues
that
we
have
opened
are
relatively
few
and
so
we're
just
gonna
turn
through
the
issues
list.
I
will
continue
that
on
Thursday
and
end
up
with
some
presentations
on
drafts
that
we
are
might
consider
adopting
regarding
extensions
one
on
datagrams
and
one
on
load.
A
D
E
E
E
Okay,
it's
one
of
the
key
decision,
points
that
we're
we're
making
here,
and
so,
if
we
don't
resolve
that
before
we
ship
version
one
as
I
hope,
we
do
very
soon
we're
in
a
bit
of
an
awkward
situation,
so
understanding
where
we're
going
with
version
negotiation,
even
if
we
don't
have
a
fixed
date
for
that,
is
that
probably
the
best
thing?
No.
A
G
Martin
Martin
Duke,
so
this
is
the
quick
version
ossification
in
the
scope
of
the
issue:
discussion
or
version
negotiation
issues;
okay,
thanks:
okay,.
A
Anything
else
any
other
agenda,
bashes.
Okay,
a
real
quick
note.
We
now
have
an
HTTP
3
logo
I.
We
may
be
the
first
ITF
working
group
with
two
logos,
so
that's
exciting.
We
have
stickers
that
have
been
graciously
created
for
us,
so
I'll
be
giving
those
out
after
the
session,
if
you're
interested,
they're,
very
small
stickers.
A
A
G
Can
you
call
it
the
matrix,
if
not
doesn't
really
matter
so
I
think
we
had
seven
clients
in
eleven
servers
participating?
It
was
worse
than
usual
participation,
wise
I,
think
part
of
it
was
just
attendance
at
Singapore
and
part
of
it
was
a
draft
24
dropped
a
couple
weeks
ago
and
I
want
to
say
there
may
be
three
or
four
teams
that
were
not
ready
to
go
other
than
that
I
think
draft
24
is
fairly
Interop
was
fairly
successful,
the
same
things
are
continuing
and
that
the
basic
protocol
functionality
is
in
pretty
good
shape.
H
I
J
A
Actually,
while
we're
talking
about
more
general
things,
one
more
reminder:
we
have
a
an
interim
meeting
scheduled
in
early
February
in
Zurich,
so
that
was
announced
on
the
list.
If
you
haven't
registered
for
that,
you
want
to
come.
Please
do
so
soon,
so
we
can
plan
to
make
sure
we
have
the
right
facilities
available,
any
other
discussion
on
hackathon,
okay.
A
So
on
two
issues,
let's
start
with
the
transport
and
TLS
issues
and
as
you
can
see,
we
have
a
few
issues
in
triage,
we'll
touch
on
those
in
a
little
while
the
editors
have
27
issues
that
they
still
need
to
address.
I.
Think
last
time
we
looked
at
this
was
about
39
or
so
so
they're,
making
some
progress
and
design
issues.
We
have
12
left
here
that
we've
decided
our
design
issues.
So
let's
go
ahead
and
go
through
those
first
up
issue:
2792.
A
K
It
feel
free
to
write
me
anytime,
Martin,
if
I'm
sorry,
which
normally
normally
is
key
phase
1.
Thank
you
now
so
on.
If
it's
a
valid
key
phase,
1
packet
you're
supposed
to
you,
know
you're
supposed
to
basically
on
help
get
your
honky
right.
But
if
it's
an
invalid
keep
it.
K
You
know,
fact
that
you
know
they
don't
have
to
be
shut
the
ball,
and
so
the
on
the
observation
here
is,
if
I
understand
correctly
that,
because
the
on
key
phase
bits
themselves
are
not
a
a
deed
prior
to
packet,
decryption
that
that
is
to
say,
there's
not
an
independent
zone
integrity
check
for
the
key
phase.
Then
an
attacker
can
flip
that
bit
and
thus
causes
you
to
do
whatever
processing
you
would
have
done
for
the
new
packet
and
then
use
a
washer.
K
This
is
bogus
because
that,
because
it
is
under
integrity,
checking
you
drop
it
right
and
the
so
I'm
so
far,
so
good,
Martin
right
and
so
as
I
understand
it.
The
there
is
some
theory
that,
given
implementation
strategies
for
doing
this,
an
attacker
might
be
able
to
probe
what
key
phase
you
are
in,
because,
if
you,
if
you
so
this
point,
part
right,
it's
all
complicated.
K
But
if
you
compute
the
new
keys
only
at
the
time
when
you're
the
parent
key
phase
change
the
attacker
regularly
measure
the
time
that
you
do
that
in
some
unspecified
fashion.
The
again
I
think
this
is
all
relative
of
consensus.
I
have
not
like
seen
like
a
really
clear
definition
of
how
this
would
work,
but
on
the
specification
then
says
in
order
to
print
this,
you
want
to
like
pre-compute.
Thank
you,
a
bunch
of
keys
on
a
particular
schedule.
So
the
like,
you
won't
have
this
happen.
K
This
is
the
proton
complaining
about
I.
Just
like
this
should
to
be
a
May
and
I
will
shut
up.
E
So
just
to
expand
on
that
I
think,
because
summary
was
good
the
dirt.
The
draft
currently
says
should
do
that
and
echo
is
arguing
for
a
May
I.
Don't
care
on
this
particular
one.
The
the
point
here
was
to
make
sure
that
it
was
understood
what
the
properties
of
the
system
were
and
that
the
mitigation
was
also
understood,
and
the
cost
of
that
were
understood
and
I
think
that
it
may
is
perfectly
adequate.
E
In
this
case,
I've
noted
that
a
couple
of
people
just
simply
generate
the
new
keys
in
line
when
they're
doing
this
processing
and
just
accept
the
fact
that
that
creates
a
potential
time
inside
channel
and
that's
fine
and
the
question
is
whether
we
recommend
that
they
don't
do
that
or
whether
they
we
just
say,
if
you're
concerned
about
this,
then
you
might
want
to
do
this
and
that's
really
the
line
we're
sitting
on
so
so
echo.
Your
proposal
is
just.
E
Anyone
object
to
that
process.
I
will
create
a
PR
when
I
sit
back
down
so
there's
there's
a
there's:
a
should
recommending
around
recommending
pre
generation
of
the
next
phase
of
keys
so
that
you
don't
lick
this
signal,
and
so
this
will
simply
make
this
a
may
and
I
think
it's
appropriate
because
a
lot
of
the
other
aspects
of
this
very
much
advisory.
So
that's
consistent
with
that.
There's
no
Interop
effect
for
this.
This
is
a
security
question.
E
Well,
Mike
Bishop
asks
off
mic
use
their
entry
any
interrupt
consequences.
Therefore,
why
do
we
use
2119
language
I?
Think
the
answer
there
is
generally
that
we
do
that
for
a
lot
of
security
related
things.
Yes,
so
it's
appropriate
to
do
that,
but
I
think
the
the
general
feeling
is
that
people
are
comfortable
to
varying
extents
with
this
side
channel
and
should
be
making
their
own
decisions.
Okay,.
I
A
K
F
K
Later
discussion
has
has
called
that
question,
and
it's
now
we
complicated
so
the
the
thesis
I
think
the
there
so
I
think
there
are
so
I
want
to
make
to
I
like
to
points.
The
first
point
is
this
looks
like
it's
gonna
be
kind
of
easy,
and
now
it's
looking
like
a
lot
less
easy
on
that
may
be
requirements
creep,
but
I
think
it's
also
like
scope
like
like
creeper,
understand
the
problem
better.
The-
and
the
second
point
is
that
I
did
the
tunt.
K
That
I
think
we
have
more
time
to
do
this
than
I
think
perhaps
thought
we
did
in
the
sense
that
we're
gonna
have
like
a
real
to
long
period
of
overlap
between
the
draft
versions
and
the
release,
version
and
I
know
like
I
was
talking
to
Ian
who's,
saying
that,
like
they
planned
experiment
with,
like
you
know,
new
verses
relatively
aggressively,
so
I
that
the
corresponding
risk
of
actual
ossification
seems
like
compared
awfully
less
high.
So
I
think
like
this
gives
us
a
little
time
to
work
on
the
problem
and
I'm
worried.
K
It's
actually
holding
you
know,
actually
hold
what
could
be
one
and
it
seems
like
you
know,
if
we
had
so
I
guess
my
I
put
on
this.
If
we
have
light,
if
we
like
solve
this
problem,
you
know
indeed
like
six
months
six
to
nine
month
period.
Well,
you
know,
while
we're
doing
my
test
deployments,
people
could
turn
their
attention
to
that.
It
was
perfectly
it's
perfectly
fine
as
an
extension.
K
So
like
let
us
use
that
mechanism
that
was
my
put
I
I
personally,
find
it
fascinating,
I'm
happy
to
work
on
it,
but
I'm,
trying
to
like
think
about
the
bigger
picture.
So
your
proposals
to
not
put
this
in
scope
for
quick
view,
one,
that's
correct:
okay,.
L
Mike
Bishop
Akamai
I
will
say
that
part
of
why
we
want
to
pull
the
version
negotiation
discussion
out
of
as
time
permits.
Is
that
going
through
discussion
of
this?
It
has
become
clear.
We
don't
really
want
to
do
this
without
some
idea
of
how
you
detect
fall
back
and
react
to
that,
and
that
is
work.
We've
already
decided
to
scope
out
so
I
think
we
either
have
to
adjust
our
scope
to
include
that
work
and
be
one
or
we
have
to
push
this
out
of
v1.
The.
M
What's
worse,
there's
the
poor
twist
that
says
may
be
fixed
by
thing:
I
mean
if
you
look
at
the
kata
page
yep,
but
English
well,
for
this
approach
to
walk
I
mean
the
server
needs
to
remember
the
keys,
the
alternatives
that
as
I
said,
but
that
means
that
it
doesn't
work
for
multi
CDN
use
case,
which
in
turn
means
that
it
work
only
for
the
large-scale
providers.
I
mean
one
of
the
largest
care
providers
that
home
both
the
client
and
the
server
into
using
this
mechanism.
M
H
It's
there's
David
Skinner's,
Igor
Chrome,
so
I
agree
with
that
curve
as
well
and
in
particular,
if
this
becomes
an
extension,
we're
starting
to
pile
up
a
list
of
drafts
that
are
coming
up.
That's
a
great
thing,
and
since
the
goal
here
is
to
prevent
someone
from
building
a
middle
box
that
only
lets
some
versions
of
quick
through
and
not
others.
We
can
establish
this
by
only
having
a
couple
p.
Large
providers
deploy
it
so
I
just
wanted
to
say
that
the
odds
of
Google
deploying
this
on
our
servers
are
pretty
high.
C
I
I
There
is
I'm
hearing
some
amount
of
fatigue
start
to
show
among
implementers
and
various
folk
who
are
starting
to
wonder
when
we
are
actually
going
to
ship
I've
heard
this
before,
but
I'm
starting
to
see
again
arise
in
that
concern
and
it's
legitimate.
It's
completely
reasonable.
We
were
hoping
to
have
some
things
done
by
the
end
of
this
year
and
we
aren't,
and
so
we're
sort
of
passing
on
the
deadline
and
moving
forward
so
in
the
interest
of
moving
forward.
I
think
we
should.
We
should
put
this
aside.
I
F
N
Protocol
apps
is
my
please
I.
Just
wanted
to
point
out
that
just
having
just
deploying
different
versions
of
quick
might
not
be
enough
to
prevent
ossification
if
the
middle
box
is
now
hard
to
decode
all
those
versions,
so
there's
the
the
risk
that
middle
boxes
will
happily
let
everything
through
that
they
understand
but
block
everything
that
they
don't
understand,
and
for
that
reason
we
need
to
deploy
a
version
where
middle
boxes
can
decrypt
the
initial
packet.
That
being
said,
an
extension
would
also
be
a
perfectly
valid
solution
for
this
problem.
G
A
A
A
E
So
this
is
an
interesting
observation
that
eka
made
doing
the
review
of
some
of
the
related
work
that
we're
doing.
The
document
currently
prohibits
the
use
of
key
updates
until
the
handshake
is
confirmed,
but
in
practice
the
first
key
update
can
occur
immediately
as
soon
as
you
have
one
RCT
keys.
I
think
this.
This
is
true,
but
we
could
still
decide
to
wait
for
confirmation
before
allowing
key
updates,
discuss.
M
Kahoku
I'd
like
to
point
out
that
there's
actually
application
key
that
precedes
one,
our
duty,
which
is
v-0
T
to
get
from
the
client
site.
So
it
makes
sense
to
also
have
confirmation
for
the
first.
I
are
one
now
treaty
key
being
used
because
it
gives
us
the
time
to
retire
the
0.5
key.
Without
that
heel,
pocket
Ryota
enclosing
a
book
or
something
I
mean
the
whole
musty
relation.
K
Eric
rajala
on
so
actually
I
think
on
Martin
is
correctly
channeling,
something
I
said,
but
that's
not
what
this
says
I
don't
think,
namely
what
this
says
is
that
the
that
the
text
in
the
specification
is
redundant
because
you
cannot
have
handshake
confirmed
that
basically
assume
that
that
could
point
to
here
on
once
you
receive
knowledge
and
practice
it
with
ease
implies
handshake,
confirmed
and
therefore
both
tests
are
not
needed
in
the
specification
where
it
says
so
so
that
that
is
not
a
design
change.
K
That's
merely
this,
but
it's
really
a
text
change
so
and
I
think
now
now
maybe
I'm
wrong
about
that
which
I'd
like
to
be
corrected,
but
this
was
not
intended
to
be.
This
is
intended
only
be
a
textual
change
to
make
life
simpler.
Now
it
may
be
the
case
that
if
we
take,
there
may
be
the
case
that
once
the
handshake
done
patch
comes
in
at
that
my
statement
here
is
no
longer
true,
which
officials
revisit
that
so
I
suggest
we
hold
off
on
this
particularly
shoot.
K
Well
after
we
resolve
the
key
change
issue
and
then
we
could
just
discuss
it
privately.
If
I'm
right,
then
this
is
an
editorial
issue.
If
I'm
wrong,
then
like
we
can
it's
a
non-issue,
there's
a
bigger
discussion
on
so
that
said,
Martin
is
separately,
making
a
point
which
I
do
agree
with,
which
is
we
could
have
laksa
rules
about
when
campus
were
permitted.
K
The
on
the
purpose
of
the
key
update
rules,
recall
is
is
to
remove
the
ambiguity
introduced
by
the
fact
that
we
only
have
that
we
have
only
have
one
bit
for
indicating
key
phase,
and
so
you
need
to
arrange
that
you
need
to
arrange
the
state
such
that
you
know
so
that
when
the
person
receives
the
OP,
that
inverted
key
phase,
though
there.
K
What
are
they
referring
to
you
right
and
that's
the
purpose
of
the
rules,
as
opposed
to
that's
like
why,
for
instance,
like
tell
us
one
more
three
laws
like
an
infant
number,
key
updates
in
in
the
phase
on,
because
there's
no
there's
no
way
to
get
it
wrong
right
in
the
same
things.
Actually
so
the
on,
so
the
on
you
can
as
soon
as
you
know,
you
can
send
one
or
key
key
keys.
K
I
see
how
the
one
key
keys
to
send
you
could
send
a
the
next
phase,
because
you
know
the
either
of
the
these
other
side
is
ready
or
it's
not,
but
it
can't
be
confused
and
so
that
so
I
think
if
we
wanted
to
relax
that
where
we
could
but
I'm
also
not
like
if
I
could
go
to
the
mat
for
that.
But
this
was
only
intended
to
be.
D
A
A
H
So
David's
gonna
see
Google
Chrome.
The
current
spec
has
most
of
the
are
transformer
or
let
me
read,
let
me
start
yet.
Our
main
joint
for
extensibility
in
quick
is
transport
parameters.
Those
are
governed
by
a
16-bit
space
and
which
is
covered
by
an
ion
our
registry
and
in
the
current
text.
Almost
all
of
that
is
specification
required,
and
there
are
cases
for
folks
who
have
like
private
extensions
that
illness.
They
don't
necessarily
want
a
document
where
they
want
to
be
able
to
get
a
code
point
without
writing
an
entire
spec.
H
So
today
that
space
is
so
tight
that
people
might
end
up
just
either
squatting
on
some
space
or
which
would
could
cause
collisions.
So
the
correct
fix
is
to
do
something
to
the
registry
and
Martin
has
APR
on
how
we
can
do
that.
Just
by
changing
the
rules.
It
includes
both
permanent
registrations
and
provisional
registrations
and
I.
Think
that
solves
the
issue
nicely.
So
so
far
like
there's
been
a
that
discussion.
Kind
of
landed
in
part
on
Martin's
PR
but
I
think
we're
in
good
shape.
There.
E
Yeah
so
some
Artin
Thomson
that
that
PR
essentially
says
that
provisional
registrations
can
go
anywhere
in
these
spaces,
but
establishes
expert
review
for
the
entire
space.
There's
a
bunch
of
advice
on
how
this
operates
and-
and
there
are
some
rules
about
how
we
might
reclaim
provisional
code
points
if
we
absolutely
need
to
and
and
a
bunch
of
other
things
like
that,
that's
a
lot
of
text
I,
don't
want
to
really
go
into
too
much
detail
here
about
what
that
is.
But
I
want
to
encourage
people
to
read
it
and
understand
it.
A
E
E
And
we've
had
some
discussions
on
that.
One
there's
some
finer
points
that
we
could
continue
just
to
discuss
here,
but
I
think
it's
we're
spending
much
more
productive
to
do
that
on
the
list.
Do
you
think
we're
close
to
getting
a
consensus
on
him?
I
talked
to
David.
He
seemed
relatively
happy
with
what
we
have
I've
talked
to
a
number
of
people.
I
think
you've
commented
on
it
as
well,
so
that
we
can
leave
it
to
a
little
more
discussion
and
then
what
did
I
would
like
to
sense.
K
Just
to
make
sure
I
understand
this,
they
play
provisional
registrations
are
essentially
free,
yeah
yeah,
we
just
people
who
don't
know
we
actually
just
discovered
it
in,
like
the
last
glass
call
at
TLS
that
we
that
we
had
their
working
group
universe
on
the
same
Co
point
to
to
do
two
drafts.
So
so
so
yes,
I
would
really
really
like
to
have
a
registry
where
we
did
this
so
that
we
don't
I
mean
like
this
wasn't
even
uncoordinated
by
exactly
the
same
clowns.
But
you
might
I
mean
me
yeah.
That's
never
happened
before.
A
E
K
Yeah,
that's
the
right
place
to
come
to
on
this.
So
for
context.
This
is
not
an
issue.
Well,
this
is
the
this
is
perhaps
less
of
an
issue
and
tell
us
because
the
ordered
nature
of
the
data
I'm
not
saying
it's
actually
I
mean
you
could
still
make
this
mistake,
but
I
I,
guess
I
would
make
two
observations.
One.
K
O
K
We
don't
stop
you
right
or
an
initial
packets
for
that
there's
a
wire,
including
permits.
It
therefore,
and
therefore
you
have
to
actually
filter
right,
so
the
so
I
don't
think
you
know
that
this
is
a
principle,
but
it's
one.
We
perhaps
respects
unless
I'm
in
other
parts
the
time
the
it'd
be
possible,
of
course,
to
make
it
impossible
what
the
initial
encoding
has
you
know,
so
you
couldn't
do
that
right.
K
We
just
don't
the
this
is
sort
of
a
kind
of
a
miss
feature
until
us,
I
think
at
the
end
of
the
day,
I'm
saying
we
sort
of
have
you
conversation
about
fixing
that
the
put
here
looking
at
me
would
be
to
make
it
so
that
the
clients
wonder
he's
depending
the
full
transcript
sorry
Eckhart
can.
A
K
The
fix
would
be
to
make
the
clients
one
RT
tikis
depend
on
the
full
transcript
so
which
I
mean
it
wouldn't
be
that
difficult,
but
as
they
say,
will
be
a
change.
I
changed
a
TLS
and
quick,
so
I
think
always
is
the
right
answer.
I'm,
given
that
even
those
points,
though
I
miss
a
nice
me
a
little
sad
like
because
I
know
it
was
kind
of
a
miss
feature
and
it's
also
a
miss
feature
in
DT
loss
by
the
way
so
I
think
I.
K
I
will
probably
float
this
at
the
TLS
working
group
that
they're
in
the
TLS
session
and
see
if
people
like
I,
don't
like
it
for
DTLS
and
would
like
to
reconsider
and
we're
happy
to
come
back
to
this
group.
If
he
tells
working
group
thinks
that
that's
like
a
details
problem
so
you're,
okay,
with
merging
this
now
I
think
I'm.
K
G
Martin
Duke,
so
substances,
substance
of
empties
PR
is
fine.
I
had
a
different
one,
much
shorter
for
the
same
problem,
but
I
guess
by
my.
But
my
way
of
thinking
of
this
is
just
sort
of
practical.
There
are
a
lot
of
quick
implementations,
some
of
which
are
sort
of
hacky
and
some
which
are
done
by
through
the
a
lot
about
security.
There's
a
much
smaller
number
of
TLS
implementations
out
there
generally
done
by
people
who
know
something
about
security
and
to
work
with
quick.
You
have
to
do
some
special
interface,
API
stuff.
G
The
right
pressure
point
in
which
to
specify
this
is
to
specify
in
the
interface
between
TLS
and
quick,
when
things
must
pass
so
that
if
the
TLS
inflators
does
not
push
down
the
receive
keys
until
the
handshake
is
complete,
you
kind
of
solved
this
naturally
for
quick,
coupla
mutations,
that's
the
narrow!
That's
the
narrow
part
of
the
waste
here
of
the
of
a
full
click
upon
full
stack,
quick
implementation.
H
David's
Knaus
II
yeah
this.
This
is
sad,
but
it's
something
we
can
live
with
for
now,
because
fixing
it
as
I
said
before,
is
really
tricky.
So
I
think
we
should
start
that
conversation
in
TLS,
but
we
don't
need
to
go
over
that
here
and
then,
once
that
happens
there
we
can
mate.
This
would
be
a
really
good
candidate
for
quick
v2
in
the
meantime,
I
think
it
would
really
be
nice
to
either
in
our
Interop
matrix
or
in
our
magical.
H
E
So
Martin
Thomson,
oh
I,
just
wanted
to
address
Martin
Jukes
concern.
Oh
I
think
his
philosophy
here
is
fine
and
I
would
support
implementations
doing
that.
But
I
was
very
careful
not
to
put
that
in
the
specification,
because
I
don't
believe
that
levying
requirements
on
the
interface
between
the
quick
transport
and
TLS
too
tightly
is
is
appropriate
here.
I.
Do
think
that
it
is
absolutely
the
right
thing.
E
Fo
TLS
implementations,
considering
this
to
think
about,
and
probably
now
that
in
in
retrospect
now
that
I
built
in
that
interface
in
NSS
I'm
thinking
that
maybe
I
did
it
wrong,
but
I'm
not
going
to
unravel
all
of
that.
Just
for
this
particular
problem.
We
have
a
fix
in
the
quick
side
of
things
and
that
works.
Fine,
I
don't
want
to
have
any
mandate
on
how
people
structure
their
implementations
in
it.
That's
getting
dangerously
close
to
that.
B
Repair
to
pay
on
quick
observation,
so
Roberto
can
you
speak
up
a
bit?
Yes,
we
learn
to
pay
on
quick
observation,
our
if
it's
not
possible
to
ensure
that
a
conforming
implementation
will
not
have
this
defect.
Is
it
possible
to
ensure
that
a
remote
side
can
probe
to
see
that
the
remote
side
has
this
defect?
Is
that
that's
yes?
Okay,.
F
P
Thomson,
thank
you
that
it's
it's
the
right
thing
to
do
to
require
this,
but
I
like
we
can't
really
require.
We
shouldn't
have
suspect
require
that
the
API
patient
is
surgeon.
We
shouldn't
be
able
to
like
require
that
the
spec
requires
this
particular
implementation.
Deal
it'd
be
ideal
to
be
able
to
actually
require
it
with
the
the
wire
protocol,
but
that
will
require
chains
and
TLS
I,
think
it's
probably
worse
making
that
chain.
A
F
H
All
right,
yeah,
so
discarding
keys,
has
been
an
adventure
to
the
point
where
we
formed
a
design
team
whose
members
are
listed
down
here:
I'm,
David's,
canoes,
II
and,
let's
hope,
if
we
killed
this
Thanks.
So
we
the
design
team
at
some
point
in
the
past,
I,
don't
even
remember,
which
ITF
came
up
with
a
solution
on
how
to
discard
the
keys.
They
went
into
the
spec
and
then
Martin
realized
that
there
was
a
way
it
was
hardly
or
broken
and
then
Kazuo
found
another
way
in
which
was
broken.
H
But
without
going
into
too
much
detail.
If
one
specific
AK
in
the
handshake
gets
lost,
the
client
can
end
up
in
a
state
were
it
keeps
we
transfer
say
retransmitting
its
clients
finished,
because
it's
expected
to
do
that
until
it
gets
an
AK,
but
the
server's
drop
those
keys.
So
it's
never
gonna
act
that
packet
and
if
you
do
it
just
the
wrong
way,
you
can
exhaust
your
congestion
window
and
completely
shoot
yourself
in
the
foot
to
the
point
where
your
connection
just
never
sends
anything
bad,
bad,
bad.
H
We
need
to
fix
this
so
and
the
other
problem
that
Kazuo
noticed
is
that
if
so,
discarding
keys
happens
well
on
what
we
call
handshake
confirmed
and
that
also
keys
off
a
lot
of
other
features
in
the
protocol,
such
connection
migration
and
if
the
client
migrates
before
the
server
has
done
this,
you
end
up
in
a
state
where
the
server
ends
up
sending
long
headers
to
a
migrated
address,
which
is
something
we
never
really
thought
of,
and
then
you
have
other
gross
things
there.
That
bad
must
fix
so
occurred.
H
Did
a
really
nice
analysis
in
LA
tech.
That
is
very
thorough.
Next
slide,
please,
and
but
we
have
a
solution,
and
hopefully
our
design
team
never
has
to
meet
on
this
again
so
Martin
other
Martin,
Martin
seaman
came
up
with
a
PR
for
this,
and
so
the
idea
is
on
the
server.
The
moment
you
receive
the
client
finished
and
your
TLS
stack
tells
you.
The
handshake
is
complete.
You
say:
okay,
great,
the
and
check
is
confirmed.
H
I
drop,
my
handshake
keys
and
I
send
a
new
handshake
done
frame
from
the
server
to
the
client,
and
you
keep
transmitting
to
that.
Until
you
eventually
get
an
ACK
and
on
the
client
as
soon
as
you
get
that
frame,
you
say:
okay,
great
now,
I
know
the
server
has
received
my
client
finished.
I
can
discard
my
handshake,
keys
and
I
can
confirm
it
and
enable
some
features
like
migration,
and
there
is
one
slight
subtlety
that
we
added
in.
H
There
is
if
the
client
receives
an
ACK
of
a
warranty,
tea
packet
had
sent
it
because
of
the
rules
we
were
talking
about.
The
server
is
not
allowed
to
process
and
a
quantity
packets
until
it's
confirmed
that
completed
the
handshake.
So
that
means
that
also
you
know
the
server
is
in
that
state.
It
just
so
happened
that
maybe
your
handshake
done
for
him
got
lost
along
the
way,
so
you
can
treat
that,
similarly
to
the
receipt
of
a
handshake
done
frame,
get
from
the
handshake
and
discard
the
keys
next
slide,
please.
H
K
H
A
C
I
Jim
I
ain't
got
to
Brian's
point
Eskenazi
had
linked
to
acres
analysis,
which
is
very
good
and
I.
Think
that's
probably
acres
analysis,
which
is
linked
in
skin
Aziz.
Slides
is
a
very
good
analysis
and
I
think
that
captures
sort
of
what
the
different,
what
the
scope
of
different
solutions
that
would
discussed
were
and
I
think
that's
required.
A
L
Q
A
L
Q
And
you
have
a
PR,
so
Eric
Kinnear,
so
Martin
seaman,
actually
wrote
a
PPR
for
this
louder
even
louder
Wow.
Can
we
also
open
up
3193,
while
we're
at
it
son
say,
should
indeed
be
design?
The
same
PR
covers
both
of
these
issues
at
the
time.
Technically,
it's
possible
to
not
exceed
it
because
it
didn't
include
the
one
established
during
the
handshake,
but
the
PR
purpose
is
changing
that.
So
the
previous
case
was
the
issuer
of
connection
IDs
issues.
However
many
they
want.
Q
So
this
PR
makes
a
change
now
that
we
have
a
way
for
the
issuer
to
require
that
they
be
retired
and
replaced
and
for
the
recipient
to
bound
the
amount
that
they're
willing
to
store
and
just
communicate
that
as
opposed
to
having
to
silently
drop
them.
The
PR
that
covers
both
of
these
issues
makes
it
so
that
you
now
say
I'm
willing
to
store
this
many.
Q
If
the
person
issues
you
too
many,
that's
actually
an
error,
and
it's
a
must
not,
and
so
they
issue
you
up
to
that
many
when
you
retire
them,
they
get
replaced
and
if
they
request
that
they
be
retired
and
replace
them,
then
you're
all
good.
So
it
brings
them
back
into
sync
and
as
a
side
effect
of
that
which
is
kind
of
what
Mike's
issue
is
trying
to
get
at.
Q
It
means
that
the
the
default
needs
to
become,
because
it
starts
counting
the
one
established
during
the
handshake
and
be
preferred
address
one
as
counting
so
that
we
don't
have
this
magical
two
that
are
floating
off
in
the
middle
of
nowhere.
So
it
makes
everything
much
more
consistent
with
the
way
everything
else
in
the
protocol
works
should
be
linked
from
both
of
these
issues.
We
just
got
a
scroll.
Q
I
At
the
bottom,
so
I
had
some
comments
on
this
earlier
and
I've
had
conversations
with
Derek
and
Kazuo
since
then
and
I
understand.
This
is
a
bit
of
a
model
shift.
The
way
we
were
thinking
about
this
earlier
was
different
than
the
way
that
these
folks
are
thinking
about
this
now
and
now,
having
understood
the
model,
I
think
it
makes
sense.
I
I
I
can
see
this
being
natural
for
those
who
aren't
who
haven't
thought
about
this
in
the
previous,
so
I
have
some
comments
in
there
which
which
need
solving,
but
those
aren't
those
aren't
fundamental,
those
aren't
blocking,
they
will
get.
They
can
easily
be
resolved.
It's
just
text
work,
but
I
think
this
is
this.
Pr
is
seen
and
I
actually
I,
don't
I,
don't
mind
doing
it.
This
way,
I
also
know
that,
apparently
this
this
this
stuff
was
confusing
to
implementers.
So
it's
it's
a
valuable
work
in
that.
I
L
Q
Erik
Kinnear,
so
you
can
change
connection
IDs
without
migrating.
So
if
you're
not
supporting
migration-
and
you
don't
ever
want
to
change
those
are
separate
things.
The
reason
that
you
need
to
is
so
that
the
server
can
give
you
the
preferred
address
transport
parameter,
and
that
comes
with
the
CID
to
use.
So
if
they
don't
give
you
that,
then
your
your
said
you,
you
are
still
saying:
I'm,
okay,
with.
A
Q
A
I
Q
Q
Eric
Kinnear,
so
this
is
the
one
that
we've
had
for
a
while.
We
wrote
up
a
bunch
of
text,
changed
it.
Gory
went
through
it
and
helped
us
review
it
since
Cupertino,
so
our
last
status
in
Cupertino
was
that
we
were
hoping
Gauri
would
would
take
a
look
and
that
we
get
some
of
the
reviews
on
the
proposed
text.
We
have
not
done
that
Thank
You
Gauri
and
then
we
went
through
with
Martin
and
reorganize
things
a
bit,
so
they
should
be
in
good
shape
to
be
included
in
the
next
consensus.
Call:
okay,.
E
I
haven't
seen
the
new
stuff
that
that
echo
has
added
to
this
document,
which
is
talking
about
the
handshake
and
the
packet
protection
and
how
that
interacts
with
all
all
of
this,
it's
a
fairly
big
project,
so
I
want
to
make
sure
that
people
are
we're
aware
of
what's
going
on
here,
because
this
this
is
really
the
the
grounding
on
which
a
lot
of
our
analysis
is
based.
It's
kind
of
strange
that
it's
coming
so
late
in
the
process,
but
I
think
that's
just
a
consequence
of
of
us
now
understanding
a
lot
better.
E
K
Yeah
I
mean
please
do
read
this.
This
should
have
no
normative
force,
but
if
you
read
this
and
you're
like
wait,
I
thought
we
defended
against
that.
Or
this
is
nonsense
or
you
know
wait.
This
is
a
little
booty
exists.
Holy
crap
yeah,
like
those
are
bad
things,
and
we
should
fix
it.
What
you
talk
about
them,
so
this
is
like
if
this
is
accurately
characterized.
Your
expectations
looks
like
things
in
here
surprising
to
you,
then,
like
that's
something
you
should
flag.
K
D
Christianism,
oh
I
have
actually
studied
that
we
never
do
a
lot.
I
have
a
unit
test
testing
that
in
my
implementation,
to
see
what
happens,
it's
extremely
hard
to
defend
against
that
attack.
It's
a
logical
consequence
of
being
able
to
support
to
support,
not
not
binding,
not
rebinding.
As
long
as
the
IP
address
are
not
authenticated,
this
dilatory
can
do
it,
except
from
sending
toxins
and
doing
heuristics,
so
I
think
that
at
best
what
we
should
have
is
a
mention
of
that
attack
in
the
security
consideration
and
some
kind
of
do
your
best
recommendation.
Q
Eric
can
hear
two
things
first,
I
did
forget
to
highlight
earlier:
we've
now
filled
out
a
Necker
filled
out
the
first
section
that
was
kind
of
TBD
when
we
discussed
this
in
cupertino.
So
thank
you,
echo
for
doing
that
and
to
Christians
point
I,
believe
the
current
text
does
highlight
that
attack
and
list
the
capabilities
that
we
believe
somebody
who
has
successfully
carried
out
that
attack
has
that's
what
I'm
hoping
people
will
take
a
look
at
and
say
no.
This
makes
no
sense.
We
don't
like
this
or
yes
that's
about
right.
Q
A
Excuse
me,
thank
you.
So
let's
go
ahead
and
mark
this
proposal
ready
go
through
the
process.
Everyone
take
special
care
to
look
at
this,
make
sure
you
understand.
The
changes
have
been
made
and
we'll
see
where
we
get
thanks
for
that
last
one
on
this
particular
list.
A
A
Sorry,
don't
know
Thank
You,
3189,
quick
loads,
real
pages
really
slowly
here
lacks
on
page
unpacked
exposure
of
packet
loss
3189
on
the
transport
draft,
and
so
this
is
a
proposal
to
add
some
bits
to
the
long
sorry
short
packet
header
for
detecting
loss
by
networks.
That's
a
topic
which
we've
discussed
before,
and
it's
related,
of
course
to
the
spin
bit
discussion,
and
we
had
a
separate
issue
about
that.
A
while
back
where
we
came
to
consensus
that
we
wouldn't
do
this
in
quickly.
One
so
been
talking
to
a
lot
of
people
about
this.
A
We
actually
had
a
lot
of
discussion
when
the
so
we
locked
the
issue
because
it
doesn't
do
any
good
to
have
a
triage
process.
If
everyone
spends
our
time
discussing
the
issues
before
we
actually
say
we're
working
to
discuss
them,
I'm
gonna
go
ahead
and
lock
that
now
talking,
yes,
Brian.
Thank
you
for
your
input.
A
A
That
would
be
a
process
that
would
be
necessary
for
us
to
consider
this,
and
the
question
is:
when
do
we
do
that
process?
So
so
that
would
be
that
that's
what's
first
in
mind,
but
but
I
want
to
open
up
the
floor.
Let's
have
some
discussion.
Let's
see
how
people
feel
about
taking
this
work
on
so
and
Igor
is,
is
the
the
proponents
of
please
start.
F
So,
just
to
give
people
a
tiny
bit
of
background
who
haven't
been
following
that
closely.
So
there's
a
lot
of
discussion
about
it
in
TS
vwg,
so
quick
increase
its
headers,
it's
one
of
the
new
protocols.
It
does
it
so
it
doesn't
expose,
delay
and
loss
to
the
past
and
which
many
operators
and
researchers
and
many
other
parties
said
that
wells.
It
is
problematic
for
them
to
ensure
quality
of
service.
Brian's
had
a
great
proposal
about
spin
bits.
F
There
was
an
extensive
privacy
discussion
and
a
working
group
decided
that
concerns
have
a
consensus
to
adopt
that
and
to
include
one
of
the
reserve
leads
for
spin
bid.
At
that
time
there
was
no
viable
proposal
for
the
lost
bid,
so
the
group
decided
that
there
is
nothing
to
do
so.
It
was
changed
the
draw
of
proposals
now
the
risk
codes
that
we've
implemented.
Based
on
that
proposal,
last
ATF
Orange
has
done
presented
some
experiments
data
from
that
code.
Yesterday's
CNET
presented
some
SATCOM
data
from
experiments
based
on
that
stuff.
F
So
it's
there
are
other
proposals
in
that
area,
which
means
that
it's
kind
of
important
people
care.
Now.
It's
clear
that
it's
quite
contentious
in
terms
of
timing
for
v1,
so
I'm
ready
to
commit
to
make
a
extension
draft
for
the
interim
and
if
working
group
is
interested
in
this
topic,
which
I
think
they
should
be
because
it's
a
lot
of
there
is
a
lot
of
interest
in
the
community.
So
we
can
work
with
that.
We
would
need
working
group
engagement
to
do
a
similar
privacy
consideration
for
the
new
draft
and.
B
B
A
Just
just
for
my
benefit,
I
think
our
options
are
to
know
discussed
this
in
the
skip.
A
quick
v1
say
this
is
out
scope
or
we
could
say.
Yes,
it
is
in
scope
or
we
could
instruct
Igor
and
the
other
components
to
come
up
with
an
extension
draft
and
we'll
start
the
extension
discussion.
If
people
think
there
are
other
options
where
they
have
opinions
about
those
options,
I'd
like
to
hear
them
so.
C
C
Right
yeah,
so
it's
a
supple,
it's
it
sounds
like
it's,
maybe
even
like
a
bath
layer,
maybe
on
top
of
UDP
might
be
a
substrate
I,
don't
know
I
told
you,
I
was
gonna.
Take
over
your
working
group
mark
I'm.
Sorry,
now
we're
seriously
I
think
there's
they
don't
really
wanted
to
read
what
I
put
into
the
issue.
I.
Think
there's
like
two
questions
here,
actually
do
put
it
up
there.
So
I
can
remember
what
I
wanted
to
say.
C
There's
two
questions
here:
one
is:
do
we
want
to
you
know
recognizing
that
it
is
kind
of
an
expedient
hack.
Do
we
want
to
basically
say
look
we
want
to
replace
the
fact
that
people
have
used
implicit
past
signals
in
TCP
to
do
loss
measurement
with
explicit
past
signals
for
loss
measurement
in
quick
and
then
the
second
question
is:
do
we
want
this
proposal
to
be
the
basis
of
that
I
think
we
should
separate
those
out
I.
Think
it's
really
late
to
have
this
conversation
I.
C
Think
like
absolutely,
we
should
say:
let's
try
and
figure
out
I
liked
Igor's
proposal.
It's
like
we're
gonna
go
really
fast
and
see.
If
maybe
we
can
get
something
that
might
actually
work
in
the
timeframe
you
know,
so
the
bet
there
that
that
Igor
is
making
is
that
you
know,
with
the
rest
of
the
things
that
we
need
to
get
done
for
v1
we're
going
to
be
slower
than
we
think
we
are
and
I
think
looking
at
our
history,
that's
a
pretty
good
bet.
C
We
just
have
profiles
a
quick
under
v1,
because
of
of
because
we're
actually
really
successful,
with
transform
yeah
yeah
down
yeah
yeah
well
I
mean,
like
Roberto,
started
with
IP
b7.
So,
let's
just
blow
it
all
up
the
the
discussion
that
we
could
have.
That
would
make
a
extension
oriented
solution
to
this
question
easier.
Is
how
many
bits
do
we
want
to
lay
aside
and
how
many
bits
do
we
think
that
we
can?
C
C
C
It
would
be
a
shame
if
we
decide
we
want
to
do
this.
We
figure
out
a
way
to
do
it
and
then
the
bits
are
gone.
So
I
think
that
is
a
discussion
that
we
we
probably
should
have,
and
then
we
can
defer
the
rest
of
the
discussion
with
respect
to
how
exactly
we
do
this,
because
I
think
there
are
probably
ways
that
look
a
lot
like
this,
but
are
subtly
different.
C
They
have
different
characteristics,
I
have
kind
of
it
the
beginning
of
an
idea
that
I
haven't
actually
had
the
time
to
work
on
and
I.
Don't
really
want
to
say
hey.
You
should
do
my
thing,
even
though
I've
written
it
down
because
it's
stupid,
but
I
think
that
we
can.
We
can
discuss
like
other
techniques
here
separately
from
the
weather.
We
want
to
do
this
or
not,
and
that's
separate
from
the.
How
do
we
make
sure
that
we
have
the
space
to
do
it
when
we're
finally
done.
O
So
we
have
a
pretty
long
queue,
so,
let's
just
keep
them
brief.
This
is
dkg
I'm,
Jabbar,
scribing,
I'm,
channeling,
Chris
lemons.
He
says
I
think
the
question
for
excluding
is
from
quick
v1
is
this
for
the
lack
of
a
packet
loss,
detection
mechanism
and
quick,
prevent
operators
from
implementing
it.
Perhaps
some
of
those
companies
who
have
expressed
strong
interest
in
this
can
comment
on
how
blocking
this
is
or
isn't.
O
C
By
at
Google,
I
I
definitely
think
we
do
not
need
to
put
this
in
quickly
one
fairly
we've
already
kind
of
I
thought
said
this
once,
but
I
would
like
to
say
that
if
there
is
something
some
small
change,
we
need
to
make
two
quick
v1
to
make
it
easier
to
actually
run
experiments
and
get
data
about
this
mechanism
as
well
as
potentially
other
competing
mechanisms,
because
I'm
also
not
100%
convinced
this
is
the
best
mechanism,
then
I
am
amenable
to
that
and
I.
Don't
think
that
should
be
considered
necessarily
out
of
scope.
C
H
David's
Knaus
II
Google
to
echo
some
of
the
points
are
you
made?
I
need
to
speak
up.
Sorry
Wow,
the
the
decision
we've
reached
as
a
working
group
a
while
back,
took
a
very
long
time
and
a
lot
of
energy
I'm
saying
that
the
decision
was
to
add
the
spin
bit
as
one
bit
that
is
optional
to
implement
in
this
Bank
this.
This
is
the
interesting
research
project.
I've
read
the
proposal.
It's
interesting,
but
research
takes
time
and
I
didn't
see
anything
in
there
that
warranted
revisiting
the
working
groups.
H
Consensus
decision
and
also
like
from
my
engineering
understanding
I
think
this
can
fully
be
implemented
as
an
extension,
negotiate
with
a
transport
parameter
and
then
use
those
bits.
So
I
really
strongly
in
favor
of
declaring
this
out
of
scope
for
quick
view
on
and
in
scope
of
an
extension,
and
let's
see
that
extension
draft
and
we
can
discuss
it
there.
We
already
have
a
bunch
of
extensions.
It
might
even
ship
at
the
same
time
as
quick
view
on,
but
if
it
gets
delayed
because
of
let's
say
the
privacy
review,
it
won't
delay.
Quick
view
want.
H
H
K
To
echo
a
few
of
the
things
people
been
saying
before,
certainly
this
should
be
sharable
as
an
extension.
If
it's
not,
then
we
failed
in
our
mechanism
and
that
be
nice
to
know
so.
I
think
this
also
ties
I'm,
saying
even
was
saying
like
if
we
find
out
there's
some
reason.
We
can't
ship
this.
That
was
something
the
higher
priority
to
address
chant.
This
is
an
extension
that
was
any
hyper
rush
now.
K
I
am
also
not
in
favor
of
putting
this
in
quick,
v1
I
feel
like
we
spend
a
lot
of
time
litigating
this
previously,
and
this
would
reopen
that
on.
You
know:
we're
gonna
have
it's
true.
K
We'll
have
some
time
in
this
sort
of,
like
you
know,
in
this
sort
of
like
somewhat
like
I,
don't
period
when
you
know
we're
doing
deployments
to
think
about
things,
but
I
think
we
have
uses
for
that
time
and
and
I
mean
that
the
exact
same
resources
which
we
need
to
like
do
other
offenses
I
think
are
more
important,
would
be
consumed
during
the
security
in
privacy
review.
So
I
think
the
idea
we're
gonna
play
as
Christian
put
its
schedule.
K
Chicken
and
like
you
know
if
this
is
somehow
finished,
that
maybe
it
just
gets
crammed
into
the
last
minute,
I
think
it's
like
super
unfortunate.
We
shouldn't
do
that.
I
know
that
correctly
and
I,
as
with
David
I.
At
some
point,
we
were
willing
to
like
take
a
look
at
the
screen
privacy
of
this,
but
I
think
it's
not
I,
don't
think
it's
a
I
super
high
priority
for
me.
Okay,
thank.
R
R
Sorry
as
yeah
Chris
box
BT.
So
my
day
job
is
designing
running
a
mobile
network
so
as
part
of
that
I
just
want
to
reiterate
the
need
to
actually
understand
packet
loss
and
where
it
occurs
in
their
network,
because
without
that
yeah
the
network
will
inevitably
deteriorate.
So,
whether
this,
how
it's
done
and
whether
it's
done
now
or
later,
I,
don't
mind
how
it's
done,
but
we
don't
want
to
wait
too
long
because
you're
then
incurring
those
issues
that
they
will
generate,
particularly
if
it's
adopted
a
lot
so
and
to
address
the
other
point.
R
S
So
gory
Fairhurst
I
think
this
sort
of
use
of
the
bytes
that
we
call
transport
is
within
the
transport
area.
Okay,
I
think
this
use
of
bytes,
which
we
put
into
the
header,
is
part
of
something
we
do
in
transport
area.
Ip
performance
metrics
is
part
of
this
group,
so
have
other
other
groups
looked
at
transport
issues
to
do
with
mobility
and
lost
detection,
latency
detection,
etc.
So
I
think
we
need
to
stop
going
on
that.
This
is
not
part
of
a
layer
whatever
at
a
layer
is,
is
part
of
the
transport
area.
S
From
my
opinion
and
I
think
we
should
do
this.
Whether
this
proposal
is
right
now,
I
can't
judge,
because
I
guess
we
spent
so
much
time
in
the
working
group.
Not
talking
about
this.
We
haven't
actually
looked
at
these
things
in
enough
detail,
so
this
could
have
a
bad
implication.
It
makes
quick
and
experimental
protocol
based
on
deployment
and
whether
it's
manageable,
which
was
never
really
part
of
what
I
was
hoping
for
in
quick.
S
J
Wait
my
actual
point
here
is:
we
have
had
a
long
discussion
of
this.
We
are
very,
very
late.
I
am
happy
to
work
on
this
if
it
is
not
gating
for
v1,
but
I
I
strongly
believe
we
should
not
set
aside
any
bits
for
it
now,
because
those
will
get
squatted
on
very
quickly
by
people
who
have
other
experiments
they
wish
to
run
with
the
network.
Some
of
them
deal
it
areas
to
the
network.
E
Yeah
mom,
Thompson
I'm,
just
gonna,
add
to
the
chorus
if
those
saying
that
this
is
gonna
take
longer
than
I'm
willing
to
tolerate
I'm,
looking
at
being
done
with
the
core
transport
protocol
very
soon.
Now,
as
in
this
month,
from
the
perspective
of
the
issues
you
saw,
we
discussed
the
issues
here
and
we
got
to
the
end
of
the
list
in
very
short
amount
of
time,
and
that's
indicative
to
me
of
something
that
basically
ready
ready
to
go.
E
E
Just
wanted
to
point
out
also
people
have
been
talking
about
extension,
I,
think
they're.
Also
thinking
about
minting
new
versions.
I
don't
want
to
go
to
the
point
of
reserving
bits
in
v1
for
speculative
reasons.
We
have
bits
lying
around
because
well
they
come
in
multiples
of
eight
and
that's
really
all
so.
I
I
don't
want
to
I,
don't
know
what
start
speculating
about
what
we
might
need
bits
for
later.
If
we
need
bits
for
something
later,
we
have
in
the
order
of
9600
of
them
in
any
given
packet.
E
We
should
probably
use
them
and
we've
done
what
we
can
to
protect
our
ability
to
use
those
packets
through
the
invariants
and
the
encryption
and
all
the
other
things
we're
doing
here.
So
I'm
not
super
concerned
about
that
sort
of
thing.
I
think
the
ship
has
sailed
on
whether
something
like
spin
or
lost
signals
can
be
invariant
in
the
protocol.
E
Take
that
as
it
as
you
will,
if
you
you're
interested
in
receiving
their
signals,
that's
a
bit
unfortunate
if
you're,
not,
then
you
might
think
that's
a
feature,
but
but
that's
where
we're
at
so
I
think
that
the
planners
proposed
is,
is
fine.
I
too,
can
participate
in
analyzing
these
sorts
of
things
again.
That
will
depend
on
at
the
time
that
that
decision
is
made
where
this
fits
in,
with
all
my
other
priorities
and
I'm
sure
that
everyone
else
is
in
that
same
position,.
A
O
Is
general
Congo
more
from
the
ACLU?
Please,
please
do
not
make
this
something
that
is
required
for
quickly
one
if
it's
proposed,
as
an
extension
again
similar
to
the
other
commenters
like
I,
would
be
willing
to
look
at
a
little
bit.
I
think
if
I
can
make
the
time
for
it.
I
am
NOT
confident
that
this
is
a
good
idea,
I'm,
not
confident
it's
good
idea
in
terms
of
ossification,
among
other
things,
so
but
yeah,
but
whatever
whatever
happens.
Please
please
not
part
of
quickly.
One.
M
M
An
extinction
and
I'm
also
not
opposed
to
leaving
some
bits
in
vivo
I
used
that
it
might
use
for
experiments,
though
I'd.
Also
you
there.
Those
bits
can't
be
a
brown
bag,
that
an
in-point
can
run
an
experiment,
because
there
should
be
a
bilateral
agreement
between
the
client
and
server
to
run
experiments
with
the
understanding
of
what
the
risks
are
I
mean,
and
that
means
that
the
bits
cannot
be
a
problem.
So
if
we
are
going
to
run
experiment,
there
should
be
a
bilateral
agreement
on
plant
X,
but
the
exact
exposure
is.
D
Christian
we
tomorrow
I
agree
with
the
other
speakers
that
this
should
not
be
part
of
v1
I
mean
the
measurement
argument
I
understand,
but
a
measurement
document
in
a
network
will
only
take
shape
that
force
when
the
vast
majority
of
the
traffic
is
quick
and
we
are
not
there
yet.
So
it's
clearly
not
a
v1
issue.
On
the
other
hand,
I
am
very
happy
to
work
on
that
as
an
extension
to
help
people
in
given
the
extension
and
to
study
the
privacy
issue
detailing
at
that.
D
I
We
are
designing
not
just
four
mechanisms
that
we
want,
but
we
also
want
to
keep
in
mind
that
we
are
designing
for
what
I
mean
by
that.
Is
that
we've
designed
the
spin
bit
and
if
you
were
to
think
of
that
as
a
template,
the
spin
bit
is
something
that
is
optional.
The
end
points
may
or
may
not
spin
it.
I
We
have
absolutely
no
experience
at
this
point
to
see
whether
that's
actually
going
to
get
deployed
in
the
wild
or
not
designing,
more
bits
that
are
not
going
to
get
deployed
potentially
makes
no
sense
to
me
so
I'd
like
to
wait
until
wait
and
see
if
he
actually
gets
some
traction
on
the
spin.
But
before
we
talk
about
adding
more
bits
that
are
optional
and
will
may
not
get
spend.
T
Tommy
Polly
Apple,
so
I
mean
echoing
a
lot
of
people's
comments.
I,
don't
think
this
is
appropriate
to
heffers
a
requirement
for
your
4v1,
but
I
think
it
is
very
useful
to
look
into
and
to
echo
Christians
point.
I
think
it
will
be
actually
a
much
better
mechanism.
If
we
wait,
because
once
we
get
more
information,
we
will
be
able
to
do
far
better
experimentation
around
different
extensions
right
now,
the
traffic
we
see.
We
have
a
lot
of
what
browser
traffic.
T
Essentially
in
one
type
of
pattern,
we
are
going
to
start
seeing
a
lot
more
use
cases,
different
types
of
traffic
and
the
fact
that
we
are
now
essentially
moving
things
that
used
to
be
implicit
and
now
we're
putting
them
across
a
encryption
boundary
and,
having
you
know,
explicit
bits.
This
is
something
we
haven't
done
very
often
before,
and
we
need
to
figure
out
how
it
works
and
even
if
we
get
experienced
just
today
with
how
it
works
for
browser
traffic,
that
may
not
be
the
right
solution.
F
A
So
you
know
this
is
one
of
the
the
mechanisms
that
you
know
for
it
to
work
and
for
it
to
give
the
operators
what
they
want.
They
need
the
cooperation
of
the
endpoints
and
from
what
I'm
hearing
from
the
implement
implementers
is
that
they
don't
want
this
to
be
on
the
critical
path
for
quick
v1,
but
they're
very
open
to
it.
As
an
extension
and
importantly,
I
heard,
a
number
of
people
say
that
they
were
willing
to
consider
helping
out
with
that
Security
and
Privacy
evaluation,
which,
for
me
is
critical.
C
Marcus,
like
actually
I,
saw
a
few
people
who
were
in
line
said
yeah
I
would
be
willing
to
work
on
this,
but
not
in
v1
I.
Don't
think
anyone
said
I'd
be
willing
to
work
on
this.
You
know
faster
than
v1
other
than
the
proponents.
Could
we
do
like
just
a
quick
show
of
hands
in
the
room
who
would
be
willing
to
work
on
sort
of
the
security
privacy
design
of
this
yeah?
There's
some
noise
back
there
who.
A
My
concern
before
this
was
that
if
no
one
was
willing
even
to
put
that
work,
and
we
would
be
in
a
bit
of
a
pickle
yeah,
and
so
we
have
a
group
of
people
who
are
willing
to
work
on
it
as
long
as
it's
not
on
the
critical
path
for
v1
and
so
I
think
that's
the
path
that
is
most
likely
to
give
us
a
successful
outcome
for
some
definition
of
success.
And
so
what
I'd
recommend
to
you,
igor's
take
you
and
your
co-authors
draft
convert
into
something.
A
That
looks
more
like
an
extension
and
we'll
talk
about
this
a
bit
more
tomorrow,
but
we're
talking
about
how
we
can
take
on
extension,
work
in
this
working
group,
and
that
could
be
something
that
just
like
tomorrow,
we're
having
load,
balancer
and
and
the
unreliable
delivery
proposed
extensions.
You
can
propose
an
extension.
The
only
question
on
my
mind,
for
that
is
timeframe,
whether
it's
better
to
do
that
in
the
zurich
interim
or
which
we've
announced
or
whether
it's
better
to
wait.
A
We
have
a
broader
audience
for
it
in
in
the
vancouver
meeting,
but
we
can
take
that
discussion
offline
and
find
the
right
time
for
for
you.
It
so
I
think
that's
our
from
from
listening
to
the
mic
line
and
what's
happened
in
the
room,
I
think
that's
the
plan
for
it
I
think
we'll
close
this
issue
as
not
in
scope
for
quickly
one
but
anticipate
an
extension
draft
that
we
can
discuss
in
the
future
is.
Is
everyone
happy
with
that
I'm
seeing
nodding
heads
and.
S
Okay,
I'm
talking
right
and
yeah
we're
with
you
also
to
try
and
make
sure
there's
a
home
for
this,
because
if
the,
if
there
is
energy
here
to
develop
this,
then
it
should
be
here
and
if
there
are
central
mechanisms
that
are
generic
across
things,
then
maybe
they
could
be
in
this
work
here
in
TSP
WG.
But
we
should
do
this
in
one
place.
Your
place
should
be
a
great
place
if
you've
got
an
extension.
Okay
great
definitely
make
sure
we
can
coordinate
that
any.
A
L
L
A
L
A
A
L
So
step
forward,
basically,
the
question
is:
when
you
put
an
ALP,
an
identifier
in
the
TLS
handshake,
are
we
talking
about
the
application
layer
LPN
or
are
we
talking
about
the
entire
stack,
which
is
h3
all
the
way
down
through
the
transport
that
it
uses?
Now
right
now,
that's
kind
of
a
a
given,
because
we
only
have
quick
v1
but
in
fact
we're
actually
we're
doing
interrupts.
L
L
L
We
expect
that
at
least
some
quick
versions
we'll
keep
a
consistent
interface
to
the
application,
or
at
least
we'll
be
superset
to
the
'quran
interface
and
therefore
that
h3
would
work
over
those
quick
versions,
but
those
application
interfaces
are
not
invariant,
so
there
will
also
be
some
quick
versions
that
don't
work
with
h3
and
we
need
to
figure
out
how
we
express
that
and
what
what
we
do
with
that.
So
next.
L
So
what
do
we
do
when
there's
a
quick
to
that
h3
works
over
one
option?
Is
we
meant
a
new,
a
LPN
token
h3
q2?
And
we
say
the
tokens
refer
to
the
entire
stack
another
one
is
to
say
that
the
client
will
offer
h3
over
quick
and
if
you
speak
quick.
Hopefully
you
know
that
that
application
protocol
can
be
spoken
of
that
transport.
L
L
L
We
have
this
draft
for
version
negotiation
where
potentially
you
could
be
doing
the
negotiations
at
the
same
time
and
you
could
choose
the
transport
version
and
application
version
combination
that
you
like
new
the
trade-off,
but
we
still
have
to
have
a
fallback
path
to
the
other
type
of
version
negotiation
if
they're
not
compatible,
but
here
we're
talking
about.
We
really
have
two
concepts
of
compatible
versions,
because
this
is
compatible
with
the
a
player.
So
next,
so
these
two
approaches.
L
If
we
stick
in
renault
service,
we
might
bring
back
the
quick
version,
hint
that
says:
I
speak
h3
and
I
can
speak
it
over
these
quick
versions
or
maybe
we
have
to
make
multiple
advertisements
of
h3,
which
implies
quick
one.
We
also
have
to
advertise
h3
q2.
We
also
have
to
advertise
h4,
which
might
imply
a
particular
quick
version,
and
that
list
could
get
kind
of
long.
So
we
have
to
figure
out.
Do
we
want
complicated
and
flexible?
Or
do
we
want
simple?
But
everything
is
rigid.
L
L
So
HTTP
3
can't
define
how
it
works
with
quick
2,
because
quick
2
doesn't
exist
yet
it
can
define
itself
in
terms
of
abstractions.
We
already
have
a
lot
of
that
in
the
interface
between
the
two
documents.
Now
we've
parceled
out
required
operations
for
connections
and
streams.
If
we
maintain
those
operations
as
being
possible
in
a
future
version
of
quick,
then
h3
should
work,
but
there's
we
don't
have
a
name
for
that
interface.
This
is
not
object-oriented.
Programming
where
we
can
say
requires
interface,
streamable,.
L
L
So
one
option
is
to
say
we're
not
going
to
solve
this
now
that
seems
to
be
a
popular
enter
in
the
working
group.
These
days
we
could
say
that
HTTP
3
requires
quick
version
1
and
if
quick
V
2
keeps
the
same
shape
of
the
application
interface,
then
quick,
V
2
can
extend
the
definition
of
the
age
3
al
PN
token,
or
we
can
have
a
separate
graph
that
does
that
or
one
that
mints
a
new
al
pn
tok
and
we
can
solve
that
later.
But
H
3
is
not
the
only
protocol.
L
E
Sure
so,
sometimes
just
just
to
clarify
this
is
to
avoid
that
situation,
where
you
have
quick,
V,
2
and
one
side
thinks
that
HTTP
3
is
fine
to
run
on
quickly
too,
but
the
other
is
not
aware
of
the
fact
that
it.
This
is
the
case,
and
you
end
up
with
some
form
of
negotiation
failure.
So
we
need
we
needed
to
be
the
case
that
when,
when
you
implement
this
new
combination
of
things,
you
can
be
sure
that
the
signaling
that
you
provide
to
the
other
side
will
be
understood.
E
L
K
K
We
could
they
decide
that,
like
you
know
that
that
the
brief
things
entirely
but
I,
just
like,
like
the
you,
could
make
the
decision
that
you
could
make
that
decision
and
yet
in
the
situation
where
both
sides
are
so
confused,
I
just
find
very
impossible.
I
mean
it's
not
like
you're,
not
like
you're,
not
like
trying
to
private
that
intersection
of
like
everything
which
side
supports
when
the
client
starts
at
notre
closer
to
HTTP.
A
L
Started
yeah,
let's
finish
so
one
more
there
it.
If
you
do
Noguchi
one
negotiate,
the
transport
first
and
then
the
a
player
which
is
kind
of
what
TCP
does
you?
You
have
TCP,
and
only
then
do
you
see
the
TLS
handshake
to
negotiate
the
a
player
in
this
kind
of
weird
hypothetical
situation
where
there's
an
h4
that
it
doesn't
support.
Quick
if
you've
already
negotiated
the
to
run
quick.
L
You
just
won't
include
that
in
the
Oh
al
pin
offer
and
the
server
won't
know
that
it
could
have
done
h4
if
it
had
only
chosen
quick
v1,
it's
a
little
weird.
Hopefully
we
continue
to
support
things
as
we
get
bigger,
but
it
means
that
the
server
is
not
operating
with
full
or
full
knowledge
of
what
the
possibilities
are.
Next.
L
What
the
document
says
right
now
the
tls
document
says
that
the
application
protocol
can
restrict
which
transport
versions
are
acceptable
and
I.
Think
that
is
probably
the
right
choice.
We
have
the
earth
right
now.
Htv-3
says
that
can
be
used
with
any
version
of
quick
where
the
crypto
handshake
is
TLS,
which,
given
that
that
says
nothing
about
what
the
interface
is
I
think
there
has
to
be
a
change
in
h3.
The
change
could
be.
We
require
quick
v1
until
other
west
dated
yeah.
E
So
so
mutton
Thomson,
this
philosophical
difference
has
existed
since
we
published
RFC
70
301,
because
everyone
has
assumed
a
very
different
model
of
how
a
OPN
operates.
Now
we
have
an
identifier
now
that
identifies
something
that
maybe
Ted
thinks
means
this
and
dkg
thinks
means
something
else,
and
we've
been
happy
up
until
this
point.
E
T
Tommy
Polly,
Apple,
so
I
think
we
should
actually
absolutely
update
the
h3
texted
to
redefine
what
it
requires.
I
would
urge
that
we
don't
you
know
we
shouldn't
say:
oh
this
requires
TLS
as
the
the
one
thing
I
don't
think.
We
should
also
say
that
it
requires
quick,
v1,
maybe
great.
If
we
can,
you
have
some
language
of
it,
describes
the
transport
services
offered
by
a
quick,
v1
layer.
T
I
mean
essentially
saying
you
need
this
shape
right,
because,
if
you're
running
h2
you
require
a
essentially
a
TLS
stream
interface,
you
know
secure
stream
interface
and
the
things
that
we're
talking
about
that
would
potentially
break
h3
would
be.
Oh,
you
no
longer
have
reliable
streams
and
like
something
fundamentally
in
that
transport
interface.
T
So
this
is
a
great
conversation.
We
won't
talk
about
how
it
evolves
into
the
future.
That's
a
thing
for
taps
and
stuff
like
that,
but
I
think
we
shouldn't
necessarily
make
the
decision
about
what
the
ALP
and
encoding
is
going
to
evolve
into
in
the
future
until
we
get
to
that.
But
I
think
really
h3
needs
to
be
tied
to
whatever
mapping
of
the
transport
we
have
on
quickly
one
today
and
that
could
work
for
quick
review.
But
if
quickly
decides
to
ditch
streams,
then
we'll
have
to.
L
A
P
Bit
please
go
on
Kyle
nekritz
when
we're
doing
the
negotiation
for
the
transport
verse
and
that's
something
that's
generally
going
to
require
round
trips
or
a
round
trip.
If
you
don't
get
your
first
choice,
whereas
the
ALP
n
negotiation,
essentially
piggy,
backs
off
the
round
trip,
that's
required
for
a
TLS
anyway,
and
if
we
try
to
shove
them
together,
then
we
lose
the
possibility
of
doing
some
a
ALP
n
negotiation
that
doesn't
add
additional
round
trips
and
that's
a
feature
I'd
really
like
to
keep.
H
David's
Kazi
Google
so
first
to
respond
to
eckers
point
about
how
this
has
never
been
a
problem
in
TLS,
the
conceptual
interface
or
SLA
from
TLS
to
its
application
is
dirt
simple.
It's
a
byte
stream,
that's
altars
to
it
pretty
much,
and
so,
when
you
can
totally
have
yeah
TLS,
101,
1,
1,
2,
1,
3
versus
HTTP,
1,
1
or
2
that
interface
between
them
is
the
same.
So
these
are
completely
independent
problems
in
quick
we've
taken
the
layering
model
and
remove
the
layers
of
indirection
to
get
better
performance,
so
that
causes
these
problems.
H
H
Tommy's
point
the
idea
of
defining
going
full
taps
as
I
like
to
call
it
and
defining
all
of
the
properties
of
these
things
is
hard.
The
taps
working
group
as
well
have
for
the
years
and
I
really
want
to
avoid
being
in
a
state
where
one
person
thinks
it
means
X,
and
one
person
thinks
it
means
Y,
and
then
people
like
I
was
saying
disagree
on
whether
it's
gtb/4
fits
on
could
be
true
or
not.
So
how
about
we
keep
this
dirt
simple
and
contained
to
what
we
know
about
today.
H
So
I
really
like
the
proposal
of
HTTP
3
means
quick
view
on
period.
If,
tomorrow
someone
has
quick,
V
2,
then
they
can
rate
a
write.
A
one-page
RFC
that
is
this
works.
Http
three
words
would
quick
v2.
The
only
downside
here
is
that
we
would
have
to
spend
a
few
more
bits
and
in
the
LPN
and
call
it
h,
3q,
2,
so
I
think
that's
the
best
way.
One
thing
all
that
as
well
is
a
LPN
is
a
concept,
that's
specific
to
TLS,
quick,
the
invariants
don't
necessarily
have
TLS.
H
If
someone
wants
to
build
HTTP
over
quick
with
a
custom,
handshake,
I'm,
sorry,
a
custom
key
exchange
mechanism
which
we're
probably
looking
into
at
Google
for
some
corporate
stuff,
that
has
some
magic
crypto
stuff
in
a
corner
somewhere
we'll
have
to
defined
that
internally
and
it
might
not
even
use
the
LPN
at
all.
So
anyway,
let's
just
keep
this
simple.
Have
the
string
h3
mean
she
will
do
a
quick
view
one,
and
then
we
can
solve
that
problem
when
we
get
there
later,
mainly
in
the
interest
of
shipping.
This
sooner.
C
Hi
I'm
Emily
I
came
up
here
to
disagree
with
David,
but
then
he
made
sense
so
I'm
going
to
agree
with
him.
I
think
I
think
that
this
actually
should
be
deferrable,
because
the
actual
question
that
you're
asking
here
is
much
harder
than
you
think
it
is
you've
taken
the
idea
of
well.
The
big
question
is
much
harder
than
you
think
it
is.
You
already
think
it's
pretty
hard,
it's
harder
than
that.
C
The
the
easy
question
is:
can
we
just
bind?
Can
can
we
so
the
problem
is:
is
we've
taken
the
concept
of
a
LPN
which
was
essentially
security
layer
trying
to
abstract
what
an
application
layer
is
just
like?
That's
just
an
application.
I
don't
really
care
about
it
and
it
doesn't
the
transport
doesn't
matter
because
it's
always
going
to
be
TCP
forever.
The
the
the
word
layer
there
is
wrong,
but
the
transport
layer
actually
wants
to
talk
about
or
the
transport
or
the
security
service
I'm
not
completely
screwed.
C
Up
on
this
see
what
happens
when
you
put
too
many
layers
in
a
stack.
What
it
actually
wants
to
talk
about
is
the
whole
stack
rate,
so
it
should
actually
be
called
Aspen
how
they
OPN
it's
the
application
stack
of
protocol
negotiation
provocation,
protocols
to
activate
amen.
C
So
the
bigger
question
of
like
of
how
do
we
do
this?
We
need
to
think
more
about
what
we
mean
about
a
stack,
the
fact
that
quick
has
a
much
more
complicated
interface
to
it,
transport
that
orbit
that
hb3
has
much
more
complicated
interface
to
its
transport
than
anything
over
TCP
everwood
means
that
you
might
think
that
you
can
do
things
in
that
top
thing.
Let's,
like
hey,
these
are
going
to
layer
cleanly,
but
you'll
always
be
wrong
right.
There
will
always
be
some
subtlety.
C
That
means
that
there's
some
dependency
here
that
won't
that
will
trip
that
up
and
then
you
have
to
have
an
exception.
I
think
that
the
longer
more
complicated
discussion
is
probably
going
to
land
on
the
bottom
one
identify
this
I
can
come
up
with
a
way
to
do
that.
That's
not
going
full
taps
unless
you
mean
to
come
to
taps
it's
this
afternoon,
but
for
now
I
think
we
just
basically
say
h3
is
q1.
C
K
Yeah
TL
DR
I
mean
we
had
a
bunch
of
points
where
we
like
knew.
We
punch
it
out
like
the
exact
way.
We're
gonna
spell
new
versions,
even
though
we
knew
that
probably
gonna
happen
case
in
point.
The
the
key
label
expansions
where
we're
calling
it
a
quick
as
supposed
a
quick
one,
so
I
think
this
perfectly
fine
is
all
this
h3
and
say
it
means
quickly
one
and
then
we
can.
When
we
get,
we
define
quick
v2,
we
can
define
decide.
We're
need
a
newly
opened
token
or
not.
K
At
that
point
with
that
said,
a
few
minor
points.
We
really
can't
like
to
find
the
semantics
of
a
OPN
here
any
differently
than
the
way
it
already
is
defined,
because
questions
so
need
some
liquid
e's
on
statement.
K
K
Like
in
one
three
first,
this
one
like,
if
you
have
like
odd
you
know
if
you
have
on
interacting
things
or
she's
like
I'm,
going
to
so
on
and
there's
always
a
tension
between
my
trying
to
get
the
optimal
comes
versus.
Having
this
like
giant
list
of
like
well,
I
mean
your
for
all
things
on
so
I'm,
not
too
sweated
about
that.
The
third
thing
is
just
wants
to
David
on
funny.
K
You
should
mention
that
TLS
has
a
straightforward
application
interface,
because
there's
the
thing
called
DTLS,
which
also
has
a
OPN
and
so
I
guess
my
thesis
is
nobody
ever
thought.
I,
don't
think
that
you
could
run
on
issue
p2
over
DT
OS,
and
that
would
be
cool,
but
I
didn't
actually
say
you
can't
do
that.
I
Denying
God
I'm
actually
surprised,
I
have
a
contrary,
opinion
here,
so
I'm
going
to
state
it
the
way,
I
understand
it,
and
we
don't
need
to
parse
this
here,
because,
obviously
it's
not
the
place
to
necessarily
do
it,
but
a
LPN
for
TLS
is
the
thing
that
sits
on
top
of
it.
My
understanding
is
application.
Was
it's
convenient
because
that's?
What
sat
on
top
of
TLS
in
this
key
is
the
thing
that
sits
on
top
of
TLS.
I
It
is
I,
don't
see
that
as
inflexible
when
I
understand
that
it's
rigid,
because
you're
specifying
the
whole
thing
that's
sitting
on
on
top
there,
but
it
is
also
the
one
option
that
to
me
leaves
more
choices
in
the
future.
One
thing
to
keep
in
mind
is
that,
yes,
the
future
is
unpredictable,
but
we
are
putting
a
lot
into
quick,
v2
or,
if
they're
hoping
that
we
will
come
up
with
a
new
version
of
quick
very
soon,
but
I.
I
Don't
think
anybody
in
the
room
is
hoping
that
we
will
come
up
with
a
new
version
of
HTTP
very
soon,
and
we
may
or
may
not
want
to
do
two
couple,
those
things
in
an
indirect
way
where
we
say
that
HTTP
3
implies
quickly
1,
then
we
have
to
figure
out
how
to
wedge
out
of
that.
So
it
just
seems
to
me
that
the
simple
and
easy
solution
right
now
is
to
combine
the
two
and
to
say
that
the
LPN
is
h,
3q
1
and
we
can
easily
say
h,
3q
to
the
problem
of
scaling.
I
A
L
E
M
L
A
L
A
A
T
Tell
me
Polly
Apple,
so
as
one
of
the
people
who
brought
up
talking
about
the
mapping,
I
also
want
to
say,
like
we
don't
I,
don't
really
want
to
open
that
whole
can
of
worms
here
and
I.
Don't
really
know
if
we
have
the
right
information
to
decide
this
to
some
degree,
I
almost
just
want
to
see
like
a
minimal
PR,
because
I
think
it's
fine
to
say.
T
Yes,
h3
uses
quick
v1,
it's
more
just
kind
of
like
the
text
around
that
paragraph
of
how
do
we
phrase
the
flexibility
of
how
we
would
update
this
later,
to
allow
h3
to
also
work
over
quick
too,
and
it's
really
probably
just
kind
of
the
nuances.
I,
don't
think
we
should
have
took
a
full
mapping
document
like
let
us
do
that
in
taps
and
that'll
be
fun
to
work
on.
But
like
that's
not
for
this
document,
we
shouldn't
hold
that
up.
Okay,.
A
P
K
I
I
think
the
minimal
thing
here
is
to
say:
h3
implies
Q
1,
and
then
we
can
punt
all
the
rest
up
till
later,
it's
worth
and
then
I
think
there
are
a
number
of
options
available
to
us.
What,
when
you
find
a
d,
qu
qu
one
one
that
has
not
that
mean
like
I
know,
there
was
like
some
hate
for
like
actually
writing
this
down.
Like
one
thing
we've
done
in
tell
us
is
like
we
have
like
a
column
of
like
in
their
registries.
K
It
says
he
uses
for
DTLS
and
some
things
you
can
and
something
you
can't
and
like
I.
Think
for,
like
the
number
of
application
protocols
are
Paul's,
are
gonna,
run,
never
be
defined
by
ITF
and
run
over
quick
in
the
next,
like
five
years
like
to
the
list,
just
listening,
which
one's
work-
okay,
it's
not
gonna
be
like
an
enormous
problem.
O
This
is
Daniel
con
Gilmore,
just
say:
h3
implies
quickly
one.
The
idea
that
this
whole
working
group
is
going
to
successfully
describe
what
the
specific
properties
are
of
of
q1.
That
HTTP
through
relies
on
in
any
reasonable
period
of
time
is,
is
bananas,
it's
not
gonna
happen
just
say:
h3
equals
Q
one
and
we
will
figure
it
out.
It
Nick.
V
I
I
A
I'm
gonna
do
hums.
1
is,
if
you
believe
we
should
close
this
issue
by
just
saying
that
H
3
is
quick
version
1.
There
might
be
a
little
bit
of
editorial
wiggle
room
around
that,
but
no
detail.
The
other
would
be
we're
gonna
take
some
time
and
do
some
work
to
try
and
describe
the
properties
we
want
from
quick
that
mean
h3.
Does
that
make
sense?
A
Ok,
so
if
you
believe
that
we
should
just
stop
and
say,
h3
is
q1,
please
come
now
and
if
you
believe
we
need
to
spend
more
time
on
this
and
try
and
do
this
in
a
properties
based
approach.
Please
come
now,
that's
pretty
clear.
Okay,
thank
you!
Mike
we'll
return
tomorrow
and
we'll
talk
about
HTTP
and
recovery
issues,
talk
about
extensions
and
talk
about
the
future.
Thank
you.