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

Andy Bierman <> Fri, 22 March 2019 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC877131272 for <>; Fri, 22 Mar 2019 09:38:05 -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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9pFnQJI6nSNi for <>; Fri, 22 Mar 2019 09:38:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A33613126B for <>; Fri, 22 Mar 2019 09:38:02 -0700 (PDT)
Received: by with SMTP id y6so2564819ljd.12 for <>; Fri, 22 Mar 2019 09:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XbV+v0F4IWhHYrZLR1LxIz8hjL3gK1t4DnGZMzQqnlE=; b=ueOc43Hxjwr37UTVgJNCeWc7guqlZN6yFMaho0H5iVHYiX2ghbGZFYQMzYcuwjElha VsX80ebkxAK6Zgc0Vgd08+77JILTBImMHZL75omvo1gHs+SmivWKOldr+ec5j51Ja4HR jO06Pc7gkSRT/8yAxUIjIuxByoxeGoTg1CaPEDk1xPccqX0MpwPjS8OSpXRUgJWtA9cD Va3JWtXYRHMb0Z0FI6adlsphWderhEHHXC4bc6Zn3bC6znFSJVGUw/TkzLK5VGM71/Sv HSPq5KOZ1MnNr+MNs//+tqJCLbjQYOWpTuCnMQNCYc62qyy4d+mzk6BcTPbQS04vpW+d KLfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XbV+v0F4IWhHYrZLR1LxIz8hjL3gK1t4DnGZMzQqnlE=; b=rMTrf8trRJBdyY0nIJlbepGi1WGSzMrE6OcxpQTAWR+uYWHMW1HuOi3l4FQmd+h8og 1UYMhr9oKI36j6+3G29eRvLTehnymRUzItkocy9/00r3xRpYEwu7wydjWZJ6Z/T2qf24 9339HcNbSC7qIGB0AMHLGb5dHIy3xqRbA8oJtvsaLiO25BRUovyQvOVW1ciRgYbUnrnn aEOwXD7bnNY4OBch/HmFnTt+fPkNgm+kqi5Fvt7KSHkR2wxevVv33/bZqeHhyQFMcM5q QW7TscdGsBHlLGgGQ7Ck0BS5vqKRu2IjLxm5bEfPFpkaYUYLg+e08kKfjpP2mZuYu2UT cy4Q==
X-Gm-Message-State: APjAAAVWffN7Rag+QqRCGWP2KqW/qhjCVWOE0UcTXNUiftecuakbmHVe eaoj4z0kHLN29o3PuQ2rCWhFEgYJBJADyIXxB2lTtQ==
X-Google-Smtp-Source: APXvYqzCr9/jMoeCv8dXiX02K4OTjQrk8e/Em+9FLIeQ4jD7B8JMRgFq0F2TAwiXcfObI7b39tyMS9ndwaof6W9vry4=
X-Received: by 2002:a2e:551d:: with SMTP id j29mr3704471ljb.180.1553272680645; Fri, 22 Mar 2019 09:38:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 22 Mar 2019 09:37:49 -0700
Message-ID: <>
To: Carsten Bormann <>
Cc: Michel Veillette <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000005ea0a50584b17ad4"
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: Fri, 22 Mar 2019 16:38:06 -0000

On Fri, Mar 22, 2019 at 9:08 AM Carsten Bormann <> wrote:

> On Mar 22, 2019, at 16:45, Michel Veillette <
>> wrote:
> >
> > 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.
> … and that is not a problem for the XML version, because the string is
> being used instead of the value.  (But then if two enumerations share a
> string, you have the equivalent problem in the XML serialization.)

The union data type has similar issues with JSON encoding, where the JSON
encoding can
influence the YANG decoding. This is not possible with XML since all values
are strings.

Anyway, I haven’t seen a piece of real-world YANG that actually has this
> problem, so I would be a bit reluctant to make CBOR-based implementations
> more complex (and less efficient) so solve this (non-?)problem.
I agree, but tools still need to identify the problem if it exists and flag
the object for different processing
or no processing at all (draft says YANG with these conflicts are not
allowed). IMO a string encoding
should be used.

All YANG union types are position-dependent.
The parser goes through the member types in order, and first one that
accepts the value given wins.
(e.g, ip-address, or any union with 2 of the same base type).

We discussed this issue during the NETMOD WG virtual interim this week, and
wanted clarification
on the scope of the problem. It seems to be limited to just multiple
enumerations in a union.
The rest of the corner-cases are just position-dependent, same as before.

Grüße, Carsten

> _______________________________________________
> core mailing list