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

From: "Mark Jones" <[email-masked]>
Date: Fri, 29 Jun 2007 14:10:11 -0400

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
		
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?

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.

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:".

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.

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".

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.

---

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.

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.

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

---

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

Hi Mark,

> 6. Security Considerations

Sounds good.

> deletion. Will these rules need to be propagated to a 3588bis?

Yes some of the new rules have been propagated to bis-04.

> 1. Introduction

Ok.

> 4. Rules on Diameter Extensibility

Ok.

> Extending an existing application

Ok.

> command and so created a new application. Correct?

Good question. In general, yes I think this is true. Others may have 
additional comments.

> 4.1 Rules on Extending Existing Applications

Ok.

> Adding an AVP to a command ABNF of an existing application

Ok.

> conditions are true, the AVP is considered mandatory".

Ok.

> Adding a new AVP value to an existing AVP 

Ok.

> Add a command to an existing application

Ok.

> are useful, I could provide a first draft. 

This is useful. We can integrate your draft when ready.

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 29 Jun 2007 15:11:56 -0400

Hi Victor/Mark,

> Good question. In general, yes I think this is true. Others may have
[TOLGA]I think this is true for AVPs with M-bit set. I guess one of the
reasons for confusions about Diameter extensibility is that people are
focusing to message definitions only syntactically rather than
semantically as well. If a node advertises an Application-Id, this means
that it is not only ready to parse the message somehow, but also that it
is ready to execute all the associated mandatory semantics. This means
that it should know how to process the AVPs with M-bit set.