[Dime] Conclusion for the Report Type

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 09 December 2013 12:00 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 []) by ietfa.amsl.com (Postfix) with ESMTP id D2E871ADDD1 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 04:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2uAH9MAic3bc for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 04:00:26 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FC1ADF57 for <dime@ietf.org>; Mon, 9 Dec 2013 04:00:24 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id my13so1319634bkb.36 for <dime@ietf.org>; Mon, 09 Dec 2013 04:00:19 -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 :content-transfer-encoding:message-id:references:to; bh=PuacnUZnU2MWxGe5n2GZBAV5ECkG5mfQxkpeo31+FYA=; b=F8CoUe823o/oYgXg/uMxE0mJv85sHnH6cnizZv8eiGNES+p4Vou2HBBD079PIJSLQT oQiVlKJf/FAX0KhUwd0ct0YKlIHhl4wd26dtVfBis6BJNpmwtPm1R53xm4woL1yXIIKy Vn5HjBYnBsw9ClTmORtSz7EkQzxe6tTapKXVPddEmu1p0MK6550dsUBAzYprzN8+x29y iJF/xZbnfKH9Zb+SejNGxASv7EMMNQjQ2HJQiPllDXxYH2EluRlK8dFUycPdgcy9CJoM DbmIEaM3U6Ok9WpSinzydEO9HxgO+n6OY6ybMIbLhrwLKr6kS9NtfjuJdsZhcroPjPSN JGRw==
X-Received: by with SMTP id h9mr663744bko.123.1386590419348; Mon, 09 Dec 2013 04:00:19 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:3c66:e081:e506:53b3? ([2001:1bc8:101:f101:3c66:e081:e506:53b3]) by mx.google.com with ESMTPSA id it12sm8446962bkb.12.2013. for <dime@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 04:00:18 -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: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net>
Date: Mon, 9 Dec 2013 14:00:17 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net>
To: "dime@ietf.org list" <dime@ietf.org>
X-Mailer: Apple Mail (2.1510)
Subject: [Dime] Conclusion for the Report Type
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, 09 Dec 2013 12:00:28 -0000


We need a conclusion here so that I can actually write something
into the -01. How about the following (I try to reflect as many
points given here as possible):

1) The basic principle for the Report Type use is that only one
   OLR per report type is allowed unless the report type and the
   OLR reflecting the new report type define exact semantics how
   to differentiate between multiple OLRs with the same report
   type. In 3GPP context, for example, a report type with an AVP
   that identifies an APN could be such a differentiator.. and that
   would need a new report type where an implementation exactly
   knows to look for this additional AVP without guesswork or 
   fuzzy heuristics.

2) A new report type or a set of new report types require a new
   feature to be allocated/defined so that both endpoints know how
   to handle the new report type that was defined after the
   publication of the baseline specification. The handling of the
   new report types must be defined (along with the new AVPs it
   might need to be included into the OC-OLR AVP).

3) With 2) in place I do not care whether the OC-Report-Type is
   enumerated or unsigned (flag vector?). I still favour Enumerated
   myself as it forces the protocol designer to come up with a 
   cleaner design ;)

4) For the baseline we only define host and realm report types.
   We do not allow multiple OLRs with these report types i.e.
   single instances of OLRs with host and/or realm are allowed.

- Jouni