Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-

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(_dot_)boucadair(_at_)orange(_dot_)com 
> Sent: Tuesday, April 11, 2017 7:48 AM To: Stephen Farrell; Martin
> Thomson; ietf(_at_)ietf(_dot_)org Cc:
> draft-dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org 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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] Envoyé : mardi 11 
> > avril 2017
> > 10:51 À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
> > ietf(_at_)ietf(_dot_)org Cc :
> > draft-dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org 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(_dot_)boucadair(_at_)orange(_dot_)com 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:-)

signature.asc
Description: OpenPGP digital signature