Re: [netconf] YANG encoding in CBOR

Ladislav Lhotka <lhotka@nic.cz> Mon, 25 March 2019 08:06 UTC

Return-Path: <lhotka@nic.cz>
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 B9979120370; Mon, 25 Mar 2019 01:06:56 -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 8ymlrML5U9rm; Mon, 25 Mar 2019 01:06:54 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41D120365; Mon, 25 Mar 2019 01:06:53 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 903AF18204C5; Mon, 25 Mar 2019 09:06:35 +0100 (CET)
Received: from localhost (dhcp-82e3.meeting.ietf.org [31.133.130.227]) by trail.lhotka.name (Postfix) with ESMTPSA id E58671820047; Mon, 25 Mar 2019 09:06:18 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Carsten Bormann <cabo@tzi.org>
Cc: Michel Veillette <Michel.Veillette@trilliant.com>, "netconf\@ietf.org" <netconf@ietf.org>, "core\@ietf.org" <core@ietf.org>
In-Reply-To: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de>
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>
Date: Mon, 25 Mar 2019 09:06:33 +0100
Message-ID: <871s2vqsxi.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sBMlWe-fJoe3pfG7chbSlzQ5tqU>
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: Mon, 25 Mar 2019 08:06:57 -0000

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://www.ietf.org/mailman/listinfo/netconf
>
> -- 
> 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/>
>
>
> 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://www.ietf.org/mailman/listinfo/netconf
>
> -- 
> 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/>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67