RE: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)

[<[e-mail]>]

Hi Stephen, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : mardi 11 avril 2017 10:51
> À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; [e-mail]
> Cc : [e-mail]
> 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, [e-mail] 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:-)
> 
> 
>