►
From YouTube: IETF99-TAPS-20170718-0930
Description
TAPS meeting session at IETF99
2017/07/18 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
A
There
we
go:
okay,
terrific,
okay,
well,
let's
just
sleep
in
here
and
I'll
hand
them
out
people.
C
A
A
I'm.
Sorry,
yes,
would
you
thank
you
very
much,
dad
okay,
we're
running
a
minute
late,
but
that's
all
right.
We
got
lots
of
time.
A
A
Okay,
well,
then,
I'm
not
going
to
kind
of
paraphrase
it,
but
my
formal
understanding
is,
if
you
say
something
here,
it's
considered
to
be
an
IDF
contribution.
If
you
say
something
in
the
hallway,
it's
considered
to
be
an
IETF
contribution.
If
you
send
something
to
the
Jabbar
list
of
the
mailing
list,
it's
90
F
contribution.
So
that's
public
disclosure
might
want
to
think
about
that.
Okay,.
D
E
A
A
A
A
So
your
name
yeah
the
Dylan
tripping
co-chairs
of
taps
transport
services,
if
you're
in
this
room,
you've
probably
been
involved
for
a
while,
because
this
is
we're
in
our
third
year.
This
is
a
little
bit
of
status
on.
What's
going
on
with
the
working
group,
we
are,
we've
published
several
documents
that
all
contribute
to
what
we're
calling
milestone,
one,
which
is
an
analysis
of
transport
protocols
in
an
attempt.
A
That
will
allow
us
to
derive
an
abstract
API
for
transport
features
and
functions
that
we
published.
One
RFC
I
mean
us
at
the
last
ITF
since
then
we
finalized
and
held
out
last
call
on
a
set
of
usage
documents
that
refined
this
analysis
and
come
up
with
some
nomenclature
for
how
to
refer
to
various
transport
features.
Those
are
separated
into
two
documents
because
they
had
really
two
different
author
sets,
one
for
TCP
and
SCTP
and
and
another
one
for
UDP
and
UDP
light,
plus
the
there's
other
stuff
in
there.
A
A
Hopefully
this
week,
I
think
what's
missing
is
that
I
need
to
I
need
to
review
it
and
Spencer
will
read
them
and
then
something
good
will
happen.
So
that's
the
that's.
The
first
of
the
I
think
that
completes
the
first
of
the
three
milestones.
I
think,
there's
an
open
question
about
whether
we
want
to
add
the
some
of
the
security
stuff
that
that
we're
gonna
be
talking
about.
Today,
to
that
as
well,
I
certainly
think
they
want
to
publish
it.
Yeah,
gory
gory.
F
A
A
H
F
Gouri
Fairhurst
again
and
yeah.
Another
reason
that
I
quite
like
having
them
separate
was
because
I
think
the
audience
of
the
two
documents
is
different.
There's
a
lot
of
people
in
apps
use,
UDP!
There's
a
lot
of
people
takes
the
other
transports
just
as
TCP
or
SCTP
or
whatever,
and
just
run
things
over
it.
So
I
think.
Maybe
the
audience
is
different
and
publishing,
as
a
pair
seems
cool.
F
Okay,
we
have
a
conversation,
but
yes,
that's
probably
true,
but
there
isn't
the
documentation
for
anything
to
do
with
UDP
dates
from
the
kind
with
time
we
built
the
ark,
and
therefore
this
is
probably
the
first
time
I've
ever
gathered
this
stuff
together.
I
think
people
might
well
think
that's
helpful,
even
if
they're
not
doing
tubs.
A
There
hasn't
we
actually
discussed
this
a
couple
times.
It
has
been
a
big
push
to
try
to
combine
the
documents
and
it
would
be,
you
know,
be
significant
amount
of
effort
so
since
nobody's
trying
that
no
one's
asking
for
it,
okay,
so
moving
on
to
milestone
to
milestone
to
is
to
take
you
know
somehow
what
milestone
one
did
was.
A
It
went
through
all
the
transport
protocols
in
ITF
standards,
plus
some
additional
ones
that
folks
wanted
to
focus
on
and
deliberately
excluded
security,
because
we
didn't
have
anybody
at
the
time
we
wanted
to
work
on
it
and
then
come
up
with
a
standard
set
of
description
of
features
and
systems.
Are
you
looking
for
the
radio?
A
Yeah
awesome,
if
you
could
find
it,
what
makes
me
want
to
dance
so
milestone.
Two
was
about
taking
that
that
that
long
list
of
description
of
features
and
trying
to
come
up
with
a
minimal
set
of
recommended
features
that
a
tap
subsystem
should
support,
and
so
this
the
idea
was
that
if
you
had
multiple
implementers
who
are
doing
taps
that
they're
at
least
sort
of
supporting
a
common
set
of
useful
stuff,
and
so
it's
a
recommendation
doc.
A
But
it's
a
recommendation
doctor
for
implementers
of
of
taps
and
and
so
we're
going
to
hear
a
discussion
today
on
current
version
of
that
draft,
which
is
kind
of
stabilizing
now
and
hasn't
been
adopted.
As
a
working
group.
That
seems
like
an
oversight
which
is
just
I
think
we
should
make
a
decision
today
if
we're
gonna
adopt
it,
because
we
don't
have
an
alternate
documented
in
progress.
A
So
I
was
really
happy
at
the
last
IETF
Tommy
from
Apple
and
and
brought
some
friends
of
his
and
agreed
to
take
a
look
at
the
transport
security
protocols
and
try
to
apply
the
same
analysis
methodology
that
we
did
on
the
on.
Basically,
the
the
data
sighted
transfer
protocols
to
the
security
protocols
so
that
we
can
come
up
with
sort
of
a
add
to
the
the
language
that
we're
building
for
the
abstract,
API
the
to
talk
about
different
kinds
of
security
services.
A
There's
several
really
useful
implementation
efforts
underway.
I.
Think
we've
already
learned
a
lot
about
that.
We're
going
to
hear
a
discussion
about
a
couple
of
those
projects
today
and
now
that
we've
gotten
you
know,
people
are
starting
to
these
things
and
they
are
talking
about
the
mechanisms
for
detecting
what
transport
protocols,
work
and
and
and
making
decisions
about,
selecting
one
over
the
other.
Assuming
an
application
uses
these
abstractions
to
describe
what
kind
of
behavior
it
wants.
A
One
of
the
things
that
that
I
would
like
to
start
thinking
about
today.
As
a
group
is
you
know,
what's
the?
What
are
the
output
of
this
activity
going
to
be
now
that
we've
sort
of
got
the
language
to
talk
about
these
things?
You
know
we're
going
to
just
sort
of
write
some
rfcs
that
describes
the
various
implementation
projects.
A
Do
we
have
enough
of
a
consensus
that
we
make
some
recommendations
for
how
what
someone
should
do
in
a
tap
system?
You
know:
can
we
agree
on
on
some
aspects
of
this,
and
so
that's
the
kind
of
thing
I'm
going
to
be
listening
for
out
of
this
and
maybe
try
to
propose
some
some
additional
documents
as
as
work
items,
here's
the
schedule.
A
So
I
think
that
we're
going
to
finish
doc.
One
today
milestone
two
I
think,
assuming
that
we
adopt
min
set
and
it's
kind
of
stabilizing
that
we
hopefully
will
be
able
to
get
that
last
called
around
the
next
IETF,
and
then
that
gives
us
one
more
cycle
for
the
thing
that
comes
later
and
I.
Don't
think
we
know
exactly
what
that
is
yet,
so
that's
probably
going
to
push
out
a
little
bit
now
rolling
back
to
the
agenda
which
I
kind
of
skipped
over
here.
So
this
was
this.
A
Is
the
working
group
status
discussion
that
we've
been
having
next
Naima
Naima?
Are
you
thank
you?
I'm
just
gonna
talk
about
the
min
set
of
transport
services
that
the
author's
Michael
and
who's
the
other
author
cited
yep
aren't
able
to
make
it
today
so
he's
going
to
give
an
overview
of
what's
going
on
from
that
team,
Chris
and
Tommy
are
going
to
talk
about
transport
security,
protocol
analysis
and
and
there's
a
bunch
of
open
questions
to
discuss
about
how
we
want
to
treat
that
stuff.
Phil
teasel
is
going
to
talk
about
socket
intents.
A
It's
come
up
a
few
times
in
the
past
and
that's
a
that's
a
project.
That's
continuing
to
mature
same
thing,
Ana's
going
to
talk
about
happy,
eyeballs
project
and
then
hopefully
we're
going
to
have
about
roughly
an
hour
to
talk
about
policy.
I,
don't
know
if
we're
going
to
need
all
that
time,
but
I
think
that
that's
that's
a
it's
good
to
have
a
little
bit
of
a
unstructured
area,
so
we
can
sort
of
see
where
that
discussions
going
to
go
any
comments
or
questions
on
the
agenda.
A
I
J
J
I
I
So
basically,
what
is
the
context
of
this
draft
is,
is
basically
trying
to
address
the
Charter
to
the
item
two
of
the
taps,
Charter,
which
tries
to
specify
the
subset
of
transfer
services
that
are
defined
in
the
item,
one
that
n
system
says
of
that
support,
taps
they
basically
provide
them
and
it
gives
guidance
to
them
to
choosing
among
these
available
mechanisms
and
protocols.
So
the
main
point
here
is
that
we
don't
necessarily
need
to
expose
all
the
transport
services
all
the
capabilities
of
all
the
variety
of
transfer
protocols
into
this
minimum
set.
I
So
it's
basically
a
minimum
set
that
that
needs
to
require
record
to
provide
the
services
that
we
think
that
are
important
to
have,
so
why
we
why
it's
a
minimal
set
is
basically
because
we
don't
want
to
expose
everything
and
why
we
don't
want
to
expose
everything.
Two
main
reasons
is
that
first,
it
will
create
a
very
complicated
API,
so
it
will
be
very
difficult
for
the
application
programmer
to
use
it,
and
the
second
is
that
it
basically
so
basically,
it
ties
us
to
a
specific
protocol
selection.
I
So
if
we
have
lots
of
transport
features
there
to
expose,
do
you
may
end
up
in
a
situation
where
you
go
on
selecting
a
specific
transfer
protocol
all
the
time,
so
we
want
to
make
things
as
automatable
as
possible,
so
this
draft
is
basically
based
on
two
other
drafts,
so
it's
driven
based
on
the
methodology
data
that
were
defined.
The
three
phases
that
were
defined
in
the
in
the
ITF
taps
transferred
usage
drafts,
the
one
that
covers
anything
but
UDP,
and
then
the
other
one
that
covers
the
UDP
ones
next.
I
So
this
is
the
the
revision
0-5
the
main
changes
since
the
zero
four
was
that
now
it
before
it
used
to
be
that
that
we
had
all
the
the
mechanism
to
derive
this
minimum
set
at
the
beginning
of
the
draft
right
now
you
have
the
the
textual
description
of
the
minimum
set
and
the
abstract
API
at
the
beginning,
and
then
you
have
the
mechanism
appearing
as
an
appendix
the
mechanisms
to
derive.
This
is
basically
a
tree
step
or
four
step
mechanism.
I
First
of
all,
you
basically
categorize
these
transport
features
of
transport
services.
You
categorize
them
into
three
categories.
There
are
things
that
are
functional,
which
means
that
the
application
basically
assumes
these
things
of
working.
For
example,
an
application
has
an
assumption
that
things
are
going
in
in
order
delivery,
so
the
application
is
written
for
in
order
delivery,
and
if
you
have
out
of
order
delivery,
then
the
application
doesn't
understand
it.
So
so
it's
as
a
functional
thing
and
the
application
breaks.
I
That's
the
assumption.
We
take,
we
ideally
better
to
be
able
to
file
back
either
to
this
V
or
UDP.
In
this
case,
we
assume
that
we
always
want
to
fall
back
to
TCP.
So
if
anything
prohibits
falling
back
to
TCP
is
something
that
you
don't
want
to
expose.
That's
the
reduction
step
so
to
two
major,
basically
criteria
to
reduce
the
list,
and
then
once
we
have
that,
then
we
have
some
cases
of
peculiarities,
for
example,
as
I
will
explain
later.
I
So
the
reason
we
need
the
groups
is
mostly
in
case
of,
for
example,
a
CTP.
There
are
things
that
you,
for
example,
a
taps
flow,
can
end
up
being
an
sctp
stream
or
or
at
the
TCP
connection.
So
you
want
to
be
able
to
differentiate
between
those
by
having
the
notion
of
grouping
the
flow.
So
all
the
taps
flows
that
belong
to
the
same
group,
they
basically
this
example.
They
will
end
up
being
in
sccp
association
and
whereas,
in
the
tcp
case
you
could
basically
configure
this
in
a
different
way.
I
I
Then
you
have
the
limited
basically
notion
of
that:
the
connect
and
listen
and
close
and
abort
semantics
in
the
draft.
This
is
mainly
because
to
support
UDP
and
streams,
because
we
don't
have
to
connect
with
the
notion
of
connect
in
the
UDP
so
to
be
able
to
have
that,
and
also
there
was
one
thing
that
Michael
presented
in
the
last
ITF,
and
that
was
the
notion
of
being
able
to
send
messages,
but
then
receiving
streams.
I
And
the
reason
for
that
is
that
yes,
so
you
want
to
be
able
to
fall
back
to
TCP
in
any
case,
and
if
you
have
a
new
UDP
application.
What
happens
is
that
the
UDP
application,
when
they
send
us
a
message
at
the
receive
side?
It
is
not
able
to
fall
back
to
TCP.
So
to
be
able
to
do
that.
You
want
to
have
a
notion
of
being
able
to
send
message
and
and
and
also
received,
byte
stream,
so
that
that
was
basically
indeed
presented
in
detail
in
the
previous
ITF.
I
So
if
you
want
to
have
more
details
on
that,
you
can
just
refer
to
the
presentation
of
Michael
and
then
another
thing
is
that
you
want
to
be
able
to
have
a
uniform
way
at
the
at
the
API
level
to
access
or
specify
the
tcp,
low-water
mark
or
SCTP
sender
dry.
So
these
things,
basically,
they
are
slightly
different
in
the
way
that
they
are
basically
operating
over
the
buffer,
and
you
want
to
be
able
to
have
a
uniform
way
at
the
API
to
do
that,
and
also
there
were
some
some
things
about
the
packet
sizes.
I
So,
for
example,
when
it
comes
to
path,
MTU
discovery,
if
you're
changing
the
path,
the
path
underneath
without
the
application
knowing
about
it,
then
UDP
applications
may
break
down
because
they
don't
know
about
the
path
MTU
of
that
specific
path.
So
the
recommendation
here
is
that
if
you
have
the
don't
fragment
field,
basically
set
you
either
don't
change
the
path
or,
if
you
do
it,
let
the
application
know
about
it.
Next,
please
so,
based
on
this
high-level
view,
the
draft
basically
has
driven
a
minimum
set
abstract
API.
I
So
this
is
a
first
try
to
specify
an
abstract
API
for
the
min
set.
Basically,
you
start
with
the
creating
a
flow
at
the
beginning.
Using
the
flow
group
ID.
Then
you
can
configure
timeouts,
you
can
configure
urgency
and
in
the
urgency
you
can
have
a
parameter
called
the
capacity
profile
and
also
the
low-water
mark
flag.
So,
in
the
capacity
profile
you
you
could
have
different
basically
capacity
profiles.
For
example,
you
have
the
pool.
I
It's
basically
sending
and
receiving
frames
when
sending
frames,
we
should
be
able
to
set
the
reliability.
This
is
added
as
it
stands
right
now,
so
the
authors
had
a
feedback
from
the
from
the
socket
intent
folks
that
it's
better
to
actually
be
able
to
set
the
reliability
at
the
beginning
of
the
flow
creation,
because
we
already
know
what
kind
of
reliability
we
are
expecting.
So
it's
kind
of
a
bit
late
to
do
it
at
the
at
the
frame
level
later.
I
I
I
Also,
you
should
be
able
to
query
properties,
for
example,
the
maximum
frame
size
that
can
be
sent
without
fragmentation,
the
maximum
frame
transport
frame
size
that
can
be
sent
on
maximum
transport
frame
size
that
can
be
received,
and
also
the
maximum
amount
of
the
day
that
can
be
sent
before.
Actually,
we
have
the
connection
establishment
so
send
before
before
connect
next,
please.
I
So
in
conclusion,
the
tap
system
can
potentially
do
more
than
this
stuff,
but
what
we
want
to
have
is
that
we
want
to
be
able
to
have
the
minimum
set
of
things
that
we
would
like
to
provide.
There
is
a
basically
important
hint
here,
and
that
is,
if
you
expose
limiting
functional
features,
you're,
actually
limiting
the
ability
to
select
these
new
transfer
protocols
that
we
want
to
use.
So
it's
better
to
not
expose
things
that
that
basically
limits
the
choice
of
transfer
protocol.
I
E
G
Mia
who
live
in,
say,
I
think
it
was
actually
not
an
oversight
to
not
adopt
it
because
kind
of
this
is
a
completely
talking
different
document
than
the
previous
version
rate.
This
is
just
something
completely
different
and
and
yeah
you're
going
one
step
further,
which
is
not
wrong,
but
maybe
not
the
wrong
the
right
document
to
do
it.
I
think
like
talking
about
the
API,
you
should
probably
be
steps
here.
So
I
was
actually
I
was
I
was
if
I
remember
correctly.
G
I
was
making
last
time
in
common
that
I
actually
want
to
see
something
else.
Then
what
was
in
the
document
previously,
but
I
wanted
to
see.
The
other
part
I
wanted
to
see
more
discussion
about
what
can
be
automated
and
how
and
which
other
things
that
need
direct
input
from
the
application
and
now
Michael
wants
to
say
something.
K
Of
course,
I
think
I've,
probably
the
right
answer.
So
this
is
just
an
extension
of
the
work
and
it
hasn't
it
hasn't
changed.
Actually
it
was
just
that
what
you
saw
before
is
most
pretty
unfinished.
We
haven't
invented
the
new
API.
Anything
is
just
a
different
way
of
writing
up
to
services.
So
this
is-
and
you
know
this
final
list
of
services
that
were
that
with
this
process
you
end
up
with
it
wasn't
a
grievous
version.
K
C
G
K
It's
it's
not
a
proposal
of
one
specific
API
that
that
taps
is
gonna.
Deliver
it's
it's
a
list
of
services,
so
you
can
read
this.
You
know
we
have
two
separate
sections
there.
One
is
kind
of
like
the
slide
that
naima
that
just
talks
about
it
in
prose
and
the
other
one
is
listing
the
same
thing
as
an
API,
but
that's
just
an
abstract.
It's
just
a
way
of
looking
at
I.
Think.
G
M
Can
we
go
actually
back
to
the
API
yeah
here
so
as
as
I
read,
it
there's
two
ways
to
read
this
right.
Well,
there's
three
years
to
read
this
and
I'm
gonna
choose
not
to
read
it
in
the
third
way,
because
if
I
just
read
it
in
a
third
way,
then
I'm
gonna
be
unhappy
and
I
want
to
be
happy.
Cuz,
it's
early
on
Tuesday
morning.
It's
not
not
Friday,
yet
I'm
not
ready
to
be
unhappy.
I
am
ready
to
move
the
mic,
though
so
what
I
see
here
is
basically
a
I.
M
Don't
actually
see
this
as
an
API
for
the
implementation
of
programs
and
because
I
think
it's
a
bit
too
low-level
I
would
say
that
this
is
a
supply-side
API.
This
is
a
after
the
analysis
of
the
minimal
set
of
things.
This
is
this
is
the
shape
of
the
API
that
any
okay
I'm
overloading
API
here.
This
is
the
shape
of
the
interface
that
taps
has
to
provide
to
the
thing
that's
going
to
implement
the
API
that
applications
are
going
to
be
implemented.
Correct,
like
this
is
the
low
level.
This
is
the
low
level
API.
K
M
So
as
long
as
as
long
as
that,
that's
a
clear
intent
and
I
think
that
this
is
actually
pretty
sane
if
the
intent
is
to
is
to
force
me
to
write
my
applications
in
this,
then
I'm,
not
unless
happy
but
I,
don't
think
that's
the
end.
I
thought
the
intent
is
like
the.
K
M
M
Mark
all
team
instruments
that
abstract
interface
and
I
think
this
whole
conversation
just
goes
away
then,
because
this
this,
this
is
pretty
clearly
seen,
and
it
also
like,
coincidentally,
happens
too
match,
with
sort
of
the
knobs
that
we've
thought
from
the
demand
side
in
post.
Sockets
have
to
be
there
right,
so
this
is
actually
kind
of
cool
because
it
confirms
okay,
these
are
the
things
we
want
to
be
able
to
control
from
up
top.
These
are
things
we
can
control
from
the
bottom
yeah
they
match.
C
M
K
Yeah
I
don't
mind
the
problem,
so
I
roll
of
this
document,
not
not
in
you
know,
presenting
an
alternative,
API
rather
than
say
post
sockets,
but
to
be
able
to
nag
you
people
to
be
able
to
say
you
know
this
functionality.
If
you're
not
putting
this
in
post
sockets,
then
you're
never
going
to
be
able
to
offer
it
on
just
opposite.
You
on
how
we
arrived
at
the
list
and
so
forth.
That's
that's
all!
It
is,
though,
I
think
a
great.
N
Tommy,
probably
yes,
so
I
agree
with
that.
I
think
as
a
as
essentially
the
ACL
is
the
Distilled
interface
right
like
if
we
saw
the
interface
that
you
would
create
from
the
full
usage
document,
and
you
tried
to
make
an
API
out
of
that.
That
would
be
really
terrible
because
it
has
way
too
many
options.
This
is
like
the
distilled
version
which
is
like
actually
think
you
can
think
about,
so
I
mean
to
that
end,
I
mean
we
haven't
responded
yet,
but
I'll
I
think
that
this
should
be
adopted
as
the
working
group
document.
N
If
for
no
other
reason,
then
it's
the
right
starting
point,
and
if
we
have
it
in
the
working
group,
then
we
can
cut
out
things
or
edit
things
properly,
but
it
has
the
right
core.
So
it's
good.
For
that
reason,
just
a
couple
specific
comments
based
on
the
document
and
based
on
the
presentation
here,
the
idea
of
things
falling
back
to
TCP
and
kind
of
requiring
falling
back
to
TCP
I
think
feels
a
little
bit
too
specific.
N
I
don't
know
if
we
could
express
it
as
far
as
saying
that
things
fall
back
to
you
know,
just
like
a
byte
stream,
or
is
that
essentially
what
I
see
what
the
integration
falls
back
to?
It's,
not
really
tea,
TP
specific
it
doesn't
have
like
it's
not
like
I
should
be
able
to
expose
all
the
TCP
options.
It's
just
kind
of
receiving
a
stream
of
data
is
the
fundamental
thing
you're
getting
at.
E
N
There's
no
reason
that
that
min
set
couldn't
work
like
a
TLS
interface
is
very,
very
similar
in
its
a
byte
stream
to
what
you
get
in
TCP
right.
So
essentially,
what
we're
falling
back
to
is
just
a
reliable
stream
of
bytes.
That
is
a
connected
thing
and
so
we're
forcing
UDP
into
this
connected
thing.
So
we're
just
saying:
let's
force
things
into
5-tuple,
connected
streams
of
bytes,
going
back
and
forth
as
the.
A
N
A
So
Michael
Michael
can
say
this
himself
if
he
feels
that
way,
but
it
but
I
think
the
idea
of
calling
it
a
the
thinking
of
this
as
a
minimum
set
is
to
saying
you
know
a
TCP,
you
know,
but
also
other
things
I
mean.
Would
you
suggest
that
it
would
be?
It
would
be
acceptable
to
have
an
implementation
that
only
fell
back
to
TLS
and
did
not
fall
back
to
TCP.
N
Sockets
and
says
you
know,
is
the
other
side
of
taps
implementation
or
not
those
areas
I
find
a
little
bit
confusing
or
that
they
go
a
little
bit
too
much
into
the
detail
of
how
this
is
actually
going
to
be
deployed
and
how
the
interface
is
used
and
I'd
like
to
see
this
potentially
removed
from
the
min
set.
I,
don't
know
Michael.
What
do
you
think
about
that?.
K
Yeah,
so
there
are
I,
mean
III
I,
see
a
point.
I
see
that
you
want
you're,
gonna
have
to
set
up
yeah
at
a
higher
layer
and
then
somehow
move
to
TLS.
If
you
want
to
some
of
the
stuff,
that's
there,
it's
gotta,
be
there
just
explain
how
things
are
gonna
work
so,
for
instance,
is
I
mean
I
can't
you
know,
allow
hiding
screenings
and
I.
Have
this
abstraction
and
talk
about
different
varietals
know
that
without
deigning
how
that
could
potentially
work?
We
were
thinking
of
doing
another
draft.
K
K
N
K
Not
the
minimum
set
that
you
want
to
add
this
functionality
and
make
it
a
bit
more
dependent
on
the
protocol
because
the
application
and
makes
a
decision
to
say
okay,
it
tells
me
that
it's
modified
stream
and
then
have
to
do
something
differently,
and
you
put
this
in
the
API
edit
functionality
if
you
want.
But
so
this
means.
A
A
O
Mr.
Dawkins
says
responsibility
director.
The
thing
that
I
would
ask
the
working
group
is
whether
it's
going
to
help
this
document
to
be
adopted
as
a
working
group
draft,
which
is
basically
saying
that
the
document
is
stable
enough
for
the
working
group
to
work
on
it,
rather
than
have
an
individual
make
the
right
choices
really
quickly
from
version
to
version
and
whether
you
know
whether
or
not
whether
people
are
committing
to
work
on
it
as
opposed
to
watching
the
authors
continue
to
type
I.
O
A
P
The
bernstrom
so
I
think
it's
a
good.
The
document
is
a
good
starting
point,
so
I'm
for
adopting
and
I
think
was
a
Spencer
was
hinting
to
it's
important
to
have
it
in
the
working
group,
because,
even
if
we
say
this
is
an
abstract
interface,
once
we
build
the
API
on
top
of
it,
they're
going
to
have
to
match
so
I
mean
that
what
we
still
have
choices
here
in
terms
of
what
we
include
in
this
minimal
set
and
how
interpret
it
and
that
interpretation
we
need
to
match
with
what
comes
on
top
of
it.
D
Look
Feazell
I,
really
like
the
document
that
Reluctant
Alice's
in
the
panics.
What
I
fear
is
that
the
kind
of
minimal
set
interface
is
limiting
something
built
on
top
of
that
and
I
think
there
has
been
some
care
taking
to
be
taken
to
make
sure
that
this
don't
happen,
that
this
means
that
doesn't
really
limit
something
like
post
sockets
built
on
top
are
extending
it
so,
except
that,
except
that
problem
I
think
we
should
really
work
on
that
and
make
sure
that
this
doesn't
happen.
Otherwise,
I'm
proud,
nothing.
K
D
J
K
I
mean
III
would
agree
it
shouldn't
it
shouldn't
limit
the
API
on
top,
but
how
do
you
think
it
might
limit?
Because
you
know
we
happen?
I
mean
the
procedure
that
if
you're
at
the
appendix
is
about
avoiding
limitations
that
arise
from
exposing
certain
functionality
that
ties
it
to
one
specific
protocol
and
so
forth,
and
then
you
know
the
automatable
features
you
can.
You
know
just
because
we
move
them
away
to
be.
The
minimum
set
doesn't
mean
that
you
can't
expose
them
so
in
which
way
is
this
limiting
I
hope
you
shouldn't
be.
D
So,
where
I
see
the
biggest
limitation
is
in
having
the
same
frame
and
receive
receive
scream,
abstraction
and
I
think
it's
hard
to
just
fix
this
in
something
extending
it.
The
the
question
is
how
to
go
about
that,
but
I
think
this
can
be
part
of
a
discussion,
okay
off
the
draft
within
the
working
group
and
not
before
adoption.
So.
Q
Colin
Perkins,
so
I'm
I
I
definitely
agree
that
this
should
be
adopted.
Coming
back
to
I,
think
the
comments
Tommy
was
making
earlier
and
the
the
questions
about
fallback
and
so
on.
It's
not
clear
to
me
why
things
like
fall
back
should
be
mentioned
in
this
draft
at
all.
You
know:
are
they
not
a
higher
level
policy
thing
you?
You
could
use
this
minimum
in
sets
to
build
an
API
that
didn't
do
any
type
of
fallback,
so
you
know
I
think
we
should.
Q
K
Q
K
M
Cairo's
yeah
I
mean
I,
see
this
as
a
as
a
choice
that
was
made
in
the
in
in
you
know.
Coming
up
with
this
draft
was,
was
we
decided
that
TCP
was
the
was
the
most
widely
deployables
port
and
so
anything
that
wants
any
application?
That
wants
to
be
most
widely
deployables
ET
p
as
a
fallback-
and
maybe
that's
not
true,
but
I
think
that
was
the
it
sounds
like
that
was
the
assumption
that
went
into
this
anyway,
I'm
in
favor
of
adoption,
so
I
don't
want
to
deliver
it.
R
About
mascots
HD
consulting
in
the
security
arena,
sometimes
we
look
at
UDP
is
our
fallback
because
he
can't
get
anything
through
and
in
a
DDoS
situation.
You
have
to
do
like
what
dots
has
to
do
is
singling
maybe
do
a
singling
just
fine
on
TCP
when
things
are
working
well
and
then
things
go
in
in
a
handbasket
in
the
network
and
then
your
fallback
is
UDP,
not
TCP.
R
So
that's
one
thing
that
I
like
to
comment
I'm
find
it's
interesting
to
follow
new
here.
The
other
thing
is:
is
that
looking
at
this
comments
earlier,
I
remember
a
conversation,
a
recent
here
with
John
Clemson,
who
lived
the
OSI
funding
games
and
much
of
the
OSI
work
died
because
of
complexity
and
the
whole
thing
about
what
TCP
was
about
was
for
simplicity.
So,
as
underlying
calls,
this
looks
really
interesting,
but
if
they're
not
be
with
the
application
sees
that
you
need
to
somehow
get
to
a
more
simplistic
application,
API
model.
This
is
really
great.
K
R
And
the
final
thing
I'd
like
to
say
is
that
the
other
day
I
work
with
in
highly
constrained
networks
and
highly
constrained
devices
more
constrained
than
what
I
tends
to
deal
with
I
can't
afford
IP
and
TCP
I'm
just
doing
direct
messaging
like
on
canvas
FB.
We
only
have
64
bytes
for
my
MTU.
So
if
I
had
something
like
this,
that
the
application
would
use
and
then
it
just
kind
of
like
wrapped
it
up
and
send
it
across
to
the
Gateway,
which
then
puts
everything
on
or
would
that
be
a
win
in
those
environments.
Q
Cohen
Perkins,
just
just
to
follow
up
on
that.
A
little
I
agree
we
should
aim
simplicity
is
in
API
is
a
good
thing,
but
but
we
should
be
realistic
about
what
the
current
API
is.
This
looks
like
you
know.
If
you
turn
this
into
suck
options
and
yeah
sakis
API
calls,
this
looks
like
exactly
what
you
would
write
a
lot
of
applications
today.
S
Vp
Julian
creep
the
broad
thank
you
I'm.
Sorry
Mission
Control
I'm
newbie
here.
So
my
question
is
a
series
interface,
look
like
a
rock-solid
synchronous,
interface
and
application
should
call
this
functions
for
to
get
to
the
tabs
no
transport
services
to
work.
So
what
about
a
synchronous
interface
for
application?
It
may
be
a
good
reason
to
send
some
callbacks
what
you
receive
and
sent
for
application,
and
the
application
automatically
can
receive
data,
not
too
cool
in
these
functions
at
all.
K
Yeah,
so
this
is
nothing
justifying
a
concrete
API.
It
is
a
list
of
services,
I'm,
sorry
for
having
created
the
confusion
by
calling
it
API.
I
can
see
that
now
older
people
tend
to
look
at
it
as
an
API
that
you're
going
to
implement
and
use
like
that.
This.
This
document,
together
with
its
producing
document,
is
analyzing
TCP,
UDP,
UDP,
light
SCTP,
no
MP,
TCP
and
figuring
out
what
other
service
isn't
done,
having
a
way
of
reducing
some
and
then
as
part
of
the
process
as
part
of
how
I
decided
to
make
it
say.
K
Well,
if
you
want
to
be
able
to
fall
back
to
TCP,
for
example,
then
this
is
what
you
end
up
with
it's
just
that
it's
just
this
analysis
and
not
more,
and
it
has
the
role
of
being
able
to
influence
API
design
decisions
to
say
if
you
want
to
add
all
the
functionality
that,
for
instance,
isn't
a
protocol
office.
But
you
got
to
do
this
if
you
want
to
be
able
to
fall
back
to
TCP.
Well,
you
have
to
do
this.
I
could
have
made
a
fallback
to
UDP,
it
would
have
made
document
longer.
K
A
Yes
or
no,
so
the
first
is,
if
you're
in
favor
working
group
adopting
this
item,
please
hum
if
you're
opposed
to
the
working
group
adopting
this
item,
please
hum:
okay,
I
think
I
heard
one
person
hum
against
and
maybe
a
few
dozen
hum
in
favor
of
so
that
sounds
like
a
rough
consensus
and
those
I
think
a
lot
of
very
good
feedback
that
came
in
the
discussion.
Hopefully,
we've
got
some
of
that
in
them
in
the
notes
check
the
ether
pad
to
make
sure
that
your
comments
are
recorded
and
and
I
guess.
A
J
A
J
A
U
C
Sorry
yeah
good
morning,
everyone,
my
name,
is
Chris
wood,
I'm
from
Apple,
and
so
we're
gonna
be
talking
about
security.
Stuff
I
was
not
at
the
last
taps
meeting,
unfortunately,
in
which
the
concern
of
a
lack
of
security
assessment
in
the
api's
was
brought
up,
and
so
Tommy
took
an
action
item
to
go
and
look
at
the
landscape
and
see
what
different
transport
security
protocols
are
in
use
for
today,
what
kind
of
features
they
provide
and
how
we
can
kind
of
abstract
them
in
a
taps
like
way.
C
So
this
is
our
discussion
of
that
next
slide
please.
So
the
goal
is
relatively
simple:
we
wanted
to
end
up
in
a
place
where
we
have
a
minimum
interface
of
sorts
for
any
kind
of
transport
security
protocol
and
waving
air
quotes,
in
which
we
could
slide
in
different
implementations
underneath
API
and
to
get
to
that
goal.
C
We
had
to
go
out
and
look
at
everything
that
was
in
use
and
try
to
look
at
them,
not
from
the
contexts
or
not
in
the
lens
of
just
a
you
know,
a
big
transport
security
protocol,
but
breaking
them
down
into
their
different
constituent
parts.
So
I
see
us,
for
example,
has
both
a
handshake
protocol
and
a
record
protocol
in
it
and
try
to
like
decoupled
protocols
based
on
long
those
lines,
and
so
we
did
exactly
that.
We
looked
at
a
set
of
popular
transport
protocol
or
transport
security
protocols.
C
It's
not
exhaustive,
so
I
mean
if
you
have
suggestions
for
things
that
we
can
include,
or
look
at,
be
very
happy
to
see
those
X
Y,
please
so
like
I
was
saying.
There's
this
general
notion
of
what
a
transport
security
protocol
is
it's
this
thing
that
provides
some
security
features
and
these
protocols
can
work
alongside
transport
protocols
like
TLS
is
built
on
top
of
TCP
and
so
on.
But
ideally
we
were
able
to
decompose
these
into
you
know
sub
or
constituent
parts.
C
So
for
the
purpose
of
this
work,
we
focus
specifically
on
what
we
call
a
handshake
protocol
and
a
record
protocol
borrowing
from
TLS,
because
it's
common
language,
so
a
handshake
protocol
is
just
a
security
protocol
that
performs
a
handshake
and
negotiation
of
sorts
and
hopefully
pops
out
a
shared
key
between
two
endpoints
and
a
record
protocol
is
something
that
uses
that
share
key
to
encrypt
datagrams
or
messages
back
and
forth
between
the
two
endpoints
thanks.
Why?
C
Please-
and
so
one
interesting
task
in
this
particular
endeavor
was
to
look
at
the
different
components
and
see
how
they
interact
from
an
interface
perspective.
So,
for
example,
in
TLS,
you
have
again
a
handshake
protocol
on
a
record
protocol
internally
and
shake
protocol
will
use
the
record
protocol
to
encrypt
both
handshake
messages
and
application
data
and
sent
over
the
wire.
So
the
handshake
uses
the
record
and
the
record
uses
the
transport
send
the
data
in
more
modern
or
newer
protocols.
C
But
regardless
of
you
know
what
the
role
or
relationship
is
between
these
two
different
or
these
components
in
a
particular
protocol,
the
features
in
each
part
are
fairly
common,
though
there
are
patterns
that
exist
across
all
of
these.
So
next
slide.
Please,
for
example,
the
handshake
protocol,
typically
as
a
variety
of
very
common
things.
It
will
provide
a
way
to
specify
private
key,
for
example,
to
do
signing
operations
or
what
have
you
authenticate?
C
C
I
saw
I'd
record
protocol
will
then
take
that
shared
secret
use
it
to
encrypt
packets
and
send
it
to
the
other
end,
and
so,
if
you
think
of
this
in
the
context
of
IPSec
with
ICANN
ESP,
that's
fancy
ESP
just
takes
a
key,
is
input
basically
encrypts
data
grants
and
some
of
the
other
side,
it's
very
simple.
It
doesn't
do
a
whole
lot.
So
the
set
of
features
provided
by
this
particular
module
is
relatively
minimum.
I
would
say,
and
then
next
slide.
Please
and
the
transport
features
I've
already
been
described
in
our
CA
o
95.
C
So
what
we
wanted
to
do
was
by
identifying
these
three
constituent
parts
again
look
at
the
different
transport
security
protocols
that
are
out
there
and
kind
of
overlay
them
on
top
of
the
protocols
in
existence.
So,
for
example,
if
you're
the
next
slide,
taking
TOS
as
an
example
and
seeing
which
parts
are
responsible
for
the
actual
handshake
portion
of
the
transport
security
protocol,
which
parts
do
the
record
stuff
and
which
parts
actually
do
the
tcp
stuff
and,
of
course,
with
the
TLS,
is
the
main
example.
C
The
overlay
is
really
typically
straightforward,
because
there
already
exist
a
handshake
and
a
record
protocol
internally.
So
no
this
should
be
new
to
anyone
or
surprising
to
anyone.
The
AUSA's
built
on
top
of
TCP
is
its
reliable
transport.
Underneath
there's
inject
mechanism
that
starts
a
connection
sets
keys
to
arts,
gives
the
record
protocol
keys
to
start
encrypting
application
data
and
handshake
messages,
depending
on
which
resent
to
us
we're
using,
and
the
record
protocol
will
occasionally
error
out
through
the
handshake
protocol.
C
If
something
bad
happens,
like
a
you
know,
a
particular
record
fails
to
be
decrypted
properly
and
authenticated
the
handshake
protocol.
Well,
then,
possibly,
during
the
negotiation
process,
provide
information
up
to
what
I'm
calling
this
connection
kind
of
layer,
which
is
essentially
the
API
to
the
protocol
and
potentially
beyond
to
the
application
yeah
area.
C
Most
TLS
implementations
will
not
have
like
an
API
directly
to
the
record
protocol.
You
just
have
this
generic
TLS
contexts
in
which
you
read
it
right
from
so
it's.
This
is
not
it's
more
of
an
API
level
thing,
so
perhaps
I
should
just
not
have
that,
but-
and
you
can
consider
it
basically,
the
application
in
the
connection
in
the
same
box,
because
the
lines
in
and
out
are
the
same
so
and
another
feature
of
this
particular
variant
is
that
the
application
will
typically
configure
the
handshake
protocol
with
you
know,
for
example,
cipher
suite
set.
C
It
supports
what
signature
algorithms
it
wants
to
provide,
and
you
know
whole
litany
of
other
kind
of
features
that
are
wants
to
enable
or
disable
for
the
purposes
of
particular
connection,
so
Feiler
shape
forward
slide.
Please
and
detail.
Us
is
not
far
off
from
this.
Basically,
it's
TLS
with
some
minor
changes,
particularly
the
handshake
step,
to
ensure
reliability
of
an
check
messages.
Yeah.
C
So,
from
the
perspective
of
the
interface,
that's
provided
by
each
of
these
different
boxes,
it's
basically
the
same.
It's
just
internally,
they
see
jaws,
goes
to
some
additional
links
to
ensure
that
handshake
messages
are
actually
received
by
the
other
and
in
the
correct
order.
But
from
the
perspective
of
the
API,
it's
almost
identical.
With
the
exception
like
you
can't
have
messages
in
datagrams
arrived
or
yeah
on.
L
The
only
finger
is
so
low
confusing
here
the
reliability
layer
doesn't
make
a
distinction
between
the
handshake
versus
the
application
data
because,
obviously
like
the
whole
purpose
is
to
have
the
application.
They
are
a
sent
unreliable,
yeah,
of
course,
there's
also
the
Aramis,
which
is
typically
public
in
many
cases,
to
the
application
layer.
So
I'm
kind
of
lumping
that
into
the
callbacks
line.
C
Yeah,
so
these
diagrams
can
very
much
be
improved.
I,
don't
claim
perfection
on
any
of
this,
but
yes
thank
you
for
pointing
that
out.
There's
a
distinction,
as
Kyle
actually
pointed
out
to
me
yesterday,
in
a
conversation
that
a
reliability
and
order
ernest
is
guaranteed
for
the
handshake
packets,
not
necessarily
so
for
the
applications.
Again,
that's
the
whole
point
of
Datagram
security
protocol
next
slide.
C
C
C
But
the
point
here
is
that,
in
contrast
to
TLS,
where
in
the
handshake
protocol
and
the
record
protocol
very
tightly
coupled
quick,
decouples
them,
for
the
purposes
of
you
know
simplifying
things
from
a
construction
perspective.
But
it
also
is
nice
from
the
kind
of
analysis
perspective,
because
you
could,
in
theory,
run
quick
with
just
a
PS
k
that
you've
derived
out
van
doesn't
need
to
be
the
one.
That's
the
same:
exchange
through
TLS
and
you'd,
be
just
fine
next
slide,
so
TCP
crypt
is
another
one.
C
We
looked
at
and
it's
great
because
it's
extremely
simple
key
exchange,
it's
kind
of
baked
right
into
the
TCP
layer
itself.
How
long
would
the
encryption
so
nothing
really
fancy
going
on
here.
You
offer
up
support
for
TCP
crypt,
do
a
key
exchange
right
after
and
start
encrypting
all
your
TCP
packets
or
segments
so.
C
Mineral
tea,
not
an
IETF
standard
or
protocol,
those
an
interesting
one,
to
say
at
least
again
also
follows
this
very
common
pattern.
If
you're
not
familiar
with
the
basic
design,
it.
C
It
merges
and
blends
many
different
things:
it's
a
transport,
a
circular
transport
protocol,
built
on
a
assumption
that
there
exists
a
directory
service
from
which
to
obtain
keys.
So
how
you
actually
derive
showed
secrets
and
do
a
handshake
is
a
little
bit
different
from
TLS,
but
the
the
basic
going
from
from
the
application
perspective
actually
starting
to
send
encrypt
the
data,
hopefully,
though,
and
is
very
similar
to
all
the
other
protocol
sort.
C
So
if
you
wanted
to
speak
to
a
particular
server,
you
would,
if
you
don't
already-
have,
for
example,
the
long
or
the
thermo
public
key
of
this
particular
service
to
do
a
key
exchange.
You'd
have
to
go
this
directory
service
to
get
this
public
key,
and
you
open
up
a
tunnel
through
this
directory
service.
C
Get
this
information
use
that
to
open
up
a
tunnel
to
the
other
end
server
that
you're
talking
about
doing
key
exchange
there
and
then,
once
you
have
the
shared
secret,
you
just
start
basically
sending
packets
back
and
forth
over
UDP,
with
some
kind
of
reliability
to
deliver
a
layer
built
on
top
of
UDP
to
ensure
that
things
get
from
end
to
end.
In
any
order,
so
again
we
see
the
same
exact
patterns
with
respect
to
what
the
different
pieces
of
the
protocol
are
providing.
C
So
we
can
decouple
these
and
and
separate
them
as
needed.
I
will
say,
though,
that
the
middle
T
is
also
interesting
in
that
the
API
for
applications
is
not
necessarily
the
same
as
TLS
where
you
have
like
this
Connie
was
saying
earlier.
This
byte
stream,
like
API
or
TCP
like
he'd,
be
odd
to
extract
it
up
if
Manila
T
depends
or
exposes
an
RPC
like
API
or
clients
will
just
send
our
pcs
over
to
the
server
and
expect
the
response
back.
C
You
know
I,
not
gonna,
try
to
rationalize
the
use
of
that
particular
API
I
mean
it
was
designed
for
a
very
particular
purpose,
but
here
in
taps
we're
trying
to
maintain
this
TCP
like
API,
so
I
mean
you
could
very
well
do
a
minimal
T
like
thing
without
our
pcs
like
it's,
that's
not
a
hard-and-fast
requirements.
Just
that's
something
interesting
to
point
out
as
a
differentiating
factor.
So.
C
A
DJB
mechanism
or
djv
protocol-
and
it's
I
mean
they
have
some
I,
forget
the
name
of
the
project
but
they're
using
it.
Within
the
context
of
this
one
research,
our
funded
research
project
has
not
seen
widespread
deployment,
I
see
yeah
and
next
so
and
then
I
can
ESB
for
IPSec.
I
can
very
similar
and
I
would
say
one
of
the
nicer
of
the
variants
and
that
there
is
a
very
clear
distinction
of
the
roles
of
every
single
this
ecosystem.
C
You
have
bike,
which
is
a
key
exchange
protocol
used
to
derive
secrets
that
ESP,
which
is
a
encapsulation
protocol
for
packets,
to
send
them
over
the
wire
using
a
specific
delivery
mechanism,
which
is
just
IP
in
this
case,
and
so
somewhere
to
TLS
and
other
handshake
protocol.
You
configure
it
a
certain
way
and
then
I
could
just
shovel
off
all
the
secrets
that
it
uses
there
drives
over
its
ESB
to
actually
handle
encrypting
and
decrypting
datagrams,
and
the
application
would
just
interact
with
it.
Much
like
it
would
with
us.
C
Q
High
competence,
just
before
you
move
into
that,
want
one
suggested
addition
for
the
previous,
which
is
that
security
P
is
a
record
protocol
which
is
usually
having
keyed
with
DTLS
yeah.
The
the
issue
here
is
that
the
record
protocol
is
different
in
that
it
does
partial
encryption
of
the
packets
yeah.
C
So,
as
IP
was
one
thing
that
we
may
do,
we
need
to
include
yes,
it
is
kind
of
so
there's
that
one
feature
which
is
missing
from
the
others
that
you
corrected
yeah
yeah.
Certainly
if
there
are
other
candidates
as
well,
we
can
include
them
yes
or
to
list.
But
yes,
there
are,
for
each
of
these
I
think
we
ran
into
little
tiny
details
that
were
not
necessarily.
C
N
All
right,
thank
you,
Chris,
so
I'll
try
to
just
go
quickly
through
this
I
want
to
first
just
present
kind
of
what
we
distilled
as
the
list
of
interfaces.
How
we
grouped
them.
You
can
look
at
the
full
list
in
the
draft,
but
the
point
is
tries
to
try
to
see
how
the
shape
of
these
transport
security
interfaces
matches
up,
with
the
shape
that
we've
derived
for
the
usage
documents
for
transport
and
maybe
see
how
that
would
apply
to
things
like
minimal
set.
N
Some
API
is
going
forward
excite,
please
all
right,
so
there's
a
whole
category
of
interfaces
that
totally
fall
into
the
configuration
category.
These
are
all
generally
just
presumably
from
the
application
to
the
security
layer,
but
you
really
shouldn't
have
to
care
it's
just
kind
of
like
application
into
connection
and
that's
setting
up
your
keys.
That's
setting
of
your
algorithm
preferences
doing
session
cache
explaining
how
you
can
get
authentic
Asian
delegation
to
do
trust
evaluation
from
the
application
level
up.
That's
required,
so
those
are
pretty
simple.
N
N
The
handshake
can
talk
to
the
transport
to
send
and
receive
that's
very
simple,
and
it
talks
to
its
record
to
do
the
setting
of
the
keys.
Most
of
those
could
probably
be
completely
implicit
to
an
implementation
and
don't
really
need
to
be
part
of
any
kind
of
minimal
set
exposure
all
right.
And
finally,
the
record
is
very
simple:
it
receives
keys
from
the
handshake.
It
tells
the
handshake
that
things
have
expired,
that
it
needs
new
keys.
It
can
interact
with
the
transport
to
encrypt
and
decrypt,
and
also
get
interactions
about.
Do
I
need
to
migrate.
N
My
keys
to
a
different
set
of
addresses
in
case
there's
mobility
there
again
most
of
these
should
be
hidden
generally,
potentially
with
the
exception
of
the
transport
mobility,
because
if
you
have
a
mobility
interface
up
from
the
taps
level,
that
may
apply
all
the
way
down
into
the
record.
So
next,
alright,
so
I
didn't
list
these
out.
N
But
this
is
essentially
the
boxes
that
the
existing
usage
documents,
which
are
now
in
going
off
into
their
nice
crystallized
form
have
so
they
have
connection
interfaces
and
data
interfaces
and
those
are
individually
broken
down
into
establish
maintenance
and
termination
for
the
connection
state
and
sending
receiving
errors
for
the
data.
So
this
all
of
the
transport
protocols
seem
to
fall
cleanly
into
this,
and
so
the
question
is:
when
we
looked
at
these
security
interfaces,
do
they
fit
into
these?
N
Do
we
have
kind
of
entirely
new
categories
that
we
need
and
how
would
that
change
the
API
and
then
beyond
that,
because
I've
listed
in
the
interfaces,
how
the
security
layers
and
the
transport
layers
interact?
How
useful
is
that
to
define
that
layer,
or
do
we
really
only
want
to
talk
about
kind
of
what
goes
up
to
the
application?
N
So
that's
a
question
I'd
like
to
hear
your
feedback
on
so
here's
one
way
of
overlaying.
Some
of
the
interfaces
from
security
I
only
did
a
subset
of
them
that
were
interesting
to
give
representative
ideas,
so
certain
things
very
clearly
fall
into
the
establishment
phase.
If
I
need
to
set
up
my
identity
set,
my
algorithms,
that's
very
similar
to
setting
any
other
option
on
a
transport
connection.
You
just
do
that
from
the
application
down
into
the
protocol.
N
There
are
other
parts
of
establishment
that
ideally
would
be
implicit
to
starting
your
transport.
If
you're
say
I
want
this
connection,
the
transport
layer
can
just
kind
of
signal
over
the
security
yeah.
You
got
to
set
your
handshake
once
I
get
TCP
up,
so
you
can
do
Els,
hopefully
that
the
that
lighter
gray
box
doesn't
need
to
be
exposed.
N
Saying
goes
for
all
of
the
record
level,
things
that
are
happening
on
the
data
path,
I
believe
looking
at
those
interfaces
that
those
should
be
essentially
overlapped
with
what
we
already
have
in
the
send/receive
and
error
cases
today
in
the
usage
document
in
the
mid
set
certain
things
like
I
mentioned
before
handling
the
mobility
of
addresses
and
interfaces,
it's
very
much
a
maintenance
thing
that
you
probably
do
need
explicitly
somewhere
in
in
the
interface
and
then
the
weird
ones.
At
least
they
seemed
odd
to
me
looking
over.
N
This
were
the
things
like
identity,
validation
or
source
address
validation,
which
are
traditionally
up
calls
from
the
security
layer
into
the
application,
and
they
can
happen
during
establishment,
or
they
can
happen
later
on,
is
essentially
a
cry
for
help
from
the
security
layer
and
at
least
I
was
looking
through
the
use
of
document.
I
didn't
see.
Many
other
cries
for
help.
I'm
currently
in
transport,.
M
So
a
clarification
question
on
sourcing
cross
validation.
Here
you
really
mean
the
lower
layer
has
either
some
change
in
the
source
address
or
a
source
address
that
you
might
be
doing.
White
listing
or
black
listing
at
the
a
player.
I
M
Like
is
this
guy,
okay,
or
what's
the
it's
so
to
verify
it's
not
about
validating
that
a
source
address
on
an
incoming
packet
is
actually
tied
to
like,
actually
is
where
it
is
right.
This
is
nante
spoofing.
This
is
a
higher
layer
thing
than
that
right,
Chris.
What
Apple
is
like
the
details,
cooking
mechanism.
M
N
N
N
Okay,
so
that
was
that
all
right
next
slide
all
right,
so
this
is
the
last
slide
I
like
to
pose
some
questions
here,
so
some
of
them
are
more
administrative
things
like
do
these
security
interfaces.
Do
they
belong
in
a
common
main
interface
like?
Would
it
make
sense
to
have
the
something
like
the
min
set
or
a
draft
off
of
the
min
set
include
security
in
kind
of
the
main
interface
that
we
would
expose?
N
Or,
alternatively,
you
do
more
like
what
a
lot
of
api's
do
today
in
which
you
have
your
nice
transport
layer
and
then,
presumably,
the
application
uses
another
layer
that
adds
the
security
as
an
overlay
to
it,
I
think
with
the
direction
for
pro
sockets.
We
would
like
to
see
those
things
combined,
so
you
have
security,
implicit,
but
certainly
one
could
have
it
as
an
overlay.
Come.
R
On
masks,
coats
I've
actually
been
working
on
this
particular
area
for
a
couple
years:
Sisu
hairs
and
my
drafts
about
secure
session
layer
services
in
my
secure
session
envelope,
and
because
there's
no
more
drivers
like
I,
said
I'm
dealing
with
with
with
Mac
Phi's,
where
you
don't
even
talk
about
running
IP
on
them
and
I'm
Dee
I'm,
also
dealing
with
environments
where
the
the
network
are
totally
totally
down
down
down
the
tubes.
So
one
of
the
things
that
I
see
here
that
you
may
want
to
change
some
of
your
wording
because
it
changes
semantics
significally.
R
You
use
your
inheriting
the
word
handshake
from
TLS
and
others.
This
is
the
control
channel
change
your
wording
for
handshake
to
control,
Channel
sure.
Then
you
can
start
talking
about
the
control
channel.
It
actually
does
more
than
just
security.
Security
may
protect
other
things.
You
need
to
do
in
exchanges
between
the
the
peers
of
the
communication,
but
there
are
other
functions
which
then
become
and
inherit
them
in
here
into
the
control
channel.
Besides,
just
security
or
security
protects
these
things
that
you
need
to
do,
but
you
but
talk
about
this
as
a
control
channel.
R
I've
been
working
at
this
for
quite
some
time
and
we're
not
transport
people
per
se,
but
that
we're
not
totally
ignorant
either
and
some
of
the
ways
to
do
this
in
saying.
What's
what
services
do
we
want
to
provide
in
this
sort
of
thing
so
that
oh
gee
I
can
do
these
in
these
environments?
I
can
provide
these
ApS
and
in
it,
and
the
other
thing
that
I
finally
like
being
able
to
say
as
I'm,
also
working
identity
or
into
networking.
R
We
have
the
ideas
pop
on
Wednesday
I'm,
the
author
of
hip,
which
is
one
of
the
main
identity
based
environments,
and
one
again
there
is
I'm
working
at
is
moving
the
identity
discussion
up
into
the
application,
not
just
in
the
network
and
how
that
thing
can
apply
there.
Can
you
talk
about
identity
in
here,
and
this
is
one
the
other
areas
which
again
we're
looking
at
and
thus
the
higher
layer
of
decoupling.
We
can
then
get
when
we
have
an
identity
organization
in
this
way.
R
N
R
M
High
paradigm,
also,
if
they
can
paraphrase
the
very
beginning
of
bolts,
comment,
the
answer
to
the
first
question
is
yes
and
bed
security
in
the
main
interface.
Yes,
all
right.
So
when
you
start
talking
about
you
say
you
can
take,
go
away
from
handshake
and
go
to
a
control
channel
which
I
actually
I
like
I,
agree.
M
That
seems
like
a
good
way
to
go
now:
you've
embedded
into
the
main
interface,
because
you're
you're,
sort
of
learning
that
line
between
control
and
control
right,
but
that's
I,
think
that's
a
good
thing
from
a
document
standpoint
from
the
documents
come
out
of
this
working
group
like
if
we
take
this
work
and
and
do
it
within
taps
which
I
think
which
I
don't
see
that
question
up
here.
Were
you
gonna
ask
that
question?
M
Be
a
good
idea,
the.
M
So
the
so
the
issue
here
is
that
we
we
basically
kind
of
pointedly,
decided
to
ignore
security
at
the
beginning
of
the
whole
taps.
Things
like
we
have
no
idea
what
we're
doing
and
now
you
bring.
This
document
does
and
bring
this
document
in
and
now
it
looks
like
we
do
kind
of
know
what
we're
doing
and
I
really
like
the
framing
of
this
document.
I
think
that
we
need
to
say
something
about
it.
M
M
A
Q
:
Perkins,
so
yeah
I
think
this.
These
are
great
drafts
and
it's
really
good
that
we
we
have
this
coming
out
in
some
of
the
question
about
main
interface
or
not
I
think
we,
we
should
perhaps
have
a
discussion
about
what
the
main
interface
should
be
and
whether
we
need
lower
interfaces
as
well.
I
think
I.
Q
I
so
I
think
for
the
at
the
interface
to
the
applications.
I
think
this
should
be
part
of
that
interface,
but
I
see
things
like
min
sets
and
this
as
being
separate
interfaces
below
that,
because
I
think
people
building
new
transports
will
want
to
know
what
the
interface
to
the
security
protocol
is.
Okay.
So,
if
you're
building
a
new
transport
protocol,
a
new
record
layer,
a
new
control
Athens,
here's.
Q
Actually,
I
think
the
nice
bit
of
the
work
that's
coming
out
of
this
is
that
we're
we're
digging
into
and
separating
out
the
api's
for
the
different
parts
and
getting
an
idea
what
the
inception
be
of
those
API,
sir,
so
I
think
keeping
those
separate
at
a
certain
level
and
then
layering
something
above
them
to
say.
This
is
how
you
build.
A
complete
system
is
potentially
a
good
idea.
E
N
N
Q
Perfect,
the
other
thing
which
again
I
suspect
is
out
of
scope.
Is
that
we're
meeting
in
parallel
with
Park,
but
the
perk
working
like
and
what
perk
is
doing
is
is
multi
levels
of
encryption,
so
you
can
have
semi
trusted
middle
boxes
as
part
of
the
transports
and
again,
I
would
assume
that
type
of
security
model
is
out
of
scope
for
this
and
we're
just
building
the
base
layer
of
encryption.
But
I
could
see
that
potentially,
as
a
composition
of.
A
A
O
Mr.
Dawkins
so
responsible
area,
director
I'm,
remembering
roughly
what
Aaron
is
remembering
with
the
additional
thing
that
basically
do.
People
in
taps
know
enough
about
security
to,
or
you
know,
to
do,
to
focus
on
that
first
and
since
there
seems
to
be
a
sea
change,
and
you
know,
the
ability
of
taps
to
focus
on
security
I
would
be
thrilled
if
it
turned
out
to
be
necessary
to
do
a
charter
change.
I
would
be
thrilled
to
do
that.
O
L
T
M
What's
what's,
let's
go
to
the
charter
high
for
in
Toronto
taps
is
not
chartered
to
perform
detailed
security
analysis.
There's
these
security
aspects
of
transport
protocols,
.
well,
security
can
be
a
transport
service.
Taps
is
being
charted
almost
simultaneously
with
TCP
Inc,
which
is
developing
the
TCP
extensions
to
provide
unauthenticated
encryption
and
integrity.
Protection
of
TCP
streams
and
taps
will
work
with
TCP
Inc
to
ensure
the
tabs
will
be
able
to
accommodate
the
protocol.
Extensions
that
TCP
Inc
provides.
So
we
have
an
independent
clause.
M
Vs
dependent
clause
interpretation
problem,
any
second
amendment
fans
in
the
room.
If
you
read
the
first
sentence
in
in
of
its
own,
then
very
very
clearly.
This
work
is
completely
out
of
scope
and
and
it's
not
on
shorter.
If
you
read
the
whole
paragraph,
it's
totally
thin.
It's
completely
on
charter,
so
literally
bringing
a
tea
speaks
into
race
into
the
exact.
A
Way
so
what
I
want
to
be
very
concrete
and
pragmatic
and
the
tea
speaking
chair
standing
behind
you?
But
what
I
want
is
that
when
we
submit
these
drafts
to
the
IAS
G
is
for
the
security
area
directors
not
to
put
a
hold
on
them
and
say
you
guys
said
you
aren't
going
to
do
this,
and
so
I
think
that
we've,
just
in
in
chairs
opinion,
I,
think
that
we've
got
a
critical
mass
of
people.
Who've
got
energy
and
expertise
who
want
to
work
on
this.
We're
not
plowing
any
new
ground.
A
It
seems
to
me,
like
it's
low
risk,
but
I
think
that
there's
maybe
a
little
socialization
task.
That
I
would
like
to
ask
our
area
directors
to
do
to
just
get
some
confirmation
and
I'm
willing
to
to
proceed
on
an
optimistic
path.
Assuming
that
you
know
we're
all
working
in
a
spirit
of
goodwill
here
and
trying
to
do
the
things
so.
M
M
Well,
I
think
that
there
that
there's
increased
scope
for
security,
I
think
and
that
there's
there
are
people
basically
I'm,
not
entirely
sure
what
I'm
trying
to
say
but
there,
but
we
want
to.
We
need
to
include
security
as
a
first-class
element
of
taps
and
I.
Don't
know
that
it
makes
sense
to
I
think
we
we
sort
of
presumed
and
I
wasn't
around
during
the
during
the
working
group
chartering,
but
I
think
it
sounds
like
we
presumed
that.
Oh
we're
just
going
to
make
use
of
the
ccpn
thing.
M
A
C
C
A
K
Okay,
I'll
speak
as
someone
who
was
there,
the
Charter
was
made,
and
that
was
much
about
getting
the
whole
thing
off
the
ground
and
avoiding
complications
with
not
having
it,
not
enough
security
expertise,
he's
peeing
happening
in
parallel.
We
can't
get
this
right
and
so
on,
and
so
on.
My
proposal,
people
just
removed
this
paragraph
and
be
done
with
it.
I
mean
okay,
this
is
specific,
I
I,
don't
see
anything,
but
like
any
reason
to
keep
this
paragraph
at
this
point,
I.
G
O
Yeah
mr.
Dawkins
again
so
I
would
say
that
the
combination
of
where
the
working
group
is
now
compared
to
where
you
were
at
charter
time
and
nothing
has
happened
in
the
past
three
years
to
make
us
think
that
security
matters
less.
So
the
combination
of
those
knots
or
the
combination
of
those
two
things
say
basically
that
doing
this
work
is
the
right.
O
The
right
thing
to
do
and
I
think
taps
is
probably
still
the
right
place
to
do
it
and
then,
like
I,
said
I'm
happy
to
take
a
charter
or
update
forward
that
suppose
that
out,
if
the
working
group
think
that
thinks
that
that's
necessary
in
order
for
you
to
be
able
to
do
the
work
but
but
yeah
so
like
I,
say
I
think
you
know
we
do
the
right
thing,
but
I
think
it's
becoming
more
obvious.
What
the
right
thing
is:
okay,
yep.
R
Mask
was
just
kind
of
echoing
everybody
else
that
the
work
that
I've
been
doing
on
this
I
see
a
clear
delineation
which
can
be
achieved
in
server
and
things
which
can
be
done
to
make
it
clear.
What
are
the
the
interface
is,
such
that
a
security
service
can
then
work
well
with
whatever
the
transports
does
or
are
so
what
taps
will
be
doing
thus
to
better
enable
security
and
then
how
then
the
security
works,
then
proceeds
along
those
lines.
R
A
So,
let's,
let's
conclude
this
discussion
with
a
hum.
The
question
is:
should
the
working
group
adopt
this
work
and
and
if
we
agree
to
do
that,
then
there's
an
implication
that
we'll
go
and
we'll
we'll
make
sure
that
the
Charter
is
adjusted
accordingly
and
and
in
turn,
make
and
publicize
this
to
other
folks
who
would
be
interested
krisily
am
something
yeah.
A
M
A
Okay,
all
right,
let
me
let
me
let
me
back
off:
let's
just
get
a
home
of
whether
people
think
the
security
work
is
interesting.
We
should
continue
to
have
this
conversation,
yes
or
no,
all
in
favor
your
home.
Yes,
anybody
thinks
we
just
shouldn't.
Do
this,
it's
a
bad
idea.
Okay,
so
there's
a
clear
consensus
for
that.
What
the
interested
parties
will
get
together
and
we'll
come
up
with
a
concrete
proposal
on
how
to
move
forward
this.
This
doesn't
work
in
it.
Thank
you.
Thank
you
very
much
for
putting
this
together
Bob.
A
On
to
number
three
I
think
we're
we're
running
a
little
bit
behind,
but
not
irrecoverably.
Are
you
keeping
an
eye
on
the
clock
a
little
bit
we're
pretty
behind
okay?
So
we
have
we
have
an
hour
and
we
ended
12:00
right.
We
have
fifty
minutes
and
we
have
two
presentations
in
a
discussion.
So
let's
try
to
keep
each
thing
to
15
minutes.
If
you
can
get
through
your
stuff
in
15
minutes.
J
G
D
Yeah,
so
next
lackeys,
everything
I
want
to
talk
is
about
inputs
to
transfer
option
selection.
So
if
you
want
to
optima
an
automatic
transfer
option
selection,
what
do
you
need
as
inputs,
and
we
came
a
little
bit
from
the
multipath
or
deciding
which
multiple
interfaces
and
positive
use?
Therefore,
this
might
be
a
little
bit
pointed
towards
this
direction.
D
So,
first
we
need
to
pass
characteristics
to
decide
which,
after
use,
we
might
need
the
needs
of
the
application
so
of
the
most
web
and
was
latency
cost
traffic
characteristic
tolerance
towards
packet
data
and
connection
loss,
and
we
need
a
way
to
decide
how
to
compose
transfer
protocol
stack
and
probably
to
debate
how
to
include
on
pass
elements
and
next
slide.
Please,
the
first
draft,
the
circuit,
intense
traffic,
goes
into
the
application
needs
discussion,
while
the
second
draft
next
slide.
D
Please
goes
into
the
discussion
on
how
to
compose
a
transport
protocol
stack
asclad,
please
so
what
at
saw
intents
so
with
socket
intense
applications.
My
express
their
communication
preferences
in
order
to
take
advantage
of
the
available
transferred
resistor
so
sir,
contains
our
hints
for
transport
option
selection
and
are
not
meant
as
strict
rules,
but
just
into
its
little
intuitive
generic
protocol.
Independent
hints,
given
from
the
application
on
what
they're
going
to
do
with
the
upcoming
communication,
and
they
should
be
matched
in
a
best-effort
way.
D
D
So
what
an
application
programmer
can
express
with
circuit
intent
is
rough
things
like
the
traffic
category.
Are
we
going
to
do
it
ball
transfer?
Are
we
going
to
control
messages?
Are
we
doing
streaming
and
the
various
categories
of
this
can
be,
for
example,
the
object
size
I
expect
to
set
a
receiver
communication
channel,
the
duration
of
the
existence
of
the
communication
channel
yeah
other
constraints
or
cost
preference,
whether
the
application
thinks
this
should
be.
D
If
this
combination
should
take
place
over
an
expensive
link
or
not
next
slide,
please,
and
so
we
see
all
of
this
information
as
inputs
to
transport
option
selection
within,
for
example,
the
tab
system.
Next
slide,
please
so
we
sync
circuit
has
can
be
used
on
a
per
floor
per
association
for
screaming
per
object
level,
and
we
try
really
drop
this
out
on
a
per
stream
and
per
object
level
and
far.
We
have
good
results
with
that
and
socket
intents
are
presumed
to
be
API
independence,
so
we
haven't
VSD,
so
the
based
implementation.
D
That
also
supports
connection
caching
and
we've
done
FEM
thinking
about
whether
this
could
be
included
into
post
sockets,
and
we
think
yes,
it
can
next
slide,
please
so
having
the
information
from
the
application.
The
next
question
is
and
having
the
past
properties,
which
are
all
as
measurable.
The
next
question
is
where
we
can
decide
what
the
passes
of
what
the
endpoints
are,
how
to
decide
to
compose
a
protocol
stack
and
for
composing
this.
D
We
have
to
compare
them
to
find
an
order
on
which
one
to
use,
and
therefore
this
the
second
draft
talks
about
communication
unit
granularity
and
about
how
to
do
this
decision-making.
How
to
reason
about
protocol
stacks
next
one,
please.
The
basic
idea
is
to
decompose
a
protocol
stack
into
two
orthogonal
things.
So,
first,
we
look
about
which
communication
units
are
operated
on
and
second,
which
mechanisms
operate
on
this
communication
units
for
multi
pass,
and
this
perspective
allows
us
to
compare
mechanisms
like
distributing
requests
of
an
application,
so
HTTP
requests.
D
We
have
a
hundred
objects
to
fetch
for
our
website,
how
to
distribute
them
among
two
links
so
just
having
two,
for
example,
TCP
sessions
running
at
HTTP
two
and
distribute
the
objects
that
way
or
to
use
just
one
HTTP
session
and
use
amputee
CP
or
that,
and
so
we
can
can
compare
this
kind
of
approaches
against
each
other
and
reason
with
what
is
the
right
approach
next
slide?
Please!
So
what
are
the
communication?
Ewtn's
were
thinking,
and
the
point
is
protocols
really
align
badly
with
the
communication
units
with
the
semantics
communications
unit
of
an
application.
D
So
we
see
the
communication
screen
units
as
object
or
message
so,
for
example,
an
HTTP
request.
This
dream,
like
a
screamin,
quick
or
SCTP,
are
rtcp
connected
for
exampie
PE,
an
association
or
we
call
the
flow
which
bundles
some
streams
and
an
association
set
of
flow
set
that
bundles
streams,
bundles
associations
that
belong
together
depending
on
the
protocol
stack
and
the
application
use
this
communication,
your
hierarchy
elements
can
just
merge
as
they
like,
and
mechanisms
can
therefore
not
be
sharply
assigned
to
one
of
these
areas
if
they
merge
next
type
is
so.
D
This
might
look
quite
interesting,
see
draft
for
details,
we've
shanking,
so
how
to
from
an
application
level
split
stuff-
and
this
can
be
just
naturally
like
objects
of
websites
already
split
or
can
be
split
by
a
lower
layer
like
TCP,
segmenting
and
scheduling,
which
can
also
seen
as
the
power
of
correct
or
per
trunk
path.
Selection
lets
deciding
how
to
distribute
the
stuff,
and
we
see
with
these
mechanisms
together
with
the
communication
units.
D
Now
transport
stack,
insect
selection
means
just
composing
a
system
from
protocol
stacks
instances
that
implement
these
mechanisms
to
come
through
a
whole
system.
This
is
a
fairly
abstract
and
complex
view,
but
I
think
it's
the
way
you
have
to
go.
If
you
want
to
reason
about
how
to
automatically
compose
stacks
in
a
system,
so
we
have
a
prototype
for
beastie
circuits.
I
already
told
you.
This
is
a
wrapper
for
these
D
circuits.
D
We
have
three
API
variants
and
we
have
a
working
code
release
on
github,
which
has
done
a
few
years
ago,
just
a
few
days
ago,
with
all
features
we'd
mention
here
yeah.
So
if
you
have
an
interest,
have
a
look
the
product
had.
Basically,
it
was
composed
of
a
library
with
our
API
and
our
they
abandoned
instance.
That
has
a
policy
was
just
still
being
a
piece
of
code.
D
Finally,
I
want
to
conclude
with
the
lessons
learned
from
this.
Sir
first
name
resolution
is
quite
separate
from
circuit
handling,
so
doing
this
wasn't
the
BST
socket
API
is
quite
painful
and
the
other
one
is
file
descriptors
for
me
are
considered
harmful
because
the
semantics
of
file
operations
really
do
not
match
the
kind
of
thing
you
have
to
do
for
network
communication
and
the
semantics
of
file.
D
Descriptor
isn't
much
change
depending
on
what
kind
of
transport
protocol
you
use,
so
the
TCP
socket
behaves
quite
differently
than
a
UDP
Soaker
for
some
system
codes
and
therefore
I
would
warn
everyone
who's
doing
this
assistant
tap
system.
To
sticking
too
much
with
the
bsd
socket
API,
it
will
be
a
pain,
so
that's
it
for
the
talk
and
I
would
like
to
have
a
rice,
a
bunch
of
questions
so
first
how
to
perceive
the
socket
intense
word.
We
now
have
a
draft
on
that
and
the
questions
is
the
working
group
interested
that
I
are
verbs.
D
The
second
bunch
of
questions
for
the
beastie
sockets
graph
is
proceed
with
this
document,
so
we
still
consider
this
as
background
work
for
the
socket
intense
draft
and
therefore
I
will
publish
most
of
its
contents
in
my
PhD
thesis
and
the
tech
reporter
anyway.
So
if
we
just
need
something
to
side,
there's
no
read:
there's
no
use
to
work
on
this
as
the
ITF
drove
it
further.
D
N
Tell
me
Paulie
yeah.
This
is
thank
you
for
bringing
this.
This
is
a
very
good
topic,
I
think
a
lot
of
the
detail,
so
we
should
talk
about
in
the
policy
discussion
at
the
end,
because
I
think
that
really
is
kind
of
all
about
this.
As
far
as
the
documents
I
can
imagine,
if
we
want
essentially
a
policy
management
document
to
kind
of
go
into
those
details
having
something
like
this
would
be
a
very
good
starting
point
for
doing
that.
N
I
could
imagine,
maybe
having
just
kind
of
one
document
around
that
you
brought
up
the
other
relationship
with
the
the
taps
guidelines
document
I
had
done.
One
question
that
I've
been
wondering
is
like
how
to
proceed
with
that
or
kind
of
split
that
out
into
the
various
places
where
it
should
be.
I.
Think
that
also
ties
in
well
with
the
happy
eyeballs
document
so
I
as
a
proposal.
I
could
imagine
that
we
could
have
no
grow.
The
happy
eyeballs
document,
because,
right
now
it
talks
about
you
know
how
you
do.
N
The
protocol
stack
racing
I
think
generalizing
that
to
also
potentially
include
some
of
the
work
that
I
mentioned.
With
the
you
know,
there's
endpoint
racing,
there's
protocol
stack
racing,
there's
other
types
of
how
you
build
your
connection,
I
think
that
could
be
its
own
document
of
just
the
details
of
that
establishment,
which
gets
into
some
of
the
points
you
brought
up
in
your
documents,
but
then
there's
also
the
separate
thing
of
how
do
we
express
the
policy
and
that's
what's
driving
this
racing
tree?
N
P
Yeah
bernstrom,
so
I
just
won't,
say
I
fully
agree
with
Tommy.
It's
great
to
see
these
straps
here
and
I.
Think
it's
a
bigger
question:
how
to
then
fit
the
pieces.
We
have
a
number
of
systems,
doing
policy
and
it's
very
nice
to
see
that
they
are
quite
similar.
I
mean
the
flow
is
maybe
a
different
in,
but
the
general
structure
is
still
quite
there's.
A
So
my
view
is
that
you
know
the
the
third
phase.
The
third
milestone
for
the
working
group
was
really
bad
experimentation.
You
know
it's
like.
We've
come
up
with
a
common
language.
Let's
go
build
some
stuff
see
what
works
you.
We
can
learn
out
of
it
if
it
turns
out
that
there's
rapid
agreement
and
can
end
convergence
towards
common
elements,
like
you
know,
like
the
Ella,
socket
intense
as
a
language
for
as
an
input
to
a
policy
engine
or
maybe
different
policy
engines.
That
seems
desirable,
I.
A
Think
in
terms
of
like
the
working
groups
goals,
if
all
we
do
is
come
out
with
an
RFC
that
is
a
compendium
of
different
approaches
to
implementing
taps.
That
is
consistent
with
what
the
Charter
says.
I
think
that
actually
we're
making
better
progress
than
that,
and
we
can
do
better
than
that,
and
so
I
would
I
kind
of
feel.
Like
it's
a
matter
of
the
folks
who
are
doing
these
implementation
projects
is
how
you
want
to
work
together.
A
You
know,
let's
try
to
find
a
way
to
collaborate
and
and
build
on
the
areas
where
there's
some
consensus,
but
I
would
like
to
see
some
description
of
the
of
the
mechanisms
and
the
lessons
learned
in
the
third
milestone.
Documentation.
I
think
that
that's
we
don't
I
think
that
this
is.
We
want
to
document
that
aspect
of
the
IETF
work
so
I'm.
A
P
Mine
is
actually
not
that
long,
okay,
okay,
so
this
is
an
update
on
the
happy
eyeballs
draft
for
transport
selection
and
its
joint
work
with
a
number
of
colleagues
in
the
neat
project.
So
next
slide.
So
this
relates
to
the
third
work
item
of
taps
so
to
how
to
select
and
engage
an
appropriate
protocol
and
how
to
discover
which
protocols
are
available
for
the
selected
service.
So
this
of
course
calls
for
some
forum
on
happy
eyeballs
mechanism
for
these
transport
selections.
P
So
we've
had
the
draft
on
this
Nayeem
presented
it
the
last
IETF.
This
is
a
summary
of
what
we
have
updated,
so
we
got
feedback
from
a
number
of
people.
So
thanks
for
that,
so
we
improved
the
wording
related
to
RFC
6555,
which
was
not
not
truly
accurate.
We
clarified
that
the
draft
applies
to
connection
oriented
transport
or
transport
that
have
some
notion
of
connectedness
I
thought.
We
had
clarified
that
one
transport
connection,
only
one
transport
connection
is
returned
to
the
application
and
the
other
connection.
P
Attempts
are
used
to
populate
the
cache
because
we're
trying
multiple
connections
in
parallel
and
we
want
to
learn
from
them.
Actually,
when
I
double-check,
to
see
if
there
was
something
else,
I
should
add
to
this
slide,
I
realized
that
that
sentence
had
fallen
out
somewhere
between
the
different
authors,
so
that
will
be
there
in
the
next
time.
We
have
some
questions
about
the
cache
lifetimes
and
things
like
that.
So
we
for
now
have
indicated
this
to
be
system
dependent
and
there
this
will
come
back
in
the
discussion
points
that
I
brought
for
for
the
draft.
P
We
change
the
example
to
use
ipv6
and
we
fix
some
other
clarifications
and
details
in
the
text
that
were
pointed
out
in
the
reviews,
so
next
slide.
So
then
to
go
back
to
to
the
Moore
architecture
and
maybe
the
more
important
and
these
interesting
things
to
discuss
in
this
context.
So
in
our
draft,
the
framework
we
have
would
have
the
eyeballs.
P
The
general
framework
is
to
have
the
application,
you
have
the
taps,
API
and
then
we
also
have
this
policy
management
module
that
is
responsible
for
indicating
what
the
correct
the
transport
candidates
are
at
a
given
time,
and
then
we
have
the
transport
probing
part
you
can
take
the
next
at
once.
So
the
draft
focus
is
here
really
on
just
the
transport
probing
part,
and
it
has
some
requirements
on
the
policy
management
management
for
what
it
provides,
but
it
doesn't
give
the
details
of
that
component
next
slide.
So
in
the
draft.
P
What
we
required
from
the
policy
management
is
that
this
is
the
piece
that
creates
a
list
of
candidate
transport
solutions
and
they
also
give
you
some
order
of
priority
and
in
general
this,
of
course,
can
be
created
in
many
different
ways.
You
may
have
some
pre-configured
choices
or
you
could
have
a
very
complex
policy
system,
but
idea,
of
course,
bit
taps
is
that
you
should
have
some
use
of
the
application
requirements
used
available
information
about
the
network
and
your
your
configured
policies.
P
But
the
only
thing
that
we
specify
in
the
document
here
is
that
you
should
use.
We
require
the
use
of
cache
information
so
that
you
don't
try
the
same
things
over
and
over
and
put
unnecessary
load
on
the
network,
and,
if
you
don't
have
policies
that
specify
otherwise,
you
should
comply
with
the
guidelines
in
RFC
6555,
so
other
than
that.
We
don't
really
specify
the
policy
management,
of
course,
in
the
implementation
of
this
in
need.
P
We
also
have
some
requirement
that,
as
I
said
on
the
use
of
caching,
so
we,
the
the
transport
problem
component,
should
cache
the
outcome
of
the
connection,
attempt
back
to
the
policy
management
and
allowing
all
the
connection
that
has
been
initiated
to
complete.
So
those
are
basically
the
only
requirements
that
the
documents
are.
Ok
next
slide,
so
I
think
what's
interesting
to
discuss
in
this
context
and
which
also
ties
back
to
the
greater
policy
discussion
is
what
the
interface
should
be
between
these
happy
eyeballs
algorithm.
P
The
policy
management
we
separate
them
do
is
describe
just
some
as
we
have
done
some
requirements
or
or
how
should
we
more
in
general,
maybe
just
split
up
the
tap
system
and
have
the
different
interfaces
between
the
pieces?
Do
we
need
some
form
of
architecture
document
so
that
we,
you
know
when
we
all
talk
about
the
policy
management
component?
We
have
different
implementations
of
that.
Do
we
talk
about
the
same
thing?
The
other
issue
related
to
the
draft
itself
is
how
much
details
you
should
you
have
on
the
happy
eyeballs
component.
P
So
many
of
the
questions
that
we
got
back
on
on
the
drafts
that
we
submitted
was
all
on
someone
like
the
parameterization.
So
what
should
the
cash
lifetime
be?
So
is
that
something
that
you
should
have
guidelines
on,
or
should
that
be
left
out
as
a
implementation
detail
and
be
fully
system
dependent?
Similarly,
d
ter
time
between
the
connection,
attempts
should
be
like
you
know,
regulate
what
what
the
delays
should
be
and
so
on,
and
similarly
should
we
have
some
rules
in
terms
of
how
the
candidate
list
is
generated.
P
O
Spencer
Dawkins
is
an
OSI
individual
some.
So
since
you
mentioned
the
cache
lifetime,
I
I
don't
know
whether
this
is
more
on
your
first
page
report
about
architecture
or
your
second
major
board
about
to
have
the
iOS
implementation,
but
it
seems
like
there's
also
an
interaction
there
with
mobility,
so
that
you
know
so
the
answer.
The
the
the
happiest
answer
that
you
can
come
up
with,
might
change
as
a
result
of
mobility
onto
a
different
network
path
with
different
characteristics.
So
just
you
know
just
having
that
I
I
think
you
know.
O
N
N
The
steps
to
the
first
question
I
think
that
it
would
be
cleaner
to
leave
them
separate
because
our
policy
discussion,
I,
imagine,
will
evolve
and
grow,
and
that
can
be
someone
independent
from
how
we
actually
do
this.
So
just
sensually.
Let's
say
you
know
it
takes
input
from
this
other
policy
management
system,
and
then
we
can
define
them
separately
as
long
as
so
I
think.
P
Just
a
comment
on
that
I
think
you
can
describe
that
on
on
different
levels,
also
right,
because
it
depends
on
if
you
see
that
these
two
components
in
the
end
should
be
separate
and
able
to
interoperate
or
if
it's
a
logical
separation,
so
that
we
know
what
the
interface
is.
So
we
need
transport
candidates.
We
need
some
priority
right.
P
That's
like
on
a
very
high
level
what
you
need,
if
you
needed
independent
components
to
interoperate,
and
you
would
need
to
specify
exactly
how
that
should
be
represented
and-
and
that's
maybe
not
necessary
if
I'm
not
sure.
If
that
is
necessary,
because
you
could
implement
that
interface
in
different
ways.
Once
you
go
to
implement
your
policy
and
happy
I
was
racing
which
would
typically
be
on
the
same
system
right
so.
N
Yes
yeah,
so
we
should
get
into
those
details.
Yeah
for
the
second
point,
I
would
actually
like
to
point
to
the
fact
that
in
v6,
ops,
David's
class,
II
and
I
are
we
have
a
happy
eyeballs
version
to
update
draft,
so
there's
actually
gonna
be
kind
of
like
abyss.
Happy
eyeballs,
so
we
a
should
reference
that,
but
B
we
could
kind
of
follow
the
style
that
we're
doing
there
in
which
you
define
you
know
there
is
a
delay
or
there's
a
lifetime
parameter
that
should
or
must
be
configurable
one.
That
system
and.
C
P
M
Aaron
asked
me
to
frame
this
discussion.
I
read
Dremel,
so
I
only
have
one
slide
about
policy.
E
M
I've
noticed
a
few
things
happening
and
like
a
lot
of
the
work
that
we're
doing
in
taps
right
now,
it
seems
to
be
converging
very
nicely,
and
one
of
the
decisions
that
we
seem
to
have
converge
very
nicely
on
is
two
pointedly
ignore
the
details
of
policy,
because
that's
where
all
of
the
fun
hard
stuff
is
and
I
really
like
that.
The
conclusion
of
the
of
the
last
discussion
was
okay.
Now
we
need
to
actually
start
getting
into
details
and
I.
M
Think
we
didn't
you
start
getting
into
details
and
each
of
the
areas
of
detail
that
we
can
get
into
is
kind
of
dominated
by.
It
goes
back
to
men
set
right.
It's
which
bits
of
the
abstract
interface
to
this
component
of
a
tap
system
are
parts
of
the
will
be
bubbled
up
to
the
higher
API
in
which
cookies
are
policies,
and
it
turns
out
that
in
every
case
it
could
be.
All
of
them
are
all
of
them.
M
So
I
want
to
actually
raise
a
different
problem
and
say
it's
actually
worse
than
that,
so
there's
a
sit
set
of
parameters
of
capabilities
of
policies
of
you
know.
All
of
these
terms
are
kind
of
overlapping
here,
but
they're,
all
kind
of
initially
based
on
the
system
capabilities
right,
you
can't
in
tap,
so
you
can't
raise
transport
protocols.
You
don't
have
implementations
of
it's
very
simple
right.
M
You
cannot
race.
I
IP
protocols
that
you
don't
have
implementations
everywhere.
You
don't
have
a
connection,
so
there's
actually
kind
of
a
hard
floor
on
where
your
policies
can
be,
and
on
top
of
that
you
can
layer
the
capability.
The
application
right,
like
so
I,
think
one
of
the
problems
that
we've
had
in
doing
API
design
for
the
few
of
transport
is
we
either
say:
okay?
Well,
it
has
to
fit
in
DSD
because
nobody
else
is
going
to
implement
applications.
M
Do
it
otherwise
or
they
say,
oh
well,
we
need
one
API
to
rule
them
all
and
I
think
those
are
both.
Mistakes
I
think
we
actually
need
different
api's
for
different
interaction
patterns
and
therefore
into
this
sort
of
cascade
of
policies
comes
the
API
that
the
application
was
written
to.
This
is
easier
to
deal
with
because
you
can
always
put
Chim
layers
in
to
put
any
API
on
top
of
any
other
thing,
but
some
of
the
efficiencies
are
really
terrible.
There's
also
application
policies,
there's
developer
preferences
and
constraints.
M
A
lot
of
what
we
see
with
sort
of
driving
forward
encryption
now
is
actually
kind
of
application
policies.
This
levels
browser
is
essentially
saying
you
know
this
cipher
suite
with
visi
and
shaking
protocol
or
go
away
and
the
certificate
needs
to
have
these
properties
or
go
away,
and
then
you
have
user
policies.
You
have
things
that
the
user
actually
wants
right,
so
these
would
be
preferences
and
constraints.
M
M
M
M
E
M
So
you
have
system
capabilities
and
application
fee
abilities
and
policies
and
user
policies
and
organization
policies,
and
we
have
a
language
for
taking
properties
of
things
and
attaching
them
to
elements
in
a
system
in
a
way
that
they
cascade
there
any
web
developers
in
the
room.
Please
leave
now
I
think
we
should
actually
configure
the
top
system
using
CSS.
U
M
I
make
this
point
for
two
reasons:
one
it's
not
as
bad
an
ideas.
It
sounds
like
it.
The
first
time,
I
really
want
people
come
up
into.
Tell
me
that
it's
a
terrible
idea
that
we're
not
gonna
do
it,
but
it
also
illustrates
how
hard
this
problem
is
because
debugging
CSS
is
maybe
the
great
unsolved
problem
with
the
21st
century
and
we've
kind
of
decided
that
we're
taking
it
on.
So
with
that
I'd
like
to
open
the
floor,
please
tell
me
I'm
wrong.
Oh
that's
depressing!
F
You're
wrong,
but
you
may
not
be
insane
gory,
fair,
okay
and
yes,
what
Cohen
said
yes,
and
maybe
also
yes
to
some
of
the
things.
There's
multiple
blobs
in
here
that
do
quite
different
things,
so
the
stuff
like
to
do
with
which,
what
your
providers
offering
and
all
the
interfaces
and
capabilities
you
have
up
your
network.
There's
transport
you're,
trying
to
figure
in
here
unless
some
other
user
policy
which,
if
you're,
live
in
an
organization,
isn't
your
policy,
it's
their
policy.
M
Time
so
so
what
what
I
would
like
to
see?
What
actually
what
I
wanted
to
draw?
But
it
was
too
hard,
was
the
verticals
here
right.
So
these
are
the
horizontals.
These
are
the
layers
of
how
things
cascade
and
the
verticals
are
the
different
bits
of
which
kind
of
policy
for
which
part
of
a
running
tap
system
you
have
and
like
I,
pretty
much
know
which
fits
in
this
application
capabilities,
but
fits
in
that
box.
I
have
a
little
bit
of
an
idea
about.
M
What's
fits
in
that
box
and
then
like
how
you
find
things
to
these
higher
boxes
gets
really
fuzzy,
so
I
think
actually
trying
to
draw
this
out.
As
a
matrix
I
mean
I
tried
to
draw
it
as
a
matrix.
It's
hard
I
think
if
we,
if
we
actually
say
okay
well,
let's
start
on
this
is
a
thing
that
we're
gonna
try
and
deliver,
and
maybe
it
turns
into
a
document
that
comes
out
of
the
group.
M
Maybe
it
just
is
we
get
smarter
while
we
do
it
and
we
throw
it
on
the
ground,
because
it's
terrifying
is,
you
know,
I
think,
but
I
think
yeah
I
think
that
the
the
next
step
is
to
put
the
verticals
in
here
and
and
actually
think
about
that.
Well,
that
have
heard
what
made
me
happy
as
I
have
heard
that
pretty
much
every
palo
herb
every
presentation
today
that
had
some
sort
of
policy
angle
actually
talked
about.
A
Q
F
Home
at
you
Cory,
a
very
quick
jump
in
on
that
it'd-
be
really
nice
to
know
how
it
happens
because
from
playing
with
this
stuff,
you
really
want
to
know
what
is
happening
as
well
as
it
happens,
magically!
That's
because
you
just
you
want
to
have
your
hands
on
the
knobs
I.
Don't
know
the
knobs
are
doing
the
right
thing,
so
I
can
design
more
things
for
them.
It's
an
engineering
problem,
yeah
yeah.
M
So
so
there's
another
I
mean
there's
another
problem
here
is
that
maybe
you
have
user
policies
in
CSS
and
maybe
you
have
user
policies
in
the
UI,
and
maybe
you
just
have
a
user
policy
thing.
Do
you
load
and
dump
think
about
it?
I
mean
like
there
are.
There
are
different.
We
we
can
build
both
Emacs
and
VI.
We
have
the
technology.
Q
Perkins,
so
I
think
we
need
to
be
careful
to
avoid
the
boiling
the
ocean
problem.
Q
Okay,
clearly,
all
the
rest
is
just
a
matter
of
engineering,
but
I
mean
there
are
pieces
of
this
I
think
we
can
make
it
a
very
good
snapper
rabbit
I
mean
the
low-level
bits.
Okay
and
I
think
we
were
engineers.
We
can
make
the
engineering
choices
about
oil
here
on
the
knobs
to
adjust
that
these
policy
things
at
these
low
levels.
Q
M
Agree
that
the
higher
up
this
stack,
you
go
the
further
away
from
our
scope
we
get,
but
at
the
same
time,
since
these
stack
on
top
of
each
other.
The
choices
that
we
make
down
here
define
the
set
of
possible
languages
up
at
the
top
level,
and
we
need
to
make
sure
that
if
we
make
any
constraints
on
that
that
we're
doing
it
with
eyes
open.
Yes,.
N
N
So
yes,
I,
agree
that
not
all
of
this
needs
to
be
specified
in
taps,
but
I
think
all
of
it
needs
to
be
acknowledged,
yep
by
taps,
and
we
need
to
define
have
the
shape
of
that.
So
the
main
point
in
which
I
think
you're
wrong
is
actually
the
ordering
of
these.
Thank
you
that
was
useful.
Can
we
go
I
want
to
put
the
application
boxes
on
the
top,
so.
J
N
Okay,
so
I
think
the
application
capabilities
and
system
capabilities
likely
can
collapse
into
each
other
and
hopefully
aren't
too
interesting
yep,
because
essentially
it's
like,
if
I
try
to
load
protocol,
SCTP
I,
don't
have
it
it's
just
not
gonna
work
right,
race
will
fail.
Who
cares
like
it's
good
I?
Think
the
application
policies
is
the
main
area
that
taps
needs
to
figure
out.
I.
Think
that's
built
up
a
lot
of
what
Phillip
was
talking
about
of
intense
I
think
there
we
should
break
that
into
yeah.
N
Did
you
have
them
already
preface
and
constraints
yeah,
so
there's
intense,
which
go
towards
designing
my
socket
options
and
stuff
like
that?
I
think
that's.
We
need
to
work
on
that
list
and
that
will
be
a
good
piece
of
work
to
do,
but
it's
not
quite
as
tied
into
all
the
other
constraints
on
the
constraint
side.
So
I
guess
the
proposal
there
would
be
like
maybe
that
part
of
the
same
CSS
rate
as
the
other
layers
using
the
terminology
I
know
so
at
least
we're
talking
about
our
implementation
right.
N
Essentially,
we
do
it
as
like:
there's
like
an
Oracle
when
you're
creating
your
connection,
so
that
application
policies
are
different
than
user
constraints
and
Enterprise
constraints
and
other
things.
Application
policies
and
constraints
are
things
that
are
the
Preferences
that
you
can
feed
into
this
Oracle
like
I'm.
The
application
I
want
here.
The
things
I
want
to
do
tell
me
what
I
can
do.
Yep
I
do
think
that
the
user
constraints
and
the
organizational
constraints
should
be
the
same
language.
Those
are
some
versions
of
it.
I
mean
internally
they
fold
into
the
same
language.
N
For
us
they
are
configured
by
different
places.
Your
enterprise,
for
example,
can
push
you
a
an
XML
file
right
now
that
describes
which
applications
are
allowed
to
use
cellular
on
roaming
or
not,
and
that
gets
overlaid
with
the
user
preferences
of.
Do
they
want
that
application
to
you,
cellular
or
not,
and
then
everyone's
happy
there.
So
that's
an
area
that
exists
that
I
believe
totally
fills
out
the
CSS
I.
N
Don't
think
we
need
to
get
too
into
the
weeds
of
how
that's
done,
because
that's
gonna
end
up
being
system
specific,
but
I
think
what
we
should
end
up
defining
is
that
these
are
parameters
that
are
fed
into
some
type
of
Oracle,
that
a
tap
system
must
be
able
to
consult,
to
give
its
application
constraints
to
and
receive
back
an
answer
of.
Okay
I
chose
this
subset
of
the
things
you
wanted,
or
here
are
the
options
you
now
have
based
on
all
of
it.
Yep.
O
Spencer
Dawkins
that'll
drop
one
of
my
questions.
It
sounded
big
deep
for
the
other
ones,
and
so
this
wasn't
speaking
as
an
ad
you
were
talking
about
you
were
talking
about.
You
know
all
these
things
being
kind
of
at
different
layers
and
maybe
with
different
people
responsible
for
those.
You
know
for
those
technology,
for
the
decision,
points
and
stuff
like
that,
I
just
observe
you
know,
did
the
right
thing
we're
supposed
to
be
able
to
work
across
areas
in
the
IETF
and
if
we
had
to
go
all
the
way
to
w3c.
O
T
You
had
on
the
floor,
I
think
I
can
thank
poor
Tommy
for
reading
my
mind.
So
let
me
see
if
I
can
add
to
something
I
mean
this:
this
layer
that
you're
showing
I
mean
it
could
actually
collapse,
because
somehow
the
system
capabilities
like
says
like
what
kind
of
application
capabilities
you
can
have
and
some
and
then
you
can
have
efficient
policies
that
actually
defines
what
kind
of
organization
policies
and
media
policies
you
could
have.
So
they
can
become
collapse.
T
But
there
are
some
other
things
like
like
I
heard,
like
somebody
say
like
now,
my
device
is
doing
it
like.
If
we
have
a
choice
between
a
Wi-Fi
and
3G
radio,
you
tend
to
prefer
Wi-Fi
because
it's
supposed
to
be
free
and
a
sub-segment,
but
things
are
happening
in
the
in
the
other
side
as
well
like
you
can
actually
the
network
or
the
operators,
they
can
actually
send
a
policy
say
like
okay,
you
have
like
data
bucket.
T
If
you
use
this
application,
I'm
not
going
to
cut
your
data
and
stuff
like
that,
so
that
also
we
could
could
be
one
thing
that
tests
my
dick
want
to
listen
to
them,
because
because
then
that
actually
decides
like
how
you're
going
to
do
your
selections-
maybe
maybe
in
one
network
you
select.
Okay,
this
this
were
participe
works.
Another
network
work
week
works
so
that
actually
affects
what
taps
is
gonna
do
so
muck.
So
my
my
thinking
is
like
that
all
the
policies,
decisions,
I
I,
think
we
need
to
think
a
bit
more
I.
D
So
briefly,
please
you
asked
us
to
say
that
you're
wrong
you're,
wrong,
I,
guess
it's
that
you
have
two
kinds
of
that
kind
of
stack.
So
first
you
have
the
stack
of
capabilities
of.
What's
can
be
done
and
that's
very
below
afterwards.
You
have
the
policies,
and
this
is
what
I
consider
policy
more
or
less.
Once
you
have
the
set
of
stuff
that
can
be
done
from
a
technical
standpoint.
You
want
to
filter
out
what
shouldn't
be
done
from
a
policy
standpoint.
D
So,
for
example,
I
don't
want
that
application
on
on
cellular
and
last
you
have
to
fill
the
point
of
ordering
it
in
a
way
from
what
is
preferred,
I.
Think
there's
this
CSS
really
really
matches.
Well
the
idea
how
to
do
that
and
afterwards,
after
we
have
this
ordering,
then
your
bet
back
to
heavy
eyeballs
on
trying
out
what
of
the
order
you
have
empty.
This
might
be
really
awesome.
This
might
be,
and
up
in
using
always
the
last
thing
on
this
tacky
or
that's
most.
Oh,
that's
this
desirable,
but
yeah.
H
L
U
U
H
H
M
I,
like
the
way
that
I
actually
the
way
that
Philip
I
think
was
Philip
put
it
that
we
basically
have.
You
know
the
supply
comes
from
down
here
and
the
filtering
comes
from
the
top
right,
so
it
what
you
can
do,
bubbles
up
and
then
what
you
don't
want
to
do
pushes
down
I
think
that's
a
it's
a
good
way
to
frame
this
or
constrain
this
set
of
solutions
that
this
makes
this
tractable.
A
A
C
K
Be
quick,
I
think
it's
about.
Who
has
what
knowledge
you
know
you
cannot
have
a
system
policy,
giving
applications
messages
out
of
order
if
messages
contact
applications
can't
accept
that
applications
may
not
know
about.
You
know
me
having
a
preference
for
Wi-Fi
or
not
so
it
depends
on
who
has
which
knowledge
really
that's
my
view
on
I
mean
at
least
helps
simplify
this
discussion.
I
think.