IETF Logo Mail Archive

Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 11 February 2014 09:37 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 41CCB1A0564 for <dime@ietfa.amsl.com>; Tue, 11 Feb 2014 01:37:24 -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, RCVD_IN_DNSWL_HI=-5] 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 WJcGRXEwQZd3 for <dime@ietfa.amsl.com>; Tue, 11 Feb 2014 01:37:21 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD111A0086 for <dime@ietf.org>; Tue, 11 Feb 2014 01:37:20 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9bIZV024556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 10:37:19 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1B9bIj4009124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:37:18 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 10:37:18 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 10:37:18 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPI+1LK95DWDMaH0qQEyVc/ebDNpqpv0FwgATFJ4CAAUePcA==
Date: Tue, 11 Feb 2014 09:37:18 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B29A1@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <CD459A84-E32A-49F9-9F5B-95167F318746@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B259D@DEMUMBX014.nsn-intra.net> <52F8E5A7.6030902@usdonovans.com>
In-Reply-To: <52F8E5A7.6030902@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.106]
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: 1784
X-purgate-ID: 151667::1392111439-00001A6F-0D9147F4/0-0/0-0
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
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, 11 Feb 2014 09:37:24 -0000

Steve,

I do not agree.

e.g. 
1. reacting node sends Request with application ID = x to reporting node
2. reporting node sends back answer (containing an OLR) with application ID = x
3. reacting node now may very well send  a new request with application ID = y to the reporting node without breaking any Diameter rules. 
The new request sent in step 3 is NOT subject to throttling according to the OLR received in step 2.
I hope this is not contentious.
In order to provide a complete list of conditions to say when an OLR of a given type applies to a new request, we should not let c) go by the board.

Ulrich


 


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 3:44 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


>>       c) The value of the Application-ID in the Diameter Header of the
>>          request matches the value of the Application-ID of the Diameter
>>          Header of the received message that contained the OC-OLR AVP.
> No need for this since we agreed that DOIC implicitly always refers 
> to the application on which the DOIC AVPs are carried in.
> <Ulrich>yes, we agreed on that, so c) is correct and it does not harm to keep c)</Ulrich>
SRD> I don't see the reason for including this statement.  By
definition, an overload report
applies to the application ID in the answer message.  There is no way
for the application-id
in the answer message to be different than the application-id in the
request message without
breaking Diameter.

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

v2.23.0 | Report a Bug | By Email