►
From YouTube: IETF106-TSVAREA-20191121-1740
Description
TSVAREA meeting session at IETF106
2019/11/21 1740
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
I'm
talking
about
this
is
our
agenda.
Today
we
have
a
one-hour
slot,
so
we
have
like
the
usual
updates.
We
have
already
a
note-taker,
that's
Martin.
Thank
you.
I
will
watch
the
job
a
little
bit
and
I.
Think
blue
sheets
are
also
running.
So
that's
great
I
go
through
the
usual
slides,
what's
going
on
in
the
area,
and
then
we
have
like
a
few
adjustment
points.
The
chairs
would
like
to
the
80s
would
like
to
talk
about.
Then
we
have
about
like
20
to
25
minutes
to
talk
about.
A
So,
first
of
all,
I
just
realized
that
I
missed
up
the
slide
when
you
can't
read
half
of
it,
but
we
would
like
to
think
our
review
team,
so
that
has
been
working
very
well
for
the
last
like
year
or
two
or
something
like
that.
We
have
like
three
November's
that
sky-high
rolls
in
sweat
and
Martin.
Duke
very
welcome
on
the
team
and
thank
you
very
much
for
your
service
and
we
have
one
person
stepping
down.
That's
Allison
I,
don't
think
I
see
her
yet,
but
she
has
been
on
the
on
the
area.
A
C
A
This
is
the
status
of
the
working
group.
I.
Don't
think
we
have
to
go
through
everything
in
detail.
One
announcement
is
that
in
the
next
months
before
the
Vancouver
meeting,
the
MP
TCP
working
group
will
actually
close
this
time
for
real.
They
finish
their
Charter.
They
published
all
the
documents
and
any
additional
or
any
future
MP
TCP
work
can
like
go
back
to
the
TCP
em
working
group
into
maintaining
state.
So
that's
very
good.
I.
C
A
Yes,
we
have
a
couple
of
new
documents
in
the
editor
cute.
This
looks
like
as
if
we
didn't
do
any
work,
there
was
no
new
RFC
published
between
now
and
in
the
last
meeting,
but
like
they
are
about
to
be
published.
The
stuff
that
was
in
the
editor
took
you
from
last
time.
So
there's
that,
like
as
always
steady
progress
was
a
couple
of
of
documents.
A
I
really
enjoy
working
with
you
guys,
but
like
we
also
have
some
media
discussions,
sometimes
and-
and
we
all
have
to
remind
ourselves
from
time
to
time
that,
like
we
reshape
this
community,
we
can
influence
like
in
this
community
how
we
want
to
work
here
and
we
can
be
active
about
it.
We
can
like
figure
out
how
we
want
to
behave
ourself,
but
we
can
also
talk
to
others
about
it
and
when
we
all
can
do
something
to
make
this
a
nicer
and
better
community
that
we
like
to
work
in
and
that's
really
important.
A
Magnus
and
I
also
talked
quite
a
bit
about
sharing
in
the
transport
area
area,
so
for
the
last
at
least
two
years
we
actually
didn't
get
any
new
working
groups.
The
situation
was
very
stable,
but
that
also
meant
that
we
couldn't
like
get
any
new
people
in
to
share
positions
to
get
experience
about
sharing,
and
this
is
usually
a
really
good
opportunity
to
train
up
new
people
who
also
might
become
80
at
some
point,
and
but
we
didn't
have
this
opportunity,
so
we
also
sought
about.
A
Maybe
you
know
rotating
chairs
a
little
bit
I
was
thinking
was
actually
that
the
cup
of
coops.
We
have
that
like
two
long,
lasting
maintenance
work,
that's
the
groups
where
you
can
actually
exchange
chairs
from
time
to
time
and
work
in
like
kind
of
train
up
new
chairs,
while,
like
small,
very
focused
groups,
you
might
want
to
have
more
continuous
tea,
but
we
also
you
know.
We
also
to
make
any
kind
of
decisions.
We
try
to
talk
to
the
chairs.
A
Of
course
we
try
to
talk
to
the
community,
but
like
also,
if
there's
any
feedback
or
any
conflicts
or
problems.
We
should
know
about.
You
really
need
to
talk
to
us
and
provide
input
to
this,
and
of
course,
you
can
also
raise
your
hand
if
you
would
be
interested
in
sharing
and
be
more
involved
in
that.
So
we
try
to
like
have
an
eye
on
that.
We
try
to
manage
the
things
as
good
as
possible
and
we
will
see
if
there's
some
movement
in
the
in
the
next
month.
A
So,
but
this
light
is
also
up
not
only
to
request
feedback
and
to
inform
you
about
it,
but
also
to
ask
you
about
what
your
opinions
is
about.
What
should
we
do
like?
How
often
should
we
exchange
chairs?
When
should
we
exchange
or
certain
tribute
to
it
at
all
like?
If
you
have
any
thoughts,
you
have
a
chance
to
speak
up
now.
If
you
would
like
to.
E
Spencer
Dawkins,
one
of
the
one
of
the
things
that
I
wish
I
had
done
differently
is
transport.
Area
Director
was
explicitly
asking
for
key
lives
from
people
in
positions
that
are
serving
the
community,
because
we
recognize
that
there
are
other
people
who
could
serve,
but
people
don't
don't
want
to
let
the
community
down
by
saying
you
know:
I'm,
not
gonna,
do
this
anymore,
but
just
it
you
know
it
might
be.
It
might
be
helpful
to
just
ask
people
from
you
know
periodically.
E
A
F
I
won't
mention
this
one
in
particular
have
had
less
than
the
number
of
ADEs
possibility
that
we
want
at
various
times
and
we
need
to
grow
those
people
and
we
get
them
from
the
chairs.
So
we
should
get
you
know.
Yes,
I
mean
no
Ronnie.
How
long
have
you
chaired
some
of
your
working
groups
like
forever
and
you've
done
an
awesome
job,
but
but
could
we
have
trained
more
new
people
and
had
a
better
pool
of
people?
That
would
be
a
great
thing.
A
Thank
you.
This
hope
we
can
actually
up
on
the
is
you
on
Sunday
and
it
will
reflect
it
back.
So
transport
we're
actually
quite
small
area,
and
we
don't
have
that
many
positions,
but
that's
also
a
good
remark
for
the
general
consideration:
yep,
okay
and
then
we
also,
we
thought
we
talked
the
opportunity
to
tell
you
a
little
bit
about
the
ports
registry,
because
it's
also
in
the
responsibility
of
the
transport
area
or
the
transferred
area
directors.
Actually.
A
So,
first
of
all,
we
would
like
to
take
the
opportunity
as
well
to
say
a
big
thanks
to
those
people
as
well,
because
they
do
have
a
constant
load.
We
have
like,
we
get
requests
like
every
week
and
there
and
they
review
them
and
they
have
to
look
up
documents
and
they
go
for
some
back
with
the
requesters.
So
there
is
actually
a
significant
load
here.
A
Thank
you
very
much
to
these
people,
but
then
we've
been
also
trying
to
be
in
touch
with
them
and
figuring
out
how
to
make
the
process
more
smooth
or,
like
figuring
out
where
the
problems
are
so
we've
been
discussing
about
potentially
also
updating.
Some
of
the
guidance
documents
we
have
around
import
registries
because
we
see,
for
example,
very
often
that
we
get
requests
that
are
only
for
a
closed
domain
and
not
for
the
internet
as
a
whole,
but
also
it's
not
clear.
You
know
it's
not
defined
somewhere.
A
What's
the
what's
the
closed
domain,
or
this
is
actually
not
spared.
I
was
out
explicitly.
We
get
a
lot
of
requests
where
people
actually
don't
need
a
fixed
port.
They
could
use
some
kind
of
discovery
mechanism
or
some
kind
of
dynamic
port
range,
and
so
we
would
like
to
provide
more
guidance
about
these
kind
of
things.
There
potentially
might
be
a
new
document
coming
up
so
just
to
make
it
work
and
to
like
get
the
point
a
little
bit
closer
to
you.
We
also
have
some
numbers,
so
that's
the
numbers
of
requests.
A
We
got
for
the
last
two
years
and,
as
you
can
see,
it's
a
total
of
about
hundred
I.
Think
if
I
don't
miss
the
math
completely
up
so
about
hundred
requests
and
about
that
of
them
gets
assigned.
But
of
course
all
of
them
have
to
be
reviewed.
Of
course,
they're
like
they
are
not
equally
spread
out
over
the
year,
but
as
you
can
see,
they're
actually
like
whicker's
kind
of
on
a
weekly
basis.
Basically.
A
Actually,
this
is
another
thing.
I
would
like
to
thank
the
experts
for
because
they
not
only
say
no,
they
do
a
lot
of
like
protocol
Design
Consultant
there,
a
lot
of
because
it's
just
like
very
random
protocol
requests.
We
get
right,
everybody
thinks
they
need
a
port,
for
they
did
a
tiny
protocol.
They
use
between
their
two
computers.
G
One
of
the
lessons
we've
learned
is
that
if
you,
if
you
put
the
experts
in
a
position
of
defender
of
the
product,
that
the
the
internet,
architectural
purity
or
what
have
you,
you
know
with
this
situation
right
here,
and
that
looks
good,
because
it
means
that
you're
only
getting
the
protocols
that
you
think
of
a
legitimate
from
what
some
definition
of
legitimate
I
mean.
We
were
trusting
the
judgment
of
those
people
on
that
to
a
large
extent.
But
what
we're
also
doing
is
driving
people
into
patterns
of
use.
That
may
be
destructive,
which
is
in.
A
A
A
H
A
D
No,
but
at
the
same
time
I
have
these
requests
rate,
etc.
I
think
we
still
we
have.
We
are
nowhere
near
of
filling
with
the
current
request
rate
with
no
world
near
of
filling
the
available
space
in
the
next
50
years,
but
it
is
so
limited,
but
not
that
fast
and
I
think
it's
something
that
could
be
discussed
or
saying
the.
D
I
J
J
K
A
So
but
part
of
kind
of
maybe
updating
some
of
the
recommendations
we
have
is
that
this
definition
about?
What's
you
know,
what's
internet
wide
and
window,
you
need
a
port
and
we're
not
it's
not
very
clear.
So
that's
definitely
something
that,
like
the
port
team
is
discussing
about,
and
we
want
to
have
more
clarity
on.
L
I
So
hi,
my
name
is
Mark
Nottingham
I'm,
one
of
the
chairs
of
quick.
Are
we
still
doing
that
I
thought?
We
were
over
that
okay
I'm,
not
a
transport
person,
but
I
do
play
one
on
TV
Laura's
couldn't
be
here
so
I'm
taking
his
place
so
status
of
the
work.
Overall,
we
have
two
of
the
documents
in
what
we
call
the
late
stage
process,
so
the
working
group
is
agreed
to
effectively
raise
the
bar
for
new
issues
so
that
we
can
concentrate
our
efforts
on
those
documents.
I
The
other
two
major
documents-
recovery,
an
HTP,
are
about
to
join
it
those
documents
in
the
light
stage
process
and
we're
seeing
the
inter
up
steadily
improving
over
time.
The
plan
moving
forward
is
is
that
we
are
hoping
we
can
do.
A
working
group
last
call
on
these
documents
around
the
end
of
the
year.
I
Let's
get
the
review
from
the
various
folks
we're
going
to
use
them
and
operate
them
and
deploy
them
and
implement
them
to
make
sure
we've
got
it
right
and
in
the
meantime
we
went
to
after
we
say
issue
that
working
group
last
call
take
a
period
of
time
where
we
pause.
We
don't
do
a
lot
of
active
development
on
the
the
issues
around
the
the
documents,
but
we
try
and
edit
orally
improve
them,
but
especially
get
implementation
deployment
experience.
I
The
working
group
really
wants
to
see
this
protocol
get
some
deployment
experience
in
its
current
form
in
its
specified
form
before
we
ship
the
RFC's,
and
so
we
want
to
take
a
pause
and
probably
not
send
it
to
the
isg
until
something
like
the
middle
of
2020.
So
this
is
the
current
plan
for
the
documents.
Of
course,
all
plans
can
change,
so
we'll
see
how
it
goes,
and
so
this
brings
up.
I
You
know
the
notion
that
the
there's
a
lot
of
quick
related
work,
that
people
have
questions
about,
and
we've
identified
a
number
of
different
kinds
of
things
that
have
come
up:
new
versions
of
quick
extensions
to
quick
to
core
quick
applications
that
use
quick
other
than
HTTP,
of
course,
and
other
random
things
that
have
popped
up,
and
so
Lars
and
I've
been
set
up
a
wiki
page
to
track
these
things
on
our
wiki
on
github.
So
we
can
have
a
one
place
where
you
can
see
all
the
quick
related
things
that
might
happen
one
day.
I
I
It
would
presumably
happen
in
the
quick
working
group,
but
of
course,
we'd
need
to
reach
harder
to
do
that,
so
that
that's
kind
of
versioning.
Next
up,
oh
that's,
smaller
type,
sorry
extensions,
too
quick.
So
these
are
generic
extensions
to
quick
they're,
not
specific
to
any
one
application,
but
they're
extending
the
capability
of
quick
or
doing
new
things,
and
there's
there's
lots
of
in
in
this
as
well.
I
We
do
have
some
capacity
opening
up
to
discuss
these
things
in
the
working
group
because,
as
I
said,
we're
gonna
take
a
pause
for
a
little
while
and
so
right
now.
Just
in
this
meeting,
we
started
talking
about
three
drafts:
a
quick
load,
balancers,
quick
version,
negotiation
and
quick
datagrams
and-
and
we're
probably
going
to
put
out
a
call
for
adoption
on
at
least
some
of
those
very
soon
I
think
we
need
some
revised
drafts
and
some
other
discussions,
but
that's
the
plan
for
those.
I
There
are
some
other
things
that
people
have
talked
about
so,
for
example,
the
lost
bits
draft.
We
discussed
a
little
bit
this
week
and
the
multipath,
which
is
in
our
Charter,
but
we
don't
have
a.
We
have
a
proposal,
but
we
haven't
discussed
it
much
yet
and
there's
zero
RTT
bdp
stuff,
which
is
a
little
bit
newer.
I
If
you
have
one
of
these
things-
and
we
haven't
already
discussed
it,
come
and
talk
to
Lars
and
I
will
try
and
assess
interest
in
the
group.
Try
and
schedule
a
time
in
a
meeting
whether
it's
an
interim
meeting
or
and
one
of
the
main
IETF
meetings
where
you
can
come
and
present
it
to
the
group
to
get
feedback
and
we'll
go
through
a
process
to
decide
whether
the
group
wants
to
adopt
it
and
if
so,
when
the
appropriate
time
to
do
that
is
we
are
currently.
I
Our
Charter
is
fairly
restrictive
about
doing
extensions
to
quick
and
so
to
do
these
things.
We
need
to
reach
Artur
we're
just
about
to
start
talking
about
Ray
chartering
for
these
three
or
some
subset
of
them
right
now,
and
for
any
additional
extensions.
We'd
need
to
do
a
recharter
as
well.
I.
Think
talking
to
the
area
director
is
having
a
little
bit
of
friction
there
as
good
just
to
pace
the
work
of
the
group
out.
So
we
don't
take
on
too
much
at
one
time.
Question
mark.
J
David
Blackwell
real,
quick
another
one
put
your
radar
screen,
there's
a
second
bits
draft
in
the
in
the
same
said,
general
area
of
exposed
some
bits
so
to
show
what's
going
on
with
with
the
with
the
transport
protocol,
it's
only
tht.
We
did
WG
agenda
dates
it
it's
in
about
the
same
areas,
law
as
lost
bits.
I
I'm
sure
there's
other
stuff
out
there,
but
but
the
idea
and
talking
the
area
directors
that
is,
is
the
locus
of
future
extensions
to
quick
what
will
happen
in
the
quick
working
group,
a
provided
we
successfully,
recharter
and
and
and
so
forth,
and
so
on.
We
need
to
balance
that,
of
course,
with
the
core
quick
version.
One
work
that
until
it
ships
is
always
going
to
take
priority,
but
but
this
is
the
plan
for
extensions
applications
that
use
quick.
I
I
But
we
don't
want
to
have
some
super
working
group
for
all
applications
that
happen
to
use
one
transport,
and
so
the
quick
working
group
won't
adopt
these.
You
know
I,
think
if
you
want
to
give
people
a
heads
up
sure
send
that
email
to
the
list.
Maybe
we
can
give
you
some
as
time
permits
time
in
a
session
if
you
want
to
advertise
what
you're
doing,
but
the
locus
of
those
discussions
shouldn't
happen
in
the
quick
working
group.
I
Of
course,
the
quick
working
group
will
always
be
available
to
consults
as
to
the
use
of
quick
or
at
least
well.
The
working
groups
live,
but
we're
not
going
to
actually
locate
those
discussions.
They're
the
appropriate
place
to
take
those
is
going
to
be
to
the
applications
area
so
dispatch,
or
they
already.
These
Martin
yeah.
G
Mon
Thompson
I
think
the
point
here,
that's
critical
is
that
we
need
to
think
of
quick
as
both
TCP
to
and
UDP
to,
and
we
this
area
probably
doesn't
want
to
take
on
all
of
the
work
for
all
the
protocols.
That's
doing
that.
Work
at
at
I
could
have
any
number
of
protocols
to
that.
That
list
and
your
other
their
absolute
and
we
that's
not
gonna-
that's
not
going
to
scale
out
we're
going
and.
I
G
G
And
I
think
one
of
the
things
that
will
happen
here
is
that
the
quick
working
group
will
will
probably
necessarily
be
involved
in
some
of
these
early
efforts
so
that
we
can
set
down
good
practices
and
come
and
make
sure
that
people
understand
the
protocol.
But
as
things
get
rolling,
that
understanding
will
spread
yeah
and
there's
no
way
that
we
can
continue
to
control
everything.
And,
yes,
arias,
not
really.
I
And
that's
next
one
point
actually
I
think
there's
a
lot
of
stuff.
We
haven't
written
down
in
terms
of
best
practices
that
one
need
to
work
out,
and
that
might
mean
new
documents
for
us,
but
they
wouldn't
be
specific
to
those
applications.
They'd
be
distilling
the
knowledge
that
we
figure
out
along
the
way.
I
Finally,
there's
other
things,
things
that
don't
really
fit
in
any
of
those
buckets
terribly
well
so
people,
you
know
if
talking
about
the
quic
network,
simulator
a
key
log
logging
format,
plugin
dies,
quick,
quick,
first
comm
lots
of
different,
interesting
things.
I
think
we
just
have
to
take
these
in
a
case-by-case
basis.
Some
of
this
might
belong
in
ops,
for
example.
There
other
places
some
of
it
might
just
be
for
people's
information,
but
come
and
talk
to
us
talk
to
the
era.
Directors,
we'll
figure
it
out
so
yeah
for
more
information.
I
That's
the
wiki
page
I
mentioned
quick
working
group
based
drafts,
wiki
related
activities.
It's
also
linked
from
the
quick
working
room,
homepage,
yeah
and
so
for
extensions
like
I,
said,
write
a
draft,
bring
it
to
the
quick
working
group.
That's
a
good
starting
point
for
applications,
ready
draft
bring
to
the
art
80s.
G
I
A
M
I'm
so
Martha
sort
of
stole
my
Thunder
as
brand
new
dispatch
chair
a
lot
of
that
stuff.
I
can
help
dispatch
and
those
questions
you
know
bring
together
the
year
sort
of
our
dairy
experts
who
can
help
find
a
home,
including
knowing
when
the
stuff
doesn't
belong
there.
So
it's
not
often
not
a
bad
step
for
an
application-level
protocol
like
the
ones
you've
enumerated.
H
So
gory
fairs
done
the
quick
for
sat-comm
bit
just
as
one
thing
and
that's
art:
can
you
speak
up
just
a
bit
Corey,
oh
yeah
I
can
speak
nice
and
slowly
and
clearly,
if
I,
try
and
on
the
quick
Forrest
calm
part.
Just
as
an
example,
there
are
a
number
of
different
pieces
in
there.
There's
the
idea
of
perhaps
using
a
proxy
for
something
there's
an
idea
of
perhaps
changing
a
transport
parameter.
There's
maybe
some
bits
that
need
to
be
changed
on
maybe
a
chain
to
some
mechanism.
H
H
I
That
I
think
I
shall
try
filing
an
issue
for
this,
exactly
if
it's,
if
it's
for
quickly
in
one
create
issues,
make
them
as
well
described
in
discrete,
as
you
can
for
things
for
the
future.
That's
a
lot
more
loose
right
now,
I
think
we'll
take
it
as
it
comes.
If
you
can
compose
things
into
drafts
that
are
just
extensions.
That
makes
a
lot
easier,
of
course,
or
just
applications,
or
you
know
some
combination
thereof.
I
If
it's
best
practices,
that's
a
different
kind
of
document,
and
we
have
you
know
we
have
the
opposite
manageability
documents,
it's
not
clear,
whether
other
kinds
of
how
do
you
use
quick
documents
or
in
scope
for
us,
but
we
can
talk
about
that
right
now.
The
working
group
is
heads
down
and
focused
on
shipping.
Quick
version
one-
and
so
you
know
as
that
gets
out
of
the
door
and
as
we
have
that
pause
I
talked
about,
will
have
more
time
to
step
back
and
think
about
other
things.
How
yeah.
E
I
So
that's
two
drafts
and-
and
we
had
a
quick
discussion
of
it
again
in
a
discussion
of
those
the
other
day.
I
think
the
agreement
of
the
group
is-
is
that
yes,
they're
still
important?
Yes,
we're
still
working
on
them,
but
because
we're
heads
down
and
quick
they're
not
getting
quite
as
much
attention
as
as
deserve
right
now
again,
that's
something
that
we
look
at
working
on
in
the
next
phase
and
I
think
we
still
want
to
ship
those
as
we
ship
the
court
documents
to
the
isg
I.
Think
that's
still
the
plan
yeah.
E
I
guess
one
of
the
questions
I
was
going
to
ask
and
please
don't
answer
it
now,
but
one
of
the
issues
with
the
management
and
operational
considerations
discussion
was
that
there
was
no
place
else
to
have
it
and
the
media
operations
working
group
recently
charter
made
it
2/3
the
way
through
their
first
meeting
before
they
started
talking
about
troubleshooting
quick.
There
is
a
place
to
send
this
work
and
make
you
know,
and
maybe
that
maybe
that's
a
good
thing
to
do.
If
you're
talking
about
rich
ordering
anyway,
you
all
will
do
the
right
thing.
N
Thank
you
on
a
lot
of
these
proposals,
especially
a
previous
I
tf's.
We
brought
them
to
things
like
dispatch
and
kind
of
a
lot
of
the
feedback
we
got
was.
This
sounds
interesting.
This
is
cool,
but
not
yet,
and
what
I'm
hearing
here
sounds
like
an
opening
of
the
floodgates
to
some
extent
which
I'm
loving.
Maybe
that's
not
the
right
term
mark
looks
uneasy,
but
as
in
maybe
the
not-yet
might
become
a
Oh.
N
B
N
A
So
then
I
don't
know
if
I
ever
said
not
yet,
but
what
we've
been
trying
previously
is
really
to
focus
on
getting
version
one
out
the
door,
concentrating
the
energy
of
like
the
people
in
the
quick
working
group
in
the
people
in
this
area
on
doing
this
work
task
and
we
are
basically
there.
So
we
should
also
do
some
work
around
it
and
we
should
use
the
protocols
we
develop.
So
yes,.
O
I
want
to
say
the
same
thing:
Spencer
mention
about
the
problem.
You
didn't
discuss
the
probability
and
management
drafted
that
are
already
there,
but
I
think
there
should
be
also
review
the
probably
in
operate
in
ops
area
because
they
have
to
do
there.
The
other
thing
is
about
the
applications.
If
we're
going
to
do
them,
I
mean
the
some
of
them
required
changes
in
what's
currently
in
v1
of
earthquake,
and
the
question
is:
are
there
any
guidelines?
Would
there
be
any
guidelines?
O
P
There
was
a
joke
a
while
back
that
we
needed
a
quick
area,
because
so
much
different
work
was
being
inspired
by
it.
Earlier
today
we
heard
about
some
work
and
TLS
to
do
some
retconning
of
their
record
layer
to
make
it
look
more
like
what
happened
in
the
split
that
ended
up
being
between
the
TLS
handshake
and
the
quick
record
layer.
We've
heard
all
of
these
applications.
P
We've
heard
these
things
that
wants
to
look
at
how
you
manage
different
applications
on
quick
and
so
I'm
gonna
suggest
that
we
actually
consider
running
an
experiment
for
a
couple
of
ITF
s
and
having
a
quick
dispatch
working
session
as
an
additional
session
to
the
to
the
regular
sessions
early
in
the
week.
So
the
people
who
are
part
of
this
flood
can
figure
out
where
their
particular
Eddy
should
go.
I
think
some
of
the
work
would
stay
here
and
transport.
Some
of
the
stuff,
in
particular
around
multipath
or
congestion
controllers,
might
really
belong
here.
P
A
great
deal
more
of
it
might
end
up
in
operations
or
applications
and
as
a
short
meeting
that
didn't,
try
and
concentrate
the
expertise,
a
meeting
that
concentrated
the
expertise
that
that
is
inherent
in
that
core
of
quick
people.
The
quick
police
that
you
were
just
talking
about
in
one
room
early
in
the
week
might
help
clarify
a
whole
bunch
of
stuff
later
and
does
a
you
know
to
session
experiment.
It
might
be
worth
trying,
as
I
said,
that
that's
the
bad
idea
ferry
for
Thursday
afternoon
idea
the
I
think
much
more
practical,
realistic
right.
P
Now
idea
is,
we
are
at
the
moment
of
Ackley's
216
right,
we
saw
this
was
HTTP,
it
was
built
for
one
thing,
and
suddenly
people
wanted
to
do
all
kinds
of
other
different
things
with
it,
and
it
went
wide
very
wide
across
the
the
landscape
of
the
internet
becoming
by
becoming
so
wide.
The
new
waste
of
the
internet
was
one
of
those
strange
things.
We
think
this
is
gonna
happen
again.
We
think
it's
gonna
happen
here,
and
this
is
one
of
the
few
times.
P
P
The
whole
point
of
a
Hitchhiker's
Guide
is
that
it's
written
for
any
of
the
audience's
who
plan
to
take
up
that
technology
and
it's
not
just
the
applications,
but
anybody
who
might
be
saying
I
want
to
do
this,
but
I
want
datagrams
with
it.
I
want
to
do
this,
but
I
need
multi
path
for
it.
It's
how
all
the
pieces
fit
together
so
that
if
they
have
an
understanding
from
TCP
and
Howell
NP
TCP
works,
they
see
the
differences
early
and
and
connected
to
the
ways
they
fit
together.
A
F
Cullen
Jennings
I
am
also
a
quick
enthusiast,
though
I'm
in
the
pale
shadow
of
David
but
I
hope
to
a
supplier,
I'm
motivated
I'm,
thrilled
to
see
quickest
open
for
business
with
things
like
Datagram
moving
forward,
because
that
enables
the
things
I
want
to
do
so.
I
am
taking
this
opportunity
to
make
a
shameless
plug
for
some
work,
we're
doing
over
in
art
around
how
to
encapsulate
audio
and
video
real-time
media
into
quick
or
web
transports,
or
various
forms
of
that
we're
sorry'
figuring
that
out
and
if
you
guys,
wanna,
join
us.
Q
Jong
clinic
so
I
have
an
abstract
question
and
then
a
concrete
instantiation
of
that
question.
So
the
abstract
question
is
you
know,
as
we
do,
applications
will
probably
develop.
You
know
requirements
that
it's
not
clear
to
us
what
they
actually
need,
whether
they
need
requirements
or
implementation
guidance
or
even
API
guidance,
and
do
that
the
particular.
The
thing
that
I'm
looking
at
is
a
number
of
applications
of
things
like
web
transport
needs
low,
latency,
congestion,
control
and
I.
Don't
know
if
that's
something
where
quick
protocol
would
need
to
change.
Q
I
L
Q
I
I
think
the
answer
I
can
give
you
right
now
is.
Is
that
you
know
the
people
you
want
to
be
talking
to.
You
are
going
to
be
generally
located
in
some
place,
like
the
quick
working
group.
Now
is
probably
not
a
great
time
to
talk
to
them
about
it
in
terms
of
the
workload
and
their
focus
next
year,
probably
whether
the
quick
working
group
is
the
right
forum
for
that
actual
discussion.
Tbd,
ok,.
G
Yeah,
not
in
Thompson
I,
think
what
we're
recognizing
here
is
that
the
quick
working
group
has
a
limited
capacity
to
do
additional
work
in
this
phase
between
now,
when
we're
sort
of
close
to
finished,
and
when
we
really
finish
on
this
thing,
and
so
there's
gonna
be
some
need
to
manage
the
priority
of
the
various
items
in
this
process.
I
tend
to
think
that
Ted's
idea
might
work,
given
the
timing
of
it
or
because
in
Vancouver
and
the
next
meeting
after
that,
which
I'd
forget
where
it
is
Madrid
we
should
be.
G
We
should
be
getting
a
few
more
of
these
things
and
Gauri's
question
is
really
interesting.
One,
because
there's
there's
a
unit
of
work
that
says
I
might
want
to
tweak
some
things
in
quick,
but
I
also
have
an
application
or
something
along
those
lines,
and,
and
so
how
a
group
like
that
discussed
specifically
that
and
a
quick
dispatch
really
does
sound
like
it's
got
all
the
wrong
connotations,
but
I'm
sure
we
can
come
up
with
a
name
for,
for
a
group
like
that
and
right
it'll
be
effective.
You.
I
G
R
Hi
Brian
Trammell
I
came
up
here
to
say
something
different
and
then
I
just
ended
up
coming
up
to
endorse.
Ted's
idea,
I
think
that
I
I
think
we
probably
don't
want
to
end
up
with
a
quick
dispatch
or
slow
and
lingering
or
whatever
we
call
it
permanently,
but
there
is
well
I
mean
he
said
the
quick
dispatch
was
bad.
So
what's
the
opposite
of
a
quick
dispatch?
Is
it's
worse?
Actually,
the.
R
The
if
you
hear
the
reason
that
I
wouldn't
just
say
hey,
we
have
dispatch.
We
have
that
process.
We
have
that
thing.
It
just
works.
Let's
do.
That
is
something
that
I
haven't
really
heard
surfaced
is
that
the
interface
that
most
other
transport
protocols
provide
to
the
application
is
here's
a
byte
stream
and
a
hope
and
a
prayer?
R
Take
your
things,
slap
it
on
the
ice
cream.
Everything
is
good
or
not.
The
interface
that
quick
provides
to
the
application
is
significantly
more
complicated
and
to
find
so.
This
is
why,
at
the
beginning
of
things
like
people
are
gonna
say:
oh
I
want
an
application
and
I
think
I
need
to
act,
quick
because
I
don't
know
what
the
interface
does.
That
thing
is
we
discussed
in
the
quickie
working
group
whether
or
not
we
wanted
to
take
on
the
work
to
do
an
API
draft
right
like
so.
R
You
know
it
goes
into
the
or
it
just
goes
into
sort
of
the
lore
and
we
figure
out
what
it
is,
and
it's
not
that
complicated.
We
don't
need
to
write
it
down
anywhere,
and
then
we
just
have
a
process,
but
I
would
I
would
say
that
one
of
the
things
we
should
do
with
that
process
is
figure
out
what
that
interface
is,
because
it
is
gonna
change
how
the
people
have
to
work
with
each
other.
Just.
I
R
Would
say
that
in
some
cases
the
the
the
answer
is:
don't
do
that
that's
going
to
be
painful,
but
I
think
that,
if
like
in
quick
since
we
don't
know
what
that
is
yet
release
we're
HT
many
knows
what
it
looks
like
for
quickly.
Don't
know
what
painful
is
yet
so
like
something
that
looks
painful
now.
It
might
actually
be
something
that
we
need
work
on
the
interface
so
yeah.
M
This
is
Patrick
I
like
quick
to
I'm.
Actually,
I'm
really
really
excited
about
a
number
of
things.
That's
gonna
do
that
I.
Think
I
really
don't
change
particularly
webviews
cases,
and
this
working
group
has
been
really
unique
in
a
couple
different
ways:
one
is
the
extended
focus
and
volume
of
work
that's
been
done
in
this
group
is
really
really
remarkable.
If
you
follow
it
closely,
it
is
I
mean
if
firehose
does
not
really
begin
describe.
What's
going
on
and
I
find
it
hard
to
simply
summarize.
M
Without
writing
the
PRS
I
can't
read
the
PRS
as
fast
as
other
people
are.
Writing
the
PRS,
slow
freaky,
but
the
fact
that
it's
composed
across
really
three
areas
has
been
I,
think
a
very
successful
experiment,
enlarged
and
necessary
for
where
it
is
and
yet
I
don't
feel
the
work
on.
All
three
of
those
aspects
has
proceeded
at
the
same
pace
within
the
working
group.
M
I
think
the
right
answer
is
more
coordination
than
centralization
as
you're
talking
about
in
farming
that
work
out
further,
and
so
some
citations
we
can
use
on
this
I
think
the
web
transport
one
is
like
is
a
good
thing
to
think
about
in
that
model,
and
it
does
have
transported
in
its
name,
but
it's
much
more
like
WebSockets
than
it
is
like
quick
itself
right.
It
has
to
polyfill,
it
has
with
other
web
like
mechanisms,
it
has
to
be
concerned
about
the
web
security,
although
on
a
whole
bunch
of
different
aspects-
and
you
know
so.
M
Yes,
it's
a
good
example.
Some
that
uses
quick
and
it
uses
quick
in
a
fairly
close
way
to
to
native.
You
can
model
that
in
your
head
in
a
bunch
of
different
ways
of
exactly
how
that
maps
together,
but
the
expertise
to
bring
a
new
thing
into
existence
probably
comes
from
somewhere
else
and
so
I
think
farming
this
out
and
really
sort
of
opening
the
floodgates.
It's
a
great
time.
So
that's
great.
I
Just
sorry
just
to
respond
to
that.
Very
briefly,
you
bring
to
mind
very
much
that
one
of
the
things
that
Lars
and
I
have
observed
is
that
we
we
see
the
implementers
and
the
people
working
on
the
specs
getting
close
to
the
point
of
exhaustion.
This
has
been
a
long
slog.
It's
a
lot
of
work
and
well.
I
know
that
people
are
excited
about
and
some
of
the
same
people
are
excited
about
new
applications
or
extensions
and
there's
going
to
be
effort
put
in
there.
I
K
K
No,
they
don't,
but
I
am
here
to
say
that
I
took
a
little
little
while,
but
I,
don't
like
the
idea
of
having
a
quick
dispatch
sort
of
a
thing.
It
seems
to
make
sense
and
the
other,
on
the
other
point
about
congestion
control
with
ICC
RJ,
chair
hat
on
I'd,
recommend
that
people
who
have
ideas
on
doing
different
condition
controllers,
even
if
the
problem
is
motivated
and
driven
by
having
quick
as
a
transport.
J
Work
not
so
much
for
you,
Marcus
for
the
80s
and
and
second
everybody,
everybody
in
the
room.
There
was
mentioned
earlier
of
some
dispatch
like
functionality
for
transport.
That
might
be
really
good
idea.
I
can
think
of
at
least
three
discussion
I've
been
involved
in
in
this
week
that
have
that
have
included
okay.
So
where
would
we
work
on
this
thing
in
the
transport
area
or
the
or
the
IETF
in
general?