IETF Logo Mail Archive

Re: [Gen-art] Gen-art LC review of draft-ietf-dime-ovli-08 - with summary

Steve Donovan <srdonovan@usdonovans.com> Thu, 06 August 2015 16:17 UTC

Return-Path: <srdonovan@usdonovans.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87161B3B49 for <gen-art@ietfa.amsl.com>; Thu, 6 Aug 2015 09:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level:
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 OEIU7MVCKqMR for <gen-art@ietfa.amsl.com>; Thu, 6 Aug 2015 09:17:31 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CDF1B3B2D for <gen-art@ietf.org>; Thu, 6 Aug 2015 09:17:31 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:59051 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from <srdonovan@usdonovans.com>) id 1ZNNrD-0006o2-V1; Thu, 06 Aug 2015 09:17:29 -0700
Message-ID: <55C3888A.3030603@usdonovans.com>
Date: Thu, 06 Aug 2015 11:17:14 -0500
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Elwyn Davies <elwynd@dial.pipex.com>, General area reviewing team <gen-art@ietf.org>, Ben Campbell <ben@nostrum.com>
References: <55B11713.1020100@dial.pipex.com> <55C0AECB.6060408@usdonovans.com> <55C19D41.4030508@dial.pipex.com>
In-Reply-To: <55C19D41.4030508@dial.pipex.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
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/gen-art/CAtAVVjv0nlFx7M2axfEXRUOpuE>
Cc: draft-ietf-dime-ovli.all@tools.ietf.org
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-dime-ovli-08 - with summary
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 16:17:32 -0000

Elwyn,

One question is answered below.  The remainder of your comments have 
been updated in the latest version of the draft (which will be uploaded 
soon).

Regards,

Steve
<snip>
>>> Minor issues:
>>> s4.2:
>>> Is there a need for and consequently how would one either cancel the 
>>> current abatement algorithm or select a different one?  I guess this 
>>> might happen if the reacting node that was running the algorithm 
>>> went away or itself became overloaded. However I I have no idea 
>>> whether this is a reasonable question!  OK.. well I see in s5.1.1 
>>> that the abatement algorithm can be changed... a pointer in s4.2 
>>> would be useful.  But could it be turned off?
>> SRD> OK.
> So... how would one turn it off if that was allowed/wanted/possible?
SRD> While not suggested, the selected abatement algorithm can be 
changed on a transaction by transaction basis.  Once an OLR has been 
sent the reporting node would need to cancel the existing overload 
report in one transaction and then send a new overload report for the 
new algorithm in a subsequent overload report.

v2.23.0 | Report a Bug | By Email