Subject: [AAA-WG]: [issue] Issue #22: Enums

From: "Mark Jones" <[email-masked]>
Date: Wed, 30 May 2001 09:42:56 -0400

Submitter name: Mark Jones
Submitter email address: [email-masked]
Date first submitted: May, 2001
Reference: Issue #22 on http://www.diameter.org/issues.html
Document: Base
Comment type: T
Priority: 1 or 2 (?)
Section: 4.3
Rationale/Explanation of issue:

At the interim meeting, a proposal for the introduction of a new data type
(or subtype) of Enumerated met with a favorable response so I am posting
it to the list for comments. As with Mark Eklund's suggestion for UTF8,
guidance is sought from SMI gurus on the most appropriate way to introduce
Enums into the base protocol.

Enumerated types are defined in the NASREQ extension already and are
different from the currently defined types in how they are validated,
encoded and allocated.

An enumerated type defines an explicit list of unsigned 32-bit integer
values that an AVP may take. This allows a Diameter peer to validate and
reject commands containing an enumerated AVP with an invalid value
(Result-Code = DIAMETER_INVALID_AVP_VALUE).

When encoding enumerated types there is a translation step from a name to
a corresponding integer value (either in the server itself or the
provisioning application). Service provisioning applications make use of
the enumerated type definition to validate data entry or offer a drop-down
list of possible names/values.

Enumerated types are also treated differently when it comes to allocating
the values in order to avoid overlapping values being used by different
implementations, e.g. NASREQ/RADIUS enumerated types are controlled by
IANA (see http://www.iana.org/assignments/radius-types). A similar
approach is required for the values of enumerated types defined in the
Diameter extensions. The values of vendor-specific Enumerated AVPs would
be controlled by the vendor themselves and not by IANA.

Requested change:

Add a new subtype of Unsigned32 as follows:

      Unsigned32
         32 bit unsigned value, in network byte order. The AVP Length
         field MUST be set to 12 (16 if the 'V' bit is enabled).

         Enumerated
            32 bit unsigned value, in network byte order, where the
            list of valid values and their interpretation is described
            in the Diameter extension introducing the AVP. As with
            Unsigned32, the AVP Length field MUST be set to 12
            (16 if the 'V' bit is enabled).

Regards,
       Mark