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".