On 13 Nov 2017, at 10:06 pm, Victor Kuarsingh <victor@xxxxxxxxxx> wrote: > On Mon, Nov 13, 2017 at 3:08 AM, Mark Nottingham <mnot@xxxxxxxx> wrote: >> Since we're talking about the title, I had a different reaction to it; currently, it reads as if *all* operators are necessarily affected by pervasive encryption. >> >> In the discussions I've had, the great majority of operators have said they are not affected by pervasive encryption (YMMV, of course), so I wonder if a title like "Reported Effects of Pervasive Encryption on Operators" or "Effects of Pervasive Encryption Purportedly Encountered by Some Operators" would be more appropriate. > > I don't think we have enough data to put any quantitative value on > this. What we have is a list of considerations / issues based on > input. Suggesting "some" would be as erroneous as suggesting "many". > The current titles seems to be neutral in this regard. I disagree; "effect" implies it's complete and always encountered; it reads as "*The* effect". > I don't have any specific issues with adding work "Reported" in title, > but does that really add any intrinsic value to the reader? (assuming > one reads the draft and does not stop at the title). To be explicit -- part of my problem with this draft as written is that it's pretty obviously had significant edits to the Introduction to try to re-cast it and address the concerns raised, but the body of the text (as well as the title) have not been changed to align with that. As such, someone reading isolated parts of the RFC (yes, that happens) could be mislead about the IETF's position on these things. The title goes a long way to setting the stage for how someone reads a document; it's what shows up in citations. >> Even then, many of the areas discussed lack important context about whether or not there are other options to achieve the same goal, and how prevalent their use by operators is. For example, the sections on Content Compression and Content Encryption beg these questions. > > It's possible solutions deployed by operators may have other technical > options, however we lack the full set of data to make claims that > other options can be used, or if so, what obstacles need to be > overcome to change deployments. There would likely be both technical > and business factors those entities need to address to change things. > > Even if there is agreement and a desire to change things, it often > takes time to change production networks which means items listed are > factors for consideration. My point is that in some cases, the goals listed may be met by parties other than operators, and that's worth mentioning. >> It might be useful to have a list of potential effects on network operators without that context, but some of the items still seem to be written in a way that assumes the intrinsic value and uniqueness of the technique being discussed (e.g., Performance Enhancing Proxies), which can be deeply misleading (despite the attempt at positioning in the Introduction). If this were Wikipedia, I'd say there were several NPOV issues remaining here. > > Who do we think we are misleading? The section seems to describe > proxies used in mobile networks to deal with real performance issues > related to that access network type. As a former mobile network > architect and operator, I don't see an issue with what is described. > There are real latency issues to deal with there and this is one way > some have dealt with them. Even within a single mobile provider's > network, there are often varying technical challenges to deal with > from market to market. The term "Performance-Enhancing Proxy" generally refers to a number of different techniques (as RFC3135 explains). Amongst people who run services, PEPs are widely known to cause problems with performance, rather than enhance it, because many operators deploy and forget them. Having an appliance that's optimising the 2017 Internet for conditions in 2005 isn't helping. Saying that the technique "measurably improves" it (the draft's words) isn't the whole story. -- Mark Nottingham https://www.mnot.net/