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

[Andy Bierman <[e-mail]>]

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%

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)


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


Grüße, Carsten
>
>
Andy


> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>