> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit <[email protected]> wrote: > >> snip/snip > >> In summary, we need a better way to describe the services we want before >> we'll ever be able to expect the transport to handle them properly. >> > I totally agree.
We've been around the "let's specify what the application wants, not what protocols can do" block a couple of times prior to creation of this group. We started and ended with the bottom-up'ish plan that is in the charter now. So, if you take a look at item #2 in the charter, it's rather unclear what that item is going to look like, and in particular how we'll arrive there: "2) 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. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services." We'll have to figure out reasonable ways to shorten the list in item #1 at some point; this could include compiling a number of services under more application-oriented terms - such as "willing to choose low latency at the cost of X". What this statement precisely means depends on "X", and I think we can get an idea of what "X" is when we create that service from the list in item #1, not out of the blue. Does that make sense? Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
