Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references
"Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com> Thu, 30 June 2016 16:06 UTC
Return-Path: <maryse.gardella@nokia.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 E866C12D82C for <dime@ietfa.amsl.com>; Thu, 30 Jun 2016 09:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 pXMiQHGR_2Zy for <dime@ietfa.amsl.com>; Thu, 30 Jun 2016 09:06:12 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127A312D1A2 for <dime@ietf.org>; Thu, 30 Jun 2016 09:06:11 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 00A0722DB66E2; Thu, 30 Jun 2016 16:06:07 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5UG69so011987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2016 16:06:10 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5UG4tes005964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jun 2016 18:06:07 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.62]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 30 Jun 2016 18:04:55 +0200
From: "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com>
To: Naveen Kottapalli <naveen.sarma@gmail.com>, Yuval Lifshitz <ylifshitz@sandvine.com>
Thread-Topic: [Dime] draft-bertz-dime-rfc4006bis - 3GPP specifications references
Thread-Index: AdHMmcl9QU9rEm9ETbuYBI9wapFCOwGHxBIAAAqDpKA=
Date: Thu, 30 Jun 2016 16:04:54 +0000
Message-ID: <F77ED24D51A356439EE433AD28B990DFC50E7539@FR712WXCHMBA09.zeu.alcatel-lucent.com>
References: <C43C255C7106314F8D13D03FA20CFE4930C7DE98@wtl-exchp-2.sandvine.com> <CANFmOt=ug2JEKqCOAOUWVxZe+m0oM_tHyWpbG5KfipQxvJC9yQ@mail.gmail.com>
In-Reply-To: <CANFmOt=ug2JEKqCOAOUWVxZe+m0oM_tHyWpbG5KfipQxvJC9yQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_F77ED24D51A356439EE433AD28B990DFC50E7539FR712WXCHMBA09z_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/Uoi3CB2E01L2GN5LBL5J7l180dk>
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: Thu, 30 Jun 2016 16:09:18 -0000
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 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
- Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP spe… Yuval Lifshitz
- Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP spe… Gardella, Maryse (Nokia - FR)
- Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP spe… Naveen Kottapalli
- Re: [Dime] draft-bertz-dime-rfc4006bis - 3GPP spe… Yuval Lifshitz