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

["Muley, Praveen (Nokia - US/Mountain View)" <[e-mail]>]

Working on implementation. Please count my support for this  work.

-Praveen 

-----Original Message-----
From: multipathtcp [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, January 17, 2018 10:46 PM
To: Mirja Kühlewind <[e-mail]>; [e-mail]
Cc: multipathtcp <[e-mail]>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

Hi Mirja, all, 

I reiterate my support to this work. 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[e-mail]] De la part de 
> Mirja Kühlewind Envoyé : vendredi 12 janvier 2018 16:30 À : 
> [e-mail] Cc : multipathtcp Objet : Re: [multipathtcp] [tcpm] 
> Working group acceptance of draft- bonaventure-mptcp-converters ?
> 
> 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
_______________________________________________
multipathtcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp