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**** > > ** ** > > ** ** > > ** ** > > >
- [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