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

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Fri, 19 Apr 2002 12:15:07 +0200

Hi,

The proposed solution is fine with me. My opinion is that we should have only one result code in a message.

I leave for your consideration whether we should change in 7.1 "All Diameter answer messages MUST include
one Result-Code AVP" to "All Diameter answer messages MUST include either one Result-Code AVP or one Vendor-Specific-Result-Code AVP." I think this would be useful.

Proposal of addition of a new subchapter inside chapter 7 (7.2 ?).

7.x Vendor-Specific-Result-Code AVP

The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type Unsigned32 and
indicates whether a particular vendor-specific request was completed successfully or
whether an error occurred. All Diameter vendor-specific answer messages MUST include
either one Vendor-Specific-Result-Code AVP or one Result-Code AVP. 

It is recommended that vendor-specific result codes follow the same conventions
given for the Result-Code AVP regarding the different types of result codes and
the handling of errors (for non 2xxx values).

In chapter 4.6:

After:
...
Vendor-Specific- 260 6.10 Grouped | M | P |   | V | N |
   Application-Id                 |   |   |   |   |   |

Add:

Vendor-Specific- TBD 7.x Unsigned32 | M | P |   | V | N |
   Result-Code                      |   |   |   |   |   |

Best regards,
Miguel

> -----Original Message-----
> From: Sami Vaarala [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 4:43 AM
> To: Mark Jones; [email-masked]
> Subject: RE: [AAA-WG]: Result codes in vendor specific applications
> 
> 
> Mark,
> 
> Would we then have a Result-Code that indicates a vendor-specific
> success/error code, which is then contained in the
> Vendor-Specific-Result-Code AVP?
> 
> Does the receiver benefit from partial understanding ("it is an
> error, but it is vendor specific") provided by the Result-Code?
> 
> Or would we simply have either Result-Code or
> Vendor-Specific-Result-Code?
> 
> -Sami
> 
> -----Original Message-----
> From: Mark Jones [mailto:[email-masked]] 
> Sent: 18 April 2002 17:05
> To: [email-masked]
> Subject: RE: [AAA-WG]: Result codes in vendor specific applications
> 
> 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: "Mark Jones" <[email-masked]>
Date: Fri, 19 Apr 2002 12:11:02 -0400

Miguel,

To avoid result code collisions between vendors, I think the new AVP needs
to include the Vendor-Id.

Vendor-Specific-Result ::==  < AVP Header: tbd >
                             { Vendor-Id }
                             { Vendor-Specific-Result-Code }

where:
	Vendor-Id: Datatype: Unsigned32; AVP code: 266
	Vendor-Specific-Result-Code: Datatype: Unsigned32; AVP code: <tbd>

Alternatively, IANA gets another AVP to police but this doesn't seem the
right approach for an AVP that is only used in vendor-specific applications.

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 22 Apr 2002 16:44:37 -0400

As I stated earlier, my preference is for a single result code per message.
If this is acceptable to the WG then building on Miguel-Angel's earlier text
submission, the following changes are required to the Base protocol draft:

---

Modify section 7.1, replacing: "All Diameter answer messages MUST include
one Result-Code AVP" with "All Diameter answer messages defined in IETF
applications MUST include one Result-Code AVP."

---

Add two new sub-sections to section 7:

7.x Vendor-Specific-Result AVP

The Vendor-Specific-Result AVP (AVP Code tbd) is of type Grouped, and
indicates whether a particular vendor-specific request was completed
successfully or whether an error occurred. Its Data field has the following
ABNF grammar:

      Vendor-Specific-Result ::= < AVP Header: tbd >
                                 { Vendor-Id }
                                 { Vendor-Specific-Result-Code }

The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies the
vendor responsible for the assignment of the result code which follows. All
Diameter answer messages defined in vendor-specific applications MUST
include either one Result-Code AVP or one Vendor-Specific-Result-Code AVP.

7.y Vendor-Specific-Result-Code AVP

The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type Unsigned32 and
contains a vendor-assigned value representing the result of processing the
request.

It is recommended that vendor-specific result codes follow the same
conventions given for the Result-Code AVP regarding the different types of
result codes and the handling of errors (for non 2xxx values).

---

In chapter 4.6:

After:
...

Add:

Vendor-Specific- TBD 7.x Grouped    | M | P |   | V | N |
   Result                           |   |   |   |   |   |
Vendor-Specific- TBD 7.y Unsigned32 | M | P |   | V | N |
   Result-Code                      |   |   |   |   |   |

Regards,
       Mark