Re: [Dime] RE : RE: RE : RE: RE : Re: draft reply LS to 3GPP SA5 on RFC 4006..

"Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com> Tue, 09 August 2016 09:59 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 92ADC12D666 for <dime@ietfa.amsl.com>; Tue, 9 Aug 2016 02:59:18 -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 IAPZM0q3agUB for <dime@ietfa.amsl.com>; Tue, 9 Aug 2016 02:59:15 -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 B43BA12D519 for <dime@ietf.org>; Tue, 9 Aug 2016 02:59:14 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7A12DD97CCE6F; Tue, 9 Aug 2016 09:59:10 +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 u799xBIG003268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Aug 2016 09:59:12 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 u799xBpI017939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Aug 2016 11:59:11 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.95]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 9 Aug 2016 11:59:11 +0200
From: "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com>
To: "lionel.morand@orange.com" <lionel.morand@orange.com>, Yuval Lifshitz <ylifshitz@sandvine.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] RE : RE: RE : RE: RE : Re: draft reply LS to 3GPP SA5 on RFC 4006..
Thread-Index: AdHyGqnkQU4xh+A6QUKL+3ZrNnFg8gAAy78g
Date: Tue, 09 Aug 2016 09:59:10 +0000
Message-ID: <F77ED24D51A356439EE433AD28B990DFC51264F8@FR712WXCHMBA09.zeu.alcatel-lucent.com>
References: <9540_1470732452_57A998A3_9540_1465_1_6B7134B31289DC4FAF731D844122B36E01F58A01@OPEXCLILM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <9540_1470732452_57A998A3_9540_1465_1_6B7134B31289DC4FAF731D844122B36E01F58A01@OPEXCLILM43.corporate.adroot.infra.ftgroup>
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_F77ED24D51A356439EE433AD28B990DFC51264F8FR712WXCHMBA09z_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/sYqCFRbS5sMep4TQNx82jFRPVk0>
Subject: Re: [Dime] RE : RE: RE : RE: RE : Re: draft reply LS to 3GPP SA5 on RFC 4006..
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: Tue, 09 Aug 2016 09:59:18 -0000

Hi Lionel,

Now I see the purpose for the clarification, which is helpful.
Therefore it could be sufficient IMHO to have:
As a reminder, the IETF RFC 3588 does not define a new Diameter base protocol but is a new version of the specification defining the Diameter base protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the IETF RFC 2223:

    Obsoleted-by

       To be used to refer to the newer document(s) that replaces the
       older document.

Which already make it clear that documents using obsoleted IETF RFC should be  updated to refer to the new IETF RFC when published (i.e. applicable to both RFC 3588 and RFC 4006 as well), and also that per 3GPP LS it is already assumed “the normative reference for Diameter base protocol would be updated to IETF RFC 6733 for 3GPP SA5 Diameter charging applications”.

Besides this, don’t you think it would also be useful for 3GPP to get recommendation on how to address the temporary situation whereby 3GPP application(s) will refer to the new version RFC 6733, whereas the current RFC 4006 is still refered-to ?
What about to have some statement like?:
"Whenever a document is updated to refer to the new IETF RFC 6733, if the same document is also using IETF RFC 4006, IETF DIME WG recommends to ….. until the revision of the IETF RFC 4006 aligned with IETF RFC 6733 is published.


BR
Maryse



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: mardi 9 août 2016 10:48
To: Gardella, Maryse (Nokia - FR); Yuval Lifshitz; jouni.nospam@gmail.com; dime@ietf.org
Subject: [Dime] RE : RE: RE : RE: RE : Re: draft reply LS to 3GPP SA5 on RFC 4006..


Dear Maryse,

The clarification is intended to clarify the wording "new Diameter base protocol" used incorrectly in the LS and then clarify the notion of "obsoleted-by" used by IETF and the consequence on documents referencing the obsoleted RFC. And the 3GPP charging specification refers to both RFC4006 and RFC3588.

To make the recommendation clear, would the following rewording be acceptable?:

"any document using the IETF RFC 3588 as reference for the Diameter base protocol should be updated to refer to the new IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WGs to follow this recommendation in their specifications when applicable. The same recommendation will apply for the revision of the IETF RFC 4006 when published by the IETF as for any new RFC obsoleting an old RFC."

Regards,

Lionel
Le 9 août 2016 10:13, "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com<mailto:maryse.gardella@nokia.com>> a écrit :
>
> Hi Lionel,
>
>
>
> Thanks for this clarification.
>
> I am not sure about this reminder in the context of this LS, unless it is intended to propose guidance on how to deal with the reference to RFC 4006:
>
>
>
> Could we have:
>
> “any document using the IETF RFC 3588 as reference for the Diameter base protocol should be updated to refer to the new IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WGs to follow this recommendation in their specifications when applicable. When IETF RFC 4006 is refered-to, the recommendation is to further consider alignment with RFC 4006 planned to be updated with new IETF RFC 6733“
>
>
>
> Or an alternative recommendation?
>
>
>
> BR
>
> Maryse
>
>
>
>
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com<mailto:lionel.morand@orange.com>
> Sent: mardi 9 août 2016 09:38
> To: Gardella, Maryse (Nokia - FR); Yuval Lifshitz; jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>; dime@ietf.org<mailto:dime@ietf.org>
> Subject: [Dime] RE : RE: RE : Re: draft reply LS to 3GPP SA5 on RFC 4006..
>
>
>
> Hi Maryse,
>
> Please below.
>
> Regards,
>
> Lionel
>
> Le 9 août 2016 09:30, "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com<mailto:maryse.gardella@nokia.com>> a écrit :
> >
> > Hi,
> >
> >
> >
> > I would also favor having the two questions from the 3GPP LS repeated as per suggestion below:
> >
> >
> >
> > “The IETF DIME WG has discussed both options raised in the LS from 3GPP SA5:
> >
> > •             Is IETF RFC 4006 planned to be updated in order to rely on IETF RFC 6733 as the new Diameter Base protocol?
> >
> > •             If not, are there any recommendations from IETF on how to address the implicit reference to IETF RFC 3588 as Diameter Base Protocol for 3GPP SA5 Diameter Online charging through use of IETF RFC 4006?
> >
> > and the decision was made to update of the IETF RFC 4006 as per the first option.”
> >
> >
> >
> > Beside this, I am not sure to understand the sentence below in the context of this LS:
> >
> > “In the present case, any document using the IETF RFC 3588 as reference for the Diameter base protocol should be updated to refer to the new IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WGs to follow this recommendation in their specifications when applicable”. Especially what is intended to be conveyed  behind “In the present case”?
> >
>
> "In the present  case" refers to the RFC 3588 "obsoleted-by" the RFC 6733.
>
> >
> > Maryse
> >
> >
> >
> > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com<mailto:lionel.morand@orange.com>
> > Sent: dimanche 7 août 2016 15:56
> > To: Yuval Lifshitz; jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>; dime@ietf.org<mailto:dime@ietf.org>
> > Subject: [Dime] RE : Re: draft reply LS to 3GPP SA5 on RFC 4006..
> >
> >
> >
> > Of course :)
> >
> > Lionel
> >
> > Le 7 août 2016 07:54, Yuval Lifshitz <ylifshitz@sandvine.com<mailto:ylifshitz@sandvine.com>> a écrit :
> >
> > Did you mean?
> >
> > " As a reminder, the IETF RFC 6733 does not define a new Diameter base protocol but is a new version of the specification defining the Diameter base protocol."
> >
> > -----Original Message-----
> > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> > Sent: Friday, August 05, 2016 8:41 PM
> > To: dime@ietf.org<mailto:dime@ietf.org>
> > Subject: [Dime] draft reply LS to 3GPP SA5 on RFC 4006..
> >
> > Folks,
> >
> > Lionel and I have been drafting a reply LS to 3GPP SA5 (and CC CT3/CT4).
> > This is the current draft. Comments are welcome. One question is (Lionel favours, I disagree ;) whether we should repeat the two questions 3GPP asked from us or assume they can look it up from the origial LS.
> >
> > - Jouni & Lionel
> >
> > -------------------------------------------------------------------------
> > The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query regarding the IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/).
> >
> > The IETF DIME WG has discussed both options raised in the LS from 3GPP
> > SA5 and the decision was made to update of the IETF RFC 4006 (the option 1). The aim of this update is to align the Diameter Credit-Control application specification with the IETF RFC 6733, fix existing known issues in the current specification and comply with the recommendations given in the IETF RFC 7423 on the design of Diameter application. The time line for the completion of the RFC 4006 update is set to November 2017.
> >
> > As a reminder, the IETF RFC 3588 does not define a new Diameter base protocol but is a new version of the specification defining the Diameter base protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the IETF RFC 2223:
> >
> >     Obsoleted-by
> >
> >        To be used to refer to the newer document(s) that replaces the
> >        older document.
> >
> > In the present case, any document using the IETF RFC 3588 as reference for the Diameter base protocol should be updated to refer to the new IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WGs to follow this recommendation in their specifications when applicable.
> > -------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > 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
> >
> > _________________________________________________________________________________________________________________________
> >
> >
> >
> > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> >
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> >
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >
> > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >
> >
> >
> > This message and its attachments may contain confidential or privileged information that may be protected by law;
> >
> > they should not be distributed, used or copied without authorisation.
> >
> > If you have received this email in error, please notify the sender and delete this message and its attachments.
> >
> > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> >
> > Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.