Re: [netconf] YANG encoding in CBOR

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 28 March 2019 11:31 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 2D295120495; Thu, 28 Mar 2019 04:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rJxszafERvZG; Thu, 28 Mar 2019 04:31:27 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0861206AB; Thu, 28 Mar 2019 04:30:24 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 80A7DB23; Thu, 28 Mar 2019 12:30:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Q85Wbd4PVdug; Thu, 28 Mar 2019 12:30:21 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 12:30:21 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 689EF200A8; Thu, 28 Mar 2019 12:30:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id yvUdl8jHnP1E; Thu, 28 Mar 2019 12:30:20 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 293A4200A7; Thu, 28 Mar 2019 12:30:20 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 12:30:19 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 14C283007A0795; Thu, 28 Mar 2019 12:30:18 +0100 (CET)
Date: Thu, 28 Mar 2019 12:30:18 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Michel Veillette <Michel.Veillette@trilliant.com>
CC: Ladislav Lhotka <lhotka@nic.cz>, Carsten Bormann <cabo@tzi.org>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
Message-ID: <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Michel Veillette <Michel.Veillette@trilliant.com>, Ladislav Lhotka <lhotka@nic.cz>, Carsten Bormann <cabo@tzi.org>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <BL0PR06MB5042823429DB7CDA0F33408B9A430@BL0PR06MB5042.namprd06.prod.outlook.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <BL0PR06MB5042C9AA6B4A0CCD913F50D89A580@BL0PR06MB5042.namprd06.prod.outlook.com> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <BL0PR06MB5042C28B79FF95078C8A881F9A580@BL0PR06MB5042.namprd06.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <BL0PR06MB5042C28B79FF95078C8A881F9A580@BL0PR06MB5042.namprd06.prod.outlook.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sP1zPyJ6fI_8V3dFSJuhXK95djQ>
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: Thu, 28 Mar 2019 11:31:41 -0000

Michel,

I think the YANG part of the problem needs to be resolved as part of
the yang next effort. We now have an issue for it so this will not get
lost. YANG extensions have their limits; you can not expect that
client and server both understand an extension and hence it is a
stretch to make the encoding of data depending on tags provided by
extensions. So what we need is:

a) A CBOR encoding that works with the current YANG rules (even if it
   may be less efficient CBOR).
b) Work on a general solution for tagged unions as part of the YANG
   next effort.
c) Eventually update the XML,JSON,CBOR encodings such that tagged
   unions are handled properly.

Assuming you won't be willing to wait for b), you have to define
something that works reasonably with YANG 1.1 (task a) and get
prepared to update the CBOR encoding when the YANG next effort has
settled on a solution (task c).

/js

On Wed, Mar 27, 2019 at 04:00:42PM +0000, Michel Veillette wrote:
> Hi Juergen
> 
> You will find in attachment the updated version of 'test-union@2019-03-25.yang'; based on your proposed solution, type tagging.
> This module defines an extension called union-tag as follow:
> 
>   extension union-tag {
>     argument tag {
>       yin-element true;
>     }
>     description
>       "In some cases, the interpretation of a value of a union type can differ
>       when encoded using the different data format. This difference comes from
>       the level of type information supported by the different data formats.
>       In the case of XML, all elements and attributes are encoded as string
>       and no type information are included. JSON supports string, number and
>       boolean. Finally, CBOR supports all YANG basic types.
> 
>       This extension can be used to add a tag to a type within a union to
>       guarantee its proper interpretation when decoded.";
>   }
> 
> This extension can be used as follow:
> 
>   leaf multiple-enumerations-test-2 {
>     type union {
>       type enumeration {
>         ext:union-tag weekdays;
>         enum "Monday";
>         enum "Tuesday";
>         enum "Wednesday";
>         enum "Thursday";
>         enum "Friday";
>       }
>       type enumeration {
>         ext:union-tag weekend;
>         enum "Saturday";
>         enum "Sunday";
>       }
>     }
>   }
> 
> If I assume this solution or similar solution is implemented, the next question is how this tag is encoded in CBOR.
> Let assume that the data node SID is 1820 and the SID assigned to "weekdays" tag is  1821.
> 
> When set to "Tuesday", this data node can be encoded using a CBOR map as follows:
> 
> {
>    1820 : { "weekdays", 1}
> }
> 
> Do we need to add a CBOR tag to this encoding to specify the use of a union tag? (99 in this example)
> I personally don't think so since the use of a CBOR map for a union data node is not currently possible.
> 
> {
>    1820 : (99) { "weekdays", 1}
> }
> 
> Should we use a SID instead of the tag? 
> 
> {
>    1820 : { 1821, 1}
> }
> 
> Should we use a delta between the data node SID and the union tag SID?
> The drawback of this approach is that the same value assigned to different data nodes is encoded differently.
> I won't personally recommend this approach.
> 
> {
>    1820 : { 1, 1}
> }
> 
> I hope this email will help moving the discussion closer to the final solution.
> 
> Please comments
> Michel
> 
> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; 
> Sent: Wednesday, March 27, 2019 2:17 AM
> To: Michel Veillette <Michel.Veillette@trilliant.com>;
> Cc: Ladislav Lhotka <lhotka@nic.cz>;; Carsten Bormann <cabo@tzi.org>;; netconf@ietf.org; core@ietf.org
> Subject: Re: [netconf] YANG encoding in CBOR
> 
> Hi,
> 
> a union can be formed by using member types that are imported and not under change control of a single author/organization and ideally this should work without complex coordination of name and number spaces.
> Duplicate enum/bits values are legal in YANG today so an encoding has to deal with this aspect of life.
> 
> A robust fix to all these problems will be to tag the type members in order to discriminate the values in the encodings. This, however, will take some time to specify and we will need to preserve backwards compatibility with unions without a tag (but compilers can encourage people to add tags whenever modules are updated).
> 
> /js
> 
> On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote:
> > Hi Ladislav
> > 
> > If I summarize this issue of multiple enumerations or bits in a union, this problem can be solve by the following approaches:
> > 
> > - To not allows these duplicate values or positions to happen in YANG
> > - To encode enumerations and bits as string (in all unions or only 
> > when multiple enumerations or bits are defined)
> > - To encode enumerations and bits as SID (in all unions or only when 
> > multiple enumerations or bits are defined)
> > - To encode enumerations and bits as delta between the value SID and 
> > the leaf SID (in all unions or only when multiple enumerations or bits 
> > are defined)
> > 
> > In this email, I will like to focus on the first option, fixing the problem directly in YANG instead of fixing the consequences.
> > 
> > Without any changes in YANG, a union with multiple enumeration or bits can be constructed without value or position overlaps.
> > For example:
> > 
> >   leaf multiple-enumerations-test-1 {
> >     type union {
> >       type enumeration {
> >         enum "Monday" { value 0; }
> >         enum "Tuesday" { value 1; }
> >         enum "Wednesday" { value 2; }
> >         enum "Thursday" { value 3; }
> >         enum "Friday" { value 4; }
> > 
> >       }
> >       type enumeration {
> >         enum "Saturday" { value 5; }
> >         enum "Sunday" { value 6; }
> >       }
> >     }
> >   }
> > 
> >   leaf multiple-bits-test-1 {
> >     type union {
> >       type bits {
> >         bit  "Monday" { position  0; }
> >         bit "Tuesday" { position  1; }
> >         bit "Wednesday" { position  2; }
> >         bit "Thursday" { position  3; }
> >         bit "Friday" { position  4; }
> > 
> >       }
> >       type bits {
> >         bit "Saturday" { position 5; }
> >         bit "Sunday" { position 6; }
> >       }
> >     }
> >   }
> > 
> > When using already defined typedef, avoiding overlap is less obvious without some help.
> > To help building unions with already defined typedefs, I propose to introduce two extensions. 
> > 
> >   extension value-offset {
> >     argument offset {
> >       yin-element true;
> >     }
> >     description
> >       "Offset added to each enum value of the associated enumeration.";
> >   }
> >   
> >   extension position-offset {
> >     argument offset {
> >       yin-element true;
> >     }
> >     description
> >       "Offset value added to each bit position of the associated bits.";
> >   }
> > 
> > The value-offset extension can be used as follow:
> > 
> >     type enumeration {
> >       enum "Monday";
> >       enum "Tuesday";
> >       enum "Wednesday";
> >       enum "Thursday";
> >       enum "Friday";
> >     }
> >   }
> > 
> >   typedef weekend {
> >     type enumeration {
> >       enum "Saturday";
> >       enum "Sunday";
> >     }
> >   }
> >   
> >   leaf multiple-enumerations-test-3 {
> >     type union {
> >       type weekdays;
> >       type weekend {
> >         ext:value-offset 5;
> >       }
> >     }
> >   }
> > 
> > The position-offset extension can be used as follow:
> > 
> >   typedef weekdays-flags {
> >     type bits {
> >       bit "Monday";
> >       bit "Tuesday";
> >       bit "Wednesday";
> >       bit "Thursday";
> >       bit "Friday";
> >     }
> >   }
> > 
> >   typedef weekend-flags {
> >     type bits {
> >       bit "Saturday";
> >       bit "Sunday";
> >     }
> >   }
> >   
> >   leaf multiple-bits-test-3 {
> >     type union {
> >       type weekdays-flags;
> >       type weekend-flags {
> >         ext:position-offset 5;
> >       }
> >     }
> >   }
> > 
> > The yang file in attachment show different examples based on this approach.
> > This module have been validated using 
> > https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.y
> > angvalidator.com%2Fvalidator&amp;data=02%7C01%7C%7Cc69426dcaaf8448e1d4
> > 708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C63689264207
> > 3257660&amp;sdata=Xqo40lzBjINVFZhIZZI1LEktAdq5mee2AdxeYqefnsA%3D&amp;r
> > eserved=0 If this approach is accepted, tools like pyang should be 
> > updated to produce an error if multiple enumerations or bits are defined with value or position overleaps.
> > 
> > Please comment,
> > Michel
> > 
> > -----Original Message-----
> > From: Ladislav Lhotka <lhotka@nic.cz>;
> > Sent: Monday, March 25, 2019 4:07 AM
> > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;; 
> > Carsten Bormann <cabo@tzi.org>;
> > Cc: Michel Veillette <Michel.Veillette@trilliant.com>;; 
> > netconf@ietf.org; core@ietf.org
> > Subject: Re: [netconf] YANG encoding in CBOR
> > 
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; writes:
> > 
> > > I think we need to look at the whole picture and in which direction 
> > > we want to go. In the longer term, I would prefer a solution where 
> > > the values of a union are discriminated. The current XML encoding 
> > > behaviour of 'first match wins' is fragile (for example, if someone 
> > > adds an enum to a type, the interpretation of data can change).
> > >
> > > Look at this:
> > >
> > > typedef bar {
> > >   type union {
> > >     type enumeration { enum "1"; value 2; enum "2"; value 1; }
> > >     type uint8;
> > >   }
> > > }
> > >
> > > We have some encodings that send the string representations of the 
> > > values and some encodings that prefer to send numeric 
> > > representations where possible. In order to have a robust solution, 
> > > encodings should likely indicate to which type the value belongs.
> > 
> > Perhaps the easiest way would be to use (optional) annotation that specifies, using an ordinal number, which of the member types is used for the particular instance. But since there can be unions inside unions, a list of numbers would be needed in general.
> > 
> > Lada
> > 
> > >
> > > /js
> > >
> > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote:
> > >> Well, if that is a problem, we can go for a longer representation within unions (section 6.12).  Theoretically, we could do that only of there is more than one enum in the union type (so things stay efficient if there is only one), but that might pose difficulties with model evolution.
> > >> 
> > >> Going for a string representation repeats the feature of XML YANG (which was ported over to JSON YANG):
> > >> 
> > >> typedef foo {
> > >>   type union {
> > >>     type enumeration {
> > >>       enum red { value 1; }
> > >>       enum breen { value 2; }
> > >>       enum glue { value 3; }
> > >>     }
> > >>     type enumeration {
> > >>       enum tacks { value 1; }
> > >>       enum nails { value 2; }
> > >>       enum glue { value 3; }
> > >>     }
> > >>   }
> > >> }
> > >> 
> > >> If you use “glue”, you don’t know which of the enumerations are being used.
> > >> 
> > >> Using SIDs, we can do better.
> > >> 
> > >> So what do we have to do to get the SID tool to allocate SIDs for enum values?
> > >> 
> > >> We could then define the CBOR tag for enums in unions to take the usual SID difference (delta relative to the environment, I’d think), not an integer value.
> > >> 
> > >> Several of us are at the hackathon and could make something happen today and tomorrow.
> > >> 
> > >> Grüße, Carsten
> > >> 
> > >> 
> > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) <rwilton@cisco.com>; wrote:
> > >> > 
> > >> > I guess that the concern is that this introduces more variation in how data is interpreted between the different XML/JSON/CBOR encodings.
> > >> > 
> > >> > E.g. if someone switched from XML to CBOR, suddenly the configuration or state data may have a different meaning.
> > >> > 
> > >> > Thanks,
> > >> > Rob
> > >> > 
> > >> > 
> > >> >> -----Original Message-----
> > >> >> From: Carsten Bormann <cabo@tzi.org>;
> > >> >> Sent: 22 March 2019 16:08
> > >> >> To: Michel Veillette <Michel.Veillette@trilliant.com>;
> > >> >> Cc: Rob Wilton (rwilton) <rwilton@cisco.com>;; core@ietf.org; 
> > >> >> netconf@ietf.org
> > >> >> Subject: Re: [netconf] YANG encoding in CBOR
> > >> >> 
> > >> >> On Mar 22, 2019, at 16:45, Michel Veillette 
> > >> >> <Michel.Veillette@trilliant.com>;
> > >> >> 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.)
> > >> >> 
> > >> >> 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.
> > >> >> 
> > >> >> Grüße, Carsten
> > >> > 
> > >> > 
> > >> > 
> > >> 
> > >> _______________________________________________
> > >> netconf mailing list
> > >> netconf@ietf.org
> > >> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > >> ww
> > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=02%7C01%7C%7C343e
> > >> a8
> > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7
> > >> C1
> > >> %7C636890980182553400&amp;sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2
> > >> B0
> > >> kvPZgr4o%3D&amp;reserved=0
> > >
> > > -- 
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&amp;data=02%7C01%7C%7Cc69426dcaaf8448e1d4708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636892642073257660&amp;sdata=RqSYuNplS4kOLU0R3etRzrR%2FU2ccwljkEZkjHHDU1HA%3D&amp;reserved=0>
> > >
> > >
> > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote:
> > >> Well, if that is a problem, we can go for a longer representation within unions (section 6.12).  Theoretically, we could do that only of there is more than one enum in the union type (so things stay efficient if there is only one), but that might pose difficulties with model evolution.
> > >> 
> > >> Going for a string representation repeats the feature of XML YANG (which was ported over to JSON YANG):
> > >> 
> > >> typedef foo {
> > >>   type union {
> > >>     type enumeration {
> > >>       enum red { value 1; }
> > >>       enum breen { value 2; }
> > >>       enum glue { value 3; }
> > >>     }
> > >>     type enumeration {
> > >>       enum tacks { value 1; }
> > >>       enum nails { value 2; }
> > >>       enum glue { value 3; }
> > >>     }
> > >>   }
> > >> }
> > >> 
> > >> If you use “glue”, you don’t know which of the enumerations are being used.
> > >> 
> > >> Using SIDs, we can do better.
> > >> 
> > >> So what do we have to do to get the SID tool to allocate SIDs for enum values?
> > >> 
> > >> We could then define the CBOR tag for enums in unions to take the usual SID difference (delta relative to the environment, I’d think), not an integer value.
> > >> 
> > >> Several of us are at the hackathon and could make something happen today and tomorrow.
> > >> 
> > >> Grüße, Carsten
> > >> 
> > >> 
> > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) <rwilton@cisco.com>; wrote:
> > >> > 
> > >> > I guess that the concern is that this introduces more variation in how data is interpreted between the different XML/JSON/CBOR encodings.
> > >> > 
> > >> > E.g. if someone switched from XML to CBOR, suddenly the configuration or state data may have a different meaning.
> > >> > 
> > >> > Thanks,
> > >> > Rob
> > >> > 
> > >> > 
> > >> >> -----Original Message-----
> > >> >> From: Carsten Bormann <cabo@tzi.org>;
> > >> >> Sent: 22 March 2019 16:08
> > >> >> To: Michel Veillette <Michel.Veillette@trilliant.com>;
> > >> >> Cc: Rob Wilton (rwilton) <rwilton@cisco.com>;; core@ietf.org; 
> > >> >> netconf@ietf.org
> > >> >> Subject: Re: [netconf] YANG encoding in CBOR
> > >> >> 
> > >> >> On Mar 22, 2019, at 16:45, Michel Veillette 
> > >> >> <Michel.Veillette@trilliant.com>;
> > >> >> 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.)
> > >> >> 
> > >> >> 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.
> > >> >> 
> > >> >> Grüße, Carsten
> > >> > 
> > >> > 
> > >> > 
> > >> 
> > >> _______________________________________________
> > >> netconf mailing list
> > >> netconf@ietf.org
> > >> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > >> ww
> > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=02%7C01%7C%7C343e
> > >> a8
> > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7
> > >> C1
> > >> %7C636890980182553400&amp;sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2
> > >> B0
> > >> kvPZgr4o%3D&amp;reserved=0
> > >
> > > -- 
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&amp;data=02%7C01%7C%7Cc69426dcaaf8448e1d4708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636892642073257660&amp;sdata=RqSYuNplS4kOLU0R3etRzrR%2FU2ccwljkEZkjHHDU1HA%3D&amp;reserved=0>
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > netconf@ietf.org
> > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=02%7C01%7C%7C343ea8
> > > d1 
> > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%
> > > 7C 
> > > 636890980182553400&amp;sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kv
> > > PZ
> > > gr4o%3D&amp;reserved=0
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&amp;data=02%7C01%7C%7Cc69426dcaaf8448e1d4708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636892642073267660&amp;sdata=zcQv4hR8ykJFdhvsd2qnTPQ3EPdEZijDc4eT%2BDmsqu0%3D&amp;reserved=0>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>