netmod-wg / yang-next

Feature requests for future versions of YANG
6 stars 0 forks source link

Have a mechanism to allow enums to be extended #90

Open rgwilton opened 5 years ago

rgwilton commented 5 years ago

I think that in some cases, individuals writing YANG modules end up using identities instead of enums because they want to leave the door open to them being extended in future. This doesn't necessarily seem like the right choice.

Specifically example I was thinking of is interface loopback.

Hence, I wonder whether YANG shouldn't have a mechanism to allow an augmenting module to add in new enum values (probably always with explicit values that don't clash).

Yes, you could have two modules that both attempt to add in the same value to an enum, but this could be treated as a compile error when constructing the schema.

jhaas-pfrc commented 1 year ago

draft-haas-netmod-unknown-bits covers a different extension headache. For known bits, you can enumerate them in current YANG 1.1. However, unknown bits are not rendered at all. This leads to the headache that if you want "visibility", you need to look elsewhere.

What would be nice is for un-named bits to have a "default name" that is rendered if content is present. Perhaps this is only done for a new type "bits-with-default-name", or something similar. However, as has been raised in other threads, when the bit is named you introduce backward compatibility headaches in that the name "changes".

abierman commented 2 weeks ago

Support the problem statement This can be done with deviate(replace) and some vendors use that. Can this be done already with a derived type? I don't think so. That should be the solution for adding enums, not just restricting enums.

Complexity: medium, bc: unknown, importance: high