See a few comments in-line on various things. > I thin kwe are going to face a lot of "extensions". Maybe a secondary goal > could be to define a standard way to access both IETF and "extension" > transports? > I think this may well be the case in the end, although there is still some way to go before we reach that. To me, the most important next step is we recognise common terminology and therefore can make progress getting the basic language correct.
+1 with Brian, if we agree the basics we could then consider other protocols around this - there could be many that potentially could be considered. Gorry > /mjm > Marie-Jose Montpetit, Ph.D. > [email protected] > @SocialTVMIT > >> On Nov 3, 2014, at 9:10 AM, Brian Trammell <[email protected]> wrote: >> >> >>> On 03 Nov 2014, at 13:56, Karen Elisabeth Egede Nielsen >>> <[email protected]> wrote: >>> >>> Hi, >>> >>> Thanks a lot for a good start. >>> >>> I notice that MPTCP is quoted as a transport protocol but that CMT-SCTP >>> isnât. I assume that this >>> is motivated by the fact that the taps work very clearly draws the line >>> in between >>> features that have made it through IETF standardisation (even as >>> informational) and features that have not and >>> only are specified in âseemingly dormantâ individual drafts. >>> Correct ? >> >> This is the intention (in keeping with item 1 on the charter). However, >> _this_ revision is very -00 and as such has only the most obvious things >> we could think of just before the deadline. My personal opinion is that >> if we can illustrate an interesting transport service using a proposed >> extension to an IETF protocol, then by all means letâs do so. >> >>> In terms of SCTP and the transport service that it provides, then I >>> wonder if the priority feature that it embeds is something >>> that afford special mentioning in this document. I.e., by usage of >>> streams and priority settings on streams then it is possible >>> to enforce that messages written on particular stream is able to >>> outrace messages written on other non-prioritized streams at least from >>> a >>> sender transmittal perspective. >>> The feature is actually started to be deployed for some applications in >>> present signalling networks but it is only partially standardized in >>> that the >>> tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature >>> are not finished yet. Still the features are described in standards >>> track documents. >> >> This definitely seems to be a transport service of interest. >> >> Cheers, >> >> Brian >> >>> From: Taps [mailto:[email protected]] On Behalf Of Aaron Falk >>> Sent: Tuesday, October 28, 2014 5:04 PM >>> To: [email protected] >>> Cc: Gorry Fairhurst; Brian Trammell >>> Subject: [Taps] new draft available: draft-fairhurst-taps-transports-00 >>> >>> Hi Folks- >>> >>> Gorry & Brian have published an annotated framework for TAPS doc 1 on >>> transport services here. We'll discuss whether to adopt it as a >>> working group doc in Honolulu. I encourage you to send comments and >>> offers to contribute text before then. >>> >>> --aaron >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
