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
>