[Dime] rfc4006bis - Future Proofing Enums - User-Equipment-Info
Yuval Lifshitz <ylifshitz@sandvine.com> Fri, 12 August 2016 07:45 UTC
Return-Path: <ylifshitz@sandvine.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4D212D9D6 for <dime@ietfa.amsl.com>; Fri, 12 Aug 2016 00:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.167
X-Spam-Level:
X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUJk1r70_OHr for <dime@ietfa.amsl.com>; Fri, 12 Aug 2016 00:45:38 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CC412D9BE for <dime@ietf.org>; Fri, 12 Aug 2016 00:45:38 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 12 Aug 2016 03:45:36 -0400
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Fri, 12 Aug 2016 03:45:36 -0400
From: Yuval Lifshitz <ylifshitz@sandvine.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: rfc4006bis - Future Proofing Enums - User-Equipment-Info
Thread-Index: AdHyEcIByFcdc3FdSa2GxZIe8Q/y7g==
Date: Fri, 12 Aug 2016 07:45:35 +0000
Message-ID: <C43C255C7106314F8D13D03FA20CFE4930CC50FF@wtl-exchp-2.sandvine.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.143.2]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/Gi4vfU2jWpugZ-EH3hEOjotuTbQ>
Cc: "Gardella, Maryse (Nokia - FR) (maryse.gardella@nokia.com)" <maryse.gardella@nokia.com>
Subject: [Dime] rfc4006bis - Future Proofing Enums - User-Equipment-Info
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2016 07:45:40 -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.
- [Dime] rfc4006bis - Future Proofing Enums - User-… Yuval Lifshitz