Subject: Re: [core] fixing YANG to CBOR

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 1 Aug 2016 20:48:25 +0000

+1

Sent from my Windows Phone
________________________________
From: Michel Veillette<mailto:[email-masked]>
Sent: ‎26/‎07/‎2016 05:31
To: Andy Bierman<mailto:[email-masked]>
Cc: Core<mailto:[email-masked]>
Subject: Re: [core] fixing YANG to CBOR

+1

Le 25 juil. 2016 à 23:20, Andy Bierman <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

I think this "union type" corner-case is not bad enough to
justify a really complicated design like tracking the order
of union type syntax changes.  We need to remove order
dependencies, not add new ones.  I should have realized
this is too complicated.

So I think the current tagging solution is good enough.
Do not change it to count and order the member type-stmts.

I will write YANG guidelines in 6087bis to attempt to prevent these
corner-cases from occurring in IETF modules.

Andy

On Mon, Jul 25, 2016 at 1:53 PM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

> On 25 Jul 2016, at 22:21, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> On Mon, Jul 25, 2016 at 1:17 PM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
>
> > On 25 Jul 2016, at 21:00, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >
> >
> > On Mon, Jul 25, 2016 at 11:51 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > > On 25 Jul 2016, at 18:05, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > > Hi Lada, Hi Andy
> > >
> > > The important questions we need answer to validate the current solution are the following.
> > >
> > > - In a union, is it valid to define multiple enumerations which reuse the same value(s) with a different semantic meaning?
> > > - In a union, is it valid to define multiple bits which reuse the same position(s) with a different semantic meaning?
> >
> > IMO, yes, in both cases. I am not saying that it's a good design though.
> >
> > >
> > > In the following examples, value or position 0 means both white and red which I believe it's invalid.
> >
> > I don't think so. The member types are checked in the same order as they appear in the union's definition, and the first type for which a given value is valid is used.
> >
> >
> >
> > That's the issue here.
> > The member type value spaces are allowed to overlap each other.
> > The "first wins" depends on the value being sent.
> > The same problem exists for JSON for boolean and numeric types.
> > Only XML passes everything as a string.  YANG union was designed only to work
> > robustly with XML.
>
> I believe for JSON it is perfectly robust. The general rule should be this: use whatever information you have to determine whether the received value is valid for the first member type. If not, try the second member etc.
>
>
> believe what youi want:
>
>
>    type union {
>        type string;
>        type int32;
>    }
>
> JSON produces different results than XML.
>
> If client A sets number 42 in JSON, then client B will read back string "42" in XML.
> If the XML client sets string "42", the JSON client will read back string "42".
> This is the exact same issue facing CBOR conversion

In my view, most implementations will eventually use just one encoding, and this problem won't exist for them.

XML, JSON and CBOR in reality pass different information, it is not like UTF-8 versus UTF-16. Restricting all alternative media types only to features supported in XML doesn't make much sense.

Lada

>
>
>
> Lada
>
>
> Andy
>
> >
> >
> > > If this is the case, the currently proposed solution to tag some specific datatype (bits,  enumeration, identityref, instance-identifier) when used in a union resolve any potential ambiguities.
> >
> > Yes, I think this is a good idea because otherwise resolving the member types may be difficult. Moreover, sometimes the sending side might want to override the resolution algorithm - e.g., if a client wants to set a leaf with "inet:host" type to "1.2.3.4" and interpret it as a domain name rather than IP address.
> >
> > > Can we move ahead with the current solution?
> >
> > The current solution is just as good and just as broken as the JSON solution,
> > and we already moved ahead with that in NETMOD WG. (So I guess that means yes?)
> >
> >
> > Andy
> >
> > >
> > > ENUMERATION EXAMPLE
> > >
> > > typedef A {
> > >  type union {
> > >    type enumeration {
> > >      enum white {
> > >        value 0;
> > >      }
> > >      enum black {
> > >        value 1;
> > >      }
> > >    }
> > >    type enumeration {
> > >      enum red {
> > >        value 0;
> > >      }
> > >      enum green {
> > >        value 1;
> > >      }
> > >      enum blue {
> > >        value 2;
> > >      }
> > >    }
> > >  }
> > > }
> >
> > Values 0 and 1 are interpreted as "white" and "black", value 2 is "blue".
> >
> > >
> > > BITS EXAMPLE
> > >
> > > typedef B {
> > >  type union {
> > >    type bits {
> > >      bit white {
> > >        position 0;
> > >      }
> > >      bit black {
> > >        position 1;
> > >      }
> > >    }
> > >    type bits {
> > >      bit red {
> > >        position 0;
> > >      }
> > >      bit green {
> > >        position 1;
> > >      }
> > >      bit blue {
> > >        position 2;
> > >      }
> > >    }
> > >  }
> > > }
> >
> > Ditto.
> >
> > Lada
> >
> > >
> > > Regards,
> > > Michel
> > >
> > > -----Original Message-----
> > > From: core [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ladislav Lhotka
> > > Sent: Monday, July 25, 2016 10:41 AM
> > > To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
> > > Cc: Core <[email-masked]<mailto:[email-masked]>>
> > > Subject: Re: [core] fixing YANG to CBOR
> > >
> > >
> > >> On 25 Jul 2016, at 16:21, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
> > >>
> > >>
> > >>
> > >> On Mon, Jul 25, 2016 at 6:00 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
> > >> Andy Bierman <[email-masked]<mailto:[email-masked]>> writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> It seems to me that the only tagging actually needed would be to
> > >>> identify the ordered list of member types within a union type.
> > >>>
> > >>>
> > >>> typedef A {
> > >>>  type union {
> > >>>    type int32 ;   // 1
> > >>>    type string; // 2
> > >>>    type B;   // 3, 4, 5
> > >>>    type identityref { base bar; }   // 6
> > >>>  }
> > >>> }
> > >>>
> > >>>
> > >>> typedef B {
> > >>>  type union {
> > >>>    type uint8;
> > >>>    type uint16;
> > >>>    type uint32;
> > >>>  }
> > >>> }
> > >>>
> > >>> leaf foo { type A; }
> > >>>
> > >>> YANG allows the member types to be reordered if it does not change
> > >>> the value set accepted by the type.  It is not clear
> > >>
> > >> I don't think this is true. The only statement in 6020bis that is
> > >> related to this issue is the bullet that you cite below, but IMO
> > >> reordering member types in a union type definition may change the type
> > >> semantics because the receiving side resolves the type according to
> > >> the order of member types.
> > >>
> > >>
> > >>
> > >> This depends on the format, but non-overlapping member types can
> > >> change position without changing syntax or semantics.
> > >
> > > Yes, but, for instance, the "inet:host" type in RFC 6991 has overlapping members: "1.2.3.4" is valid as both "inet:ip-address" and "inet:domain-name".
> > >
> > > Lada
> > >
> > >> The exact member type that matches is not important.
> > >>
> > >>   typedef foo1 {
> > >>      type union {
> > >>         type int32 { range "1..10"; }
> > >>         type int32 { range "11..20"; }
> > >>      }
> > >>    }
> > >>
> > >>  typedef foo2 {
> > >>      type union {
> > >>         type int32 { range "11..20"; }
> > >>         type int32 { range "1..10"; }
> > >>      }
> > >>    }
> > >>
> > >>
> > >>
> > >> Lada
> > >>
> > >> Andy
> > >>
> > >>
> > >>> if new member types can be added in new module revisions.
> > >>>
> > >>> If new member types are allowed in typedef B, then the relative
> > >>> position of (6) can change, even if typedef A does not change.
> > >>> YANG does not explicitly state if this is allowed or not.
> > >>>
> > >>> bits and enumerations can be expanded in new revisions, which
> > >>> changes the value set, but existing value and position numbers are
> > >>> not allowed to change.
> > >>>
> > >>> The problematic text is in 6020bis, sec 11
> > >>>
> > >>>  o  A "type" statement may be replaced with another "type" statement
> > >>>      that does not change the syntax or semantics of the type.  For
> > >>>      example, an inline type definition may be replaced with a typedef,
> > >>>      but an int8 type cannot be replaced by an int16, since the syntax
> > >>>      would change.
> > >>>
> > >>>
> > >>>
> > >>> In practice reordering member types would be very rare, but the SID
> > >>> numbering would need to remember the member type order for each leaf
> > >>> or leaf-list that resolves to a union type.
> > >>>
> > >>> It doesn't help to tag any other type besides union.
> > >>>
> > >>>
> > >>> Andy
> > >>> _______________________________________________
> > >>> core mailing list
> > >>> [email-masked]<mailto:[email-masked]>
> > >>> https://www.ietf.org/mailman/listinfo/core
> > >>
> > >> --
> > >> Ladislav Lhotka, CZ.NIC Labs
> > >> PGP Key ID: E74E8C0C
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > [email-masked]<mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/core
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.