Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP

Ben Campbell <ben@nostrum.com> Tue, 03 December 2013 22:30 UTC

Return-Path: <ben@nostrum.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 80B581AE1A6 for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 14:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 6qum9G2Fxf1Z for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 14:30:42 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 847451ADDA0 for <dime@ietf.org>; Tue, 3 Dec 2013 14:30:42 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3MUbfp040632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:30:38 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Tue, 03 Dec 2013 16:30:37 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D2B4DEE-B8FF-4221-B719-5D8012277AB4@nostrum.com>
References: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: "ext lionel.morand@orange.com" <lionel.morand@orange.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type 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: Tue, 03 Dec 2013 22:30:43 -0000

On Dec 3, 2013, at 11:35 AM, lionel.morand@orange.com wrote:

> Hi,
>  
> The proposed format for OC-Report-Type AVP is Enumerated.
> This would lead to extensibility issue as discussed several times.
>  
> I would propose to define the OC-Report-Type AVP as Unsigned64 and create specific values. The same registry can be used to add values but we would get rid of the problem with Enumerated AVP.
>  
> Comment?
>  

I'm missing something--what's the problem with extending Enumerated AVPs in this context?

I recognize that we don't want new applications to change the set of values in Enumerated AVPs defined by another application. But that's not what we're talking about here. Why couldn't we, for example, create an Enumeration for DOIC that is intended to be extensible, and maybe even has an IANA registry?

(But for the record, I'm fine with Unsigned64).


> Lionel
>  
> _________________________________________________________________________________________________________________________
> 
> 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
> https://www.ietf.org/mailman/listinfo/dime