Re: [yang-doctors] guideline for enum and value?

Martin Bjorklund <mbj@tail-f.com> Thu, 25 January 2018 08:59 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6312E870 for <yang-doctors@ietfa.amsl.com>; Thu, 25 Jan 2018 00:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 j5Y5K2KOHKlD for <yang-doctors@ietfa.amsl.com>; Thu, 25 Jan 2018 00:59:24 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0812D868 for <yang-doctors@ietf.org>; Thu, 25 Jan 2018 00:59:24 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id C96461AE0442; Thu, 25 Jan 2018 09:59:22 +0100 (CET)
Date: Thu, 25 Jan 2018 09:59:21 +0100
Message-Id: <20180125.095921.224499312159563778.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: bclaise@cisco.com, yang-doctors@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180125083753.kngg2f3zysxq4qbm@elstar.local>
References: <c3d21c6e-8cc0-e109-4b81-278242d70071@cisco.com> <20180125083753.kngg2f3zysxq4qbm@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/gkSiPXok7rQ5T5w7BogKBpyFqig>
Subject: Re: [yang-doctors] guideline for enum and value?
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 08:59:26 -0000

Hi,

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, Jan 25, 2018 at 09:18:27AM +0100, Benoit Claise wrote:
> > Dear all,
> > 
> > Still busy with the RFC6087bis AD review, reviewing the enum sections now.
> > 
> > Do I recall correctly a guideline about not using "value" in enum?

I think this was a discussion on YANG 1.1, not 6087bis (but I might be
wrong).

> > Something to be inserted in RFC6087bis? At least a pros and cons discussion?
> >
> 
> I would rather say the opposite:
> 
>   YANG automatically assigns numeric values to enums if no values are
>   specified. This automatic assignment requires that (a) the order of
>   enums never changes and (b) additional enums are only appended but
>   never prepended or inserted. This is subtle and using explicit value
>   assignments, though more verbose, tends to be more robust when
>   modules are revised.

Is this a recommendation to always use the "value" statement?  I don't
think now is the right time to add such an recommendation, and I don't
think it should be recommended.  Maybe we could say something about
taking care when adding an enum, but RFC 7950, section 11, bullet 1
already says that value must not change, so we would essentially just
say that you must follow the rules of 7950.


/martin


> 
> Background:
> 
> Note that NETCONF and RESTCONF do not send the numeric values due to
> the way the XML and JSON encodings are defined. But this may be
> different for other encodings, the proposed CBOR encoding uses the
> numeric value. Some implementations do support mappings to protocols
> such as SNMP where numeric values are used.
> 
> We had a longer discussion about this when we talked about how we deal
> with timezones, which change regularly and have no natural numeric
> value. Algorithms to produce YANG enumerations from the timezone
> databases are difficult if you want to have stable numeric values.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>