Re: conclusion on draft-farrell-perpass

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you!

Apologies for the hassle, I owe you beers:-)

But seriously, thanks for sponsoring this and doing such a thorough job.

S


On 27 February 2014 11:51:21 GMT+00:00, IETF Chair <chair@xxxxxxxx> wrote:
>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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]