> On Feb 5, 2015, at 3:44 AM, Michael Welzl <[email protected]> wrote: > > >> 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. Yes but in fact I think that you have to look at both ends: define what the service wants can be tricky but necessary. On the other hand it also almost implies that the mechanims or services also expose their characteristics - if not, matching of services to transport cannot happen. > > 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? Yes but the issue will be in defining X - less latency at the expense of bandwidth or more complexity in the network or ??? Each of those may imply a different transport. > > Cheers, > Michael >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
