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

[Carsten Bormann <[e-mail]>]

Hi Andy,

> On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann <[e-mail]> wrote:
> On Mar 24, 2019, at 12:29, Andy Bierman <[e-mail]> wrote:
> > 
> > The answer seems to be simple but inefficient:
> > Always encode bits or enumeration as a string, if this is within a union type.
> 
> For enum values within unions (which are already handled specially by giving them a CBOR tag) we could simply use a SID (that we then would have to generate for each enum value) instead of a string.  We could also extend this to enums outside unions; but here the recurrence to the (outside unions unambiguous) value sounds better to me.
> 
> Bits.  Oh.  Same procedure, I’d say.


> On Mar 24, 2019, at 23:52, Andy Bierman <[e-mail]> wrote:
> 
> This seems like it would make the SID file very complicated.

Not necessarily:

> Not sure it would work since leaf/leaf-list can define their own types.
> Plus, all the enum typedefs would have to be numbered this way.

Right!
It would amount to defining an identifier scheme for all the so far anonymous enums (and bits defs, I gather).

> Maybe the SID authors can comment on how this would be done.

Well, such an identifier scheme would benefit the whole YANG ecosystem, so you can have a transition from “first match wins” to proper name equivalence.  So we would need to do it in a way that over time it can become part of the core YANG definition.

We can maybe cheat:  Use strings for enums inside unions for now, and values only outside.
But it would be good if the SID files generated (and registered) for a YANG module already had those enum/bits type identifiers so we only have to do the SID generation once, so I’m not sure if I like cheating; doing the SIDs for those identifiers right from the outset would win so much more.

So does anyone have an idea how such an identifier scheme might look like?

Grüße, Carsten