Alissa Cooper has entered the following ballot position for draft-mm-wg-effect-encrypt-17: Abstain
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Many thanks for all the effort that has gone in to addressing all the comments from the last IESG review and from the community. I find this version to be much improved from the last time the IESG reviewed it. However, I do not feel that I can support the publication of the document. While the tone has improved in many places and the introduction does a better job of contextualizing the document, the document still contains text in several sections that states service providers' claims about their practices as facts rather than stating them as claims or presenting the practices in a neutral way. This was a point raised in my previous DISCUSS (I've included my previous DISCUSS ballot text below in full for reference). In the previous review round Warren had invited recommendations for places where the tone or choice of words could be made more neutral or balanced, and I provided many detailed suggestions, but a number of those were not adopted. I also realize that the introduction contains much of the disclaimer text we previously hashed out to try to address this, but it doesn't contain all of it. So this is still a major issue for the document, IMO. The document also still extemporizes about future possible impacts, making it hard to come away with a neutral view of their treatment, as I noted in my previous DISCUSS ballot. I support the DISCUSS position held by Ekr. But given the above I don't think it will be fruitful for me to continue to engage on the details of this document, so I'm abstaining. I've included below some of the areas that I still find problematic, as well as some nits. Problematic areas: = Section 2.1.2 = (1) "Network operators are often the first ones called upon to investigate application problems" I still contend that without data to back this up, this claim should not be made, especially for the enterprise context. (2) "Vendors must be aware that in order for operators to better troubleshoot and manage networks with increasing amounts of encrypted traffic, built-in diagnostics and serviceability must be enhanced to provide detailed logging and debugging capabilities that, when possible, can reveal cleartext network parameters." If I try to paraphrase this it sounds like "vendors should build in capabilities to decrypt encrypted traffic." Was that the intent? = Section 2.2.4 = I agree with Christian Huitema's unresolved comments on this section. In the thread regarding his comments Kathleen said "we don't want to make general statements that aren't necessarily true" -- IMO that is what the middle three paragraphs in this section are doing. At a minimum, I think the characterizations about the effects of performance-enhancing proxies needs to be qualified by saying "some operators find that ..." rather than stating their effects as fact. = Section 2.2.7 = "There is work in progress to specify protocols that permit Service Function Chaining (SFC)." I don't think it makes sense to have this forward-looking statement when Section 1 states that "This document describes practices currently used by network operators to manage, operate, and secure their networks." I think it makes sense to focus this section on how existing SFC deployments have stopped functioning because of increased use of encrypted traffic, but it seems unfair to claim that some future, yet-to-deployed functionality will be broken. = Section 2.3.2 = "As a result, some mobile carriers block customer's encrypted requests, which is a far less optimal customer experience because the blocking reason must be conveyed by some other means." This could easily be read to imply that sending requests in cleartext is optimal. Overall, the use of the words "usual," "optimal," and "often" in this section imply a level of generality that is unwarranted I think. = Section 5.6 = The implications for SAVI seem speculative unless you can point to SAVI deployments that have been impacted by increased use of encryption. Nits: = Abstract = s/Pervasive Monitoring (PM) attacks on the privacy of Internet users is of serious concern/Pervasive Monitoring (PM) attacks on the privacy of Internet users are of serious concern/ = Section 2.1.2 = (1) "Further, the performance of some services can be more efficiently managed and repaired when information on user transactions is available to the service provider. It may be possible to continue such monitoring activities without clear text access to the application layers of interest ..." It's not clear what "such monitoring" refers to, since the previous sentence is about performance management and service repair. (2) Is "User/Service Key Quality Indicators" a term of art? It seems weird to be capitalized. = Section 2.2.3 = This section seems like it was left in the document by mistake. = Section 2.3 = "As previously stated, the intent of this document is to document existing practices, the development of IETF protocols follows the guiding principles of [RFC1984] and [RFC2804]." Is that comma supposed to be a period? I'm not following the grammar here. = Section 2.3.1 = s/However, the lack of ability to efficiently manage endpoints as a service reduces providers' ability to offer parental control./However, the lack of ability to efficiently manage endpoints as a service reduces network service providers' ability to offer parental control./ = Section 4.1.2 = It seems like a single reference to RFC 8250 would suffice. = Section 7.4 = What is a trusted transit proxy? ---------------------------------------------------------------- Previous DISCUSS ballot text: I have cleared my original DISCUSS point from my earlier review -- I get what the text is saying now, although I still think the "lose the option" language implies some entitlement to the option in the first place, which seems inappropriate. But given the reviews from Martin Thomson and Christian Huitema, it's not clear to me that this document represents the consensus view of the IETF community. Kathleen's response to Martin reinforces the point that we were discussing in the first ballot cycle, which is that this document is written for and represents operators, not the broader array of Internet interests. Yet the suggestion to state that fact up front in the document was not adopted. Having had some more time to review this document than I had in the previous ballot cycle, I also am finding myself in agreement with significant portions of the reviews from Martin and Christian. Reading their reviews helped crystallize a lot of the difficulty I had in parsing this document the first time around. I understand the rationale that led to this document being written and I think there is a version of this document that could be written that would achieve the original goals while giving the subject matter a readable, neutral treatment. Such a version would be a useful contribution. But I don't think this document achieves that. In particular, there are four things that I think it would need to do to achieve that: 1. State the analysis in a neutral way. As I had mentioned in one of the email threads for the previous ballot cycle, I believe this document could be written in a neutral way -- e.g., “Service providers currently do X. It is implemented using Y mechanism. Encryption at Z layer breaks current implementations.” -- but it is not. Instead it characterizes many of the practices described as "optimizations" or "features" or "enrichment" and states service providers' claims about what these practices accomplish (e.g., "maximize QOE") as facts rather than stating them as the reasons given by service providers for why they engage in the practices. This is why in the previous round I suggested the disclaimer at the top of the document to say that the document is giving a view from service providers; that apparently didn't go anywhere, so the other option is to describe each technique neutrally, or explain with each technique that the characterization of the benefits is from the view of the operator. Martin's comments about being clear about who is benefitting point this out as well. 2. Limit the discussion to techniques presently being affected and those effects. There is a bunch of extemporizing about future possible impacts (e.g., in Sec. 2.7, 4.1.2, 4.1.3.1, 5.7, 7, 8). It's very hard to characterize future implications, who will bear the "cost" for what, whether increases in user complaints to various parties are "worth it," etc., in a way that is perceived as neutral by all affected parties. Better not to make predictions if the goal is to give a neutral treatment of network functions being impacted today. 3. Acknowledge the controversy. Many of the practices described in this document are controversial, and have been for a long time. There is nothing wrong with that. I agree with Christian that it would be better to state an understanding of that head-on rather than leave it to the reader to decide whether any particular characterization of something described implies an endorsement of it. This has been done before, even in potentially controversial documents that this document references, e.g. RFC 3135. 4. Structure the document in a way that is consistent and logical with minimal repetition. It seems like there are multiple ways that this could be done. Organizing based on use case (per Christian) and then discussing techniques used within each use case is one way; organizing based on technique while mentioning the goals for which each technique is employed is another. At present the document is jumble of these. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
