ABSTRACT:
>    The Diameter Base specification, described in RFC 3588, provides a
>    number of ways to extend Diameter, with new Diameter commands, i.e.
...
>    This document aligns the extensibility rules of Diameter application
>    with the Diameter commands offering ways to delegate work on Diameter
>    to other SDOs to extend Diameter in a way that does not lead to poor
>    design choices.

  The first paragraph is unusual for an abstract (and it's repeated in
  the introduction), and the second paragraph needs to say that this
  updates RFC3588.


Section 4., paragraph 1:
>    This section describes changes to the IANA consideration sections
>    outlined in RFC 3588 regarding the allocation of Command Codes by
>    IANA.

  And I'm guessing you want to instruct IANA to start applying these as
  soon as this document is approved?

Currently, Section 3 seems to say that IETF produces better quality
specifications than other organizations, and others are more likely to
screw up security. I find this a bit negative and arrogant -- when
defining a new Diameter application for a system developed in some
other organization FOO, I think it's much more likely that FOO 
understands their system, and its security requirements, better than
IETF does.

  In the Gen-ART Review by Scott Brim on 2009-09-21:

  Not a big issue but: if you do revise it, consider putting in a
  little more about the motivation.  Without naming names, what were
  the "questionable design decisions" and why were they an issue?

Like Pasi, I would favor rewording the Security Considerations section.

Carl Wallace had some editorial suggestions in his secdir review:

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