Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requi res new A pplication-ID

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 10 Sep 2004 15:54:07 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 08, 2004 02:02
To: [email-masked]; [email-masked]
Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID

Javier,
 
Our AD has stated that we can make a simple erratta to RFC 3588 to make this change.  So at 
 
<bert> I think you meant "can NOT make" !!??
<bert>
 
present, this is not an option on that is on the table.  If we would like to change the RFC,
then we will need to produce a new RFC.
 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Javier Gonzalez Gallego
Sent: 07 September, 2004 14:53
To: [email-masked]
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID

Thomas, 
The actual text in RFC3588 seems to imply your conclusion, but it is not fully clear. However what seems to be clear to me is the agreement in the need to correct it. If we look to the mails arounf 19 of August, there's a number of opinions and  emails in agreement with Bernard Adoba's sentence asking for a correction:

> Included in the list of conditions requiring a new Application-ID is: 
> 
> "   -  Adding new AVPs to the command, which have the "M" bit set." 
> 
> Given the discussion since the publication of RFC 3588, I now believe 
> that the above sentence is in error.  A new Application-ID should not 
> be required due to addition of AVPs to an application, whether the 
> mandatory bit is set or not. 

When and how this correction will be done is what seems to be still open. 

At least, that is my recollection of the debate. 
Javier 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Belling Thomas 
Sent: 03 September 2004 13:01 
To: [email-masked]'; [email-masked]; [email-masked] 
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID 

Hi all 

There seems to be an understanding in the group that a new application ID is mandated if a new AVP mith ´M´Flag is added.

However, the text in RFC 3556 seems to indicate it is optional: " Should a new Diameter usage scenario find itself unable to fit within

   an existing application without requiring major changes to the 
   specification, it may be desirable to create a new Diameter 
   application.  Major changes to an application include: 

   -  Adding new AVPs to the command, which have the "M" bit set. " This seems to be in line with explanatory text for the ´M`bit, that also speaks about AVPs without ´M´bits outside applications: "

      The 'M' Bit, known as the Mandatory bit, indicates whether support 
      of the AVP is required.  If an AVP with the 'M' bit set is 
      received by a Diameter client, server, proxy, or translation agent 
      and either the AVP or its value is unrecognized, the message MUST 
      be rejected.  Diameter Relay and redirect agents MUST NOT reject 
      messages with unrecognized AVPs. 

      The 'M' bit MUST be set according to the rules defined for the AVP 
      containing it.  >>> In order to preserve interoperability, a Diameter 
      implementation MUST be able to exclude from a Diameter message any 
      Mandatory AVP which is neither defined in the base Diameter 
      protocol nor in any of the Diameter Application specifications 
      governing the message in which it appears. <<< ... 

      Diameter implementations are required to support all Mandatory 
      AVPs which are allowed by the message's formal syntax and defined 
      either in the base Diameter standard or in one of the Diameter 
      Application specifications governing the message. 
" 

If the understanding within the group is a new application ID for the AVPs with the ´M´bit is mandatory, (the below interoperability concerns may justify that), one could improve the wording. Is that something for the errata?

Or is it preferable to keep the wording as it is, and grant a certain degree of freedom fpr application designers in this difficult field?

Thomas 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
> On Behalf Of [email-masked] 
> Sent: Friday, September 03, 2004 11:31 AM 
> To: [email-masked]; [email-masked] 
> Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit 
> AVPs requires new A pplication-ID 
> 
> 
> Lionel, 
> 
> > > Right now, there is no standard way to do extended 
> > > negotiation.  If there were one, we could could use this to 
> > > negotiation sub-feature support.  However, as there is no 
> > > solution at present to do this.  Do you feel that this 
> > > feature is needed?  
> > > 
> > 
> > From my point of view, the problem of versioning has 
> appeared due to the 
> > "unclear" specification of the extensibility mechanism 
> (i.e. adding new 
> > AVP with the M-bit set). To avoid the need for a new 
> application-ID when 
> > a new feature is added to an existing Diameter application, 
> a solution 
> > was to define versions of the same application and to 
> specify a specific 
> > version negotiation at the application layer. But this solution was 
> > forced by the "new M-bit AVP -> new application-ID" dogma. 
> > 
> > If the base protocol specification clarifies that the 
> addition of new 
> > M-bit AVPs doesn't require a new application-ID and the 
> approriate error 
> > handling for unsupported AVPs (as proposed by Bernard), this will 
> > deprecate the use of version. 
> 
> According to our AD, adding new mandatory AVPs causes interoperability 
> problems, therefore the current text remains as is.  If we would like 
> to modify that behavior, we most likely need to document the new 
> functionality in an RFC. 
> 
> John 
>