Se below >> On 16 Mar 2015, at 14:07, Mirja Kühlewind >> <[email protected]> wrote: >> >> Hi Karen, >> >> section 3 should describe what currently is standardized. Am I right >> that there is no RFC on CMT SCTP (yet)⦠and that this was/is the >> reason that there was some discussion that this is out of scope? If so, >> what the status of CMT SCTP? Will there be potentially be an RFC anytime >> soon? > Hi Mirja, > > this is an interesting question. It is not yet a WG document and the last > time I asked > for WG adoption, the question by the chairs was who would the consumer of > the document > be? A lot of people involved in implementing this in FreeBSD, the ns-2 and > the INET > simulator are already co-authors. > I tried to get some support for stack vendors, but none of them wanted to > make statements > about future products. > > If there is a chance to progress this in TSVWG as a WG document, we would > be interested, > but I don't see why I should get a different answer when asking the same > question again > without having a relevant list of some "consumers" of the potential RFC. > > Best regards > Michael >
As tswg co-chair: that is more or less what I recall. Importantly: There was no decision that this was outside the charter. So, if there are developments or indications of greater maturity, then tsvwg could revisit this and revive the work - but I'd expect the same questions to be asked by the Chairs. Gorry (with tsvwg chair hat upon my head) >> >> However, in section 3 if there are any similarities to MPTCP in SCTP, >> either in MH or CMT, these could be described in a similar way and >> potentially even refer to MPTCP or the other way around. If SCTP is >> described independent of MPTCP thatâs fine as well, or potentially >> even better for the start. As soon as we then start writing section 4, >> we anyway to have to detect those similarities and can still add >> references or adapt the wording to use the same term later on. >> >> Mirja >> >> >> >>> Am 16.03.2015 um 12:52 schrieb Karen Elisabeth Egede Nielsen >>> <[email protected]>: >>> >>> Hi Mirja, >>> >>>>>> >>>>>> Having said this, I'd like to first see a complete section (3.2) on >>>>>> MPTCP before we start to writing something on this in section 4. >>>>>> However, I'm sure you could also help to provide some text in >>>>>> section >>>>>> 3.2...? That would be great! >>>>> >>>>> Yes, that was the plan. I think the API for both SCTP and MPTCP are >>>>> relevant in highlighting the underlying features of the protocol, >>>>> even >>>>> though these APIs are not what needs to be described. >>>> >>>> Yep. APIs should not be discussed in section 4. However, for the >>>> protocol >>>> description in section 3, if you look at the other descriptions, there >>>> is >>> also a >>>> subsection on the (higher layer) interface. As you say there is often >>>> a >>> strong >>>> dependency therefore I think there is a purpose to describe the >>>> interface >>> as >>>> well (in section 3) to have a ground truth for discussion. >>>> >>>>> >>>>> The synthesis in section 4 should come at a later stage, once 3.2 >>>>> (and >>>>> perhaps a similar discussion in SCTP's section), have been written >>>>> up. >>>> >>>> Yes! >>>> >>> [Karen ] Do you here refer to SCTP MH or CMT SCTP ? >>> >>> MPTCP include concurrency aspects which, for SCTP, only significantly >>> arise with CMT SCTP. >>> >>> It has previously been stated that CMT SCTP would not be in scope of >>> taps. >>> Is that still the assumption ? >>> >>> BR, Karen >>> >>>> Mirja >>>> >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>> >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
