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

Yuval Lifshitz <ylifshitz@sandvine.com> Sun, 03 July 2016 09:00 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 16A3912B03F for <dime@ietfa.amsl.com>; Sun, 3 Jul 2016 02:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.345
X-Spam-Level:
X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TvXM0oR0Wk7T for <dime@ietfa.amsl.com>; Sun, 3 Jul 2016 02:00:26 -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 4986312B00E for <dime@ietf.org>; Sun, 3 Jul 2016 02:00:26 -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.195.1; Sun, 3 Jul 2016 05:00:25 -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; Sun, 3 Jul 2016 05:00:24 -0400
From: Yuval Lifshitz <ylifshitz@sandvine.com>
To: "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com>, Naveen Kottapalli <naveen.sarma@gmail.com>
Thread-Topic: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references
Thread-Index: AdHMmcl9QU9rEm9ETbuYBI9wapFCOwGUVrkAAAfhngAAf3sWUA==
Date: Sun, 03 Jul 2016 09:00:23 +0000
Message-ID: <C43C255C7106314F8D13D03FA20CFE4930C878E2@wtl-exchp-2.sandvine.com>
References: <C43C255C7106314F8D13D03FA20CFE4930C7DE98@wtl-exchp-2.sandvine.com> <CANFmOt=ug2JEKqCOAOUWVxZe+m0oM_tHyWpbG5KfipQxvJC9yQ@mail.gmail.com> <F77ED24D51A356439EE433AD28B990DFC50E7539@FR712WXCHMBA09.zeu.alcatel-lucent.com>
In-Reply-To: <F77ED24D51A356439EE433AD28B990DFC50E7539@FR712WXCHMBA09.zeu.alcatel-lucent.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: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE4930C878E2wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/ZuOtvK4ysquTbvO_JQufuIOuNBc>
Cc: "dime@ietf.org" <dime@ietf.org>
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: Sun, 03 Jul 2016 09:00:29 -0000

Agree with both points. As the reference to 22.115 is very generic.
In most cases, though, we should reference specific 3GPP versions. Unlike in IETF, they don’t rename the document, even if substantially modified between versions..

From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]
Sent: Thursday, June 30, 2016 7:05 PM
To: Naveen Kottapalli; Yuval Lifshitz
Cc: dime@ietf.org
Subject: RE: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references

Hi all,

I would concur with the suggestion to just mention the 3GPP spec w/o version for the reference to 22.115, in case it is proposed to stick to this 3GPP reference:

[3GPPCHARG] is refered-to for the requirement “ that an application must be able to rate service information in real-time.”  as an example, which remained applicable (although I could not find the exact statement in this v5.2.0 referenced version) to subsequent versions of 22.115, and we could expect this to be still applicable in the future versions since it is generic enough.

Regarding the reference to [3GPPIMEI]:
The structure of IMEISV didn't change between release 5 and 13, and will likely not change in the future. But since this is about format, wouldn’t it be better to point on an explicit version, i.e. the last published one (Rel-13)?

BR
Maryse

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Naveen Kottapalli
Sent: jeudi 30 juin 2016 14:19
To: Yuval Lifshitz
Cc: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references

Is it mandatory to mention the version number?  Since the specification numbering keeps changing for every release, so can't we just mention the specification number without version?

Yours,
Naveen.

On 22 June 2016 at 21:16, Yuval Lifshitz <ylifshitz@sandvine.com<mailto:ylifshitz@sandvine.com>> wrote:
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<mailto:dime-bounces@ietf.org>] On Behalf Of Jouni Korhonen
Sent: Friday, June 17, 2016 6:39 PM
To: dime@ietf.org<mailto: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<mailto:DiME@ietf.org>
> https://www.ietf.org/mailman/listinfo/dime
>

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

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