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

On Fri, Mar 22, 2019 at 9:08 AM Carsten Bormann <cabo@tzi.org> wrote:

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

The union data type has similar issues with JSON encoding, where the JSON
encoding can
influence the YANG decoding. This is not possible with XML since all values
are strings.

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.
>
>
I agree, but tools still need to identify the problem if it exists and flag
the object for different processing
or no processing at all (draft says YANG with these conflicts are not
allowed). IMO a string encoding
should be used.

All YANG union types are position-dependent.
The parser goes through the member types in order, and first one that
accepts the value given wins.
(e.g, ip-address, or any union with 2 of the same base type).

We discussed this issue during the NETMOD WG virtual interim this week, and
wanted clarification
on the scope of the problem. It seems to be limited to just multiple
enumerations in a union.
The rest of the corner-cases are just position-dependent, same as before.

Grüße, Carsten
>
>
Andy

> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>