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

[ivaylo petrov <[e-mail]>]

Hello,

On Mon, Mar 25, 2019 at 7:23 AM Carsten Bormann <[e-mail]> wrote:

> 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.
>
>
[IP]: Carsten, your idea for the good solution would be to keep the way
enum values are sent now outside of unions and only send the SIDs inside
unions, is that correct? If so, this sounds as a very good solution to me.
It might add a bit of complexity in the SID generation, but I would expect
it to be rather small.


> So does anyone have an idea how such an identifier scheme might look like?
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core


Best regards,
Ivaylo Petrov