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 standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. In July 2011, I conducted a secdir review of a previous revision of this document (-04) and found that the Security Considerations section was inadequate because it did not include any analysis of the specific security issues related to priority systems. I'm pleased to say that the authors have attempted to address this issue in their new draft. They added a reference to the Security Considerations section of RFC 5866, which is thorough and sound. In addition, they explicitly identify one threat: unauthorized changes to QoS parameters in transit. However, the countermeasure proposed is confusing. The document now says "integrity protected values SHOULD be ignored". I would expect the reverse. Values that are not integrity protected SHOULD be ignored. Am I wrong? I'm concerned that the other threats described in RFC 5866 are not addressed in this document. Lack of authentication and confidentiality protection for QoS parameters can have serious negative impacts, as described in RFC 5866. In the IETF spirit of "send text", I suggest the following paragraph be added to the Security Considerations section of this draft: As described in [RFC5866], failure to provide adequate authentication and confidentiality protection for QoS parameters may result in serious failures that undermine the very purpose of QoS. Countermeasures such as Diameter communication security should be employed as appropriate. I will supply a further optional suggestion to clarify the text recently added regarding integrity. I recommend that the first paragraph of the Security Considerations section be stripped to just its first sentence and that the following paragraph be used in place of the new text that was added at the end of that paragraph: The values in the AVPs defined in this draft are not supposed to be changed by any of the Diameter servers or any other intermediaries. In fact, changes to these AVPs in transit could result in serious problems such as inability to complete high-priority emergency phone calls. Therefore, source integrity protection SHOULD be employed for those AVPs (e.g., the use of S/MIME with the SIP RPH, or an INTEGRITY object within a POLICY_DATA object). The text that I wrote may well be incorrect or misguided. I'm just trying to provide helpful suggestions from a security perspective. If the authors would like to have a further chat about this topic, I'd be glad to do so. And if they want to keep the text that they added on integrity protection, that's OK. I just found it a bit lacking in describing the threat and its consequences and in providing an effective countermeasure. Thanks, Steve