►
From YouTube: IETF100-TSVAREA-20171116-1810
Description
TSVAREA meeting session at IETF100
2017/11/16 1810
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
C
C
Okay,
I'm
Spencer,
and
this
is
Maria
and
we're
the
transport
area
directors
and
welcome
to
TSP
area
and,
if
you're
attending
something
else,
you
may
be
doing
it
through
mideco
you're
in
the
right
place.
For
us,
though,
we
start
off
with
the
note
welt
and
just
put
that
up
as
a
reminder
to
people
to
remember
their
obligations
as
ITF
participants.
C
So,
just
to
give
a
quick
chance
for
people
to
bash
agendas,
I'm
going
to
do
a
quick
state
of
the
area.
Kind
of
thing
and
Mary
is
going
to
talk
about
NAT,
dev
and
then
mark
and
Lars
are
going
to
are
going
to
talk
for
a
few
minutes
about
what
they're
doing
with
synchronizing
specifications
and
interrupt
testing
I'm
going
to
talk
for
a
couple
minutes
about
some.
C
C
We
always
try
to
start
off
thinking
the
area
review
team
without
which
Mary
and
I
could
not
be
as
effective
as
we
are
as
area
directors
recognized
than
the
people
who
have
done
our
reviews
and
stuff
like
that.
I
wanted
to
also
mention
that
Alice
Menken
has
been
part
of
the
triage
team
since
we
started
the
triage
team
and
she
will
be
leaving
that
and
she
is
being
replaced
by
some
guy
named
Magnus.
So
we
appreciate
we
appreciate
all
of
that
and
leashes
Aang
is
also
stepping
down
as
a
reviewer
and
I
guess.
C
C
C
Yeah
the
best
to
do
this
is
when
you
move
the
a
huge
air
to
be
a
chair
of
TSP,
WG
and
then
and
then
you
so
those
you
can
close
the
working
group
and
then
we
just
don't
close
the
working
group
for
a
while
will
always
always
catch
or
change
when
we
hand
it
to
you,
we
have
a
decent
number
of
documents
that
we've
have
moved
someplace
since
IETF.
Ninety
nine
and
I
saw
that
we
just
had
two
more
pop
out
like
this
afternoon.
C
C
C
Aware
networking,
from
the
first
meeting
of
the
research
group
a
proposed
research
group,
we
had
enough
sad
tales
of
why
that
won't
work
whatever
that
is
to
where
we
wanted
to
write
those
down
so
that
people
can
learn
from
literally
decades
of
experience
and
so
that
we
don't
repeat
old
mistakes,
but
that
we
move
on
to
new
and
exciting
mistakes
of
her
own
was
a
joke.
I'm
I
offered
to
get
that
document
started
and.
C
C
C
D
It's
a
little
bit
confusing
to
look
over
there
anyway,
so
we
had
some
updates
from
the
net
Deaf
conference
already
and
previous
Arab
meetings,
because
that's
like
one
of
the
open
source
communities
where
our
draft
they
read
our
drafts
and
implement
stuff.
Actually,
that's
actually
the
right
thing:
they
read
our
drafts,
not
the
RSC's,
that's
a
problem,
but
anyway
there
was
a
net
of
meeting.
Last
week
in
Seoul
I
went
there.
D
D
D
The
net
f
is
basically
the
the
meta
2.2
which
was
last
week
in
seoul
is
the
fifth
conference
they
organized
so
it's
like
and
they
do
two
per
year,
so
they
only
started
like
three
years
ago,
so
it's
rather
new
thing
and
they're
still
community
building.
So
it's
actually
kind
of
interesting
to
to
interconnect
with
them,
and
the
next
net
def
conference
will
be
in
Europe,
probably
in
spring,
but
they
might
also
they
also
considered
actually
to
co-locate
again
or
or
move
to
Montreal
together
with
the
IETF.
D
So
it's
not
decided
yet,
but
probably
it
will
Greensburg
spring
in
Europe.
Actually,
oh
sorry,
so
usually
they
have
a
very
strong
focus
on
performance.
Say
it's
not
really,
like
you
know,
what's
the
new
cool
feature
we
have
to
implement
in
the
credits
rather,
like
you
know
there
is
this
feature?
How
can
we
optimize
it?
How
can
we
do
offloading?
How
can
we
do
the
system
first,
or
how
can
we
clean
up
the
code
to
make
it
faster
these
kind
of
topics?
D
So
it's
like
very
much
in
the
detail,
so
it's
all
there's
also
a
lot
of
topics
around
net
filtering
or
VBF,
which
is
also
packet
filtering
and
using
these
kind
of
tools
for
optimizing
your
code.
Other
topics
that
were
present
at
the
conference
is
like
also
how
to
test
your
code.
There
was
a
separate
workshop
about
IPSec
data
center
scenarios.
Wireless
is
also
in
topic
where
they
are
working
on
say.
This
is
basically
mainly
the
slides.
Are
there
because
these
are
linked,
so
you
can
actually
click
on
the
presentations.
D
D
There
were
two
talks
about
testing,
so
that's
like
about
software,
how
to
implement
a
state
implementation,
so
that's
actually
something
that
you
can
use
in
a
broader
scale,
not
only
on
the
news
credit.
So
that
might
also
be
interesting
for
you,
then
there's
of
course
always
something
about
xtp,
so
packet
filtering.
There
was
this
time
and
also
last
time
there
was
like
kind
of
an
overview
workshop.
So
if
you
don't
know
what
it
appears
and
you
want
to
learn-
it-
that's
probably
also
a
good
reference.
D
But
this
is
like
one
of
the
two
big
toppers
like
hardware
acceleration
of
these
kind
of
things,
and
there
is
also
a
new
version
of
net
M,
which
is
now
using
x2p,
which
is
just
a
little
bit
faster
than
the
old
version
was,
if
you're,
using
that
yeah
and
then
I've
listed
also
a
couple
of
topics
it
which
are
related
to
security,
which
also
could
be
interesting
here,
but
again
focus
on
performance,
optimizations
and
that's
it
except.
You
have
any
questions
about
it.
C
You
could
I
ask
mr.
Nottingham
to
come
up
and
enlighten
us
a
little
bit
about
the
way
HTTP
to
that
has
been
doing
implementation
and
specification
synchronization
we're
hoping
to
make
it
we're
hoping
to
make
the
transport
area
more
aware
of
what's
possible
within
at
the
IETF,
and
certainly
the
one
that
I
spend
the
most
time
talking
to
people
about
in
this
space
is
quick
and
mark
is
involved
with
that,
but
also
his
own
beginning.
Http
do
so
thank.
C
E
We
go
so
yeah
your
your
area.
E
Our
area
directors
asked
me
to
very
briefly
discuss
our
approach
to
interoperability
and
and
and
implementation
in
HTTP
2.
So,
oh
there
it
is
so
we
had
an
interesting
situation.
We
had
an
in
to
put
document
that
we
were
chartered
upon
called
speedy
and
it
had
a
fair
amount
of
deployment
on
the
network.
It
was
in
a
couple
of
browsers
and
a
couple
of
different
server-side
implementations,
so
we
already
had
running
code.
E
We
just
needed
to
make
that
running
code
adapt
to
the
changes
that
were
made
in
the
working
group,
which
were
not
trivial
and
when
we
got
to
draft
for
we
decided
to
identify
that
as
an
implementation
draft
that
was
in
June
I
forget
the
year.
What
was
that
2014
13
13,
probably
something
it's
ancient
history
now
and
we
said
that
we
wanted
to
do
Interop
on
that
in
August
at
our
next
interim
meeting.
E
So
we
were
on
a
fairly
aggressive
schedule
as
interim
meetings,
which
was
very
good
for
for
building
a
group
of
people
working
towards
a
single
goal.
I
personally,
as
the
workgroup
chair
was
expecting,
maybe
three
or
four
implementations
to
show
up
and
to
get
you
know,
partial
Interop.
It
turns
up.
We
had
ten
implementations
show
up,
which
was
fantastic
and
within
the
first
day,
and
we
had
one
day
in
her
up
and
then
I
think
was
a
three
day
working
group
meeting.
E
E
We
had
interruptive
ents
at
every
subsequent
interim
meeting
and
we
were
testing
the
whole
stack
kind
of
in
a
very
ad
hoc
fashion,
because
we
were
developing
a
new
version
of
an
existing
protocol.
We
had
the
luxury
of
you
know
you
can
rely
on
normal
HTTP,
you
know
tools
and
and
and
test
Suites
and
whatever.
So
you
know
point
a
browser,
a
web
page.
Does
it
work
if
the
HTTP
2
is
in
use?
Yes,
no.
What
kind
of
problems
happen
and
that
was
fairly
straightforward?
E
One
of
the
key
things
was
the
ability
to
negotiate
versions
on
the
wire
really
allowed
experimentation
and
an
even
early
deployment,
one
of
the
the
fun
things
that
a
lot
of
people
don't
realize
is
when
we
did
that
draft
for
that
that
first
implementation
draft
that
we
put
out
there
one
of
our
implementers
decided
to
put
it
live
on
the
network
Twitter.
If
you
went
to
twitter.com
and
did
the
NPN
for
for
whatever
the
NPN
identifier
that
we
used,
you
would
get
HTTP
to
from
Twitter
comm,
which
was
pretty
cool
and
kind
of
scary.
E
But,
and
that
just
shows
you
know
how
you
can.
You
know,
use
these
mechanisms
that
we
put
in
as
protocols
to
allow
this
kind
of
evolution
to
happen
and
especially
when
you
have
endpoints
put
up
not
just
during
the
interrupts
but
throughout
the
development
of
protocol,
and
you
can
say
well
my
endpoints
over
here.
We
put
them
on
a
wiki
page,
and
you
say:
okay
well,
I'm,
hitting
your
endpoint
I'm.
Getting
this
error.
E
Where
I
see
this
behavior-
and
you
talk
through
that-
and
it's
a
great
interaction
from
from
a
working
group
to
your
standpoint,
the
best
thing
is
is:
when
you
see
this
level
of
of
engagement
from
folks,
you
start
basing
your
discussions
and
your
decisions
on
the
running
code,
which
is
really
what
we're
supposed
to
be
doing
here.
It's
very
gratifying.
E
D
E
A
really
tough
decision,
sometimes
I
mean
you
know
we
were
releasing
new
drafts.
Editorial
drafts
fairly
rapidly
I
think
we
got
up
into
around
20
ish
and
identifying
the
right
places
for
for
interrupts
it.
Really.
You
have
to
take
the
temperature
of
the
room
and
figure
out.
Okay,
how
many
implementations
can
come
to
the
party
how
many
are
being
left
behind?
Sometimes
it's
the
right
thing
to
do
to
leave
a
few
behind.
E
You
don't
want
people
gate
weighing
forward
progress
of
the
group,
but
you
you,
you
know
you
have
to
have
a
lot
of
coordination
between
what
are
we
discussing
as
a
working
group
and
what
are
we
putting
into
the
drafts
and
then
what
is
being
tested
for
and
and
and
and
operated
upon,
and
you
have
to
make
sure
that
the
changes
you
know
if
you
make
a
big
change,
you
need
to
allow
people
time
to
digest
that.
So
it's
really
just
a
judgement
call
Patrick.
Do
you
want
I
know
Patrick,
wants
to
add
something:
I.
F
F
So
it
was
very
typical
for
there
actually
for
an
implementation
to
carry
two
or
three
of
these
drafts
at
a
time,
and
we
just
look
for
the
highest
one
that
that
overlapped
and
there
certainly
were
ones
that
were
tested
in
the
wild
that
were
not
not
marked
implementation
draft,
but
because
we
were
shipping
them
as
IDs
anyhow,
not
just
living
off
of
an
editor's
copy
that
worked.
Okay,
yeah.
E
C
G
C
H
H
That
is
quick,
so
so
next
slide,
which
is
my
last
slide
yeah,
but
it's
so
busy,
we've
been
I,
mean
Mark's,
been
involved
with
h2o
and
he's
also
chairing
quick.
So
we
basically
learned
from
what
h2
did
quick
turns
out
a
little
bit
more
complicated
than
then
h2
right
so,
but
we
basically
have
the
same.
We
have
same
idea
that
we're
gonna
has
worked
for
h2s
we're
gonna
do
this.
We
can
have
a
sequence
of
internet
drafts
in
our
case.
H
Actually,
quick
is
a
set
of
four
things
that
we
call
the
base
drafts
and
we
try
to
have
them
progress
at
the
same
number,
so
we're
we're
at
l7.
Now
one
of
them
was
at
O
six
for
a
little
while
because
we
forgot
to
click
the
button,
but
the
idea
is
that
they
all
they
all
sort
of
within
a
few
days
of
each
other.
They
move
versions,
even
if
there
isn't
a
whole
lot
of
updates
for
some
of
them
just
so
that
it.
H
You
know,
people
have
an
easy
way
to
identify
the
stuff
and
pretty
much
and
in
a
pretty
ad
hoc
fashion.
For
the
last
year,
we
sort
of
blessed
so
far
as
what
we
call
implementation
drafts
and
I
think
it
was
all
five
which
was
about
six
months
ago,
and
then
we
did
Oh
seven,
which
we
interrupt
at
this
meeting
and
what
the
editors
copy
is
always
sort
of
ahead
of
the
of
the
implementation.
H
But
that's
fine
and
I
think
now
the
next
one
is
probably
going
to
be
Oh
8,
so
we're
going
a
little
bit
slower,
because
now
the
implementations
are
actually
they
need
to
implement
a
lot
of
text,
that's
been
written
and
it
takes
a
little
bit
longer,
so
we're
doing
three
a
year.
So
far,
what
roughly
say
I
don't
know
we're
going
to
keep
that
up.
We
have
too
little
data.
H
We
have
a
wiki
page
for
each
of
those
implementation
drafts
that
actually
tells
the
implementers
which
parts
we
consider
ready
for
implementation.
So
four
or
five
phases
that
you
gotta
be
able
to
do
a
handshake
that
that's
kind
of
a
given.
We
expect
you
to
be
able
to
exchange
encrypted
stream
data,
which
is
already
quite
a
bit
of
machinery
you
need
to
put
in
and
I
think
we
wanted
a
stream
to
be
closed,
not
the
connection,
so
there's
a
little
bit,
so
there
was
not
very
well
defined.
What
did
what
these
things
meant?
H
Specifically,
the
closing
part.
Many
people
didn't
quite
know
what
they
were
supposed
to
implement,
but
at
least
sort
of
the
the
the
handshake
and
the
stream
data
actually
worked
pretty
well
and
now
we're
preparing
for
implementation
draft
three
and
we're
gonna.
Just
this
meeting
talked
about
who's
going
to
hold
a
pen
to
write
the
wiki
draft
for
what
is
required
there,
and
we
are
increasingly
getting
more
rigorous
about
what
we
expect
from
an
implementation.
H
So
this
time,
I
think
we
at
least
discuss
that
there's
gonna
be
a
whole
lot
more,
that
we
want
people
to
do
in
Melbourne,
but
we're
gonna
order
it
so
that,
if
you
can
do
everything
you,
if
you
go
down
the
list
you
you
can
be
sort
of
assured
that
at
least
everybody
will
have
the
first
things
on
that.
Listen
and
maybe,
as
you
go
down
the
list,
there
will
be
fewer
things
that
everybody
has
implemented,
but
that's,
okay.
H
We
are
also
discussing
to
increase
the
cadence
of
these
interrupts.
We've
done
six
a
year,
because
we
do
three
meetings
at
the
ITF
and
three
interims,
and
that
turns
out
to
not
be
enough
at
the
moment,
because
the
coding
has
really
started
in
earnest.
So
we
are
looking
to
do
virtual
interrupts
meetings,
I,
don't
know
if
it's
gonna
be
once
a
month
or
once
every
two
weeks,
or
maybe
once
every
week
where
we
say
Monday
is
implemented
a
and
if
you
are
want
to
join
the
slack
that
we
use
to
coordinate
this.
H
Other
people
will
be
on
at
slack
too,
without
you
needing
to
agree
with
them
booked
booked
time
or
something
that
is
and
we're
gonna
basically
run
each
other's
stuff
over
the
network
and
talk
wants
like
and
and
debug
jointly,
that's
sort
of
the
the
goal.
Here
we
haven't
done
one
of
those,
so
we
don't
quite
know
how
that's
going
to
go,
but
some
people
do
this
pairwise
anyway,
in
between
the
interrupts,
because
most
people
actually
also
have
public
servers
up.
H
So
if
you
have
a
server
implementation,
most
people
have
stood
one
up
in
Amazon
and
if
it
crashes,
it
restarts
and
there's
usually
some
way
that
you
could
actually
look
at
the
log
of
that
server
over
the
weapons
or
you
can
just
shoot
a
client
hello
and
see
what
happens.
That's
been
very
useful,
especially
the
automatic
restart
part
I
think
is
pretty
crucial
to
get
that
right.
H
Otherwise,
you're
going
to
be
able,
if
you're,
going
to
log
into
your
server
a
whole
lot
and
we
start
for
people
and
we
sort
of
have
a
way
which
also
evolved
in
a
pretty
ad
hoc
fashion.
As
a
Google
Docs
interrupt
matrix,
where
you
basically
say
yep
I
could
do
handshake.
Yep
I
could
do
data
with
you
and
then
we
sort
of
keep
track
of
what
worked
and
what
didn't
work
between
these
implementations.
I
think
also
for
the
future.
H
There's
talk
about
automating
this
a
bit
more
because
so
at
the
first
Interop
I
think
we
had
like
four
or
five
implementations
now
I
think
we
had
at
least
twelve
and
there's
several
more
that
are
ongoing,
but
they
haven't
shown
up
yet
so
it's
gonna
be
extremely
tedious
in
the
future
to
fill
that
matrix
without
some
support,
but
that's
what
computers
are
for.
So
we
might
think
about
some
more
integrated
way
to
you
know,
especially
it
opens
up
all
the
stuff
from
get
up
compile
it
run.
H
It
have
some
way
to
declare
success
and
and
mark
the
matrix
so
yeah,
that's
basically
what
we've
been
doing,
I
think
it's
working
well,
we're
you
know
not
using
WebEx
or
any
IGF
collaborative
tools
we
use
slack
because
that's
what
developers
are
used
to
and
there's
a
lot
of
integrations
with
other
things
that
we
use,
which
is
nice.
H
D
H
So
I
mean
bunch
of
implementations,
especially
the
ones
that
actually
have
you
know:
teams
of
developers
I
get
paid
for
writing
that
thought
sort
of
code.
They
tend
to
have
really
nice
unit
test
frameworks
and-
and
it
turns
out
now
that
we're
looking
at
getting
the
flow
control,
correct
or
the
loss,
recovery,
correct
and
the
condition
control
correct.
H
It's
it's
really
useful
if
you
have
a
way
to
predictably
generate
a
test
scenario
with
a
lost
pattern
and
maybe
a
delay
or
something
or
if
you
want
to
get
fancy
little
a
spike
or
something
like
that,
so
that
you
can
actually
repeatedly
test
your
implementation
against
another
implementation
under
a
you
know,
realistic,
but
repeatable
Network
condition,
and
so
we're
trying
to
think
of
how
what
we
can
do
there
I
think
ekor
has
some
code
and
I
have
some
code
and
we
might
cobble
something
together
along
some
timeline,
but
I
mean
everybody
sort
of
has
that
infrastructure
or
needs
to
get
that
infrastructure.
H
H
So
the
at
the
first
so
this
week
we
had
I
think
around
20
people,
but
it's
kind
of
hard
to
tell
because
we
overlap
with
TLS
quite
a
bit
at
the
moment.
But
when
I
looked
at
the
hackathon
registration
and
that
searched
for
straight
quick,
I,
think
I
had
like
17
or
18
people,
and
we
had
a
bunch
more
that
were
remote
on
slack
during
the
inner
up
and
at
the
first
meeting
we
had
maybe
half
that
we
still
had
a
pretty
significant
number
at
the
first
one.
Already
module
do.
D
Those
people
stay
for
the
quick
session
just
come
for
the
interrupt
I
think.
I
I
J
I
K
L
H
F
H
One
point
on
on
the
stage
for
the
week
part,
which
I
think
it's
important
so
I
think
we
have
people
show
up,
because
we
do
this
inter
up
here
on
that
otherwise
wouldn't
come
specifically.
We
have
some
developers
that
are
in
teams
where
you
might
see
you
know
somebody
is
a
little
bit
higher
up.
The
food
chain
participate,
but
we
actually
get
the
people
who
write
the
code
that
maybe
otherwise
wouldn't
have
come
to
an
ITF,
and
so
that's
kind
of
a
nice
sort
of
side
effect
I.
H
Think
of
having
some
of
these
these
inner
of
events
here,
whatever?
What
was
your
question?
You
can
I
remember
all.
H
Different
constituency-
yes,
so
we
have
I,
think
pretty
consciously
so
we're
trying.
We
realized
that
if
we
only
ever
met
at
the
IDF's,
we
would
not
be
done
in
ten
years.
So
the
the
these
venues
do
not
allow
the
discussion
to
happen
at
a
pace
that
we
need
in
order
to.
We
already
moved
the
milestone
back
six
months
and-
and
you
know,
if
you're
a
transport
working
group
that
is
not
a
big
deal,
nobody
would
even
blink
an
eye.
H
We
had
people
email
us
because
that
it
caused
a
significant
product
delays
and
we
know
it
increased
investment
in
the
technology,
and
that
is
not
a
little
thing
for
many
people
who
actually
want
to
run
this
in
production
and
not
you
know,
keep
seeing
draft
revisions
so
in
only
in
the
inner
rims
we
have
about
fifty
people
and
the
active
participation
fraction
is
much
higher
than
at
the
IETF.
I
would
say
that
at
least
like
two-thirds
in
the
room
are
actively
participating.
H
It's
still
not
a
hundred
percent,
which
is
not
making
me
very
happy,
because
we
we
still
need
a
over
provision
in
the
room
and
we
still
have
people
that
that
don't
seem
to
actually
actively
do
anything
while
they're
there,
which
kind
of
makes
me
wonder
who
they're
working
for
and
how
that
can
be.
Because
you
know
we
go
around
the
world
quite
a
bit,
but
it's
it's
certainly
better.
Plus.
H
F
H
J
L
Brian
Trammell,
even
if
I
don't
show
up
on
the
blue
sheet.
So
this
this
is
a
a
pretty
cool
new
way
to
run
a
working
group.
I
think
I
have
I,
have
a
couple
of
particular
quips,
but
I
think
that
there's
there's
a
trade-off
space
here
and
I'm,
not
sure
if
it's
the
exactly
the
right
point
in
the
trade-off
space,
but
I
get
the
speed.
H
Actually
vagrant
because
I
have
a
zero
copy
stack
and
you
I
need
to
run
a
VM,
so
I
can
run
the
the
zero
copy
drivers
underneath
it
and
and
it's
you
know
it's
basically,
you
just
write
whatever
you
would
do
and
type
into
SSH.
You
put
a
vagrant,
see
in
front
of
it
and
it
does
it
in
the
machine.
If
it's
not
that
big
of
a
deal
to
do
this
with
virtual
machines
would.
H
L
L
So
this
is,
you
know,
this
is
like
I
think
the
reason
that
it's
you
and
Mark
that
came
into
own,
he
did
actually
go,
get
a
drink,
Denis
that
you
and
Mark
came
in
here
to
talk
about.
This
is
because
this
this
is
sort
of
like
running
a
process
code
that
we've
got
experience
within
the
app
area
that
were
you
know,
sort
of
like
through
quick,
pushing
down
into
the
transport
area
and
we're
seeing
what
works
from
their
development
process
and
what
needs
to
be
tweaked,
so
I
think
there
were.
L
There
might
be
area
specific
things
that
are
done
here,
but
you're
right,
it
might
actually
be
a
thing
that
goes
through.
Like
is
more
for
the
whole
IETF
I,
don't
know
what
you
could
do
for
you
know.
When
you
get
down
to
routing
it
gets
a
little
bit
more
difficult
and.
H
That's
what
the
web
guys
tend
to
have
pretty
good
testing
framework,
yeah
and-
and
the
you
know
in
TCP
we
have
n
is
to
rate,
which
is
not
quite
the
same
thing,
but
so
we're
trying
to
I
think
we're
trying
to
sort
of
mark
something
up
that
would
give
us.
You
know
it
may
be
exactly
what
we
need
for
a
quick
or,
or
you
know
some
of
that,
but
so
I
am
so
not
signing
up
to
do
anything
more
anything
more.
L
H
Okay,
so
if
we
can
can
run
on
your
thing,
you
know
I'm
sure
that
that
would
be
a
good
test
for
it.
But
I
be
already
very
concerned
about
our
timeline
and
yeah.
L
And
I'm
not
trying
to
make
I
mean
yeah
I'm,
trying
to
make
any
more
work,
but
I
knew
I
was
gonna
fail
at
that.
So,
but
it
seems
like
there
might
be
like
I'm,
a
very
big
fan
of
sort
of
the
running
code
side
of
the
equation,
and
it
seems
like
there
might
be
something
that
we
can
do
take
out
of
quick
that
can
possibly
make
things
work
a
little
bit
better
in
them.
I.
H
Mean
there
is
the
packet
drill,
I
think
it's
called
right:
yep
the
Google
tool,
but
and
and
people
so
I
I,
think
I
know
that
Google
has
a
very
extensive
test
of
packet,
drill
cases
that
they
basically
run
their
whatever
change.
They
want
to
make
to
tcp
against
and
if
it
passes
that
they
can
be
reasonably
sure
that
right.
G
H
H
A
D
A
cool
I
mean
I
just
wanted
to
quickly
it
like
on
the
slides
I
presented
privacy.
There
was
also
one
talk
like
the
last
talk
under
testing,
which
is
actually
and
eclipse
based
framework
where
you
can
have
like
a
formal
specification
of
your
put
a
call
and
enable
test
against
it.
So
maybe
that's
actually
useful
yeah.
H
Once
we
have
one
for
a
quick,
we
can
totally
use
that,
but
I
so
no
I
mean
all
of
those
things
are
great
right
it,
but
it's
it's
that
all
of
them
also
require
quite
a
bit
of
work
and
and
the
formal
specification
for
protocol,
that's
under
very,
very
heavy.
Active
development
is
not
going
to
make
that
development
go
faster.
I
think.
M
Hi,
curry,
I
use
pocket,
drills,
well,
I
use
pocket
drill
as
well,
but
that
wasn't
what
on
stalker
I
wondered
how
we
deal
with
the
tension
of
trying
to
get
other
people
engaged
with
quake
and
building
things
on
it
and
understanding
the
dynamics
of.
What's
going
on
when
we're
designing
something
so
very,
very
complicated
a
it
seems
like
the
working
groups,
two
rules
trying
to
get
people
in
there
and
understand
it
and
then
build
on
it
and
we're
also
trying
to
develop
it
and
that's
a
bit
of
a
tricky
one
to
balance.
Yeah.
H
So
we
use
the
ITF
meetings
like
to
get
input
from
people
that
don't
show
up
at
the
interims,
for
example,
like,
like
congestion,
control
experts,
don't
come
to
creek
at
the
moment,
because
it's
too
much
about
other
stuff,
but
they
hang
out
in
the
ITF,
and
so
we
can
have
a
session
and
discuss
things.
But
you
can
maybe
make
progress
on
like
one
or
two
issues
and
I
think
we
have
like
I.
Don't
know
how
many
hundreds
open
at
the
moment,
so
it
simply
doesn't
work
for
moving
the
needles
significantly
on
anything
that
matters.
H
H
I
mean
every
morning
when
I
look,
click
on
github
write,
the
entire
like
I,
know
how
many
pages,
it's
all
just
what
happened
in
the
base
drafts
repository
overnight,
because
I'm
in
Europe,
right
and
I'm,
like
you
know,
read,
read
all
and
move
on
it's
so
it's
it's
a
full-time
job
to
participate
in
quick,
no
question
yeah,
and
that
makes
it
hard
if
that's
not
possible,
and
it's
a
challenge
for
how
do
you?
How
do
you
not
lose
the
part
of
the
community
that
can't
afford
that,
but
might
still
be
able
to
make
valuable
contributions?
H
M
H
G
H
I
think
for
the
people
who
are
sitting
around
the
front
table
and
they
start
chatting
and
not
using
their
names,
they
actually
feel
that
the
the
pace
is
better
right.
Things
move
faster,
you
can
have
a
discussion.
You
can
actually
make
some
progress
for
everybody
else.
It's
way
harder
to
follow,
yeah
because
nobody
says
their
name.
There
isn't
a
mic
line,
remote
attendants,
probably
especially
struggle
boy.
J
H
Meeting
right,
it's
the
goal
of
the
meeting
to
push
development
of
the
protocol
forward,
in
which
case
I
would
say
the
remote
ik
that
the
room
experiment
actually
works.
Right
is
the
purpose
of
the
meeting
to
allow
the
rest
of
the
community
to
catch
up
or
understand
more
about
quick,
in
which
case
you
have
to
have
a
slower
meeting
and
have
more
formalism,
then
that
totally
doesn't
work
and
I'm.
Actually
so
I
like
the
interims.
A
lot
I
frankly
think
we
could
almost
almost
stop
meeting
at
the
IDF's,
because
please.
D
Interrupt
you
here,
because
there
are
a
lot
of
process
challenges
we
have
as
quick,
because
it's
a
different
kind
of
working
group,
then
many
other
working
groups,
but
the
one
thing
we
would
like
to
concentrate
here
is
actually
how
to
move
along
with
the
implementation,
how
to
sync
that
up
and
how
to
make
quick
work.
Progress
on
that
part,
so
I
mean.
H
D
J
J
C
Yeah
so
the
last
thing
I
wanted
to
be
sure
to
do,
and
we've
tried
to
leave
some
time
for
open
mic
things
and
and
stuff
like
that
with
a
group,
but
I
wanted
to
put
this
in
front
of
the
transport
community.
And
let
me
just
ask
a
couple
of
quick
questions:
doesn't
I?
Don't
care
I,
don't
care!
Why
you're
there,
but
how
many
people
here
go
to
hackathon,
okay,
so
I'm,
seeing
about
eight
something
like
that?
Maybe
and
I
don't
care
on
what?
But
how
many
people
here
do
anything
on
yang.
C
Are
you
a
small,
a
small
elite
team
I
think
that
David,
and
maybe
somebody
else
so
I-
wanted
to
talk
about
this
Benoit
Klaus?
Who
is
the
outgoing
management
side
yeah
ad,
and
he
gave
this
presentation
about
this
to
the
isg
at
the
retreat
in
in
May
and
this.
So
this
is
a
proposal,
but
this
is
this
is
kind
of
what
Ben
was
trying
to
do
in
the
world
of
Yang.
C
So
the
idea
that
he's
working
with
is
that
the
working
group
controls
the
structured
document
and
the
version
control
is
positive,
the
ones
that
I
know
about
or
github,
but
it
you
know
it
doesn't
have
to
be
that,
but
something
like
that
and
that
they
do
version
numbers
that
are
three
levels:
major
minor
patch,
nothing
revolutionary
about
that
so
far
where
it
starts
to
get
kind
of
interesting
for
IETF
folks.
So
if
you're
thinking
about
nature
version
bumps
are
basically
obsoleting,
the
previous
version,
minor
ones,
are
updating.
C
The
previous
version
and
patches
are
fixing
the
current
version.
The
previous
version
and
where
they
started
to
be
interesting,
was
conversations
about.
Well,
what
does
it
take
to
do
either
any
one
of
these
levels
of
changes?
What
Benoit
was
talking
about
it
at
the
draft,
which
you
know
you
guys
have
the
link,
so
you
can
check
it
out,
but
what
he
was
talking
about
was
basically
that
the
you
know
major
revisions
would
require
IETF
consensus.
C
Potentially
minor
revisions
would
require
working
group
consensus
in
concurrence
with
the
ad,
which
basically
gives
the
ad
a
chance
to
say
you
know.
That's
really.
You
know.
That's
really
a
major
version
change
and
requires
idea
of
consensus,
or
basically
that
patch
level
version
bumps
can
be
up
to
the
EO
up
to
the
editors
judgment
with
the
working
of
chair.
C
D
L
So
historically
is
al
here:
how
was
here?
Okay,
historically
an
IP
p.m.
we've
I
mean
we've
done,
interrupts
of
the
of
some
implementations
of
the
metrics,
but
we
try
for
the
base
metrics
to
be
basically
two
steps
away
from
the
implementation
right.
There's
the
metric
definition,
which
can
be
implemented
by
one
of
a
number
of
methodologies
which
can
be
implemented
by
one
of
a
number
of
protocols,
and
it's
only
if
protocol
methodology
and
metric
line
up
do
you
have
comparability.
L
So
that's
historically
that
sort
of
things
that
have
been
under
the
framework
yeah
and
you
know
amp
and
T.
Well,
one
of
the
things
that
we're
doing
the
registry
is
to
be
able
to
pull
in
other
methodologies
and
implementations
for
a
given
metric.
That
may
not
be
able
to
be
sort
of
interrupt
and
calibrated
to
within
the
tolerances
that
we've
had
for
our
amp
and
T
lamp
right.
L
It
might
be
interesting
to
do
some
sort
of
calibration
framework,
like
those
are
automated
testing
of
certain
things.
Okay,
well
set
up
an
environment,
a
test
environment,
we're
gonna
use
three
or
four
different
ways
to
do.
You
remember:
ecology
the
same
metric
and
see
what
the
tolerances
are
that
might
be
interesting
beyond
that.
I'm
not
sure
how
a
lot
of
this
applies
to
high
ppm
I
can
keep
talking
until
the
apertures
get
in
mine.
C
So
also
an
opportunity
for
people
in
other
working
groups
to
be
thinking
and
if
you
don't
have
a
thing
that
you
are
ready
to
share
with
the
mic
yet
like
I,
say,
you're
invited
to
think
I
should
also
ask
if
there's
anything
else,
if
there's
anything
that
the
the
transfer
area
needs
to
know
that
you'd
like
to
share
in
here
and
so
we'll
just
kind
of
move
into
our
open
mic
time.
For
the
last
few
minutes
that
we
have
together
here
anything
that
the
ABS
need
to
know
anything
that
the
community
needs
to
know.
N
Well,
since
you're
Spencer,
Brian,
carpenter
and
I
was
actually
thinking
mentioning
this
point
in
the
interior
meeting,
but
they
ran
out
of
time
he
I
couldn't
marry.
I
might
guess
what
this
is
about.
It
came
to
my
attention
that
we
have
an
eye
on
our
registry
with
256
slots
in
it
that
is
about
2/3
full
and
which
is
in
the
dreadful
state
of
disrepair
right.
N
It's
the
registry
for
protocol
numbers,
which
kind
of
falls
halfway
between
interior
and
transport
since
most
of
the
entries
in
a
transport
protocols
and
I,
am
not
volunteering,
but
it
really
seems
to
me
that
it
needs
a
cleanup.
It
has
an
trees
in
there
that
are
assigned
to
well
there's
one,
for
example,
assigned
to
answer
and
a
brown
merit.
As
far
as
I
know,
he
left
Merritt
before
I
came
to
my
first
IETF.
G
N
There
are
assignments
to
Jon
Postel
and
there
with
no
documentation,
I,
don't
know
quite
how
it
can
be
done,
but
I
feel
that
we
owe
it
to
descendants
in
this
organization
not
to
leave
them
a
registry
which
is
in
such
a
mess
in
such
a
crucial
point
in
the
protocol
stack.
So
if
somebody
really
feels
the
urge
to
help
with
this
problem,
it
would
be
good
for
them
to
speak
out.
H
I
would
not
disagree
with
my
former
is
gshare,
so
I
think
this
is
not
useful
specifically
because
the
amount
of
effort
it
needs
to
actually
verify
whether
something
is
still
in
use
out
there.
This
is
is
a
lot
I
know,
because
so
we
just
did
it
for
for
a
transport
port
for
UDP
443,
which
you
know
somebody
asked
hey,
how
come
the
for
that
quick
might
run
over
is
actually
assigned
to
some
gentleman
from
mosaic.
H
So
it's
fine
in
the
90s
and
you
know
never
reclaimed,
and
then
that's
fine,
and
so
we
actually
went
through
the
trouble
of
contacting
him
and
he's
still
around
and
then
after
explaining
who
we
are,
he
actually
transferred
the
port
to
the
isg,
but
it
took
like
four
months
right,
and
that
was
actually
something
that
might
even
matter
at
some
point
but
yeah.
D
Say
for
the
ports
for
the
system
port,
so
we
actually
are
about
to
clean
this
up
and
like,
and
we
don't
plan
to
run
after
every
session
separately.
We
try
to
do
this
a
little
bit
more
efficiently
and,
let's
see
if
it
works
and
I
would
like
to
run
that
part
first
and
then
we
can
probably
talk
about
the
protocol
numbers
again,
but
as
it
might
actually
be
more
the
end
area.
Responsibility
for
the
protocol
numbers
anyway,.