On 03 Nov 2014, at 15:10, 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 The main reason which the SCTP CMT ID is still very -00 is based on the limited chances that it will progress to an RFC. This might change in the future, but the last time I tried it was hard to find people willing to implement it. It is currently implemented in FreeBSD and two simulation models (NS-2 and INET for OMNeT++), and most of the people involved are coauthors. So it is hard to get consumers of a potential RFC. Maybe someone implementing it in Linux and Solaris...
Best regards Michael > 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
