Rob, Rewinding to the points raised in the original discussion thread:
> On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton) <[email protected]> wrote: > Specifically, sometimes/always just reporting the raw hex value alongside the > bits value seems like a simple, effective, and robust solution, and perhaps > we could recommend a standard name prefix or suffix for the name of the raw > value leaf relative to the bits value leaf. Leaf name aside, the question is what do you do with the raw value, especially when it's not really octet-aligned? In the example that prompted this discussion, we have a nybble. (See RFC 4724) In that case, the nybble occupied the high order bits. The natural value that it is part of is a uint16 that contains a 12 bit time value. The "raw" for the bits really shouldn't be the uint16. The "raw" really shouldn't be a dump of the full capability. I think it has been a mistake in prior models to ship raw that devolves to "you need to tcpdump the yang". One practice may simply be to say "shift the bits to the right" (presuming usual network byte order considerations in IETF), which would take this nybble and put it in the low-order bits of the respective leaf. Also, keep in mind that these practices are often needed for "RESERVED" fields that later on are decomposed into further structured fields. This would mean a NBC change to the "raw" representation in such a case. I can provide a contrived example, if this is not clear. Once the "what do you do with the bits" point is addressed, there's also the matter of how you ship it. I find it peculiar that we seem to preference the human-readable forms for "raw" than the machine readable ones in most of our discussions. > In addition, I think that if we wanted a more efficient solution that doesn’t > require modelling two leaves, then perhaps this could be considered as a > potential YANG Next issue. I.e., is there is a small change or addition to a > future revision of the YANG language (or encodings) that could allow this to > be better handled. IMO, permitting bit field aliasing where multiple names can refer to the same bit position would address this issue. Good for YANG-next. That said, I'm targeting the narrow use case of a small number of bits. Such "raw" considerations break down under larger examples. See above for such an example. -- Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
