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