IETF Logo Mail Archive

Re: [Dime] Ben's comments on 4.3, third paragraph from end

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Fri, 16 January 2015 10:30 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 0E2D31ACD03 for <dime@ietfa.amsl.com>; Fri, 16 Jan 2015 02:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uUS7c9nVfD6U for <dime@ietfa.amsl.com>; Fri, 16 Jan 2015 02:30:37 -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 8FC941A8878 for <dime@ietf.org>; Fri, 16 Jan 2015 02:30:37 -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 t0GAUY8A006091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Jan 2015 10:30:34 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0GAUTVh022845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Jan 2015 11:30:32 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 16 Jan 2015 11:30:29 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Fri, 16 Jan 2015 11:30:29 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>, Steve Donovan <srdonovan@usdonovans.com>
Thread-Topic: [Dime] Ben's comments on 4.3, third paragraph from end
Thread-Index: AdAwqcKKpO0LYTRKTfCB6qzRIWwNRQAEwOaAAARbWgAAJ7oO0A==
Date: Fri, 16 Jan 2015 10:30:28 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523F249@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681523F07F@DEMUMBX014.nsn-intra.net> <54B7BD25.4040103@usdonovans.com> <5BC32AB7-6DA7-4B27-90E6-40203B3C35D2@nostrum.com>
In-Reply-To: <5BC32AB7-6DA7-4B27-90E6-40203B3C35D2@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.157]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 2249
X-purgate-ID: 151667::1421404235-00007286-620961F0/0/0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/OYqXvkMiEkZeWvA7EaPvGUyz5w8>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end
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: Fri, 16 Jan 2015 10:30:40 -0000

Ben

The Note at the beginning of 5.1 is about change of announced capabilities in reacting nodes, while the text in 4.2 (and 5.2.1.4) is about change of selected algorithm by reporting nodes.
I don't think the text in 4.2 (and 5.2.1.4) is totally wrong. Of course, if the reacting node changes the set of announced capabilities, the reporting node may change (or even need to  change) the selected algorithm. What is not allowed to be changed by the reporting node during an overload condition is the deterministic function that assignes to every set of commonly supported algorithms a distinct selected algorithm.


Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Thursday, January 15, 2015 4:19 PM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

Sorry, that was 4.2. 

> On Jan 15, 2015, at 7:14 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
> 
> I agree with Ulrich, I don't see the issue.
> 
> 
> On 1/15/15 3:58 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Ben wrote:
>> -- 4.3, third paragraph from end:
>>  
>> This still assumes that reporting nodes cannot change algorithms during overload. I thought we agreed to remove that. (The normative text is also still there--see later comment.)
>>  
>> <Ulrich> I don't understand. In my copy of -06 the third paragraph from end in 4.3 reads:
>>    Two types of overload abatement treatment are defined, diversion and
>>    throttling.  Reacting nodes are responsible for determining which
>>    treatment is appropriate for individual requests.
>> How does this text assume that reporting nodes cannot change algorithms during overload?
>>  
>>  
>> 
>> 
>> _______________________________________________
>> DiME mailing list
>> 
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

v2.23.0 | Report a Bug | By Email