IETF Logo Mail Archive

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

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 26 February 2014 15:19 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 11ECF1A0097 for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:19:07 -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 YV2p8TmiLjeb for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:19:04 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 641931A0660 for <dime@ietf.org>; Wed, 26 Feb 2014 07:19:02 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QFIx13031303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 16:18:59 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QFIx6N029073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 16:18:59 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 16:18:59 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 16:18:59 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPLKfaNBG2qkbh0kelPIaMQYlrnZq6+hlQgAmztBKAAvg4YP//+vqAgAARmAA=
Date: Wed, 26 Feb 2014 15:18:58 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B4AAB@DEMUMBX014.nsn-intra.net>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026644D6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <D2D4DD91-8F3D-4C24-9E3A-E2AE3918D468@gmail.com> <52FCBBF7.7000700@usdonovans.com> <D4BE67F7-6D7B-4DB2-8DF0-D430A8FC6582@nostrum.com> <5302351F.6050902@usdonovans.com> <E194C2E18676714DACA9C3A2516265D2026697DE@FR712WXCHMBA12.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum! .com> <530B7D62.1080700@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net> <07D74432-AB28-43BB-9C54-EA091D647250@nostrum.com>
In-Reply-To: <07D74432-AB28-43BB-9C54-EA091D647250@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.116]
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: 2321
X-purgate-ID: 151667::1393427940-00003660-92E82A4D/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dgtn3UX6W7kJlb58wbWzNSFmgrI
Cc: "dime@ietf.org" <dime@ietf.org>
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: Wed, 26 Feb 2014 15:19:07 -0000

#34 	Semantics of OC-Report-Type AVP	Resolved	Agreed - Replace text in section 4.6 with text proposed in the ticket.

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, February 26, 2014 4:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Given the further discussion, what is the currently proposed conclusion?

On Feb 26, 2014, at 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Ben, Steve, all
>  
> I still think we can conclude on #34.
>  
> The issue here is independent and is valid for both realm-routed-request reports and realm reports (should we ever agree on them, see #55).  I shall open a new ticket on Multiple Reporting Nodes reporting realm-routed-request reports for the same realm.
>  
> Ulrich
>  
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
> Sent: Monday, February 24, 2014 6:12 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>  
> Ben,
> 
> One comment below.
> 
> Steve
> 
> On 2/20/14 5:16 PM, Ben Campbell wrote:
>  
> On Feb 18, 2014, at 8:54 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>  
> - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.
>  
> I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.
> SRD> The reason for this requirement is to handle the likelihood that each reporting node of the new realm report type will have independent sequence numbers.  Thus, as long as all reporting nodes report all updates to the realm overload status, it should be sufficient for a reacting node to only listen to one of the reporting nodes when determining if the OLR is new.
> 
>  
>  
>  
>

v2.23.0 | Report a Bug | By Email