►
From YouTube: IETF100-TSVWG-20171113-1740
Description
TSVWG meeting session at IETF100
2017/11/13 1740
https://datatracker.ietf.org/meeting/100/proceedings/
A
D
D
D
D
D
D
D
So
this
is
this:
is
a
transfer
area
working
group,
you're,
I'm
David
black.
This
is
a
quote:
Cory
Fairhurst
quickly,
scrambling
up
Wes,
Wes
Wes
could
not
be
here.
So
the
two
of
us
get
get
try
to
run
things.
This
is
the
first
session
we
have
an
hour
today,
followed
by
two
hours
on
Friday
morning.
This
is
the
IAT
F
note
the
usual
ITF
note.
Well,
please
pay
attention
to
it.
It
applies
to
you,
including
any
comments
made
made
in
this
meeting.
We've
got
a
note-taker.
D
We
got
jabber
scribe
in
general
folks
drafts
you
see
in
the
list.
They
could
use
they.
They
always
use
reviews
and
in
particular
this
is
a
case.
Scratch
scratch.
Let's
help
other
people
out.
If
you
review
other
people's
drafts
drafts
you
care
about.
Our
more
are
more
likely
to
get
reviewed
all
right
time
to
start
doing
doing
something
doing
something
usual
here:
ecology,
conferences,
accomplishments
and
status.
We've
had
Nora
she's
published
since
a
frog,
but
there
are
three
in
the
RFC
editor
Q,
two
of
which
are
about
to
emerge.
D
Details
in
cap
of
SCTP
and
the
SCTP
I
did
a
chunker.
After
both
in
authors,
forty-eight-
and
there
is
work
going
on
of
any
authors
and
I
end
up
the
to
pull
things
out,
the
third
one,
the
different
web
RTC
QoS
is
part
of
WebRTC,
a
draft
tarball
or
hairball.
It's
gonna
be
at
the
artsy
editor
for
a
while
there's
one
ID
in
post,
IETF
last
call
processing.
That's
my
ish
and
experimentation
draft.
That's
what
happened
there
is
we
sent?
Oh
six
to
the
iesg.
D
Oh
seven
resulted
from
Aisha
comments.
We
wanted
actually
adding
a
fair
amount
of
text
to
it.
In
essence,
the
most
important
piece
of
that
is
a
summary
of
what
other
people
worked
with
ecn
need
to
understand
about
this
draft.
How
to
stay
out
of
the
way
of
experiments.
Bob
Brisco
gave
that
a
good,
solid
review,
Bob
and
I
are
80%
through
his
comments
in
what
that
means
is
for
four
out
of
his
five
major
issues
are
resolved,
plus
a
buncha
toriel
stuff.
E
Unhex
up
and
there
are
changes
that
have
occurred
since
this
left
the
working
group,
the
IES
G's.
Given
us
lots
of
review,
other
people
have
as
well,
so
there
are
changes
to
the
wording.
If
you
care
about
the
detailed
welding,
please
read
the
latest
draft,
we'll
pull
start
to
list
before
we
send
it
on
to
the
RFC
editor.
D
Right
so
in
particular,
oh,
it
will
get.
Oh,
it
will
get
posted
tomorrow
and
if
we
need
more
changes
in
oh
nine,
it's
not
an
O
nine,
it's
not
a
problem.
Okay,
that
was
a
first
one.
Second,
one
we
had
a
successful
IETF
last
call
on
the
diffserv
Wi-Fi,
a
mapping
draft.
That's
in
is
evaluation,
I
think
they're
going
to
make
decision
on
it
at
the
end
of
November
and
as
we'll
explain
a
bit
more
later
and
discipline,
the
session
would
like
to
get
the
diffserv
lower
effort.
D
Phb
draft
to
work
group
last
call
fairly
soon
there's
a
crucial
decision.
We
have
to
make
today
and
we'll
talk
about
that
on
a
minute
or
two.
There
are
11
additional
working
group.
Ids
you're,
highly
paid
chairs
regard
this
as
a
high-water
mark,
and
so
we
want
to
move
some
these
drafts
along
out
working
group
into
other
people's
hands
before
adopting
any
more
drafts
in
in
the
working
group.
Okay,
note
on
a
few
related
drafts.
There's
a
couple
of
individual
submissions
that
will
be
discussed
here.
Transfer
hadouken
impacts
today,
transferred
header
encryption
impacts.
D
Is
that
today,
or
is
that
that
Friday?
It's
on
the
book,
both
these
on
the
agenda
and
datagrampacket
is
a
ssin
EMP,
MTU
detection.
One
of
those
is
today
one
of
those
is
Friday
I
think
transfer
encryption
is
today
the
there's
three
drafts
in
the
intern
in
the
interior
working
group,
Colonel,
M,
few
considerations,
a
multipath
library
and
socks
protocol
version
6,
which
is
now
at
oh
one.
D
Your
interest
in
these
please
go
to
the
interior
meeting
more
related
drafts,
a
party
switching
scheduler
draft
draft
Finzi
we're
gonna
we're
gonna,
try
to
bash
each
into
the
minute
to
see
if
we
can
get
a
little
bit
time
for
that
in
this
meeting,
and
then
the
deterministic
networks
folks
are
starting
to
think
about
a
transport
layer.
Draft
Foubert
draft
to
bear
is
going
to,
despite
its
name,
is
actually
be
discussed
in
the
deck
net
meeting
this
week.
D
We
we
need
to
have
a
bunch
of
transfer
people
I
show
up
there
on
unfortunate,
I,
think
Det
Nitin
and
T
CPM
conflict.
Okay.
This
is
what
the
agenda
looks.
Like
note,
günther
note
well
doc
compliment
status
when
Dumas
review
in
a
minute
drafts
a
day.
Friday's
agenda
is
note
well
and
a
lot
more,
a
lot
more
time
for
drafts.
Next
thing
up
is
milestone,
review
and
then
what
of
the
detail
agenda?
Okay,
milestone
review,
so
we
had
a
bunch
of
drafts
that
we
thought
we
would
get
the
is
U
V.
D
Now
the
end
of
the
year,
those
first
five
drafts
the
to
any.
The
two
in
orange
yellow
was
orange
and
the
first
three
in
green
we're
not
going
to
get
all
five,
those
to
ask
the
iesg
in
the
next
month
or
so
Bob.
What's
a
reasonable
date
for
sending
those
first
two
drafts
about
eating
encapsulation
working
group
last
call.
D
F
D
If
we
give
her
earlier,
we
go
extra
credit,
I,
think
January,
I,
think
Jan.
Yet
Ghent
January
sounds
regional
for
the
EC
and
kept
the
two
ECM
capture
as
one
of
the
things
I
need
to
do.
Do
a
careful
review
of
the
the
overall
one.
That's
the
date
for
working
group.
That's
called
closely
yes,
so
the
goal
will
be
get
Sandburg
group
last
call
Goldie's
and
work
last
call
in
December
and
go
to
the
iesg
in
January.
D
Well,
yeah.
It's
see
that
as
soon
as
they
escape.
Let's
call
it
last
last
call
unscathed:
okay,
it
Michael
or
Randy
the
SCTP
drafts.
D
D
D
Okay,
rest,
the
milestones
probably
get
stay,
put
transport
options,
we're
hoping
is
April
the
three
elf
for
let's
see
the
two
FEC
drafts
in
June,
the
three
l4s
drafts
in
in
September
and
telling
Jason
feedback
graph
right
now,
we've
pushed
out
a
year
chairs
are
a
little
uncertain
about
about
the
few
about
the
future
that
drafted
needs
it
needs.
It
needs
to
need
some
major
revisions.
D
Okay
with
that,
let
me
quick
show
the
agenda,
as
is
this
is
agenda
bashing
we've
done
document
status
to
our
own
accomplishments.
Next
up
will
be,
it's
probably
I
think
a
status
update
from
Bob
on
the
tuition.
Encapsulation
drafts,
lower
effort,
page
B
draft
round.
One
follows
the
the
goal
here.
Is
we
really
do
need
to
pick
the
dscp
diffserv
code
point
for
the
lower
effort
PHP
this
week?
D
So
it's
on
the
agenda
twice
today,
I
think
Gauri's
gonna
leave
the
discussion
about
making
sure
we
understand
what
the
problem
is,
what
considerations
are
and
why
this
isn't
an
easy
decision?
I'm
gonna
try
to
make
decision
on
Friday
all
by
other
transport.
Encryption
draft.
Now
we're
also
going
to
bash
the
agenda
if
time
permits
we'd
like
to
give
draft
Finzi
of
priorities
that
party
scheduler
draft
five
minutes
at
the
end
of
the
meeting,
if
we
get
through
everything
else
else
before
them,
and
have
five
minutes
to
spare
whoops
try
going
forward.
D
Okay,
on
Friday
SCTP
drafts,
Alvarez
drafts,
Laura
peach,
B
round,
2
to
McGee,
SCP
selection
to
effect
frame
drafts
and
then
the
the
datagram
p.m.
to
UD
draft
and
if
you're,
an
ICC
RG.
You
heard
this
draft
on
six-man
draft
mentioned
it's
actually
going
to
get
discussed
here.
Friday,
okay,
aside
from
the
change
to
do,
try
to
fit
in
some
fit
in
these.
The
fins
draft
Finzi
scheduler
draft
into
this
end
of
this
session.
Any
other
agenda,
Bash,
requests,
hearing,
none,
consider
the
agenda.
Bashed
Bob,
your
slides,
you
or
you
just
want
to
talk.
D
Yeah
there
might
meal
somewhere.
I
have
no
idea.
F
F
E
E
B
F
Okay,
so,
as
I
said,
just
posted
updated
it
this
this
morning,
next
couple
of
recap,
slides
that
are
there
mainly
for
those
that
are
not
used
to
what
goes
on
here,
so
I'll
very
quickly
go
over
these.
Essentially,
there
are
two
problems.
First,
is
that
a
RFC
of
on
tunneling
of
ACN
didn't
quite
specify
its
scope
precisely
enough,
and
so
there
was
ambiguity,
weather
protocols
that
have
a
shim
between
two
IP
headers
were
included
in
its
scope.
F
F
F
The
the
main
problem
that
the
two
problems
I
just
talked
about
are
both
related
to,
in
that
double
column.
The
sort
of
second
and
third
from
the
right
safe
configuration
is
this
question
of,
is
it?
Is
it?
Can
it
be
safely
configured
when
it's
not
even
trying
to
implement
ACN
and
the
other
one
is
to
update
the
protocol
themselves?
And
so,
since
the
last
meeting
dealt
with,
or
at
least
added
all
these
mobile
IP
protocols
that
use
GRE
as
an
encapsulation.
F
Then
I
mentioned
tirado
last
time,
there's
a
little
Red
Cross
there
just
say:
I
would
have
liked
to
put
the
put
a
change.
The
protocol
in
this
RFC,
which
is
what
or
in
this
draft
that
to
become
an
RFC,
which
is
what
this
draft
is
for
and
I,
will
try
one
more
time
to
get
that
done
before
we
go
to
working
great
last
call
and
the
other
one
J
Collins
helped
me
a
lot
with
AMT
and
we've
put
up
an
update
into
the
protocol
and
he's
he's
gonna
be
implementing
that.
F
Then
there
was
UDP.
Tunneling
generally
had
missed
out
that
rather
important
in
important
one,
but
there's
already
an
RFC
that
covers
that,
and
there
was
a
really
quite
niche
one
with
using
TCP
as
an
in
Capulet
encapsulation
for
I
can
hip
set,
which
has,
or
at
least
now
has
good
text
in
it
and
gone
to
RFC.
So
next.
G
D
F
Well,
yeah,
it's
it's
I
mean
that
that's
the
sort
of
initial
grab
of
what
what
it
the
what
there
is
to
do.
But
then
this
explains
why
there's
still
some
crosses
in
the
column
that
says
where
the
where
the
protocol
needs
to
be
updated
and
why
it
hasn't
been,
and
that's
largely
based
on
human
interaction.
F
The
you
know
if
we
get
past
those
two
points:
I
proposed
a
fix
and
like
with
Jake,
it
gets
fixed
and
we're
done
did
the
same
with
l2tp,
but
in
some
other
cases
like
the
mobile
IP
ones,
I
get
the
feeling
that
it
would
be
an
academic
exercise.
It
wouldn't
really
yeah.
We
might
change
the
RSC's,
but
it's
not
going
to
change
anything
in
in
real
life.
So
I'm
it
seem
to
be
the
energy
there
to
do
it.
So
I'm,
you
know,
am
I
bothered.
D
F
Right,
okay,
so
the
specific
ones
have
been
updated
this
time
around
with
certainly
we've
updated
them
all
anyway,
by
putting
a
safety.
The
safety
flaws
in
them,
but
we
haven't
actually
updated
the
protocol
unless
we
got
someone
interested
so
and
the
reason
for
putting
the
safety
protocol
in
them
all,
or
at
least
the
safety
guidance
in
is
that
it
puts
and
updates
by
flag
on
their
RFC.
So
at
least
people
know
that
there's
there's
something
to
do
there
and.
D
F
D
Okay,
so
is
this
ready
for
working
group
Lashkar?
It's
the
drafts
as
it
stands
is
ready.
Now.
Yes,
all
right,
I
I
want
I
want
to
give
it
a
sanity
check,
read
before
I
sent
working
class
call,
but
yeah
I
think
any
getting
it
to
Andrew.
Last
call
before
the
end
at
the
end
of
November
is
reasonable.
Yeah.
F
Regarding
your
question
on
whether
it's
changing
other
you
know
making
a
load
of
other
RFC's
non-compliant,
that's
deliberately
not
the
case.
The
safety
thing
I've
not
said
anything
must
about
implementations.
I've
made
it
a
must
for
operators
to
configure
things
correctly
so
that
it's
it's
not,
and
then
there.
G
E
E
Hi
I'm
going
to
talk
about
the
le
PHB
and
as
a
chair,
so
I'll
come
over
here
to
make
running
the
slides
a
little
bit
easier
and
Roland's
in
the
room.
If
we
have
questions
on
the
draft,
but
this
isn't
really
about
questions
on
the
draft
at
the
moment.
What
I'm
going
to
do
is
try
and
just
take
through
the
discussion
about
the
Ayana
registry
and
the
choice
of
code
point
well,
I!
Don't
need
that
big!
That's
ridiculously
huge!.
E
Okay,
okay,
right
I
will
continue
the
the
draft
primarily
concerns
allocation
of
a
code
point
to
support,
lower
effort,
traffic
and
draft
IETF,
TS
v,
WG
le
p,
HB
and
next
slide.
Okay
and
the
world,
as
currently
stands,
has
tried
to
use
CS
1
and
to
define
a
code
point
that
can
be
used
for
sending
traffic.
That's
got
a
lower
effort
requirement
than
best
effort,
so
this
is
basically
scavenger
class
and
software
update
and
background
download.
Whatever
you
want
to
call
it.
E
However,
this
RFC
doesn't
actually
allocate
that
called
point,
and
that
code
point
has
some
known
problems.
It
has
known
problems
when
you
try
and
do
other
things
with
diffserv,
because
it
doesn't
really
fit
in
particularly
the
first
few
bits
of
the
value
0
0
1,
which
we
really
don't
want
to
have.
If
you
want
to
follow
that
discussion
either
come
to
the
mic
or
loop
back
in
the
proceedings
to
the
last
IETF,
where
we
discussed
all
this.
So
this
is
the
place
we're
trying
to
get
away
from.
E
This
is
the
current
I
on
a
registry
and
the
current
I
on
the
registry
and
has
many
items
in
there
which
are
being
used,
many
of
which
are
deployed
in
networks,
and
these
are
the
well-known
dscp
s.
The
only
active
pill
currently
in
the
IANA
registries
pill.
One
and
the
proposal
are
stated
in
Roland's
draft
and
proposed
to
the
working
group
in
Prague
was
we
could
use
dscp
to
the
SCP
2.
E
Twenty
percent
of
packets
remarked
this
way
now,
if
this
were
just
a
issue
within
your
own
domain,
that
might
not
be
in
it
might
not
really
be
a
problem
because
you
can
define
and
use
CS
1,
as
the
US
did
with
internet
I
mean
that
worked.
However,
if
we
want
to
define
something
that
works
end
to
end
and
I,
think
that's
the
main
purpose
of
things
in
TS
vwg.
We
want
to
value
that
doesn't
have
a
problem
when
there
are
mappings
by
real
equipment
now
there.
E
This
is
particularly
insidious
because
what
happens
with
the
toss,
precedence,
bleaching
action
is
that
other
traffic
gets
back
to
the
core
point.
That
we'd
propose
to
use
for
a
lower
effort
service
and
it
happens
to
be
part
of
the
AF
class
and
unfortunately
F
as
well,
so
it
really
makes
messes
up
the
whole
diffserv
domain.
If
you
start
then
using
dscp
for
le
traffic.
So
let's
move
on,
we
talked
about
this
and
I'll.
E
E
We
have
another
registry
pool
we've
currently
only
ever
allocated
from
registry
pool
one
it's
reserved
for
standards,
action
registry
pool
two
is
reserved
for
experimental
or
lawful
use,
and
we've
got
reason
to
believe
operators.
They've
used
these
code
points
they're
assigned
for
them.
We
expectancy,
we
continue
to
be
assigned
for
them,
but
then
there
is
pool
three
who
three
to
our
knowledge,
has
not
be
used
for
anything
or
standardized
in
any
way.
I
under
controls,
the
registry.
There
are
no
registry
entries.
E
The
pool
is
currently
being
used
for
whatever
purpose
out
there,
and
we
assume
that
that
purpose
can
change,
because
the
registry
is
marked
for
future
standard
action.
Allocations
are
necessary
as
necessary
could
be
because
we
ready
to
pull
one
allocations,
but
we'd
be
willing.
If
this
group
thinks
it's
the
right
thing
to
do,
to
ask
for
Ayane
to
open
up
that
registry
and
start
that
process.
D
E
D
I
think
that
covered
it,
as
I
said
earlier,
the
goal
of
this
time
period.
This
this
timeslot
agenda
was
not
so
much
to
make
the
decision
but
to
tee
up
what
we're
looking
at
and
why
we're
looking
at
it,
which
is
what
goriias
described
me
if
dhcp
two
had
been
satisfactory
cross.
The
board
we'd
have
probably
had
this
draft
of
at
the
RFC
editor
before
prog.
D
It's
not
there.
There
have
been
of
measurements
reported
that
that
the
do
show
that
that
this
precedence
bleaching
occurs
as
somebody
work
on
diffserv
I
was
annoyed
at
dscp,
bleaching
lead
bleats
all
six
bits
now
that
now
looks
like
a
feature
by
comparison.
Only
bleaching,
the
first
three
any
questions
or
comments
on
this.
D
We
have
to
take
them
in
the
hallway
afterwards
or
during
the
week.
The
goal
is
to
the
goal
is
to
make
a
decision
on
this
on
Friday
and
in
fact
one
of
the
sort
of
a
nefarious
agenda.
Manipulations
going
on
here
is
we're
going
to
tea
the
pie
shop
today
and
make
a
decision
on
Fridays
people
kind
of
think
about
it.
Mr.
carpenter,
sir,
the.
H
Feedback
right
here
at
just
an
observation
that
the
one
of
the
characteristics
have
pulled
three
is:
it
is
defined
as
four
local
or
experimental
use.
So
we
actually
don't
know
if
there
is
another
category,
if
operators
who
are
using
it
for
something
because
they're
not
obliged
to
tell
anybody.
So
it's
another
thing
to
think
about
when
thinking
about
opening
up
this
pool
and.
E
Yes,
please
think
about
that,
and
one
of
the
things
we
might
not
know
that,
if
not
wrote,
has
been
using
it.
They
may
also
understand
how
to
remark
diffserv
code
points
and
if
they
understand
how
to
do
that,
they
may
then
just
bleach
this
traffic
back
to
zero,
which
actually
is
not
a
disastrous
outcome.
E
F
D
I
And
remark:
at
Google
we
have
a
situation
where
we
have
a
list
than
based
if
it
code
point
allocated
for
our
internal
mappings,
and
there
are
many
parts
of
the
network
where
that
code
point
and
the
default
code
point
sherek
you
and
many
parts
where
they
do
not,
and
the
solution
of
using
a
less
than
beasty
for
transport
as
well
works.
Just
fine.
G
So
what
we're
seeing
is
increasing
fractions
of
the
transport
headers
being
encrypted,
and
this
is
reducing
the
visibility
of
the
the
various
transport
header
fields
right,
the
sequence
numbers,
the
acknowledgement
numbers
the
window.
The
flags
in
TCP,
for
example,
for
example,
are
not
visible
in
quick.
G
Maybe
this
is
better
yes,
okay,
good,
so
quick
as
an
example
of
this
we're
seeing
transport
protocols
making
the
choice
to
encrypt
more
of
the
headers,
and
it's
not
just
quick.
It's
it's
a
bunch
of
things,
but
quic
is
perhaps
the
the
most
active
of
them
right
now
and
in
principle
we
could
encrypt
everything
above
the
IP
header
in
the
port,
although
so
far
no
one
has
gone
all
of
it
gone
quite
that
far
next
slide.
G
So
there's
obviously
a
bunch
of
good
reasons
for
doing
this.
A
number
of
benefits
people
have
mentioned.
It
reduces
the
information
leakage
from
the
transport
layer
which
it
makes
it
harder
to
infer
the
connection
progress.
It
makes
it
harder
to
infer
things
like
the
round-trip
time,
the
timing
variation
and
it
prevents
some
spoofing
in
injection
attacks
and
just
generally
enhances
the
privacy
of
the
connection
enhances
privacy
of
the
transports.
G
G
What
has
perhaps
been
less
widely
discussed
is
that
there
are
some
costs
of
us
as
well.
There
are
costs
in
that
by
encrypting
all
of
the
transport
headers
or
a
significant
portion
of
the
transport
headers.
We
also
complicate
the
the
network
operations
to
some
extent
and
we
complicate
the
process
of
specifying
protocols
and
doing
research
and
developments
or
new
protocols.
G
So,
in
terms
of
network
operations,
obviously,
if
if
the
transport
headers
are
observable,
this
lets
the
network
operators
analyze
the
performance
of
their
network,
it
lets
them.
Look
at
the
behavior
of
the
flows
going
through
the
network,
detect
anomalies
check
to
see
that
you
know
and
get
some
understanding
of
that.
The
mix
of
traffic
in
there
informs
their
traffic
engineering,
their
capacity
planning
and
so
on,
and
this
gives
them
a
sort
of
overall
I
guess
passive
view
of
the
health
of
their
network
as
a
whole.
G
I'm
told
that
this
is
important
to
to
at
least
some
of
the
operators,
and
if
the
headers,
the
transport
had
to
start
being
encrypted,
these
operators
are
going
to
have
to
develop
workarounds,
and
some
of
that
might
be
a
statistical
classification
of
the
flows.
Some
of
it
might
be
active
traffic
probing
in
places
passive
analysis,
and
some
of
it
might
be
just
encapsulating
all
the
data
inside
some
sort
of
ship
lair,
which
replaces
the
head
as
we've
encrypted
at
the
transport.
But
people
people
need
this
information.
G
Addition
when
it
comes
to
debugging
I
mean
rather
than
thinking
of
the
health
of
the
overall
health
of
the
network.
We
also
have
to
think
about
debugging
particular
problems
with
particular
customers
networks,
for
example,
and
operators
have
the
problem.
Is
they
can't
observe
the
transport
behavior,
it's
very
difficult
to
debug?
What's
going
on
right,
you
know
if
the
the
headers
are
encrypted,
then
a
flow
which
is
being
subjects
packet
loss,
for
example,
is
indistinguishable
from
any
other
flow,
because
you
can't
see
the
sequence
numbers
and
tell
that
there
is
packet
loss
happening.
G
So
in
a
world
where
well,
significant
proportion
of
the
transport
headers
are
encrypted,
debugging
gets
difficult.
Maybe
we
have
to
do
active
probes
and
run
the
risk
that
the
active
probe
doesn't
have
the
same
characteristics
as
the
traffic.
The
user
was
happening.
Well,
it
was
using,
and
so
it
behaves
differently.
Maybe
it's
more
intrusive.
G
It
might
may
give
you
different
answers,
or
maybe
you
have
to
get
the
information
from
the
endpoints,
but
at
the
endpoint
thinks
the
connection
is
doing
after
it's
decrypted
that
information
and
the
question
then
is:
do
you
trust
that
endpoint
to
be
doing
it
correctly,
right
and
sure,
most
of
the
time
the
endpoint
will
not
be
lying
to
the
operator
that
you
don't
know
that,
and
you
can't
tell
for
sure
unless
you
can
see
the
transport
headers,
okay,
traffic
analysis.
Obviously,
if
you
you
can't
do
traffic
analysis.
G
If
you
encrypt
the
transport
headers,
the
operators
and
people
doing
research
on
network
protocols
can't
tell
if
the
transports
are
behaving
as
they're
expected
and
we're
sort
of
losing
the
information.
We
need
to
inform
future
developments
to
inform
future
standardization
because
we
don't
know
if
the
network
is
behaving
if
the
transport
is
behaving
as
we
believe
it
is,
and
we've
seen
a
number
of
presentations
earlier
in
mataji
and
I
see
Gogi,
for
example,
about
problems
with
existing
transports
and
that
these
things
happen
all
the
time
and
people
can
spot
it
because
they
can
do
measurements.
G
And
this
is
a
sort
of
similar
point
when
we
consulted
specifying
the
protocols
when
we
come
to
thinking
about
the
future
interactions
between
different
versions
of
the
protocol
between
protocols.
We
need
to
be
able
to
see
what's
going
on
and,
yes,
you
can
build
a
testbed
and
you
can
set
up
a
test
bed
that
decrypts
everything
and
logs
the
right
information,
and
you
can
start
to
understand
future
interactions.
G
That
way,
but
to
some
extent
you
have
to
do
this
in
a
while
to
really
understand
the
full
range
of
behaviors
that
you
see
in
the
real
network,
because
when
you
put
things
out
there
on
the
real
network,
you
find
some
weird
pathology
that
no
one
had
thought
of
again
that's
difficult.
If
the
headers
are
encrypted
a.
G
G
So
we're
not
against
transport
level,
encryption
encrypting,
the
transport
headers.
There
are
clearly
some
important
benefits
from
doing
this.
I
think
what,
as
perhaps
been
slightly
lost,
though,
is
that
there
also
costs
it
has
costs
in
terms
of
operations.
It's
got
costs
in
terms
of
how
we
deploy
protocols
and
how
we
build
standards
and
how
we
do
R&D
on
protocols,
and
we
need
to
seek
a
balance.
We
need
to
make
sure
that
we're
not
obstructing
real
needs,
which
will
just
force
people
to
deploy
workarounds
that
that
take
away
the
privacy
benefits
are
encrypting
it
anyway.
G
So
we'd
like
this
to
be
considered
as
a
working
group
item
we'd
like
this
to
be
considered
as
a
working
group
item.
So
we
can
get
some
discussion
of
these
issues
going
right
as
I
say,
we're
not
trying
to
say
don't
encrypt
the
transport
headers,
we're
trying
to
say
think
about
what
is
encrypted.
Think
about
the
stakeholders
here
and
make
sure
that
when
you
encrypt
things,
the
privacy
benefits
outweigh
the
costs
in
terms
of
operations
are
in
these
tenders,
developments
and
potentially
privacy,
because
people
deploy
more
invasive
monitoring
mechanisms.
K
K
Oh
sorry,
quick,
Lars,
I
get
Jeff
quick.
Does
this
document
have
a
relation
to
quick
I?
Think
quick
should
be
paying
attention
to
some
of
these
issues.
Do.
K
If
this
is
adopted
and
there's
consensus
for
these
things
in
here-
and
this
consensus
is
different
than
the
consensus
of
the
quick
working
group,
what
should
we
do
so
I'm
asking
specifically
because
for
those
of
you
are
not
in
quick
right,
there's
a
discussion
on
whether
quick
should
expose
some
limited
amount
of
information
about
its
operations,
such
as
the
RTT?
It's
seeing
in
the
clear
whether
that
clear
text
is
authenticated
or
not
is
up
for
discussion,
but
but
it
would
basically
be
observable,
but
not
necessarily
changeable
by
the
path.
K
So
that's
a
piece
of
information
that
that
sort
of
would
restore
some
visibility
into
what
Creek
is
doing,
that
otherwise
wouldn't
be
there
and
there's
an
ongoing
discussion
that
we're
gonna
have
on.
Well,
we
had
a
design
team
to
figure
out
whether
the
operator
community
felt
that
there
was
a
need
for
having
this
sort
of
information
available
and
and
spoiler
alert.
The
design
team
is
gonna
report
on
Wednesday
that
they
didn't
have
consensus
on
an
outcome.
So
there's
going
to
be
discussion
is
on
Wednesday.
This
seems
to
be
an
important
discussion
to
have.
A
K
G
D
It
out
speaking
as
the
uninvolved
chair
was
in
the
room,
I
certainly
understand
largest
process
concern,
which
is
in
particular.
If
quick
has
these
issues,
quick,
probably
ought
to
be.
The
first
worked
example
and
using
TS
vwg
to
end
run
quick
and
try
to
tell
quick
what
to
do
doesn't
tend
to
end
well,
so
I
think
I'd
like
to
avoid
that
basically
suggest
that
step.
One
is
to
focus
attention
on
on
these
on
these
issues
and
quick
and
see
where
that
goes.
I.
K
Says
we
need
to
have
the
discussion
just
to
clarify
right,
so
I'm
not
concerned
that
that
this
will
be
an
end
run
to
force
a
certain
outcome.
I'm
concerned
that
quick
will
be
blocked,
while
nothing
happens
on
this
discussion
right.
So
we
pushed
the
milestone
for
quick
out
by
six
months
and
we've
gotten
an
incredible
amount
of
feedback
from
large
implementers
that
this
is
very
problematic
and
they
really
want
a
shift
next
year
and
that
they.
K
So
the
argument
that's
been
made
and
I'm
not
saying
that
this
is
the
you
know
it's
true,
but
it's
been
made
several
times.
Is
that
IETF,
quick,
getting
delayed
means
that
proprietary,
quick,
we'll
see
more
deployment,
which
is
you
know,
not
necessarily
a
bad
thing,
but
it's
not
necessarily
outcome
that
the
ITF
would
want
to
see,
and-
and
so
they
that's
why
there
is
a
clock
here,
but
the.
K
The
danger
I
see
is
not
the
end
run.
The
danger
is
the
you
can't
put
a
quick
RFC
out.
While
you
know
we
don't
have
an
answer
here.
That's
good.
Let's
get
the
ad
done
like.
L
L
Spencer
Spencer's
opinion
about
this
is
that
this
thing
is
targeting
informational
and
that
it
seems
insane
to
hold
up
a
working
group
on
the
outcome
or
the
output
of
the
informational
draft
in
another
working
group.
I'm
not
saying
that
that's
never
happened
in
the
IETF,
but
it
shouldn't
happen
here.
It
seems
like
to
me
so
I
guess.
My
question
is.
L
L
I
wish
we've
been
working
on
it
all
along,
but
you
know
where
we
are
where
we
are
so
I'd
like
I'd
like
to
make
sure
that,
if
the
brainpower
that
goes
into
this
because
the
people
who
work
on
it
are
smart,
if
the
brainpower
that
goes
into
this
is
useful,
you
know
that
has
it
out,
but
they
could
be
used.
Someplace
that
that's
I
think
the
responses
you
know,
I
think
that's
the
the
responsibility
of
the
director
to
make
sure
that
that
happens.
J
If
its
status
here
I
think
we
need
to
sync
up
and
and
make
sure
that
the
insights
here
get
into
the
management
draft,
and
so
there
are
I'm
sure,
there's
a
thorough,
there's,
a
whole
list
of
other
drafts
that
touch
on
various
other
aspects
of
this
and
I'm,
assuming
that
you've
you've
at
least
skimmed
all
of
them,
and
that
you've
taken
the
you've
taken.
Two
things
from
those
that
are
relevant
and
you've
ignored
the
things
from
those
that
are
not
relevant.
E
Gauri,
coming
over
this
side
of
the
room
and
tried
to
sound
a
sensible
volume
level
and
yeah
we've
looked
at
many,
but
if
you
know
of
more
that's
always
good.
One
thing
in
particular,
is
the
one
that
Morton
and
Catherine
Moriarty
is
in
IES
is
in
IETF
last
call
at
the
moment,
and
that
looks
at
operational
viewpoints
of
various
stories,
things
that
are
going
on
in
the
operations
world.
So
if
people
aren't
just
in
this
subject,
that's
definitely
want
to
make
comment
on
the
ITF.
Listen.
J
M
Fleming
Andreasen,
so,
first
of
all,
thank
you
for
doing
this
work.
I
very
much
agree
with
the
message
that
you're
trying
to
send
here,
which
is
that
we
need
more
balance
in
this
debate.
We
all
understand
the
privacy
and
security
issues,
and
we
agree
that
they
need
to
be
addressed,
but
it
seems,
like
we've,
moved
a
little
bit
too
far
in
that
direction
and
and
we're
not
adequately
taking
into
consideration
what
are
the
implications
of
that?
So
I
am
very
supportive
of
both
the
message
and
the
the
intent
here.
M
So
I
would
like
to
see
this
work
move
forward.
I
think
some
good
questions
have
been
brought
up
in
terms
of
more
concretely.
What
does
that
mean?
But
I
think
for
starters,
if
we
can
get
on
a
page
where
everybody
recognizes
that
these
issues
need
to
be
addressed
as
well,
then
at
least
we're
off
to
a
good
start,
because
the
debate
tends
to
go
too
much
in
one
direction
right
now,
in
my
experience
at
least,
could.
D
N
Or
any
Evan
I
think
I
support.
This
document
I
think
it's
important,
because
currently
there
is
a
BCP
101
that
says
that
network
might.
Even
though
security
is
the
important
I
mean
network
need
to
be
manageable,
but
it
doesn't
say
what
it
means
to
be
manageable.
I
think
this
thing
says
what
is
needed
in
order
for
the
network
to
be
managed
and
that's
why
I
think
it's
important,
because
it's
its
complement,
this
IB
document
and
I
think
that
should
be
considered
for
every
transport
that
we
are
doing
now
and.
O
Julie
so
I'm
largely
sympathetic
to
the
vantage
point.
We're
in
systems
need
to
be
protected
from
meddling
of
middleboxes
the
network
itself
and.
O
The
depredations
of
outside
observation,
one
of
the
problems
I
also
have,
of
course,
is
that
I
actually
have
to
protect
endpoints
in
ways
that
are
sufficiently
scaleable
that
they
don't
have
to
get
wiped
off
the
map
by
large
collections
of
devices
that
may
or
may
not
wish
to
reveal
their
intentions
before
sending
me
a
packet
but
I
think
one
of
the
things
that
is
sort
of
poorly
explored
in
our
understanding
of
why
people
want
visibility
or
or
control
in
in
transports
is
the
question
of
the
integrity
of
the
material.
That's
within
them.
O
So
some
of
the
biggest
problems
we
have
or
when
people
design
middle
boxes
that
manipulate
the
stuff,
without
necessarily
disclosing
that
they're
doing
that
and
I
think
that
actually
is
because
for
things
where
we
wanted
to
provide
visibility,
we
didn't
provide
enough
protection
for
integrity
where
that
was
actually
a
required
feature
as
well.
O
So,
for
example,
that
translators
are
enabled
by
the
fact
that
you
can
manipulate
the
source,
ports
or
destination
ports
for
that
matter,
without
without
any
significant
effort
like
encapsulation,
for
example,
you
can
simply
rewrite
the
packet
because
those
things
are
not
protected
in
any
cryptographically
significant
way.
I'd
still
like
to
know
what
a
flow
is
that
doesn't
mean
that
I
necessarily
want
middleboxes
to
be
able
to
change
change,
elements
of
that
and
I
think
integrity,
protection,
particularly
cryptographic.
B
K
I
said
not
not
to
begin
at
Scripture
this
time
and
following
up
to
a
Joel
set,
so
integrity
protection
is
certainly
it's
not
controversial,
really
I
think
that
we
should
call
it
a
beauty.
Protection
is
and
I
think
not
controversial,
and
so
Fleming
painted
the
picture
that
this
is
your
privacy
versus
operations.
K
It's
actually
not,
or
not,
only
right,
privacy,
certainly
one
one
aspect,
but
there's
also
the
aspect
of
even
if
your
integrity
protect
transport
level,
information,
middle
boxes
are
going
to
ossify
around
what
they
see,
and
we
want
to
be
able
to
change
that,
and
we
can't,
if
it's
in
the
clear,
because
stuff
will
be
shipped
that
things
this
field
is
always
this
and
and
if
it's
not
anymore,
it'll
go
wrong.
That's
the
harder
problem
attracted
well,
it's
also
a
hard
problem.
K
Privacy
I,
don't
understand
very
deeply,
so
I'm
not
going
to
comment
on
it,
but
but
it
once
you
expose
it
right.
It
is
actually
gonna
be
used
and
when
we
wrote
a
new
version
of
quick,
we're,
gonna
be
rolling
them
frequently
and
we're
gonna
dip
those
bits
or
can
I
have
something
else
in
them.
You
know
the
middle
boxes
are
not
necessarily
gonna
know
what
to
do
with
that
for
very
long
either.
You're
gonna
update
them.
You
know
a
lot
or
you're
gonna
have
a
little
box.
K
That's
not
very
useful
and
be
doing
this,
because
what
we
found
with
TCP
or
is
that
there
is
enough
old,
crap
out
there
that
actually
breaks
TCP.
It
makes
it
slower
these
days
right.
So
v6
is
faster
than
before,
mostly
because
there's
not
so
much
crap
in
the
path
and
and
encrypting,
everything
is
a
way
to
not
allow
crap
to
have
anything
to
grab
on
and
and
that's
an
argument.
I
think
that
resonates
with
you
personally
and
I
would
love
to
hear
from
operators
that
come
and
say.
When
are
we
doing
this?
K
We
have
a
very
limited
need
for
a
piece
of
information.
This
is
something
that
you
know
is
is
has
consensus
to
be
good
to
expose
were
helpful
to
expose
I
personally,
haven't
really
seen
it
yet,
but
that
those
sorts
of
things
are
interesting,
because
otherwise
you
know
the
I
fully
subscribes.
You
a
point
right.
I
have
a
research
hat
that
I
occasionally
use
for
stuff
and
it's
nice
to
be
able
to
see
stuff
and
measure
stuff,
and
it
helps
us
learn
things
about
the
network,
but
that
same
information
makes
the
network
ossify.
Yes
and.
G
I
think
the
the
trade-off,
which
is
perhaps
not
as
widely
discussed
as
it
should
be,
is
where
the
ossification
is
a
good
thing
or
a
bad
thing
and
in
some
ways
it's
clearly
a
bad
thing,
because
it
stops
us
changing
things
in
other
ways.
It's
a
good
thing
because
it
stops
us
changing
things
and
it
means
we
have
been
successful
and
the
stuff
is
out
there
and
being
used
and
people
are
building
on
it.
G
P
Mark
Townsley
from
Cisco
I
think
that
the
current
current
cat-and-mouse
game
between
the
endpoints
and
the
network
elements
in
points
hide
from
the
network
elements
and
network
elements
do
more
and
more
things
to
discover
the
end
points.
Even
if
everything's
encrypted
will,
you
know,
will
analyze
the
flows,
apply
a
signature
databases,
machine
learning,
you
name
it
to
figure
out
what's
going
on
there,
because
our
operators
or
customers
demand
it
right.
So
this
is
a
race
to
the
bottom.