Hi, I want to weigh in supporting the publication of this document. I was a document author and then WG chair in CCAMP at a time when it was exceeding hard to get a GMPLS RFC published because the security considerations for GMPLS "were not properly documented". I can confess that I became very disillusioned with the IETF process and with the serving Security ADs at the time. It took a lot of discussion for me to be convinced that the ADs were doing what they genuinely thought was best for the Internet (even though they were wrong ;-) But it was not the existence of any document describing security consideration sections that enabled the ADs to block publication. Nor was it some wrinkle in the process. It was the right and proper process that enables ADs to worry about the impact on the stability (which includes security) of the Internet when looking at publication requests. Furthermore, it was not the process per se that was at fault, it was the enthusiasm of the ADs, and *that* was perfectly possible to handle using the existing processes (although it was a steep learning curve for me) and normal discussions about which we should never be defensive or paranoid. So, why do I rake up the past now? This document in its current form does not, IMHO, represent a tool that can be used by any AD to block or cause delay to the publication of any RFC. If anything, it provides assistance to authors to enable them to think about some new yet key issues and include the right discussions in their documents. The document goes nowhere near as far as RFC 5706 in "dictating" what has to be documented in a protocol spec yet I don't recall any fuss about that document. Far from it: this document simply describes the landscape, explains how privacy attacks may be happening, and indicates that the authors think that such attacks should be considered in the design of protocols. And there is a get-out-of-jail-free card that I would find perfectly acceptable: This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been addressed?" Note that that discussion can be in the shepherd write-up, on the mailing list, in a conversation with the Sec AD during evaluation or (and only if the authors/WG want to) in the I-D. I do not find the discussions of opinions voiced against this I-D to be convincing, and I support its publication. Thanks, Adrian