Subject: [Dime] rfc4006bis - Future Proofing Enums - User-Equipment-Info

From: Yuval Lifshitz <[email-masked]>
Date: Fri, 12 Aug 2016 07:45:35 +0000

In the discussion that started in the IETF96 meeting, it was suggested that new AVPs will be added to allow extending existing enumerated AVPs, that currently cannot be extended without forcing a new Diameter application ID.
Would like to suggest the following additional AVPs to RFC4006bis:

"
8.XX.  User-Equipment-Info-Extension AVP

   The User-Equipment-Info-Extension AVP (AVP Code XXX) is of type Grouped and
   allows the credit-control client to indicate the identity and
   capability of the terminal the subscriber is using for the connection
   to network.

   It is defined as follows (per the grouped-avp-def of RFC 6733):

      User-Equipment-Info-Extension ::= < AVP Header: XXX >
                                                              [ User-Equipment-Info-IMEISV ]
                                                              [ User-Equipment-Info-MAC ]
                                                              [ User-Equipment-Info-EUI64 ]
                                                              [ User-Equipment-Info-ModifiedEUI64 ]
                                                              [ User-Equipment-Info-IMEI ]
                                                            *[ AVP ]

  Note that if the credit-control client wants to use an equipment type that does not 
  exist in the User-Equipment-Info AVP, it MUST use the User-Equipment-Info-Extension AVP.
  If the credit-control client wants to use an equipment type that already exist the 
  User-Equipment-Info AVP, it MAY use the User-Equipment-Info-Extension AVP if it is known that 
  the credit-control support it, or the User-Equipment-Info AVP otherwise.

8.XX.  User-Equipment-Info-IMEISV AVP

   The User-Equipment-Info-IMEISV AVP (AVP Code XXX) is of type OctetString.
   The identifier contains the International Mobile Equipment
   Identifier and Software Version in the international IMEISV format
   according to 3GPP TS 23.003 [3GPPIMEI].

8.XX.  User-Equipment-Info-MAC AVP

   The User-Equipment-Info-MAC AVP (AVP Code XXX) is of type OctetString.
   The identifier contains the 48-bit MAC address is formatted as 
   described in [RAD802.1X].

8.XX.  User-Equipment-Info-EUI64 AVP

   The User-Equipment-Info-EUI64 AVP (AVP Code XXX) is of type OctetString.
   The identifier contains the 64-bit identifier used to identify hardware instance of the
   product, as defined in [EUI64].

8.XX.  User-Equipment-Info-ModifiedEUI64 AVP

   The User-Equipment-Info-ModifiedEUI64 AVP (AVP Code XXX) is of type OctetString.
   In case of a types of terminals that have identifiers other than IMEI, IEEE 802 MACs, or EUI-64.
   These identifiers can  be converted to modified EUI-64 format as described in [IPv6Addr]
   or by using some other methods referred to in the service-specific documentation.

8.XX.  User-Equipment-Info-IMEI AVP

   The User-Equipment-Info-IMEI AVP (AVP Code XXX) is of type OctetString.
   The identifier contains the International Mobile Equipment
   Identifier in the international IMEI format
   according to 3GPP TS 23.003 [3GPPIMEI]."
"

Issue is tracked here: https://trac.tools.ietf.org/wg/dime/trac/ticket/95
Will send proposals for other extensible AVPs on separate emails.