IETF Logo Mail Archive

Re: [Dime] DOIC: Self-Contained OLRs

Steve Donovan <srdonovan@usdonovans.com> Mon, 16 December 2013 22:02 UTC

Return-Path: <srdonovan@usdonovans.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 CDEE61A1F02 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 14:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 0n-DNm-AFNvB for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 14:02:23 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 43DCA1A1DBD for <dime@ietf.org>; Mon, 16 Dec 2013 14:02:23 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63397 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <srdonovan@usdonovans.com>) id 1VsgF2-0008Ha-O1; Mon, 16 Dec 2013 14:02:21 -0800
Message-ID: <52AF786B.30100@usdonovans.com>
Date: Mon, 16 Dec 2013 16:02:19 -0600
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <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> <8933972A-65A8-4EBC-8FAA-7DC64EEE808A@nostrum.com>
In-Reply-To: <8933972A-65A8-4EBC-8FAA-7DC64EEE808A@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 22:02:23 -0000

On 12/16/13 3:34 PM, Ben Campbell wrote:
> 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.)
>
I agree that it SHOULD, I don't see how we can make it a MUST.
>

v2.23.0 | Report a Bug | By Email