[Dime] Issue #45 proposed wording changes
Steve Donovan <srdonovan@usdonovans.com> Tue, 18 March 2014 16:19 UTC
Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005981A06D9 for <dime@ietfa.amsl.com>; Tue, 18 Mar 2014 09:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level:
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edwh4d_1QTAk for <dime@ietfa.amsl.com>; Tue, 18 Mar 2014 09:19:19 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9E85B1A06CC for <dime@ietf.org>; Tue, 18 Mar 2014 09:19:19 -0700 (PDT)
Received: from [137.254.4.58] (port=30488 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WPwjO-0006vq-AB for dime@ietf.org; Tue, 18 Mar 2014 09:19:10 -0700
Message-ID: <532871FF.1050903@usdonovans.com>
Date: Tue, 18 Mar 2014 11:19:11 -0500
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "dime@ietf.org" <dime@ietf.org>
Content-Type: multipart/alternative; boundary="------------080801000107030505090706"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s0A8P94BX1-VObi0VQc1cfeL0og
Subject: [Dime] Issue #45 proposed wording changes
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 18 Mar 2014 16:19:21 -0000
All, I believe we have reached consensus on this issue that validity duration with a value of zero is used by the reporting node to indicate that an overload report is no longer valid and should be removed. I also believe that we have agreed that we will support a reduction percentage of zero with a non zero validity duration. To this end, I propose the following specific wording changes in the -01 draft. Regards, Steve ----- Section 4.5, Paragraph 1: First sentence - change "since" to "after". (Editorial change) Change: Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity- Duration AVP were not present. To: Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are treated as if the OC-Validity-Duration AVP were not present and result in the default value being used. Paragraph 3: Replace: This leaves no need for the reacting node to reason or guess the overload condition of the reporting node. With: This is achieved by sending an updated overload report (meaning it must contain a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). Section 5.5.2, Paragraph 7 Change: value == 0 Indicates explicitly the end of overload condition and the reacting node SHOULD NOT apply the traffic abatement algorithm procedures anymore for the given reporting node (or realm). To: value == 0 Indicates that no traffic reduction has been requested. As a result the overload state, including the sequence number, MUST NOT be removed and future overload reports of the same type from the same reporting node must follow the rules for new sequence numbers. New paragraphs at end of the section: A value of zero ("0") received in the OC-Validity-Duration in an updated overload report indicates that the overload condition has ended and that the overload state is no longer valid. In the case that the validity duration expires or is explicitly signaled as being no longer valid the state associated with the overload report MUST be removed and any abatement associated with the overload report MUST be ended. After removing the overload state the sequence number MUST NOT be used for future comparisons of sequence numbers. Section 5.5.3, New paragraph at the end: The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD insure that all reacting nodes receive the updated overload report.
- [Dime] Issue #45 proposed wording changes Steve Donovan