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

Naveen Kottapalli <naveen.sarma@gmail.com> Thu, 30 June 2016 12:19 UTC

Return-Path: <naveen.sarma@gmail.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 ECD3212D12B for <dime@ietfa.amsl.com>; Thu, 30 Jun 2016 05:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aoQOwD0sLEPE for <dime@ietfa.amsl.com>; Thu, 30 Jun 2016 05:19:34 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAD212D0BA for <dime@ietf.org>; Thu, 30 Jun 2016 05:19:34 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id u201so61837562oie.0 for <dime@ietf.org>; Thu, 30 Jun 2016 05:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TDjq9i7NwWAcHoSLGWK1P8/PsCGHXDDH68QgHoxNKe4=; b=zvC3g/UV093GQEGDmhWxRC2ePRHk2ZbTqVgQEmDPJdDJCGy6DIapRFdgVfVYC7bf6b qWWYod1DJolsEGkRZ1aR7gjFGZYHcud7qzlDENKSCsQreGIkd+wzWB01dBpD1Yms1DJ8 7+ipL/NNaNwqy1uf1vRU0Plcj51BYcoYQNhPg2IsOkpcD0uEngOkNZEMAS1UbFzEnmV2 PN79tULBoJYpsHzqcogmxn2scDYW7pr36tPyKC0lVgLUsd8qMGBqXAFzreTHc3Pas3Of Kfxply0MZJGTlpsYIwbrYEGejs8eka4mVHbu7rbFQQWznLildUFPq1D3K93ZEWC7dklH zXIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TDjq9i7NwWAcHoSLGWK1P8/PsCGHXDDH68QgHoxNKe4=; b=JUHvwPNuc+iKnRGuZCIXcnBFTwFGMSC+s3NSAZ+t2qijD1chkwzVGc0Wmhgzsf7Dg3 xUSo4RY0+U0a1vqyky4Q4QM2srgaJgTsoIySCuV1qoSyAec7gDU8AyZgFJ8MDjy/ciEX 4IEmYMNOSNBU8XBvKovKaZiBCK+hzvknJQydcA9bciudeMlDYTt6Cjs5QWCxa49uMYIm a7eAZg7nOJ0kKPPww8qAHkxgaPQD7Fh7IQaQinop0mvMrBbsxafic2dMJDrIRUW2LZbC WVtfDBUJxSRspygmIEsQUpSvE+4HYVxX3P8ha/5aGnuynuaRvf2i3WURhcaPAXRlCqJj wVBA==
X-Gm-Message-State: ALyK8tLPwGYVOEh06CSmDv518wOIkfiDL5s+8Al7XmS/Km3oTBs8D6sB2hCKz0bWB9DF+Vp5weQ//3K0KKKtsw==
X-Received: by 10.202.73.16 with SMTP id w16mr9353733oia.92.1467289173784; Thu, 30 Jun 2016 05:19:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.3.5 with HTTP; Thu, 30 Jun 2016 05:19:14 -0700 (PDT)
In-Reply-To: <C43C255C7106314F8D13D03FA20CFE4930C7DE98@wtl-exchp-2.sandvine.com>
References: <C43C255C7106314F8D13D03FA20CFE4930C7DE98@wtl-exchp-2.sandvine.com>
From: Naveen Kottapalli <naveen.sarma@gmail.com>
Date: Thu, 30 Jun 2016 17:49:14 +0530
Message-ID: <CANFmOt=ug2JEKqCOAOUWVxZe+m0oM_tHyWpbG5KfipQxvJC9yQ@mail.gmail.com>
To: Yuval Lifshitz <ylifshitz@sandvine.com>
Content-Type: multipart/alternative; boundary=001a113e5804fc7fbb05367de157
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/uDmobJUTGsGSwnyLacpaJsXFbqQ>
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 12:19:37 -0000

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> 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] 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
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>