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

Hi Jeff and WG,

One potential consideration that came to my mind is about the choice of using 'bits' at all (vs a set of Boolean leafs), and it is related to on-change telemetry.

With a leaf of type 'bits' that has on-change telemetry support, an update will return the entire bitfield. That means you don't immediately know which particular bit changed.

If a set of Boolean leafs was used instead, then a client immediately knows which specific condition changed state.

There are pros and cons to both sides of this though. With on-change and 'bits', you do get the entire bitfield in the notification. So if you want purely stateless processing, and are willing to go through the entire analysis of all the bits every time you get an on-change notification, then it works well. It also works well if you need/want to look at a combination of the bits in order to process the update in the collector/client/consuming-app.

But if you just want to immediately know exactly which item changed, with bits you would have to cache the previously received value and compare to see which bit(s) changed.

I'm not sure this is a important consideration for your proposal but wanted to bring it up in case is resonates with others.

Jason
> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Thursday, January 26, 2023 3:52 PM
> To: netmod@ietf.org
> Subject: [netmod] Modeling unknown bits in YANG (draft-haas-netmod-
> unknown-bits-00)
> 
> The following draft is hopefully a simple proposal.  It models operational
> state for protocols with bit vectors using the 'bits' type in YANG when a
> given bit position hasn't been assigned yet.
> 
> This proposal comes out of a brief inquiry to the YANG doctors while trying
> to solve the problem mentioned in the draft for the BGP YANG model.
> 
> Your feedback is appreciated and, if the proposal is acceptable, I'd suggest
> adoption by the Working Group.
> 
> Please note that the draft is on github.  I'm happy to take feedback as
> issues or pull requests there:
> 
> https://github.com/jhaas-pfrc/draft-haas-netmod-unknown-bits
> 
> -- Jeff
> 
> ----- Forwarded message from internet-drafts@ietf.org -----
> 
> Date: Thu, 26 Jan 2023 12:43:24 -0800
> From: internet-drafts@ietf.org
> To: Jeffrey Haas <jhaas@pfrc.org>
> Subject: New Version Notification for draft-haas-netmod-unknown-bits-
> 00.txt
> 
> 
> A new version of I-D, draft-haas-netmod-unknown-bits-00.txt
> has been successfully submitted by Jeffrey Haas and posted to the
> IETF repository.
> 
> Name:		draft-haas-netmod-unknown-bits
> Revision:	00
> Title:		Representing Unknown YANG bits in Operational State
> Document date:	2023-01-26
> Group:		Individual Submission
> Pages:		18
> URL:            https://www.ietf.org/archive/id/draft-haas-netmod-unknown-
> bits-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-
> bits/
> Html:           https://www.ietf.org/archive/id/draft-haas-netmod-unknown-
> bits-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-haas-netmod-
> unknown-bits
> 
> 
> Abstract:
>    Protocols frequently have fields where the contents are a series of
>    bits that have specific meaning.  When modeling operational state for
>    such protocols in YANG, the 'bits' YANG built-in type is a natural
>    method for modeling such fields.  The YANG 'bits' built-in type is
>    best suited when the meaning of a bit assignment is clear.
> 
>    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.  This cannot be done using the YANG 'bits'
>    built-in type without assigning them a name.  However, YANG
>    versioning rules do not permit renaming of named bits.
> 
>    This draft proposes a methodology to represent unknown bits in YANG
>    operational models and creates a YANG typedef to assist in uniformly
>    naming such unknown bits.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod