Greetings. Regarding http://tools.ietf.org/html/draft-farrell-perpass-attack-02 I think a document like this needs prose that is clear, straight to the point, easy to follow, persuasive, confident, convincing, inspiring. It should be, at least more than your ordinary RFC, a work of art, and in art it is often necessary to start over from scratch than making a few tweaks here and there. An important reason is that, as I understand it, some would like to use the document as substitute for debate. It is not good enough for that. If an IETF Working Group participants wants the group to consider wire- tapping requirements, and a pointer to RFC 2804 puts an end to that, I think that's fair. If I saw draft-farrell-perpass-attack-02 used this way or otherwise having such an effect, I think that would not be fair. This is my intuitive reaction from reading through the document a few times; I suspect there are material reasons, but some editorial issues are easy to identify. I think it may be useful to point some of them out while I continue to review the document. (This is a mind-dump provided as-is from first impressions, not something I intend to argue over). The Abstract is this: The IETF has consensus that pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. The last two words do not belong here. If they mattered they should not be left as a hanging appendage to the sentence but appear prominently, but they do not even matter, the Abstract does not need to highlight that the IETF does not have consensus on something impossible. The qualifier "technical" makes the document appear deceptive. I do not understand what it means, why it is there. I will have to keep this in mind throughout the rest of the document, but human brains have a rather limited set of registers, odds are I will forget about the four touch- downs in a single game. I think the document does not actually explain why this qualifier is in the Abstract. My impression is that it is not needed there. The document continues: 1. It's an Attack The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive monitoring. Such pervasive surveillance requires the monitoring party to take actions that are indistinguishable from an attack on Internet communications. Participants at that meeting therefore expressed strong agreement that this was an attack that should be mitigated where possible via the design of protocols that make pervasive monitoring significantly more expensive or infeasible. There are many problems here. The biggest is probably that I get the impression that this is twisted on a technicality. The logic is thus: 1. X is not an attack. 2. X is indistinguishable from an attack. 3. X is therefore an attack. If X was an attack then "indistinguishable from an attack" would be un- necessary, so I get the impression that I am missing some important detail here. Also note that this appears to be the central argument of the document, but unlike the Abstract, it's just "attack", not "techni- cal attack". The first time I looked at the document this was the point where I stopped reading and instead scroll through the document to see what else is there, and then put it aside for later when I can concen- trate better. Another problem is that the second sentence equates "pervasive moni- toring" with "pervasive surveillance". That makes me wonder whether the two are actually precisely the same thing, and I note that the document does not actually introduce or define either of them before this point and never defines "pervasive surveillance". We are thrown right into "It's an Attack". Contrast this with RFC 2804 which takes care to start with a "Summary position" section, later discusses "The Raven process", and then provides "A definition of wiretapping". That is a clear separation of concerns, this draft throws it all together. The document continues This Best Current Practice (BCP) formally documents that consensus, having been through an IETF last call. Before the document talked about meeting participants expressing strong agreement. "That" is not consensus, some people in Vancouver expressing something is not a method of finding IETF consensus. The "oh yeah, there was also a last call" appendage does not help here. It seems to me that this should be the other way around, IETF Consensus, oh yeah, and there was a meeting in Vancouver, by the way. I am sorry if this seems petty, but the dominant capitalisation is "Last Call"; "last call" gives an impression of carelessness and haste, not an impression of careful attention to detail. I think "Best Current Practice" is a qualifier that cannot stand on its own (something like "document" should follow), and it is probably not a good idea to emphasise the formal document status in the document, it gives too much of a sense of "look at me! I'm important! And I need to point this out! Because, actually I am not that important after all". I also think this document is probably intended for a wide audience, so it should avoid abbreviations as much as possible. (To stick with the re- ference, RFC 2804 only abbreviates and explains the abbreviation for "IESG" and "IAB" and uses them only in immaterial sections). Later in the document The term "attack" is used here in a technical sense that differs somewhat from common English usage. In common English usage, an "attack" is an aggressive action perpetrated by an opponent, intended to enforce the opponent's will on the attacked party. In the Internet, the term is used to refer to a behavior that subverts the intent of a communicator without the agreement of the parties to the communication. I speak English only as a third language, but my impression is "intended to enforce the opponent's will on the attacked party" is not in fact part of how the word is usually or even commonly understood. I think "In the Internet, the term is used" is not suitable prose for a general audience. This is more something like "when the Security Con- siderations sections of IETF specifications refer to an 'attack', then". I suspect the document probably should not give the impression to IETF outsiders that "we" speak in some sort of "code" where words do not mean what they ordinarily mean. It might be an option to simply say what the memo means by the word "attack" without reference to other definitions. Later on In particular, the term "attack", when used technically, implies nothing about the motivation of the actor mounting the attack. My initial impression was that this contradicts the earlier definition, for instance, it seems to me that the "motivation" is to subvert "the intent of a communicator without the agreement of the parties". I do not see how "monitoring" and "surveillance" are free of "motiviation", so I am not sure if this is trying to explain "attack" independently of the main points of the document, or what else might be the point. Later in the same paragraph ... The same techniques can be used regardless of motivation and we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be. ... This probably is a Central point of the document but it is lumped to- gether with other things in a single paragraph. The "other" section of the document carries this headline 2. And We Will Continue to Mitigate the Attack This is like saying that we will "further perfect the optimisations". To me this mainly conveys insecurity, don't want anyone to think "we"'ve not done this before now. Right, it's like calling something "Network News Transfer Protocol Great International Consensus Standard" instead of just "NNTP". It's desperate and probably means the opposite. And clearly, starting a sentence with a conjunction is very transparent. As Bender learned, "When you do things right, people won't be sure you've done anything at all." In the hope this helps, -- Björn Höhrmann · mailto:bjoern@xxxxxxxxxxxx · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/