Re: [core] Comments on draft-ietf-core-yang-cbor-00

Ladislav Lhotka <lhotka@nic.cz> Mon, 23 May 2016 11:22 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E612D69A for <core@ietfa.amsl.com>; Mon, 23 May 2016 04:22:59 -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] 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 AI6RqhhKy_UG for <core@ietfa.amsl.com>; Mon, 23 May 2016 04:22:58 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24B1D12D681 for <core@ietf.org>; Mon, 23 May 2016 04:22:58 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E8A4F1CC02AA; Mon, 23 May 2016 13:22:58 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20160521112857.GA4437@elstar.local>
References: <CABCOCHRRACvVXx2S_hZm2TxbvP48aO4Q4REkh0LFjmHkMkZ1Vg@mail.gmail.com> <m2y473svm0.fsf@nic.cz> <57401CC2.2040002@tzi.org> <20160521112857.GA4437@elstar.local>
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 23 May 2016 13:22:59 +0200
Message-ID: <m2zirh81d8.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/YadMDbzcK6q50nyZK-FytlT2swg>
Cc: Core <core@ietf.org>
Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 11:22:59 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Sat, May 21, 2016 at 10:30:58AM +0200, Carsten Bormann wrote:
>> Ladislav Lhotka wrote:
>> > The receiving side will resolve the union type by the first union member
>> > type that matches the CBOR-encoded value. It's the same as in JSON encoding.
>> 
>> Or, at least, similar -- we are not always making the same serialization
>> decisions.
>> 
>> The weird aspect of this part of YANG is that the actual validity (and
>> specific semantics and thus usefulness) of a union in the YANG module
>> depends on the specifics of the serialization below.
>
> YANG's native serialization of values are untyped strings.

To my knowledge, this hasn't been stated as a design feature for YANG,
it's just a side effect of XML being the only serialization that was
considered when YANG was being designed.

>
>> More frankly: Tying the semantics of a modeling language to one specific
>> serialization mechanism is an utterly broken design.
>
> Not necessarily. It may start to look broken once you have
> serializations that are typed and for some reasons people think the
> type information should impact how YANG works (that assumes values
> serialized as untyped strings). Note that type rules differ for
> different serializations so you actually have no chance to get away
> without any weird corner cases.
>
>> I'm not sure that it can be fixed, though, so we'll likely have to work
>> around this breakage.
>
> I disagree that YANG is broken.

+1, although I think it would be useful to have a general mechanism for
signaling the actual type of a value - one option is to use a metadata
annotation.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C