[Dime] Diameter Guidelines: additional info on alternative to the use of Enumerated

[<[e-mail]>]

Hi,

A late comment made me realize that one guideline was missing in http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-20 about the possible alternative to Enumerated values when additional values might be defined after the definition of the AVP.
As discussed, one alternative is to use Unsigned32/Unsigned64 AVP instead and to define specific values.
I will update the section 5.6 accordingly.

Regards,

Lionel 

PS: for information, the proposed text is described below. 

************************************

5.6.  Use of Enumerated Type AVPs

   The type Enumerated was initially defined to provide a list of valid
   values for an AVP with their respective interpretation described in
   the specification.  For instance, AVPs of type Enumerated can be used
   to provide further information on the reason for the termination of a
   session or a specific action to perform upon the reception of the
   request.

   As described in the section 4.4.2 above, defining an AVP of type
   Enumerated presents some limitations in term of extensibility and
   reusability.  Indeed, the finite set of valid values defined at the
   definition of the AVP of type Enumerated cannot be modified in
   practice without causing backward compatibility issues with existing
   implementations.  As a consequence, AVPs of Type Enumerated cannot be
   extended by adding new values to support new capabilities.  Diameter
   protocol designers are then strongly advised to carefully consider
   before defining an Enumerated AVP whether the set of values will
   remain unchanged or new values may be required in a near future.  If
   such extension is foreseen or cannot be avoided, it is recommended to
   rather define AVPs of type Unsigned32 or Unsigned64 in which the data
   field would contain an address space representing "values" that would
   have the same use of Enumerated values.

   For instance, an AVP describing possible access networks would be
   defined as follow:

      Access-Network-Type AVP (XXX) is of type Unsigned32 and contains an
      32-bit address space representing types of access networks. This
      application defines the following classes of access networks, all
      identified by the thousands digit in the decimal notation:

      o  1xxx (Mobile Access Networks)

      o  2xxx (Fixed Access Network)

      o  3xxx (Wireless Access Networks)

      Values that fall within the Mobile Access Networks category are used
      to inform a peer that a request has been sent for a user attached to
      a mobile access networks. The following values are defined in this
      application:

      1001: 3GPP-GERAN

         TBD.

      1002: 3GPP-UTRAN-FDD

         TBD.

   Unlike Enumerated AVP, any new value can be added in the address
   space defined by this Unsigned32 AVP without modifying the definition
   of the AVP.  There is therefore no risk of backward compatibility
   issue, especially when intermediate nodes may be present between
   Diameter endpoints.

   In the same line, AVPs of type Enumerated are too often used as a
   simple Boolean flag, indicating for instance a specific permission or
   capability, and therefore only two values are defined, e.g., TRUE/
   FALSE, AUTORIZED/UNAUTHORIZED or SUPPORTED/UNSUPPORTED.  This is a
   sub-optimal design since it limits the extensibility of the
   application: any new capability/permission would have to be supported
   by a new AVP or new Enumerated value of the already defined AVP, with
   the backward compatibility issues described above.  Instead of using
   an Enumerated AVP for a Boolean flag, protocol designers are again
   encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which
   the data field would be defined as bit mask whose bit settings
   are described in the relevant Diameter application specification.
   Such AVPs can be reused and extended without major impact on the
   Diameter application.  The bit mask should leave room for future
   additions.  Examples of AVPs that use bit masks are the Session-
   Binding AVP defined in [RFC6733] and the MIP6-Feature-Vector AVP
   defined in [RFC5447].

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.