Re: [netconf] YANG encoding in CBOR

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sat, 23 March 2019 13:35 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 5971012795E; Sat, 23 Mar 2019 06:35:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 jvr6EQVbYalG; Sat, 23 Mar 2019 06:35:23 -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 D18E9128664; Sat, 23 Mar 2019 06:35:22 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4B0278B2; Sat, 23 Mar 2019 14:35:21 +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 9Fk1rxaIeq-w; Sat, 23 Mar 2019 14:35:21 +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; Sat, 23 Mar 2019 14:35:21 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E213200A6; Sat, 23 Mar 2019 14:35:21 +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 MsqfPOtV-UwO; Sat, 23 Mar 2019 14:35:20 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (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 5F566200A5; Sat, 23 Mar 2019 14:35:20 +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; Sat, 23 Mar 2019 14:35:19 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 6C88530077AB2F; Sat, 23 Mar 2019 14:35:19 +0100 (CET)
Date: Sat, 23 Mar 2019 14:35:19 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Carsten Bormann <cabo@tzi.org>
CC: Michel Veillette <Michel.Veillette@trilliant.com>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
Message-ID: <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Carsten Bormann <cabo@tzi.org>, Michel Veillette <Michel.Veillette@trilliant.com>, "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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) 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/_P6MOAYaYmzKoCgbCHa8tXdFD1E>
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: Sat, 23 Mar 2019 13:35:26 -0000

On Sat, Mar 23, 2019 at 11:27:08AM +0100, Carsten Bormann wrote:
> On Mar 23, 2019, at 11:10, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; wrote:
> > 
> > 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'
> 
> Can you point to chapter and verse?

RFC 7950 section 9.12:

   When generating an XML encoding, a value is encoded according to the
   rules of the member type to which the value belongs.  When
   interpreting an XML encoding, a value is validated consecutively
   against each member type, in the order they are specified in the
   "type" statement, until a match is found.  The type that matched will
   be the type of the value for the node that was validated, and the
   encoding is interpreted according to the rules for that type.
 
> > 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.
> 
> In a serialization that has more type information (such as yang-cbor), you can reliably distinguish any usage of the uint8 from the usage of the enumerations.  We put in the CBOR tags to enable that even though enumeration values are normally represented by their “value” field.

The JSON encoding (RFC 7951 section 6.10) also can distinguish between
the enum and the uint8 but it can't distinguish between other types
that all map to a JSON string. Can the CBOR encoding distinguish
between two uint8 values (or two string values) in a union?

typedef temperature {
    type union {
    	type fahrenheit; // an int16
	type celsius;    // an int16
    }
}

> The part that I don’t understand is what is the plan with handling conflicts between the enumerations.

Depends on what you consider a conflict. My problem is that I see
three encodings that all appear to do something slightly different and
the problem seems to be that YANG kind of defers the interpretation of
unions to encodings. Things would be robust if even the above case
would be unambiguous in all encodings, i.e., the union would be a
discriminated or tagged union.

/js

> I’m not sure what the equivalence model is, here — do YANG enums employ structural equivalence?  There is no name up there, so it can’t really be name equivalence, unless there is an implicit name being inferred from the schema tree.
> 
> Grüße, Carsten
> 
> 
> 
> 
> > 
> > /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/>
> > 
> > 
> 

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