Re: [Dime] Conclusion for the Report Type

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Mon, 16 December 2013 17:04 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 31B9F1AE09D for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 09:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level:
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 TEQ767Z9sk31 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 09:04:37 -0800 (PST)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 185A11AE08A for <dime@ietf.org>; Mon, 16 Dec 2013 09:04:36 -0800 (PST)
X-AuditID: c1b4fb31-b7fa78e0000005dd-27-52af32a369d4
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BF.EC.01501.3A23FA25; Mon, 16 Dec 2013 18:04:35 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 18:04:25 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>, "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZBkR5KHZ79W0mkFVMNJsC5E5pXFi8A
Date: Mon, 16 Dec 2013 17:04:25 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
In-Reply-To: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre5io/VBBge3mVrM7V3BZrF/XQOT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXRPXcDU8EB/orWixINjNN5uhg5OSQETCTa fi5nhrDFJC7cW8/WxcjFISRwglFiTedDJpCEkMBiRomns8xAbDYBO4lLp1+AxUUEgiUWbm8F aubgEBYwkuhbWwwRNpaYeuUZG4RtJPF/7gywchYBVYkdaxeA7eIV8JVYt/ol1K4mRokbZ++z giQ4BWwlGle9BrMZgQ76fmoNWDOzgLjErSfzmSAOFZBYsuc81NGiEi8f/2OFsJUkGpc8YYWo 15FYsPsTG4StLbFs4WuoxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbJ4tTipNx0I0O9 3PTcEr3Uoszk4uL8PL3i1E2MwGg5uOW34Q7GidfsDzFKc7AoifMyTO8MEhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAobXt+sdOkFc+ro63D9x3/l/Lfc2ZX+sToOO7AbA7mNOF9J+xKDzE5 XahvTtgjZ8J3Mchzl32szEHZOAMO06u3p59euNzfoj9j0Vm+DRwXljLcqAroU9ZLCPYX4FUv Or7oU6L7woKPhjudI1efbNWwT1m3+Db3Wl8m9QNrc/7OfZvz3Dp92XYlluKMREMt5qLiRAA0 FrhEZAIAAA==
Subject: Re: [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, 16 Dec 2013 17:04:43 -0000

Hello,

I agree on the principles.
Enumerated is fine for me as well.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 09 de diciembre de 2013 13:00
To: dime@ietf.org list
Subject: [Dime] Conclusion for the Report Type

Folks,

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
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime