Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

[Stefano Secci <[e-mail]>]

Hello,

in LIP6 we're working since 2014 on MPTCP proxy design and experiments, and I'm personally available to review also next versions of the MPTCP converter work and participate to the discussions.

Best,
Stefano

> Le 12 janv. 2018 à 16:29, Mirja Kühlewind <[e-mail]> a écrit :
> 
> Hi all,
> 
> replying to Joe’s email but directed to the whole group as I would like to clarify one point:
> 
> Even though I think this was stated explicitly and correctly in the initial mail by the chairs that was starting the adopting call, I would like to note again that the current charter seems allow the group to work on these kind of approaches. The original mails stated:
> 
>> The TCPM charter states that the "WG mostly focuses on maintenance issues
>> (e.g., bug fixes) and modest changes to the protocol, algorithms, and
>> interfaces that maintain TCP's utility". Assisting the deployment of new TCP
>> extensions could be understood as one way to ensure TCP's utility.
> 
> draft-bonaventure-mptcp-converters does not propose direct changes in the TCP protocol itself but it aims to support deployment of TCP options and thereby "maintains TCP’s utility".
> 
> Of course this proposal could be seen as an application to TCP but given the application is to enable deployment of TCP options such that TCP extensions can be used by other over-the-top applications, it is very closely interconnected to the TCP protocol itself.
> 
> I proposed to discuss this doc in tcpm because I think TCP expertise is needed here and I would feel uncomfortable if this work would happen in a wg outside of the tsv area. An alternative would be to narrow the scope of the proposed approach down to enable MCTCP support only and proceed the work in the MPTCP group. However, as there is a much broader TCP expertise in tcpm, I’m very certain that the quality of the final work would be higher if the document would be adopted in tcpm instead.
> 
> To my understanding Joe’s initial emails was saying that he does not support the adoption of this document in tcpm as over-the-top applications are out of scope. As explained above, my assessment is that this work is in scope for tcpm. 
> 
> Effectively the questions that were originally ask in the adoption call were not so much on the scope but:
> 
> 1) Is there support for this work in tcpm, meaning are people in this group willing to review and discuss this work?
> 
> 2) Are there concerns against the adoption of this document? 
> 
> I well notice that there have bee three people in the group that have concerns regarding the question if this document is in scope. However, I , and I believe the chairs as well, do not share these concerns based on the provided arguments in the discussion. 
> 
> Therefore, I would like to make another request to the group and try to figure out if there is enough energy and interest in this group to pursue this work in tcpm (instead of mptcp or potentially some non-tsv group). Please let me know if you in general support the work and would be willing to review and discuss the proposed draft in this group (question 1 above)!
> 
> Of course, please also let me/us know if there are other (technical) concerns that would preclude the adoption of this work that did not come up yet!
> 
> Thanks,
> Mirja
> 
> 
> 
>> Am 06.12.2017 um 05:26 schrieb Joe Touch <[e-mail]>:
>> 
>> 
>> 
>> On 12/5/2017 2:48 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>> Hi Joe, all,
>>> 
>>> Regarding "*out of scope for* TCPM":  Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. 
>> Although I appreciate that's strictly true, I doubt the charter would
>> change to include "haiku development".
>> 
>> By the same token, IMO, this doc falls into one of two categories:
>> 
>> 1) if, as is, it proposes direct placement of out-of-band data in the
>> SYN payload, I think it is a bad idea and not worth pursuing in TCPM
>> 
>> 2) if, instead, it is corrected to explain that its use of the data
>> channel for proxy information is simply a conventional application data
>> path, then it would not be a "modification of TCP" at all (minor or
>> otherwise). If that isn't clearly out of scope for TCPM, I do not know
>> what is or ever would be (can we start haiku next, in that case?)
>> 
>> Joe
>> 
>> _______________________________________________
>> multipathtcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>