Re: [core] Comments on draft-ietf-core-yang-cbor-00

Carsten Bormann <cabo@tzi.org> Tue, 24 May 2016 19:03 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F54912D1CA for <core@ietfa.amsl.com>; Tue, 24 May 2016 12:03:27 -0700 (PDT)
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 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 PLtw3lUXGRRo for <core@ietfa.amsl.com>; Tue, 24 May 2016 12:03:26 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F8912D099 for <core@ietf.org>; Tue, 24 May 2016 12:03:25 -0700 (PDT)
Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C97C51720CE; Tue, 24 May 2016 21:03:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id wmb9svr-9EcQ; Tue, 24 May 2016 21:03:21 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 534AB1720BA; Tue, 24 May 2016 21:03:21 +0200 (CEST)
Message-ID: <5744A576.2010507@tzi.org>
Date: Tue, 24 May 2016 21:03:18 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
References: <CABCOCHRRACvVXx2S_hZm2TxbvP48aO4Q4REkh0LFjmHkMkZ1Vg@mail.gmail.com> <m2y473svm0.fsf@nic.cz> <57401CC2.2040002@tzi.org> <CABCOCHTSNZqB_rCZP0_R5-1iatTuvfH0Kfa4UK6kO+o+M810_w@mail.gmail.com> <BLUPR06MB1763658FF97E46F2DDC29079FE4F0@BLUPR06MB1763.namprd06.prod.outlook.com> <57449D68.5060003@tzi.org>
In-Reply-To: <57449D68.5060003@tzi.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/4sytS3DswoMLUeUUCs8g25TKlYQ>
Cc: Core <core@ietf.org>
Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 19:03:27 -0000

Here is a nice example of a union that is actually a union in the
set-theoretic sense:

  typedef security-model {
    type union {
      type enumeration {
        enum v1  { value 1; }
        enum v2c { value 2; }
        enum usm { value 3; }
        enum tsm { value 4; }
      }
      type int32 {
        range "1..2147483647";
      }
    }
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }


(ietf-snmp-common.yang from https://github.com/YangModels/yang)

Note that there is no intention to actually allow a value of 1 to 4 for
the int32 arm.

This is an example of a general pattern that we see in data modeling
languages where the model both tries to define the generic set of values
(positive int32 here) and specific allocations within that set.
(CDDL has .within for this purpose.)

Here it would not be useful to tag the enumeration specially, as all
positive int32 values are intended to be allowed; it is just that four
of those values have a meaning defined in this specification.  If that
specification evolves, we might add more such values in the enumeration,
changing the tag for those with respect to implementations that
previously already have used that value without the specification having
specifically called it out.  Ouch.

(There are 219 occurrences of "type union" in that repo; most of these
are just DRY violations though.)

Grüße, Carsten