Re: [netconf] YANG encoding in CBOR

Michel Veillette <> Thu, 28 March 2019 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C4A31202F5; Thu, 28 Mar 2019 11:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wk2jUkp1wasF; Thu, 28 Mar 2019 11:01:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96F701202EF; Thu, 28 Mar 2019 11:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUAuzwptZV5dJJG9g+pczbGz6Ee9Jayv+Wn9LfvXOSk=; b=Xdn5vVkw3pf3y8bdvD1zj4L1xboxv7tOYKSdLDBsEPG3DsDsr9jn1QqrTARIYLH8Rkn+w9u81d1jpE+diDWjTQDl1DVJw6HN2Tg7WYDCIT5UVqBxk+iordkPS7/4Dl9z/ufNAZ2H95C1fT64nXQtsLq5HSTC7Jdz2LesYCU+AHg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.19; Thu, 28 Mar 2019 18:01:36 +0000
Received: from ([fe80::6d4a:3963:7ffb:1f30]) by ([fe80::6d4a:3963:7ffb:1f30%2]) with mapi id 15.20.1750.017; Thu, 28 Mar 2019 18:01:36 +0000
From: Michel Veillette <>
To: Andy Bierman <>
CC: Carsten Bormann <>, Juergen Schoenwaelder <>, "" <>, "" <>
Thread-Topic: [netconf] YANG encoding in CBOR
Date: Thu, 28 Mar 2019 18:01:36 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-CA, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d44db18a-4070-489f-bbdb-08d6b3a76b87
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4227;
x-ms-traffictypediagnostic: BL0PR06MB4227:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(346002)(136003)(39850400004)(199004)(189003)(13464003)(476003)(2906002)(33656002)(106356001)(105586002)(486006)(8676002)(6306002)(97736004)(66066001)(54896002)(4326008)(229853002)(790700001)(6116002)(6916009)(81166006)(68736007)(11346002)(81156014)(3846002)(6436002)(25786009)(8936002)(446003)(9686003)(72206003)(966005)(478600001)(7736002)(55016002)(236005)(606006)(74316002)(53936002)(14454004)(6246003)(6506007)(26005)(53546011)(316002)(76176011)(186003)(256004)(102836004)(5660300002)(52536014)(71200400001)(71190400001)(86362001)(7696005)(93886005)(99286004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4227;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: xyE/QQ7MRYT7GajVUnCn23nEcbgARMAqPQJpsxfOo30zwI190N2yJwBXwOl+PTT4tukj45aQ8bZ58UR15Ee/lFaElFy9l70PkC6G0cdoSgh+A+SbnOOoSqRPk8vmE8aNTiGU6ZtzGKaZlAslEjO7qeg+m5x1ZRhNxHnHDpkrXBAawsGc6r9Q0EfG0AJJNMIm3WfiZVAIGmCaSTKCYW5R16TRMWay7FxX1ocvVZeg5dqoSnrHX+6FiWtNP34RH0+Q7wfEAFVKRFKPREzNnVxUCnjVy6NdeksMlPBp7p4ffldqtOezcB/PDTvjLelj3QsEvX9aeNeXNyOPGAyM/q2BfXhHmlmFWfWIvaxQU0NB7SpyXGgzkRTKT0CM6/OVR6FMOeIl7LbJ7FSr39gQLaZo2dPtO/p3eRc4SUKi7WpUDFQ=
Content-Type: multipart/alternative; boundary="_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d44db18a-4070-489f-bbdb-08d6b3a76b87
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 18:01:36.0899 (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: BL0PR06MB4227
Archived-At: <>
Subject: Re: [netconf] YANG encoding in CBOR
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Mar 2019 18:01:45 -0000

Hi Andy

The current discussion on 'union' don't help reducing the size and complexity of some of the 'ietf-inet-types' types such as:
typedef ip-address
typedef ipv4-address
typedef ipv6-address
typedef ip-address-no-zone
typedef ipv4-address-no-zone
typedef ipv6-address-no-zone
typedef ip-prefix
typedef ipv4-prefix

Or some of the 'ietf-yang-types' types such as:
typedef date-and-time
typedef timestamp
typedef phys-address
typedef mac-address
typedef hex-string
typedef uuid
typedef dotted-quad

The simples way to address those is to create a new version of these YANG modules by adding a binary option using a union.
I hope this can eventually happen when the CBOR encoding get more popular.


From: Andy Bierman <>
Sent: Thursday, March 28, 2019 11:51 AM
To: Michel Veillette <>
Cc: Carsten Bormann <>rg>; Juergen Schoenwaelder <>de>;;
Subject: Re: [netconf] YANG encoding in CBOR

On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette <<>> wrote:
+1 for value outside, string inside union

This is simple, but I was trying to support some very common types (like ip-address)
that are unions of strings, and are desirable to send as binary instead of string representation.


My rational:

- SID can have up to 8 bytes and will provide a marginal compression.
- Generating SID for all 'enumeration' and 'bits' in case they are used in 'union' is lot of overhead to revolve a corner case.
- YANG also support the 'choice' statement (<>) which is similar to
   the concept of type tagging within union. This construct can be used by YANG modules specifically created for
  embedded applications to take advantage of 'enumeration' encoded as value and 'bits' encoded as bit.


-----Original Message-----
From: Carsten Bormann <<>>
Sent: Thursday, March 28, 2019 9:47 AM
To: Juergen Schoenwaelder <<>>
Cc: Michel Veillette <<>>; Ladislav Lhotka <<>>;<>;<>
Subject: Re: [netconf] YANG encoding in CBOR

So for enum/bits we are back to value outside, string inside union?
Can we use SIDs instead of the strings for the latter?
This can’t be much more complicated than assigning a SID to each string that occurs in an enum/bits in a union.

Grüße, Carsten

netconf mailing list<><>