Re: [netconf] [core] YANG encoding in CBOR

Carsten Bormann <> Mon, 25 March 2019 06:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F96E120360; Sun, 24 Mar 2019 23:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F3wgb2uN70ua; Sun, 24 Mar 2019 23:23:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4DEE12035F; Sun, 24 Mar 2019 23:23:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 44SPNJ5BnRz10Q6; Mon, 25 Mar 2019 07:23:44 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Mon, 25 Mar 2019 07:23:44 +0100
Cc: Juergen Schoenwaelder <>, "" <>, "" <>
X-Mao-Original-Outgoing-Id: 575187822.01148-4f3da4270b3f661c3b433a83b313ed81
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Andy Bierman <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [netconf] [core] 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: Mon, 25 Mar 2019 06:23:49 -0000

Hi Andy,

> On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann <> wrote:
> On Mar 24, 2019, at 12:29, Andy Bierman <> wrote:
> > 
> > The answer seems to be simple but inefficient:
> > Always encode bits or enumeration as a string, if this is within a union type.
> For enum values within unions (which are already handled specially by giving them a CBOR tag) we could simply use a SID (that we then would have to generate for each enum value) instead of a string.  We could also extend this to enums outside unions; but here the recurrence to the (outside unions unambiguous) value sounds better to me.
> Bits.  Oh.  Same procedure, I’d say.

> On Mar 24, 2019, at 23:52, Andy Bierman <> wrote:
> This seems like it would make the SID file very complicated.

Not necessarily:

> Not sure it would work since leaf/leaf-list can define their own types.
> Plus, all the enum typedefs would have to be numbered this way.

It would amount to defining an identifier scheme for all the so far anonymous enums (and bits defs, I gather).

> Maybe the SID authors can comment on how this would be done.

Well, such an identifier scheme would benefit the whole YANG ecosystem, so you can have a transition from “first match wins” to proper name equivalence.  So we would need to do it in a way that over time it can become part of the core YANG definition.

We can maybe cheat:  Use strings for enums inside unions for now, and values only outside.
But it would be good if the SID files generated (and registered) for a YANG module already had those enum/bits type identifiers so we only have to do the SID generation once, so I’m not sure if I like cheating; doing the SIDs for those identifiers right from the outset would win so much more.

So does anyone have an idea how such an identifier scheme might look like?

Grüße, Carsten