Last Call Review of draft-ietf-ppsp-problem-statement-

Request Review of draft-ietf-ppsp-problem-statement
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-12-13
Requested 2011-11-24
Authors Yunfei Zhang, Ning Zong
Draft last updated 2011-12-21
Completed reviews Genart Last Call review of -?? by Francis Dupont
Genart Last Call review of -?? by Francis Dupont
Genart Telechat review of -11 by Francis Dupont (diff)
Secdir Last Call review of -?? by Russ Mundy
Assignment Reviewer Russ Mundy 
State Completed
Review review-ietf-ppsp-problem-statement-secdir-lc-mundy-2011-12-21
Review completed: 2011-12-21


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The document has more of a "marketing" tone to it than most IETF documents and, as such, seems more like a "why do we need to do this ppsp protocol" (or protocol suite?) than a problem statement.  On the other hand, if the working group believes that publishing this information will help with reaching their goals or providing context to potential future implementers of actual protocol specifications, I don't see any reason not to publish it - as long as it remains Informational.

With respect to the security considerations section, the information seems to be good particularly since the document itself covers a wide range of potential protocol specifications.  Requiring subsequent specifications to address specific threats and mitigations is good but it would also be good for these specifications to document specific security requirements for the protocols as well as the threats.  Additionally, specifically excluding support for a particular requirement (Digital Rights Management (DRM)) does not seem to make sense in this document since it claims to be a problem statement - this sounds much more like the statement of a non-requirement than a security consideration and should be in some requirements document or the requirements section of protocol specifications.

Russ Mundy