Skip to main content

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

Request Review of draft-ietf-precis-problem-statement
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-23
Requested 2012-10-11
Authors Marc Blanchet , Andrew Sullivan
I-D last updated 2012-10-25
Completed reviews Genart Last Call review of -?? by Vijay K. Gurbani
Secdir Last Call review of -?? by Scott G. Kelly
Assignment Reviewer Scott G. Kelly
State Completed
Review review-ietf-precis-problem-statement-secdir-lc-kelly-2012-10-25
Result Has Issues
Completed 2012-10-25
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.

This is a problem statement document that describes issues and considerations
for development of a replacement for Stringprep (RFC3454). It is intended for
publication as an Informational RFC.

Here is the entirety of the Security Considerations section:

   This document merely states what problems are to be solved, and does
   not define a protocol.  There are undoubtedly security implications
   of the particular results that will come from the work to be

When I first saw this, I thought it seemed reasonable. Then I went to the RFC
editor page and searched for "problem statement". I looked at the first 4 in
the list (6707, 6646, 6606, and 6567), and they each have considerably more in
the security considerations section. They talk about the security-related
problems to be solved without recommending specific solutions (which seems
appropriate for a problem statement). They stay at a high level, but they do
discuss security issues to be addressed, and if these documents were reviewed
by this group prior to publication, they presumably do so completely.

This document should probably do the same.