Updated IANA Considerations for Diameter Command Code Allocations
RFC 5719
Note: This ballot was opened for revision 01 and is now closed.
(Ron Bonica) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Ralph Droms) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
Comment (2009-10-07)
No email
send info
send info
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?
(Pasi Eronen) No Objection
Comment (2009-10-05)
No email
send info
send info
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.
(Adrian Farrel) (was Abstain) No Objection
(Russ Housley) No Objection
Comment (2009-10-06)
No email
send info
send info
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?
(Cullen Jennings) No Objection
(Alexey Melnikov) No Objection
(Tim Polk) No Objection
Comment (2009-10-06)
No email
send info
send info
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."