Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

<lionel.morand@orange.com> Mon, 24 March 2014 16:51 UTC

Return-Path: <lionel.morand@orange.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 CE0321A01DF for <dime@ietfa.amsl.com>; Mon, 24 Mar 2014 09:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UEAR9dcbsaUR for <dime@ietfa.amsl.com>; Mon, 24 Mar 2014 09:51:05 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 236991A026D for <dime@ietf.org>; Mon, 24 Mar 2014 09:51:04 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7EF6D2AC709; Mon, 24 Mar 2014 17:51:03 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6142338406C; Mon, 24 Mar 2014 17:51:03 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 24 Mar 2014 17:51:03 +0100
From: <lionel.morand@orange.com>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>, "Steve Donovan" <srdonovan@usdonovans.com>, "Shishufeng (Susan)" <susan.shishufeng@huawei.com>, Jouni Korhonen <jouni.nospam@gmail.com>
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRXfTKav1Yd2xqUyLNClmxsrsL5rvj0+AgACNVgCAABf6gIAALFyAgAASFiA=
Date: Mon, 24 Mar 2014 16:51:02 +0000
Message-ID: <8734_1395679863_53306277_8734_13050_1_6B7134B31289DC4FAF731D844122B36E518BC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026649A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <EE7D3FEB-CD2A-45D9-9700-5CCA118D9A14@gmail.com> <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se> <FC3C0F25-F8BE-4B4B-AF30-4CF2029A2520@gmail.com> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com> <A7A9CDB7-9D90-458B-8C24-F0BFF52F897C@gmail.com> <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>, <53302446.9080700@usdonovans.com> <E194C2E18676714DACA9C3A2516265D202672882@FR712WXCHMBA12.zeu.alcatel-lucent.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.6]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E518BC8PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.24.134215
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XKAb1P6H3m_PzpDhXd2-WFpkCw0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 16:51:12 -0000

IMHO it is a lot of fuse for something not so critical!
Session-id is for no use at all in a lot of Diameter applications and no one complains :)

Here it is even simpler: there is a clear use of this AVP. This info (the explicit AVP or the default value) needs to be taken into account in the process of the received OLR and any compliant implementation needs to be able to understand the OLR-Report-Type.
So except "optimization", what is the rational not to make it required in the OLR?

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : lundi 24 mars 2014 17:30
À : ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Steve Donovan; Shishufeng (Susan); Jouni Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

+1

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 2:52 PM
To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi all

I am also in line with the agreement tendency as that OC-Report-Type is not required (so to keep the text as it is in the draft); I expressed this  preference a while ago.


Best regards

JJacques



________________________________
De : DiME [dime-bounces@ietf.org] de la part de Steve Donovan [srdonovan@usdonovans.com]
Date d'envoi : lundi 24 mars 2014 13:25
À : Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org<mailto:dime@ietf.org>
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to make a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com><mailto:srdonovan@usdonovans.com> wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.

This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com><mailto:maria.cruz.bartolome@ericsson.com> wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com><mailto:jouni.nospam@gmail.com> wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com><mailto:jean-jacques.trottin@alcatel-lucent.com> wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com<mailto:lionel.morand@orange.com> Envoyé : mercredi 12 février 2014 15:46 À :

dime@ietf.org<mailto:dime@ietf.org>; maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com> Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::= < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::= < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoyé : mercredi 12 février 2014 15:26 À :

maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com> Cc : dime@ietf.org<mailto:dime@ietf.org> Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com>  |      Owner:  MCruz

  Type:  defect                             |  Bartolomé

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><http://trac.tools.ietf.org/wg/dime/trac/ticket/54>

dime <http://tools.ietf.org/wg/dime/><http://tools.ietf.org/wg/dime/>



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_____________________________________________________________________

____________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime





_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.