Subject: [Dime] [Fwd: Re: Review of draft-ietf-dime-app-design-guide-01.txt]

From: Victor Fajardo <[email-masked]>
Date: Fri, 29 Jun 2007 14:14:36 -0400

Subject: RE: Review of draft-ietf-dime-app-design-guide-01.txt
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 29 Jun 2007 11:00:14 -0500

Mark,

Do you mind if we forward your comments to the DiME mailing list?
 
Comments in-line.

>-----Original Message-----
>From: ext Mark Jones [mailto:[email-masked]] 
>Sent: 29 June, 2007 07:55
>To: [email-masked]; [email-masked]; 
>Tschofenig Hannes (NSN DE/Muenchen); [email-masked]; 
>Loughney John (Nokia-NRC/PaloAlto)
>Subject: Review of draft-ietf-dime-app-design-guide-01.txt
>
>Victor, Tolga, Hannes, Glenn, John,
>
>I finally got around to reviewing this important draft and my 
>comments/ questions are below. Please note that I'm on 
>vacation next week so I'll respond to emails the week after (July 9th).
>
>Thanks for initiating this draft. I am optimistic that the 
>other SDOs will embrace it and review their future specs for 
>compliance. I will certainly be pushing for compliance in the 
>groups where I participate.
>
>Regards
>Mark
>
>---
>
>General comment: I found the structure a little confusing at times,
e.g.
>sections on extending applications contain guidance on new
applications.
>I would like to suggest the following re-org:
>
>1. Introduction
>
>2. Rules for Reuse
>2.1 Application Reuse
>	Adding Commands
>	Deleting Commands
>2.2 Command Reuse
>	Adding AVPs (mandatory vs optiona)
>	Deleting AVPs
>2.3 AVP Reuse
>	Adding values
>	Deleting values
>
>3. Rules on introducing new elements
>3.1 Rules for new applications
>	Justifying allocation of Application-Id
>	Use of Application-Id in a Message
>	Application Specific Session Statemachine
>3.2 Rules for new commands
>3.3 Rules for new AVPs
>
>4. Other design considerations
>4.1 Diameter Account Support
>4.2 Generic Diameter Extensions
>4.3 Updating an existing Application
>4.4 System Architecture and Deployment
>
>5. IANA Considerations
>6. Security Considerations
>7. Acknowledgements
>8. References

That seems reasonable, anyone else have thoughts? 		
>Comments on specific sections:
>
>Abstract
>--------
>
>Is the draft only going to focus on clarifying existing rules 
>in the Base rfc? I think we're adding some new rules too, e.g. 
>AVP/command deletion. Will these rules need to be propagated 
>to a 3588bis?

I would think so.

>1. Introduction
>---------------
>
>The draft provides guidance on the decisions to define new AVP 
>values, new AVPs and new commands. Not just new applications 
>as suggested in this section.

OK

>4. Rules on Diameter Extensibility
>----------------------------------
>
>I suggest rewording "Defining a new Diameter application can 
>be done by:" to "Mapping a new application to the Diameter 
>protocol can be done by:".

OK

>Extending an existing application
>---------------------------------
>
>Typo in first sentence. It should read "In this case, the 
>requirements of the new application are not completely unique 
>and there are existing applications ..."
>
>If I choose to reuse an existing application, do I have to 
>implement all commands even though they may not be used in the 
>new application? I would expect the answer to be yes otherwise 
>you've effectively deleted a command and so created a new 
>application. Correct?
>
>4.1 Rules on Extending Existing Applications
>--------------------------------------------
>
>To my understanding the rules for extending an application are fairly
>restrictive: Existing applications can only be extended by the 
>addition of non-mandatory AVPs to existing commands or adding 
>values to existing AVPs (providing they don't change the AVP 
>semantics). If correct, this rule should be stated somewhere 
>in this section.

OK.

>Adding an AVP to a command ABNF of an existing application
>----------------------------------------------------------
>
>I suggest explicitly stating the rule in the first paragraph: 
>a mandatory AVP can not be added to (or deleted from) an 
>existing command.
>
>
>I like the list of questions to help qualify whether an AVP is 
>mandatory but a summary statement would help: "If one or more 
>of the above conditions are true, the AVP is considered mandatory".
OK

>Adding a new AVP value to an existing AVP
>-----------------------------------------
>
>There are a couple of typos in the subsection title: should 
>start with "Adding" instead of "Add"; "to an" is repeated.
>
>Need to explicitly state what "rule applies" since it may not 
>be obvious to the reader: A new value can only be added to an 
>existing AVP if it does not change the semantics of the AVP. 
>	
>Add a command to an existing application
>----------------------------------------
>
>Again need to state what "rule applies" here: to my 
>understanding, a command can not be added to an existing 
>application regardless of whether it is a new command or 
>reused from another application.

OK

>---
>
>I also have suggestions for a couple of new sections. If you 
>agree they are useful, I could provide a first draft. 
>
>AVP datatype rules
>------------------
>
>If appropriate derived AVP data format exists, it SHOULD be 
>used instead of the base type, i.e. if you're transporting an 
>IP address, use the "Address" data type instead of some new 
>encoding as Octet String.
>
>Datatype use should be consistent across an application. Reuse 
>of derived AVP data formats defined in existing IETF 
>applications is encouraged.

That makes sense.

>
>Guidelines for SDOs
>-------------------
>
>I think we have three types of groups that extend Diameter:
>	. IETF
>	. Other SDOs
>	. Vendors
>
>From a protocol extensibility perspective the other SDOs are 
>treated as vendors. However, the SDOs do have interoperability 
>concerns that a single vendor does not. I think it would be 
>useful to offer them some general advice:
>
>	. Follow the IETF reuse guidelines for their own 
>applications, commands and AVPs.
>	. Determine the level of internal policing required for 
>assignments (First come, first served vs Expert Review). 
>Obviously these are over and above any IANA requirements.
>	. Consider assigning an internal expert body to review 
>SDO application, command, AVP and value use.
>	. If an internal expert body is not available, consider 
>publishing application as an IETF draft and requesting DIME WG review.

SDOs unfortunately, don't have a special status inside the IETF. I was
bugging
some people on the IESG about this at some point, but nothing happened.

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