IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 25 January 2018 10:57 UTC

Return-Path: <acee@cisco.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 67FD612DA05 for <yang-doctors@ietfa.amsl.com>; Thu, 25 Jan 2018 02:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 YdHm-DD3rC91 for <yang-doctors@ietfa.amsl.com>; Thu, 25 Jan 2018 02:57:17 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DCD126CBF for <yang-doctors@ietf.org>; Thu, 25 Jan 2018 02:57:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3100; q=dns/txt; s=iport; t=1516877837; x=1518087437; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=U043Tjmy3zHrpVBYwwKlxGuBWplBMLFmHskNlfKP8DA=; b=Lk+8w+IhGc85jInYNil7YZtwwhZWKLjXrGvJYXRMsoDPpfAIDMUjmGjI 1okUCC/8PBDZK38DSdPYzexv1ejdw0vw7Q8q11LJcPRt9VTGxG8am/pSs FncaYN8qIX89FlTwlFXNUz5SzE0vGWFeCLjjH0V7Zkzq0Dt5xrIukNmNJ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AsAQAst2la/5tdJa1aAxkBAQEBAQEBAQEBAQEHAQEBAQGDQmZ0JweDVookjmiBWyeXQxWCAgoYC4UYAhqEIlQYAQEBAQEBAQECayiFJAEBBAEBIRE6Cw4CAgEIDgIIAgImAgICGQwLFRACBAENBYo1ELR9gieKXgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYEKg0KCFYM/KQyCeYMvAQECgTc4FwomglAxghQgBaQKAowPiVGUJZctAhEZAYE7AR85gVBwFT0qAYF/hFd4jTuBFwEBAQ
X-IronPort-AV: E=Sophos;i="5.46,411,1511827200"; d="scan'208";a="60895498"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 10:57:16 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0PAvGAQ013938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jan 2018 10:57:16 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 25 Jan 2018 05:57:15 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 25 Jan 2018 05:57:15 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Benoit Claise (bclaise)" <bclaise@cisco.com>
CC: YANG Doctors <yang-doctors@ietf.org>
Thread-Topic: [yang-doctors] guideline for enum and value?
Thread-Index: AQHTlbUkzfVXBtKozU2IeKLGGrnAZ6OEl/yA///THIA=
Date: Thu, 25 Jan 2018 10:57:15 +0000
Message-ID: <03309732-5A6C-4527-A442-99F4DB9AD423@cisco.com>
References: <c3d21c6e-8cc0-e109-4b81-278242d70071@cisco.com> <20180125083753.kngg2f3zysxq4qbm@elstar.local>
In-Reply-To: <20180125083753.kngg2f3zysxq4qbm@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <EDFD0F7CB451234C954545B5152D8EAE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/m5Rlz-Zu3zLMJJ_17uWGZdcLAyY>
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 10:57:19 -0000

I agree with Juergen. I also believe when the enum corresponds to some standard value (e.g., IETF address families), there is significant advantage in preserving that value in the YANG enum. 
Thanks,
Acee 

On 1/25/18, 3:38 AM, "yang-doctors on behalf of Juergen Schoenwaelder" <yang-doctors-bounces@ietf.org on behalf of 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?
    > 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.
    
    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

v2.23.0 | Report a Bug | By Email