Re: [netmod] Modeling unknown bits in YANG (draft-haas-netmod-unknown-bits-00)

[Jürgen Schönwälder <[e-mail]>]

On Fri, Jan 27, 2023 at 09:33:43AM -0500, Jeffrey Haas wrote:
> Jürgen,
> 
> Thank you for your comments.
> 
> On Thu, Jan 26, 2023 at 11:40:33PM +0100, Jürgen Schönwälder wrote:
> > On Thu, Jan 26, 2023 at 03:51:57PM -0500, Jeffrey Haas wrote:
> > - I suggest to avoid talking about displaying data, the verb 'display'
> >   is never used in RFC 7950.
> 
> What is the suggested verbiage for such things?

Depending on context, I think it is 'modeling' when it is about
choosing the type or 'rendering' / 'representing' when it is about how
a type's value is rendered (in XML). Some proposals:

   When bits that are currently RESERVED or otherwise unassigned by the
   protocol are received, being able to display them is necessary in
   YANG operational models.

   When bits that are currently RESERVED or otherwise unassigned by the
   protocol are received, being able to model them is necessary in
   YANG operational models.


   In that typedef, the "flags" leaf could only display
   position 0, the "restart" named bit.  The implementation couldn't
   display that the 'N' bit was sent in the protocol.

   In that typedef, the "flags" leaf could only represent
   position 0, the "restart" named bit.  The implementation couldn't
   represent that the 'N' bit was sent in the protocol.


   One solution to modeling unknown bits is to have a subsequent leaf
   whose purposes is only to display unknown bit mappings.

   One solution to modeling unknown bits is to have a subsequent leaf
   whose purposes is only to model unknown bit mappings.


   The only purpose of such
   unknown named bits is to display fields that may later be assigned
   during maintenance of the protocol.

   The only purpose of such
   unknown named bits is to represent fields that may later be assigned
   during maintenance of the protocol.


   Only the bits received in the protocol that aren't
   recognized would be represented in the protocol-specific "unknown-
   flags" leaf, or similar.

   Only the bits received in the protocol that aren't
   recognized would be represented in the protocol-specific "unknown-
   flags" leaf, or similar.

[...]

> The "more compact representation" also doesn't have any guidance that I'm
> aware of for general YANG modeling.  For example, if the field in question
> can fit into one of the unsigned integer types, good advice may be to pick
> the smallest unsigned integer type that can hold it.  The place where I
> expect there to be some content is whether you start such a bit vector's
> position 0 in the most significant bit, or position the bit vector's last
> bit in the least significant bit position?  (Shove to the left or right.)
> I've seen both forms in implementations.  It's also been the source of bugs
> in both forms and sometimes seen in SNMP MIB implementation issues.

I fear there is no common guidance and I agree that this a source of
trouble, in particular if these details are also left undefined in the
description statement.
 
> What I would have preferred to exist in the YANG language is a bits type
> that provides for automatic default naming for unassigned positions.  Thus,
> using your example:
> <flags>restart b1</flags>
> 
> I understand the motivations to not do this since there's a desire to have
> stable naming for the position 1 element.  Thus, we're driven to this
> discussion.

I assume there are use cases where this would be useful and perhaps
others where it is less so. But more likely nobody thought about this
13 years ago. I do not know whether we have a YANG next issue for this
but this may be an issue worth to look at if there is ever another
version of YANG.

> The motivation for the unknown-flags representation is the expectation that
> they are unusual, and it should be trivial to note the things that are
> unexpected.  One should not have to dig through the raw bits to find that
> there's one that doesn't have a mapping.  In your example above, seeing b0
> means I have to know that "restart" is given position 0 and is expected, but
> that "b1" hasn't been assigned anything.
> 
> Fundamentally, the contents of unknown flags would be, in C syntax:
> unknown_flags = ~known_flags & received_value

Yes, understood.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>