Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

Jeff, WG,

The recommendation I would give for modeling bit fields with reserved bits is to not model them as the YANG bits type. Even if, on the protocol level of whatever it is that we are managing, some uint16 is divided up into three well defined bit fields and have another few bits reserved for future use, that is no strong reason for selecting the bits type in the YANG representation of this functionality.

YANG works best when those three currently defined bit fields are defined as three separate YANG leafs. Logically, that is what they are. Three separate quantities. Later, when some of the reserved bits are taken to good use, another YANG leaf that declares the new functionality can be easily added to the next version of the YANG in a backwards compatible way. The new leaf could even have an if-feature statement, so that clients can identify server support up front. Or use the YANG choice statement to describe how various fields exist on condition that certain other leafs have some specific value.

If we are concerned about the efficiency of the management protocol, then there are *significantly* greater savings to be had by taking a more holistic approach, rather than focusing on the encoding details for esoteric leaf types. Txid comes to mind :-)

Best Regards,
/jan

> On 21 Aug 2023, at 16:15, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> Rob,
> 
> Rewinding to the points raised in the original discussion thread:
> 
> 
>> On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton) <rwilton@cisco.com <mailto:rwilton@cisco.com>> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod