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

Andy Bierman <andy@yumaworks.com> Thu, 28 March 2019 01:37 UTC

Return-Path: <andy@yumaworks.com>
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 7A437120148 for <netconf@ietfa.amsl.com>; Wed, 27 Mar 2019 18:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 U5OEizqzEjgZ for <netconf@ietfa.amsl.com>; Wed, 27 Mar 2019 18:37:28 -0700 (PDT)
Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E58912012E for <netconf@ietf.org>; Wed, 27 Mar 2019 18:37:28 -0700 (PDT)
Received: by mail-lf1-x141.google.com with SMTP id r25so12763130lfn.13 for <netconf@ietf.org>; Wed, 27 Mar 2019 18:37:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tfknNrBJwSLp4kQR0Lu3mUy31/WpYeLthisqCPdE34U=; b=G8Uw1tATUcS9XMk5/OLkXO00hxNoWJb5V4WMpA4oiRmZiI7JUQHqVNS2rmsigTQ1mE zUkS756m5khYWZcMyap9Fyz17sfDMBRAKOcGgTEmuUfrSN7izDtz9ngIdcX/ByQ3LMEh nm3upnwcgcAHZ7fMXTHrahkAxrdrtdSuWT/kAlBT1H4kc0sSJBbAlnUXq7Ieq94yE0Ly L0sHil1EFsjXKCkdyu9UlbBV/QFgTmA2U99sMpQMIwqVxD8ZwpdzJ8hh5420Lu+M1Yxl yivdThzodktWnu406Zb8b8gwLnp0VPRA8wov5Z/0aRcvGfNniZwRmN2vjf5njhc3u++V ASzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tfknNrBJwSLp4kQR0Lu3mUy31/WpYeLthisqCPdE34U=; b=O8sOs9hzpyYGrpj2DGeZwGI87Nf9ONlGdWeh8YdPocILvRMgfX7FqlOdf2HGq3U5lv dEq4/wENx2L3PLsDHYHZ23g87gk1T+C6/Av3N07A5irEhJw53/MtQOcKF3zj+vrFpiT/ TChEGU0mwWLKnIArI8HKl5ib4bZ4vsyrtSizfvGLoCkT/CqAajCQ5KgClao5zGR8aBPZ uQTjctiAmdP89cyzb6vby7Qc66tXhXT7MenpQ09QmOBUhULlGQVSz8BwXoK4I401qW5p Ae7qNze6xgSjR7gA3dn3IhY9QFtT/W5KngrckSvb6QIwCWhzx35Kpxme6niu6vhOzuf3 1g5A==
X-Gm-Message-State: APjAAAXabgjujM/pkFIdPeoQu6Mu+9TjqgEXF6dZidgEBAvur3juwmX+ UVZs9mMrEl7Bc1nr0wnOVyY8ndPW9059TmYVLEsQyw==
X-Google-Smtp-Source: APXvYqyRaPFW0AOUPsnL50Vb9oeZVPLSkndbHZR5bHsKrVcItoOnc1+TXSy79ptu3oPtgU7yxqEMxvijqGI48zQW5TM=
X-Received: by 2002:ac2:41c4:: with SMTP id d4mr21103116lfi.104.1553737046602; Wed, 27 Mar 2019 18:37:26 -0700 (PDT)
MIME-Version: 1.0
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> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> <CABCOCHRKhvUzrDcELOWGHY5HWt7EQpq-iYdY84z3oqOCQjsATg@mail.gmail.com> <ce1bfc2916dcc3eadf03a46f901e08060c3858b2.camel@nic.cz>
In-Reply-To: <ce1bfc2916dcc3eadf03a46f901e08060c3858b2.camel@nic.cz>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 27 Mar 2019 18:37:15 -0700
Message-ID: <CABCOCHT0LKzT3wUSsatbtUYDvmzssx8-1eNpRuKrDvQjDcV=Kg@mail.gmail.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Michel Veillette <Michel.Veillette@trilliant.com>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bcd01e05851d98c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Jg7lG09l511js-qYwT6NOA92cxw>
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: Thu, 28 Mar 2019 01:37:35 -0000

Hi Lada,

On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka <lhotka@nic.cz>; wrote:

> Andy Bierman píše v St 27. 03. 2019 v 09:13 -0700:
> >
> >
> > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka <lhotka@nic.cz>; wrote:
> > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote:
> > > > 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).
> > >
> > > I already opened a new issue for this in yang-next:
> > >
> > > https://github.com/netmod-wg/yang-next/issues/72
> > >
> >
> > We already explored the solution of giving the member types numbers
> > so they could be used in CBOR but this was rejected because it is so
> complex
> > to implement.
>
> I don't think it is too complex. Get the type in the schema, get the
> member,
> that's all. It is much easier and more robust than the current algorithm.
> ...


I think a discriminated union is too complex and overkill, considering the
low probability
of the problem.

It's not as if the client or server developers know which union member type
each value is using.
This is not going to be hard-wired either.  Senders do not usually validate
data, especially
NETCONF servers.  It will be very expensive (and very slow) to validate
union types
in order to determine the member type number.

We cannot rely on YANG authors to follow the update rules, especially when
they change type definitions to fix bugs.  The encoding for a union cannot
ever
change over time or it will break clients. We want to support clients
without requiring
any code changes, even when the server is upgraded.

I prefer a much easier and faster solution:

The client or server must figure out which data nodes have this problem at
boot-time.
These data nodes will always be sent with a new tag (for DUP-UNION) and the
format will always be a string. A receiver must be able to handle DUP-UNION
strings
and parse them against the union type correctly.

All other union type data nodes are sent as normal.
Annotations are not needed.

The JSON vs. XML ordering problem can be handled with best practices
https://tools.ietf.org/html/rfc8407#section-4.11.4


Andy