[Dime] Quick review of draft-ietf-dime-diameter-cmd-iana-00.txt

[<john.loughney at nokia.com>]

Dear Dime-ers,

Here is a quick review of draft-ietf-dime-diameter-cmd-iana-00.txt

http://www.ietf.org/mail-archive/web/dime/current/msg03534.html


Basically, this seems like a reasonable approach to me.  Some specific 
comments:

The introduction says:

   The Diameter Base specification, described in RFC 3588, provides a
   number of ways to extend Diameter, with new Diameter commands, i.e.
   messages used by Diameter applications, and applications as the most
   extensive enhancements.

I am confused by the wording "extensive enhancements" - do you mean " ...common 
ways to extend the protocol"?  If so, then it make sense.

More substantive:

IANA considerations say:

   The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved
   for vendor-specific command codes, to be allocated on a First Come,
   First Served basis by IANA [RFC5226].  The request to IANA for a
   Vendor-Specific Command Code SHOULD include a reference to a publicly
   available specification which documents the command in sufficient
   detail to aid in interoperability between independent
   implementations.  If the specification cannot be made publicly
   available, the request for a vendor-specific command code MUST
   include the contact information of persons and/or entities
   responsible for authoring and maintaining the command.

My biggest worry is that we get a lot of fragmentation in the command code space,
like we have seen with RADIUS, and we just end up making Diameter = 2xRADIUS ...
I don't have a great solution, other than labeling this area as 'EXPERIMENTAL'
code space and if someone wants to upgrade it to a standard, then they should
have a lightweight publication mechanism via the IETF. 

Then again, perhaps the WG has gone through this and understands all of the trade-offs
and implications of this, therefore my worries are no warranted.  If it is so, then I am
fine with this approach.

John