Acee,
> On Apr 12, 2023, at 10:33 AM, Acee Lindem <acee.i...@gmail.com> wrote: > So the way you offer backward compatibility is that each bit-encoded field > would have two leaves, one for the known bits and one for the unknown. Then > when a bit is defined and supported by a YANG model implementation, the > known flags could be augmented and the corresponding unknown bit would just > no longer be returned by the implementation. Correct? That's the idea. > Another way to do the same thing and avoid the duplication of the leaves > would be to use identities with the bit position encoded in the identity > identifier. Of course, this would require defining the identities for the > unknown bits for each base identity corresponding to a bit encoded field. I'd talked about this option with a few people and disconsidered it. The reason to disconsider it is that within the same leaf, the value "changes meaning" once you end up with the new identity for the value when it's assigned and then end up with an orphaned identity. Implementations looking at that bit for that leaf now need to "know" they are equivalent. For the moment, the only hint that YANG can provide about this equivalency is in the description. At least within the bits construct, bit number assignment is always crystal clear. > In either case, it would be better to have a construct in the YANG syntax > which allows changing the definition of a bit to be a backward-compatible > change. Even more obvious, adding a new enum should be allowed as > backward-compatible change but I digress and this wouldn’t help us for our > current models. I agree. If we end up with "yang-next" as I've heard it called, this would be a useful case to resolve. If we ended up with such a thing, it'd be nice to simply deprecate the "unknown" leaves, upgrade the type from "bits" to "bits-with-unknown" (or similar) and work from there. -- Jeff _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
