Hi Mark, Thank you for your comments. This draft is in the process of a major revision and will have another IETF last call. I think most of your pikers have been considered, but we'll make sure prior to posting an update. Best regards, Kathleen Sent from my iPhone > On Apr 30, 2017, at 11:45 PM, Mark Nottingham <mnot@xxxxxxxx> wrote: > > Sorry for the late review; on the plus side, I'm coming to it with fresh eyes. > > Overall, this document reads as if it was originally written to highlight the downsides of increased use of encryption, and then rewritten to be more neutral in tone. Unfortunately, some of the original intent posited there still seeps through. > > In doing so, it often fails to convey that there are any options other than "this has to be done by the network." I know that this has been cast as a survey of potential impacts, and therefore doesn't necessary need to enumerate alternatives, but the way that it's written could easily lead a reader to think that there aren't alternatives. It also is odd that alternatives are not enumerated when they're often well-known, and the really interesting issues are in the tradeoffs between doing something in the network (i.e., as a third party) vs. by one of the endpoints (a first party to communication) or their delegates. > > For example, Section 2.2 talks about the importance of passive monitoring for traffic surveys, but fails to discuss alternative means of gathering data (e.g., anonymised data from content providers; telemetry from client implementations) that are superior in some ways, limited in others. It would be a useful contribution to characterise the tradeoffs here, so this is an opportunity lost. > > Section 2.3.2.1 points out that "Web proxies are widely used", but fails to note that the vast bulk of caching is done by endpoints -- browsers, CDNs and reverse proxies, thereby sidestepping the issues of encryption (although they have their own unique challenges). Discussing why this form of caching has become prevalent might help inform network operators as to why getting the economics and trust relationships of intermediation right is important. > > Section 2.3.2.2 motivates DPI as "Input for Differential Treatment", but fails to note the developing efforts to coordinate client and server behaviour to adapt to network conditions, without the need for stripping encryption. > > Section 2.4 talks about need for compression proxies, but fails to note the deployment of them in overlay networks (e.g., by Google Chrome, UCBrowser, Opera Mini, etc.). There is a minefield of issues surrounding them, of course, but it's useful context. > > Section 2.5.2 does note that endpoint-based alternatives might be possible, but fizzles out after that. Exploring why they haven't developed would be a substantial contribution. > > A few additional points: > > * The Introduction says "it is important to catalog existing standard functions around network management, security and troubleshooting that have depending upon the availability of open information to function." Using the word "standard" here is misleading; some of the described functions are not envisioned or enshrined by Internet Standards. > > * The Introduction says "The IETF reiterates its view that pervasive monitoring is an attack..." It's odd to have an Informational document "reiterate" a BCP. > > * Much of the Introduction motivates this document as being about "network management, security and troubleshooting." Then, later, it inserts things like "monitoring services", policy enforcement, and parental controls. These are qualitatively very different things. Being able to monitor and run the network to provide a service is not the same as being able to impose your will upon the users of that service. Elevating the latter to the status of the former is not something we should even unintentionally imply, even if it is common practice. > > * Section 1.1 asserts that "Increased use of encryption (either opportunistic or authenticated) will impact operations for security and network management, causing a shift in how these functions are performed." This is an assertion about the future that's quite strong. I could see it saying that they *have* impacted, and then giving examples, or that they *might* impact them in the future, but asserting that it *will* impact them seems like an assertion that doesn't have IETF consensus. > > * Section 2.6.5 talks about injecting HTTP headers into a connection and fails to note the significant privacy issues brought about by this practice. Using encryption to defeat this is, to many in the IETF community, a feature, not a bug. > > > Hope this helps, > > -- > Mark Nottingham https://www.mnot.net/ >