[netmod] Re: Gunter Van de Velde's Discuss on draft-ietf-netmod-rfc6991-bis-17: (with DISCUSS)

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

On Wed, Dec 11, 2024 at 05:22:44AM -0800, Gunter Van de Velde via Datatracker wrote:
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-netmod-rfc6991-bis-17: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> # Upon reviewing MPLS-TE Administrative Groups as defined in OSPFv2 (RFC 3630),
> OSPFv3 (RFC 5329), IS-IS (RFC 5305), and (Extended-)Administrative-Groups (RFC
> 7308), I noted that these RFCs define and utilize 32-bit bitmasks, or sets of
> 32-bit bitmasks, for (Extended-)Administrative-Groups. While a 32-bit bitmask
> can be represented as a decimal uint32 value, it may be more operationally
> useful—especially within YANG models—to display these values directly as
> bitmasks.
> 
> I am therefore raising this DISCUSS to consider adding a dedicated bitmask type
> to facilitate this form of representation as a common type.
>

I am not sure what is proposed here. Note that there have been several
discussions related to bits and their representation in YANG modules.
It seems that there is not a simple type that addresses all issues
that come up. How bits or bit masks are exposed in a management
interface seems to be specific to what the bits mean. There also was a
discussion at some point in time how to deal with bits that are at
some time unallocated but later allocated. See for example
draft-haas-netmod-unknown-bits-02.txt. To me, it seems the proper
action would be to write guidelines discussing the pros and cons of
different approaches to represent bits and bit masks. In general it
would be good if we would have a collection of YANG design pattern but
so far this idea never really took off (i.e., nobody found the time to
do the work).

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany