On 11/04/17 13:03, Dave Dolson wrote: > Regarding "benefits", these devices clearly have perceived benefits I do not agree that the IETF ought described perceived benefits as if the claimed benefits accrue as hoped for. That is far too close to marketing. In a contentious case like this, I can see why someone may feel that's useful as a form of balance or part of a larger debate, but in the end I think we need to step back and take an engineering approach. S > to those who deploy them. My view is that the document should explain > that perspective for readers who lack the operator perspective. The > intent was not to mandate or recommend deployments. > > David Dolson ‎ Original Message From: mohamed.boucadair@xxxxxxxxxx > Sent: Tuesday, April 11, 2017 7:48 AM To: Stephen Farrell; Martin > Thomson; ietf@xxxxxxxx Cc: > draft-dolson-plus-middlebox-benefits@xxxxxxxxxxxxxx Subject: RE: > draft-dolson-plus-middlebox-benefits (was RE: Review of > draft-mm-wg-effect-encrypt-09) > > > 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:-) >> >> >> >
Attachment:
signature.asc
Description: OpenPGP digital signature