Subject: RE: RE : [AAA-WG]: Application support in Diameter

From: <[email-masked]>
Date: Tue, 4 May 2004 13:42:15 +0300

Hi Lionel,

> If a given application is defined with a specific mandatory 
> AVP, let us called it "Application-Version AVP", defining the 
> set of mandatory AVPs that must be supported (used with the 
> M-bit set), it could be possible to define a new  set of 
> mandatory AVPs and remain compliant with the Diameter base protocol.
> 
> *	The CER/CEA exhange would be used as defined in RFC 
> 3588, to advertize supported applications.
> *	The "Application-Version AVP" would be used along with 
> the application-ID in every request sent by a 	
> Diameter peer (except CER/CEA).
> *	The receiver would check the couple (Application-ID + 
> Application-Version) before any other action.
> *	The Application-Version AVP defines the set of AVPs 
> that have to be supported. If the receiver does not 
> support this version, this would occur an error message. This 
> error message may inform the originator of the request about 
> the supported Application-Version.
> 
> It would be therefore possible to add new mandatory AVPs 
> without creating a new application ID. The only restriction 
> is to remain unmodified the command code ABNF definition. If 
> a new AVP is added to the ABNF or a new command is needed, a 
> new application ID would have to be assigned. In this 
> context, CER/CEA exchange is then only used to be sure that 
> the Diameter peers will exchange supported commands (and not 
> mandatory 
> 
> Could it be a generic way to solve this problem application 
> versioning?

This is more-or-less what I was thinking. However, some care
probably should be taken in designing this.  I think unlimited
extensions could casuse some trouble, the application would
need to specify what parts could be update by new AVPs, etc.

John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 14:55:14 +0300

Hi Lionel,

> Maybe I should clarify that the set of mandatory AVPs defined 
> by the Application-Version "N+1" is equal to the set for 
> application-Version "N" + new mandatory AVPs. Therefore, to 
> insure interoperability and backward compatibility, it is 
> needed to update the reference document for the given 
> application with the set of new AVPs.
> One new Application-version will correspond to one new 
> version of the reference document and would support all the 
> previous versions. If it is not possible (or not wanted 
> anymore) to fulfill this requirement, a new application ID 
> will be also assigned in this case.

What is the difference between application and application version?
If you have an application called Foo_v1, then you make modifications
so now you have Foo_v2, what problems would this cause?  Your server
could advertise support for Foo_v1 and Foo_v2.  If my client supports
only Foo_v1, then we could negotiated that with the CEA/CER messages.
Is there a reason why this mechanism is not sufficient and
something more complicated needs to be invented?

John

---

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Tue, 4 May 2004 14:34:48 +0200

Hi John,

From my point of view, it is just an administrative problem.

With the current mechanism, a new AVP implies a new application-ID, and then a request to IANA for allocation number.
From my point of view, the procedure is too heavy if you are just considering addition of mandatory AVPs without modification of the command ABNF description already specified.

With the Application-Version AVP, it would not be necessary to wait for IANA number allocation to upgrade the application. The aim is to provide the maximum of flexibility at the application level but to remain compliant with the RFC 3588 defining the base protocol.

BTW, I'm not sure that it would be so complicated to implement and to manage.

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de [email-masked]
> Envoyé : mardi 4 mai 2004 13:55
> À : MORAND Lionel FTRD/DAC/ISS; [email-masked]; 
> [email-masked]
> Objet : RE: RE : RE : [AAA-WG]: Application support in Diameter
> 
> 
> Hi Lionel,
> 
> What is the difference between application and application 
> version? If you have an application called Foo_v1, then you 
> make modifications so now you have Foo_v2, what problems 
> would this cause?  Your server could advertise support for 
> Foo_v1 and Foo_v2.  If my client supports only Foo_v1, then 
> we could negotiated that with the CEA/CER messages. Is there 
> a reason why this mechanism is not sufficient and something 
> more complicated needs to be invented?
> 
> John
>

---

From: <[email-masked]>
Date: Tue, 4 May 2004 15:38:06 +0300

Hi Lionel,

> With the current mechanism, a new AVP implies a new 
> application-ID, and then a request to IANA for allocation number.
> From my point of view, the procedure is too heavy if you are 
> just considering addition of mandatory AVPs without 
> modification of the command ABNF description already specified.
> 
> With the Application-Version AVP, it would not be necessary 
> to wait for IANA number allocation to upgrade the 
> application. The aim is to provide the maximum of flexibility 
> at the application level but to remain compliant with the RFC 
> 3588 defining the base protocol.

You need to request AVP values from IANA as well, so I am not sure
this is anyhow different.  My main point is, the mechansims
for negotiation with Application IDs are defined already.  The
mechanism you are proposing isn't documented completely in 3588,
so that may be problematic.

John

---

From: Avi Lior <[email-masked]>
Date: Fri, 7 May 2004 14:46:17 -0400

Been reading these threads and I have a thought:

It maybe a good idea if we had a document to guide future Application
Writers on how to extend Diameter.

Using RADIUS as a historical example, I suggest that it would be better to
have this text sooner rather than later.

Thoughts?

Avi