IETF Logo Mail Archive

Re: [Dime] DOIC: Self-Contained OLRs

Ben Campbell <ben@nostrum.com> Mon, 16 December 2013 21:35 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 998531ADED5 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 13:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 LpoC68Vsm4sV for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 13:35:04 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C45071ADE84 for <dime@ietf.org>; Mon, 16 Dec 2013 13:35:04 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLZ0Am096847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:35:01 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <52AF264E.9070304@usdonovans.com>
Date: Mon, 16 Dec 2013 15:34:54 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <8933972A-65A8-4EBC-8FAA-7DC64EEE808A@nostrum.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se> <D3716AC2-10E5-4E7C-95A1-87BCAA88CFE9@gmail.com> <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com> <E194C2E18676714DACA9C3A2516265D201CB4AA4@FR712WXCHMBA12.zeu.alcatel-lucent.com> <52A86663.30500@usdonovans.com> <E194C2E18676714DACA9C3A2516265D201CB4BC7@FR712WXCHMBA12.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D31B94@xmb-rcd-x10.cisco.com> <52AEFED7.5060908@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D33C8C@xmb-rcd-x10.cisco.com> <52! AF264E.9070304@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] DOIC: Self-Contained OLRs
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, 16 Dec 2013 21:35:05 -0000

On Dec 16, 2013, at 10:11 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

> There is nothing in the self-contained overload report proposal the requires cross-application data handling.  An implementation can take advantage of cross-application information if it is able and wants to, but it is not required to do so.

I'm not sure I agree on that point. If an endpoint that _supports_ application Y receives a report _about_ application Y, it needs to honor that report regardless of what what application the enclosing Diameter message was tied to. (This is part of why I've commented in the past that I think overload reports are protocol data.)

v2.23.0 | Report a Bug | By Email