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

From: <[email-masked]>
Date: Wed, 8 Sep 2004 03:01:40 +0300

Javier,
 
Our AD has stated that we can make a simple erratta to RFC 3588 to make this change.  So at
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]] 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]] 
> 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 
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Sep 2004 17:11:38 -0700 (PDT)

> If we would like to change the RFC, then we will need to produce a new
> RFC.

Producing an RFC is not by itself an obstacle, assuming:

a. We have consensus that there is a problem with the current text of RFC
   3588.  That is, that there are situations in which it will be
   desirable to add support for *IETF Standard* AVPs with the 'M' bit set,
   without having to create a new *IETF Standard* Application-ID.  This
   argument in turn rests on the need to add support for small numbers
   of additional IETF Standard AVPs, rather than aggregating support for
   a set of AVPs into a new Application.  As Barney Wolff argued, there
   may be good reasons for aggregation, aside from the RFC 3588 issues.
   For example, there is a question about whether it even makes sense
   to support additional attributes in RADIUS in granularities smaller
   than a "feature".

b. We have consensus that addition of *Vendor Specific* AVPs with the
   'M' bit set still requires a new Application-ID.  Here again the
   issues arises as to whether support for multiple VSAs should require
   allocation of multiple Vendor-Specific Application-IDs, or just
   one.

c. We have consensus that other changes described in RFC 3588 (such as new
   command codes, changes in the round trips, etc.) still require a new
   Application-ID.

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 08 Sep 2004 09:54:28 +0300

I just want to point out that, if the WG decides to update RFC 3588, it 
may be a good idea to import the text of the AAA URI draft:

http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt

The motivation: this draft proposes an update to the AAA URI scheme. 
This text should have been in RFC 3588.

Regards,

        Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Sep 2004 08:40:03 -0700 (PDT)

> may be a good idea to import the text of the AAA URI draft:

To my knowledge, there has been no discussion about issuing an RFC 3588bis
document so far.