Thank you, Ben. These are helpful and actionable comments. If I had time before the telechat, I would update. We’ll include these just after the telechat.
Best, Kathleen Sent from my mobile device > On Feb 6, 2018, at 6:36 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > > A few things that earned a red pen while I was reading. > Sadly, I did not have time to correlate with other reviews, so > probably some of these were already caught. > > Abstract: > > "recognized that making networks unmanageable" (add "that") > comma --> semicolon after outcome > > Section 1.1, first paragraph, last sentence: this sentence is pretty > rambly -- "the acceptance of" may be unneeded, and the last clause > could become ", since the latter is more easily deployed than the > former, and is preferrable to no encryption at all" > > Page 5, last line, s/enhances/enhance/ > > Page 6, second paragraph, "preventing the vulnerability described > above by providing an end-to-end solution" -- "providing an > end-to-end solution" does not itself describe a vulnerability. > > Page 7, first (partial) paragraph, last sentence: there seem to be > missing or vague (pro)nouns -- who is "they", and the actions are > taken by several what? > > Section 2, second pargraph, s/purpose of each technique/purpose of > several techniques/ -- this is not an exhaustive listing. > > Section 2.2.1, first paragraph, does "this configuration" inherently > require TLS termination, or only some configurations of it? > > Page 12, penultimate and last paragraphs: we seem to talk about > using the sequence number as a cookie before we talk about TCP > allowing the use of server-generated sequence numbers for a side > channel, which seems out of order. > > I'm pretty sure (e.g.) Christian already noted that section 2.2.3 > reads more like a note-to-self than complete sentences, but just in > case he didn't, it does. > > Section 2.2.4, first sentence, s/,/;/ to avoid a comma splice > > Page 14, last line, s/changing/changes > > Section 2.2.5, first paragraph, last sentence, I think it would help > to clarify the nature of the business risk, since it's not really > covered very much immediately prior. > > I'm not sure that the last paragraph of section 2.2.7 adds any > value. > > Section 2.3, last sentence, s/,/;/ again > > Page 17, last (partial) pargraph, second sentence, s/,/;/ > Next sentence, I don't think this si really TLS-specific, and I > might s/where this/that/, if I understand the intent correctly. > > I'm always surprised to see "SPAM" in all-caps, as it's not an > acronym or abbreviation. > > Page 26, second line, "the storage" (add "the") > > Section 4.1.3.2: > second line, s/allow/allows/ > s/The use TCP/The use of TCP/ > last sentence, "Troubleshooting capabilities with encrypted sessions > from the middlebox may be limited to the use of [...]" > > Page 38, first complete sentence, I don't understand what this is > trying to say. Currently you'll usally see an SNI; is this trying > to say that in a move to a more-encrypted world this signal will go > away? > > Section 7.4, I'm a bit confused by the first sentence. Maybe, > "Transport header encryption prevents trusted transit proxies from > [existing|doing some sort of thing]"? > Or maybe just s/prevents/prohibits/? > > Page 41, OS is used before it is expanded. > > > Hope this is helpful (and feel free to repost somewhere public if > you think it's merited), > > Benjamin _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
