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

Michel Veillette <Michel.Veillette@trilliantinc.com> Tue, 24 May 2016 17:02 UTC

Return-Path: <Michel.Veillette@trilliantinc.com>
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 EC0CE12D147 for <core@ietfa.amsl.com>; Tue, 24 May 2016 10:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.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 jUvRXpD3ovaV for <core@ietfa.amsl.com>; Tue, 24 May 2016 10:02:30 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680121.outbound.protection.outlook.com [40.107.68.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992F812D096 for <core@ietf.org>; Tue, 24 May 2016 10:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uOVW+F0CRPdN0uXkUNeekZL8gAZsGcvAzg0D4rNkFVU=; b=Nn1awggzcpR41PuZEFGH68StU/B3OZWpGuo9f0dm4a/Yw+1dJ2Z9twrs8qB7JK8E7v1emVYEb3+8F7Uaz3AA0jv7GnFx+dwCBDZES5h89nNH3oDB5JkQfgbZU+f7UCNSonxZoeF2JBgUSxg/mSIHGKhvJu3MrWWTQqLV7nphgC0=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 24 May 2016 17:02:26 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0497.022; Tue, 24 May 2016 17:02:26 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Andy Bierman <andy@yumaworks.com>, Carsten Bormann <cabo@tzi.org>
Thread-Topic: [core] Comments on draft-ietf-core-yang-cbor-00
Thread-Index: AQHRr8iPxRSRAjhbgEmS2wWjXvPI7Z/DCcOAgAAM3gCAAHTzgIAEndcg
Date: Tue, 24 May 2016 17:02:26 +0000
Message-ID: <BLUPR06MB1763658FF97E46F2DDC29079FE4F0@BLUPR06MB1763.namprd06.prod.outlook.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>
In-Reply-To: <CABCOCHTSNZqB_rCZP0_R5-1iatTuvfH0Kfa4UK6kO+o+M810_w@mail.gmail.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-office365-filtering-correlation-id: 95aca98e-4061-425b-50b7-08d383f52f01
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:NW061VlljrUcZBL+3DAnk5rzYI6lR7FQzAkQ9XhztZMA4IwzRAEMKQ2PQ8BPqUk/BDqhStRucf/jzuXnc+2h2IOdgmPVysgonAwhsklGf3/EYVi4QkXsMDOsOnhxKQWSDRESH0A+FqoR+VkMYWcYFg==; 24:GOnmKtw4fqaEGKfBe68/9d8RbCfoJd5ppyAwql1PtDi3t+qhWJtZR2EQPapPwtZC5KKhab7R+m4s+SeUkCMx/iJNmhm6KcPwBUmqBMnoLDs=; 7:GEEI5VFW22ywysGSfVSxqwxm20n+tXavldK/TXKqO2iRUDy81DfHq6CvylBsnVfsVxQuZ9th4FmEfobf8ukq+kC4bBf4TMxHVgkYCSnJHt6QX+Ixf/1QLTqwBGqUqaBOLZLBIlIhnYElWDQShQqoQELXSonc0tC0kTdrCbjft+fan4/Q858Kzzt56Hxqvbpa
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763;
x-microsoft-antispam-prvs: <BLUPR06MB17632CEE1EEA9A69F13A1394FE4F0@BLUPR06MB1763.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763;
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(87936001)(8676002)(11100500001)(15975445007)(77096005)(81166006)(86362001)(5002640100001)(3660700001)(92566002)(50986999)(6116002)(54356999)(102836003)(586003)(790700001)(3846002)(122556002)(3280700002)(76176999)(5003600100002)(2950100001)(2900100001)(1220700001)(5004730100002)(230783001)(10400500002)(5001770100001)(93886004)(106116001)(76576001)(8936002)(19625215002)(189998001)(33656002)(99286002)(19580405001)(19580395003)(19300405004)(9686002)(16236675004)(4326007)(74316001)(5008740100001)(2906002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1763658FF97E46F2DDC29079FE4F0BLUPR06MB1763namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 17:02:26.3213 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/D0RyzlU93-fO5YYstMU2kTL40kI>
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 17:02:34 -0000

Hi Andy

I propose that we articulate a solution around your proposed solution #3 and #4.

If we implements YANG built-in type tagging (Solution #3), we can remove any ambiguities between the different YANG built-in types introduced by the CBOR encoding.
YANG built-in type tagging is preferred over union member tagging to increase backward compatibility between YANG module revisions.
I propose that the YANG built-in types listed bellow with a * are tagged.

  binary              | major type 2
* bits                | major type 2
  boolean             | major type 7, additional information 20 and 21
* decimal64           | major type 0 and 1
  empty               | major type 7, additional information 22
* enumeration         | major type 0
* identityref         | major type 0 and 1
* instance-identifier | major type 0, 2, 3 or 4
  int8                | major type 0 and 1
  int16               | major type 0 and 1
  int32               | major type 0 and 1
  int64               | major type 0 and 1
  string              | major type 3
  uint8               | major type 0
  uint16              | major type 0
  uint32              | major type 0
  uint64              | major type 0

This proposed CBOR tagging remove any ambiguities between:

·        integer, decimal64, enumerator, identityref and instance-identifier

·        binary, bits and instance-identifier

·        string and instance-identifier

Solution #4 (guidelines) are still needed to address the following issues:

·        evolution of a simple type to a union

o   Not recommended for tagged built-in types (bits, decimal64, enumeration, …) to avoid non backward compatible encoding of older YANG module versions.

·        limitations imposed by the use of multiple union members based on the same built-in type

o   string patterns must be unique

o   integer ranges must be unique

o   enumeration names and values must be unique

o   bits names and positions must be unique

o   multiple instance-identifier are not allowed since uniqueness are not guaranty

Regards,
Michel

From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: May-21-16 11:30 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Core <core@ietf.org>
Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00



On Sat, May 21, 2016 at 1:30 AM, Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:
Ladislav Lhotka wrote:
> The receiving side will resolve the union type by the first union member
> type that matches the CBOR-encoded value. It's the same as in JSON encoding.

Or, at least, similar -- we are not always making the same serialization
decisions.

The weird aspect of this part of YANG is that the actual validity (and
specific semantics and thus usefulness) of a union in the YANG module
depends on the specifics of the serialization below.
More frankly: Tying the semantics of a modeling language to one specific
serialization mechanism is an utterly broken design.
I'm not sure that it can be fixed, though, so we'll likely have to work
around this breakage.

What we were trying to figure out was the extent of the situations where
a YANG module specifier might rely on the XML-specific way of resolving
unions.


I agree YANG is broken is the sense that the union type was not
designed to work if the protocol encoding is not XML.
Since every value node in XML is a string, the sender and
receiver cannot get out of sync wrt/ which member type matches.


This is a legal union type even though in XML type 'int32' would never be used
because 'string' would match everything.

 leaf foo {
   type union {
      type string;
      type int32;
   }
 }

This is a problem for config nodes:
   JSON/CBOR client sets { "foo" : 42 }
   XML client reads back <foo>42</foo>

JSON (and CBOR) will send { "foo":42 }, not { "foo":"42" } if they intend to
send the number, but XML cannot do the same.  There is no problem
unless XML is being used in addition to JSON or CBOR.

Some solution choices:

  1 - do nothing and let XML and JSON/CBOR be broken together
     (solution is do not use XML and JSON/CBOR together in the same server)
  2 - force receiver to convert JSON/CBOR to a string for union type matching
  3 - tag the data somehow so the receiver knows which union member type is being sent
  4 - write YANG guidelines on how to design union types that will produce the same
     match with all encoding schemes

IMO CBOR has to solve the enumeration and bits issues with (3) but
for the problem in general, just do (4)


 Andy


Examples that seem painful:

1)

 type union {
      type enumeration {
         enum one; /* value 0 */
         enum two; /* value 1 */
      }
      type uint32;
 }

Here, the XML will have the string "one" or "two", or a decimal string,
which is unambiguous.  The JSON encoding also has the string for
enumerations, which we obviously want to replace by the numeric value in
a compact encoding.

We were thinking about possibly adding CBOR tags to disambiguate this.
This becomes more insidious if this is an evolution from an earlier
version that just said:

 type enumeration {
   ...
 }

(We wouldn't want to sprinkle in tags just in case a type might possibly
evolve into a union later.)

2)

Also, just having a tag saying "this is an enumeration value" does not
work for this case:

 type union {
      type enumeration {
         enum one; /* value 0 */
         enum two; /* value 1 */
      }
      type enumeration {
         enum alpha; /* value 0 */
         enum beta; /* value 1 */
      }
 }

We haven't found a way yet to tag this case that is robust against
further evolution of the YANG module.

Clearly, YANG module specifiers will not rely on this when they are
cognizant of concise encodings.  However, relying on specification
writers not doing this would mean that YANG modules have to be vetted
for mistakes of this kind before they can be used in a CBOR environment
after an exclusively XML/JSON life.  (Maybe that actually *is* the
answer -- if we could get pyang to detect this case and issue a warning,
that might be enough.)

Grüße, Carsten