Updated IANA Considerations for Diameter Command Code Allocations
draft-ietf-dime-diameter-cmd-iana-01
Yes
(Ron Bonica)
No Objection
(Adrian Farrel)
(Alexey Melnikov)
(Cullen Jennings)
(Jari Arkko)
(Lisa Dusseault)
(Ralph Droms)
(Robert Sparks)
(Ross Callon)
(Tim Polk)
Recuse
(Dan Romascanu)
Note: This ballot was opened for revision 01 and is now closed.
Lars Eggert
No Objection
Comment
(2009-10-07)
Unknown
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?
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Abstain)
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
(2009-10-05)
Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2009-10-06)
Unknown
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?
Tim Polk Former IESG member
No Objection
No Objection
(2009-10-06)
Unknown
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."
Dan Romascanu Former IESG member
Recuse
Recuse
()
Unknown