Re: [netconf] YANG encoding in CBOR

Michel Veillette <Michel.Veillette@trilliant.com> Fri, 22 March 2019 18:34 UTC

Return-Path: <Michel.Veillette@trilliant.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E39131430; Fri, 22 Mar 2019 11:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level:
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NDGIHNZsZS_m; Fri, 22 Mar 2019 11:34:04 -0700 (PDT)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680123.outbound.protection.outlook.com [40.107.68.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1860413142E; Fri, 22 Mar 2019 11:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2I3cDsw5K7wkdV7T5zOjGmfE/lybhT6U1fv4k+FFHns=; b=qmhObOpBhvVF9GYOZBEYOZognvUAGrZPMD4eXQDxG/4Kkqrrp+j44m0RN7qPAPexrJqnhM6uDHuhGSpO9qWzTFPy6LB7f0k/Vi85DvJo8Rctn++4tGVjPF1OdIbl/fk3GlNkjdrvi4YKqhD+IvAVKyZKdPtHHyc/8rHh2VxHNcA=
Received: from DM6PR06MB5049.namprd06.prod.outlook.com (20.176.122.224) by DM6PR06MB5946.namprd06.prod.outlook.com (20.179.163.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Fri, 22 Mar 2019 18:34:00 +0000
Received: from DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::1cf7:3307:9831:558e]) by DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::1cf7:3307:9831:558e%4]) with mapi id 15.20.1709.015; Fri, 22 Mar 2019 18:34:00 +0000
From: Michel Veillette <Michel.Veillette@trilliant.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "core@ietf.org" <core@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: YANG encoding in CBOR
Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAXew9AAAeuD8A==
Date: Fri, 22 Mar 2019 18:34:00 +0000
Message-ID: <DM6PR06MB50497E9F418DF2F9EEA2E5469A430@DM6PR06MB5049.namprd06.prod.outlook.com>
References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <BL0PR06MB5042823429DB7CDA0F33408B9A430@BL0PR06MB5042.namprd06.prod.outlook.com> <edbd00c68ad2440684d61160be263e9c@XCH-RCD-007.cisco.com>
In-Reply-To: <edbd00c68ad2440684d61160be263e9c@XCH-RCD-007.cisco.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com;
x-originating-ip: [207.96.192.122]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 547e9d3f-3261-4656-fede-08d6aef4f3ee
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR06MB5946;
x-ms-traffictypediagnostic: DM6PR06MB5946:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <DM6PR06MB59462A616036BF623813A5FF9A430@DM6PR06MB5946.namprd06.prod.outlook.com>
x-forefront-prvs: 09840A4839
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39830400003)(396003)(366004)(376002)(199004)(189003)(478600001)(6116002)(81156014)(6436002)(6246003)(9686003)(6306002)(54896002)(72206003)(14454004)(229853002)(8676002)(55016002)(7696005)(2501003)(3846002)(99286004)(68736007)(25786009)(5660300002)(966005)(74316002)(236005)(790700001)(105586002)(110136005)(53936002)(8936002)(86362001)(486006)(2906002)(71200400001)(52536014)(11346002)(446003)(106356001)(2201001)(97736004)(7736002)(476003)(71190400001)(3480700005)(26005)(102836004)(6506007)(66066001)(53546011)(81166006)(76176011)(606006)(186003)(33656002)(256004)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR06MB5946; H:DM6PR06MB5049.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: HcLxRl3D0FCsq/IsL7EX4ihOBgQZWyhWODV0EVpXjrQ2q79JkmiWgqq2zeNvhJp3aKYbvKoJHA+NIQJZPRJgqrMAVeoERV3K9Nda94IZSeW6b37h/82u216Eb2J05HtOE03TE4kL0EP9+GNL6cxaMN7Gyb2P9QPmepx9Bjzo0H8Kr35IYyqJQziJRIGRmwzkWvwi1bxLOn8cgWtiHefvMtSC+IZ10dkNckwRhwJ8DwjU5O5N+rVKTxhEPSIgF2I6GYxqRzn5q4CN8wfZh+QN66jqgVgo0evibdK4IV0ehQ+t65IPqul4hVO5AmJAz/M0XOBPf6jkkJTkAi453Sl+hzbEjruriTN9OAQPtVTWvBo+OUB1E5utWGa9R0O4DkiT0Q+tZWBKPxZO3qsJtzsIzYQ8A7G+unX7mUeLk83jYgk=
Content-Type: multipart/alternative; boundary="_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_"
MIME-Version: 1.0
X-OriginatorOrg: Trilliant.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 547e9d3f-3261-4656-fede-08d6aef4f3ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 18:34:00.5221 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5946
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/XCy1B2jAGF38xMXCYUH4faaJwtM>
Subject: Re: [netconf] YANG encoding in CBOR
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2019 18:34:08 -0000

Hi Rob

Any solutions have been discussed or proposed?

Encoding enumerators part of a union as CBOR text string might be the simples solution.
Would you please discuss this proposed solution with any and any other interested parties in Prague.

Regards
Michel

From: Rob Wilton (rwilton) <rwilton@cisco.com>
Sent: Friday, March 22, 2019 1:33 PM
To: Michel Veillette <Michel.Veillette@trilliant.com>; core@ietf.org; netconf@ietf.org
Subject: RE: YANG encoding in CBOR

Hi Michael,

Indeed, it was the encoding of unions containing more than one enum that was the concern raised in the meeting.

Thanks,
Rob


From: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>
Sent: 22 March 2019 15:45
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>; core@ietf.org<mailto:core@ietf.org>; netconf@ietf.org<mailto:netconf@ietf.org>
Subject: RE: YANG encoding in CBOR

Hi Rob

==================================================================
About "I was wondering whether it would be better to encode enum values ..."

YANG assigns either explicitly or implicitly to each enumeration, a unique integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7950%23section-9.6.4.2&data=02%7C01%7C%7C240258b409ab4199aa2608d6aeec637b%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636888727665422412&sdata=Q%2FY2hWDGxB9YnVJRr10eUl1F0PdJAzGC1%2FLZRO0B%2FaI%3D&reserved=0>.
In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.6<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-core-yang-cbor-07%23section-6.6&data=02%7C01%7C%7C240258b409ab4199aa2608d6aeec637b%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636888727665432421&sdata=sej1JrJZGbECXHACilc3fe%2BgMHCIGy4CggCra8LPI5Y%3D&reserved=0>
When used outside of a union, I don't see any issues with those values.
Andy, do you have a specific example for which, the current encoding is ambiguous?

==================================================================
The encoding of union is defined in:
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-core-yang-cbor-07%23section-6.12&data=02%7C01%7C%7C240258b409ab4199aa2608d6aeec637b%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636888727665432421&sdata=AjA49ErkN1IbbIr29dKYPN6oJr%2FbGk12QUP7Nk90W0E%3D&reserved=0>

Currently, each YANG datatype in a union is encoded differently to avoid any ambiguities between  them.
For example, integer 4 is encoded as:

04 # unsigned(4)

enumerator value 4 is encoded as (assuming the allocated tag is 99):

D8 63 # tag(99)
   04 # unsigned(4)

The list of these encoding is shown below:
- unsigned integer --> CBOR unsigned integer
- integer --> CBOR unsigned integer, CBOR negative integer
- enumeration --> CBOR tag <TBD>
- identityref as SID --> CBOR tag <TBD>
- string --> CBOR text string
- identityref as name --> CBOR tag <TBD>
- bits --> CBOR tag <TBD>
- binary --> CBOR byte string
- decimal64 --> CBOR tag 4
- boolean --> CBOR simple value

The only potential problem I aware is when multiple enumerations are part of the same union.
Value 4 from enumeration A will be encoded the same way as Value 4 from enumeration B.

Is it a real problem is real life?
If so, how this can be resolved?

I won't be present at the Prague meeting, but I'm certainly available to discuss this topic by email.
I will be present at the Montreal meeting for any remaining discussions on this draft.

Note: I'm currently updating the draft to remove any dependencies with RFC 7951, to resolve a comment sent by Andy.

Regards
Michel


From: core <core-bounces@ietf.org<mailto:core-bounces@ietf.org>> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org<mailto:core@ietf.org>; netconf@ietf.org<mailto:netconf@ietf.org>
Subject: [core] YANG encoding in CBOR

Hi,

As part of YANG evolution discussion, that was some talk about using a binary encoding of YANG in NETCONF or RESTCONF.

CBOR looks like a good fit for this, and obviously CORE WG are working on draft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBOR encoding of YANG cannot handle all YANG data models.  In particular, because of the way that the encoding works there are limitations on how unions of enums work.  Is that still the case?

Hence I was wondering whether it would be better to encode enum values in CBOR using module-qualified names, or also assign them SIDs and use the SIDs.  Has this approach been considered at all?

Or, is there an alternative approach to how we could/should consider using CBOR as a binary encoding for YANG data in NETCONF or RESTCONF?

Do you think it would be possible to get interested parties together to discuss this at some point in Prague?

Thanks,
Rob