Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)

Kiran Jadhav <xkiranj.1980@gmail.com> Mon, 10 September 2012 10:46 UTC

Return-Path: <xkiranj.1980@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 4296421F864A for <dime@ietfa.amsl.com>; Mon, 10 Sep 2012 03:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.114
X-Spam-Level:
X-Spam-Status: No, score=-4.114 tagged_above=-999 required=5 tests=[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_LOW=-1]
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 uN-AENRg38Pw for <dime@ietfa.amsl.com>; Mon, 10 Sep 2012 03:46:36 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 049B721F863F for <dime@ietf.org>; Mon, 10 Sep 2012 03:46:35 -0700 (PDT)
Received: by eaai11 with SMTP id i11so817230eaa.31 for <dime@ietf.org>; Mon, 10 Sep 2012 03:46:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YFy5OPMFKo6QJ4KKdSj19qbz/Kilhlim/wpLhOHzFnc=; b=P1cf3bCBOIOJXwAcSkePZy7UG37QX+OH9V6C5chIjAOzwgjkZvyPpJp+TXgY+kVPmg cZVxqH295iOuBPB/ZEVqls1/lBmUX9n9HusRugf4QMkdZxShUd4eMEKadlNTX5tpspdv 6VC58FATur2byo7NkJ6fn/repta6X0iaJ7TCUXJlxNeCduR+gA9il8dGfiaYiQiw7cOH DXZ0gwGQb9Fv8RmMsx2LXeO+Nq1ORDvDjc+rrhihjX7wdVCi1C6tg1WpCkgML6qPv64h kQKCD7Pd4G45SJYlkZj6KDdSDdqoo9pX0FY61K+xYDu8cZWiP/nGYcyeKhUqShRapuS6 iJjg==
MIME-Version: 1.0
Received: by 10.14.0.198 with SMTP id 46mr18952281eeb.30.1347273995136; Mon, 10 Sep 2012 03:46:35 -0700 (PDT)
Received: by 10.14.221.199 with HTTP; Mon, 10 Sep 2012 03:46:34 -0700 (PDT)
In-Reply-To: <504DC309.6040202@cisco.com>
References: <CADUSUHPQYQqW5J5kE+-AiZJ8sTM2nYtMMhvLW++YP=y-zMoRJA@mail.gmail.com> <5047024C.5070806@cisco.com> <E813F56D4B93FC49999BC08DAE9B7CC05EBC14@DEMUEXC027.nsn-intra.net> <1B49CAB6E1212B40BDB75660BDF2B4A50FDF164E@OIVMEXO02.omnitel.it> <504DC309.6040202@cisco.com>
Date: Mon, 10 Sep 2012 12:46:34 +0200
Message-ID: <CADUSUHOj79UtUzog7KMTwAsfu19shnsXEr8g35=gPvJQePExeQ@mail.gmail.com>
From: Kiran Jadhav <xkiranj.1980@gmail.com>
To: Benoit Claise <bclaise@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b62275ee52ec504c956ab09"
X-Mailman-Approved-At: Mon, 10 Sep 2012 03:50:03 -0700
Cc: 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:49:21 -0000

Thank you every one for the consideration.

Best Regards,
Kiran

On Mon, Sep 10, 2012 at 12:38 PM, Benoit Claise <bclaise@cisco.com> wrote:

>  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<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<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> <xkiranj.1980@gmail.com>****
>
> *To: *
>
> RFC Errata System <rfc-editor@rfc-editor.org> <rfc-editor@rfc-editor.org>*
> ***
>
> *CC: *
>
> Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com,
> juha-pekka.koskinen@nokia.com, marco.stura@nokia.com,
> John.Loughney@nokia.com, rbonica@juniper.net, bclaise@cisco.com,
> Bernard_Aboba@hotmail.com, 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> 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>
>
> 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****
>
> ** **
>
> ** **
>
> ** **
>
>
>