Re: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)
"Schendel, Jens (NSN - DE/Berlin)" <jens.schendel@nsn.com> Thu, 06 September 2012 14:19 UTC
Return-Path: <jens.schendel@nsn.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 C5CC121F867C for <dime@ietfa.amsl.com>; Thu, 6 Sep 2012 07:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4]
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 sdWIYRS45IAy for <dime@ietfa.amsl.com>; Thu, 6 Sep 2012 07:19:18 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D2BA421F8630 for <dime@ietf.org>; Thu, 6 Sep 2012 07:19:17 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q86EJDe4003574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Sep 2012 16:19:13 +0200
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q86EJCUW025397; Thu, 6 Sep 2012 16:19:13 +0200
Received: from DEMUEXC027.nsn-intra.net ([10.150.128.19]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Sep 2012 16:19:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD8C3A.924F9BBA"
Date: Thu, 06 Sep 2012 16:19:04 +0200
Message-ID: <E813F56D4B93FC49999BC08DAE9B7CC05EBC14@DEMUEXC027.nsn-intra.net>
In-Reply-To: <5047024C.5070806@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Fwd: Re: [Editorial Errata Reported] RFC4006 (3329)
Thread-Index: Ac2LOf4lanhHdIrgRoirTgQcdfatZAA/XGdQ
References: <CADUSUHPQYQqW5J5kE+-AiZJ8sTM2nYtMMhvLW++YP=y-zMoRJA@mail.gmail.com> <5047024C.5070806@cisco.com>
From: "Schendel, Jens (NSN - DE/Berlin)" <jens.schendel@nsn.com>
To: ext Benoit Claise <bclaise@cisco.com>, dime mailing list <dime@ietf.org>
X-OriginalArrivalTime: 06 Sep 2012 14:19:06.0118 (UTC) FILETIME=[92B8AA60:01CD8C3A]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 18630
X-purgate-ID: 151667::1346941153-00006F5F-6DB84154/0-0/0-0
Cc: xkiranj.1980@gmail.com
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: Thu, 06 Sep 2012 14:19:19 -0000
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, 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