See below > 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 >>
I think SCTP multihoming and path failover should be there. I personally think that formal discussion of SCTP/ CMT falls outside the scope of TAPS, until the IETF decides to adopt this work (that's for TSVWG sometime). However, I guess if TAPS wanted to refer to a paper on the possibility of such extensions to SCTP in the discussion section that could easily be considered. Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
