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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 24 March 2019 14:40 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 3EBAC129619; Sun, 24 Mar 2019 07:40:53 -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 1CBn5dZGZMGD; Sun, 24 Mar 2019 07:40:51 -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 6C2C71294B6; Sun, 24 Mar 2019 07:40:51 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DF52D3D; Sun, 24 Mar 2019 15:40:49 +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 WSV4IvdO_E7T; Sun, 24 Mar 2019 15:40:49 +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; Sun, 24 Mar 2019 15:40:49 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C80AB200A7; Sun, 24 Mar 2019 15:40:49 +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 B8S7xlLUImxj; Sun, 24 Mar 2019 15:40:49 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (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 6B02B200A6; Sun, 24 Mar 2019 15:40:49 +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; Sun, 24 Mar 2019 15:40:48 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 8781230077BEFE; Sun, 24 Mar 2019 15:40:48 +0100 (CET)
Date: Sun, 24 Mar 2019 15:40:48 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@yumaworks.com>
CC: Carsten Bormann <cabo@tzi.org>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
Message-ID: <20190324144048.xz3ovvuyqaygoimy@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, 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> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <CABCOCHRcEPUB=Yf2Vdf6ZpN-SxjYeMPL_54-EKMYSpUO9b-RwA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABCOCHRcEPUB=Yf2Vdf6ZpN-SxjYeMPL_54-EKMYSpUO9b-RwA@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) 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/VTLWJWNgpB2DHzCspC_ZA7kblBU>
Subject: Re: [netconf] [core] 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: Sun, 24 Mar 2019 14:40:53 -0000

On Sun, Mar 24, 2019 at 04:29:45AM -0700, Andy Bierman wrote:
> On Sun, Mar 24, 2019 at 2:47 AM Carsten Bormann <cabo@tzi.org>; wrote:
> 
> > On Mar 23, 2019, at 14:35, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de>; wrote:
> > >
> > > RFC 7950 section 9.12:
> >
> > Thank you, this is very useful.
> >
> > Let me try to ask my other question in a very concrete way:
> >
> > If I have
> >
> > > 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; }
> > >    }
> > >  }
> > > }
> >
> > in one place, and
> >
> > > typedef bar {
> > >  type union {
> > >    type enumeration {
> > >      enum red { value 1; }
> > >      enum breen { value 2; }
> > >      enum glue { value 3; }
> > >    }
> > >    type enumeration {
> > >      enum sparkling { value 1; }
> > >      enum blinking { value 2; }
> > >      enum steady { value 3; }
> > >    }
> > >  }
> > > }
> >
> > in another place, is the value “red” between the two types referring to
> > the “same thing”?
> >
> >
> 
> no -- and this is not an error, although it is position-dependent:
> 
>   typedef baz {
>      type union {
>        type foo;
>        type bar;
>     }
>   }
> 
> The issue for CBOR applies to both bits and enumerations.
> The probability of 2 enum names clashing is almost zero.
> The probability of 2 value-stmts clashing is almost 100%

Enum names like 'unknown' do have a probability to clash that is
larger than 0%.
 
> The answer seems to be simple but inefficient:
> Always encode bits or enumeration as a string, if this is within a union
> type.
> There are not many of these -- more likely to find strings with different
> patterns
> where first-match-wins is no different than before (for XML)

The first match wins rule is debatable. Someone adds an enum to an
enumeration that you import and suddenly the interpretation of config
changes. Not very robust.

> > If there were a typedef for the two anonymous enumerations that both look
> > the same, as in
> >
> >   typedef color {
> > >    type enumeration {
> > >      enum red { value 1; }
> > >      enum breen { value 2; }
> > >      enum glue { value 3; }
> > >    }
> >   }
> >
> > and that typedef being referenced from both unions instead of copy-pasting
> > it, would that change the answer?
> >
> >
> 
> I think first-match-wins still dictates the result.
> 
> The JSON issue (and maybe CBOR) is what Juergen is talking about:
> 
>     typedef maybe-first {
>        type union {
>            type string;
>            type int32;
>         }
>      }
> 
> Use 42 as an example...
> The XML encoding <foo>42</foo> will always match string.
> The JSON (or CBOR) encoding { "foo": 42 } will always match int32
> We want YANG data to maintain fidelity and still be encoding-independent,
> but this is broken for union types.

If we plan to improve things we have we should improve the union
construct by turning it into a tagged union (and do away with the
'first match wins' rule but leave it for backwards compatibility for
untagged unions as long as they are used).

/js

-- 
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/>