Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30

From: David Spence <[email-masked]>
Date: Wed, 06 Jun 2001 02:59:32 +0200

I have a number of editorial comments which I am finally getting a around to
documenting.  See below.

Pat Calhoun wrote:
> 
> All,
> 
> Below is the new text for section 9, which attempts to address the issues
> mentioned above. I would appreciate some feedback from folks on whether the
> text is consistent with their understanding of the outcome of the Interim
> meeting.
> 
> Actual fixes:
> 
> Issue 13: DSI is removed, and a new answer only message is used to report
> protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events
> are moved to a new class within the Result-Code AVP.
> 
> Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST
> only be included if a host is changing the result-code AVP, and is not the
> one whose identity is in the Origin-FQDN.
> 
> Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP
> in it's group.
> 
> Thanks,
> 
> PatC
> ----
> 9.0  Error Handling
>... 
> 
> 9.1.3  Protocol Errors
>... 
> 
>       DIAMETER_TOO_BUSY                  3005
>          When returned, a Diameter node SHOULD attempt to sent the
                                                            ^^^^
                                                            send
>          message to an alternate peer.
>... 
> 
> 9.1.5  Permanent Failures
>... 
>
>       DIAMETER_MISSING_AVP               5006
>          The request did not contain an AVP that is required by the
> 
> Calhoun et al.            expires October 2001                 [Page 45]
> 
> Internet-Draft                                                  May 2001
> 
>          Command Code definition. If this value is sent in the Result-
>          Code AVP, a Failed-AVP AVP SHOULD be included in the message.
>          The data portion of the Failed-AVP MUST contain an AVP header
>          containing the AVP Code and vendor-Id.

Actually the Failed-AVP AVP MUST contain an example of the missing AVP
complete with the Vendor-Id if applicable.  The value field of the missing
AVP should be of correct minimum length and contain zeroes.

>... 
> 
>       DIAMETER_AVP_NOT_ALLOWED           5009
>          A message was received with an AVP that MUST NOT be present.
>          The Failed-AVP AVP MUST be included and contain the AVP Code of
>          the offending AVP.

The Failed-AVP AVP MUST be included and contain a copy of the offending AVP.

> 
>       DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010
>          A message was received that included an AVP that appeared more
>          often than permitted in the message definition. The Failed-AVP
>          AVP MUST be included and contain the AVP Code of the offending
>          AVP.

The Failed-AVP AVP MUST be included and contain a copy of the first instance
of the offending AVP that exceeded the maximum number of occurrences
allowed.

> 
>       DIAMETER_VENDOR_ID_UNSUPPORTED     5011
>          The Home Diameter server has detected vendor-specific AVPs in
>          the message, and the vendor dictionary is not supported. One or
>          more Failed-AVP MUST be present, containing the offending AVPs.

I thought this was only an error if the offending AVPs had the M bit set. 
Otherwise the receiving server should just ignore the offending AVPs.

>...
> 
> 9.4  Error-Reporting-Host AVP
> 
>    The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString,
>    encoded in the UTF-8 [24] format, according to the Diameter identity
>    rules defined in section 2.6.  This AVP contains the identity of the
>    Diameter host that set the Result-Code AVP to a value other than 2001
>    (Success), only if the host setting the Result-Code is different from
>    the one encoded in the Origin-Host AVP. This AVP is intended to be
>    used for troubleshooting purposes, and MUST be set when the Result-
                                                    ^^^
                                                    sent

>    Code AVP indicates a failure.
>... 

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 6 Jun 2001 06:49:33 -0700

> I have a number of editorial comments which I am finally getting a around to

Thanks for catching these errors. See below...

> Otherwise the receiving server should just ignore the offending AVPs.

hmmmm... I believe that you are correct, and this Result-Code is therefore 
no longer necessary.

PatC