Re: [netmod] enumeration type

Jonathan Hansford <Jonathan@hansfords.net> Wed, 22 January 2014 15:16 UTC

Return-Path: <jonathan@hansfords.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25BC1A0102 for <netmod@ietfa.amsl.com>; Wed, 22 Jan 2014 07:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 atJLUM0I9uoE for <netmod@ietfa.amsl.com>; Wed, 22 Jan 2014 07:15:58 -0800 (PST)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 054A31A00CF for <netmod@ietf.org>; Wed, 22 Jan 2014 07:15:57 -0800 (PST)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id H3Fv1n0044CLSd8013FwSA; Wed, 22 Jan 2014 15:15:56 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=LqOrlBtc c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=ymigdH7LP5EA:10 a=0B8HqoTn75oA:10 a=eDuwVpe5h8AA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=valQ_CuEJh4A:10 a=kj9Kw6FvMZAKwy35cuoA:9 a=QEXdDO2ut3YA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 22 Jan 2014 15:15:55 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Jan 2014 15:15:55 +0000
From: Jonathan Hansford <Jonathan@hansfords.net>
To: netmod@ietf.org
In-Reply-To: <20140122123353.GA50544@elstar.local>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <a11dee950d4ca6dddb165597e9e53920@imap.plus.net> <20140122123353.GA50544@elstar.local>
Message-ID: <cdc455f5b62c27d342f7242dc1e78f34@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.152]
Subject: Re: [netmod] enumeration type
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 15:16:00 -0000

On 2014-01-22 12:33, Juergen Schoenwaelder wrote:

> On Wed, Jan 22, 2014 at 10:30:41AM +0000, Jonathan Hansford wrote:
>
>> Can anyone explain why enumerations were originally given values, if
>> they have no intrinsic meaning (other than the fact that calling 
>> them
>> enumerations implies that numbers are involved)?
>
> As far as I recall, they were originally designed this way at the
> Stockholm meeting (that is months before the YANG work came to the
> IETF) in order to support some coexistance with other protocols that
> happen to use numbers instead of strings on the wire for 
> enumerations.

Having looked through some historical documents, it may also have 
arisen from the draft-bjorklund-yang-requirements-00 response ("SMIv2 
style enumerations are fully supported in YANG.") to RFC 3216 "SMIng 
Objectives", section 4.1.17 "Enumerations":

    Type: basic

    From: SMI, SPPI

    Description: SMIng must provide support for enumerations.  
Enumerated
       values must be a part of the enumeration definition.

    Motivation: SMIv2 already has enumerated numbers.

    Notes: Enumerations have the implicit constraint that the attribute
       is constrained to the values for the enumeration.

>
> Looking at it from today's perspective, I tend to believe the
> automatic assignment of values was not a very smart choice (since
> using it is very dangerous when it comes to updates) and in hindsight
> it might have been better to allow values as an optional feature of 
> an
> enum that YANG data model designers can use but are not required to
> use.
>
> /js
>
> PS: I do feel somewhat guilty for this design but I am not sure who
> actually had this automated numbering idea and it probably does
> not matter. Back in London, I started coding what several years
> later became RFC 6643, but for that I did not need automated
> numbering.