> On Apr 12, 2023, at 13:27, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Wed, Apr 12, 2023 at 10:04 AM Jeffrey Haas <jh...@pfrc.org > <mailto:jh...@pfrc.org>> wrote: >> Tom, >> >> >> > On Apr 12, 2023, at 12:44 PM, tom petch <ie...@btconnect.com >> > <mailto:ie...@btconnect.com>> 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. > > > I unclear on the "ease of use" gained by using YANG bits to define bit > positions. > IMO is would be much easier to use a protocol-specific leaf if you want to > debug > a specific protocol. An operational leaf like "raw-foo-field" is sufficient > and easy to use.
I have to agree. We did this for LSAs in the ietf-ospf.yang model. Also, I tend to think this extension (if it were to become a requirement) is overkill. Typically, extensions using reserved bits must be backward compatible so why do we need to encode these bits explicitly in the YANG models for nodes not supporting extensions using the formerly reserved bits??? Also, reserved bits typically “MUST be ignored upon receipt” and this is inconsistent with that guidance. Thanks, Acee > > The only semantics seems to be the bit position, which is already standardized > and can be represented many ways (e.g. hex-string, binary, uint32). > > >> >> -- Jeff > > Andy > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org <mailto:netmod@ietf.org> >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
