Tom,
> On Apr 12, 2023, at 12:44 PM, tom petch <[email protected]> wrote: >> 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. >> > <tp> > > That caught my eye and I am not sure I understand, As the I-D says, a bit is > identified by its name and the canonical form is a list of space-separated > names, bit number assignment I do not see except as a local convention > which I would not call crystal clear. With bits, if bit position 3 is "foo", you always know that foo is bit-position 3. With identities, identity foo from base bar is simply "foo" and if it has anything to do with bit-position 3, it's listed by description. If you define foo2 and it's semantically the same as bit-position 3, an implementation could render "foo foo2", "foo", or "foo2". The underlying type doesn't provide machinery that enforces what you do. Somewhat maddening if you're trying to see what bits on the wire are. If you're driven to "just give me the hexdump", we've lost the ease of use game. -- Jeff _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
