Hi Jürgen, Thank you for your response.
First, I would like to let you know that I will clear my DISCUSS and move my observation to a non-blocking "No Objection." This is because there are alternative approaches to displaying a bitmask I have in mind, and the observation is non-blocking from a YANG code perspective. Additionally, I will have limited availability over the next two weeks to explore the suggested type in more detail and I do not believe this issue is significantly strong to block progress for so long. That said, I still believe that a standardized bitmask type has value as a common IETF type. Consider the example of an RFC-defined administrative group as specified in [RFC 3630](https://www.rfc-editor.org/rfc/rfc3630). Section 2.5.9 defines the Administrative Group (AG) as a 32-bit bitmask where each set bit represents a unique and independent administrative group: > 2.5.9. Administrative Group > > The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the > network administrator. Each set bit corresponds to one administrative group > assigned to the interface. A link may belong to multiple groups. > > By convention, the least significant bit is referred to as 'group 0', and the > most significant bit is referred to as 'group 31'. > > The Administrative Group is also called Resource Class/Color [5]. > > The Administrative Group sub-TLV is TLV type 9, and is four octets in length. In this example, each of the 32 bits has no purpose other than representing a particular administrative group. Decoding these bits, for instance "10000100 00000000 00000000 00000001", indicates that the administrative groups corresponding to bit positions 0, 5, and 31 are set. It conveys no additional information beyond which positions are set. Similarly, Extended Administrative Groups (EAG) as defined in [RFC 7308] apply the same logic, but for multiple sets of these 32-bit bitmasks. In that scenario, a leaf-list of this type would be useful. It could also be applied to represent a bitmask associated with an IP address (e.g., a subnet mask) in a more visually intuitive manner. Currently, a workaround might be to use a uint32 or hexadecimal representation. However, such representations are not as immediately clear for operators trying to determine which bits are set at a glance. A dedicated 32-bit bitmask type would make it easier to visualize and understand which bits are active, benefiting both operational efficiency and clarity. For convenience find a mockup example that will hopefully clarify it better: module example-32bit-binary { yang-version 1.1; namespace "urn:example:32bit-binary"; prefix e32b; organization "Example Organization"; contact "mailto:[email protected]";; description "Example module defining a type for a 32-bit binary string representation."; revision "2024-12-20" { description "Initial revision."; } typedef binary-32-bits { type string { pattern "[01]{8} [01]{8} [01]{8} [01]{8}"; description "A 32-bit binary value represented as four groups of eight bits, each group separated by a single space. For example: 00011101 10100001 00011110 11010000"; } description "A type representing a 32-bit binary value displayed as a string."; } leaf admin-group { type binary-32-bits; description "An Administrative Group leaf that stores a 32-bit binary value in a spaced binary format."; } leaf-list extended-admin-group { type binary-32-bits; description "A leaf-list of 32-bit binary values, each represented as a spaced binary string."; } } Hope it provides additional context around the now non-blocking observation, Kind Regards Gunter Van de Velde ________________________________________ From: Jürgen Schönwälder <[email protected]> Sent: Wednesday, December 18, 2024 7:56:00 PM To: Gunter van de Velde (Nokia) <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-netmod-rfc6991-bis-17: (with DISCUSS) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
