IETF Logo Mail Archive

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

Ben Campbell <ben@nostrum.com> Mon, 24 February 2014 18:08 UTC

Return-Path: <ben@nostrum.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 8FB781A0175 for <dime@ietfa.amsl.com>; Mon, 24 Feb 2014 10:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.216
X-Spam-Level:
X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 uQ6LbgTQJXoC for <dime@ietfa.amsl.com>; Mon, 24 Feb 2014 10:08:53 -0800 (PST)
Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id E82BD1A00F2 for <dime@ietf.org>; Mon, 24 Feb 2014 10:08:52 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1OI8nqv042855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 12:08:51 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <530B7D62.1080700@usdonovans.com>
Date: Mon, 24 Feb 2014 12:08:48 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EE0179F-5A98-4471-9B53-A728C131AACC@nostrum.com>
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>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vpBRKIJzdvgIh2NCiOYYoJBa9gk
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: Mon, 24 Feb 2014 18:08:54 -0000

On Feb 24, 2014, at 11:12 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

>> 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.


Okay, does that imply an argument for actual timestamps? :-) 

Or a way to make sure the timestamp is scoped to the reporting node?  Do we need to be unique across just time, or time and space?

v2.23.0 | Report a Bug | By Email