Hi Stephen, Please see inline. Cheers, Med > -----Message d'origine----- > De : Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] > Envoyé : mardi 11 avril 2017 10:51 > À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; ietf@xxxxxxxx > Cc : draft-dolson-plus-middlebox-benefits@xxxxxxxxxxxxxx > Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft- > mm-wg-effect-encrypt-09) > > > Hi Med, > > On 11/04/17 09:15, mohamed.boucadair@xxxxxxxxxx wrote: > >> I hope that the IETF never publishes > >> draft-dolson-plus-middlebox-benefits; it makes claims about the > >> benefits of specific solutions for different use cases with the > >> goal of justifying those solutions. > > > [Med] I'm afraid this is speculating about the intent of > > draft-dolson. Assured this is not the purpose of that document. The > > motivation is to document current practices without including any > > recommendation or claiming these solutions are superior to others. > > Just to note that I completely agree with Martin's interpretation > of the thrust of this draft and I totally fail to see how your > argument above can be justified given that draft title, abstract > and even filename (and also the content;-). [Med] "beneficial" is derived from the initial request that motivated this draft (excerpt from the abstract): At IETF97, at a meeting regarding the Path Layer UDP Substrate (PLUS) protocol, a request was made for documentation about the benefits ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that might be provided by permitting middleboxes to have some ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ visibility to transport-layer information. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When the abstract > says "This document summarizes benefits" then I cannot interpret > that as other than being intended to justify the uses described. [Med] I would prefer if we can avoid to "interpret", but raise questions to the authors if there is a doubt. The document does not provide a recommendation or claims this is the only way to achieve the technical goals. It does only reflect some deployment reality together with some motivations. > > A fairly thorough re-write to aim to describe the pros and cons > would be a different and more useful document. [Med] There are already many RFCs that discuss the issues/cons (I can cite this RFC I co-authored https://tools.ietf.org/html/rfc6269 for the CGN case). What is needed IMHO is something else: understand the requirements that led to deploy some of these functions. Similarly a draft > that strives to neutrally describe existing reality could maybe > be useful (*) [Med] This is the intent of draft-dolson. but one that only describes middlebox friends with > "benefits" is not IMO beneficial ;-) [Med] The intent is not to "sell something" but to understand the technical needs so that hopefully we can have a reference for future solution-oriented discussions. If a given function can be provided without involving an on-path device, this would be great for operators (optimize CAPEX/OPEX is our motto). > > Cheers, > S. > > (*) That is the argument for draft-mm-effect-encrypt, for which I > do support publication (apparently in disagreement with Martin in > that case:-) > > >