The IESG has made a conclusion on draft-farrell-perpass [1]. This draft was extensively discussed during the last call and within the IESG. As you have seen, there has also been a number of document revisions and changes based on the discussion. The last version reflected changes that the IESG felt were necessary to move forward. It has not been an easy to task to determine what the final outcome should be. The IESG took the approach that the document should reflect community opinion, not just our opinions, even if many of us had strong opinions on the topic. But even reflecting community opinion was not easy. I have over 700 e-mails on this topic, some of those e-mails focus on specific aspects, and the opinions and the draft changed as the discussion progressed [2]. Nevertheless, I want to thank everyone who has contributed on this topic. You really care about this topic, and making the right recommendations at the IETF. Thank you. The IESG believed there eventually was consensus to publish the document and our main question was whether the document should proceed as initially planned (BCP) or whether it should be downgraded to Informational. After a discussion we have concluded that there is (very) rough consensus to publish the document as BCP. While there was clearly no full consensus, we believe that issues were discussed sufficiently to allow them to be addressed - even if no full agreement with the entire group could be reached. There were three high-level concerns that I wanted to discuss in this e-mail: 1) Some forms of network management, traffic measurements, and similar important tasks might be affected by a broad definition of pervasive surveillance. We should obviously not make legitimate networking tasks harder, and that was not the intent of the document. In the last version, we believe that the the third last paragraph of Section 2 clarifies this sufficiently. 2) The document has too little specific guidance, making it difficult to follow it as a rule (if the document is a BCP) and is easily subject to mis- or over-application. The document is indeed thin on the specific guidance. Its primary message is to say that pervasive monitoring is yet another threat that we need to consider when working on Internet technology. This seems inline with RFC 2026 notion that BCPs can be "community's best current thinking on a statement of principle". Also, we see positive signs about many of those more specific details emerging in various documents. 3) The document, particularly as a BCP, could be used to block documents by ADs in an unreasonable fashion. There was considerable concern about this. However, the IESG process for document approval is most commonly not based on specific rules in existing RFCs, but rather specific technical concerns of the individual AD reviewers. ADs occasionally raise invalid issues on documents, and we expect (and get) pushback when that happens. I have certainly made mistakes when filing a Discuss. These are resolved through discussion. In more severe cases, we have override procedures, appeals, discussions with the Nomcom, and recall procedures to deal with these issues. In other words, if we start from the assumption of a misbehaving AD, no new documents are needed to file an inappropriate Discuss. Any AD can raise concerns about pervasive monitoring under the current Discuss criteria, and this document doesn't change that. We don't think this document will significantly change things for the worse. However, the IESG felt that there is an opportunity to clarify our procedures with regards to this specific case: The IESG intends to make a change to its Discuss criteria statement [3]. While the general thrust of the statement already indicates that AD disagreement with informed WG consensus is a NOT an acceptable basis for a discuss, we wanted to say that more explicitly in the specific context of adequate consideration for pervasive monitoring issues. Section 3.2 of the Discuss criteria statement is about criteria that are not appropriate basis for a Discuss. We plan to say that while it is generally necessary that IETF work considers the impact of specific threats such as pervasive surveillance, informed and rational community decisions about the particular protocols and the possible need for mitigating mechanisms will be respected. In addition, there were a number of other issues that were discussed. These included, for instance: - Request to not support more encryption, and a point that surveillance can have good or useful motives. (Although there is little by way of solutions in the current draft, and previous RFCs have already talked at length about IETF position towards encryption.) - Argument that the document will lead to one concern dominating others. (The draft says "... mitigate the technical aspects of PM, just as we do for protocol vulnerabilities in general") - Architectural issues and separate legal/political remedies should be brought up. (They are now.) - Whether to describe the issue as an attack or as indistinguishable from an attack. (Current text is the result of the discussion started by Stephen Kent.) - The textual style of the document is that it reads as "too offended". (Some changes were done regarding this, but otherwise this comment was considered to be in the rough.) - The document should include a checklist and more detailed actions. (See 2 above. Also, various documents under development are more likely to produce a more fine-grained guidance on specific issues.) This e-mail is a report of the IESG's conclusion on the matter. I will proceed with the approval of the document in the next couple of days. References: [1] http://tools.ietf.org/html/draft-farrell-perpass-attack-06 [2] http://tools.ietf.org/rfcdiff?url1=draft-farrell-perpass-attack-02.txt&url2=draft-farrell-perpass-attack-06.txt [3] https://www.ietf.org/iesg/statement/discuss-criteria.html Jari Arkko for the IESG