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:multipathtcp-bounces@ietf.org] De la part de
> Mirja Kühlewind
> Envoyé : vendredi 12 janvier 2018 16:30
> À : tcpm@ietf.org
> 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 <touch@strayalpha.com>:
> >
> >
> >
> > 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
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp