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