Re: [netconf] [core] YANG encoding in CBOR

[Juergen Schoenwaelder <[e-mail]>]

On Sun, Mar 24, 2019 at 04:29:45AM -0700, Andy Bierman wrote:
> On Sun, Mar 24, 2019 at 2:47 AM Carsten Bormann <[e-mail]> wrote:
> 
> > On Mar 23, 2019, at 14:35, Juergen Schoenwaelder <
> > [e-mail]> wrote:
> > >
> > > RFC 7950 section 9.12:
> >
> > Thank you, this is very useful.
> >
> > Let me try to ask my other question in a very concrete way:
> >
> > If I have
> >
> > > 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; }
> > >    }
> > >  }
> > > }
> >
> > in one place, and
> >
> > > typedef bar {
> > >  type union {
> > >    type enumeration {
> > >      enum red { value 1; }
> > >      enum breen { value 2; }
> > >      enum glue { value 3; }
> > >    }
> > >    type enumeration {
> > >      enum sparkling { value 1; }
> > >      enum blinking { value 2; }
> > >      enum steady { value 3; }
> > >    }
> > >  }
> > > }
> >
> > in another place, is the value “red” between the two types referring to
> > the “same thing”?
> >
> >
> 
> no -- and this is not an error, although it is position-dependent:
> 
>   typedef baz {
>      type union {
>        type foo;
>        type bar;
>     }
>   }
> 
> The issue for CBOR applies to both bits and enumerations.
> The probability of 2 enum names clashing is almost zero.
> The probability of 2 value-stmts clashing is almost 100%

Enum names like 'unknown' do have a probability to clash that is
larger than 0%.
 
> The answer seems to be simple but inefficient:
> Always encode bits or enumeration as a string, if this is within a union
> type.
> There are not many of these -- more likely to find strings with different
> patterns
> where first-match-wins is no different than before (for XML)

The first match wins rule is debatable. Someone adds an enum to an
enumeration that you import and suddenly the interpretation of config
changes. Not very robust.

> > If there were a typedef for the two anonymous enumerations that both look
> > the same, as in
> >
> >   typedef color {
> > >    type enumeration {
> > >      enum red { value 1; }
> > >      enum breen { value 2; }
> > >      enum glue { value 3; }
> > >    }
> >   }
> >
> > and that typedef being referenced from both unions instead of copy-pasting
> > it, would that change the answer?
> >
> >
> 
> I think first-match-wins still dictates the result.
> 
> The JSON issue (and maybe CBOR) is what Juergen is talking about:
> 
>     typedef maybe-first {
>        type union {
>            type string;
>            type int32;
>         }
>      }
> 
> Use 42 as an example...
> The XML encoding <foo>42</foo> will always match string.
> The JSON (or CBOR) encoding { "foo": 42 } will always match int32
> We want YANG data to maintain fidelity and still be encoding-independent,
> but this is broken for union types.

If we plan to improve things we have we should improve the union
construct by turning it into a tagged union (and do away with the
'first match wins' rule but leave it for backwards compatibility for
untagged unions as long as they are used).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>