Jan,
> On Aug 22, 2023, at 4:07 AM, Jan Lindblad <j...@tail-f.com> wrote: > The recommendation I would give for modeling bit fields with reserved bits is > to not model them as the YANG bits type. I think I've unfortunately caused this thread to fork in a non-productive fashion. The unknown-bits proposal discusses primarily what to do about unassigned bits in flags fields. Similar considerations in terms of NBC modeling for the contents of RESERVED fields similarly apply. I'm going to reply to the remainder of this message solely from that context. > 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. I would not make that recommendation. Unless you know the underlying contents are a given type, something that handles representing that state opaquely is the best you can do. > 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. This is fine. As you slice off portions of reserved for new state, you add new leaves that model that new state appropriately. What remains unanswered is what you'd do if you wanted to model the contents of that RESERVED field over the transition process. Let's do a single theoretical iteration: Our mythical protocol has a 16-bit RESERVED field that is octet-aligned in the PDU, just to make this easy. If the model author wanted to represent the contents of that field at all for state purposes, how best to model that? Some options: 1. We know it's 16 bits, so just make it a uint16. 2. We don't like 1 because uint16 implies that it has a type, so we model it as a bounded hex-string. 3. We don't like the IETF hex-string format because the consumer of this thing is a machine rather than a human, so we make it a bounded binary. All three of these are fine. An update to the protocol then slices off the lower octet for a new field that's a uint8 type. We can model that as a new leaf fine. What then of the "reserved" leaf? Some impacted properties: 1. It's no longer describing 16 bits of data. At best, it describes the 16 bits of data that now includes the new leaf. You have overlapping noise in the model. 2. You shouldn't shrink the existing leaf as that's NBC. 3. It's arguable you don't want to mask out the new field from the reserved field as that's exactly as NBC as the bits conversation we're having. Other options? 1. Obsolete the existing leaf, create a new one. reserved2, reserved-20230813, reserved-iana-foo... 1a. pray that you don't have the options to have forking features. If so, you might end up in combinatoric if-feature hell if you wanted to capture the various options. 2. Leave it alone. It's historical noise, even though the property impacts above are relevant. 2a. When all of the reserved space is finally allocated, obsolete the leaf. Thus, we have similar considerations for non-bit RESERVED fields if we have any interest in modeling them. If the Working Group prefers to make that the actual issue rather than solely the bits scenario, that's perfectly reasonable. > > 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 :-) I certainly don't need to be convinced of this point; see my comments about tcpdump and YANG. -- Jeff _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
