Subject: RE: [AAA-WG]: Result codes in vendor specific applications

From: "Sami Vaarala" <[email-masked]>
Date: Thu, 18 Apr 2002 16:03:09 +0300

Hi,

The 'V'-flag in the AVP indicates that the AVP *code* is vendor
specific -- not the value.  The change suggested introduces
essentially a private AVP that happens to have the same AVP code
as the IANA-assigned Result-Code.

Alternative changes:
   1. Add a vendor-specific flag (and vendor ID) into the Result-Code
AVP.

   2. Add a value for each result category indicating vendor specific
      extra information.  I.e., a generic "protocol error" with
      vendor specific additional information available.

Even though a Diameter node has a single vendor ID itself, it is free
to use vendor specific stuff of other vendors.  Thus, the result code
should be accompanied with the vendor ID that specified the code.

-Sami

-----Original Message-----
From: Miguel-Angel Pallares-Lopez (ECE)
[mailto:[email-masked]] 
Sent: 17 April 2002 17:21
To: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: Result codes in vendor specific applications

Issue:          Result codes in vendor specific applications
Submitter name: Miguel-Angel Pallares
Submitter email address: [email-masked]
Date first submitted: 17-04-2002
Reference:
Document:       draft-base-10
Comment type:   Technical
Priority:       H
Section:        4.6, 7.1

Reason for change: currently there is a lack of definition about whether
a vendor specific application can define its own Result-Codes. New
commands defined by a vendor may have an associated semantic that is not
covered by the existing result codes.

Proposed change:

In section 4.6:
"...
Result-Code      268  7.1     Unsigned32 | M  |  P  |    |  V  | N  |
..."
changes to
"...
Result-Code      268  7.1     Unsigned32 | M  |  P  |    |     | N  |
..."

In section 7.1:
After the paragraph that begins with:

"The Result-Code data field contains an IANA-managed..."

A new paragraph would read:

"Any vendor wishing to implement a vendor-specific Diameter command
specific commands MAY use privately managed result codes. If the
Result-Code AVP sent in the response to a vendor-specific command
contains a vendor-specific result code the 'V' bit MUST be set and the
Vendor-Id as described in 4.2 MUST be present".

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 3:27 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Result codes in vendor specific applications
> 
> 
> Hi Miguel,
> 
> 
> > I haven't found any statement in the base regarding the 
> > management of Result-Codes in vendor specific applications. I 
> > assume that a vendor specific application can assign its own 
> > result codes. Is my understanding correct? 
> > 
> > If so and if there is consensus in the list I am happy to 
> > provide the (small) required changes.
> 
> Please file an issue & suggest text.  This is the best way
> to get concensus.
> 
> Thanks,
> John
>

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 18 Apr 2002 10:04:31 -0400

I agree with Sami that flipping the 'V' bit in the AVP header to get a
vendor-specific result code is inappropriate since it blocks any vendor from
defining an AVP with code 268. This may be a problem for vendors who have
already used this code in their RADIUS vendor-specifc AVPs.

I would prefer to find the vendor-specific result codes in one AVP
regardless of vendor rather than have to hunt for the message result based
on vendor/application. However, I'd rather we introduce a new
Vendor-Specific-Result-Code AVP instead of changing the existing Result-Code
AVP to be a grouped AVP.

Regards,
       Mark

---

From: David Frascone <[email-masked]>
Date: Thu, 18 Apr 2002 09:04:45 -0500

I agree completely.

-- 
David Frascone

      Insert inevitable trivial witticism of your choice.