►
From YouTube: IETF94-TAPS-20151103-1520.webm
Description
TAPS meeting session at IETF94
2015/11/03 1520
A
A
A
A
C
C
B
B
D
B
B
B
B
B
B
B
B
When
we
get
to
work
in
group
last
call,
we
really
need
some
detailed
review
both
for
the
technical
and
the
editorial
content.
So
that's
something
you
can
think
about
now
will
certainly
help
the
work
of
the
group.
The
second
thing
we're
going
to
talk
about
is
a
document.
That's
been
discussed
a
little
bit
on
the
working
group
list,
draft
well
cold
taps
transports
when
the
co-authors,
my
name
is
going
to
be
here
to
talk
about
that.
It's
a
somewhat
algorithmic
processing
of
transport
protocols.
B
B
Thought
the
ticket
was
clear,
but
alright
help
us
on
the
way
so
names
going
to
talk
about
the
process
that
they
used
to
generate
this
draft
and
like
to
see
some
discussion
about
whether
folks
think
it's
a
useful
document
for
the
working
group
to
take
up
our
Charter
has
we've
been
calling
document
to,
which
is
a
has
to
two
features.
One
is
selects
a
subset
of
the
protocols
that
we
identify
in
the
first
document,
so
we
take
of
the
transport
protocols
that
we
described
in
the
first
document.
B
Which
pieces
should
be
used
of
those
protocols
and
so
we'll
get
into
that
a
little
bit
later,
steins
going
to
talk
about
an
approach
that
they
have
used
in
the
draft.
That's
been
circulated
on
the
list
and
that's
a
can
be
I,
think
a
shorter
discussion,
so
we've
got
90
minutes
I.
Think
you
got
playing
time
to
cover
these
things
and
in
any
other
business.
So
is
there
anything
that
anybody
wants
to
bash
on
the
agenda.
B
All
right:
well,
let's
move
along
then
so
a
little
bit
of
working
group
status,
I
apologize
for
my
cough.
So
this
is
the
schedule
that
I
presented
in
Prague
and
I
think
that,
even
though
that
we
didn't
have
the
interim
meeting
that
we
discussed
at
the
last
last
time,
we
were
together.
I
think
that
we
are
still
pretty
much
on
track
for
this
schedule
and
I'm
probably
going
to
send
it
to
Spencer
to
have
it
put
up
on
the
site.
B
If
we
do
talk
about
adopt,
if
we
do
adopt
this
other
document,
that
name
is
going
to
talk
about.
We
may
end
up
slipping
out
the
the
later
documents,
but
I
think
that's
something
that
we
can.
We
can
discuss
later
today,
so
the
most
salient
piece.
The
schedule
is
that
we
want
to
finish
a
working
group
last
call
of
the
first
document
soon,
ideally
by
the
end
of
the
year,
which
means
getting
people
have
to
focus
over
the
next
several
weeks
to
to
get
that
out.
B
E
C
C
E
Slide
please
so
we're
here
talking
about
drakkaidia
caps
transports.
This
is
basically
just
reminding
those
of
us
who
haven't
looked
at
this
document
since
the
last
time
we
talked
about
it
in
Prague.
Why
we're
writing
it
and
what
the
document
thinks
it
is
actually.
The
Charter
has
obviously
remained
unchanged
since
last
we
talked
about
the
document
the
abstract
has
as
well,
so
there's
a
couple
of
things
in
the
abstract.
E
I
actually
went
back
and
have
a
look
at
this,
because
we've
had
this
discussion
about
other
about
the
other
tab
transports
document
and
how
that
fits
in
and
yeah
so
describe
services
providing
about
existing
IETF
protocols.
We
do
talk
about
congestion,
control
mechanisms
in
the
abstract,
but
we
don't
really
in
the
document,
so
we
should
probably
fix
that
it's
designed
to
help
application
networks
that
program
and
to
inform
the
work
of
the
IETF
caps
working
group,
so
this
was
always
kind
of
intentioned
as
a
dual
purpose
document
right.
So
it's!
E
E
To
get
it
out
in
December,
which
is
the
of
2015
wow,
it's
pretty
close.
Basically,
we
can
ask
a
question
about
this
document
next
slide.
Please
are
we
there
yet,
and
the
answer
is
yes,
asterisk
we're
basically
done
Aaron,
actually
I'm
going
to
quote.
You
ran
into
Erin
earlier
in
this
meeting.
I,
don't
remember
what
day
it
was.
He
said:
yeah
I
read
this
document
front
back
for
the
first
time
and
it's
actually
pretty
good
and
I
had
the
same.
E
You
know
for
407
I
looked
at
it,
you
know
in
the
editorial
we've
been
down
in
the
weeds
for
a
really
long
time
about
okay.
Well,
we
need
to
make
a
decision
about
where
this
you
know
how
we
need
to
go
get
another
transfer
protocol.
We
need
to
edit
it
so
that
it
actually
fits
into
the
sort
of
a
flow
of
inter
press.
E
The
document
I
hadn't
really
read
it
front
to
back,
and
it's
it's
basically
kind
of
done
and
what
isn't
done
next
slide
is
almost
certainly
doable
for
December,
even
considering
the
fact
that
I'm
not
really
going
to
be
home
before
december
and
goriya
isn't
here
and
birria
is
actually
not
going
to
be
home
till
january.
So
I
guess
we
have
to
it's.
It's
me
and
gory
figuring
this
out
I,
but
even
given
that
I
still
think
it's
doable,
because
this
is
all
we
we
have
to
do.
E
It's
basically
already
content,
complete
I
I
did
the
I.
Had
my
editor
tell
me
a
text
editor
tell
me
that
there
are
ten
editor's
note
still
in
the
document.
I
had
a
quick
look
at
these.
These
are
mostly
editorial
and
it's
probably
safe
to
simply
drop
many
of
them
at
this
point,
say:
okay,
yeah
we're
not
going
to
do
it.
This
was
a
good
idea,
but
we
don't
have
the
cycles.
We're
done.
It's
not
going
to
add
much
more
to
the
document.
E
If
we,
if
we
resolve
this,
there
is
one
editor's
note.
That
is
the
only
content.
In
a
section.
That's
the
section.
3
92,
which
is
the
interface
on
RTP.
This
was
written
by
gori,
so
I
mean
the
section
was
written
by
gory.
He
didn't
provide
an
RTP
interface
section,
so
we
either
need
a
couple
of
sentences
there
to
conform
with
the
format
or
we
can
break
compliance
with
the
format
we
will.
I
will
discuss
with
gauri
what
we
want
to
do
on
that.
E
B
B
E
We
have
the
end,
so
we
could
actually
see
if
there's
anything,
that
we
can
pull
out
of
the
introductory
text
that
talks
about
the
interface
in
such
a
way
that
we
could
stick
it
in
here.
Right
I
mean
the
problem
that
the
problem
is
is
that,
with
with
respect
to
RTP
interface,
the
question
is
which
one
right
I
mean.
There's.
C
E
E
C
E
F
E
E
That
is
it
all
interesting
or
useful
that
fits
into
72
columns
when
you
you
have
more
than
you
know,
on
the
order
of
50
features
and
on
the
order
of
12
things
that
you're
going
to
matrix
together,
it
just
doesn't
make
any
readable
sense.
So
if
other
people
feel
strongly
about
that,
please
step
up
now,
but
otherwise
I
think
we're
just
going
to
cut
it.
We're
going
to
go
with
the
tree
structure.
E
E
While
we're
structuring
this
one
check
for
completeness
and
correctness
to
check
for
structure,
if
there's
anything,
that's
structured
there
in
a
way,
that's
not
useful,
let
us
know
once
those
are
done
so
actually,
how
would
you
like
to
do
this?
As
the
charity
you
want
to
put
working
group
last
call
on
07,
and
these
become
working
group
lost,
call
comments
to
our
self,
or
do
you
want
to
do
working
your
boss
call
after
we
send
this
version
of
the
document
in
which
is
going
to
be
like
mid
to
late
november.
B
B
Get
throw
spell
check,
take
out
the
duplicate
UDP,
like
section
yeah,
but
first
what's
I
think
that
what
we
want
to
do
is
ask
whether
there's
to
the
room,
whether
there's
anybody
who
has
an
opinion
as
to
whether
they
think
this
I
mean
the
author's
think.
This
doctrine
is
ready
for
working
good
class.
C
B
Sorry,
it's
a
learning,
it's
so
hard
to
do
these
questions.
Clearly,
what
I'm
trying
to
say
is
if
Brian
does
the
cleanup
that's
listed
on
this
slide
we.
So
we
think
that
this
is
the
remainder
of
the
work
that
needs
to
be
done
on
the
document.
Modulo
was
spell
check
and
the
issue
that
you
just
pointed
out
Oh
in
the
comments
from
Karen.
Yes,
that's
right,
so
does
anybody
see
a
blocking
issue
that
needs
to
be
fixed
before
we
take
this
to
working
group
last
call.
B
C
B
H
H
It's
basically
about
a
different
approach
on
how
to
identify
the
services
in
the
transfer
protocols
and
condition
control
mechanisms.
So
next
slide
please.
So
what
is
the
scope
of
this?
Internet-Draft
is
basically
addressing
the
working
groups
charter
item,
one
which
is
to
define
a
set
of
transport
services
provided
by
the
existing
I
achieve
protocols,
and
also
this
works
as
a
starting
point.
H
It
only
considers
the
services
that
have
been
considered
between
two
endpoints
only
so
this
draft
is
intended
to
be
a
compliment
or
supplement
to
the
basically
the
taps
transferred
internet-draft
and
currently
it's
in
current
shape
with
the
00
version.
It
only
includes
tcp
and
sctp.
In
future
we
are
envisioning
that
we
will
have
more
protocols
included
in
the
draft
next
slide,
please.
So
what
is
the
goal
of
this?
H
Internet-Draft
is
basically
to
use
a
generic
approach
and
to
basically
develop
a
document
that
that
is
used
by
mainly
the
taps
system,
designers
and
eight
lopers
to
be
able
to
map
the
services
between
these
protocols
and
also
to
know
how
to
use
them
and
in
each
of
the
protocols
that
are
included
in
the
draft.
It
basically
tries
to
answer
the
questions
that
arises
when
you're
trying
to
basically
build
and
implement
a
tap
system
next
slide.
Please.
H
So
it
basically
follows
a
33
pass
approach
so
in
it
goes
through
pass,
one
which
looks
at
different
rfcs
that
are
related
to
the
each
of
the
protocols
that
are
included
there
and
it
summarizes
the
relevant
parts
and
it
basically
says
what
is
provided
by
that
protocol
to
the
upper
layer
as
well
as
the
applications
and
how
it's
being
used.
This
is
the
past
one,
the
past
two.
H
It
tries
to
categorize
the
services
derived
from
past
one
and
weather
and
categorize
them,
based
on
the
metric,
whether
they
are
related
to
add
to
a
connection
and
maintenance
or
establishment
of
connection
or
availability
of
it,
or
it's
related
to
a
dense
data
transmission
face
and
eventually,
in
the
past.
Three.
H
What's
going
to
happen,
is
that
we're
going
to
present
the
superset
of
all
the
services
that
we
figured
out
and
for
all
the
protocols
based
on
the
list
in
the
past
two,
as
well
as
the
text
in
the
past,
one
which
is
according
to
the
rfcs
to
include
the
services
that
are
basically
static
in
inserting
protocols
and
next
slide?
Please.
So
the
approach
I'm
going
to
explain
the
approach
in
pass
one.
H
So
in
the
current
draft,
you
are
looking
at
TCP
and
sctp,
and
we
define
service
here
as
any
form
of
interaction
between
the
transfer
protocol
and
its
user
could
be
a
ULP
or
an
application.
So
we
go
through
the
RFC's
and
then,
as
you
can
see
in
the
table,
we
identify
certain
interactions
and
then
we
exclude
those
services
that
are
that
should
not
be
implemented
in
those
protocols.
H
According
to
other
RFC's
and,
for
example,
the
urgent
mechanism,
according
to
the
RFC
1693
or
the
services
that
are
optional
or
implementation
dependent,
we
exclude
those
from
the
list
and
also
the
services
that
are
already
provided
elsewhere
somewhere
else
in
the
by
another
mechanism.
And
then
we
end
up
being
having
a
table
like
that,
for
example,
for
tcp
you
have
open,
send,
receive
and
so
on
and
so
forth,
and
for
sctp
you
have
associated,
send,
receive
and
shut
down,
and
so
on
and
so
forth.
H
Next
slide,
please
and
then
once
we
have
this
list
in
the
table,
we're
going
to
that
to
the
fate
to
the
past,
to
which
basically,
we
try
to
categorize
the
services
that
we
draft
previously,
whether
they
relate
to
a
connection
or
data
transmission.
So
we
use
a
format.
Basically,
the
format
is
a
category
dot,
whether
we
might
have
a
subcategory
or
not.
We
could
have
a
subcategory
and
then
the
service
name
and
then
the
protocol,
for
example,
in
case
of
tcp.
H
In
the
connection
establishment
phase,
we
could
have
connection
dot,
stablishment
connect,
ECB
and
the
same.
We
could
have
for
sctp
and
then
using
that
kind
of
format.
Then
we
could
map
different
services
between
different
protocols
and
then
explain
how
they
are
being
used
in
API
or
in
RFC.
Next
slide.
Please,
and
then,
when
we
go
through
this
pass
to
then
for
every
service
that
we
identify.
H
Once
we
have
the
past
who,
then
we
move
on
to
pass
3,
then
we
basically
turn
everything
upside
down.
We
basically
look
at
all
the
super
sets
of
all
the
services
that
we
found
in
the
protocols
that
are
included
in
the
draft
and
based
on
the
past
two
as
well
as
past
one
and
then
for
example,
here
and
we
are
not
presenting
the
entire
service
set,
but
basically
a
part
of
it
just
for
the
sake
of
you
know
a
clarity,
for
example.
In
case
of
this
connection,
availability,
that's
a
basically
a
category
and
a
subcategory.
H
Then
we
could
drive,
for
example,
listen
to
one
specified,
a
local
interface
as
a
service,
and
then
we
know
that
protocols
like
TCP
and
sctp
would
provide
that.
If
we
have
another
service
which
is
being
able
to
listen
on
a
specified
local
interfaces,
then
that's
the
CTP
that
provides
that
an
TCP
doesn't
provide
it.
So
in
case
of
the
data
receive
which
is
also
category
subcategory,
then
we
know
that
the
sctp
can
provide
us
with
the
choice
of
a
stream
to
receive
on,
whereas
the
TCP
doesn't
support
multi
streaming.
So
yes,
please
and.
G
C
C
H
C
H
G
I
mean
I
I
feel
very
strongly
about
this.
I
mean
you
have
the
document.
I've
read
only
refers
to
4960
and
agreement,
and
the
way
we've
worked
in
the
HTTP
community
is
to
have
the
API
specified
in
RFC,
64-58
and
I
think
it
is
not
valid
to
have
a
document
here
that
does
not
refer
to
64-58,
so
I
don't
know
when
we're
going
to
discuss
that,
but
if
it
was
now
I
mean
this
is
for
me
a
blocking
comment.
So.
G
But
I
would
say
that
in
the
document
right
now,
you
state
that
you're
only
using
4960,
and
that
was
not
what
you
said
here
orally.
You
said
that
you
would
use
our
of
seas
and
then
I'm
happy
I'm,
just
saying
that
right
now
it's
stated
in
the
document
that
the
basis
is
4960
and
I'm.
Saying
that
that
does
not
is
not
I,
don't
believe,
that's
valid
for
a
ctp
at
least
so
I'm
happy.
If
you
say
that
you
would
include
the
RFC's
yeah.
H
Definitely
I
would
like
to
have
your
input
yep,
so
the
discussion
that
we're
going
to
have
before
we
go
through
this
discussion,
I
would
like
to
state.
One
thing
is
that
using
this
approach
that
we
are
taking,
so
we're
basically
able
to
derive
services
from
any
text
that
basically
talks
about
and
what
the
protocol
provides
and
how
it's
being
used
and
and
and
now
I
would
like
to
have
this
discussion
on
what
protocols
to
include
in
this
draft.
H
So
what
you
see
is
basically
it's
very
simple:
it's
only
tcp
versus
sctp,
so
it's
get
kind
of
more
interesting
when
we
have
more
protocols
there
that
we
could
actually
see
a
difference
between
the
set
of
services
and
some
of
the
services
won't
show
up,
haven't
shown
up
here
yet
because
we
just
don't
have
the
protocols
which
would
provide
those
services.
So
if
you
have
more
protocols
than
we
would
have
a
longer
list
of
services,
that
would
basically
be
quite
similar
to
that.
F
Have
a
small
problem:
they
are
about
composition.
Is
that
part
of
the
rationale
for
doing
is
analysis
is
to
do
composition
of
a
doc
protocols
that
fit
exactly
some
applications
need
and
when
I
I
see
what
we
do
in
terms
of
composition,
it's
very
seldom
in
some
of
services,
as
in
the
aveo
application.
That
note
want
to
receive
data,
for
example,
but
it's
mostly
in
terms
of
what
kind
of
implementation
you
want
underneath
back.
H
Now,
basically,
the
current
text
is,
you
approach
is
to
use
both
protocol
and
api.
So
it's
not
something
that
is
fully
API
dependent.
So
it
also
looks
at
the
if
you've
read
the
document.
It
also
looks
at
the
text
in
the
protocol
and
you
don't
necessarily
need
an
API
description.
We
could
use
a
generic,
API
or
abstract
API
to
be
able
to
derive
the
services.
C
F
H
C
B
If
you
can
get
sctp
end
to
end
and
if
you
can't
fall
back
to
tcp
and
if
tcp
doesn't
work,
you
fall
back
to
http
over
tcp
or
something
like
that,
and
so
it
was
not
about
composition
of
the
the
elements
of
what
an
individual
protocol
provides.
But
the
goal
was
to
allow
selection
of
the
the
to
use
the
best
protocol
you
can.
But
if
you
that
would
work,
end-to-end
I
think
that
there's
the
analysis
that
we've
done
so
far
can
support
many
other
approaches.
But
that
was
the
problem
that
I
understood.
B
You
know
in
our
original
problem
state
of
what
we're
trying
to
accomplish,
and
so
it
seems
to
me
that
this
this
goes
towards.
That
of
being
able
to
articulate
you
want
to
be
able
to
say
an
advocate,
you
want
an
application,
be
able
to
say
what
it
wants
in
a
way
that
you
can
reasonably.
So
you
don't
say:
oh
ok!
Well,
this
had
a
protocol
we'll
meet
the
needs
of
this
application,
but
these
ones
won't
so
I'll.
Try.
You
know
the
best
of
these
until
I
find
one
that
works.
I.
D
Wanted
me
a
clearing
I
want
to
add
something
to
it,
because
it
might
be
even
simpler
than
just
a
fallback.
For
example,
it
might
be
just
providing
a
good
interface
to
chose
the
right
protocol
instead
of
giving
the
application
designer
name,
you
have
to
choose
between
those
two
adecuada
calls,
and
they
don't
even
know
what
the
protocols
do
so
I've
I've
talked
to
application
designers
who
ask
me,
should
I
use
HTTP
or
should
I
use
TCP
and,
like
that's
the
interface,
which
is
not
really
good?
Well
understandable
for
them
so
does
it
makes.
B
It
seems
to
me
that
once
you've
done
that
you
can
go
and
stay
all
right
now.
It
now
I'm
going
to
build
underneath
this,
instead
of
just
using
existing
protocols,
I'm
going
to
create
some
new
set
of
composable
pieces
that
support
the
same
API,
but
that
to
me
is
is
a
more
ambitious
goal
than
one
this
group
is
trying
to
solve.
F
Melius
example,
because
I
having
concrete
examples
are,
that
is
very
useful.
Ok,
so
you
have
an
application
and
the
application
designer
is
choosing
between
using
tcp
and
using
HTTP.
They
typically
do
not
choose
that,
because
TCP
provide
the
stream
of
data
and
HTTP
providing
a
gatepost
pragma.
They
choose
that
because
they
are
concerned
about
getting
to
firewalls
or
they
choose
that
because
they
are
concerned
about
hitting
the
road
balancer
in
the
server
farm,
all
those
issues
that,
because
they
want
to
do
a
specific
trade
off
between
overhead
and
facilities.
F
D
Mean
that
the
kind
of
examples
you
gave
just
is
the
stuff
we
actually,
that
should
be
represented
in
the
interface,
but
in
like
in
this
example
I
just
brought.
It
was
even
easier,
like
the
application
designer
just
used
some
kind
of
library,
and
that
was
the
two
choices
he
had
and
he
he
couldn't
make
anything
for
it
out
of
it.
F
I
I
have
seen
concrete
examples
of
doing
an
application
and
having
to
choose
mean
what
kind
of
api
I
use
and
people
do
all
kinds
of
stuff,
but
typically
they
start
with
adding
consideration
of
implementation.
Consideration
of
firewall
traversal
consideration
of
overhead
meant
more
than
and
then
and
then
once
once
you
can
pass
data
on
and
then,
if
you
don't
have
multiplexing,
you
can
do
it
yourself
and
sings
about
it.
They
do
it.
A
E
E
But
what
Christian
said
that,
when
you
are
making
a
choice
about
which
interfaces
you're
going
to
look
at
in
order
to
do
this
decomposition
recomposition
exercise,
which,
by
the
way
I
think
is
a
really
cool
exercise
and
I-
was
really
happy
to
see
the
features
that
fell
out
of
this,
because
that
gives
us
for
those
features
that
show
up
both
in
the
in
the
working
group
document
taps
transports
list
and
your
list.
We
now
have
a
lot
more
confidence
that
those
are
probably
features
that
we
care
about
right.
E
E
The
choice
to
concretely
I
could
say
the
choice
to
use
and
I'm
going
to
get
the
numbers
wrong.
The
sctp
protocols,
abstract
API
versus
the
sctp
sockets
API,
is
a
completely
arbitrary
choice
and
it
would
be
interesting
to
me
to
see
what
results
you
would
get
for
sctp.
If,
as
Karen
suggest,
you
use
the
socket
API
as
the
basis
and
not
the
abstract,
API
I,
don't
know
that
you'll
get
a
different
answer.
You
Karen
believes
that
you
will.
She
knows
a
lot
more
about
sctp
than
I.
Do
is
so
yeah.
E
G
Quick
counter
remark:
I
mean
I'm
I'm,
not
saying
that
things
are
going
to
fundamentally
change.
So
this
is
more
that
there
was
I
mean
there
are
comparisons
in
the
document.
That's
that's
just
plainly
wrong.
So
I
what
I'm
saying
that
the
sink?
Yes,
this
draft
will
change
but
I'm
not
saying
that
it
will
fundamentally
change
the
exercise
and
I
think
that's
important.
G
I
mean
that,
while
the
secretary
office
is
for
while
the
socket
API
for
HTTP
contains
a
lot
of
advanced
features,
I'm,
not
thinking
that
all
these
advanced
features
necessarily
would
go
in
here.
There's
just
right
now,
some
basic
things
that
are
specified
that
I've
see
with
another
the
one
that
you're
referring
to,
which
I
important
to
have
included.
E
And
then,
if
the
worse,
the
problem
is,
is
that
now,
when
you
compare
that
which
sounds
like
the
right
thing
to
do
to
the
TCP
abstract
API,
now,
you've
got
an
apples
and
oranges
problem,
and
I
wish
I
had
a
suggestion
for,
for
which
wrongly
shaped
orange,
to
compare
to
the
sctp.
You
should
pick,
and
I
don't
have
one
so.
H
This
is
not
an
API
oriented
document,
I
mean
we
use
api's,
but
but
I
mean
you
could
actually
use
the
normal
ctp
and
also
TCPS
RFC's
to
actually
get
that
so
so
this
is
not
a
100-person
api
oriented
document.
So
but
I
mean
you
could
use
any
of
those,
but
I
mean
depends
on
how
extensive
you
want
to
get
into
into
deriving
all
the
services
there.
So
so
far
I
mean
we
are
almost
converging
to
all
the
lists
that
are
in
the
tabs
transfer
document.
H
D
D
Actually
your
approach
as
you
presented,
it
sounds
very
tempting,
but
then,
if
you,
if
you
figure
and
then,
if
I
started
reading
document
I
said
a
green
document,
you
actually
try
to
do
actually
look
at
protocols
and
you
don't
really
apply
this
approach
so
clearly,
because
it
doesn't
get
you
so
far
and
and
I
think
that
both
approaches
cannot
guarantee
that
we
get
the
complete
list
of
features.
We
won't
might
always
miss
something
and
say
it
can
supplement
it,
but
at
the
moment,
I
still
don't
really
see
the
volume.
Putting
additional
effort
into
this
approach.
D
D
H
D
H
That
the
point
here
is
that,
if,
if
you
want
to
have
the
list
of
services,
that's
of
course
very
cool,
but
then
when
you
want
to
implement
something,
these
services
actually
mean
different
things
in
different
transfer
protocols.
So,
oh
let's
say
you
could
have
the
power
message:
reliability
in
a
ctp
and
that's
not
possible
to
do
that
in
TCP.
D
D
Yeah
but
I
mean
it
doesn't
mean
that
the
future
does
next
I
mean
future
itself
exists
somewhere.
So
we
should
spell
it
out
that
it
is
there
and
then,
in
the
second
step
in
the
second
document,
we
actually
look
at
this
list
of
features
where
we
know
that
we
cannot
provide
the
whole
choice
because
that's
currently
not
implemented
and
we
get
it
down
to
those
pieces
that
we
can
put
right
now
into
it
tabs
implementation
and
implement
right.
Now.
That's
for
me
step
2.
C
G
G
I
think
this
document
I
see
it
more
as
having
value
in
the
process
of
us
defining
the
types
API,
so
I
think
it's
good,
that
it
goes
a
step
deeper
than
the
other
document
for
us
to
have
more
concrete
information
and
also
to
perhaps
to
isolate
a
little
more
details
than
what
was
ended
in
the
in
the
other
document.
But
we
are
not
I
mean
you're,
not
at
all
tempting
to
go
into
all
the
details.
G
You
just
actually
just
specifying
a
few
more
details
and
trying
to
do
that
to
find
out
what
is
exactly
what
we
want
to
have.
What
so
I
for
me,
that's
exercise
is
useful
and
I
enjoyed
reading
the
document
and
I
enjoyed,
seeing
both
tcp
and
HTTP,
and
then
seeing
your
sort
of
your
comment.
You
want
them
in
the
end,
because
that
comment,
you
you
don't
get
from
this
transfer
document.
G
So
from
that
perspective,
I
I
support
the
effort,
but
I,
don't
I,
don't
see
it
as
as
as
as
an
effort
that
supports
the
work,
we're
doing
more
than
something
that
would
would
live
on,
necessarily
will
value
when
the
taps
APR
has
been
defined.
Then
I
have
a
different
comment.
That
I
don't
know
it's
about
the
TCP
API
it's
completed.
G
It
was
to
the
discussion
we
had
before
and
I
think
that
as
a
problem
presently
will
tcp
API
that
you're,
using
an
RFC
for
that
and
obviously
that's
very
old
and
which
was
outdated,
implementations
20
years
ago,
or
something
like
that
so
so
so
so
there
are
is
six.
So
there
is
a
problem
with
these
implementations
in
these
api's,
because
the
discussions
I
mean
very
concretely
about
the
push
and
the
urgent
bit
and
they're
not
implemented
as
they
are
written
in
the
rfcs
today
and
I.
G
G
E
So
hi
Corey
Fairhurst.
I
know
I
can't
I'm
not
even
going
to
try
to
do
an
impression,
so
I
do
think
this
is
very
useful
in
complements
the
description
and
taps
transports.
I,
don't
know
whether
he
can
replace
that
I
can
we
have
with
this,
but
I
do
think
we
can
learn
a
lot
more
with
this
approach
as
well.
The
other
protocols
for
this
document
should
definitely
be
kept
out
of
scope.
C
C
E
H
I
think
that's
actually
the
main
thing
that
I
wanted
to
discuss
today.
Basically,
we're
gonna
proceed
with
with,
including,
though
fount
there
but
I'm,
not
quite
sure,
with
DCC
p,
and
then
we
had
discussions
on
the
mailing
is
whether
we
need
to
to
include
this
or
not,
and
this
is
something
I
like
to
just
hear
from
the
group
and
how
to
proceed
with
this
so
make.
D
Living
again,
I
want
to
clarify
my
statement,
so
I
think
the
approach
makes
absolutely
sense
and
could
be
complimentary.
But
then,
when
I
was
reading
a
protocol
I
had
the
feeling
that
you
don't
even
clear
the
fun
of
your
approach,
because
you
look
back
into
the
rfcs
and
the
protocol
description
whatever
and.
H
D
I'm
not
going
to
follow
Edward
and
I'm
not
objecting
against
its
efforts.
Oh
that's
right
and
then
on
the
DCCC
p
point
I
think
yeah,
it's
a
it's
like
it's
a
it's
not
very
well
used,
but
it
has
a
clear
intention
what
the
use
case
is
it.
There
is
no
some
attention
so
I
think
we
should
integrate
it.
I
agree.
B
H
B
B
First,
I
guess:
the
first
question
is
yeah.
Is
this:
should
this
be
a
working
group
document
and
then
we
can
talk
about
if
we
think
it's
a
working
group
document
what
we
think
should
be
in
it,
so
how
many
people
have
read
this
document?
Let's
just
see
how
informed
the
group
is
here:
mm,
okay,
well,
everybody!
The
microphone
appears
to
have
read
the
document.
B
Okay,
yes,
that's
a
very
good
sign
right.
So
does
anybody
so
who
thinks
that
we
should
adopt
this
as
a
working
group
document?
Yeah
all
right?
Let's
sorry
not
show
Vance,
but
if
you
think
we
should
adopt
this
as
a
working
group
document,
all
right,
a
subtle
hum
who
thinks
we
should
not
adopt
this
as
a
working
group
document.
B
C
E
B
B
C
B
We're
adding
a
new
deliverable
I,
don't
think
we're
changing
the
scope
of
the
Charter.
You
know,
I
think
we
want
to
publish
I,
think
we're
going
to
work
on
this
document
and
publish
it
as
an
RFC.
Do
we
have
to
have
a
document
listed
as
a
milestone
in
order
to
publish
it
as
an
RFC?
It's
the
process,
question.
B
C
And
and
my
thing,
glass,
a
is
just
to
be
kind
of
clear
on
which
one
of
those
things
is
true,
because
I
was
kind
of
hearing
that
that
might
be
a
different
deliverable
to
documents
to
do
the
same
deliverable
you
know,
that's
that's
one
thing
in
the
Charter,
because
those
those
show
up
is
milestones
which
you
know
like
you
and
I
negotiate.
Basically,
but
if
we
you
know,
if
it's
changing
the
deliverables,
you
know
what
is
actually
being
delivered.
That's
charter
takes
change
so
that
that's
going
to
the
wider
community
so.
B
I
believe
that
we
have
not
that
that
the
goal
of
this
document
has
is
not
to
change
the
scope
of
what
the
group
is
trying
to
accomplish
and
what
we,
what
we've
discovered
is
that
you
know
it
takes
two
drafts
to
do
it.
So
to
me
this
is
not
a
scope
change,
it's
not
it's,
not
a
change
in
the
in
what
the
in
the
Charter
so
and
I'm
opened.
If
people
want
to,
if
we
people
won't,
have
a
discussion
of
this
and
so
I
think
at
that
point,
it's
we've
lost
Spencer's
attention.
D
C
B
C
B
C
B
C
Know
so,
back
to
back
to
Spencer
and
I
like
say,
I
was
a
little
confused
by
the
answers
I
was
giving
or
whether
this
required
a
change
to
the
deliverables
or
not.
If
the
answer
is,
it
doesn't
change
the
deliverables
you're
just
going
to
use
two
documents
to
says
that
one
of
the
deliverables
Spencer
things
that
could
be
the
right
answer.
Spencer
thinks
that
re
chartering
to
do
stuff-
that's
not
on
the
Charter
now
would
be
conversation
I'd
like
to
have
it's
not
a
conversation.
C
B
All
right,
good,
well,
I,
think
we're
on
the
same
page
here
we
okay,
so
now
we're
working
on
a
new
document.
So
there
has
been
there's
a
proposal
on
the
slide,
which
I
think
only
gori
has
expressed
an
opinion
on,
which
is
that
the
existing
draft
is
extended
to
include
the
protocols
in
bold
and
not
the
ones
that
are
listed
at
the
bottom
of
the
slide.
And
does
anybody
have
any
input
on
that.
E
E
B
H
B
B
D
D
C
B
I
Very
glad
we
have
come
to
a
consensus
regarding
the
document
one,
but
I'll
try
to
shed
some
light
on
how
to
get
further
on
this.
So
next
slide-
and
this
is
over
the
protocol
stack.
We
are
working
on
application
on
the
top
/
transport
protocols
in
the
bottom
and
the
tab
system
in
the
middle.
I
guess
we
all
agree
on
that
and
I've
just
quoted
few
words
from
from
our
Charter,
which
says
that
we
are
to
describe
an
abstract
interface
that
the
applications
can
use
in
order
to
get
to
the
right
protocols.
I
I
I
Writing
a
draft
yessing
tabs
minimal
set,
and
in
that
draft
we
we
found
a
minimal
set.
We
tried
to
find
a
minimal
set
of
features
that
be
used
as
a
starting
point
to
define
document
to,
but
what
we
found
was
that
that
minimal
set
was
maybe
not
very
productive
in
going
further
in
order
to
fulfill
our
charter
to
to
be
able
to
implement
the
tabs
system
up
there.
I
So,
in
my
mind,
I'm,
not
part
of
this
other
graph
that
we
have
discussed
today,
but
I
think
the
reason
they
started
to
do
that
next
slide
was
to
find.
How
can
we
use
the
transport
protocols
because,
in
order
to
implement
the
type
systems,
you
need
an
interface
to
the
transport
protocol
and
that's
what
draft
will
this?
I
But
then
how
do
we
go
on
further
in
order
to
make
document
to
and
fulfill
our
charter
next
slide?
I
think
we
need
to
make
document
to
mainly
based
on
draft
whistle,
because
in
document
to
in
order
to
get
further
I
think
we
need
to
have
this
minimal
set
of
interfaces
between
a
top
system
and
the
tradeboard
protocols.
I
This
picture
up,
I
I,
couldn't
resist
to
also
next
slide,
see
where
I
see
your
picture,
where
I
see
the
documentary,
because
we
are
going
to
describe
an
abstract
interface,
as
it
says
in
our
charter
document,
to
your
course
has
to
describe
this
abstract
interface
at
the
top
between
the
application
and
the
tabs
system
and
I.
Think
documentry
then
needs
a
document
to
that.
This
finds
the
other
interface
between
tabs
and
the
transport
protocols.