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

[Andy Bierman <[e-mail]>]

Hi Lada,

On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka <[e-mail]> wrote:

> Andy Bierman píše v St 27. 03. 2019 v 09:13 -0700:
> >
> >
> > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka <[e-mail]> wrote:
> > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote:
> > > > Hi,
> > > >
> > > > a union can be formed by using member types that are imported and not
> > > > under change control of a single author/organization and ideally this
> > > > should work without complex coordination of name and number spaces.
> > > > Duplicate enum/bits values are legal in YANG today so an encoding has
> > > > to deal with this aspect of life.
> > > >
> > > > A robust fix to all these problems will be to tag the type members in
> > > > order to discriminate the values in the encodings. This, however,
> will
> > > > take some time to specify and we will need to preserve backwards
> > > > compatibility with unions without a tag (but compilers can encourage
> > > > people to add tags whenever modules are updated).
> > >
> > > I already opened a new issue for this in yang-next:
> > >
> > > https://github.com/netmod-wg/yang-next/issues/72
> > >
> >
> > We already explored the solution of giving the member types numbers
> > so they could be used in CBOR but this was rejected because it is so
> complex
> > to implement.
>
> I don't think it is too complex. Get the type in the schema, get the
> member,
> that's all. It is much easier and more robust than the current algorithm.
> ...


I think a discriminated union is too complex and overkill, considering the
low probability
of the problem.

It's not as if the client or server developers know which union member type
each value is using.
This is not going to be hard-wired either.  Senders do not usually validate
data, especially
NETCONF servers.  It will be very expensive (and very slow) to validate
union types
in order to determine the member type number.

We cannot rely on YANG authors to follow the update rules, especially when
they change type definitions to fix bugs.  The encoding for a union cannot
ever
change over time or it will break clients. We want to support clients
without requiring
any code changes, even when the server is upgraded.

I prefer a much easier and faster solution:

The client or server must figure out which data nodes have this problem at
boot-time.
These data nodes will always be sent with a new tag (for DUP-UNION) and the
format will always be a string. A receiver must be able to handle DUP-UNION
strings
and parse them against the union type correctly.

All other union type data nodes are sent as normal.
Annotations are not needed.

The JSON vs. XML ordering problem can be handled with best practices
https://tools.ietf.org/html/rfc8407#section-4.11.4


Andy