IETF Logo Mail Archive

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

Jouni Korhonen <jouni.nospam@gmail.com> Wed, 04 December 2013 10:18 UTC

Return-Path: <jouni.nospam@gmail.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 445291AE237 for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 02:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 GzWnp-3js-Au for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 02:18:26 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B9A931AE0EE for <dime@ietf.org>; Wed, 4 Dec 2013 02:18:19 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id eo20so9634823lab.14 for <dime@ietf.org>; Wed, 04 Dec 2013 02:18:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cGEXHu77TlyfQI39xfK/no/8O6yKnBls2e2jHqIPKDQ=; b=AlxgXAgOBcLMl2IcFykyRnF4nc2j9TZyvaUqS6uHBU7AjCOAux9G6Z/MqWeFeuYTGq RgG0qJkrNyBobMA9eMp4IdIyhpEd/bxmHfzfoHgDevfvciuabh4KzHfnLV2QINV6zwTy ApaJmq6DDLIjBdouJIjfkb/5Eg6y8EpDOIFYnV8Xg/RxYl7v88YESqBW1bDlWGo2IZLD HftJ7dXcMYyeN5+tS2ujzNdcNaCi2/yNV6TCbAY6hohuB1N09oj8z9kDRRVaQ++1DHTO JmemNzi0xQHdt18xAkvw8VTU1EY+qbkJCd/0MKR+DUGsrQ5bQb5AIdEVgt3Qnjr/YzYy qxpw==
X-Received: by 10.112.199.225 with SMTP id jn1mr465562lbc.49.1386152296043; Wed, 04 Dec 2013 02:18:16 -0800 (PST)
Received: from [192.168.250.212] ([194.100.71.98]) by mx.google.com with ESMTPSA id n13sm24582052lbl.17.2013.12.04.02.18.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 02:18:14 -0800 (PST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <78E23951-EE6E-4295-BBE3-FDC37C5E362D@nostrum.com>
Date: Wed, 04 Dec 2013 12:18:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFC06DA8-F85E-4C45-BB5B-B0E6E5668B73@gmail.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> <78E23951-EE6E-4295-BBE3-FDC37C5E362D@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1510)
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: Wed, 04 Dec 2013 10:18:37 -0000

On Dec 4, 2013, at 12:05 AM, Ben Campbell <ben@nostrum.com> wrote:

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

I defined a while back a default value for the
OC-Report-Type. In the absence of the AVP, the
default applies.

- JOuni


> 
>

v2.23.0 | Report a Bug | By Email