Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP

From: "STURA Marco Consultant" <[email-masked]>
Date: Thu, 11 Nov 2004 09:52:37 +0100

Lionel,

I think the conclusion was "yes it is possible", and indeed it is.

If a server receives an AVP with M bit set that cannot recognize,
although the AVP is optional in the ABNF (i.e. in square brackets), the
Failed-AVP AVP is included in the failed answer.

Similarly, if the value of the AVP (which has the M bit set) is not
recognized the failed answer includes the Failed-AVP AVP.

Br
Marco
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of MORAND Lionel RD-CORE-ISS
Sent: Wednesday, November 10, 2004 5:45 PM
To: [email-masked]
Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP

Any other thought on this thread?
The initial question was:

"Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP
result code along with the Failed-AVP AVP to indicate that an optional
AVP (from the ABNF point of view) is missing in the received command? If
not, could you identify some operational issues?"

BR,

Lionel

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Nov 2004 04:36:21 -0800 (PST)

RFC 3588 Section 7 says:

"   - A command is received with an AVP that is omitted, yet is
      mandatory according to the command's ABNF.  The receiver issues an
      answer with the Result-Code set to DIAMETER_MISSING_AVP, and
      creates an AVP with the AVP Code and other fields set as expected
      in the missing AVP.  The created AVP is then added to the Failed-
      AVP AVP."

In Section 7.11 it says:

   "A non-successful Result-Code AVP (one containing a non 2xxx value
   other than DIAMETER_REDIRECT_INDICATION) MUST include the
   Error-Reporting-Host AVP if the host setting the Result-Code AVP is
   different from the identity encoded in the Origin-Host AVP.

   The Result-Code data field contains an IANA-managed 32-bit address
   space representing errors (see Section 11.4).  Diameter provides the
   following classes of errors, all identified by the thousands digit in
   the decimal notation:

      -  1xxx (Informational)
      -  2xxx (Success)
      -  3xxx (Protocol Errors)
      -  4xxx (Transient Failures)
      -  5xxx (Permanent Failure)"

DIAMETER_MISSING_AVP uses Result-Code value 5005, which is the Permanent
Failure category, a terminal error.  Section 7.1.5 says:

"     Errors that fall within the permanent failures category are used
      to inform the peer that the request failed, and should not be
      attempted again."

Given the above, it would appear to me that the DIAMETER_MISSING_AVP
Result_Code cannot be returned in response to lack of inclusion of an AVP
without the Mandatory bit set.

Having said that, it is possible that some other AVP that *is* mandatory
may take on a value that implies the need for another optional AVP,
which is missing.  That would be a terminal error, but a Result_Code
other than DIAMETER_MISSING_AVP should be used to indicate that.