Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references

Yuval Lifshitz <ylifshitz@sandvine.com> Wed, 22 June 2016 15:56 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 DA4C412DE19 for <dime@ietfa.amsl.com>; Wed, 22 Jun 2016 08:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] 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 GIAhoqIbj8D9 for <dime@ietfa.amsl.com>; Wed, 22 Jun 2016 08:56:50 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083F012DE45 for <dime@ietf.org>; Wed, 22 Jun 2016 08:46:17 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 22 Jun 2016 11:46:16 -0400
From: Yuval Lifshitz <ylifshitz@sandvine.com>
To: "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references
Thread-Index: AdHMmcl9QU9rEm9ETbuYBI9wapFCOw==
Date: Wed, 22 Jun 2016 15:46:15 +0000
Message-ID: <C43C255C7106314F8D13D03FA20CFE4930C7DE98@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.1]
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/a1YxPEghiaXcbzGPmvFMoj6ZlFo>
Subject: Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references
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: Wed, 22 Jun 2016 15:56:52 -0000

Hi All,
RFC4006 currently reference rel5 3GPP specifications. Would like to propose the following changes to it would point to latest specifications:
In page 91, we have following text:

[3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 5), 3GPP TS 23.003 v. 5.8.0,
               2003-12
Current version of that spec is 13.5.0 (http://www.etsi.org/deliver/etsi_ts/123000_123099/123003/13.05.00_60/ts_123003v130500p.pdf) 
The structure of IMEI didn't change between release 5 and 13, so the change should not have other side effects, therefore would recommend following text:

[3GPPIMEI]  3rd Generation Partnership Project; Technical
               Specification Group Core Network, Numbering, addressing
               and identification, (release 13), 3GPP TS 23.003 v. 13.5.0,
               2016-04.

Another 3GPP specification referenced from RFC4006 is in page 90:

[3GPPCHARG] 3rd Generation Partnership Project; Technical
               Specification Group Services and System Aspects, Service
               aspects; Charging and Billing, (release 5), 3GPP TS
               22.115 v. 5.2.1, 2002-03.

One option here would be to use the latest version of the above spec, which is 13.3.0 (http://www.etsi.org/deliver/etsi_ts/122100_122199/122115/13.03.00_60/ts_122115v130300p.pdf) 
In the introduction, the spec is used as justification to why RFC4006 was needed at the first place, and why RFC3588 was not sufficient for these needs. So, any additional requirements added in release 13 version would only stress the necessity of RFC4006.
Would recommend the following text:

[3GPPCHARG] 3rd Generation Partnership Project; Technical
               Specification Group Services and System Aspects, Service
               aspects; Charging and Billing, (release 13), 3GPP TS
               22.115 v. 13.3.0, 2016-03.


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, June 17, 2016 6:39 PM
To: dime@ietf.org
Subject: Re: [Dime] draft-bertz-dime-rfc4006bis

Thanks for the "RFC4006bis" team for initiating the work. See inline

6/17/2016, 1:04 AM, Yuval Lifshitz kirjoitti:
> Dear group members,
> There are some more modification to RFC4006 that we would like to propose (also listed here: https://github.com/lbertz02/rfc4006bis/issues) that probably require further discussion in the group:
> (1) Update the IPv6 reference

This is straight forward. Just make sure to reference to RFC4291bis work in 6MAN (draft-ietf-6man-rfc4291bis)

> (2) Update the 3GPP charging reference (currently point to rel5...). 
> Here we may want to change that to point to a different doc altogether 
> (3GPP TS 32.299), which is more relevant (and didn't exist at the 
> time)

Here, someone really needs to check that changing the reference (TS and
release) does not break anything. I would encourage you to come up with a short analysis e.g., to Berlin meeting.

> (3) Change the AVP table in page 56-57, by removing the "Encr" and 
> "SHOULD NOT" columns, and the "P" indication (see attached file) - 
> similarly to the change made in RFC6733

This should be straigh forward. To my understanding no implementation follows the 'encr' recommendation in practise. Correct?

> (4) Upgrade Restriction-Filter-Rule AVP to also support RFC 5777

Again here some effort needs to be put to analyze backward compatibility is maintained if we touch Restriction-Filter-Rule AVP. I would encourage you to come up with a short analysis e.g., to Berlin meeting.

Also, I'll add (5) Credit-Control-Answer when 'E' is set. Check that the command is aligned with RFC6733 regarding the error replies.

- Jouni



>
> Appreciate your feedback!
>
> Yuval
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime