Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De : Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] > Envoyé : mercredi 12 avril 2017 10:35 > À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Martin Thomson; ietf@xxxxxxxx > Cc : draft-dolson-plus-middlebox-benefits@xxxxxxxxxxxxxx > Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft- > mm-wg-effect-encrypt-09) > > > Hiya, > > On 12/04/17 09:13, mohamed.boucadair@xxxxxxxxxx wrote: > > Hi Stephen, > > > > Please see inline. > > > > Cheers, Med > > > >> -----Message d'origine----- De : Stephen Farrell > >> [mailto:stephen.farrell@xxxxxxxxx] Envoyé : mardi 11 avril 2017 > >> 20:34 À : Dave Dolson; BOUCADAIR Mohamed IMT/OLN; Martin Thomson; > >> ietf@xxxxxxxx Cc : > >> draft-dolson-plus-middlebox-benefits@xxxxxxxxxxxxxx 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). > > I'm not sure that s/benefits/services/g in the document text > would work, so I don't accept that argument. If you meant > something else, I'm not sure what. > > > > > 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? > > I did not argue that no middlebox ever provided any benefit [Med] Cool. This is not what I understood from your initial comment: "...if the claimed benefits accrue as hoped for" ^^^^^^^^^^ > to anyone so I don't know how answering the above questions > would help. [Med] I helps to understand what we can call "beneficial" or not. Having concrete examples is helpful. > > But in case it does help: yes, firewalls have provided some > benefits over the years. I suspect those are now diminishing > but could be wrong. I don't know if it's gotten to the point > that firewalls are more of a benefit or a scourge today. (Having > just had the fun of installing a stun/turn server to get two > browsers to chat with one another, I can freshly attest to the > "pointless scourge" aspect as I didn't have to ask the f/w > admins anything to get around the useless barrier they were > in this particular case;-) > > It might be possible to do studies and produce data that'd help > the community decide that question (f/w utility vs. scourge) and > that could be a useful activity, if done objectively. That last > (objectivity) seems hard though, as it seems there are many folks > who find being objective in this space difficult (on all sides). [Med] Yes, that's a collective effort to be made by all. In the meantime, we need to remember that IETF is supposed to do ENGINEERING. > I've no idea if similar studies and data could help with > (re-)evaluating other aspects of middlebox deployment claimed > utility. > > And again, I see no utility at all in a statements along the > lines that "firewalls are beneficial because they can do X." > > S. > > > > > > > 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.boucadair@xxxxxxxxxx Sent: Tuesday, April 11, 2017 7:48 > >>> AM To: Stephen Farrell; Martin Thomson; ietf@xxxxxxxx Cc: > >>> draft-dolson-plus-middlebox-benefits@xxxxxxxxxxxxxx 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.farrell@xxxxxxxxx] Envoyé : mardi 11 avril > >>>> 2017 10:51 À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson; > >>>> ietf@xxxxxxxx Cc : > >>>> draft-dolson-plus-middlebox-benefits@xxxxxxxxxxxxxx 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.boucadair@xxxxxxxxxx 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:-) > >>>> > >>>> > >>>> > >>> > >