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

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Tue, 16 Apr 2002 09:17:43 +0200

Hi,

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.

Best regards,
Miguel

---

From: <[email-masked]>
Date: Wed, 17 Apr 2002 10:27:19 +0300

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? 
> 

Please file an issue & suggest text.  This is the best way
to get concensus.

Thanks,
John

---

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Wed, 17 Apr 2002 16:21:25 +0200

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,
> 
>

---

From: <[email-masked]>
Date: Fri, 19 Apr 2002 07:18:53 +0300

Hi Mark,

> 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.

That sounds reasonable - anyone want to provide text?

John

---

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Mon, 22 Apr 2002 07:43:17 +0200

Mark,

I totally agree with your proposal, we need the Vendor-Id inside.

Regards,
Miguel

> From: Mark Jones [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 12:11 PM
> 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: "Sami Vaarala" <[email-masked]>
Date: Mon, 22 Apr 2002 11:22:28 +0300

Mark,

>...
> If we decide the Result-Code AVP is required in addition to the
> Vendor-Specific-Result-Code, it also leaves developers with the
question
> "Which generic Result-Code is most appropriate for my vendor-specifc
> problem?". This mapping may not always be obvious and so it will
probably
> not be done consistently (especially across different vendors).

For each error category, add an error code that indicates a
vendor-specific
error of that category.  But this point is moot if we don't send both a
generic and a vendor specific result code.

-Sami

---

From: <[email-masked]>
Date: Mon, 22 Apr 2002 16:15:27 +0300

Sami & Mark,

Could you document the text that should be added for this
issue, otherwise I don't think that this can be added.

John

> From: ext Sami Vaarala [mailto:[email-masked]]
> Sent: 22 April, 2002 11:22
> To: Mark Jones; [email-masked]

---

From: <[email-masked]>
Date: Wed, 24 Apr 2002 13:35:14 +0300

Hi all,

I think that this can be accomadated - does anyone have misgivings
about this?

John

> From: ext Mark Jones [mailto:[email-masked]]
> Sent: 22 April, 2002 23:45
> To: [email-masked]
> 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 }
> 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:
> ...
> Vendor-Specific- 260 6.10 Grouped | M | P |   | V | N |
>    Application-Id                 |   |   |   |   |   |
> 
> 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
> 
>