> On 16 Mar 2015, at 14:07, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > 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 > > 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 >> <karen.niel...@tieto.com>: >> >> 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 >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
