IETF Logo Mail Archive

[Dime] Ben's comments on 5.2.2: 5th paragraph

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 15 January 2015 09:59 UTC

Return-Path: <ulrich.wiehe@nsn.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 CDE9E1B2BBB for <dime@ietfa.amsl.com>; Thu, 15 Jan 2015 01:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 QgTPzxAKyKEK for <dime@ietfa.amsl.com>; Thu, 15 Jan 2015 01:59:14 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DEE1B2BC2 for <dime@ietf.org>; Thu, 15 Jan 2015 01:59:13 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0F9xCvX000714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2015 09:59:12 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0F9xCwo030137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Jan 2015 10:59:12 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 15 Jan 2015 10:59:11 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 10:59:11 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: Ben's comments on 5.2.2: 5th paragraph
Thread-Index: AdAwqehaWtrP3vnmTBC01HcLvLd+1Q==
Date: Thu, 15 Jan 2015 09:59:10 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523F0AA@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.109]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681523F0AADEMUMBX014nsnin_"
MIME-Version: 1.0
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: 3166
X-purgate-ID: 151667::1421315952-00007286-D207DF6B/0/0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/u9QoSv-Y1h9_L04KhoXpOTUbeZg>
Cc: "draft-ietf-dime-ovli@tools.ietf.org" <draft-ietf-dime-ovli@tools.ietf.org>
Subject: [Dime] Ben's comments on 5.2.2: 5th paragraph
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: Thu, 15 Jan 2015 09:59:16 -0000

Ben wrote:
-- 5.2.2: 5th paragraph:

This doesn't seem quite right, since it leaves the option of no abatement at all. Second, it doesn't seem to allow delegation of abatement downstream. When might one choose to ignore those SHOULDs? Is this here to allow delegation? If so, the use of SHOULD makes local throttling preferred over delegation.

<Ulrich> My understanding is: If delegation of abatement is done by a node, then that node is no longer a reacting node.
The first SHOULD is ignored by reacting nodes that do not support diversion and hence always perform throttling. For the second SHOULD you MAY be right. We SHOULD replace it with MUST.
In addition the world "otherwise" must not be read as " if diversion abatement treatment is not possible" but as " if diversion abatement treatment is not possible and if the first SHOULD is ignored".

v2.23.0 | Report a Bug | By Email