Skip to main content

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)

Recuse

(Dan Romascanu)

Note: This ballot was opened for revision 01 and is now closed.

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

                            
Lars Eggert Former IESG member
No Objection
No Objection (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?
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