Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)
Benoit Claise <bclaise@cisco.com> Mon, 10 September 2012 10:38 UTC
Return-Path: <bclaise@cisco.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 8AF2C21F861A for <dime@ietfa.amsl.com>; Mon, 10 Sep 2012 03:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.023
X-Spam-Level:
X-Spam-Status: No, score=-9.023 tagged_above=-999 required=5 tests=[AWL=2.091, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soVXv4BAzHHm for <dime@ietfa.amsl.com>; Mon, 10 Sep 2012 03:38:04 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2FC21F8619 for <dime@ietf.org>; Mon, 10 Sep 2012 03:38:03 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AAc1rh000113; Mon, 10 Sep 2012 12:38:01 +0200 (CEST)
Received: from [10.149.0.91] (dhcp-10-149-0-91.cisco.com [10.149.0.91]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AAc17V004938; Mon, 10 Sep 2012 12:38:01 +0200 (CEST)
Message-ID: <504DC309.6040202@cisco.com>
Date: Mon, 10 Sep 2012 12:38:01 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: "Stura, Marco, Vodafone Italy" <Marco.STURA@vodafone.com>
References: <CADUSUHPQYQqW5J5kE+-AiZJ8sTM2nYtMMhvLW++YP=y-zMoRJA@mail.gmail.com><5047024C.5070806@cisco.com> <E813F56D4B93FC49999BC08DAE9B7CC05EBC14@DEMUEXC027.nsn-intra.net> <1B49CAB6E1212B40BDB75660BDF2B4A50FDF164E@OIVMEXO02.omnitel.it>
In-Reply-To: <1B49CAB6E1212B40BDB75660BDF2B4A50FDF164E@OIVMEXO02.omnitel.it>
Content-Type: multipart/alternative; boundary="------------030009070603070601090308"
Cc: xkiranj.1980@gmail.com, dime mailing list <dime@ietf.org>
Subject: Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 10 Sep 2012 10:38:05 -0000
Thanks to all. Accepted as "Hold for document update" Regards, Benoit. > > Hi, > > Yes I agree with proposed change. Indeed the intention is that GSU AVP > is not sent at all, this was supposed to be clear looking at Flow VIII > (fro example) in Annex A. > > BR, > > Marco > > ------------------------------------------------------------------------ > > *From:*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf > Of *Schendel, Jens (NSN - DE/Berlin) > *Sent:* Thursday, September 06, 2012 4:19 PM > *To:* ext Benoit Claise; dime mailing list > *Cc:* xkiranj.1980@gmail.com > *Subject:* Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) > *Importance:* Low > > Hi, > > I agree with the proposed change. Actually, the Credit Control Server > may decide to apply immediate redirect for some other reason than zero > balance (which is given as explanation in the RFC text), i.e. for some > other advice like charge rate or so. > > I also believe that the original wording (even if not completed) would > have been different if zero GSU were indented. > > So, pretty clear to me. > > Jens > > *From:*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf > Of *ext Benoit Claise > *Sent:* Wednesday, September 05, 2012 9:42 AM > *To:* dime mailing list > *Cc:* xkiranj.1980@gmail.com > *Subject:* [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329) > > Dear all, > > This errata has been submitted. > While this looks right me, I always prefer to have a confirmation from > the experts... > > Regards, Benoit. > > > > -------- Original Message -------- > > *Subject: * > > > > Re: [Editorial Errata Reported] RFC4006 (3329) > > *Date: * > > > > Thu, 23 Aug 2012 12:00:03 +0200 > > *From: * > > > > Kiran Jadhav <xkiranj.1980@gmail.com> <mailto:xkiranj.1980@gmail.com> > > *To: * > > > > RFC Errata System <rfc-editor@rfc-editor.org> > <mailto:rfc-editor@rfc-editor.org> > > *CC: * > > > > Harri.Hakala@ericsson.com <mailto:Harri.Hakala@ericsson.com>, > Leena.Mattila@ericsson.com <mailto:Leena.Mattila@ericsson.com>, > juha-pekka.koskinen@nokia.com <mailto:juha-pekka.koskinen@nokia.com>, > marco.stura@nokia.com <mailto:marco.stura@nokia.com>, > John.Loughney@nokia.com <mailto:John.Loughney@nokia.com>, > rbonica@juniper.net <mailto:rbonica@juniper.net>, bclaise@cisco.com > <mailto:bclaise@cisco.com>, Bernard_Aboba@hotmail.com > <mailto:Bernard_Aboba@hotmail.com>, david@mitton.com > <mailto:david@mitton.com> > > > > Hello All, > > I have reported an Editorial Errata for RFC4006. > > This small editorial errata in the RFC4006 is causing issues in some > call scenarios where the end user is given an option by the Service > Provider to replenish his credit if it is found at the start of a call > that the end-user's account balance is zero/insufficient. This is > basically due to mis-interpretation of the sentence in the RFC by > different vendors. > > Please have a look at the suggested change which will help a common > implementation of the behavior across all vendors. > > Best Regards, > > Kiran Jadhav > > On Thu, Aug 23, 2012 at 11:13 AM, RFC Errata System > <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> wrote: > > > The following errata report has been submitted for RFC4006, > "Diameter Credit-Control Application". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=3329 > > -------------------------------------- > Type: Editorial > Reported by: Kiran Jadhav <xkiranj.1980@gmail.com > <mailto:xkiranj.1980@gmail.com>> > > Section: 5.6.2 > > Original Text > ------------- > " Note that the credit-control server may already have initiated the > above-described process for the first interrogation. However, the > user's account might be empty when this first interrogation is > performed. In this case, the subscriber can be offered a chance to > replenish the account and continue the service. The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit. It immediately starts the graceful > service termination without sending any message to the server. An > example of this case is illustrated in Appendix A." > > Corrected Text > -------------- > " Note that the credit-control server may already have initiated the > above-described process for the first interrogation. However, the > user's account might be empty when this first interrogation is > performed. In this case, the subscriber can be offered a chance to > replenish the account and continue the service. The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful > service termination without sending any message to the server. An > example of this case is illustrated in Appendix A." > > Notes > ----- > In the sentence "The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication and Validity-Time > AVPs but no Granted-Service-Unit." it is important that we add the > letters "AVP" after Granted-Service-Units as it is not clear whether > the sentence refers to "Not sending Granted-Service-Unit AVP at all" > or "sending GSU=0 (Granted-Service-Unit AVP with value 0". > > Different OCS vendors interpret the sentence above in a different way, > some do not send the Granted-Service-Unit AVP at all, while some > others send the Granted_Service-Unit=0. And this causes problem in the > call scenario where FUI+Redirect is sent together with GSU=0. This > causes the call to enter a loop and terminate with an error. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4006 (draft-ietf-aaa-diameter-cc-06) > -------------------------------------- > Title : Diameter Credit-Control Application > Publication Date : August 2005 > Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, > J. Loughney > Category : PROPOSED STANDARD > Source : Authentication, Authorization and Accounting > Area : Operations and Management > Stream : IETF > Verifying Party : IESG >
- [Dime] Fwd: Re: [Editorial Errata Reported] RFC40… Benoit Claise
- Re: [Dime] Fwd: Re: [Editorial Errata Reported] R… Schendel, Jens (NSN - DE/Berlin)
- Re: [Dime] Fwd: Re: [Editorial Errata Reported] R… lionel.morand
- Re: [Dime] Fwd: Re: [Editorial Errata Reported] R… Benoit Claise
- Re: [Dime] Fwd: Re: [Editorial Errata Reported] R… Kiran Jadhav