Subject: [Taps] TAPS charter rev 20140818

From: Aaron Falk <[email-masked]>
Date: Mon, 18 Aug 2014 20:37:37 -0400

Hi Folks-

We received a bit more charter input from the IAB and I've incorporated it
into the draft below.  Diffs against the last rev and the version submitted
for IETF comment are also attached (as usual).  The IESG will be taking up
approval of the TAPS working group at their telechat on August 28 so
comments, including support, are appreciated.

Regards,

--aaron

------

Last updated 2014-08-18

Transport Services (taps)

The vast majority of Internet applications make use of the Transport
Services provided by TCP (a reliable, in-order stream protocol) or UDP (an
unreliable datagram protocol). We use the term "Transport Service" to mean
an end-to-end facility provided by the transport layer that can only be
correctly provided with information from the application. This information
may be provided at design time, compile time, or run time.  Additionally,
it may include guidance from the application on whether the facility in
question is required or simply a preference by the application. Four
examples of Transport Services are reliable delivery, no guarantee of order
preservation, content privacy to in-path devices, and minimal latency.

Other transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and
UDP-Lite and the LEDBAT congestion control mechanism extend the set of
available Transport Services beyond those provided to applications by TCP
and UDP. For example, SCTP provides potentially faster (than TCP) reliable
delivery for applications that can accept blocks of data out of order, and
LEDBAT provides low-priority "scavenger" communication.

Application programmers face difficulty when they use protocols other than
TCP or UDP. Most network stacks ship with only TCP and UDP as transport
protocols.  Many firewalls only pass TCP and UDP and some only support HTTP
over TCP. As a result, using other transport protocols or building a new
protocol over raw sockets, risks having an application not work in many
environments. Applications, therefore, must always be able to fall back to
TCP or UDP, or even HTTP in many cases, and once the application programmer
has committed to making an application work on TCP or UDP or HTTP, there is
little incentive to try other transport protocols before falling back.
Further, different protocols can provide the same services in different
ways. Layering decisions must be made (for example, whether a protocol is
used natively or tunneled through UDP).

Because of these complications, programmers often resort to either using
TCP or HTTP, or implementing their own customized "transport services" over
UDP. When application developers re-implement transport features already
available elsewhere, they open the door to problems that simply using TCP
would have avoided, and ensure that the applications can't benefit from
other transport protocols as they become available.

Because even TCP and UDP are not guaranteed to work in all environments
today, some programmers simply give up on using TCP or UDP directly,
relying instead on "HTTP as a Substrate". BCP 56 identified many issues
with this strategy, but assuming that if "any protocol is available on a
given network path and on the hosts that will be communicating, that
protocol will be HTTP" is a reasonable strategy for today's Internet. The
IESG has agreed with this viewpoint enough to publish the WebSocket
protocol on the standards track.

The goal of the TAPS working group is to help application and network stack
programmers by describing an (abstract) interface for applications to make
use of Transport Services. The Working Group deliverables emphasize
defining Transport Services that are important to applications followed by
experimental mechanisms to a) determine if the protocols to provide the
requested services are available on the end points and supported along the
path in the network and b) fall back, i.e., select alternate, possibly
less-preferred, protocols when desired protocols are not available. The
Working Group will not define a richer set of Transport Services for
applications, although the TAPS deliverables could inform proposals for
future chartered work on Transport Services.

The Working Group will:

1) Define a set of Transport Services, prioritizing those provided by
existing IETF protocols and congestion control mechanisms. As a starting
point, the working group will consider services used between two endpoints.

2) Note that not all capabilities of IETF Transport protocols need to be
exposed as Transport Services. This document will recommend the minimal set
of Transport Services for inclusion in the abstract API. The resulting
document will also provide guidance on making a choice among available
mechanisms and protocols to obtain a certain Transport Service.

3) Specify experimental support mechanisms to provide the Transport
Services identified in work item 2. This document will explain how to
select and engage an appropriate protocol and how to discover which
protocols are available for a given connection. Further, it will provide a
basis for incremental deployment. The associated milestone will be
scheduled and work on this document will begin when the TAPS Transport
Services have been specified.

The following topics are out of scope for this Working Group:

- Signaling-based Quality-of-Service (QoS) mechanisms

- Definition of new encapsulations and tunneling mechanisms

- Extension, modification, or creation of existing IETF transport protocols

- Language-specific APIs

TAPS is not chartered to perform detailed analysis of the security aspects
of transport protocols, but TAPS is being chartered almost simultaneously
with TCPINC, which is developing the TCP extensions to provide
unauthenticated encryption and integrity protection of TCP streams, and
TAPS will work with TCPINC to ensure that TAPS will be able to accommodate
the protocol extensions that TCPINC defines.

Milestones:

M9: Submit to the IESG an Informational document defining a set of services
provided by IETF transport protocols and congestion control mechanisms.
M15: Submit to the IESG an Informational document recommending a minimal
set of Transport Services that end systems should support.
M18: Recharter or close.

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 09:27:06 +0200

Dear all,

I'm surprised by the number of changes to the charter at this late stage. One particular change strikes me as quite significant: the following milestone was removed:

***
M18: Submit specification of how the transport services can be provided to IESG.
***
...and instead there is now text in the charter saying "The associated milestone will be scheduled and work on this document will begin when the TAPS Transport Services have been specified".

What's the point of this? Is it a concern about the time line? Milestone dates can be changed, if they must, but I think it's important that the charter contains the milestone, as a dedication to actually develop a workable solution, not just a list of things. The way it stands now, all the group produces is a long list and a shorter list. Not what most members of the group here wanted, I think. I object to this removal.

Cheers,
Michael

On 19. aug. 2014, at 02:37, Aaron Falk wrote:

> Hi Folks-
> 
> We received a bit more charter input from the IAB and I've incorporated it into the draft below.  Diffs against the last rev and the version submitted for IETF comment are also attached (as usual).  The IESG will be taking up approval of the TAPS working group at their telechat on August 28 so comments, including support, are appreciated.
> 
> Regards,
> 
> --aaron
> 
> ------
> 
> Last updated 2014-08-18
> 
> 
> The vast majority of Internet applications make use of the Transport Services provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer that can only be correctly provided with information from the application. This information may be provided at design time, compile time, or run time.  Additionally, it may include guidance from the application on whether the facility in question is required or simply a preference by the application. Four examples of Transport Services are reliable delivery, no guarantee of order preservation, content privacy to in-path devices, and minimal latency.
> 
> Other transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite and the LEDBAT congestion control mechanism extend the set of available Transport Services beyond those provided to applications by TCP and UDP. For example, SCTP provides potentially faster (than TCP) reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. 
> 
> Application programmers face difficulty when they use protocols other than TCP or UDP. Most network stacks ship with only TCP and UDP as transport protocols.  Many firewalls only pass TCP and UDP and some only support HTTP over TCP. As a result, using other transport protocols or building a new protocol over raw sockets, risks having an application not work in many environments. Applications, therefore, must always be able to fall back to TCP or UDP, or even HTTP in many cases, and once the application programmer has committed to making an application work on TCP or UDP or HTTP, there is little incentive to try other transport protocols before falling back. Further, different protocols can provide the same services in different ways. Layering decisions must be made (for example, whether a protocol is used natively or tunneled through UDP). 
> 
> Because of these complications, programmers often resort to either using TCP or HTTP, or implementing their own customized "transport services" over UDP. When application developers re-implement transport features already available elsewhere, they open the door to problems that simply using TCP would have avoided, and ensure that the applications can't benefit from other transport protocols as they become available. 
> 
> Because even TCP and UDP are not guaranteed to work in all environments today, some programmers simply give up on using TCP or UDP directly, relying instead on "HTTP as a Substrate". BCP 56 identified many issues with this strategy, but assuming that if "any protocol is available on a given network path and on the hosts that will be communicating, that protocol will be HTTP" is a reasonable strategy for today's Internet. The IESG has agreed with this viewpoint enough to publish the WebSocket protocol on the standards track. 
> 
> The goal of the TAPS working group is to help application and network stack programmers by describing an (abstract) interface for applications to make use of Transport Services. The Working Group deliverables emphasize defining Transport Services that are important to applications followed by experimental mechanisms to a) determine if the protocols to provide the requested services are available on the end points and supported along the path in the network and b) fall back, i.e., select alternate, possibly less-preferred, protocols when desired protocols are not available. The Working Group will not define a richer set of Transport Services for applications, although the TAPS deliverables could inform proposals for future chartered work on Transport Services. 
> 
> The Working Group will:
> 
> 1) Define a set of Transport Services, prioritizing those provided by existing IETF protocols and congestion control mechanisms. As a starting point, the working group will consider services used between two endpoints.
> 
> 2) Note that not all capabilities of IETF Transport protocols need to be exposed as Transport Services. This document will recommend the minimal set of Transport Services for inclusion in the abstract API. The resulting document will also provide guidance on making a choice among available mechanisms and protocols to obtain a certain Transport Service. 
> 
> 3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2. This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for a given connection. Further, it will provide a basis for incremental deployment. The associated milestone will be scheduled and work on this document will begin when the TAPS Transport Services have been specified. 
> 
> TAPS is not chartered to perform detailed analysis of the security aspects of transport protocols, but TAPS is being chartered almost simultaneously with TCPINC, which is developing the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams, and TAPS will work with TCPINC to ensure that TAPS will be able to accommodate the protocol extensions that TCPINC defines. 
> 
> Milestones: 
> 
> M9: Submit to the IESG an Informational document defining a set of services provided by IETF transport protocols and congestion control mechanisms.
> M15: Submit to the IESG an Informational document recommending a minimal set of Transport Services that end systems should support.
> M18: Recharter or close.
> 
> 
> <charter-diff-20140717-20140818.pdf><charter-diff-20140726-20140818.pdf>_______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Brian Trammell <[email-masked]>
Date: Tue, 19 Aug 2014 11:32:33 +0200

Hi Aaron,

Following some (i.e. extensive) hallway discussion in Toronto to Thursday, I'd make one following suggested changes to this draft charter, inline.

> M15: Submit to the IESG an Informational document recommending a minimal set of Transport Services that end systems should support.

Per the third point of the charter, I think we want to add the third milestone back, but make clear that the effort is experimental; something like:

M18: Submit to the IESG an Experimental document exploring abstract interfaces to Transport Services, and defining an experiment to evaluate such interfaces for applicability to common application design patterns and incremental deployability

> M18: Recharter or close.

I recommend we keep this milestone as well.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 11:41:36 +0200

Hi Brian, thanks getting into this discussion!

In line below:

> M18: Submit to the IESG an Experimental document exploring abstract interfaces to Transport Services, and defining an experiment to evaluate such interfaces for applicability to common application…

I think this is a significant change to the wording that we had during IETF open review, which was:

I'd be fine with the status of this document explicitly being Experimental, as it was before, see:
https://sites.google.com/site/transportprotocolservices/charter-proposal/charter-before-london
i.e. to change this back to:

M18: Submit Experimental specification of how the transport services can be provided to IESG.

...but your wording seems to be an entirely different thing: exploring abstract interfaces? defining an experiment to evaluate them for applicability to app design patterns? This is really something else. Why do you propose such a change at this late stage? Who else wants that, and why?

> I recommend we keep this milestone as well.

+1. That one wasn't ever debated I think. Fine.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Tue, 19 Aug 2014 12:07:53 +0200

> On 19. aug. 2014, at 11:32, Brian Trammell wrote:

<snipping away the vast majority of the charter we seem to agree on>

I think we need something a bit more specific than "submit specification of how the transport services can be provided to the IESG" -- since (for my part) I'm not really sure what that means. My wording is simply an attempt to take the language from the third "working group will" point and turn it into a milestone:

> 3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2.

i.e. "Submit to the IESG an Experimental document exploring..."

> This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for a given connection. 

"...abstract interfaces to Transport Services..." (since "how to select and engage" seems to me to very much be an abstract interface, maybe I'm reading it wrong)

> Further, it will provide a basis for incremental deployment. The associated milestone will be scheduled and work on this document will begin when the TAPS Transport Services have been specified. 

"...defining an experiment to evaluate such interfaces for... incremental deployability". (The bit about application design patterns is admittedly something I added to point out it's not _just_ incremental deployability we care about, but I would submit that if we're not building this in the hope that it addresses common application design patterns, then we can all go home.)

I'm of course open to better wording that captures point (3), this is just a first suggestion. And we do want something very open... but I think "Submit Experimental specification of how the transport services can be provided to IESG" is a bit too open.

Thoughts?

Cheers,

Brian

> _______________________________________________
> Taps mailing list
> [email-masked]

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 19 Aug 2014 12:09:16 +0200

Hi all,

Having read through the updated charter that Aaron circulated, I also 
find the removal of the third milestone a significant change and would 
like to see it back. From the discussion on the TAPS list, I think this 
has been a big part in motivating the interest for this work.

I also agree with Michael that if we want to indicate that the work is 
experimental (which is fine) we should just insert the word 
"Experimental" in the original milestone again. Brian, the meaning of 
your proposed new wording is very unclear to me as well.

Cheers,
Anna

On 2014-08-19 11:41, Michael Welzl wrote:
>> Following some (i.e. extensive) hallway discussion in Toronto to 
>> Thursday, I'd make one following suggested changes to this draft 
>> charter, inline.
>>
>> On 19 Aug 2014, at 02:37, Aaron Falk <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Hi Folks-
>>>
>>> We received a bit more charter input from the IAB and I've 
>>> incorporated it into the draft below.  Diffs against the last rev 
>>> and the version submitted for IETF comment are also attached (as 
>>> usual).  The IESG will be taking up approval of the TAPS working 
>>> group at their telechat on August 28 so comments, including support, 
>>> are appreciated.
>>>
>>> Regards,
>>>
>>> --aaron
>>>
>>> ------
>>>
>>> Last updated 2014-08-18
>>>
>>>
>>> Services provided by TCP (a reliable, in-order stream protocol) or 
>>> UDP (an unreliable datagram protocol). We use the term "Transport 
>>> Service" to mean an end-to-end facility provided by the transport 
>>> layer that can only be correctly provided with information from the 
>>> application. This information may be provided at design time, 
>>> compile time, or run time.  Additionally, it may include guidance 
>>> from the application on whether the facility in question is required 
>>> or simply a preference by the application. Four examples of 
>>> Transport Services are reliable delivery, no guarantee of order 
>>> UDP-Lite and the LEDBAT congestion control mechanism extend the set 
>>> of available Transport Services beyond those provided to 
>>> applications by TCP and UDP. For example, SCTP provides potentially 
>>> faster (than TCP) reliable delivery for applications that can accept 
>>> blocks of data out of order, and LEDBAT provides low-priority 
>>> "scavenger" communication.
>>>
>>> Application programmers face difficulty when they use protocols 
>>> other than TCP or UDP. Most network stacks ship with only TCP and 
>>> UDP as transport protocols.  Many firewalls only pass TCP and UDP 
>>> and some only support HTTP over TCP. As a result, using other 
>>> transport protocols or building a new protocol over raw sockets, 
>>> risks having an application not work in many environments. 
>>> Applications, therefore, must always be able to fall back to TCP or 
>>> UDP, or even HTTP in many cases, and once the application programmer 
>>> has committed to making an application work on TCP or UDP or HTTP, 
>>> there is little incentive to try other transport protocols before 
>>> falling back. Further, different protocols can provide the same 
>>> services in different ways. Layering decisions must be made (for 
>>> example, whether a protocol is used natively or tunneled through UDP).
>>>
>>> Because of these complications, programmers often resort to either 
>>> using TCP or HTTP, or implementing their own customized "transport 
>>> services" over UDP. When application developers re-implement 
>>> transport features already available elsewhere, they open the door 
>>> to problems that simply using TCP would have avoided, and ensure 
>>> that the applications can't benefit from other transport protocols 
>>> as they become available.
>>>
>>> Because even TCP and UDP are not guaranteed to work in all 
>>> environments today, some programmers simply give up on using TCP or 
>>> UDP directly, relying instead on "HTTP as a Substrate". BCP 56 
>>> identified many issues with this strategy, but assuming that if "any 
>>> protocol is available on a given network path and on the hosts that 
>>> will be communicating, that protocol will be HTTP" is a reasonable 
>>> strategy for today's Internet. The IESG has agreed with this 
>>> viewpoint enough to publish the WebSocket protocol on the standards 
>>> track.
>>>
>>> The goal of the TAPS working group is to help application and 
>>> network stack programmers by describing an (abstract) interface for 
>>> applications to make use of Transport Services. The Working Group 
>>> deliverables emphasize defining Transport Services that are 
>>> important to applications followed by experimental mechanisms to a) 
>>> determine if the protocols to provide the requested services are 
>>> available on the end points and supported along the path in the 
>>> network and b) fall back, i.e., select alternate, possibly 
>>> less-preferred, protocols when desired protocols are not available. 
>>> The Working Group will not define a richer set of Transport Services 
>>> for applications, although the TAPS deliverables could inform 
>>> proposals for future chartered work on Transport Services.
>>>
>>> The Working Group will:
>>>
>>> 1) Define a set of Transport Services, prioritizing those provided 
>>> by existing IETF protocols and congestion control mechanisms. As a 
>>> starting point, the working group will consider services used 
>>> between two endpoints.
>>>
>>> 2) Note that not all capabilities of IETF Transport protocols need 
>>> to be exposed as Transport Services. This document will recommend 
>>> the minimal set of Transport Services for inclusion in the abstract 
>>> API. The resulting document will also provide guidance on making a 
>>> choice among available mechanisms and protocols to obtain a certain 
>>> Transport Service.
>>>
>>> Services identified in work item 2. This document will explain how 
>>> to select and engage an appropriate protocol and how to discover 
>>> which protocols are available for a given connection. Further, it 
>>> will provide a basis for incremental deployment. The associated 
>>> milestone will be scheduled and work on this document will begin 
>>> when the TAPS Transport Services have been specified.
>>>
>>> TAPS is not chartered to perform detailed analysis of the security 
>>> aspects of transport protocols, but TAPS is being chartered almost 
>>> simultaneously with TCPINC, which is developing the TCP extensions 
>>> to provide unauthenticated encryption and integrity protection of 
>>> TCP streams, and TAPS will work with TCPINC to ensure that TAPS will 
>>> be able to accommodate the protocol extensions that TCPINC defines.
>>>
>>> Milestones:
>>>
>>> M9: Submit to the IESG an Informational document defining a set of 
>>> services provided by IETF transport protocols and congestion control 
>>> mechanisms.
>>> M15: Submit to the IESG an Informational document recommending a 
>>> minimal set of Transport Services that end systems should support.
>>
>> Per the third point of the charter, I think we want to add the third 
>> milestone back, but make clear that the effort is experimental; 
>> something like:
>>
>> M18: Submit to the IESG an Experimental document exploring abstract 
>> interfaces to Transport Services, and defining an experiment to 
>> evaluate such interfaces for applicability to common application 
>> design patterns and incremental deployability
>
> ...but your wording seems to be an entirely different thing: exploring 
> abstract interfaces? defining an experiment to evaluate them for 
> applicability to app design patterns? This is really something else. 
> Why do you propose such a change at this late stage? Who else wants 
> that, and why?
>
>
>>> M18: Recharter or close.
>>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 13:40:54 +0200

> "...abstract interfaces to Transport Services..." (since "how to select and engage" seems to me to very much be an abstract interface, maybe I'm reading it wrong)

I'm pretty sure that the whole phrase was meant to mean some form of "Happy Eyeballs++ for transports". I think this is obvious for the second half ("discover which protocols are available..."), but end-to-end, more than that is required. If Happy Eyeballs gives me a TCP response before it gives me a protocol X response that I'm hoping for, do I wait or just use X later in case it arrives? And: do we need to tell the other end what we're doing? Find out what the other side is even capable of?  (for some services we do, for some we don't).

We can now start wordsmithing to try to put this into clearer words, but I didn't think this is the right time to do that... we've been wordsmithing so much?!  and I have trouble interpreting the phrase as an "abstract interface", frankly, but this may be just me who has looked at the text from one particular angle for so long.

> "...defining an experiment to evaluate such interfaces for... incremental deployability". (The bit about application design patterns is admittedly something I added to point out it's not _just_ inc…

We've been around the "common application application design patterns" block, see Martin Sustrik's presentation in London, the minutes, and extensive list discussion on that topic. This didn't culminate in charter text and I'd suggest to not insert such text now.

> I'm of course open to better wording that captures point (3), this is just a first suggestion. And we do want something very open... but I think "Submit Experimental specification of how the transp…

Personally I think this is less open than the wording you suggested, but that's just me not understanding what you even mean with "abstract interface", and inserting something about application design patterns doesn't exactly make it clearer I think.

I tried to explain what was meant with the original text but haven't made a text proposal. If we must change the text then I'd welcome proposals from others. But I seriously wonder if we *really* have to, and *really* should, at this point: with every change we insert, one person that liked things as they were during IESG review or IETF review might then not like the text anymore. I guess we should do only very minor changes at this late stage, and I don't actually think what we're now discussing is so minor.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Tue, 19 Aug 2014 14:01:16 +0200

> I'm pretty sure that the whole phrase was meant to mean some form of "Happy Eyeballs++ for transports". I think this is obvious for the second half ("discover which protocols are available..."), bu…

ACK.

> We can now start wordsmithing to try to put this into clearer words, but I didn't think this is the right time to do that... we've been wordsmithing so much?!  and I have trouble interpreting the p…

So to me the abstract interface is how the application specifies what things should get happy eyeballs'd (since trying to figure out if we can get PR-SCTP down the path is pointless if we don't want retransmission at all). I know we don't belong to the the billion-knobs school of transport configuration here, but the app needs to be able to specify what it expects. 

(Further down the program -- in the bit of the work we specifically agreed not to do yet because views start diverging wildly -- there's the question of how to broaden out the interface beyond establishment time.)

> We've been around the "common application application design patterns" block, see Martin Sustrik's presentation in London, the minutes, and extensive list discussion on that topic. This didn't culm…

ACK. Though we still need language that makes it clear that it's applications that are expected to make use of the transport services we specify.

> Personally I think this is less open than the wording you suggested, but that's just me not understanding what you even mean with "abstract interface", and inserting something about application des…

Okay. I can't really understand how I would evaluate whether a given document provides a "specification of how the transport services can be provided", but as long as the WG and the chairs can, then that doesn't really matter.

One English as well: "can be provided" really reads here as though it binds to "to the IESG". We're not trying to provide transport services to the IESG. :) So I'd say at minimum we need to make this point parallel to the others, and point out the apps-are-our-users bit:

M18: Submit to the IESG an Experimental document specifying methods for providing the Transport Services identified by the WG to applications.

How's that?

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 14:10:57 +0200

> (Further down the program -- in the bit of the work we specifically agreed not to do yet because views start diverging wildly -- there's the question of how to broaden out the interface beyond esta…

Well...  the group started out wanting to do an API. After grinding by the IETF mill, this became the first two documents: lists of services. So we shouldn't go down that path again, I'm afraid (don't get me wrong, I'd like to see an API; we had it in there once, as another Informational RFC, but someone asked to have it removed; maybe this is one of the things we can consider defining when we recharter?).

> ACK. Though we still need language that makes it clear that it's applications that are expected to make use of the transport services we specify.

Isn't that obvious? Who else would?

> M18: Submit to the IESG an Experimental document specifying methods for providing the Transport Services identified by the WG to applications.

Fine by me (and thanks for the fix).

Cheers,
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 19 Aug 2014 17:27:44 +0200

On 2014-08-19 14:01, Brian Trammell wrote:

<snip>

> M18: Submit to the IESG an Experimental document specifying methods 
> for providing the Transport Services identified by the WG to 
> applications. How's that? Cheers, Brian 

Sounds good to me as well.

Cheers,
Anna

---

From: Toby Moncaster <[email-masked]>
Date: Tue, 19 Aug 2014 16:31:26 +0100

I’d be happier with rephrasing it slightly as:

M18: Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG.

On 19 Aug 2014, at 16:27, Anna Brunstrom <[email-masked]> wrote:

>> M18: Submit to the IESG an Experimental document specifying methods for providing the Transport Services identified by the WG to applications. How's that? Cheers, Brian 
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 19 Aug 2014 15:32:25 +0000

I agree.
________________________________________
From: Taps [[email-masked]] on behalf of Toby Moncaster [[email-masked]]
Sent: Tuesday, August 19, 2014 11:31 AM
To: Anna Brunstrom
Cc: [email-masked]
Subject: Re: [Taps] TAPS charter rev 20140818

---

From: Brian Trammell <[email-masked]>
Date: Tue, 19 Aug 2014 17:32:50 +0200

hi Toby,

> M18: Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG.

Works for me.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 18:00:22 +0200

+1.

Now, we can perhaps head on to the other charter changes related to this re-inserted milestone. I suggest the following undo's => I mean going back from THIS VERSION to the PREVIOUS VERSION, which is the version that went to IETF review:

THIS VERSION:

PREVIOUS VERSION:
2) Note that not all capabilities of IETF Transport protocols need to be exposed as Transport Services. This document will recommend the minimal set of Transport Services that support mechanisms must provide (such as those in work item 3). The resulting document will also provide guidance on making a choice among available mechanisms and protocols to obtain a certain Transport Service. 

a bit below, for item 3 (last sentence):

THIS VERSION:
The associated milestone will be scheduled and work on this document will begin when the TAPS Transport Services have been specified. 

PREVIOUS VERSION:
Work on this document will begin when the TAPS Transport Services have been specified. 

Not relevant to this particular discussion, but a suggested minor change nevertheless, for the out-of-scope list:

THIS VERSION:

PREVIOUS VERSION:
- Extension, modification, or creation of transport protocols 

The only problem I have here is that "the creation of existing.... protocols" does not sound very logical. I suggest to remove "existing".

Cheers,
Michael

---

From: Toby Moncaster <[email-masked]>
Date: Tue, 19 Aug 2014 17:13:37 +0100

> 2) Note that not all capabilities of IETF Transport protocols need to be exposed as Transport Services. This document will recommend the minimal set of Transport Services that support mechanisms mu…

I actually now think the previous version was a little clumsy. Also it sounds really weird to start this item with a note… This makes me suspect this item has been over-edited :)

Should we in fact say:

2) Define the minimal set of Transport Services that must be provided by mechanisms such as those to be specified in work item 3. The resulting document will give guidance on choosing from available mechanisms and protocols to provide a given Transport Service. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services.

> Work on this document will begin when the TAPS Transport Services have been specified. 

Agreed since we will already have the milestone scheduled

> The only problem I have here is that "the creation of existing.... protocols" does not sound very logical. I suggest to remove "existing”.

I’m guessing this was actually trying to cover 2 things: The creation of new protocols and the extension or modification of existing protocols.

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 21:51:11 +0200

> 2) Define the minimal set of Transport Services that must be provided by mechanisms such as those to be specified in work item 3. The resulting document will give guidance on choosing from availabl…

I agree, much better, and it's not a semantic change, just language.

> I’m guessing this was actually trying to cover 2 things: The creation of new protocols and the extension or modification of existing protocols.

Yes, sure - but my point is that the word "existing" doesn't need to be there to convey that complete message.

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Wed, 20 Aug 2014 10:54:12 -0400

>> 2) Define the minimal set of Transport Services that must be provided by mechanisms such as those to be specified in work item 3. The resulting document will give guidance on choosing from availab…

The problem here is that we haven’t described what work item 3 is.  I’d prefer a statement that stands on its own. If you don’t like my text above, please propose something you like better.

Trying to piece an alternate phrasing from the thread I get:

>> 3) Submit to the IESG an Experimental document exploring abstract interfaces to Transport Services and defining an experiment to evaluate such interfaces for incremental deployability.  The associated milestone will be scheduled and work on this document will begin when the TAPS Transport Services have been specified. 

This seems less concrete to me.  I like “select and engage protocols” but I’d like to hear more input from the group.

—aaron

---

From: Michael Welzl <[email-masked]>
Date: Thu, 21 Aug 2014 00:00:22 +0200

> The problem here is that we haven’t described what work item 3 is.  I’d prefer a statement that stands on its own. If you don’t like my text above, please propose something you like better.

Work item 3 is just the third item in the list, where the text you cite above is the 2nd item. If that isn't clear enough, we could replace the sentence above them:

The Working Group will:

with:

The Working Group will consider the following three work items:

In my opinion, the clearest version is in the charter that went to IETF open review:
***
- Specify the subset of those Transport Services, as identified in 
  item 1, that end systems supporting TAPS will provide, and give
  guidance on choosing among available mechanisms and protocols.
***

which you changed into the "work item 3" text on 26 July, i.e. during IETF open review, and documented in the diff file: "charter-diff-20140722e-20140726.pdf" that you sent to the list, and justified with:

"I've been working on a few changes that I think clarify the charter, particularly the document goals.  Since I wasn't part of the initial discussions I may have misunderstood where there is agreement.  For example, the role of the second document seems to be really about getting consensus on some requirements for the third."

I couldn't see any other input leading to this change. My suggestion would be to undo it.

> This seems less concrete to me.  I like “select and engage protocols” but I’d like to hear more input from the group.

What we did mean when we wrote this was "Happy Eyeballs ++". The Happy Eyeballs folks are on the list and have stated interest in continuing it here; there were ideas (all in the list archives..) on making it more scalable by using it later, i.e. no need to send out so much SYN-style traffic so fast; caching information; first asking the other side what protocols it supports to only test those that really must be tested. How to state this more clearly? Not sure. I think we were all quite happy with the "select and engage an appropriate protocol" sentence.

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Thu, 21 Aug 2014 10:29:29 -0400

> I couldn't see any other input leading to this change. My suggestion would be to undo it.

So, I admit that my understanding has been evolving over the course of the charter discussion and I’m perfectly willing to undo prior ‘improvements’ that I’ve made.   Anyone else want to weigh in?  

> What we did mean when we wrote this was "Happy Eyeballs ++". The Happy Eyeballs folks are on the list and have stated interest in continuing it here; there were ideas (all in the list archives..) o…

Ah!  I thought there was some objection to ‘select and engage’.  So, is the version from the last charter rev acceptable?

Addressing the matter of whether to include a scheduled milestone for the third document or not, let me make a suggestion.  I acknowledge and respect that there are several folks in the group invested in seeing work take place on the ‘engage & select’ mechanisms and I believe it is in the IETF’s interests in seeing that work mature.  (Indeed, I hope there are teams off busily working on implementations now.)  

However, as I’ve already made clear, the ‘distraction’ risk to the working group progress of a tantalizing research area is significant.  I would propose adding the milestone for the third doc with some chair ground rules: 

1. no agenda time will be allocated to that topic until the first two docs are mostly complete and stable (in the chair’s opinion)  

2. mailing list discussion of such topics during that period may be discouraged if it appears it is slowing progress on the docs 1 and 2.   

Spencer would need to approve this and I would want the group to back me up if (when) the time comes that some, er, discipline needs to be applied. 

Thoughts?

—aaron

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Aug 2014 17:51:52 +0200

hi, Aaron, all,

was just in the middle of trying to catch back up with this thread, thanks for giving me a point to hang this off of... :)

Speaking, as Spencer said, for myself (thanks, Spencer!)...

> 3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2. This document will explain how to select and engage an appropriate protocol and how to discov…

This works for me, and it seems to me like that's where we've converged (less the final sentence).

> Addressing the matter of whether to include a scheduled milestone for the third document or not, let me make a suggestion.  I acknowledge and respect that there are several folks in the group inves…

Agreed...

> However, as I’ve already made clear, the ‘distraction’ risk to the working group progress of a tantalizing research area is significant.

I think there's two points of risk here. One is distraction. On that point I'll admit that half the reason I reversed my position on this point during discussions in Toronto is that I became convinced that the risk of distraction itself is actually lower than the risk of breaking this whole process on arguments over distraction, so let's stick a milestone on the charter and rely on ourselves to keep things on track.

(The other point of risk is what makes this engineering-research: the approach might simply not provide much return, because the set of transports that can provide a given interface to are too limited, or because the diversity of path brokenness on the Internet is too narrow. I hope I'm being pessimistic when I say this, but hedging this bet is one of the reasons the IAB Stack Evolution program is exploring other divergent-but-related solutions to the problem, simultaneous with TAPS. Let's build the thing and find out, though. No rule I can find says we only get to try to solve the problem once. :) )

>  I would propose adding the milestone for the third doc with some chair ground rules: 

> 1. no agenda time will be allocated to that topic until the first two docs are mostly complete and stable (in the chair’s opinion)  

I'd say "on track" as opposed to "mostly complete"... For the first document, especially, there will probably be significant editing work (compiling subparts of the document from multiple contributors into a coherent whole -- I've already volunteered to help out here). So this document may be "ready" as far as its feed-in to the happy-transports stuff well before it's complete. The second document, probably less so.

> 2. mailing list discussion of such topics during that period may be discouraged if it appears it is slowing progress on the docs 1 and 2.   

I'm personally less comfortable with this restriction, mainly because it feels kind of punitive (of course, I'd say that the list should discuss anything it wants, except how bad the cookies at the snack breaks are).

Isn't it sufficient simply to gate the *submission* of the third milestone to the IESG on the *publication* of the first two?

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Thu, 21 Aug 2014 18:16:29 +0200

Hi,

> 3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2. This document will explain how to select and engage an appropriate protocol and how to discov…

Yes, except that I have requested and still request to remove the last sentence ("The associated milestone will be scheduled and work on this document will begin when the TAPS Transport Services have been specified. "), but this is what you address below.

> Spencer would need to approve this and I would want the group to back me up if (when) the time comes that some, er, discipline needs to be applied. 

I can understand your concern and have a neutral position on this; I guess there are pro's and con's either way... I'll leave this for others to discuss.

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 21 Aug 2014 15:24:15 -0500

I'm mostly trying to be helpful here, rather than trying to be an AD. 
Ideally, those aren't mutually exclusive, but ...

> I'd say "on track" as opposed to "mostly complete"... For the first document, especially, there will probably be significant editing work (compiling subparts of the document from multiple contribut…

Keeping in mind that we're trying to nail down jelly here, if I were 
co-chairing TAPS, and I'm not, I'd think the goal would be that we can't 
make additional progress on work that's already milestoned - if the 
working group can profitably work on meeting a milestone, that should 
have priority, but if the working group has been through the open 
issues, has a plan of action, and mostly needs to do homework before 
moving forward ... well, face-to-face time is precious, and I wouldn't 
want to send everybody I'm asking them to do home early because of a 
line in the charter.

But, and I can't emphasize this enough, Aaron (who I've asked to serve 
as co-chair) and his Co-chair Still To Be Named have to be comfortable 
with what the charter says the working group will do. So, take my 
opinion as a data point.

> Isn't it sufficient simply to gate the *submission* of the third milestone to the IESG on the *publication* of the first two?

This one is speaking as an AD - I would be surprised to see the third 
document (which executes the plan the first two documents come up with) 
passing the first two documents in IETF Last Call, but I'd encourage the 
charter to be permissive. Keeping in mind what I said about WG co-chairs 
and comfort, I could imagine that the hard restriction is that I don't 
see Publication Requested for the third document before the first two 
documents are *approved*, but I'm not seeing a reason to hold up the 
Experimental work while the document goes through RFC Editor editing, 
reference hold, or some other thing that gets in the way of an RFC 
appearing to the world.

Does that make sense?

Spencer