►
From YouTube: IETF101-TAPS-20180321-0930
Description
TAPS meeting session at IETF101
2018/03/21 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
C
C
B
E
F
C
G
F
B
H
B
I
C
For
those
who
are
new
to
this
working
group,
I
mean
this
work.
You
will
be
working
on
an
abstract
API,
where
application
does
entail,
which
transport
to
use
rather
get
the
transporter
services
by
telling
them
what
they
want
to
do.
So
this
is
not
well
I.
Think
most
of
us
know
about
it.
If
you
not,
please
have
a
look
and
also
read
about
the
web
pages
yeah.
So
this
is
media
hydrogen
sharper
and
co-chairing
the
steps
working
group
with
our
own
phone,
hello,
so
I
think
there
will
be.
C
B
K
L
B
So
a
little
bit
of
update
on
what's
going
on
the
working
group
first
are
our
second
and
third
documents
have
been
published,
so
we've
got
three
RFC's
out
now,
which
I,
frankly
I'm
a
little
bit
surprised.
We've
gotten
this
far,
but
I
continue
to
feel
better
about
this
group.
Every
meeting
we
get
so
you
guys
have
stepped
up
and
you
know
taking
something
all
the
way
through
our
receiver
acquires
really
like
some
follow-through
and
dedication.
So
thank
you
very
much
to
the
authors
for
getting
the
news
out.
B
B
So,
as
we
talked
about
in
last
couple
meetings,
we
have
revised
the
Charter.
There
are
two
there's
a
few
knits
which
you
can
see
on
the
data
tracker,
but
the
two
most
important
bits
are
one.
We
have
a
new
and
entry
on
our
scope
of
work
about
looking
at
transport
security
protocols.
The
new
text
is
here
that
we're
going
to
analyze,
compare
and
contrast
properties
and
dependencies
of
selected
IETF
transport
security
protocols
and
other
relevant
security
protocols,
as
agreed
upon
by
the
working
group,
participants
define
a
set
of
security.
B
So
you
know
anything
that
crosses
from
the
transport
tribe
to
another
tribe,
like
the
security
tribe
is
always
a
little
thorny
in
getting
agreement,
and
so
this
took
a
few
rounds
of
through
IHG
review,
but
actually
once
we
got
the
wording
right,
everybody
was
in
supportive
of
it.
So
so
I
think
this
is
more
good
work.
The
other
thing
that
we
did,
which
is
when
we
first
charted
the
group
we
were
going
to.
We
set
the
bar
kind
of
low.
B
We
said
we're
going
to
produce
basically
informational
documents
and
I
think
that
everybody's
confidence
is
higher
and
I
think
that
the
focus
is
really.
Things
are
converging
to
the
point
that
we
felt
comfortable,
proposing
that
the
final
output
of
the
working
group
is
going
to
be
a
set
of
proposed
standards.
So
I
think
that's
good
too.
That
taps
will
be
a
standard
not
that
we
can
force
anybody
implement
it,
but
we'll
make
a
standard.
We
updated
the
schedule,
so
the
security
document
we'd
like
to
get
done
by
next
ITF.
B
B
B
J
All
right
morning,
everyone,
my
name,
is
Chris
wood,
I'm
from
Apple
I'm
gonna,
give
you
an
update
on
the
secure
drop
that
we've
been
working
on
for
a
while
now
with
Tommy,
follow
the
kallenberg
and
Kairos
slide
please.
So
the
point
of
this
document
is
pretty
straightforward,
similar
to
the
transport
services,
the
RFC's
that
we've
already
put
out.
We
want
to
look
at
the
services
that
are
provided
by
Transport
security
protocols.
The
interface
is
that
these
protocols
have
them
to
provide
in
which
we
would
like
to
incorporate
in
the
new
taps
architecture.
J
So
the
I
guess
outline
of
the
document
follows
this.
These
three
simple
points
here
we
go
through
and
surveys
a
bunch
of
existing
transport
security
protocols,
both
within
the
ITF
and
outside
of
the
ITF,
extract.
What
we
deemed
the
mandatory
features
and
optionally
the
optional
features
as
well,
and
then
identify
these
common
interfaces
such
that,
if
you
were
to
integrate
or
implement
these
protocols
within
the
context
of
a
taps
architecture,
they
could
just
kind
of
slide
in
and
applications
can
make
use
of
them.
So
they
need
to
know
if
they're,
using
TLS
for
something
specific.
J
M
J
Charter
text
says
that
we're
going
to
be
looking
strictly
at
ITF
protocols.
The
document
itself
considers
those
both
in
the
ITF
and
outside
the
ITF
in
particular,
because
there's
a
lot
of
innovation,
that
kind
of
happens
with
security
protocols
outside
of
the
ITF,
and
there
are
many
things
that
don't
have
RFC's
that
should
be
looked
at
if
we're
going
to
kind
of
help.
J
The
new
generic
API
that
could
be
used
by
any
and
all
applications
in
the
future
and
additionally,
in
whitson
scope,
work
like
I,
said
we're
gonna
be
analyzing
these
new
transport
security
protocols,
potentially
in
collaboration
with
the
security
area,
to
make
sure
that
we
identify
what
we
deem
or
what
we
deem
is
say
a
mandatory
future
or
a
necessary
interface
is
actually
a
mandatory
and
necessary
interface,
because
those
are
the
main
experts
there.
We're
gonna
make
sure
we
get
that
information.
Correct.
J
What's
out
of
scope
is
absolutely
any
kind
of
recommendation
for
which
protocol
or
algorithm
to
use
or
I
can
say
you
must
use.
You
know
cha-cha
follow
your
AES
GCM,
whatever
or
TLS
1.3
instead
of
quick
or
you
know,
pick
your
poison
I
guess,
but
we're
also
not
going
to
be
building
any
new
protocols,
because
that's
the
job
and
responsibility
of
those
that
are
not
in
the
transport
area.
J
Please
so
a
little
bit
of
history
here
back
in
Chicago
I
believe
was
the
first
time
took
an
action
item
to
start
looking
at
the
security
properties
of
existing
transport
security
protocols
and
the
ITF
99,
we
produced
the
zero
zero
version,
which
included
just
a
base
set
things
like
TLS
minimal
T,
which
is
a
non
IDF
protocol,
courtesy
P,
also
non
IDF
protocol,
PCP,
crypt
and
IP
to
DSP
the
next
site.
Ef.
J
There
will
be
more
protocols
here,
and
hopefully
they
will
be
representative
of
what
the
Internet
at
large
uses
for
Transport
Security
next
slide,
please.
So
the
methodology
within
the
draft
is
I,
guess
fairly
straightforward.
We
try
to
decouple
the
relevant
bits
of
the
transport
security
protocols
that
we're
looking
at.
In
particular,
we
try
to
focus
on
what
we
consider
to
be
the
handshake
parts
of
a
protocol
and
the
record
or
framing
parts
of
a
protocol.
This
is
important
because
some
don't
have
both.
J
For
example,
ESB
doesn't
have
a
handshake,
it's
just
pretty
much
a
record
protocol
with
some
framing
give
it
a
key
and
you
encrypt
datagrams,
and
it
goes
the
other
side
and
some
protocols,
just
don't-
have
any
kind
of
framing
built
in
them
whatsoever.
I
mentioned
noise
here,
which
is
not
technically
protocol.
It's
a
protocol
framework,
but
that's
purely
about
building.
You
know
key
exchange.
Handshake
protocols
has
nothing
to
do
or
talks
nothing
about
how
you
actually
encode
messages
and
send
in
to
the
other
side.
J
So
we
want
to
make
sure
we
distinguish
between
the
two
additionally
we're
trying
to
focus
strictly
on
the
interface
of
these
protocols
as
specified
and
hopefully
soon
as
implemented,
because
there
is
a
bit
of
a
delta
there
and
practice.
Quite
often,
we
don't
care
necessarily
about
what
the
implementation
details
we
just
want
to
make
sure
that
we
get
the
interface
correct,
and
this
is
analogous
to
the
endeavour
and
the
goals
of
the
transport
services
or
the
transport
services
RFC.
Eighty
or
ninety
five
next
slide,
please.
J
So
when
looking
at
these
different
protocols,
we
don't
really
we're
not
restricting
them
to
any
player
in
the
stack.
So,
for
example,
like
USB
and
wire
guard,
far
away
at
the
bottom
right
about
the
internet
layer,
and
then
things
like
DT,
OS,
TLS
and
quic
can
exist
up
at
the
session
layer
and
we
might
even
creep
up
as
far
as
you
know,
looking
at
application
layer
TLS
if
we
feel
so
advantageous,
because
that's
yet
another
transport
security
protocol.
But
don't
quote
me
on
that.
I
may
change
my
mind.
J
So
the
point
here
being
we're
not
trying
to
focus
on
one
particular
layer,
because
the
interface
at
are
for
each
of
these
particular
protocols
is
fairly
common,
regardless
or
yeah.
I
guess,
regardless
of
its
position
in
this
stack,
I
slide
please
and
before
I
guess:
I
go
into
some
of
the
features
it's
worth
kind
of
commenting
on
how
the
I
would
envision
the
security
protocol
sort
of
fit
into
the
taps,
architecture,
which
everyone
will
go
into
much
more
detail
later
on
in
general.
J
The
goal
is
to
kind
of
abstract
away
the
the
specific
security
protocol
on
use
inside
this
steps-
architecture,
black
box
here
and
then
at
various
points
during
the
applications.
Use
of
the
tap
system
use
different
interfaces
to
either
configure
or
dynamically.
You
know
tune
or
I
guess,
update
the
protocol
in
action.
J
So,
for
example,
if
you
dress
protocol
or
the
security
protocol,
calls
out
to
the
application
to
validate
certificate
from
a
peer,
you
would
do
that
kind
of
during
the
online
connection
setup
phase,
and
then
you
use
a
different
set
of
interfaces
when
the
connection
is
actually
established.
You
need
to
read
my
data
or
you
want
to
get
actually
metadata
properties
from
the
security
protocol
configuration
and
the
API
that
the
API
that
we're
striving
for
would
map
to
the
specific
implementation.
Api.
J
That's
inside
the
taps,
architecture,
for
example,
the
security
API
that
exists
at
a
player
would
map
to
how
you
would
drive
TLS.
You
know
internally.
So,
for
example,
if
you
were
to
set
a
private
key
and
within
the
taps
layer,
it
just
would
set
a
private
key
for
TLS,
a
specific
specific
use.
If
you
were
to
set
a
specific
algorithm
that
you
might
want
to
use
for
you
know
encryption
or
whatever,
that
would
set
a
specific
cipher
suite
in
TLS
internally.
J
So
applications
are
it
kind
of
like
ideally
unaware
of
which
specific
protocols
and
use
they
just
know
that
I
have
these
specific
security
properties,
here's
how
I
configure
them!
Here's,
how
I
here's?
What
I
have
to
do?
You
know
during
connection
establishment
and
here's
what
I
can
do
when
the
connection
is
established
and
what
I
can
do
when
I
want
to
tear
it
down.
So
next
slide,
please!
J
J
So
if
it
the
private
key
stored
in
the
hardware,
you
know
HSM
or
an
enclave
or
something
like
that,
it's
necessary
for
the
specific
invitation
be
able
to
access
that
private
key
to
perform
a
digital
signature
or
something
it's
absolutely
mandatory
that
the
handshake
work
I'll
be
able
to
authenticate
the
peer
or
the
remote
in
this
case,
so
that
you
know
who
you're
speaking
to
and
it
must
be
able
to
validate
the
source
of
a
connection.
So,
for
example,
many
DTLS
implementations
or
DLT
on
spec.
J
If
it's
under
heavy
load,
a
DTR
server
can
provide
cookie
back
to
the
client
and
the
client
must
I
got
my
cookie
back,
there's
a
way
of
validating
that
the
packet
came
from.
You
know
some
particular
specific
source
and
it's
not
being
spoofed
and
flooded
with
you
know,
just
garbage
and
shake
or
client
hello,
packets.
J
So
the
TLS!
You
don't
worry
about
this,
because
you're
built
on
top
of
TCP
and
you
kind
of
have
that
implicitly,
you
know
supply
for
you.
But
you
know,
because
many
protocols
add
this
feature
in
after
the
fact.
We
consider
it
to
be
a
mandatory
thing
that
the
handshake
should
provide
optionally.
We
would
like
to
support
mutual
authentication,
that's
not
something
that
every
single
protocol
does,
but
it's
quite
common.
So,
for
example,
TLS
obviously
provides
client
and
server
authentication
application
layer
feature
negotiation.
J
So
you
can
just
extend
it
for
days
and
do
whatever
you
want,
provided
that
you
know
no
one
yells
at
you
when
you
present
your
extension,
it,
the
Mike
I
fir
back
to
the
earlier
meeting
this
week
and
being
able
to
kind
of
cache
previously
negotiated
session
and
state
material
was
also
quite
common,
but
again
not
essential
to
the
operation
of
the
handshake
protocol.
It's
just
kind
of
an
optimization
that
really
helps
move
things
along
and
managing
that
stay
is
also
pretty
important
like
if
you
want
to
be
able
to
flush
it
on
demand.
J
From
the
record
side,
because
the
the
purpose
of
the
record
protocol
is
quite
simple,
the
features
that
we
must
support
are
obviously
very
small.
For
example,
you
should
be
able
to
import-
or
you
know,
given
a
key
encryption
datagrams
and
send
them
in
I
kind
of
said.
Together,
you
should
be
able
to
encrypt
on
authenticate
any
kind
of
Datagram
or
segment
here.
I
guess
one
outstanding
issue
attacks
we
could
address
this
kind
of
unifying
the
terms
that
were
kind
of
I'm.
Throwing
around
here
is
a
record
segment,
whatever
Datagram
it'd
be
used
to.
J
J
There's
kind
of
two
there's
really
three
distinct
phases
in
which
you
interact
with
the
protocol.
There's
the
configurations
stage
at
during
the
pre
connection
setup
time,
there's
the
active
kind
of
interfaces
that
you
must
work
with
during
the
connections
phase
and
then
there's
the
interface
that
you
can
invoke
and
use
once
the
connection
is
established
so
during
configuration.
This
is
the
time
when
you
know
you
actually
tell
the
security
protocol,
here's
everything
you
might
need
to
do
to
or
might
need
to
use
in
order
to
set
up
a
connection.
J
So
if
you're
a
server,
for
example,
you
might
need
to
specify
a
private
key.
Otherwise
you
can't
do
anything
and
talk
to
anyone.
You
may
need
to
provide
what
you're
supported
algorithms
are
and
a
delegate,
though
I
call
back
essentially
to
be
invoked
if
you
want
to
authenticate
or
do
any
kind
of
peer
validation,
and
you
might
also
want
to
like
specify
parameters
for
the
session
cache
if
one
such
exists.
Now
all
this
is
not
necessarily
something
that
applications
would
need
to
do.
Particular
authentication
delegation
session
cache
management
and
support
algorithms
in
in
practice.
J
It
would
be
nice
if
those
were
things
that
are
just
handled
by
the
system
by
default.
You
know
you
have
a
good
set
of
agreed-upon
algorithms,
that
you
know
the
system
considers
safe.
There
is
a
the
tap
system
itself
manages
the
session
cash
in
the
application
is
absolutely
nothing
to
do
with
it,
and
you
know
validating
a
peer
or
something
that's
kind
of
deferred
to
you
know
the
system
itself.
Now
there
are
cases
where
applications
may
want
to
override
your
validation,
like
if
they're
doing,
certificate
pinning-
and
maybe
that's
not
easy
to
do
so.
J
J
You
need
to
be
specific
here
for
the
handshake
handshake
bits
if
you're
called
the
api's
at
the
taps,
layer
would
go
down
to
the
api's
at
the
security
protocol
which
drive
the
handshake
bit
of
the
protocol
and
then
drive
the
record
bit
of
vertigo
need
to
obviously
be
able
to
send
and
receive
handshake
messages.
I
think
that's
fairly
obvious.
You
feel
they
validate
the
identity
of
the
peer
perform.
The
source
address
validation.
These
features
that
I
was
mentioning
earlier.
Additionally,
providing
an
interface
for
key
updates
is
quite
useful.
J
So,
for
example,
when
the
connection
is
established,
you
get
an
update
that
you
have
a
new
key
available
and
then
tell
us,
or
the
application
that's
built
on
top
with
us,
might
extract
that
pre
shared
key
and
use
it
for
other
purposes,
quick,
for
example.
It
does
exactly
this
and
you
know
the
pre
sure
key
export
interface
goes
along
with
that
key
update
interface.
So
thank
you
so
fairly
straightforward,
the
record
interface
again,
because
it's
quite
simple,
the
interface
is
also
pretty
lightweight.
J
It
should
be
able
to
import
a
PSK
and
then
use
it
to
encrypt
application
data.
Or
do
you
clip
the
application
data
depending
on
what
you're
doing
it
would
be
nice
if
you
know
so.
This
is
not
something
at
all.
I
guess
record
protocol
implementations
support,
but
it
would
be
nice
if
the
record
protocol
itself
kept
track
of
what
the
maximum
number
of
bytes
I
can
encrypt
with.
This
key
is
and
then
tell
you
the
application.
B
J
I
include
you
to
go.
Look
at
the
draft.
It's
it's
survey,
so
there's
a
lot
of
information
there
and
there's
certainly
room
for
improvement.
In
particular,
there
are
several
outstanding
issues:
we'd
like
to
kind
of
unify
the
document
structures.
The
point
raised
by
Kyle.
There
are
some
instances
where
we
don't
follow
the
same
convention
and
how
we
describe
certain
features
and
certain
interfaces
of
a
protocol
and
how
we
kind
of
pull
things
together
at
the
end.
So
I
don't
know,
maybe
you
guys
plan
to
work
on
that
in
the
end
or
I.
J
Okay,
all
right
we'd
also
like
to
expand
the
security
considerations.
In
particular.
This
is
where
all
the
output
from
the
interaction
with
the
security
community
would
go
working
with
them
to
make
sure
that
we
get
the
text
right
about
what
we
should
and
should
not
say
about
usage
of
these
security
protocols
and
whatnot,
because
right
now,
it's
kind
of
light.
Another
thing
that
I
kind
of
alluded
to
earlier
is-
and
this
is
sort
of
a
made-
a
bigger
task-
is
to
identify
the
Delta
between
protocol
implementations
and
there
you
know
standardized.
J
You
know
what
the
standards
say,
because
that
will
help
us
kind
of
identify
any
missing
gaps
that
may
be
missing
from
the
interface,
and
we
may
want
to
include
four.
You
know,
I,
guess,
being
more
or
getting
greater
coverage
and
getting
things
more
correct.
So
next
steps
are
you
still
waiting
until
the
end?
Okay?
So
next
ups,
because
this
is
now
in
the
Charter
that
we'd
like
to
call
for
working
group
adoption
of
this
particular
draft
and
continue
just
hammering
out
and
adding
these
new
protocols
as
needed?
There's
a
bunch
of
issues
here.
J
So
if
you
feel
so
inclined
to
tackle
one
boat
requests
are
absolutely
welcome
and
I.
Don't
know
if
I
have
a
link
to
the
repository,
but
I
can
certainly
circulate
once
the
list
and
everyone
can
submit
their
poll
requests
there
and
then
in
tandem
commence
the
reviews
at
the
security
area,
because
we
want
to
get
that
ball
rolling
depending
on
how
long
it
may
or
may
not
take
and
I.
Think
that's
in
so
Kyle
Kyle.
J
N
O
N
Very
low,
okay,
so
in
the
process
of
working
on
this
document,
I
think
there's
one
thing:
that's
been
making
me
a
little
bit
uneasy
and
I
in
conversations
with
Aaron
I
got
kind
of
the
same,
the
same
feeling
from
him.
It's
about
scope
and
scope,
creep
and
I
feel
like
so
one
of
the
things
that
you
said
early
on
in
the
presentation
was
well
we're
gonna
cover
everything
right
and
it's
like
well
I
mean.
N
And
you
know
that's,
but
anyway
right,
it's
just
so
like
I,
think
I.
Think
I'm
wondering
if,
as
devil's
advocate
a
better
approach
might
be
to
just
make
sure
that
we
choose
enough
protocols
to
analyze
where
recover
the
set
of
the
basically,
where
we,
where
we
can
determine
what
the
set
of
features
that
each
of
these
protocols
might
have
and
then
maybe
and
then
maybe
from
that
derive
a
set
of
shim
interfaces
that
are
required
as
a
as
an
interface
to
taps
itself.
Right.
N
So
essentially,
if,
if
some
let's
say
some,
some
security
protocol
is
lacks
an
automatic
mechanism
for
key
rotation
after
a
certain
number
of
records
have
been
encrypted
right,
you
could,
you
can
imagine
a
shim
layer
between
that
and
the
rest
of
taps.
That
says
all
right
at
this
point,
we
are
going
to
force
a
renegotiation
or
something
like
that
to
to
cover
that
requirement.
N
J
Very
good
point
I
think
in
looking
at
the
implementations
that
will
kind
of
help
us
really
confirm
or
deny
whether
or
not
we
got
the
selection
correct.
That
is
to
say
if
we
started
looking
implementations
of
like
Tila
stacks
that
are
not
our
own
and
we
find
out
that
there's
there's
these
massive
features
that,
like
just,
are
not
in
the
standard,
but
everyone
does
like
that.
Will
kind
of
that.
J
That's
a
good
indication
that
there
is
a
gap
in
the
protocols
that
we
selected,
and
maybe
it
was
provided
by
a
different
protocol
that
was
not
DLS,
but
it's
there.
It
needs
to
be
covered,
so
I
I
think
there
are
the
outstanding
issues
that
are
on
the
github
tracker
to
add.
A
bunch
of
these
new
protocols
are
there's
quite
a
number
of
them
and
we
could
certainly
just
say
okay
for
now.
Let's
just
stick
to
the
ones.
J
We
have
maybe
look
at
some
of
when
tations
to
see
if
anything
pops
up
and
if
it
does
maybe
then
increase
the
scope
a
little
bit
but
again,
I'm
not
quite
sure
that
that's
the
right
approach,
I
mean
people
who
worked
on
these
surveys
in
the
past.
I,
of
course,
open
to
suggestions.
I
know
that
we
need
to
be
sensitive
to
the
time,
especially
if
we
want
to
get
this
done
by
next
idea.
So
I
write.
N
N
Framework,
it
uses
some
protocols,
it's
sort
of
taps
like
in
a
sense,
but
where
you
know
where
do
you
stop
and
it
seems
like
it
seems
like
what
you
want
is
to
is
to
choose
a
set
of
protocols
from
which
you
can,
from
which
you
can
then
kind
of
distill
out?
What
are
the
important
features
that
a
that
the
tap
Slayer
is
going
to
need
and
which
protocols
can
be
kind
of
retrofitted
to
have
all
of
those
if
they
don't
have
them
natively,
I,
agree.
N
I,
also,
agree
that,
like
like
separating
the
handshake
and
record
protocols,
might
make
sense
because
in
a
sense,
right,
TLS
and
DTLS
are
the
same
protocol
at
the
handshake
layer
right,
but
it's
at
the
record
layer
where
they
differ,
and
that
might
make
a
difference
to
which
transport
you
choose
when
you're
deciding
well,
you
know
when
you're
deciding
between
say,
you
know,
messages
that
don't
require
reliability
and
the
stream,
but
it's
but
does
the
is
the
handshake
really
different
or
the
security
property
is
really
different.
Not
I
mean
a
little
bit,
but.
J
Q
The
question
about
scope,
I
think
that
we
could
go
we
and
by
we
I
mean
you
I
guess
document
could
go
relatively
quickly
through
that
list
of
open
issues
and
do
a
relatively
quick
judgment
call
as
to
whether
you're
not
you're
gonna
get
something
into
the
set
of
sort
of
interface
characteristics
by
adding
a
protocol
right.
So
so,
looking
back
at
80
95,
it
has
a
gigantic
glaring
omission.
It
doesn't
talk
at
all
about
quick,
but
adding
quick
wouldn't
actually
bring
anything
because
quick
doesn't
add.
Q
Q
We
looked
at
a
bunch
of
other
ones
very
quickly.
Here
are
some
references
to
them.
They
don't
add
anything
to
the
to
what
we
have
here.
I
had
two
questions.
One
is
a
buzz
word,
troll
question
from
Twitter
sharam,
post
quantum
Krypto
I.
Don't
think
that
I
don't
think
that'll
change.
Anything!
No
in
terms
of
okay
good!
Is
it
deployed.
Q
Q
J
J
Q
O
Q
B
So,
first
great
document,
thank
you
for
pulling
this
together.
I'm
Erin
Faulk
occupying
also
co-chair
the
working
group,
not
sure
if
I'm
wearing
my
sure
hat,
but
as
a
as
a
a
reader
of
the
document,
I
thought
that
it
was
it's
good
on
the
issue
of
which
protocols
to
include
on
the
scope.
I
think
this
is
an
area
where
we
want
to
get
input
from
the
security
area.
You
know
transport
shouldn't
be
saying
what
the
important
security
protocols
are
in
the
internet.
They
might
have
opinions
that
you
know,
or
you
know,
I
already
said.
B
J
B
B
That's
this
one
so
I'm
trying
to
take
that
picture
and
now
go
to
the
next
slide
and
I'm
trying
to
squeeze
all
those
protocols
somewhere
into
this
picture,
and
so
it
looks
to
me
like
what
you're
doing
is
you're
moving
the
API.
However
high
up,
you
need
to
go
so
that
all
the
security
protocols
fall
inside
it.
Is
that
true,
or
is
this
actually
not
as
clean
as
you
drive
so.
J
In
practice,
we
would
likely
go
up
as
up
this
high.
Essentially,
we
want
to
include
at
least
these
protocols
whether
or
not
we
push
it
up.
Even
higher
is
open
for
debate
and
likely
will
not
my
comment
about
going
up
higher
and
you
know
looking
at
things
higher
up,
the
stack
was
strictly
to
kind
of
tease
out
any
other
features
that
we
might
be
missing.
The.
B
B
Think
that
that
may
eliminate
some
things
from
the
list,
because
there
might
be
some
things
where
you
actually.
You
know
it
is
an
application
and
it
needs
to
be
tightly
involved
in
this
right,
I'm
sort
of
going
on
company'll
here,
but
it
seems
to
me
like,
like
work
to
a
little
bit
we're
when
it
was
TLS.
Okay,
it's
easy
to
see.
They've
got
the
shim
that
sits
on
top
of
the
transport
protocols,
but
now
we're
kind
of
working.
Our
way
up,
yeah.
J
R
Sorry,
quality
Apple
to
the
point
of
what
protocols
are
in
scope
and
level
here,
I
think
we
should
limit
it
essentially
to
the
type
of
things
we
have
that
are
like
TLS
or
DTLS.
Even
if
they're
not
considered
to
be
truly
transport
protocols
generally,
they
are
essentially
just
providing
a
pseudo
transport
layer
with
extra
functionality
involved
in
them,
but
the
applications
relationship
with
reading
writing
on
them
is
essentially
the
relationship
of
an
application
to.
B
R
That
would
be
good.
We
could
even
essentially
just
define
that
in
the
document
saying
that
the
we
are
considering
security
protocols
that
behave
like
transports
when
the
application
uses
them.
Let's
take
that
down
the
notes
but
Texas
effectively,
but
that's
alright
I
think
implicitly
we're
thinking
of
that
in
the
back
of
our
heads.
But
it's
not
spelled
out
yeah
well
to
agree.
R
C
Tremendous
the
the
updated
term
says
like
it's
a
limited
set
of
ID
protocol
as
well,
so
who
might
be
possible
as
a
mighty
protocol
going
to
the
appendix
as
well.
So
when
you
are
setting
up
the
test,
you
need
to
also
come
up
with
like
it's
not
about
only
then
non
idea
protocol.
It
might
be
including
idea,
protocols
yep.
According
to
the
text
in
the
shuttle
yep.
R
The
one
other
point
I
wanted
to
bring
up
is
how
quick
has
a
very
interesting
discussion
earlier
this
week
regarding
the
relationship
of
TLS
and
the
security
layering
to
the
quic
protocol,
unclear
exactly
how
all
of
that
is
going
to
land.
We
do
have
analysis
of
the
current
IETF
quick.
As
of
like
what
the
documents
say
today
in
this
document,
if
that's
in
flux,
I'm
not
sure
how
we
should
reflect
that
in
the
document.
J
L
B
Think
an
easy
way
to
deal
with
this
as
we
get
it
as
far
as
we
can,
and
then
we
let
the
document
rest
I,
don't
think.
There's
there's
huge
value
in
pushing
it
through
as
an
RFC
as
soon
as
possible.
I
just
want
only
get
the
work
done,
so
we
can
move
on
and
make
sure
that
the
API
stuff
incorporates
what
we
know
and
we
can
go
back
and
revise
it
later.
I
don't
see,
that's
great
also,.
J
I
think
the
stream
zero
problem
was
I,
don't
recall
correctly
what
the
text
was
or
what
was
said
in
the
meeting,
but
my
understanding
was
that
they
would
hope
to
have
this
kind
of
resolve.
Why
the
next
idea?
So
you
know,
maybe
the
two
are
aligned
in
this
textbook
on.
You
know
solidify
itself,
and
we
can
just
kind
of
stick
with
it,
whether
it
be
we
now
layer
on
top
of
G
to
us
or
we
stick
with
what
we're
doing
so.
T
S
J
J
B
B
U
U
So
this
was
the
first
one
was
addressing
the
comments
we
got
at
the
last
idea
and
with
a
few
emails
later,
for
instance,
one
comment
was
that
we
should
not
talk
about
falling
back
to
TCP
and
UDP,
but
we
got
them.
You
know
as
members
of
a
set.
So
this
is
just
in
you
know
a
text
change
really.
It
doesn't
talk
about
fallback
to
TCP
or
UDP
anymore.
It
says
implementation
over
it's
a
kind
of
intelligent
search
and
replace
operations
right
because
it's
not
exactly
everywhere.
Exactly
like
that,
but
doesn't
say,
falling
back
removed.
U
References
to
burst
burst
occurs.
They
were
in
there
that
did
say
that
post
office
requires
a
system
on
both
sides
to
function,
because
that
was
my
understanding
of
it
at
that
time,
and
the
replaced
flow
with
taps
connection,
which
again
is
on
the
next
slide,
changed
into
something
else.
But
I
was
for
this
update
and
frame
with
message.
U
So
there
is
no
more
the
tap
system
and
the
taps
connection.
This
is
now
really
replaced
with
transport
system
and
connection
I
think
the
document
doesn't
actually
use
any
new
terminology
anymore.
Now
just
refers
to
the
you
know:
the
uses
words
off
of
the
protocols
that
it
is
based
upon
and
section
three
and
four
finally
managed
to
relieve
merge
together
into
one
section
C,
and
then
there
were
a
few
editorial
knits,
and
that
was
it.
B
U
So
there
is
text
saying
that
there
is
some
text
in
the
appendix
deriving
things
related
to
security,
that
that
are
there,
you
know
in
the
protocols,
authentication
and
so
on.
Then
there
is
text
saying
that
in
the
min
set
that
is
being
proposed
here.
This
is
all
excluded,
because
there's
a
companion
document
talking
about
security
as
reference
is
that
so.
B
I,
don't
think
in
the
in
the
security
document.
There's
any
discussion
of
what
a
minimum
taps
implementation
needs
to
support.
Do
we
okay?
So
do
we
think
that
there
that
a
minimum
taps
implementation
must
secure
support
some
security
protocols
in
order
to
be
called
taps?
If
we're
going
to
say
that
if
we
believe
that
we
should
say
it
somewhere,
this
document
is
one
place
to
say
it
or
we
could
say
in
the
security
document,
then
and
then
put
a
statement
in
here.
Q
Brian
Trammell
meeting
the
mic
I
think
we
do
need
to
say
that
it's
an
implementation
requirement
given
sort
of
a
pattern
of
the
rest
of
the
documents.
We
were
kind
of
putting
security
on
the
side,
afterward
and
then
we're
gonna.
Tell
people
don't
put
security
on
the
side
like
we
did
in
these
documents,
but
the
most
logical.
So
the
so
draft
is
it
drop
water
drop
Holly
but
yeah.
So
Chris's
document
that
Chris
just
presented
seems
to
basically
be
eighty.
B
B
N
Just
to
clarify
Kyle
Rose,
just
to
clarify
you
can
imagine
I
just
want
to
know
what
what
is
what
the
thinking
here
is.
You
can
imagine
a
a
system
using
taps
that
has
sufficient
security
built
into
it
right
that
it
only
needs
a.
It
only
needs
a
way
to
get
packets
across
the
Internet.
Is
that
intended
to
be
supported
here
or
is
there
or
are
there
going
to
be
minimum
security,
quiet
requirements
on
every
transport
that
will
essentially
require
say
double
encryption
or
something
like
that?
I.
N
U
O
For
the
usage
document,
we
have
a
separate,
so
this
is
actually
not
a
question
towards
the
mean
set,
but
rather
security
draft
for
the
usage
documents.
We
have
a
separation
now
with
sorry
for
them,
we
have
a
separation
between
min
set
and
usage
document.
For
the
let's
say
non
security
features.
Do
we
need
the
same?
Separation
for
the
security
features
will
just
be
just
docked.
The
one
document
covering
both
yeah.
B
That
was
the
thing
that
I
was
trying
to
explore
and
what
I
got
from
the
people
who've
been
working
on.
The
other
document
was
that
that
one
document
could
cover
both
I,
don't
see
a
lot
of
value
in
having
two
documents,
I
mean.
If
it's
two
different
sets
of
people,
then
it
might
make
sense
but
I,
that's
my
that's
my
personal
opinion.
I
think
we
should
just
clarify.
R
Tommy
Polly
Apple,
yeah
I
think
looking
at
the
security
set.
What
we've
distilled
of
what
Chris
presented
is
I
think
a
lot
smaller
than
the
set
of
all
of
the
transport
features
that
were
analyzed.
It's
it's
already
more
minimal,
as
I
think
it
requires
fewer
stages
of
distillation.
Had
we
encountered
the
same
thing
with
the
transport
features
between
UDP,
TCP,
sctv,
etc,
and
they
had
all
come
together
more
neatly,
then
we
wouldn't
have
needed
all
the
documents.
S
U
S
Q
Wanted
to
go
back
to
the
previous.
The
conversation
to
reiterate,
I
think
that
one
of
the
reasons
we
did
the
sort
of
three
stage
documents
is
that
we
didn't
quite
know
what
the
process
was
going
to
be
for
making
these
decisions
when
we
started.
So
it's
like.
Let's
do
all
the
homework
and
one
of
the
things
that
has
come
out
of
this
process
is.
We
understand
how
to
do
the
process
now
great
and
we
understand
how
to
say:
okay.
Q
B
U
B
B
B
Well,
it
seems
like
that's
kind
of
an
important
call
for
working
group.
Adoption
well
yeah.
Well,
that's
why
we
needed
it
in
the
Charter.
Now
it's
in
the
Charter.
Now
we
can
adopt
it.
Okay,
let's
take
a
hum
so
hum
for
people
who
think
that
we
should
adopt
the
Security
document
in
this
working
group.
B
B
O
B
R
R
So
we
have
three
new
documents
that
have
been
published,
and
these
are
all
aimed
at
the
milestones
coming
after
min
set
and
coming
after
the
trans
persecutory
survey,
trying
to
synthesize
all
the
things
that
we've
learned
from
the
surveys
and
min
sets
etc
and
unify
the
approaches
to
how
we
go
on
from
there.
So
again,
as
we
said,
there
are
three
documents.
This
is
the
first
one,
it's
just
about
the
architecture
fairly
high-level,
aimed
at
introducing
everyone
to
these
concepts.
R
So,
to
recap
from
last
time,
there's
a
lot
of
discussion
about
what
are
we
going
to
do
about
what
was
milestone
3
at
that
point,
so
that
last
milestone
is
all
about.
How
do
we
define
mechanisms
to
allow
a
transport
system
to
be
actually
deployed
to
be
defined
to
be
used
by
applications?
And
as
of
last
time,
there
were
several
documents
which
were
all
in
this
area
describing
various
aspects
of
it.
So
we
had
the
meet
document,
which
described
the
whole
neat
system.
R
Happy
eyeballs
on
steroids,
we
had
the
other
taps,
happy
eyeballs
document
which
went
into
just
how
you're
racing
the
protocols,
especially
for
SCTP,
and
the
experience
done
there,
and
we
also
have
these
socket
intents
about
how
applications
can
specify
the
the
Preferences
and
types
of
properties
they
want
from
their
transport
to
end
up
selecting
the
correct,
transferring
the
correct
path.
So
these
are
all
very
related.
They
all
cover
different
parts
and
we
all
had
useful
things
to
bring
to
the
table.
So
how
do
we
reconcile
these
and
combine
the
efforts?
R
So
the
proposal-
and
this
was
taken
to
the
list
back
in
January
I-
think-
was
to
distill
the
work
from
these
into
three
new
drafts,
one
being
the
architecture
draft.
This
is
to
explain
the
whole
approach.
What
are
the
basic
concepts
I
think
of
the
audience
here,
as
essentially
the
IETF
community
and
coming
to
this
with
new
eyes.
Essentially,
what
are
we
trying
to
approach
here?
There
is
the
interface
or
API
document
which
explains
in
detail
how
the
applications
that
we'll
be
using
transport
services
actually
use
this
system.
R
What
is
the
abstract
non
language
specific
API
into
this,
and
so
the
audience
there
mainly
is
developers
who
want
to
write
apps
to
use
transport
level
services
and
then
there's
the
implementation
document,
which
I
think
covers
all
the
things
that
had
been
lacking
in
the
previous
descriptions,
to
explain
really
in
detail.
How
do
you
actually
implement
a
system
such
that
you
take
this
interface
and
you
apply
it
into?
R
You
know
real
code
that
is
actually
taking
the
protocols
and
looking
at
how
do
we
apply
these
various
interface
aspects
to
each
protocol
and
to
each
approach
as
we
are
doing
racing
of
protocols
etc.
So
that's
what
we
decided
to
do
so.
The
architecture
draft
mainly
has
two
parts
in
it.
It's
relatively
short
compared
to
the
others.
It
has
a
design
principle
section
which
covers
the
constraints
on
the
approach.
What
are
the
guidelines
we've
given
ourselves
when
working
on
this
to
make
sure
that
we're
coming
up
with
something
that
makes
sense?
R
That's
reasonable
and
also
future
proof,
and
this
is
based
on
the
surveys
that
have
been
previously
done.
It's
based
on
the
men
set
and
it
expresses
essentially
that
history
there
and
what
we're
trying
to
do
and
then
the
second
section
is
more
just
like
a
list,
laundry
list
of
concepts
and
terminology
that
define
the
framework
that
we're
working
in
that
define
concepts
that
hopefully
can
be
used
both
in
the
API
documents
and
the
interface
document
and
potentially
may
seep
into
implementations
as
a
development.
R
R
So
for
the
rest
of
this
I,
just
kind
of
wanted
to
go
over
what
our
principles
and
concepts
are.
So
we
can
all
have
an
introduction
to
them.
If
you
have
any
thoughts,
clarifying
questions
come
up
now.
If
we
have
general
discussion,
we
can
leave
that
to
the
end,
because
we're
going
to
do
three
presentations
here
of
the
whole
sweep.
R
R
R
The
goal
is
to
write
your
code
once
and
reuse
across
multiple
protocols
that
doesn't
necessarily
imply
anything
about.
Are
these
things
switching
out
underneath
me,
but
I
want
to
just
write
my
basic
code
for
how
I
use
my
transport
a
single
time,
and
maybe
it
automatically
switches
over
to
some
new
protocols,
maybe
I
recompile
with
new
options,
but
it's
the
same
code
and
this
common
set
must
at
least
include
the
minimal
set
defined
in
min
set.
So
that's
principle.
R
One
principle
two
is
that
we
do
need
to
provide
access
to
specialized
features
and
the
way
we
do
that
needs
to
be
carefully
done.
So,
if
you
have
a
non
generic
protocol
option,
it
does
need
to
have
need
to
have
some
way
to
be
set.
Otherwise
a
lot
of
applications
will
not
find
this
very
useful
if
they
can't
set
their
UDP
checksum
specific
option.
R
R
R
Certain
specific
features,
however,
like
I,
could
say:
I
need
security
on
this
I
need
to
make
sure
this
is
at
least
using
AES
blah
blah
blah.
Those
may
end
up
limiting
protocol
selection
because
there
are
important
ramifications
that
come
from
degrading.
Your
security
third
principle
is
just
talking
about
the
scope
for
the
API
and
implementations
going
forward,
so
the
API
must
include
at
least
min
set,
so
we
have
to
be
able
to
do
basic,
TCP
and
UDP
operations
here.
R
However,
not
all
implementations
must
implement
all
of
the
protocol
features,
so
you
could
imagine
there
could
be
some
IOT
devices
that
don't
want
to
actually
implement
TCP
or
TLS,
because
they're
really
lightweight,
but
the
API
that
they
provide.
If
we
want
to
be
common
everywhere,
should
still
Express.
Oh,
you
could
ask
for
TCP
and
it
would
just
not
give
it
to
you
and
they
would
fail.
The
API
should
also
hold
back
and
avoid
referencing
any
specific
protocols.
R
We
wanna
make
sure
it
remains
general
and
protocol
agnostic
going
forward
and
the
implementation
is
the
thing
that's
responsible
for
defining
the
mappings
of
the
API
on
to
specific
protocols
which
we
imagine
it
can
be
extended
over
time.
We
can
have
future
definitions
of
how
you
map
quick
version
100
into
this
API
and,
of
course,
there
are
no
new
protocols
being
defined
in
this
effort
collectively
and
there's
also
no
requirement
to
use
a
tap
system
on
both
sides.
R
R
Essentially
we
have
at
the
top
a
application
and
a
series
of
categories
of
API
is
that
it's
working
with
it
has
several
phases.
It
has
a
pre
establishment
phase
in
which
it
has
to
do
the
setup.
It
has
the
establishment
phase,
which
says:
I
want
to
actually
activate
this
object,
whether
it's
a
listener
or
a
connection.
It
can
do
data
transfer,
which
is
a
clearly
the
goal
of
a
lot
of
our
transport
networking.
R
It
can
terminate
things
and
then
there's
also
the
phase
of
receiving
events
from
the
transport
system
up
into
the
application,
so
that
essentially
defines
the
phases
of
the
API
level
down
below.
There
is
the
implementation
which
has
concepts
such
as
gathering
all
the
candidate
paths,
endpoints
racing
them
having
cache
state
in
involving
system
policy
in
this
whole
decision-making
process
and
building
a
protocol
stacks.
So
that's
kind
of
the
high-level
view
should
be
fairly
straightforward.
R
It
Maps
well
onto
things
that
we're
all
familiar
with
like
TCP
UDP
systems,
alright,
so
just
running
through
a
couple
of
the
concepts
here.
These
are
the
main
highlights
from
the
document.
First,
we
have
the
basic
objects
that
we
imagine
need
to
be
interacted
with.
First,
there
is
a
pre
connection.
This
is
a
interesting
term
that
was
come
up
in
our
various
debates
about
terminology.
It's
essentially
the
properties
and
parameters
that
can
be
specified
to
define
what
a
connection
or
a
listener
can
be.
R
It's
the
endpoints
and
properties
that
the
application
wants,
but
it
doesn't
actually
do
anything
on
its
own.
A
connection
is
the
name
that
we're
using
for
the
basic
object
that
can
be
created
from
those
properties
and
is
an
active
object
that
can
be
used
to
send
and
receive
messages
between
a
local
and
remote
endpoint,
and
this
is
we're
using
the
term
connection,
but
it
can
still,
of
course,
apply
to
things
like
UDP,
that
on
a
protocol,
level
are
connectionless,
but
this
represents
the
active
state
that
the
application
is
aware
of
to
send
receive
messages.
R
A
listener
is
the
passive
receiving
object
that
allows
you
to
receive
incoming
connections.
So
then
the
concepts
for
the
pre
establishment
phase
we've
already
mentioned
briefly.
There
are
local
and
remote
endpoints.
This
is
these
represent
the
things
that
I
can
define
my
identity
and
also
define
the
identity
of
the
things
I
can
talk
to.
There
are
path,
selection
properties,
which
is
a
whole
set
of
properties
that
define
which
paths
so
which
interfaces
which
addresses
etc.
R
The
application
wants
to
be
able
to
interact
with
there
our
protocol
selection
properties,
and
these
are
the
properties
of
what
services
I
need
my
transport
to
offer
such
that
we
can
select
the
correct
transfer
protocol
for
you.
And
finally,
there
are
the
protocol,
specific
properties
which
are
the
ones
I
mentioned
earlier,
saying,
oh
and
if
you
use
protocol
X,
make
sure
you
configure
in
this
way,
because
I
know
my
server
only
is
expecting
that
particular
bit.
These
do
not
alter
the
protocol
selection
so
doing
the
establishment
phase.
Pretty
simple.
R
We
do
imagine
that,
as
we
are
expanding
this,
we
are
going
to
include
a
couple
more
actions
for
things
that
are
doing
multicast
and
other
styles
of
connections,
but
we're
starting
with
the
limited
set
that
everyone
could
agree
on
for
movie
concepts
for
data
transfer,
of
course,
their
send
and
receive
basic
concepts.
The
broader
one
over
that
is
that
we
are
communicating
in
sending
and
receiving
messages.
R
Messages
are
units
of
data
that
can
be
sent
to
receive
and
they
are
in
order
to
themselves
the
boundaries
may
or
may
not
be
understood
by
the
underlying
protocols,
but
having
this
concept
is
very
important
to
decorate
the
messages.
So
we
can
essentially
say
here
are
the
properties
of
this
particular
piece
of
data
such
that
when
we
have
protocols
like
setp
or
quic,
that
may
have
a
more
ability
to
do
interesting
things
with
those
pieces
of
data
we're
able
to
take
advantage
of
those,
but
it
does
still
map
well
into
a
system.
R
As
far
as
events,
we
have
things
like
connection
becoming
ready,
which
means
that's
essentially
it's
connected.
You
can
read
and
write
on
it.
Now
things
like
it's
failed.
It's
now
a
the
connection
has
ended.
You
can
have
events
that
your
message
has
been
sent
and
a
message
has
been
received
and
these
can
deliver
errors
or
deliver
the
actual
data
that
you've
received
and
then
their
events,
like
paths,
properties
change
to
let
the
application
know
if
it
needs
to
that
some
properties
of
the
system
that's
working
on,
have
modified
underneath
it.
R
This
is
especially
relevant
if
you
have
something
in
which
I
need
to
change
the
quality
of
the
streaming
I'm
doing,
because
I'm
now
on
a
different
interface
than
it
was
before.
Sometimes
the
applications
will
need
to
be
involved
in
this,
and,
finally,
we
have
concepts
for
terminating
connections
you
can
close,
which
is
the
generic
graceful
teardown
of
a
connection,
and
it
may
involve
communicating
to
the
remote
end
point
that
we
are
done
with
this.
R
It
may
not,
and
we
also
believe
that
it
is
important
to
have
the
concept
of
an
abort
which
is
more
immediate
teardown
and
involves
not
sending
any
outstanding
data.
It's
get
rid
of
this
quickly,
so
that
covers
the
API
concepts
as
far
as
the
implementation
concepts
we
are
defining
here,
the
steps
of
candidate
gathering,
which
is
all
about
filtering
out
the
protocols
and
paths
and
endpoints
that
are
allowed
based
on
the
application
preferences
and
the
system
policy,
and
this
is
elaborated
much
more
in
detail
in
the
implementation
draft.
R
We
have
steps
of
candidate
racing,
which
means
that,
fundamentally,
when
we're
bringing
up
connections,
they
are
happy
eyeballs
based.
They
are
flexible
in
what
they're
trying
they're
trying
multiple
things.
We
also
have
the
concept
of
connection
groups.
This
is
for
things
that
are
being
multiplexed,
whether
it's
SCTP
streams,
quick
streams,
hb2,
etc.
These
are
connections
that
have
similar
properties
and
allow
the
underlying
tap
system
to
turn
them
into
multiplex
connections,
and
that's
essentially
it
that
covers
the
architecture.
Q
Q
Does
it
essentially
take
the
architecture
that
we
worked
out
in
that
document
and
the
principles,
the
architectural
principles
from
that
document
and
to
sort
of
project
them
into
an
abstract
interface
that
you
could
actually
implement
in
any
given
language
in
order
to
meet
the
transport
services
architecture?
So
we
had
some
design
principles.
These
are
derived
from,
but
functionally
separate
from
the
design
principles
from
the
architecture.
Q
We
want
to
do
sort
of
everything
that
people
do
with
networks
for
naval
applications
written
to
the
single
API,
to
make
use
of
multiple
transport
protocols
in
terms
of
features,
providing
one
explicit
support
for
security
properties,
I'm
sort
of
we're
catching
up
with
the
security
document
and
saying
security
is
actually
a
whether
you
turn
it
on
and
off
its
part
turn
it
on
or
not.
It's
part
of
the
transport
layer
for
asynchronous
connection
transmission
and
reception.
Q
The
requirement
for
a
synchronicity
comes
from
the
fact
that
you
actually
do
a
lot
of
the
cool
stuff
in
terms
of
connection
racing
or
a
path
property
pass
election.
Any
of
the
things
that
you
want
to
do
in
order
to
make
taps
work
doesn't
really
work.
If
you're
doing
it
single
threaded
in
terms
of
first
I'm
going
to
go,
do
a
get
a
tour
info
and
then
I'm
going
to
go,
do
a
socket
and
then
I'm
going
to
go.
Do
a
connect,
support
for
multi
streaming
and
multi
path,
transport
protocols.
Q
So
we
put
this
in
here
because
it
actually
wasn't
quite
yet
captured
in
the
architecture.
But
a
lot
of
the
interesting
developments
in
the
transport
layer
right
now
are
in
this
space
in
sort
of,
like
you
know
so,
quick
and
be
quick
and
P
TCP
an
atomic
transmission
of
data.
This
is
also
interesting
for
being
able
to
take
a
chunk
of
something
that
you
want
to
send
over
a
transport
and
say
all
of
these
bytes
somehow
belong
together.
Please
make
sure
they
get
there.
Q
On
the
other
side,
this
is
necessary
when
you're
building
applications
on
top
of
these
multi
streaming
and
multipath
transport
protocols.
There
was
a
lot
of
discussion
in
on
previous
taps
meetings
about
how
exactly
this
works,
and
we
think
we
have
a
way
to
make
it
work
we'll
talk
about
that
in
a
moment.
So
when
we
take
that
in
the
architecture
diagram
and
and
push
it
through
those
principles,
we
end
up
in
the
interface
diagram
that
looks
like
this.
Q
So
these
up
here
are
the
phases,
and
then
we
have
sort
of
the
pre
establishment
involves
sort
of
figuring
out
what
the
properties
are.
The
endpoints
you're
going
to
connect
to
and
resolving
those
taking
the
parameters
for,
selecting
a
connection
binding
that
to
a
pre
connection
and
then
taking
that
pre
connection
in
turning
into
a
connection.
So
in
points
and
here
I
have
actually
references
to
the
document
for
those
of
you
who
haven't
read
it
yet,
you
can
actually
just
go
through
this
presentation.
Q
You
don't
really
have
to
read
the
document
and
when
you
do
read
the
document,
you
want
to
check
to
see
where
I
got
things
wrong.
In
my
slides,
that's
the
that's
the
the
section
reference.
So
we
want
to
be
able
to
specify
a
remote
local
endpoints
at
a
variety
of
resolutions.
You
might
actually
have
application
logic
that
says
you
need
to
connect
to
this
IP
address.
Q
You
generally
will
be
doing
things
in
terms
of
their
main
names,
but
in
sort
of
in
other
environments,
you
have
other
ways
to
specify
things
right.
There
here
is
under
control
of
the
transport
services
system,
not
application
control.
So
this
is
a
departure
from
bsd
sockets
in
it
now,
there's
sort
of
a
a
explicit
phase
for
resolution.
Get
outer
info
followed
by
an
explicit
phase
for
doing
something
with
this
drug
sock
adder,
and
we
don't
want
to
do
that
anymore,
because
you
can't
do
a
lot
of
the
cool
stuff
we
want
to
do
in
taps.
Q
If
that's
your
pattern,
this
is
bound
to
the
pre
connection,
because
the
pre
connection
has
properties
that
may
do
some
pre
path,
selection
right.
So,
for
example,
if
you're
doing
resolution
with
the
dns,
the
answer
you
get
depends
on
the
resolver
and
the
source
address
that
you
present
it.
So
you
need
to
actually
do
multiple
resolutions,
depending
on
the
selected
protocol
stack
depending
on
the
provisioning
domain,
depending
on
other
properties
that
interface.
There
is
an
open
issue
that
we
need
to
address
here.
Q
When
you
put
this
under
the
control
of
the
transport
services
stack,
some
applications
may
actually
want
control
of
when
the
resolution
happens,
because
DNS
queries
can
leak
interest
about
some
things
and
you
might
not.
You
might
actually
want
to
say:
okay
well,
I
want
to
check
over
here
first,
and
only
if
that
fails,
I
want
to
check
over
there
because
I'm
less
I
trust
this
network
more.
We
don't
have
a
an
answer
for
that,
yet
we
have
a
space
of
answers,
but
we
need
to
sort
of
pick
one.
Q
Yes,
of
course,
otherwise
we
can
just
go
home,
so
crackers
parameters,
section
5
here
we
have
sort
of
properties
that
you
can
use
to
select
both
protocol
stacks
and
paths,
and
these
are
essentially
used
to
select
or
prefer
or
eliminate
candidates,
while
you're
trying
to
do
connection
establishment.
Oh
these
are
the
old,
slides,
ok,
good,
they're,
mostly
correct.
These
properties
are
partially
there's
a
missing
partially
right
there
for
michael
derive
from
min
set.
Q
You
know
whether
or
not
the
protocol
stack
provides
reliable
data
transfer
preservation
of
ordering,
whether
or
not
it
provides
the
ability
to
select
reliability
on
a
per
message
basis,
like
PR
SCP,
whether
it
provides
your
RPGs
such
an
establishment,
multiplexing
or
multi-streaming,
whether
you
can
get
retransmission
and
ICMP
notification,
as
in
SCTP
control
over
the
checksum
coverage
for
doing
partial,
checksumming
or
checksum
disabling
for
UDP
and
UDP
light
a
capacity
profile
which
we
can
talk
about
in
the
discussion
and
then
sort
of
paths.
Only
interface
type,
information.
Q
There's
only
one
like
I
can
I
can
actually
give
you
URL
to
throw
up
because
basically
I'd
just
say
hey,
we
have
issues,
please
go
to
get
up
and
I'll
tell
you
that
when
we
get
there,
so
the
we
have
these
four
column
pass
election
properties
separate
from
that
our
protocol
properties.
If
you
have
suggestions
on
the
terminology,
we
are
very
open
to
them.
These
are
protocol
properties.
Allow
us
to
configure
in
query
information
about
a
running
protocol
stack
after
it
has
been
selected
in
a
transport
independent
way.
Q
Q
We
have
the
transmission
scheduler
for
the
group,
we'll
talk
about
groups
in
a
second,
the
connection
aboard
timeout
notification
thresholds,
checksum
coverage,
minimum
and
maximum
sizes
for
how
we
deal
with
with
framing
the
idea
here
is
to
have
for
the
min
set
a
set
of
protocol
properties,
which
we
don't
need
to
know
anything
about
the
transport
protocol
to
set
the
architectures
requirement
to
be
able
to
reach
down
into
the
protocol
when
you
really
really
need
to
is
provided
by
sort
of
specific
protocol
properties-
and
these
are
essentially
names
based
by
the
protocol.
Q
S
Q
S
Q
B
N
Q
Q
So
here
here
right
now,
we
haven't
actually
said
must,
should
we
haven't
put
normative
language
on
these?
We
need
to
do
that
in
a
future
revision.
I
think
what
we're
asking
today
is.
Is
this
the
correct
approach?
Not
is
this
the
correct
list
of
things
I
mean
we
need
to?
We
need
to
go
on
the
details
of
that,
and
we
need
to
actually
back
that
up
with
stuff
in
the
implementation
document
that
these
are
zeros
your
arrest.
So.
B
Q
As
you
see,
we
have
a
we
may
need
to
revisit
the
organization,
the
document,
because
I
just
jump
from
section
five,
two
to
section
nine,
one
back
to
section
five
three,
so
this
is
what's
in
the
security
parameter
section
of
the
document
right
now.
Actually,
looking
at
Chris's
present
station
this
morning,
the
security
parameter
section
does
need
to
be
updated
to
follow
the
minimal
set
that
comes
out
of
that
document.
But
here
we
have
again
generic
security
properties
that
allow
you
to
it's
exactly
the
same
thing
right
like
so.
You
have
a
transport.
Q
And
then
you
can
configure
in
query
security
features
in
a
protocol
independent
way,
this
identity,
private
key,
the
group's
algorithm,
cipher
suites.
You
want
to
use
on
configuration
the
session
cache,
pushing
pre-shared
keys
into
a
session
and
then
callbacks
for
trust,
verification,
identity,
challenges
right.
So
these
are
standard
things
that
are
partially
derived
from
that
work,
but
we
need
to
sync
it
up.
There
are
a
few
more
things
that
need
to
go
in
here.
Q
What
yeah,
for
example?
So
now
you
know,
following
the
the
structure
of
the
architecture
document,
we
go
through
the
different
parts
of
sort
of
usage
of
this
API
in
terms
of
their
phase
great
so
phase
the
pre
connection
phase,
the
pre
establishment
phase
is
all
involving
a
pre
connection,
so
this
takes
some
endpoints
and
some
parameters,
and
one
of
the
purposes
of
giving
this
to
a
pre
connection
is
so
that
the
system
can
prepare
cache
information,
pull
information
out
of
the
cache
before
it
actually
does
the
the
establishment
right.
Q
So
this
allows
the
system
sort
of,
in
the
background,
to
start
preparing
for
the
fact
that
you're
going
to
ask
for
connection
on
this.
You
can
also
group
connections
for
establishment,
we'll
get
into
that
in
a
second
and
recognizing
that
this
can
get
a
little
bit
clunky.
You
know
for
many
applications
you
might
want
to.
Let
them
just
say:
hey
I.
Have
some
parameters,
give
me
one
connection
I'm
only
ever
going
to
need
one
connection
there.
Q
We
can
have
sort
of
convenience,
calls
in
the
implementation
of
the
API
that
says:
ok,
I'm,
going
to
pre
connect,
then
I'm
going
to
connect
at
the
same
time,
because
one
of
the
one
of
the
goals
here
is
that
we
want
an
API
that
doesn't
look.
You
know
much
more
Byzantine
than
what
people
are
used
to
right
now.
So
once
you
have
a
pre
connection,
you
can
establish
it.
There
are
three
ways
to
do
this
sort
of
active
passive
and
either
active,
North,
passive
or
both
active
and
passive.
Q
At
the
same
time-
and
each
of
these
has
and
of
associated
with
it
when
this,
when
the
connection
is
done
so
if
I
want
to
initiate,
then
I
get
a
ready
event.
If
I
do
a
listen,
then
the
pre
connection
becomes
a
listener
and
I
get
a
bunch
of
connection
received
events
and
if
I'm
doing
a
rendezvous,
then
basically
there's
additional
information
about
how
that
relay
is
going
to
happen.
Q
If
there's
now
traversal
it
needs
to
happen,
and
then
once
that
channel
is
established,
you
get
a
rendezvous
done
event
event
these
once
these
are
created
before
these
events
fire.
These
are
still
real
actual
connections,
and
you
can
do
everything
that
you
want
to
do
with
a
connection
with
these
connections.
You
won't
receive
any
data
on
them
because
there's
no
way
for
the
data
to
get
to
you,
but
you
can
start
throwing
stuff
into
the
buffer
and
you
can
start
in
queueing
receive
requests.
The
details
of
zero
RTT
are
still
an
open
issue.
Q
Q
The
way
that
we
represent
multi
streaming
protocols
in
an
environment
where
you
may
or
may
not
have
access
to
a
multi
streaming
protocol
is
with
a
connection
group.
This
is
a
neat
concept
that
we've
kind
of
slammed
some
post
sockets
into.
So
we
have
a
sort
of
a
unified
way
of
dealing
with
this.
But
it's
it's
inspired
by
the
neat
approach.
Q
You
can
take
connections
and
you
can
entangle
them
into
groups
once
a
connection
group,
but
connection
is
entangled
into
a
group
all
of
the
protocol
properties
of
that
connection
move
together.
That
represents
the
fact
that
these
on
logical
connections
may
just
be
streams
in
a
multi
streaming
transport
protocol.
They
may
have
one
sort
of
like
lower
layer
connection
among
all
the
connections
in
the
group,
or
they
may
be
implemented
as
multiple
flows.
Q
If
you
don't
have
a
multi
streaming
protocol
available
to
you,
the
way
that
you
create
a
entangled
connection,
so
the
group
itself
is
not
created
explicitly
it's
created
in
implicitly
by
creating
new
pre
connections
that
are
cloned
from
existing
pre
connections.
So
you
can
take
a
pre
connection
and
you
clone
it
every
initiation
you
do
off.
Of
that
pre
off
of
the
entangled
set
of
pre
connections
will
be
part
of
the
same
group.
Q
You
can
take
an
existing
connection
and
you
can
clone
it
on
the
other
side,
if
there
is
a
if
the
underlying
multi-streaming
transport
protocol
supports
notification,
that
a
new
stream
is
available
on
that
shows
up
as
a
connection
received
event.
So
as
far
as
the
application
on
the
listener
side
is
concerned,
it's
just
a
new
connection
that
popped
up.
There
are
details
and
how
you
would
handle
this
when
you
have
a
single
stream
initiated
by
the
initiator
in
a
client-server
architecture.
Q
Where,
then,
the
server
would
initiate
new
streams,
that's
an
open
issue
and
we
need
to
handle
that
as
well.
Sending
data
pretty
easy,
there's
a
thing
called
connection
dot
send
not
super
exotic,
various
sender
side
framing.
So,
if
you're
in
an
in
a
environment
that
basically
allows
you
to
deal
with
arbitrary
application,
a
sort
of
data
types,
you
can
hand
that
data
type
in
to
send,
as
opposed
to
doing
the
serialization
inside
the
application
and
take
the
serialization
and
move
it
down
into
the
API.
Q
So
you
have
a
the
ability,
the
application
has
the
ability
to
say.
Please
frame
my
data
like
this.
This
is
kind
of
a
convenience
function,
but
it
could
be
used,
for
example,
to
frame
data
differently
in
case
different
protocols
are
used
because
there
is
a
requirement
for
different,
framing
and
different
protocols
on
the
on
the
other
side
from
the
server.
Q
Person
behavior
can
be
controlled
by
license
and
parameters.
So
again
we
have
lifetime
how
long,
if
I'm,
partially
reliable,
how
long
should
I
wait
until
I
give
up
on
this
niceness
is
again
inverse
priority,
whether
or
not
it
needs
to
be
ordered
with
respect
to
the
last
send
on
the
same
connection,
a
well.
Q
Potent
and
can
be
used
for
zero,
RTT
and
then
checksum
coverage,
immediate
acknowledgement
and
then
sort
of
this
instantaneous
capacity
profile,
which
we'll
talk
about
in
the
discussion
later
pretty
much
any
time.
You
do
a
thing
with
this
API
at
my
yield
and
event
here
that
would
be
sent
a
as
far
as
I
know.
This
made
it
to
the
other
side
depending
on
what
the
fee,
the
underlying
protocol
can
give
you
as
far
as
how
much
send
information
about
how
far
it
got
sent.
Q
Usually
this
is,
it
got
put
down
to
the
kernel,
so
it's
it's
not
TCP
X,
no!
Actually!
So,
if
we,
if
we,
if
we
have
TCP
ACK
notification
or
a
a
protocol
that
gives
us
that
notification,
we
probably
want
a
another
event
here
for
delivered,
but
that's
not
there
yet
discussion,
gory
or
not
right.
So
this.
These
are
all
you.
You
can
see
that
there's
a
common
theme
if
there
are
open
issues.
This
is
your
zero
document
we
have
along
the
author
group.
Q
We
have
a
pretty
good
agreement
that
this
is
the
right
approach
for
this.
We
want
feedback
on
whether
or
not
we're
barking
completely
up
the
wrong
tree,
but
like
all
of
the
little
details
we
want
to
do
under
working
group
change,
control
receiving
amazingly
this
is
called
actually
connection
not
receive.
So
the
application
essentially
registers
that
it
is
ready
to
receive
data
by
calling
receive,
and
then
it
gets
a
receive
event.
This
is
a
way
to
allow
sort
of
application
pushback
to
you
know
for
essentially
flow
control.
Q
This
message
is
going
to
contain
an
octet
array
as
well
as
some
reference
to
some
transport
metadata.
So
if
the
underlying
stack
gives
you
the
ability,
for
example,
to
see
the
ecn
status
of
this
packet,
you
could
actually
get
that
out
of
the
metadata.
How
about
how
we
generalize
and
make
specific
that
metadata
is
an
open
issue.
Okay,
thank
you
very
much.
Q
The
there's
a
detail
here
on
that.
We
actually
worked
quite
hard
on
in
that
this
API
gives
you
atomic
reads
when
the
underlying
transport
protocol
gives
you
message
framing
and
boundary
preservation
like
SCTP,
then
that
atomic
read
information
comes
down
from
it.
You
do
you
do
a
send
on
one
side.
It
gets
put
into
a
frame
thing
on
the
transport
protocol
out
of
the
transport
protocol
framed
ud
frame
it
and
everything
is
fine
when
you're
running
over
something
like
TCP
yep.
Q
What
are
you
running
over
something
like
TCP?
You
need
to
have
some
knowledge
of
the
application
protocol
running
underneath
it
in
order
to
D
fraim.
It
turns
out
almost
every
application
protocol
that
runs
over
TCP
has
its
own
framing
mechanism
because
it
needs
it
right.
This
is
a
an
indication
that
this
is
actually
a
missing
transport
protocol
or
missing
transport
layer.
Feature
that
we're
adding
back
here.
So
just
like
the
cinder
side,
framing
the
cinder
site,
D
framing
allows
you
to
push
that
down.
Closing
you
can
close
connections.
You
can
also
report
them.
Q
B
I
O
V
Hello,
everyone
so
I'm,
Ana,
bernstrom
and
I'm
here
to
present
the
third
document
in
this
document
suit,
implementing
interfaces
for
transport
services
and,
as
already
introduced
by
the
previous
two
speakers.
This
document
complements
architecture
and
the
API
draft,
so
it
provides
guidelines
on
how
you
can
implement
this
type
of
tap
system.
V
So
the
first
part
is
the
application.
The
implementation
needs
to
support
the
basic
objects
that
are
defined
in
architecture,
so
the
pre
connection
is
implemented
as
a
bundle
of
the
different
properties
and
the
objects
that
it
contains.
An
important
part
for
the
implementation
is
that
when
this
pre
connection
is
turned
into
a
connection
or
a
listener,
these
paths,
selection
and
protocol
selection
properties
becomes
immutable.
So
the
implementation
needs
to
ensure
that
they
do
not
change
after
this
point.
V
So
moving
on
to
the
first
phase,
the
pre
establishment.
So,
as
you
already
heard
in
this
phase,
the
application
provides
its
endpoints
and
it
can
give
the
preferences
regarding
the
the
protocol
and
the
paths
that
it
prefers
to
use.
So
the
implementation
then
stores
these
objects
and
properties
as
part
of
its
pre
connection
object,
and
you
also
have
a
lot
of
these
port
protocol
and
path,
selection
properties,
so
for
the
ones
that
are
not
specified
by
the
application.
The
implementation
needs
to
use
the
default
values
that
is
part
of
the
API.
V
One
part
for
the
implementation
is
also
that
during
this
pree
establishment
face,
you
can
also
do
early
failure
detection.
So
if
the
application
gives
you
path
or
protocol
selection
properties
that
you
cannot
support,
because
you
know
as
an
implementation,
what
protocols
you
have
and
if
they
are
not
supported
than
providing
an
early
failure,
notification
can
be
beneficial
here,
because
then
you
can
save
resources
and
similarly,
if
you
request
properties
that
are
not
compatible
with
each
other,
that
implementation
can
generate
an
error.
V
So
an
important
part
in
the
pre
establishment
is
that
you
get
all
these
properties
and
preferences
from
their
application
and
the
implementation
needs
to
take
these
together
with
other
inputs.
So
you
have
some
dynamic
system
policy
where
you
as
an
implementation,
can
gather
information
from
previous
connections
or
you
can
gather
information
from
other
sources
external
to
you,
and
you
may
also
have
some
default
implementation
policies.
V
So
a
key
thing
for
the
implementation,
and
one
of
the
main
benefits
of
having
the
tap
system
is
that
we
dynamically
can
make
these
decisions
to
give
an
optimal
transport
performance.
So
any
of
the
in
the
implementation.
You
also
have
to
ensure
that
the
constraints
that
are
given
by
any
of
these
input
parameters
all
have
to
be
satisfied.
So
you
cannot
select
the
protocol
that
doesn't
follow
the
requirements
from
the
application
or
that
violates
your
system
policy,
for
instance,
so
for
implementing
the
connection
establishment,
as
you
already
saw
in
the
architecture
overview.
V
There
are
two
main
steps
to
this
part,
so
it's
the
candidate
gathering
where
you
identified
on
which
possible
paths
and
protocols
an
endpoint
can
you
use-
and
this
is
also
where
you
use
this
system
policy
component
in
that
step.
And
then
you
have
the
racing
of
these
components
when
you
try
them
out
and
see
which
ones
you
can
actually
establish,
and
you
provide
them
one
of
them
back
to
the
application.
V
So
this
is
quite
a
large
part
of
the
description
of
the
current
implementation,
tation
draft-
and
this
comes
a
lot
from
Thomas
draft
on
that
topic.
That
was
also
presented
in
the
previous
meeting
that
we
had,
but
for
the
candidate
gathering,
you
can
describe
the
candidates
by
the
in
a
compact
notation
by
the
the
endpoint,
the
path
and
the
protocol,
and
you
can
done
also
structure
this
available
candidates
as
a
three
as
a
tree.
So
if
you
have
a
in
this
case,
you
have
the
endpoint
and
you
have
any
path
available.
V
You
can
then
split
that
up,
depending
on
which
which
path
you
selects.
For
instance,
you
have
Wi-Fi
and
you
have
LTE
and
then
you
may
also
have
for
Wi-Fi
use.
One
end
point
ipv4
address,
but
you
may
have
for
the
other
LT.
You
may
have
both
ipv4
and
ipv6
endpoints,
so
you
can
structure
all
your
choices
as
the
tree,
and
this
is
kind
of
how
you
can
represent
and
have
all
the
the
candidates
that
are
possible
to
use
and
when
you
construct
this
tree,
the
order
in
which
your
branch
is
quite
important.
V
So
Brian
was
already
talking
about
this-
that
it's
important,
that
you
do
the
DNS
resolution,
for
instance,
on
the
right
path
so
that
you
don't
get
candidates
here
that
or
doesn't
make
sense
you
use
actually
and
sorry,
and
also
his
you
also
don
need
to
sort
the
branches.
So
this
is
kind
of
how
you
give
the
preferences
for
the
different
protocols
and
the
different
paths-
and
this
is
again
BAM
based
on
your
own
on
your
system
policy.
V
P
So
I
am
trying
to
understand
if
the
previous
slide
and
this
slide
occur
in
two
different
like
time
phases
or
not
because
like
it
seems
to
me,
like
you,
can't
tell
that
LTE
one
nine
two
zero
two
one
is
like.
You
can't
tell
that
and
without
doing
a
blocking
operation.
That's
oh
I'm,
trying
to
understand.
If
you
first
gather
and
then
you
all,
you
have
to
do
a
DNS
lookup
right,
so
you
I,
if
you
gather
so.
V
H
V
Time:
okay,
yes,
then
we
have
the
candidate
racing
and
you
can
do
it
in
in
different
ways
depending
on.
If
you
want
to
have
a
delay
between
the
candidates,
you
want
to
wait
until
a
failover
happens
and
the
racing
completes
once
you
have
one
candidate
that
succeeds
or
if
all
of
them
fail
and
one
aspect
here,
of
course,
when
you
have
a
tap
system,
is
that
the
success
here
is
different
depending
on
what
protocol
you
use.
So
if
you
have
TCP,
for
instance,
it's
quite
natural
to
think
that
you
succeed
once
your
handshake
succeeds.
V
If
you
have
UDP,
there
is
no
handshake.
So
as
soon
as
you
have
a
route
to
the
endpoint,
you
can
say
that
you
succeed.
The
multiplex
connections
are
a
bit
special
here,
because
here
you
may
already
have
a
connection
set
up
and
you
just
use
a
new
stream
of
that
connection,
so
you
actually
can
succeed
immediately,
and
this
also
has
some
implications
on
what
happens
at
the
other
side,
because
you
may
have
a
reliable
taps
connection,
but
you
actually
don't
yet
any
connection
received
event
on
the
other
side
generated
by
the
establishment
it.
H
V
So
that
was
the
active
part
of
opening
air
connections.
We
also
have
the
listening
side,
so
here
dope
implementation
then
needs
to
register
the
listener
object
and,
depending
on
what
path
and
protocol
preferences
has
been
specified,
you
may
be
listening
over
multiple
paths.
You
may
be
listening
for
multiple
protocols
and
you
can
actually
get
different
protocol
stacks
back
as
an
application,
depending
on
what
happens
underneath
in
the
tap
system.
V
Data
transfer,
I
think
you
Brian
already
talked
quite
a
bit
about
this-
that,
depending
on
what
protocol
you
have
sending
or
the
message
is
different,
if
you
have
a
protocol
that
has
a
natural
message
framing
and
a
message
just
gets
mapped
to
that.
If
you
have
TCP
done
depending
on,
if
you
have
a
framer
or
you
will
send
a
sequence
or
byte
bytes,
there
is
some
discussion
about
how
to
support
all
the
different
sand
parameters
again.
What
that
means
what
these
sand
crater
parameters
means
depends
on
the
underlying
protocol.
You
have
in
some
of
them.
V
You
may
not
have
support
for
it
and
in
others,
you
can
do
something
useful
with
them.
0Tt
data
is
an
important
case.
Brian
already
talked
about
that
as
well
from
an
implementation
standpoint.
This
is
something
that
you
have
to
integrate
with
the
racing,
so
you
have
to
have
the
the
data
provided
by
the
application,
and
then
you
have
to
provide
it
into
each
of
the
the
candidates
when
you
race
it,
so
that
you
can
include
it
for
the
protocols
where
it
makes
sense
on
the
receiving
side.
V
Again,
Brian
talked
quite
a
bit
about
that
part
as
well,
and
it's
also
dependent
on
the
protocol
that
you
have.
So
if
you
have
a
TCP,
you
may
not
have
the
the
framing,
depending
on
what
has
been
passed
down
by
the
application,
and
you
also
have
some
hints
there
that
the
application
provides
to
you
so
that
you
know
how
to
deal
with
the
incoming
incoming
data.
V
The
important
part
there
from
the
implementation
standpoints,
perhaps,
is
that
you
don't
have
any
half
close
connection,
so
the
protocols
that
support
that
does
not
get
propagated
up
to
the
application.
Again,
when
you
have
the
multi-streaming
protocols
and
you
multiplex
several
taps
connections
onto
the
same
underlying
transport
connection,
you
also
get
some
special
behavior,
because
here
closing
a
connection
is
just
closing
a
stream
and,
depending
on
the
underlying
protocol,
you
may
not
then
get
the
finished
event
on
the
other
side.
V
R
A
clarifying
comment
on
that
Tommy
I
think
the
point
here
is
that
a
close
in
this
is
being
interpreted
as
a
termination
of
the
full
connection,
we're
still
discussing
half-closed
being
able
to
be
sent,
but
I
believe
that
would
be
more
property
of
the
sending
of
a
message
and
saying
that
now
this
message
is
the
end
of
the
underlying
connection.
Please
send
a
fin
with
it.
That's
a
sending
parameter,
not
a
termination
parameter.
V
There
is
some
more
discussion
on
cache
State
in
relation
to
the
system
policy,
so
you
may
have
state
cache
both
by
the
protocols,
so,
for
instance,
when
you
perform
happy
eyeball,
you
may
learn
about
what
protocols
work
and
not
and
you
my
cache
information
for
TFO
and
things
like
that.
You
can
also
have
the
performance
caches,
which
is
knowledge
about
your
different
paths,
round-trip
times
available,
bandwidth
and
so
on,
and
this
information
may
also
come
from
external
sources.
V
There
is
a
section
in
the
graph
discussing
also
protocol
specific
considerations
or
how
these
actions
map
to
the
different
protocols
and
some
specifics
to
think
about-
and
this
is
the
list
of
the
protocols
that
are
currently
discussed
as
column
was
already
commented.
We
have
the
round
of
an
environment
discovery.
This
is
currently
a
separate
section
that
needs
to
be
integrated
with
integrated
with
the
rest
of
the
document
and
I.
Think.
V
There's
also
quite
a
bit
of
information
missing
there
in
general
I
think
we
started
from
the
architecture,
so
this
was
the
first
thing
we
did
nailed
down
to
get
the
agreement
there,
and
then
we
have
the
API
and
then
we
started
also
to
have
the
implementation
to
see
that
things
match,
but
there
are
still,
of
course,
a
lot
of
open
issues.
Also
in
in
this
draft.
B
So
let
me
start
by
just
taking
a
home
of
the
room,
those
people
who
are
comfortable
making
these
documents
they're.
Here's
your
documents,
obviously
not
done,
but
making
them
taps
working
group
documents
today,
I'm
going
to
ask
whether
you
are
in
favor
of
it,
whether
you're
opposed
to
it
or
whether
you
need
more
information.
So,
let's
say
who's
in
favor
of
adopting
these
documents
today,.
B
A
N
Like
there's
an
intent
for
rendezvous
to
be
very
general
and
I,
think
that
we're
gonna
want
that
because
it's
not
just
ENS,
not
even
just
multicast
DNS,
but
you
can
imagine
service
discovery
via
a
database
where
you
have
say
stable
names
for
a
service
that
might
move
around
between
IPS
or
between
data
centers.
So
I
don't
want
to
belabor
the
point,
but
we.
L
Jackson
two
comments
regarding
the
center
motive.
One
is
you
had
some
time
to
live
for
partial
reliability
of
their
other
notions
of
partial
mobility,
so
make
sure
you
can
cover
that
and
the
other
one
is
you
had
atomic
sense
so
I
agree.
There
is
a
need
to
provide
an
ascend
call
information
where
message
begins
and
where
message
stops
it's,
but
it
could
be
limiting.
If
you
say
you
do
it
with
atomic
sense,
which
limits
you
to
say
which
limits
the
size
of
the
messages
you
can
send
to
the
size
you
can
buffer
inside
your
stack.
Q
I
only
had
20
minutes
so
I
didn't
read
the
whole
document.
There
is
a
notion
of
a
partial
send
and
a
partial
receive
so
if,
for
example,
the
if
you're
receiving
something
and
the
transport
layer
framing
or
the
underlying
application
layer,
D
framer
basically
says
I
cannot
find
the
end
of
frame
before
your
maximum
buffer
size
you'll
get
back.
Essentially
a
an
atomic
receive
Orono
a
partial
receive.
So
it's
a
yeah.
Here's.
The
here
are
some
bytes
from
this
message
and
they
start
at
this
offset
and.
Q
L
R
It
is
the
same
thing
for
the
send,
so
one
of
the
discussions
that
we
had
early
on
and
if
people
have
feedback
on
the
naming
here
to
be
good.
Initially,
when
we
were
talking
about
the
data
transmission,
fundamental
concept,
for
while
we
had
content
as
the
thing
which
was
essentially
the
the
piece
of
data
that
you
can
send
at
a
time
which
was
related
potentially
to
a
larger
overall
message,
we've
changed
the
wording
to
be
more
message
centric,
but
that
means
on
a
given
send.
R
You
may
actually
send
a
message
multiple
times
that
you
send
the
first
part
of
your
message
and
the
next
part
of
the
next
part,
and
you
could
essentially
stream
that
message
in
and
there
are
properties
of
that
message
which
are
separate
from
the
fact
that
I'm
sending
it
in
separate
chunks,
because
you
definitely
need
to
be
able
to
stream
gigabytes
and
gigabytes
of
data
that
you
can't
all
have
in
memory
at
once.
Okay,.
H
Yeah
I
mean
on
the
rendezvous
side.
I
think
the
the
initial
goal
is
that
we
support
happy
eyeballs
and
things
like
ice,
and
once
we
have
figured
that
out,
which
is
hard
enough
in
itself,
we
then
make
sure
and
try
and
generalize
it
to
anything
else,
people
care
about
yeah
and,
as
for
the
rest,
if
I
think
it's
fairly
clear,
there
are
a
bunch
of
terminology
issues
and
perhaps
suboptimal
names,
and
we,
if
anyone
has
suggested
better
naming
so
try
and
clarify
some
of
this.
We
are
very
open
suede.
This
I
mean.
R
R
Specifically
on
the
rendezvous
stuff,
because
I
believe
we
have
in
scope
some
of
the
basic
parts
of
that
if,
as
you're
looking
at
various
use
cases
here,
you
see
things
about
certain
rendezvous
models
that
the
current
architecture
would
prohibit
or
limit
in
the
future.
Please
bring
those
up
sooner,
because
we
want
to
make
sure
that
it's
not
a
constraint
that
we
have
added,
rather
than
just
something
that
needs
to
be
expanded
upon
in
the
future.
Yes,
yes,
and
just.
H
C
Is
it
hello
yeah?
This
is
dad
exam,
also
co-chairing,
but
maybe
coach
hat
off
here
from
the
floor.
It's
about
the
policy
thing,
so
the
architecture
graph
says
it
has
a
system
policy
and
API
doesn't
say
almost
anything
about
the
policy.
How
do
you
set
up
the
policy
and
the
implementation
drive
size?
We
have
system
policy,
you
have
network
policy
and
her
application
policy.
So
how
do
we
do?
What
is
it
thinking
about
architecture
drop
to
include
or
rename
the
system
policy
to
something
else
or
API
to
include
more
about?
C
V
Q
For
the
API,
the
API
draft
is
really
about
well,
the
focus
of
the
API
draft
now
is
really
about
the
interface
that's
provided
to
the
application
developer.
There
is
missing
language
about
the
interface
that
is
provided
to
an
administrator
or
a
user,
so
that's,
basically
just
an
oversight
right.
So
we're
basically
saying
these
are
the
these
are
the
knobs
that
you
have
as
an
app
developer?
The
app
developer
is
generally
not
going
to
be
setting
the
system
policy
right.
It
may
have
its
own
application
policy
yeah.
Q
Policy
is
essentially
represented
by
the
set
of
you
know,
prefer
avoid
require
so
on
on
the
different
parameters
rate.
So
those
have
to
be
projected
through
business
and
policy
so
yeah.
We
should
add
something
about
that
and
add
the
add
information
about
an
administrative
interface
and
what
that
looks
like
because-
and
it
should
probably
look
the
same
right
so
that
you
can
sort
of
configure
things
in
the
same
terms.
V
But
there
are
also
different
time
scales
on
these
things.
Right
so
I
mean
the
the
port
that
you
say
is
set
in.
The
application
preferences
can
be
changing
and
influenced
by
what
you're
sending
or
what
you're.
In
the
specific
instance
and
the
dynamic
policies
are
also
dynamically
learned
by
the
system,
and
then
the
default
system,
policies
or
more
long
term,
and
they
can
also
be
updated,
but
on
a
different
time
scale.
So
basically,
I
have
those
three
impossible.
R
The
fact
that
the
architecture
defines
the
system
policy
actually
puts
that
in
the
implementation
concepts
of
things
that
are
not
necessarily
going
to
be
exposed
to
the
API
and
the
classic
example.
I
have
of
system
policy
is
on
a
mobile
phone,
a
way
to
disable
cellular
data
for
a
given
app
or
even
the
carrier,
pushing
down
that
policy.
That
is
not
something
that
may
be
ever
expressed
in
any
API
that
anyone
could
interact
with
the
part
of
policy
for
an
application
to
interact
with
that.
R
I
believe
would
be
the
path,
selection
properties,
and
so
we
can
maybe
specify
hey.
You
can
set
your
default
path
for
the
selection
properties
for
my
process,
but
there
will
always
be
a
category
of
things
that
are
invisible
to
the
app
that
come
from
some
other
part
of
the
system
that
maybe
the
user,
interacting
with
the
UI
and
I.
Don't
think
that's
in
scope
for
us
to
specify.
We
just
need
to
interact
with
it.
Yeah.
C
Iii
get
that
under
system
policy
thing,
but
I
do
believe,
like
application
need
to
say
some
some,
sometimes
some
something
about
the
policy
that
system
might
need
to
listen
or
the
network
or
the
server
actually
install
some
policy
from
a
particular
app.
So
I
think
the
only
thing
I'm
asking
is
like
clarification,
and
how
do
you
do
prioritization?
Basically,
when
you
have
multiple
policies
active
on
a
packet
level
or
a
connection
level
or
a
system
level,
so
just
a
clarification
on
those
things.
Yeah.
V
So
I
mean
at
the
moment
we
only
have
specified
that
you
have
the
constraints
you
have
to
follow
for
all
the
policy
inputs.
You
have
right.
So
if
you
can't
satisfy
them,
then
you
cannot
establish
a
connection,
but
then
of
course
it's
in
practice
more
complicated
because
you
may
have
trade-offs
between
different
things
when
it's
not
a
strict
requirement
and
I
mean
some
of
that
I
think
is
implementation-dependent
and
some
of
it
we
can
maybe
specify
some
organized
on
yeah.
C
N
So
a
few
things:
first,
those
things
are
invisible
to
the
applications.
I'm
not
sure
I
might
be
better
to
say
they're
read-only
to
the
application.
Yes,
because
so
there
probably
should
be
a
way
to
find
out:
hey
I'm
not
allowed
to
use
LGG,
so
don't
try,
which
means
you
still
need
an
API
for
that.
You
need
to
read
API
for
finding
out
what
the
default
policy
is
on
and
then
the
second
thing
is
I
feel
like
this
is
maybe
a
little
bit
of
a
couple,
but
it
is
actual
discussion.
N
R
N
R
And
so
I
think
that's
actually
the
point
of
this.
The
this
the
callback
to
sending
a
message
is
not
when
it
has
been
act.
It's
actually
when
it
has
been,
is
actually
consumed
by
the
buffer,
and
so,
if
I
call
send
with
the
message
and
I
don't
get
the
callback
quickly.
I
know
that,
essentially,
there
is
back
pressure
that
the
TCP
send
buffer
cannot
consume
this
data
yet
and
so
well,
we've
used.
R
We
actually
have
some
of
these
similar
models
in
public
api's
ready,
and
we
recommend
that
people
if
they
want
to
limit
their
own
buffering
that
you
should
not
include
other--,
send
until
you've
received
that
call
back.
So
I
think.
The
one
thing
that
we
should
add
probably
is
a
way
to
tune
the
size
that
is
being
theirs
willing
to
be
out
in
an
outstanding
queue
within
TCP,
which
will
essentially
control
how
quickly
their
send
callbacks
will
come.
N
Or
general
point
is
just
to
think
one
thing
that
would
make
me
more
confident
its
API
is,
if
I
could
is,
if
basically
you're
getting
your
on
dog
food,
but
just
say,
could
you
implement
quick
on
top
of
this
UDP
or
give
them
a
tie?
So
if
you
have
a
match,
like
our
mcat
congestion
control,
things
like
that,
so
so.
N
N
R
So
from
our
angle,
at
Apple,
we
are,
we
essentially
use
this
internally,
we
for
our
own
prototypes,
in
which
we
would
be
doing
quick,
interrupt
we've
been
using
both
inside
and
then
also
making
sure
that
the
UDP
surface
of
this
is
what
you
would
need
to
implement
quick.
So
we're
interested
in
both
aspects.
M
A
wide
spectrum
of
like
the
choir
MERS,
you
could
define
both
precisely
on
imprecisely.
So
in
terms
of
those.
Is
there
anything
in
this
API
that
is
planned,
because
that's
one
problem
with
the
sockets
API
today
to
do
the
application
can't
really
provide
intent.
It
can
basically-
and
we
usually
end
up
like
compromising
and
stand
up
yeah.
Q
Y
What
we
have
right
now
is
the
capacity
profile
which
can
specify
in
which
the
application
can
specify
whether
it
wants
to
optimize
for
like
low
latency
or
high
bandwidth.
For
example.
We
also
have
the
concept
of
intense
that
the
application
can
say.
Ok,
this
is
going
to
be
a
big
transfer
and
this
is
going
to
be
like
a
small
transfer.
Y
Y
Q
That
stuff,
right
now
in
the
interface
document,
is
in
Appendix,
A,
I
think
so
we
we
all
of
the
things
that
we
sort
of,
took
in
from
the
three
proposals
and
put
together
that
we
did
not
come
to
consensus
on
this
belongs
in
this
document
went
into
the
appendix,
and
that
was
most
of
the
socket
intense
stuff
and
a
couple
of
other
things
that
came
from
I'm,
not
sure
if
they
came
from
inside
or
not,
but
they
came
from
somewhere
and
I
like,
and
this
doesn't
look
actually
like.
It's
gonna
be
useful,
so
I.
R
Think
those
are
elements
that
we
have
not
finalized
on
the
semantics
for
and
the
correct
way
of
doing
it.
We
believe
that
they
are
useful,
so
I
think,
if
maybe
we
could
take
a
look
at
the
appendix
open
issue
say
like
which
ones
of
these
we
think
are
the
most
important.
How
can
we
phrase
them
correctly?
Once
we
get
consensus,
then
we
believe
we
can
bring
them
in
to
all
three
documents.
Sure.
M
The
other
thing
I
wanted
to
say
is
yes,
the
abstraction
is
great,
but
from
the
perspective
of
the
application,
you
know
if
it
requests
certain
services-
and
you
pick
you
know
your
paths
and
protocols
in
dynamically
that
it
loses
consistency
like
if
a
repeat
connection
and
the
pinging
a
different
protocol.
That's
not!
It
may
not
really
help
with
performance
metrics
and
such
so
some
sort
of
consistency
guarantee
answer
in
terms
of
hey.
If
we
pick
one
path
it
gets
consistently
picked
would
be
useful
to
specify.
R
Right
I
think
when
we
get
into
discussions
of
like
a
specific
deployment
like
it's
very
important
to
know
what
does
my
server
actually
support?
What
are
the
contracts
there
and
I
think
the
preferences
and
allowances
do
need
to
take
that
into
account
right
I.
You
could
imagine
saying
I
want
to
prohibit
this
protocol
on
this
path,
because
I
know
it's
going
to
have
certain
problems
or
will
not
work
or
essentially
really
bias
it
towards
one
or
the
other.
R
M
Think
my
question
is
slightly
different,
so
I'm
saying
that
if
you,
if
you
went
through
all
the
policy
and
you're
racing,
to
figure
out
what
supported
versus
not-
and
you
end
up
with
protocol
X
yeah,
the
application
would
prefer
that
in
that
session,
that
you
continue
picking
X
consistent.
You
know
yeah.
L
M
L
Q
There's
a
there's,
a
chunk
of
the
architecture
that
we
didn't
talk
about
at
all,
which
is
essentially
sort
of
the
the
security
state
cache
and
the
transport
state
cache
right.
So
the
system
any-any
implementation,
the
system
is
necessarily
going
to
have
to
learn
about
paths
and
this
that's
where
the
stickiness
lives
I
think
we
could.
We
can
definitely
recommend
sort
of
parameters
without
stickiness,
but
the
architecture
basically
has
this.
Q
This
idea
that
there's
a
we
call
it
an
association
cache
in
in
Poe
sockets,
because
Association
isn't
overloaded
at
all,
but
the
the
idea
is
that
there's
enough
information
there
and
you
pretty
much-
have
to
implement
enough
important
to
make
this
work.
You
need
to
have
that
cache
and
then
the
stickiness
is
just
a
novel
in
that
cache
and
we
should
we
should
but
you're
right.
We
should
recommend
that
there's
a
certain
amount
of
stickiness
there
in
terms
of
the
parameters.
M
Z
So
gory
fair
has
just
one
of
the
off
the
team
but
I'm
on
the
policies
and
how
all
that
interacts,
because
the
election
and
what
we
do,
there's
probably
multiple
on
what
we
have
as
inputs
here,
because
some
of
these
things
are
actually
asking
for
things
from
the
services
which
are
predictable.
And
if
you
asked
for
this,
you
will
get
this
in
this
environment
and
other
ones
are
optimization
and
tuning
and
I
think
we
have
to
kind
of
discuss.
Z
AA
Yeah
Tim
Jones
form
a
similar
comment
to
gorira
is
to,
for
example,
with
the
system
configuration
where
you're
putting
all
these
things
from
there's
a
potentially
a
bottomless
pit
of
things
you
could
use,
and
one
of
the
things
that
seems
of
interest
to
me
v6
point
of
view
is
the
provisioning
domain
work
over
an
inter
area
and
one
particular
when
you're
multihomed,
but
again
comes
back
to
some
of
the
things
others
have
said.
That
might
be
a
dynamic
thing
where
the
PVD
information
changes
periodically
with
Ras,
and
you
then
have
to
adapt
to
that.
AA
Q
So
it
it
sounds
to
me
I'm
gonna,
it
may
be
Aaron
might
say
the
same
thing.
It
sounds
to
me,
like
there's
a
collection
of
other
things
that
people
would
like
to
see
in
these
documents
about
sort
of
like
actually
running
this
system
right.
So
that
might
be
a
fourth
doc
that
we
don't
have
yet
it
might
go
into
the
implementation,
talk
and
then
come
back
out.
I,
don't
know
it's!
It's
not
really
clear
to
me
where
this
work,
but
there
that
does
seem
to
be
a
hole
that
that
we
need
to.
B
I
think
that
we
won't
be
able
to
write
that
doc
until
people
yeah
so
I
set
this
question.
Email
I
didn't
get
an
answer
and
I
think
it
might
be
interesting
enough
to
raise
in
this
group,
which
is
you
know
like
a
year
or
two
ago
there
was
a
woman
here
who
was
doing
like
some
very
high-performance
TCP
stuff,
and
she
was
really
concerned
about
like
setting
socket
options
for
her
tcp
and
wondering
whether
taps
was
going
to
allow
to
do
that.
B
V
B
Q
Because
that
won't
work,
obviously
so
we
just-
but
this
is.
This-
is
sort
of
tied
to
an
issue
that
we
kind
of
just
realized
that
we
had
when
we
were
looking
over
this
here
in
London
is
there's
a
sort
of
a
general
right.
This
is
the
what
specified
in
the
interface
document
is
sort
of
the
low
performance
version,
the
interface
right,
it's
the
you
know.
We
do
everything
one
at
a
time
right,
so
batch
tayo.
Q
We
probably
need
to
be
able
to
to
have
some
sort
of
way
to
get
out
of
the
way
for
batch
sends.
We
might
need
to
get
out
of
the
way
for
memory-mapped
I/o
and
direct
NIC
access.
These
are
things
that
we
know
we
need
to
put
cut
outs
in
the
API,
for
so
we
won't
keep
people
from
doing
them,
but
we
don't
know
how
to
do
that
yet
so,.
B
O
O
B
B
R
R
My
gut
on
this
would
be
that
it
should
all
go
through
taps.
That
is
why
we
have
the
design
principle
in
there
at
the
very
beginning,
like
we
need
to
support
specific
protocols,
because
we
need
to
address
these
use
cases.
We
cannot
have
a
worse
set
of
things
than
this
existing
standards.
From
my
own
perspective,
like
in
our
own
implementation
of
this
we're
not
always
going
over
sockets,
because
sometimes
we
have
ways
of
doing
things
more
efficiently
than
a
socket
option
would
have.
R
So
if
you
all,
you
do,
is
directly
exposed
to
the
socket
option
through
and
you
allow
someone
to
call
set
sock
opt.
You
are
now
essentially
exposed
the
fact
that
there
isn't
a
single
underlying
socket
there.
That
does
become
quite
problematic
if
you
are
doing
something
like
now,
I'm
doing
some
multi
streaming
thing
on
top
of
quick,
there
is
no
F
D.
R
There
is
no
any
of
this
underneath
that
so
I,
the
only
person
I
think
we're
taking,
is
have
a
one-to-one
mapping
of
all
the
existing
socket
options
that
we
believe
are
important,
and
it
essentially
replaces
the
socket
option.
Directory
and
individual
implementations
we'll
have
to
manage
those
sure
would
be
good
document
said
that
somewhere,
because
I
was
looking
at
explicitly.
R
Y
About
these
properties,
we
now
have
a
real
zoo
of
protocol
selection,
properties,
path,
selection,
properties
than
specific
protocol
properties,
generic
protocol
properties,
and
then
they
can
be
specified
by
the
application,
as
required,
preferred
or
not,
and
then
later,
when
the
connection
existing
application
can
query
which
of
them
were
actually
satisfied.
And
so
this
is
right.
As
I
said,
it's
a
zoo
and
I
would
propose.
Y
We
just
make
one
pair
one
section
in
the
API
draft,
where
we
sort
ease
out
really
neatly
and
like,
and
then
this
is
also
also
going
to
be
about
terminology,
because
there
has
been
some
confusion
and
then
we
have
to
fix
on
which
ones
go
in
the
draft
and
which
ones
go
in
the
extension
and
appendix
we
just
have
to
make
sure
we
don't
constrain
ourselves
for
the
future.
I.
O
Just
wanted
to
put
unfelt
easel
I
just
want,
to
put
it
a
little
bit
more
into
a
perspective
that
I
think
that
AB
system
should
have
both.
It
should
have
some,
let's
say,
mall
as
Auto
mode,
that
as
an
application,
you
specify
it
in
as
easy
as
possible
way
and
say
well,
I'm
doing
the
following
stuff.
Please
give
me
an
appropriate
transport
and
allow
the
implementer
of
the
tap
system
to
make
smart
choices
there,
based
on
various
inputs
based
on
configuration
based
also
probably
on
third-party
interests.
O
On
the
other
hand,
if
the
application
exactly
knows,
I
need
a
TCP
socket
and
I
need
the
following
tuning
for
me
within
the
TCP
protocol.
So
not
the
socket
options
as
it
was
exposed
by
the
bsd
api,
but
as
the
protocol
parameters
for
tcp
are,
then
the
application
should
be
able
to
to
do
this.
But
I
think
this
are
two
different
modes
and
an
application
can
even
mix
and
match
with
these
modes.
R
I
totally
agree,
I
think
one
of
the
nice
things
here
is
that
is
really
not
diverging
from
what
sockets
already
does
I
mean
when
I
look
at
socket
applications
today,
they're
lost
that
just
call
socket
connect
send
receive,
and
there
are
lots
that
have
tons
of
socket
options.
So
this
is
not
unprecedented.
H
Okay,
so
we've
had
done
I
think
quite
a
good,
detailed
discussion
here.
Obviously,
this
API
is
being
built
based
on
our
best
guess,
that's
what
the
API
should
look
like
and
based
on
our
experiences
with
these
protocols,
a
very
set
of
protocols
and
I.
Think
one
of
the
things
that
would
be
useful
to
get
input
from
from
the
working
group
is:
are
there
any
protocols
which
don't
fit
with
this
API?
So
anything
we've
gotten
about
any
styles
of
protocols
which
we
forgotten
about
well.
B
H
O
E
Q
Authors
put
together
a
github
organization,
called
taps
API.
We
can
send
a
link
to
this
to
the
list
for
people
who
file
issues
on
it.
What
do
we
want
to
bring
that
under
working
group
control?
It's
got
one
repo
in
it,
which
is
our
drafts
repo,
if
they're
all
adopted.
Q
E
B
AB
So
I'm
Fernanda,
gold
and
I
will
be
presenting
our
idea
on
the
problem
statement
regarding
ipv6
address
usage.
As
a
very
small
background.
This
is
a
document
that
we
had
originally
targeted,
six
men
and
when
we
presented
this
document
at
sixth,
when
we
were
suggested
that
taps
would
probably
be
a
better
venue
for
it
next
slide.
AB
So
some
words
about
the
ipv6,
obvious
usage
problem
statement.
Obviously
a
pv6
provides
increase,
address
and
flexibility.
We
have
like
plenty
of
fallacies
and
also
we
have
addresses
of
the
different
properties
like
scope,
stability,
etc,
and
there
are
a
number
of
things
that
are
related
with
them,
with
the
properties
of
the
addresses.
First
of
all,
that
the
implications
of
these
properties
are
not
always
well-known
implications
in
terms
of
security,
privacy,
interoperability,
etc,
and
there
are
also
exists.
AB
So
what
this
document
is
about,
as
I
mentioned
before
our
document
was
originally
target
at
six
months,
so
that
that's
why
it
focuses
on
one
ipv6.
Only
so
far,
one
of
the
first
goals
of
the
document
is
to
discuss
the
implications
of
different
ipv6
address
properties.
For
example,
if
you
take
a
look
at
temporary
addresses,
what
are
the
implications
on
security
and
privacy,
but
also
on
interoperability,
because,
for
example,
in
some
implementations,
when
these
addresses
become
invalid,
if
he
had
a
long
lead
the
Sippi
correction?
AB
Well,
the
TCP
connection
will
be
teared
up
okay,
so
these
are
some
of
the
of
the
properties
that
we
want
to
analyze
by
providing
analysis
of
all
these
properties,
so
that
at
the
time
in
which
you
want
to
make
a
decision
on
which
others
to
use-
or
you
know
what
the
implications
are,
the
second
goal
is
to
provide
a
probe,
a
problem
statement
regarding
ipv6
service
issues.
Usage.
This
is
related
with
the
limitations
that
we
have.
You
know
the
current
IP
is,
and
you
know
the
third
one
is
to
possibly
trigger
work
in
this
area.
AB
AB
Yeah,
the
last
one
that
I
had
seen
was
the
the
one
of
the
goals.
So
I
guess
that's
the
yeah
I
think
that's
the
right
one.
So
some
comments
when
it
comes
to
you
know
the
limitations
of
the
api's,
for
example,
when
you
think
about
our
going
connections,
there's
a
lot
of
things
that
you
cannot
really
specify.
For
example,
you
might
want
for
some
specific
application
to
have
a
new
address
created
for
your
application,
whatever
that
is,
you
might
want
to
employ
different
addresses
for
different
users.
AB
AB
F
AB
And
the
implications
on
incoming
connections
is
that
you
know,
typically,
when
you
look
at
the
sockets
API
oceans,
that
an
application
has
is
to
either
buy
the
while
Carreras,
meaning
that
you
will
accept
incoming
connections
on
all
of
the
addresses
or
another
thing
that
you
might
do
is
to,
for
example,
buying
specific
addresses.
But
if
you
decide
to
find
specific
addresses
well,
first,
it
essentially
becomes
very
non
portable,
okay
and
also
the
application
you
need
to
understand.
AB
You
need
to
be
able
to
you
know,
to
analyze,
how
to
identify
and
know
the
properties
of
each
of
the
addresses
that
you
have
on
your
system.
So
you
know
quite
likely
what
you
respect
is.
You
know
to
be
able
to
specify
some
decide
properties
on
the
kind
of
addresses
that
you
want,
and
you
know
have
the
API
deal
with
them,
but
obviously
that's
a
gap
in
there,
because
that's
something
that
you
you
know
you
currently
cannot
do.
It's
like.
AB
Z
Okay
discussion
so
gory
fire
Fairhurst
here.
Thank
you.
If
not
all,
for
going
through
that
and
I
see
two
things
in
the
document.
As
I
read
it
I
see
something
about
use
of
ipv6
addresses
and
the
policies
and
the
implications
of
using
these
and
I
also
see
the
need
for
a
new
API.
If
those
concerns
need
us
to
react
and
I'm
interested
in
what
six
months
they
thought
about.
Z
The
the
security
and
the
use
of
privacy
addresses
on
the
whole
framework,
because
that
piece
seems
very
alien
to
transport
to
me,
but
the
second
part
designing
a
new
API
might
be
really
interesting.
If
the
first
of
all
is
clear,
maybe
it
should
be
two
documents.
Perhaps
I
don't
know:
do
you
have
any
feedback
on
what
happened
in
six
melon?
How
enthusiastic
they
were
about
the
whole?
You.
AB
Essentially,
I
presented
that
he
once
or
twice
and
like
the
response
that
I
think
I
got
was
like
it
didn't,
really
belong
the
six-month
and
it
would
be
long
as
well
like
Tufts.
If
you
ask
me
myself,
I
think
that,
for
example,
the
analysis
of
the
properties
of
fathers
is
from
my
perspective,
it
actually
might
you
know,
fall
into,
let's
say
six
men
or
in
area.
That's
my
personal
thought,
I
guess.
Certainly
the
API
is.
You
know
something
that
is
that
more
clearly
falls
within
tubs.
AC
So,
literally
one
of
the
six
months
years,
so
in
six
men,
we've
defined
all
these
mechanisms
for
generating
these
six
addresses
of
different
properties,
and
you
have
you
know:
temporary
privacy
addresses
and
different
lifetimes,
and
all
that
we
have
specified
one
document
that
on
source
address
selection,
which
has
lots
of
policy
tables
and-
and
you
know,
some
ways
for
applications
to
make
preferences
who,
which
type
of
address
they'd
like
but
we're
very
much
a
bottoms-up.
AC
We
made
this
available.
We
really
have
no
idea
how
it
should
be
used.
So
I
don't
think
you
know.
This
is
why
we
wanted
to
drop
this
to
the
people
who
could
actually
make
use
of
these
things.
We
don't
want
to.
The
only
thing
we
have
is.
We
have
addresses
with
different
properties
in
different
lifetimes
and
that's
kind
of
where
our
competency
ends.
R
Tommy
Polly
Apple,
thank
you
for
another
for
presenting
this
well
I
agree
that
there
do
seem
to
be
two
separate
concerns
here.
I
think
the
aspect
of
the
privacy
and
security
properties,
or
when
should
you
use
one
or
the
other
feels
like
it
belongs
in
another
document
that
likely
is
not
in
taps
I,
don't
know
exactly
where
that
belongs.
Maybe
it's
in
terrier
I.
Don't
know.
R
However,
the
mechanism
for
actually
selecting
these
I
think
really
sounds
like
one
of
the
path
selection
properties
that
we've
been
describing
in
the
architecture
in
the
API
and
in
the
implementation.
So
especially
I
think
for
the
case
of
a
server
you
know.
Do
I
want
to
be
only
receiving
connections
on
my
one
stable
public
address.
Do
I
want
to
only
receive
them
on
the
temporary,
don't
receive
them
on
all
of
them
when
I'm
creating
outbound
connections
based
on
the
properties
of
these
connections.
R
What
source
address
do
I
want
to
bias
towards,
because
those
are
effectively
different
paths
when
we're
thinking
of
MPT
CP,
it
can
essentially
treat
every
source
address
as
a
different
path
that
it
has
so
I
think
that's
really
all
very
relevant
and
the
right
place
to
specify
that
would
be
in
the
interface
that
we
were
just
describing
so
rather
than
adopting
this
draft
as
the
tabs
working
group
item,
because
I
think
it
includes
other
things
than
this.
What
would
you
say
about?
AB
For
me,
that's
that's
fine.
The
only
thing
you
know
I
agree
that
there
are
parts
of
this
document,
but
the
thing
is
that
the
analysis
of
the
you
know,
iris
properties,
is
kind
of
like
necessary
to
be
able
to
do
the
other
part,
because,
obviously
the
time
in
which
you
you
want
the
application
to
select.
You
know
some
kind
of
properties.
Those
properties
are
going
to
map
into
specific
kinds
of
viruses
with
alice's
of
you
know,
specific
properties.
So
that's
some.
What
I
wonder
is
where
we
will
keep
the
analysis.
AB
I
mean
I,
agree
that
the
API
part
I
could
belong
in
a
different
document,
but
it
yes
in
some
place
or
another.
You
should
have
a
discussion
or
how
you
map
some
properties.
The
application
is
requiring
to
which
addresses-
and
you
know
the
logic
that
map's
one
thing
to
the
other.
Well,
if
the
document
essentially
or
is
something
that
it
explains,
what
are
the
properties
of
the
different
kinds
of
Alice's?
Will.
R
Be
useful
to
be
able
to
reference
that
document
as
guidance
it
also.
We
would
need
to
think
what
should
the
tap
system
do
by
default?
Let's
say:
maybe
it
has
a
different
default
for
listeners
than
it
does
for
outbound
connections.
I
I,
don't
know
is
that
use
ipv6
ops
is
that
in
terrier
what
I
don't.
O
Y
Turning
hat
I
think
I
see
some
potential
input
to
the
implementations
draft
there
as
well,
because
that's
about
default
addresses
and
also
the
sorting
of
potential
endpoint
addresses,
but
also
local,
addresses
and
and
I
also
see
a
potential
relation
to
the
security
parameters
that
we
specify
in
the
API
Draft.
So
maybe
it
can
also
like
have
an
influence
on
those
or
vice
versa.
Z
So
quarry
first
coming
back
again
after
having
a
few
moments,
to
think.
Is
it
possible
that
you
can
revise
the
traffic
just
to
be
clearer
on
the
separation
between
the
things
you
would
seen
an
API
on
the
problem
space?
Even
if
it's
just
the
same
document,
apero
grass
around,
would
would
really
help
me
figure
out
and
who
perhaps
should
look
at
this
because
I
don't
really
know
which
group
should
look
at
it
or
not.
Z
B
AA
Jones
I
think
well.
This
should
be
included
as
part
of
the
standard
work.
You're
not
pulled
out
of
something
ipv6
specific,
but
67
24,
it
does
say
prefer.
Temporary
address
is
outbound,
so
it's
a
kind
of
a
big
clue
in
there
that
if
you're
your
default
should
be
to
do
that,
but
whether
there
are
then
hints
on
the
path
selection
to
change.
That
and
pvd's
might
change
that
sure.
But
that's
all
part
of
the
general
architecture,
not
something
it's
v6.
Was
it
so.
B
Okay,
so
that's
a
that's
it
for
the
agenda.
Thank
you
very
much
to
Tom
Jones
for
taking
notes
in
the
ether
pad.
If
anybody
said
anything
at
the
microphone
that
is
expecting
somebody
else
to
do
work,
you
should
make
sure
that
the
ether
pad
captures
it.
So
there
is
a
record
of
that
that
discussion.
It's
all
available
right
now
and
thanks
for
buddy
for
coming
Thank,
You,
Fernando
and
we'll
see
you
in
Montreal
blue
sheets
has.