Re: [netconf] YANG encoding in CBOR

Carsten Bormann <cabo@tzi.org> Wed, 27 March 2019 08:25 UTC

Return-Path: <cabo@tzi.org>
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 392D6120274; Wed, 27 Mar 2019 01:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 00i_fhlNbhj1; Wed, 27 Mar 2019 01:25:44 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBD9120273; Wed, 27 Mar 2019 01:25:44 -0700 (PDT)
Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Th066RkVzyct; Wed, 27 Mar 2019 09:25:42 +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 <cabo@tzi.org>
In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de>
Date: Wed, 27 Mar 2019 09:25:42 +0100
Cc: Michel Veillette <Michel.Veillette@trilliant.com>, Ladislav Lhotka <lhotka@nic.cz>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 575367940.6541671-11d0d25c658c030fed37d5d31691a56a
Content-Transfer-Encoding: quoted-printable
Message-Id: <DAEA3E2E-E32C-452C-A2D6-2C951F3ECAD2@tzi.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>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ExMktYlrgqcpEu9IbjVOtTRMxvg>
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: Wed, 27 Mar 2019 08:25:46 -0000

On Mar 27, 2019, at 07:16, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> 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).


And that may be the way forward:

As XML and JSON already differ in handling “first-match wins” (as Andy has demonstrated), there is probably not a lot of damage in CBOR being different again in handling this arcane case, so we can mostly ship as is (but see below).

We then develop the YANG-wide fix together.  We’ll make sure that the CBOR union representation has the right placeholders to put that in.  For that, it would be nice to have a direction about where exactly that information would be in the instance tree.  And, more importantly, if something needs to be included in the SID files, it would be good to nail that down now.

Grüße, Carsten