Following up on an obscure point ... On Tue, Feb 6, 2018 at 11:40 PM, Ben Campbell <b...@nostrum.com> wrote:
> Ben Campbell has entered the following ballot position for > draft-mm-wg-effect-encrypt-17: No Objection > > 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: > ---------------------------------------------------------------------- > > This is a considerably better document than the previous versions I have > reviewed. Thanks for all that work. But of course, I still have some > comments > :-) > > Substantive Comments: > > -2.2.2, 2nd paragraph: "... for example, many > forms of communications (from isochronous/real-time to bulk/elastic > file transfer) will take place over HTTP port 80 or port 443, so only > the messages and higher-layer data will make application > differentiation possible." > > I'm confused about the use of port 443 in that sentence; presumably > traffic to > 443 will be encrypted and not allow differentiation using higher-layer > data. > > -2.2.4: This section lacks a discussion of the impact of encryption. > > -2.2.5, last paragraph: I understand that techniques that require endpoint > cooperation might be out of scope, but the tone of this paragraph makes it > sound like requiring endpoint cooperation is a negative. Is that the > intent? > > -2.3, section title: The title is only partially evocative of the section > content. I suggest adding "content filtering". > > -2.3.1: I think it might be worth mentioning that an "intercepting > certificate" > requires endpoints to be configured to trust that certificate. (I assume > we are > not talking about the more unsavory practice of certificates that > misrepresent > their subjects. > > -2.3.4 I concur with Adam that this section should explicitly mention > "cross-site user tracking" as one of the common motivations for header > insertion/enrichment. I think it should also include a mention of RFC 8165. > > -5.2: This section doesn't seem to include discussion of the impact of > encryption. > > Editorial and nits: > > -IDNits finds a number of unused references, and a few other reference > issues. > Please check. > > - Abstract: 2nd sentence is hard to parse, and ends with a comma splice. > > - 1, 2nd paragraph: " The following informational > documents consider the end to end (e2e) architectural principle, a > guiding principle for the development of Internet protocols [RFC2775] > [RFC3724] [RFC7754]." > > Is the comma correct? It currently reads along the lines of "The documents > consider the e2e principle, and we think that it is a guiding > principle...", > but I think you might mean "The documents consider the e2e to be a guiding > principle..." > > -1, 3rd paragraph: "... (including methods for network > endpoints where applicable)..." > Should that say "methods that rely on network endpoints"? > > -2.1.1: Please expand "CAIDA" > > -2.1.1: Paragraph starting with " > When using increased encryption, operators lose a source of data that > may be used to debug user issues." > I don't think the operators are the ones using the encreased encryption in > that > sentence. Perhaps "When endpoints use increased encryption..." or even > (When > increased encryption is used..." > > -2.1.3, 2nd paragraph: "The ability to examine layers and payloads > above transport provides a new range of filtering opportunities at > each layer in the clear. " > Should "new range" be "increased range"? > > -2.1.3, third paragraph: The last sentence seems out of place. Is the > point of > the paragraph to point out that the use of these monitoring techniques for > DoS > mitigation can't be distinguished from the use of them for privacy > violation? > > -2.2.1: Please expand "QUIC" and add a citation. > QUIC started out as an acronym (and went through two or three variations), but sometime during the chartering process, the expansion was dropped. QUIC is both the working group name and abbreviation in https://datatracker.ietf.org/wg/quic/about/. But citations are good :-) > > -2.2.3, last sentence: Sentence fragment. > > -2.2.4, first sentence: Comma splice. > > -2.2.5, first paragraph: " Encryption of packet contents at a given > protocol layer usually makes DPI processing of that layer and higher > layers impossible. " > > This sentence seems misplaced; the section is not about DPI. > > -- same paragraph: I don't understand the point(s) of the last two > sentences. > > -2.2.5, third paragraph: "The Enhanced Multimedia Broadcast/ > Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate > delivering same stream to different users, using either unicast or > multicast depending on channel conditions to the user. " > > I can't parse that sentence. > > -2.3.3: Please make the "SHOULD" lower case. Since this document does not > use > RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a > literal quote. > > -3: "Businesses understanding the > threats of monitoring in hosted environments only increased that > pressure to provide more secure access and session encryption" > > Why "only"? That seems to suggest one would expect some different result. > > -3.1.2: This section is about Hosting SPs, but the last two paragraphs > seem to > be about ASPs. While I realize those may sometimes be the same > organization, > they are architecturally distinct. > > -3.2.2: "STARTTLS ought have zero effect..." > "Ought to have zero effect" or "has little effect"? (If the former, it's > safe > to say "should" since this draft does not use RFC 2119 keywords.) > > -3.2.2, last paragraph: Should "SPAM filtering" be "content-based SPAM > filtering"? > > -4.2: What does it mean for tools to "use" keywords? Does this mean "search > for" or "monitor for" keywords? > > -5.4: This seems to say that "Detection and Mitigations" involves > thousands of > hosts, etc. I think the point is that the botnets themselves may involve > thousands of hosts..." > > -7 and subsections: It looks like the editing of this section is not > finished; > several sections indicate they are to be deleted. > > -7.4: Please describe what you mean by "transit proxies". > > I can't parse item 4. The entire section could use proofreading for missing > articles. > > -12: Are there really no normative references? The definition of a > "normative > reference" is any reference needed to fully implement or _understand_ the > document. This is true for both informational and standards-track > documents. Do > you think a reader can fully understand this document if they ignore every > reference? (I'm willing to accept that the answer might be "yes" given the > nature of this draft--but that situation is rare in practice.) > > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
