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

[Stephen Farrell <[e-mail]>]

Hiya,

On 11/04/17 12:47, [e-mail] wrote:
> 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. 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 

Well, just because someone asks for something doesn't mean
it's always a good idea to give it to them. I also not that
the quoted text is silent as to whether the downsides ought
also be documented. But regardless of whether or not there
is a desire for this document, in anything like it's current
form, I'd be one voice opposed to publication.

> 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. 

Mine was a comment not a question. I think both can be valid.

> 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.

I disagree that the above fairly describes the current text.

> 
>> 
>> 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.

If so, I think that the current text is very very far from being
ready.

S.

> 
> 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:-)
>> 
>> 
>> 
>