Skip to main content

Last Call Review of draft-ietf-dime-diameter-cmd-iana-

Request Review of draft-ietf-dime-diameter-cmd-iana
Requested revision No specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-25
Requested 2009-09-10
Authors Dan Romascanu , Hannes Tschofenig
I-D last updated 2009-09-18
Completed reviews Secdir Last Call review of -?? by Carl Wallace
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-dime-diameter-cmd-iana-secdir-lc-wallace-2009-09-18
Completed 2009-09-18
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
- 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
- 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).