Common YANG Data Types
draft-ietf-netmod-rfc6991-bis-18

This is just an observation, no changes are required: 
The shepherd write-up is 22 months old, and the template isn't up to date (2019 vice 2022).

While the change addresses my previous DISCUSS ballot (see https://mailarchive.ietf.org/arch/msg/netmod/j6miegpXfNcoLveL9wkrYOXPcHY/ ), I can only regret a misleading leaf name of 'mac-address' that is only applicable to 48-bit MAC addresses.

Also, it seems that all my COMMENT from my previous ballot were ignored; of course, they were and are still non-blocking, but they could have improved the text.

[Updated on 18 December 2024 from DISCUSS to No Objection]

# Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-rfc6991-bis-17

# Many thanks for this work. it’s been quite helpful as I continue to tinker with YANG in my daily tasks.

# 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.

#First, I would like to let you know that I will clear my blocking 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 types 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.

Each of the 32 bits in the bitmask 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:example@example.com";
  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,

Thank you to Russ Housley for the GENART review.

# Internet AD comments for draft-ietf-netmod-rfc6991-bis-17
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* "typedef protocol-number {
               If IPv6 extension headers are present, then the
       protocol number type represents the upper layer protocol
       number, i.e., the number of the last 'next header' field
       of the IPv6 extension headers."

  Surely since this can represent all values of the Next Header field this
  _could_ indicate the value of an IPv6 Extension Header?

  It seems to me that we should just say this is the value of the
  protocol/next header field wherever this numberspace is indicated, and
  that in some contexts extension headers might be skipped over and the
  ultimate next header value is what is meant in this field.

  This should be called out on a case-by-case basis, though, I would expect
  (i.e. wherever this type is used).

* ipv[46]-address-no-zone

  Why are these patterns so much more permissive than the non-zone parts
  of the address patterns?  Why not just copy the address pattern text and
  leave off the %<zone> pattern chunk?

* email-address

  This pattern seems overly permissive.  It appears to permit the RFC 5322
  S3.2.3 "specials" that are not part of "dot-atom".

  I'm no SMTP expert, but it seems like at least excluding the @ special
  might help?  E.g.

      [^@]+@[^@]+

  or something.

I support Orie's DISCUSS position.  His point about Security Considerations might draw an additional DISCUSS from the SEC ADs.

The shepherd writeup doesn't explain why Proposed Standard is being requested.  (It's fairly obvious, but I'd prefer a bit more completeness.)

I think the SHOULD [NOT]s in the "object-identifier" section could use some guidance about why they're only SHOULD [NOT].  Is there a reason one might deviate from this advice?  What's the interoperability impact of doing so?

Same question about the SHOULD under "domain-name".

Thanks for addressing my discuss and comments in https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-rfc6991-bis-18