Subject: Re: [Taps] So, is this the -00 charter yet?

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Jun 2014 10:32:55 +0200

hi Spencer, all,

catching up on this thread in random-access order; replying only to the process question here...

On 30 May 2014, at 23:47, Spencer Dawkins <[email-masked]> wrote:

> 
> On 05/30/2014 11:46 AM, Joe Hildebrand (jhildebr) wrote:
>> On 5/30/14, 10:43 AM, "Gorry Fairhurst" <[email-masked]> wrote:
>> 
>>> Maybe I am hearing you wrong: My problem is that I'd argue that you are
>>> failing the WG before it starts, by somehow saying you can do the
>>> analysis and setup the stack, but that the group won't publish the
>>> networking specs that allow it to be used across a path to another
>>> system? Or are you saying the group shouldn't be chartered until it has
>>> a candidate solution for this? - Either way I think either I or you may
>>> be confused.
>> No, I'm suggesting the group recharter when it has a candidate solution.
>> Rechartering is relatively easy, particularly if you're showing signs of
>> success on the existing charter.
> 
> Hi, Joe et al.
> 
> So I'm not quite visualizing the proposal. Even rough text would help.
> 
> Guessing in anticipation of text arriving ... is the idea that the working group to be would develop however many proposals as seem useful, and then
> 
> IF one is blindingly obvious as the right thing to do
>  THEN publish as PS
> ELSE  IF people are willing to "experiment" with drafts
>  THEN experiment, and publish what works as PS
> ELSE publish one or more Experimental RFCs and let 100 implementations bloom?

Speaking for myself, it seems to me that this is exactly what Experimental RFCs _should_ be for, so I'd tend to lean toward a TAPS WG that publishes implementable proposals for partial or complete solutions to the transport evolution problem relatively quickly.

I do share (what I read as) Joe's concern that the road from I-D to even an experimental RFC tends to take a lot of energy that could be spend on other things, so maybe we have a set of I-Ds with intended status experimental that we only put the final energy into publication as an RFC when it becomes obvious we want to reference later.

(Whether all that belongs in _this_ charter as opposed to a subsequent one is an open question in my mind.)

Cheers,

Brian

> Or, if not, could you clue me in?
> 
> Thanks,
> 
> Spencer, who is quite pleased with the discussion so far
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 02 Jun 2014 10:35:47 -0500

> Speaking for myself, it seems to me that this is exactly what Experimental RFCs _should_ be for, so I'd tend to lean toward a TAPS WG that publishes implementable proposals for partial or complete…

I'd buy that.

> (Whether all that belongs in _this_ charter as opposed to a subsequent one is an open question in my mind.)

Practice varies across IESGs, but I believe this IESG is fine with 
saying "forward for publication" in the charter.

Obviously, whatever a working group forwards for publication should 
contain a recommended document category, but the IESG can move it to a 
more appropriate category if that's the right thing to do, even after 
IETF Last Call, so don't spend a lot of angst on that.

Spencer

p.s. the only critical thing is that we do a Last Call at the highest 
level category we're considering. If you request publication on a PS 
that needs to be Experimental, no additional last call. If you request 
publication on an Experimental that needs to be PS, that requires a 
second Last Call.

 From http://tools.ietf.org/html/rfc2026#section-6.1.2:

    The IESG is not bound by the action recommended when the
    specification was submitted.  For example, the IESG may decide to
    consider the specification for publication in a different category
    than that requested.  If the IESG determines this before the Last-
    Call is issued then the Last-Call should reflect the IESG's view.
    The IESG could also decide to change the publication category based
    on the response to a Last-Call. If this decision would result in a
    specification being published at a "higher" level than the original
    Last-Call was for, a new Last-Call should be issued indicating the
    IESG recommendation. In addition, the IESG may decide to recommend
    the formation of a new Working Group in the case of significant
    controversy in response to a Last-Call for specification not
    originating from an IETF Working Group.

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 02 Jun 2014 16:01:19 -0500

On 06/02/2014 10:35 AM, Spencer Dawkins wrote:
>>> Guessing in anticipation of text arriving ... is the idea that the 
>>> working group to be would develop however many proposals as seem 
>>> useful, and then
>>>
>> Speaking for myself, it seems to me that this is exactly what 
>> Experimental RFCs _should_ be for, so I'd tend to lean toward a TAPS 
>> WG that publishes implementable proposals for partial or complete 
>> solutions to the transport evolution problem relatively quickly.
>
> I'd buy that.
>
>> I do share (what I read as) Joe's concern that the road from I-D to 
>> even an experimental RFC tends to take a lot of energy that could be 
>> spend on other things, so maybe we have a set of I-Ds with intended 
>> status experimental that we only put the final energy into 
>> publication as an RFC when it becomes obvious we want to reference 
>> later.
>>
>> (Whether all that belongs in _this_ charter as opposed to a 
>> subsequent one is an open question in my mind.)
>

So, just checking in.

I'd like to see an updated charter proposal that reflects recent mailing 
list discussion, including dropping the specifics about document 
category, so that the folks on the mailing list can check whether their 
concerns have been addressed.

One more process thing - if I'm getting feedback I can live with when 
the charter's reviewed on this mailing list, I'd like to put TAPS 
forward for chartering before IETF 90, but the slot request cutoff is 
coming up really soon (specifically, 2014-06-06, this coming Friday), so 
you can expect to see TAPS on the BOF wiki with something like the 
charter you've been discussing, to make sure it gets a slot.

Questions? Comments?

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Mon, 2 Jun 2014 23:47:20 +0200

Hi!

Spencer, thank you very much for this update. Much appreciated!

Regarding the charter bit, let's try to figure out what specifically is needed. Here's the link to the always-most-up-to-date version:
https://sites.google.com/site/transportprotocolservices/charter-proposal

You wrote:

> I'd like to see an updated charter proposal that reflects recent mailing list discussion, including dropping the specifics about document category, so that the folks on the mailing list can check whether their concerns have been addressed.

What exactly do you mean with "dropping the specifics about document category" - is the suggestion to change WG goal #1, which now reads:
"identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs."
to
""identify services provided by existing IETF transport protocols and congestion control mechanisms" ?

For other changes, I'll try to recap the current state; please, all, if you feel I'm misrepresenting things, 1) it's definitely not intentionally, 2) by all means correct me!

The way I see it, we have 2 issues to discuss.

ISSUE 1:
------------

We had some consensus on the charter as it currently stands; then, there was the comment by Aaron about a small wording change that I had missed, in WG goal #2, which currently reads:

"specify a set of transport services that end systems need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service."

Joe spoke against Aaron's change and offered an alternative proposal, which again Gorry didn't like, saying that it seems to him to be a big change in what he's seen on the list. 

My question at this point is: can we keep the original text of goal #2 as I quote it here, or does anybody have yet another proposal that we all can live with?

ISSUE 2:
------------

There were some arguments about the need for WG goal #3, mechanisms to discover the availability of protocols...   - and it seems that several of us want to keep it. Can we (with the current text), or do we need to discuss this more?

Any other issues? Shoot, all  :-)

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Mon, 2 Jun 2014 18:02:33 -0400

Michael-

I'm actually OK with Joe's proposed wording:

On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> On 5/30/14, 8:29 AM, "Aaron Falk" <[email-masked]> wrote:
>
> >My proposed wording change (which at least Gorry accepted) is not in the
> >current draft.  Repeating:
> >
> >
> >Revise working group goal #2 to read "specify a set of transport services
> >that end systems **implementing TAPS** need to provide and provide
> >guidance on choosing among available mechanisms and protocols to obtain a
> >given transport service."
>
> There's no protocol for TAPS yet, so nobody is going to "implement TAPS".
> Suggested change: "end systems need to provide" -> "applications want to
> use".

It allows the wg more flexibility which is probably appropriate in this
stage.

--aaron

On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl <[email-masked]> wrote:

> Regarding the charter bit, let's try to figure out what specifically is
> needed. Here's the link to the always-most-up-to-date version:
> list discussion, including dropping the specifics about document category,
> so that the folks on the mailing list can check whether their concerns have
> been addressed.
>
>
> What exactly do you mean with "dropping the specifics about document
> category" - is the suggestion to change WG goal #1, which now reads:
> "identify services provided by existing IETF transport protocols and
> congestion control mechanisms, based on Standards-track and Experimental
> RFCs."
> to
> For other changes, I'll try to recap the current state; please, all, if
> you feel I'm misrepresenting things, 1) it's definitely not intentionally,
> 2) by all means correct me!
>
>
> We had some consensus on the charter as it currently stands; then, there
> was the comment by Aaron about a small wording change that I had missed, in
> WG goal #2, which currently reads:
>
> "specify a set of transport services that end systems need to provide
> and provide guidance on choosing among available mechanisms and protocols
> to obtain a given transport service."
>
> Joe spoke against Aaron's change and offered an alternative proposal,
> which again Gorry didn't like, saying that it seems to him to be a big
> change in what he's seen on the list.
>
> My question at this point is: can we keep the original text of goal #2 as
> I quote it here, or does anybody have yet another proposal that we all can
> live with?
>
>
> ISSUE 2:
> ------------
>
> There were some arguments about the need for WG goal #3, mechanisms to
> discover the availability of protocols...   - and it seems that several of
> us want to keep it. Can we (with the current text), or do we need to
> discuss this more?
>
>
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 3 Jun 2014 00:13:03 +0200

other opinions? (myself, i'm neutral)

Sent from my iPhone

> On 3. juni 2014, at 00:02, Aaron Falk <[email-masked]> wrote:
> 
> Michael-
> 
>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
> It allows the wg more flexibility which is probably appropriate in this stage.
> 
> --aaron
>  
> 
>

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 03 Jun 2014 00:44:25 +0200

Hi,

I do not like "applications want to use". The application requirements 
give input for the services to specify, but to say that we should 
specify what applications want to use sounds strange to me.

I think the current formulation is better and more clear. I am also fine 
with the "implementing TAPS" addition that Aaron suggested. But as Joe 
did not like "implementing", how about:

"specify a set of transport services that end systems supporting TAPS 
need to provide and provide guidance on choosing among available 
mechanisms and protocols to obtain a given transport service."

Anna

On 2014-06-03 00:13, Michael Welzl wrote:
> On 3. juni 2014, at 00:02, Aaron Falk <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Michael-
>>
>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     On 5/30/14, 8:29 AM, "Aaron Falk" <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi!
>>
>>     Regarding the charter bit, let's try to figure out what
>>     specifically is needed. Here's the link to the
>>     always-most-up-to-date version:
>>>     I'd like to see an updated charter proposal that reflects recent
>>>     mailing list discussion, including dropping the specifics about
>>>     document category, so that the folks on the mailing list can
>>>     check whether their concerns have been addressed.
>>
>>     What exactly do you mean with "dropping the specifics about
>>     document category" - is the suggestion to change WG goal #1,
>>     which now reads:
>>     "identify services provided by existing IETF transport protocols
>>     and congestion control mechanisms, based on Standards-track and
>>     Experimental RFCs."
>>     to
>>     For other changes, I'll try to recap the current state; please,
>>     all, if you feel I'm misrepresenting things, 1) it's definitely
>>     not intentionally, 2) by all means correct me!
>>
>>
>>     We had some consensus on the charter as it currently stands;
>>     then, there was the comment by Aaron about a small wording change
>>     that I had missed, in WG goal #2, which currently reads:
>>
>>     "specify a set of transport services that end systems need to
>>     provide and provide guidance on choosing among available
>>     mechanisms and protocols to obtain a given transport service."
>>
>>     Joe spoke against Aaron's change and offered an alternative
>>     proposal, which again Gorry didn't like, saying that it seems to
>>     him to be a big change in what he's seen on the list.
>>
>>     My question at this point is: can we keep the original text of
>>     goal #2 as I quote it here, or does anybody have yet another
>>     proposal that we all can live with?
>>
>>
>>     ISSUE 2:
>>     ------------
>>
>>     There were some arguments about the need for WG goal #3,
>>     mechanisms to discover the availability of protocols...   - and
>>     it seems that several of us want to keep it. Can we (with the
>>     current text), or do we need to discuss this more?
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Tue, 3 Jun 2014 08:31:09 +0100

My original point was that I did not think this was the piece about what
applications wanted to use - that I thought was going to be part of #2, my
thoughts were that #3 related to the transport system working out what was
actually supported, and the mechanisms (tricks, protocols and messages to
be exchanged) to complete this process determining a usable transport.  My
view is probably a fairly modular way of looking at the problem - but it
would allow at least something to be built, and experimentally deployed -
who knows, if the method works it would achieve the goal.

That's not to say there isn't a chance for a richer "apps" interaction,
i'd juts like a focus on what paths *support*.  Putting more over UDP
probably heightens the need to also do the apps part - but UDP also has
its own set of path issues. My argument is that the TAPS #3 item needs to
focus on finding a transport that can be used over the path - if that
can't be fixed, then TAPS can't succeed.

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Tue, 3 Jun 2014 10:17:52 +0200

Anna talked about item #2, not item #3 (where no other wording was proposed I think), so your response is confusing. Try again?

Do you agree with Anna's proposed wording for item #2?  I do.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 03 Jun 2014 09:46:27 +0100

Sorry, "yes".

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Tue, 3 Jun 2014 10:54:01 +0200

Aaron?  Joe?

---

From: Toby Moncaster <[email-masked]>
Date: Tue, 3 Jun 2014 10:03:24 +0100

I think Anna’s proposed wording is good.

Toby

---

From: Aaron Falk <[email-masked]>
Date: Tue, 3 Jun 2014 14:43:16 -0400

fine with me

--aaron

On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl <[email-masked]> wrote:

> >> Anna talked about item #2, not item #3 (where no other wording was
> proposed I think), so your response is confusing. Try again?
> >>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 4 Jun 2014 10:39:22 +0200

Hi Joe,

I think I need you to say on the TAPS list whether you agree with this or not.

It's about this text bit:
""specify a set of transport services that end systems supporting TAPS
need to provide and provide guidance on choosing among available
mechanisms and protocols to obtain a given transport service."

(below, Anna spoke against your suggested text and suggested this alternative)

My personal opinion: I'd go with Anna's suggestion - this whole "what do applications want" question is a never-ending story and doesn't seem to be necessary to me: as Brian called it, we start with the "support side" here, not the "demand side". TAPS is only the beginning.

Cheers,
Michael

Begin forwarded message:

> From: Aaron Falk <[email-masked]>
> Subject: Re: [Taps] So, is this the -00 charter yet?
> Date: 3. juni 2014 20:43:16 CEST
> To: Michael Welzl <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> fine with me
> 
> --aaron
> 
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Jun 2014 10:47:56 +0200

hi Michael, all,

I think the point Joe was trying to make here (please correct me, Joe) is more that the supply-side does, at some point, need to match up with services that applications that will actually use. Yes, we're doing things from the supply-side in TAPS, but we will need participation from application developers at the _very_ least as a sanity check on the output of TAPS. 

That said, I'm personally happy with Anna's text here, since trying to draw a boundary around "what applications want" within the charter is probably a less productive way to do this IMO than just making sure the app developers are paying attention _during_ discussions of the milestones on the charter. The IAB "IP Stack Evolution" program-in-formation (current name is still subject to change, program scope to be published shortly) will have as one of its goals working together with the chairs of TAPS and within the WG itself to foster this cross-area coordination.

Cheers,

Brian

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 04 Jun 2014 05:02:04 -0400

Yes to get more applications developers.

I do have a problem with "what applicactions want". I think it should be "what
applications require"?

Quoting Brian Trammell <[email-masked]>:

> hi Michael, all,
>
> I think the point Joe was trying to make here (please correct me, 
> Joe) is more that the supply-side does, at some point, need to match 
> up with services that applications that will actually use. Yes, we're 
> doing things from the supply-side in TAPS, but we will need 
> participation from application developers at the _very_ least as a 
> sanity check on the output of TAPS.
>
> That said, I'm personally happy with Anna's text here, since trying 
> to draw a boundary around "what applications want" within the charter 
> is probably a less productive way to do this IMO than just making 
> sure the app developers are paying attention _during_ discussions of 
> the milestones on the charter. The IAB "IP Stack Evolution" 
> program-in-formation (current name is still subject to change, 
> program scope to be published shortly) will have as one of its goals 
> working together with the chairs of TAPS and within the WG itself to 
> foster this cross-area coordination.
>
> Cheers,
>
> Brian
>
>> My personal opinion: I'd go with Anna's suggestion - this whole 
>> "what do applications want" question is a never-ending story and 
>> doesn't seem to be necessary to me: as Brian called it, we start 
>> with the "support side" here, not the "demand side". TAPS is only 
>> the beginning.
>>
>> Cheers,
>> Michael
>>
>>
>>
>> Begin forwarded message:
>>
>>> >> Anna talked about item #2, not item #3 (where no other wording 
>>> was proposed I think), so your response is confusing. Try again?
>>> >>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 4 Jun 2014 11:04:03 +0200

... and I should have been clearer about what I meant when I said:
"this whole 'what do applications want' question is a never-ending story 

=> I should have really phrased it as:
the "should our charter include text, and if so, how, about 'what do applications want' ?" - question is a never-ending story.

The focus is really on charter text now. Glad to hear that you're happy with Anna's text. I think once we get a similar statement from Joe we can consider this one agreed upon.

I have now applied Anna's text to the charter at:
https://sites.google.com/site/transportprotocolservices/charter-proposal

and also done the other change that Spencer requested. He wrote: "...dropping the specifics about document category", with which he can only have meant this text:
"identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs."
which I now changed to:
"identify services provided by existing IETF transport protocols and congestion control mechanisms"

So, I think if we get an ok from Joe on this change, I can probably hand this charter over to Spencer...

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 4 Jun 2014 11:05:53 +0200

> I do have a problem with "what applicactions want". I think it should be "what

That text is already removed in the most recent version (which uses Anna's proposal instead).

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Jun 2014 11:07:55 +0200

> I do have a problem with "what applicactions want". I think it should be "what

(This is a bit of a side conversation, because I think it's okay to remove mention of application requirements from the charter altogether... but...)

There's a little bit of a mismatch between the demand- and supply-side here; applications have requirements and will do what is necessary with available transports to meet those requirements. Usually this means they use some API provided by their platform that somewhere along the line maps down to something-over-TCP (XmlHttpSocket, for example). Sometimes this means application developers roll their own transports over UDP (QUIC, Mosh). 

Given this pragmatism, there is, I think, value in providing services from the transport layer that the application development community doesn't know it needs yet. Simply reacting to requirements expressed in terms of the present situation is unlikely to lead to much innovation. :)

Cheers,

Brian

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Jun 2014 15:50:56 +0000

All the transport protocols listed in the first paragraph are protocols between applications (SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT). 

With layers of layers aggregations (or tunnels) in today's network, the hosts (applications) level transport layers information get buried. That means those application level transport protocols are not visible to network elements. Therefore, the gained benefits are very limited even with relentless effort (of IETF) to fine tune the transport protocols between applications. 

It is much more effective to have transport protocols between applications <-> networks.   

Therefore, I am suggesting following wording changes to the charter description:

--------------------------------

Description of Working Group

Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP.  All those transport protocols are protocols between hosts (or applications). 

With layers of layers aggregations (or tunnels) in today's network, the hosts (applications) level transport layers information get buried. That means those application level transport protocols are not visible to network elements. Therefore, the gained benefits are very limited even with relentless effort to fine tune the transport protocols between applications. 

It is much more effective to have transport protocols between applications <-> networks.   

For an application programmer, it is hard to use protocols other than TCP or UDP: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost.

There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide.

Linda Dunbar

-----Original Message-----
From: Taps [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Wednesday, June 04, 2014 4:08 AM
To: Marie-Jose Montpetit
Cc: Joe Hildebrand; Michael Welzl; [email-masked]
Subject: Re: [Taps] So, is this the -00 charter yet?

On 04 Jun 2014, at 11:02, Marie-Jose Montpetit <[email-masked]> wrote:

> I do have a problem with "what applicactions want". I think it should 
> be "what applications require"?

Cheers,

Brian

>>> ""specify a set of transport services that end systems supporting 
>>> TAPS need to provide and provide guidance on choosing among 
>>> available mechanisms and protocols to obtain a given transport service."
>>> 
>>>> >>> My original point was that I did not think this was the piece 
>>>> >>> about what applications wanted to use - that I thought was 
>>>> >>> going to be part of #2, my thoughts were that #3 related to the 
>>>> >>> transport system working out what was actually supported, and 
>>>> >>> the mechanisms (tricks, protocols and messages to be exchanged) 
>>>> >>> to complete this process determining a usable transport.  My 
>>>> >>> view is probably a fairly modular way of looking at the problem 
>>>> >>> - but it would allow at least something to be built, and experimentally deployed - who knows, if the method works it would achieve the goal.
>>>> >>>
>>>> >>> That's not to say there isn't a chance for a richer "apps" 
>>>> >>> interaction, i'd juts like a focus on what paths *support*.  
>>>> >>> Putting more over UDP probably heightens the need to also do 
>>>> >>> the apps part - but UDP also has its own set of path issues. My 
>>>> >>> argument is that the TAPS #3 item needs to focus on finding a 
>>>> >>> transport that can be used over the path - if that can't be fixed, then TAPS can't succeed.
>>>> >>>
>>>> >>> Gorry
>>>> >>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I do not like "applications want to use". The application 
>>>> >>>> requirements give input for the services to specify, but to 
>>>> >>>> say that we should specify what applications want to use sounds strange to me.
>>>> >>>>
>>>> >>>> I think the current formulation is better and more clear. I am 
>>>> >>>> also fine with the "implementing TAPS" addition that Aaron 
>>>> >>>> suggested. But as Joe did not like "implementing", how about:
>>>> >>>>
>>>> >>>> "specify a set of transport services that end systems 
>>>> >>>> supporting TAPS need to provide and provide guidance on 
>>>> >>>> choosing among available mechanisms and protocols to obtain a given transport service."
>>>> >>>>
>>>> >>>> Anna
>>>> >>>>
>>>> >>>>
>>>> >>>>>>> My proposed wording change (which at least Gorry accepted) 
>>>> >>>>>>> is
>>>> >>>>>>    not in the
>>>> >>>>>>> Revise working group goal #2 to read "specify a set of 
>>>> >>>>>>> transport
>>>> >>>>>>    services
>>>> >>>>>>> that end systems **implementing TAPS** need to provide and 
>>>> >>>>>>> provide guidance on choosing among available mechanisms and 
>>>> >>>>>>> protocols to
>>>> >>>>>>    obtain a
>>>> >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl 
>>>> >>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >>>>>>
>>>> >>>>>>    Hi!
>>>> >>>>>>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 4 Jun 2014 16:13:39 +0000

I won't stand in the way of that text, but I'll repeat for the folks that
haven't heard me say this:

If the TAPS wg doesn't have adequate representation from the application
layer folks, you will produce something that won't be consumed.  Saying
things like "we're just the support side" is liable to make the
apps-focused people assume that this is yet another TSV thing they can
safely ignore.

"What apps want" is *not* an unending story.  They want to be able to
deploy something more flexible than TCP on top of today's Internet,
without requiring everyone to update their OS kernels, and without
requiring administrator privileges at any point.  Treating that set of
requirements as rocket science won't help your output to get deployed.

On 6/4/14, 2:39 AM, "Michael Welzl" <[email-masked]> wrote:

>My personal opinion: I'd go with Anna's suggestion - this whole "what do
>applications want" question is a never-ending story and doesn't seem to
>be necessary to me: as Brian called it, we start with the "support side"
>here, not the "demand side". TAPS
> is only the beginning.
>
>
>Cheers,
>Michael
>
>
>
>
>
>Begin forwarded message:
>
>
>>>>interaction,
>>>>>requirements
>>>>>>>    ""identify services provided by existing IETF transport
>>>>>>>protocols
>>>>>>>    and congestion control mechanisms" ?
>>>>>>>
>>>>>>>

-- 
Joe Hildebrand

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 04 Jun 2014 11:20:42 -0500

> "identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs."

I actually meant something else :-)

The specifics about document category in that text were fine (the 
existing protocol specifications are already in specific document 
categories now), although there's no strong reason I can see to add that 
back in to the charter.

I was talking about specifics on document categories in the milestones 
(there was a decent amount of mailing list discussion about whether the 
third milestone would be standards-track or experimental, and the 
milestones didn't have to say anything about that, beyond "to the IESG").

> So, I think if we get an ok from Joe on this change, I can probably hand this charter over to Spencer...

Just let me know :-)

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Wed, 4 Jun 2014 18:36:08 +0200

On 4. juni 2014, at 18:20, Spencer Dawkins <[email-masked]> wrote:

> The specifics about document category in that text were fine (the existing protocol specifications are already in specific document categories now), although there's no strong reason I can see to add that back in to the charter.

ok, so I left it as it is now -

> I was talking about specifics on document categories in the milestones (there was a decent amount of mailing list discussion about whether the third milestone would be standards-track or experimental, and the milestones didn't have to say anything about that, beyond "to the IESG").

fixed.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 4 Jun 2014 18:42:33 +0200

On 4. juni 2014, at 18:13, Joe Hildebrand (jhildebr) <[email-masked]> wrote:

> "What apps want" is *not* an unending story.

... but agreeing on it for the sake of a WG charter is. We've gone through a year of "no, this is a TSV-only thing, let's incorporate apps stuff in the charter" now, only to find us back at the beginning after a year of debate. I'm fine with this beginning because it's *something* - it's a way to get started, and something we need to do anyway.

>  They want to be able to

I'm not treating it as rocket science, but there are many different opinions here on how this should be done. You state one thing ("deploy something more flexible than TCP on top of today's Internet"), but this isn't quite the whole story. You have people who actually deal with sockets. You have people who don't. You have people saying the first group of people doesn't exist. You have people only dealing with middlewares and wanting to make patterns work better. You have folks trying to make everything look like TCP. It's a large number of opinions, and they don't seem to be mutually exclusive to me - these are all different ways of dealing with the problem.

But now go ahead and incorporate all the opinions in the paragraph above in the charter and try to get people to agree on things. I've been trying this for a year. Even when I started I thought it won't work, but people like you said "if you don't get apps people in on this from the start, this is bound to fail", and so we've been having fun with all these views for a year now.

See? This is why I don't want to repeat this exercise now. But I do want to get started with something small and reasonable, something that we all need no matter what.

Cheers,
Michael

---

From: [email-masked]
Date: Wed, 4 Jun 2014 17:50:47 +0100

+1

I suggest we'll find there is more than one problem here - and I really do
think there is a need to review the Apps needs/expectations etc - and
maybe a need to express really what transports are trying to achieve for
apps - but equally I don't understand why this stops deployment of the
methods above/within the transport framework for apps that *CAN* use
existing protocols.

I move to start the work.

Gorry

> ... but agreeing on it for the sake of a WG charter is. We've gone through
> a year of "no, this is a TSV-only thing, let's incorporate apps stuff in
> the charter" now, only to find us back at the beginning after a year of
> debate. I'm fine with this beginning because it's *something* - it's a way
> to get started, and something we need to do anyway.
>
>
>>  They want to be able to
> I'm not treating it as rocket science, but there are many different
> opinions here on how this should be done. You state one thing ("deploy
> something more flexible than TCP on top of today's Internet"), but this
> isn't quite the whole story. You have people who actually deal with
> sockets. You have people who don't. You have people saying the first group
> of people doesn't exist. You have people only dealing with middlewares and
> wanting to make patterns work better. You have folks trying to make
> everything look like TCP. It's a large number of opinions, and they don't
> seem to be mutually exclusive to me - these are all different ways of
> dealing with the problem.
>
> But now go ahead and incorporate all the opinions in the paragraph above
> in the charter and try to get people to agree on things. I've been trying
> this for a year. Even when I started I thought it won't work, but people
> like you said "if you don't get apps people in on this from the start,
> this is bound to fail", and so we've been having fun with all these views
> for a year now.
>
> See? This is why I don't want to repeat this exercise now. But I do want
> to get started with something small and reasonable, something that we all
> need no matter what.
>
> Cheers,
> Michael
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 4 Jun 2014 18:57:29 +0200

Hi,

While I agree with your thinking, I don't want to open yet another can of worms. See, as I just wrote in the other email, this group has a 1-year-history of starting with a small compromise; blowing it up; letting the air out again. Don't blow the balloon up again, please.

In my opinion, such text belongs where that particular debate happens: in the charter of AEON (now called AECON) - where it could be formulated to say that the work of TAPS, should a TAPS WG come into being, would be extended as you propose below.

I do support the AECON work. In my opinion AECON and TAPS could form two very nicely complementary WGs - but I want TAPS to survive in case AECON doesn't, so to speak...

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 04 Jun 2014 12:33:19 -0500

Just for light steering (as a somewhat responsible AD) ...

> While I agree with your thinking, I don't want to open yet another can of worms. See, as I just wrote in the other email, this group has a 1-year-history of starting with a small compromise; blowin…

I don't know the future any more than other folks, but I'm guessing that 
TAPS would be more successful if it's exporting needs to other groups 
after it identifies the needed services, than if it's importing 
suggestions about how services could be provided from (potentially many) 
other places.

> I do support the AECON work. In my opinion AECON and TAPS could form two very nicely complementary WGs - but I want TAPS to survive in case AECON doesn't, so to speak...

I just want the right thing to happen. That could be a right thing, but 
it's too early for me to tell :-)

Spencer

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Jun 2014 09:37:19 +0200

greetings all,

Tying a couple of threads together here...

On 04 Jun 2014, at 19:33, Spencer Dawkins <[email-masked]> wrote:

> I don't know the future any more than other folks, but I'm guessing that TAPS would be more successful if it's exporting needs to other groups after it identifies the needed services, than if it's importing suggestions about how services could be provided from (potentially many) other places.

+1

> I just want the right thing to happen. That could be a right thing, but it's too early for me to tell :-)

In my opinion as well there's a very clear line between AECON and TAPS, and I agree with Michael that these questions belong in AECON.

Missing from either at the moment are approaches for lower-level signaling to in-path devices -- not to say "this traffic will have these characteristics" but more to group flows using new (userland) transport protocols into sessions so that firewalls and middleboxes that want to make decisions at session establishment time can do so without mucking about in each transport's semantics. This is something we're discussing in (what will now definitively be called) the IAB IP Stack Evolution program, which may result in work being referred into an existing or new WG or RG. But at the moment that effort is definitively separate from TAPS in the present charter.

> I move to start the work.

I second Gorry's call. The points Joe raises are important -- again, I think it's useful to do this work from the "supply side", but only if there is some indication of current or eventual "demand". There's a tension here that comes from trying to do engineering work from two different viewpoints, and IETF area-tribalism (backed up by a scheduling algorithm that is not focused on  making cross-area participation easy) doesn't help.

I don't think this tension is something we can resolve in the charter; rather, we (TAPS participants, chairs, ADs, the IAB) will have to remain vigilant to make sure the output is applicable to application requirements.

In any case, the charter is IMO ready to send up for wider review.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Jun 2014 13:58:12 +0200

Hi,

Thanks Brian for all you wrote here; I agree with all of it. As for sending the charter on, I would also agree... Spencer, what do you think?

If you agree with our impression that "the time has come", then please go ahead, just copy+paste it out from https://sites.google.com/site/transportprotocolservices/charter-proposal   :-)

Spencer, I also noticed that TAPS isn't in the BOF Wiki yet, and we have only one more day before the scheduling deadline - are you going to put it in there, or shall I?   (anyway, given that it seems we have an agreed-upon charter, is this then even intended as a BOF, or a side-meeting of some sort, or what?)

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 05 Jun 2014 11:55:04 -0500

On 06/05/2014 06:58 AM, Michael Welzl wrote:
> Hi,
>
> Thanks Brian for all you wrote here; I agree with all of it. As for 
> sending the charter on, I would also agree... Spencer, what do you think?
>
> If you agree with our impression that "the time has come", then please 
> go ahead, just copy+paste it out from 
>  :-)

Michael, I'm ready when the group is.

My next step would be to put this in the datatracker as a proposed 
working group charter for review.

> Spencer, I also noticed that TAPS isn't in the BOF Wiki yet, and we 
> have only one more day before the scheduling deadline - are you going 
> to put it in there, or shall I? (anyway, given that it seems we have 
> an agreed-upon charter, is this then even intended as a BOF, or a 
> side-meeting of some sort, or what?)

So, if TAPS moves forward and wants to meet in Toronto, TAPS will need a 
slot, and slots go to working groups (which TAPS isn't) and to BOFs. It 
would be helpful if you cut-and-pasted into the BOF Wiki, and just put 
"in charter review process" somewhere toward the top of the description. 
That way, TAPS reserves a slot for Toronto, and if the charter is 
approved before Toronto, that works, too.

Does that make sense?

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Jun 2014 21:29:58 +0200

> Michael, I'm ready when the group is.

My feeling is that the group is ready. I'm asking one more time, explicitly: ARE YOU READY?

https://www.youtube.com/watch?v=CIhylLW4Fcs

(Let's say: we're all ready if no complaints come up within the next day)

> My next step would be to put this in the datatracker as a proposed working group charter for review.

Great!!

> So, if TAPS moves forward and wants to meet in Toronto, TAPS will need a slot, and slots go to working groups (which TAPS isn't) and to BOFs. It would be helpful if you cut-and-pasted into the BOF Wiki, and just put "in charter review process" somewhere toward the top of the description. That way, TAPS reserves a slot for Toronto, and if the charter is approved before Toronto, that works, too.
> 
> Does that make sense?

Sure does, will do!

Michael

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 Jun 2014 16:36:19 -0400

> https://www.youtube.com/watch?v=CIhylLW4Fcs

AC/DC?  Feh.

https://www.youtube.com/watch?v=x3KjlnuETk0

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 Jun 2014 16:52:53 -0400

>> If you agree with our impression that "the time has come", then please go
>> ahead, just copy+paste it out from

Rather than waiting until it officially goes to the IESG, some suggestions:

OLD
Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite
and the LEDBAT congestion control mechanism extend the number of
transport services to applications in addition to the long-standing
two services provided by TCP and UDP.
END

TCP and UDP are two protocols... they provide more than two services.
I think what this really wants to say is something like this:

NEW
Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite,
and the LEDBAT congestion control mechanism extend the set of
transport services that are available to applications, beyond those
provided by TCP and UDP.
END

I would break into a new paragraph before "For an application programmer".

OLD
For an application programmer, it is hard to use protocols other than
TCP or UDP: not all protocols are available everywhere, hence a
fall-back solution to e.g. TCP or UDP must be implemented.
NEW
For an application programmer, it is hard to use protocols other than
TCP or UDP: most network stacks only support TCP and UDP, many
firewalls only pass TCP and UDP, and requiring other transport
protocols risks having an application not work in many environments.
Applications, therefore, must always be able to fall back to TCP or
UDP.
END

OLD
Some protocols provide the same services in different ways. Layering
decisions must be made (e.g. should a protocol be used natively or
over UDP?). Because of these complications, programmers often resort
to either using TCP or implementing their own customized solution over
UDP, and chances of benefiting from other transport protocols are
lost.
NEW
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 implementing their own customized solution over UDP.
That can result in applications re-implementing features already
available elsewhere, and chances of benefiting from other transport
protocols are lost.
END

I don't really understand what work item 2 is trying to say, and how
it's a distinct work item from number 1.  Maybe it should be merged
with 1, or rephrased to make the distinction clear.

For item 3, I thought we were going for more than discovery, and meant
to specify an experimental mechanism for specifying the services that
were desired, and allow the transport layer to figure out how to
provide those services.  No?

Barry

---

From: Michael Welzl <[email-masked]>
Date: Fri, 6 Jun 2014 00:36:41 +0200

Hi,

Thanks a lot for your suggestions!

Comments below:

> available elsewhere, and chances of benefiting from other transport

I agree with all of the above, and I also find it hard to imagine that someone would want to object to these changes - hence I incorporated them in the charter at
https://sites.google.com/site/transportprotocolservices/charter-proposal
straight away.  (this is not to stop others from commenting, of course! Just saying I think it's unlikely so I did what seemed efficient to me)

> with 1, or rephrased to make the distinction clear.

In my interpretation (and I hope that's the general view here?), #2 is a shortened list of #1 - just the useful stuff that we really recommend providing, not the complete list of absolutely all combinations of things, no matter how strange or useless. I'd be glad to get suggestions (from you or anybody else) on making that clearer in the text.

> provide those services.  No?

So, item #2 is meant to be the list of services that we desired. I'd say we wanted and tried to capture "allow the transport layer to figure out" with "discover the availability... how to select and engage a protocol...". Again, glad to get phrasing suggestions!

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sat, 7 Jun 2014 11:02:39 +0200

Ok, I will give it a try myself. See below:

On 6. juni 2014, at 00:36, Michael Welzl <[email-masked]> wrote:

> (snip)

(snip)

> In my interpretation (and I hope that's the general view here?), #2 is a shortened list of #1 - just the useful stuff that we really recommend providing, not the complete list of absolutely all com…

Here goes a proposal for item #2:

OLD
specify a set of transport services that end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service.
END

NEW
specify a shorter set of transport services that end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service.
END

The only change is that I inserted "shorter", but maybe that's enough to clarify the relationship to item #1?

> So, item #2 is meant to be the list of services that we desired. I'd say we wanted and tried to capture "allow the transport layer to figure out" with "discover the availability... how to select an…

My proposal for item #3:

OLD
specify experimental mechanisms to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. This will explain how to select and engage a protocol to deliver a transport service.
END

NEW
specify experimental mechanisms to deliver a transport service. This will explain how to select and engage a protocol, and how to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment.
END

The intention is to more clearly say - with the first sentence - that we want to let the transport layer "figure out how to provide these services". The rest is just a rearrangement of the old text, no new words were introduced (and no animals harmed)   :-)

Thoughts?

Cheers,
Michael

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 Jun 2014 10:20:26 -0400

> Ok, I will give it a try myself.

Yes, sorry: I was in httpbis meetings for a couple of days, and was
distracted from other things by that.

> specify a set of transport services that end systems supporting TAPS need to
> provide and provide guidance on choosing among available mechanisms and
> protocols to obtain a given transport service.
> END
>
> NEW
> specify a shorter set of transport services that end systems supporting TAPS
> need to provide and provide guidance on choosing among available mechanisms
> and protocols to obtain a given transport service.
> END
>

Maybe...
Or maybe "specify a subset of those services identified in item 1,
which end systems..."

Does that work for you?  I think it does for me.

> My proposal for item #3:
>
> OLD
> specify experimental mechanisms to discover the availability of protocols on
> an interface (both end system and path support), in order to provide a basis
> for incremental deployment. This will explain how to select and engage a
> protocol to deliver a transport service.
> END
>
> NEW
> specify experimental mechanisms to deliver a transport service. This will
> explain how to select and engage a protocol, and how to discover the
> availability of protocols on an interface (both end system and path
> support), in order to provide a basis for incremental deployment.
> END
>
> The intention is to more clearly say - with the first sentence - that we
> want to let the transport layer "figure out how to provide these services".
> The rest is just a rearrangement of the old text, no new words were
> introduced (and no animals harmed)   :-)

I like that change; thanks.

Barry

---

From: Michael Welzl <[email-masked]>
Date: Sun, 8 Jun 2014 00:25:38 +0200

> distracted from other things by that.

No worries!

> Does that work for you?  I think it does for me.

It does for me, too.

Others? List?

> I like that change; thanks.

Cool. Others? List?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Tue, 10 Jun 2014 09:05:27 +0200

Hi,

I have now applied these comments at:
https://sites.google.com/site/transportprotocolservices/charter-proposal

Any more comments? Anyone?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 11 Jun 2014 09:10:58 +0200

Hi,

Unless someone comments by the end of tomorrow, 12 June, I will consider the charter final from the point of view of the WG and ship it to Spencer.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 11 Jun 2014 09:22:27 +0200

hi Michael,

It looks good to me. Thanks a lot for driving this forward!

Cheers,

Brian

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 11 Jun 2014 16:21:49 +0200

Hi,

+1

Regards,
 Roland

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 12 Jun 2014 09:33:31 +0000

+1

Regards,
Will (Shucheng LIU)

> From: Taps [mailto:[email-masked]] On Behalf Of Bless, Roland
> (TM)
> Sent: Wednesday, June 11, 2014 10:22 PM
> To: [email-masked]
> Subject: Re: [Taps] LAST CALL: charter ready to ship?
> 
> Hi,
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Jun 2014 11:43:00 +0200

Hi Michael, hi all,

I didn't contribute so far, but were following the discussion. You all did a 
really good job. Special thanks to Michael for caring! I believe the charter 
is ready and I'm happy to contribute in future!

Mirja

On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote:
> Hi,
>
> Unless someone comments by the end of tomorrow, 12 June, I will consider
> the charter final from the point of view of the WG and ship it to Spencer.
>
> Cheers,
> Michael
>
> >>>> specify a set of transport services that end systems supporting TAPS
> >>>> mechanisms and protocols to obtain a given transport service.
> >>>> END
> >>>>
> >>>> NEW
> >>>> specify a shorter set of transport services that end systems
> >>>> supporting TAPS need to provide and provide guidance on choosing among
> >>>> available mechanisms and protocols to obtain a given transport
> >>>> service.
> >>>> END
> >>>>
> >>>> specify experimental mechanisms to discover the availability of
> >>>> protocols on an interface (both end system and path support), in order
> >>>> to provide a basis for incremental deployment. This will explain how
> >>>> to select and engage a protocol to deliver a transport service.
> >>>> END
> >>>>
> >>>> NEW
> >>>> specify experimental mechanisms to deliver a transport service. This
> >>>> will explain how to select and engage a protocol, and how to discover
> >>>> the availability of protocols on an interface (both end system and
> >>>> path support), in order to provide a basis for incremental deployment.
> >>>> END
> >>>>
> >>>> The intention is to more clearly say - with the first sentence - that
> >>>> we want to let the transport layer "figure out how to provide these
> >>>> services". The rest is just a rearrangement of the old text, no new
> >>>> words were introduced (and no animals harmed)   :-)
> >>>

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: David Ros <[email-masked]>
Date: Thu, 12 Jun 2014 12:12:36 +0200

Hi,

+1

Cheers,

David

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 12 Jun 2014 11:16:20 +0100

Also +1 (and I echo Mirja's thanks to Michael)

Toby

> On 12 Jun 2014, at 11:12, David Ros <[email-masked]> wrote:
>

---

From: Anna Brunstrom <[email-masked]>
Date: Thu, 12 Jun 2014 13:32:23 +0200

+1

Anna

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 12 Jun 2014 06:37:04 -0500

Michael,

Please let me know when to pull the trigger :-)

Spencer

On 06/12/2014 06:32 AM, Anna Brunstrom wrote:
>>>> On 12 Jun 2014, at 11:43, Mirja Kuehlewind 
>>>> <[email-masked]> wrote:
>>>>
>>>> Hi Michael, hi all,
>>>>
>>>>>>>>> choosing among
>>>>>>>>> The only change is that I inserted "shorter", but maybe that's 
>>>>>>>>> enough
>>>>>>>>> to clarify the relationship to item #1?
>>>>>>>> Maybe...

---

From: Michael Welzl <[email-masked]>
Date: Thu, 12 Jun 2014 13:41:40 +0200

after "the end of today", to keep my promise from y'day's mail....

Sent from my iPhone

> On 12. juni 2014, at 13:37, Spencer Dawkins <[email-masked]> wrote:
> 
> Michael,
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 12 Jun 2014 16:54:46 +0000

+1, 

Linda

-----Original Message-----
From: Taps [mailto:[email-masked]] On Behalf Of Toby Moncaster
Sent: Thursday, June 12, 2014 5:16 AM
To: David Ros
Cc: Michael Welzl; [email-masked]
Subject: Re: [Taps] LAST CALL: charter ready to ship?

Toby

>> I didn't contribute so far, but were following the discussion. You 
>> all did a really good job. Special thanks to Michael for caring! I 
>> believe the charter is ready and I'm happy to contribute in future!
>> 
>> Mirja
> 
> Hi,
> 
> +1
> 
> Cheers,
> 
> David
> 
> 
>> 
>> 
>>> Unless someone comments by the end of tomorrow, 12 June, I will 
>>> consider the charter final from the point of view of the WG and ship it to Spencer.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>>>>> Yes, sorry: I was in httpbis meetings for a couple of days, and 
>>>>>> was distracted from other things by that.
>>>>> 
>>>>> No worries!
>>>>> 
>>>>>>> specify a set of transport services that end systems supporting 
>>>>>>> available mechanisms and protocols to obtain a given transport service.
>>>>>>> END
>>>>>>> 
>>>>>>> NEW
>>>>>>> supporting TAPS need to provide and provide guidance on choosing 
>>>>>>> among available mechanisms and protocols to obtain a given 
>>>>>>> transport service.
>>>>>>> END
>>>>>>> 
>>>>>>> enough to clarify the relationship to item #1?
>>>>>> 
>>>>>> Maybe...
>>>>>> Or maybe "specify a subset of those services identified in item 
>>>>>> 1, which end systems..."
>>>>>> 
>>>>>>> protocols on an interface (both end system and path support), in 
>>>>>>> order to provide a basis for incremental deployment. This will 
>>>>>>> explain how to select and engage a protocol to deliver a transport service.
>>>>>>> END
>>>>>>> 
>>>>>>> NEW
>>>>>>> specify experimental mechanisms to deliver a transport service. 
>>>>>>> This will explain how to select and engage a protocol, and how 
>>>>>>> to discover the availability of protocols on an interface (both 
>>>>>>> end system and path support), in order to provide a basis for incremental deployment.
>>>>>>> END
>>>>>>> 
>>>>>>> The intention is to more clearly say - with the first sentence - 
>>>>>>> that we want to let the transport layer "figure out how to 
>>>>>>> provide these services". The rest is just a rearrangement of the old text, no new
>> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 
>> Stuttgart
>> 
>> tel: +49(0)711/685-67973