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 20:34
À : Dave Dolson; 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)
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.
[Med] I'm afraid it is hoped for some functions. For example, the IETF
specified in the past many functions to provide specific services (called
benefit in draft-dolson) such as NAT64 (IPv4 service continuity).
If you don't perceive that function as a "benefit", can you please answer the
following:
* Because your operator is running out of IPv4 addresses, it decides to give
you an IPv6 prefix without enabling any function in the network. Won't you call
the hotline of that operator to claim that you don't access to most of Internet
resources and that something is to be fixed otherwise you will unsubscribe?
* When you are attending an IETF meeting, I assume you are using IPv6-only
SSID. Do you volunteer to opt-out from NAT64 in the coming meeting?
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.
[Med] Fully agree. This is why we need to understand the intended usage to have
a reference for any 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:-)