IETF Logo Mail Archive

Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

Ben Campbell <ben@nostrum.com> Tue, 03 December 2013 22:05 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 47CBB1AE16B for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 14:05:52 -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 2OlKD8CjPSo0 for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 14:05:51 -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 7A23D1ADD9D for <dime@ietf.org>; Tue, 3 Dec 2013 14:05:51 -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 shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3M5g5T039642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:05:43 -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: <18796_1385626955_5296FD4B_18796_11001_1_6B7134B31289DC4FAF731D844122B36E3071A0@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Tue, 03 Dec 2013 16:05:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <78E23951-EE6E-4295-BBE3-FDC37C5E362D@nostrum.com>
References: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> <4CFE9D80-E25A-4B8F-96D1-EB7C21F2F11A@nostrum.com> <9AC5C876-99AD-4C43-9B13-3288C76459FB@gmail.com> <18796_1385626955_5296FD4B_18796_11001_1_6B7134B31289DC4FAF731D844122B36E3071A0@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: "ext lionel.morand@orange.com" <lionel.morand@orange.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01
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, 03 Dec 2013 22:05:52 -0000

On Nov 28, 2013, at 2:22 AM, lionel.morand@orange.com wrote:

> I could discuss the need for the report type for a longtime...
> But I can live with the following approach:
> 
> - Keep the report type AVP
> - Keep the Report type as optional in the OC-OLR
> - Clarify that the OC-OLR applies to the Origin-Host of the Answer when the report type is absent
> - Multiple OLRs can be found in the answer only if the OLRs have different Report types e.g. response to an initial request (with only dest-Realm AVP) may contain overload status of the node and of the realm
> - Remove "aggregated"
> 
> Is it OK for everyone?

What does it mean for the report type to be optional? More to the point, do we expect all reacting nodes to support ReportType? If not, what behavior do we expect from a node that doesn't understand ReportType, and gets a report that includes it? The answer can't be to ignore the presence of ReportType, because that is likely to cause incorrect action.

v2.23.0 | Report a Bug | By Email