Last Call Review of draft-snell-http-prefer-
review-snell-http-prefer-secdir-lc-yu-2012-10-18-00

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 -15 version has substantial changes from the -14 version that I
began reviewing, but the changes appear to not affect my evaluation.
This document appears mostly ready for publication, but it could use a
few minor clarifications.

The Security Considerations (Section 6) states that implementers need
to refer to the specification of each preference to determine the
security considerations relevant to each, but the specifications of
the preferences defined in this document do not state any security
considerations.  The second paragraph of Section 6 describes server
resource consumption risks associated with honoring a client's
requested preferences.  These risks seem primarily applicable to the
preferences "return-asynch", "return-representation", and possibly
"wait".

Do the other preferences specified in this document lack such risks of
excessive server resource consumption?  It would be useful to
explicitly state whether they do.

Not security related:

In Section 2, the right hand side of the first line of the ABNF rule
for "preference" seems identical to that for "parameter".  Why does
"parameter" not appear in first line of the definition of
"preference"?  Is it solely to distinguish the semantics of the first
token (or key-value pair) in the semicolon-separated list?

Consider rewording "A preference token can contain a value." to "A
preference token can have an associated value.", because the value
("word") is not syntactically a part of the token.

"An optional set of parameters" should probably be reworded "An
optional set of named parameters".  This change would help clarify
that the optional word that follows the preference token is not a
parameter, but is an unnamed value associated with the parameter
token.

Is the prevailing practice to omit any spaces preceding the semicolon,
and to have a single space after the semicolon?  If so, it might be
useful to mention.  (I think there might be a similar issue with the
"#rule" in draft-ietf-httpbis-p1-messaging-21, but I haven't checked
that document extensively.)  Such practices appear consistent with the
examples in this document and with conventional English punctuation.

Editorial:

In the first paragraph of Section 6, "it's additional associated"
should be "its additional associated".