ietf
[Top] [All Lists]

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

2017-04-11 06:48:24
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:-)