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

From: <[email-masked]>
Date: Tue, 16 Jun 2009 19:46:08 +0200

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

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 17 Jun 2009 17:45:20 +0900

Hello,

I'd just have a very small editorial comment. By the end of page 4:

   WG [I-D.ietf-dime-rfc3588bis]. and when approved will obsolete RFC
                               ^^^

I think the dot after the reference should be removed.

Since the content is redundant with rfc3588bis section 11.2.1, I am
wondering if modifying that draft (3588bis) to reference this one when
it becomes an RFC (hopefully before the 3588bis) would not result in
less work for everyone ? Just an idea...

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Jun 2009 17:41:21 +0800

Hi:
May I have a quick comment for draft-dime-diameter-cmd-iana.
In the introduction of this draft, it points out a serious design issue that other SDO choose to define new applications on
existing commands rather than asking for assignment of new command codes. I totally agree with it.
 I wonder how this problem is really resolved in this draft?
Does it mean that the other SDO uses vendor specific command code namespace to assign new command codes if they want to
avoid IETF review? Why not strenghen interoperability between different SDO to get around this problem?
Also I wonder whether there is the similar bad design issue in the IETF relevant work?

Regards!
-Qin