Subject: [Dime] Comments on section 1.2 of draft-ietf-dime-rfc3588bis-05

From: "Mark Jones" <[email-masked]>
Date: Sun, 12 Aug 2007 10:34:55 -0400

Please find below my comments on the extensibility section in 3588bis:

* Section 1.2: Bulleted list is missing "Creating new commands".

* Section 1.2: Suggested rewording of last paragraph and removing
command code comments (new section proposed below for commands):

   Reuse of existing AVP values, AVPs, commands and Diameter
   applications are strongly recommended. Reuse simplifies 
   standardization and implementation and avoids potential 
   interoperability issues.  

* Section 1.2.1:  Second paragraph is incorrect for vendor-specific AVP
values. Suggest rewording to:

   In order to allocate a new value for a standards track AVP, a request
   MUST be sent to IANA [RFC2434], along with an explanation of the 
   new AVP value.  IANA considerations for AVP values are discussed in
   Section 11.4.

* Section 1.2.2: Suggest rewording the first paragraph to include a
recommendation on derived data type usage: 

   When no existing AVP can be reused, a new AVP MUST be created.  
   The new AVP MUST be defined using one of the data types listed in
   Section 4.2 or 4.3. If an appropriate derived data type is already
   defined, it SHOULD be used instead of the base data type.

I considered tightening this last sentence to a MUST but realized
RADIUS/Diameter Translation Nodes could not be compliant. The Design
Guidelines draft should probably explain this exception to the rule.

* Section 1.2.2: Suggest rewording the second paragraph to use a
requirement key word:

   In the event that a logical grouping of AVPs is necessary, and
   multiple "groups" are possible in a given command, a Grouped AVP 
   SHOULD be used (see Section 4.4).

* Section 1.2.2: Second paragraph is incorrect for vendor-specific AVPs.
Suggest rewording to:

   In order to create a new standards track AVP, a request MUST be sent 
   to IANA with a reference to the specification that defines the AVP.  
   IANA considerations for AVPs are discussed in Section 11.1.1.

* Section 1.2.2: I suggest removing the sentence requiring that the IANA
request include the commands that make use of the AVP. For me, this
implies that the IANA AVP entry must be updated every time an AVP is
reused.

* Section 1.2.x: Add new section on the creation of new commands:

1.2.x Creating new Commands

   A new command should only be created when no suitable command can 
   be reused from an existing application.  In order to create a new
command, 
   a request MUST be sent to IANA. The IANA considerations for commands 
   are discussed in Section 11.2.1.

Regards
Mark

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 13 Aug 2007 08:10:12 -0400

Hi Mark,

Thanks for the comments.

> * Section 1.2: Bulleted list is missing "Creating new commands".

Ok.

>    standardization and implementation and avoids potential 

Ok.

>    new AVP value.  IANA considerations for AVP values are discussed in

Sure.

>    defined, it SHOULD be used instead of the base data type.

Ok.

>    IANA considerations for AVPs are discussed in Section 11.1.1.

Ok.

>    are discussed in Section 11.2.1.

Sure. Though this maybe to terse. We can re-hash a little bit.

regards,
victor