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 document relaxes the requirements in the IANA considerations section of RFC 3588 to allow a chunk of the possible command code space to be vendor specific instead of requiring IETF review of all possible command codes. The security considerations section is probably fine as-is but might benefit from addition of some discussion regarding consequences of reusing command codes (interoperability problems are mentioned in the introduction). A few nits are below. - The first sentence of the abstract (and introduction) is difficult to parse. - In the Introduction, change "the conditions, which" to "the conditions that" and change "were causes" to "were caused". - The document states that it "aligns the extensibility rules for Diameter command codes with those defined for Diameter application identifiers". Since the values are not aligned and there's no mention of "extensibility rules" elsewhere in this document nor in 3588, I suggest something like: "This document changes the allocation rules for Diameter command codes to support usage of vendor specific command codes, similar to the allocation of vendor specific application identifiers." - It might be worth noting that this draft updates RFC 3588 independent of its pending successor (or maybe this draft should be informational if it is really only providing a preview of 3588bis).