Telechat Review of draft-farrell-perpass-attack-05
review-farrell-perpass-attack-05-genart-telechat-brim-2014-01-31-00

Request Review of draft-farrell-perpass-attack
Requested revision No specific revision (document currently at 06)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-02-04
Requested 2014-01-23
Authors Stephen Farrell , Hannes Tschofenig
I-D last updated 2014-01-31
Completed reviews Genart Last Call review of -03 by Scott W. Brim (diff)
Genart Last Call review of -04 by Scott W. Brim (diff)
Genart Telechat review of -05 by Scott W. Brim (diff)
Secdir Last Call review of -02 by Adam W. Montville (diff)
Opsdir Last Call review of -03 by Dan Romascanu (diff)
Assignment Reviewer Scott W. Brim
State Completed
Request Telechat review on draft-farrell-perpass-attack by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 06)
Result Ready
Completed 2014-01-31
review-farrell-perpass-attack-05-genart-telechat-brim-2014-01-31-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< 

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-farrell-perpass-attack-05
Reviewer: Scott Brim
Review Date: 2014-02-01
IETF LC End Date: 2013-12-31
IESG Telechat date: 2014-02-06

Summary: This draft is ready for publication as a BCP.

Major issues:

Minor issues:

Nits/editorial comments:

Two comments:

First, there are good arguments for publication as Informational , but
since it incrementally adds to BCP 72, it should be incorporated
there, so BCP is slightly better.

Second, the only significant difference from -04 was the removal of
"and be prepared to justify their decisions". There was a lot of
discussion that led to this, and some concern that the statement on
architectural considerations is not strongly enough worded without it.
However, see the previous paragraph (both paragraphs are below).  I
believe that these two paragraphs, taken together, do what is desired.

   Those developing IETF specifications need to be able to describe how
   they have considered PM, and, if the attack is relevant to the work
   to be published, be able to justify related design decisions.  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 considered?"

   In particular, architectural decisions, including which existing
   technology is re-used, may significantly impact the vulnerability of
   a protocol to PM.  Those developing IETF specifications therefore
   need to consider mitigating PM when making these architectural
   decisions.  Getting adequate, early review of architectural decisions
   including whether appropriate mitigation of PM can be made is
   important.  Revisiting these architectural decisions late in the
   process is very costly.

Scott