IETF Logo Mail Archive

Re: [Dime] Conclusion for the Report Type

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Mon, 16 December 2013 17:53 UTC

Return-Path: <jean-jacques.trottin@alcatel-lucent.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 0AD111AE0C3 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 09:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 eYa8UHglTe-r for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 09:52:58 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EECF21ADF9B for <dime@ietf.org>; Mon, 16 Dec 2013 09:52:57 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBGHqtVM005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Mon, 16 Dec 2013 11:52:56 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBGHqsFG009208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Mon, 16 Dec 2013 18:52:54 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 18:52:54 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZTfmjwZl8bgUqgMbcmsBQ2dppXB06AgAAcu4A=
Date: Mon, 16 Dec 2013 17:52:54 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D201CB57C1@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com> <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
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:53:00 -0000

Hi 

About Enumerated versus unsigned (flag vector), Lionel is in favour of using unsigned (flag vector) due to the issue  for adding a new emulated value in the future to the existing one, creating backward compatibility. In  3GPP CT4 it is the unsigned (flag vector rule we apply for new AVPs, so I would prefer to be consistent by using the same rule. It would be good to have Lionel's view on this.

Best regards

JJacques 

  

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : lundi 16 décembre 2013 18:04
À : Jouni Korhonen; dime@ietf.org list
Objet : Re: [Dime] Conclusion for the Report Type

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

v2.23.0 | Report a Bug | By Email