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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-netmod-rfc6991-bis and RFC 9911, changed IESG state to RFC Published)

There are two COMMENTs that the RFC Editor should be aware of.

- There is no note to the RFC Editor, but RFC XXXX refers to the document in question.
- There is a reference to IEEE-802-2001, but it might be worthwhile checking if IEEE-802-2014 might be a better reference.

[Ballot comment]
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.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Shepherd:

  Proposed Standard.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Shepherd (from the Abstract):

    This document defines a collection of common data types to be
    used with the YANG data modeling language. This version of the
    document adds several new type definitions and obsoletes RFC 6991.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Shepherd:

  There was a great debate with regards to if the "ipv[46]-address"
  types defined in RFC 6021 should be changed to not support zones.
  Despite RFC 6991 defining "ipv[46]-address-no-zone" types, many
  continued to be surprised that a zone could be configured.  There
  was a rough 50/50 split, to which the chairs decided that no change
  was the most conservative action. 

  There was a last-ditch proposal that seemed viable (to add an
  "ipv[46]-address-with-zone" type and deprecate the existing
  "ipv[46]-address" type, i.e., to have no default) didn't get
  enough support for the chairs to veer off of their "no change"
  decision.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Shepherd:

  The Shepherd is unaware of implementations or commitments,
  but the modules defined in this document are absolutely
  fundamental, so much as that they're coded into the YANG
  utilities `pyang` and `yanglint`, that there is no doubt
  the definitions in this document have been scrutinized.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:

  The Shepherd is Kent Watsen.
  The responsible AD is Mahesh Jethanandani.



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Shepherd:

  The Shepherd reread the entire document, which led to requesting
  an update to address numerous non-technical issues that were
  addressed in the -15 update.

  The Shepherd validated the syntactical correctness of the two
  modules defined in this document using both `yanglint` and `pyang`,
  with neither returning any errors or warnings.

      $ yanglint ietf-yang-types@2023-01-23.yang
      $ yanglint ietf-inet-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-yang-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-inet-types@2023-01-23.yang



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Shepherd:

  The Shepherd does not, anymore, have concerns about
  the depth or breadth of the reviews that have been
  performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Shepherd:

  The Shepherd does not believe that portions of the document
  need review from a particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Shepherd:

  The Shepherd has no specific concerns or issues with this document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Shepherd:

  The authors confirmed that he is unaware of any IPR related to
  this document.

  Here is the link to the IPR call request:
      https://mailarchive.ietf.org/arch/msg/netmod/ZMHBDiBvFfLRjV4EDH9D9V5eOj8



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Shepherd:

  No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Shepherd:

  WG consensus behind this document is reasonably strong, as a
  number of folks engaged in discussions over the course of time.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Shepherd:

  No one has threatened an appeal or otherwise indicated
  discontent (extreme or otherwise).



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Shepherd:

  Idnits was tested against -15, which has a number of "line too long"
  warnings, all of which are due to the author using UTF-8 encodings
  for his name.


  Idnits generated the following warning, which is okay given the document
  explicitly identified invaliad IP address ranges:

    == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.


  Idnits also generated this warning, for which I cannot determine why:

    Miscellaneous warnings:
    ----------------------------------------------------------------------------
 
    == The document seems to contain a disclaimer for pre-RFC5378 work, but was
      first submitted on or after 10 November 2008.  The disclaimer is usually
      necessary only for documents that revise or obsolete older RFCs, and that
      take significant amounts of text from those RFCs.  If you can contact all
      authors of the source material and they are willing to grant the BCP78
      rights to the IETF Trust, you can and should remove the disclaimer.
      Otherwise, the disclaimer is needed and you can ignore this comment.
      (See the Legal Provisions document at
      https://trustee.ietf.org/license-info for more information.)




(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:

  The document is written by a YANG Doctor, and hence did not go through a
  YANG Doctor review.



(13) Have all references within this document been identified as either normative or informative?

Shepherd:

  Yes, all the references have been reviewed to be correct.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Shepherd:

  All normative references are published.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Shepherd:

  There are no downward normative references.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Shepherd:

  The publication of this document obsoletes RFC 6991, and it is listed
  as such in the title page header, listed in the abstract, and discussed
  in the introduction.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Shepherd:

  The IANA Considerations section only registers the YANG modules
  and their namespaces.  The registrations look proper, except the
  following change should be applied to reflect latest guidance:

    OLD: Registrant Contact: The NETMOD WG of the IETF.
    NEW: Registrant Contact: The IESG



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Shepherd:

  None of the IANA registration requests require expert review.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Shepherd:

  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint ietf-yang-types@2023-01-23.yang
      $ yanglint ietf-inet-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-yang-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-inet-types@2023-01-23.yang


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Shepherd:

  The Shepherd tested the formatting using these two commands:

    $ pyang -f yang --keep-comments --yang-line-length 69 \
      ietf-yang-types@2023-01-23.yang > new.yang && diff \
      ietf-yang-types@2023-01-23.yang new.yang

    $ pyang -f yang --keep-comments --yang-line-length 69
      ietf-inet-types@2023-01-23.yang > new.yang && diff
      ietf-inet-types@2023-01-23.yang new.yang


  Both of which produced substantial albiet innocuous diffs.
  For example, the author chose to indent one less character
  in 'description' statements which, honestly, is equally
  readable, and some may argue as better.  In another example,
  the formatting output was clearly worse, and so immediately
  discounted.  None of the formatting was structually improved.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-netmod-rfc6991-bis-17
CC @evyncke

Thank you for the work put into this document and thanks for your patience for my ballot.

Please find below one blocking DISCUSS points (easy to address by the shepherd and the author), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Kent Watsen for the shepherd's write-up (using the old template though), *but it lacks* the WG consensus and the justification of the intended status.

Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc6991-bis-17-intdir-telechat-fressancourt-2024-12-12/ (and I have read the author's reply)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Shepherd's write-up

Please update the responsible AD as it is no more Rob Wilton.

`Idnits also generated this warning, for which I cannot determine why:` explanation should be given though. It is mainly about pre-RFC5378 copyright (RFC 6991) but as the author of this I-D is the same as the RFC 6991, he has the right privilege

### Section 3

`typedef mac-address` and `pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';` is incorrect as there are also 16-bit and 64-bit MAC addresses (notably for IEEE 802.15.4).

[Ballot comment]

## COMMENTS (non-blocking)

### Abstract & introduction

AFAIK, YANG has several versions, should the document specify to which version(s) it is applicable ?


### Section 2

Please add a note to the RFC editor with instruction about `RFC XXXX` *before* using it.

### Section 3

s/each octet represented by two hexadecimal numbers/each octet represented by two hexadecimal digits/

### Section 4

I support Erik Kline's comments about several IP-layer-related data types (also indicated by Antoine).

### Section 9

`IEEE-802-2001` is quite outdated... there is a newer version dated 2014. Should it be normative ?

## NITS (non-blocking / cosmetic)

### Uppercase for acronyms

s/uri/URI/ and possibly other occurrences.

[Ballot comment]
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".

[Ballot comment]
[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,

[Ballot comment]
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).

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-netmod-rfc6991-bis-17
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc6991-bis-17.txt&submitcheck=True

* 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/

## Discuss

Thanks to Bron Gondwana for the ARTART Review.
I see: https://mailarchive.ietf.org/arch/msg/netmod/nXYnXH3oBBADXyW8YmWGMQnPb1M/

"""
The decision on whether it's more important to try to align everything we can to the more sensible handling of 'Z' and -00:00, or leave things how they are, is beyond my pay grade!  I'll leave it for the IESG to weight the pros and cons.
"""

### Time

And the relevant comments from the authors: https://mailarchive.ietf.org/arch/msg/netmod/PePGt7_5e-R9xMDIebRt1edDTBs/

```
unfortunate. I will update the definitions of 'date' and 'time' to
follow RFC 9557 but I will not touch 'date-and-time' for now unless
lets say the IESG decides that alignment with RFC 9557 is more
important than our concerns about compliance of existing
implementations generating canonical representations.
```

The text in -17:

```
639         (b) The time-offset -00:00 indicates that the date-and-time
640             value is reported in UTC and that the local time zone
641             reference point is unknown. The time-offsets +00:00 and Z
642             both indicate that the date-and-time value is reported in
643             UTC and that the local time reference point is UTC (see RFC
644             3339 section 4.3).
```

In contrast to the section which Bron encouraged the authors to cite which states:

```
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "Z". (The original version of this specification provided -00:00 for this purpose, which is not allowed by [ISO8601:2000] and therefore is less interoperable; Section 3.3 of [RFC5322] describes a related convention for email, which does not have this problem). This differs semantically from an offset of +00:00, which implies that UTC is the preferred reference point for the specified time.
```

and

```
Also note that the fact that [ISO8601:2000] and later do not allow -00:00 as a local offset reduces the level of interoperability that can be achieved in using this feature; however, the present specification does not formally deprecate this syntax. With the update to [RFC3339], the local offset Z should now be used in its place.
```

See the full details at: https://datatracker.ietf.org/doc/html/rfc9557#section-2.2

I think you should make it clearer that 'date-and-time' is not compliant with RFC9557 but 'date' and 'time' are.

There is currently no text in the document which comments on this.

I could not find a reference in RFC6020 to support the comment on the list "Note that RFC6020 picked -00:00 as the canonical representation for values in UTC with an unknown local time-offset."
I assume you mean RFC6021, which has the following text:

```

      The date-and-time type is compatible with the dateTime XML
      schema type with the following notable exceptions:

      (a) The date-and-time type does not allow negative years.

      (b) The date-and-time time-offset -00:00 indicates an unknown
          time zone (see RFC 3339) while -00:00 and +00:00 and Z all
          represent the same time zone in dateTime.

      (c) The canonical format (see below) of data-and-time values
          differs from the canonical format used by the dateTime XML
          schema type, which requires all times to be in UTC using the
          time-offset 'Z'.
```

I suggest something like:

RFC6021 defined the canonical format for date-and-time in a way that is not directly compatible with dateTime XML Schema type, or the guidance provided in RFC 9557 which updated RFC 3339.
If the time in UTC is known, but the offset to local time is unknown, this SHOULD be represented with an offset of "Z", and MAY be represented using "-00:00" for backwards compatibility.
Note that "Z" and "-00:00" are semantically different from an offset of +00:00, which implies that UTC is the preferred reference point for the specified time.

### URI Normalization

```
1675         6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
1676         percent-encoding is removed, and all case-insensitive
1677         characters are set to lowercase except for hexadecimal
1678         digits within a percent-encoded triplet, which are
1679         normalized to uppercase as described in Section 6.2.2.1
1680         of RFC 3986.

1682         The purpose of this normalization is to help provide
1683         unique URIs.  Note that this normalization is not
1684         sufficient to provide uniqueness.  Two URIs that are
1685         textually distinct after this normalization may still be
1686         equivalent.
```

What is unnecessary percent-encoding?

It seems wise to comment on unicode directly here, as you have for A-Labels regarding IDNA.

Also what is the value of producing unique URIs if not for comparison / equivalence checks?

### Did you mean A-Labels?

```
1723         The domain part may use both A-labels and U-labels
1724         (see RFC 5890). The canonical format of the domain part
1725         uses lowercase characters and U-labels (RFC 5890) where
1726         applicable.";
```

Seems strange to suggest U-Labels in a canonical format.

Also, is there a relevant length restriction here?

https://datatracker.ietf.org/doc/html/rfc5890#section-4.2

Consider just lifting the text for this section directly from: https://datatracker.ietf.org/doc/html/rfc6531#section-3.2

```
  When doing lookups, the SMTPUTF8-aware SMTP client or
  server MUST either use a Unicode-aware DNS library, or transform the
  internationalized domain name to A-label form (i.e., a fully-
  qualified domain name that contains one or more A-labels but no
  U-labels)
```

I believe this was Bron's comment as well.

[Ballot comment]
## Comments

### SHOULD NOT use counter32 when ...

Should this be normative guidance? It seems like normative guidance to me.

```
13         description of a schema node using this type.  If such
414         other times can occur, for example, the instantiation of
415         a schema node of type counter32 at times other than
416         re-initialization, then a corresponding schema node
417         should be defined, with an appropriate type, to indicate
418         the last discontinuity.
```

### SHOULD NOT use default statement

```
477         The counter64 type should not be used for configuration
478         schema nodes.  A default statement SHOULD NOT be used in
479         combination with the type counter64.
```

I wonder under which circumstances can this advice be ignored.
It seems like it is natural for any type that has no defined initial value, that a default statement MUST NOT be used.

### What about leap seconds?

Not sure if leap seconds matter for YANG, iirc, they can sometimes be relevant for GPS systems.

```
634         The date-and-time type is compatible with the dateTime XML
635         schema dateTime type with the following notable exceptions:
```

```
Because the dateTime type and other date- and time-related types defined in this specification do not support leap seconds, there are portions of the ·UTC· timeline which cannot be represented by values of these types. Users whose applications require that leap seconds be represented and that date/time arithmetic take historically occurring leap seconds into account will wish to make appropriate adjustments at the application level, or to use other types.
```

- https://www.w3.org/TR/xmlschema11-2/#d-t-values
- https://www.rfc-editor.org/rfc/rfc3339#appendix-D


### Securing Considerations

```
1759   This document defines common data types using the YANG data modeling
1760   language.  The definitions themselves have no security impact on the
1761   Internet, but the usage of these definitions in concrete YANG modules
1762   might have.  The security considerations spelled out in the YANG
1763   specification [RFC7950] apply for this document as well.
```

This document incorporates URI normalization, datetimes, and internationalized email addresses and domain names by reference.

You should repeat security considerations for at least a few of these topics here.

For example:

- https://datatracker.ietf.org/doc/html/rfc3339#section-7
- https://datatracker.ietf.org/doc/html/rfc3986#section-7.2
- https://datatracker.ietf.org/doc/html/rfc5890#section-4.2

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

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc6991-bis-17.txt

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

I am therefore raising this DISCUSS to consider adding a dedicated bitmask type to facilitate this form of representation as a common type.

[Ballot comment]
# 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 % 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.

If memory serves me right, more edits are planned for this document. Juergen will correct me if I am wrong. I will wait for an update or a correction to my statement before sending this to IESG.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netmod-rfc6991-bis-16. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-yang-types
URI: urn:ietf:params:xml:ns:yang:ietf-yang-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-inet-types
URI:urn:ietf:params:xml:ns:yang:ietf-inet-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-yang-types
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-types
Prefix: yang
Module:
Reference: [ RFC-to-be ]

Name: ietf-inet-types
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-inet-types
Prefix: inet
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

IANA Question --> Should other references to RFC6691 in https://www.iana.org/assignments/yang-sid be updated to point to [ RFC-to-be ] instead of RFC6691?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-08):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netmod-rfc6991-bis@ietf.org, kent+ietf@watsen.net, mjethanandani@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Common YANG Data Types) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'Common YANG Data Types'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a collection of common data types to be used
  with the YANG data modeling language.  This version of the document
  adds several new type definitions and obsoletes RFC 6991.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/



No IPR declarations have been submitted directly on this I-D.

Changed action holders to Jürgen Schönwälder, Mahesh Jethanandani, Kent Watsen (Jurgen to address expert review comments. Kent, could you track, and let me know when the document is ready for IETF LC. Thanks.)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Shepherd:

  Proposed Standard.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Shepherd (from the Abstract):

    This document defines a collection of common data types to be
    used with the YANG data modeling language. This version of the
    document adds several new type definitions and obsoletes RFC 6991.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Shepherd:

  There was a great debate with regards to if the "ipv[46]-address"
  types defined in RFC 6021 should be changed to not support zones.
  Despite RFC 6991 defining "ipv[46]-address-no-zone" types, many
  continued to be surprised that a zone could be configured.  There
  was a rough 50/50 split, to which the chairs decided that no change
  was the most conservative action. 

  There was a last-ditch proposal that seemed viable (to add an
  "ipv[46]-address-with-zone" type and deprecate the existing
  "ipv[46]-address" type, i.e., to have no default) didn't get
  enough support for the chairs to veer off of their "no change"
  decision.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Shepherd:

  The Shepherd is unaware of implementations or commitments,
  but the modules defined in this document are absolutely
  fundamental, so much as that they're coded into the YANG
  utilities `pyang` and `yanglint`, that there is no doubt
  the definitions in this document have been scrutinized.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:

  The Shepherd is Kent Watsen.
  The responsible AD is Robert Wilton.



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Shepherd:

  The Shepherd reread the entire document, which led to requesting
  an update to address numerous non-technical issues that were
  addressed in the -15 update.

  The Shepherd validated the syntactical correctness of the two
  modules defined in this document using both `yanglint` and `pyang`,
  with neither returning any errors or warnings.

      $ yanglint ietf-yang-types@2023-01-23.yang
      $ yanglint ietf-inet-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-yang-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-inet-types@2023-01-23.yang



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Shepherd:

  The Shepherd does not, anymore, have concerns about
  the depth or breadth of the reviews that have been
  performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Shepherd:

  The Shepherd does not believe that portions of the document
  need review from a particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Shepherd:

  The Shepherd has no specific concerns or issues with this document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Shepherd:

  The authors confirmed that he is unaware of any IPR related to
  this document.

  Here is the link to the IPR call request:
      https://mailarchive.ietf.org/arch/msg/netmod/ZMHBDiBvFfLRjV4EDH9D9V5eOj8



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Shepherd:

  No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Shepherd:

  WG consensus behind this document is reasonably strong, as a
  number of folks engaged in discussions over the course of time.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Shepherd:

  No one has threatened an appeal or otherwise indicated
  discontent (extreme or otherwise).



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Shepherd:

  Idnits was tested against -15, which has a number of "line too long"
  warnings, all of which are due to the author using UTF-8 encodings
  for his name.


  Idnits generated the following warning, which is okay given the document
  explicitly identified invaliad IP address ranges:

    == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.


  Idnits also generated this warning, for which I cannot determine why:

    Miscellaneous warnings:
    ----------------------------------------------------------------------------
 
    == The document seems to contain a disclaimer for pre-RFC5378 work, but was
      first submitted on or after 10 November 2008.  The disclaimer is usually
      necessary only for documents that revise or obsolete older RFCs, and that
      take significant amounts of text from those RFCs.  If you can contact all
      authors of the source material and they are willing to grant the BCP78
      rights to the IETF Trust, you can and should remove the disclaimer.
      Otherwise, the disclaimer is needed and you can ignore this comment.
      (See the Legal Provisions document at
      https://trustee.ietf.org/license-info for more information.)




(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:

  The document is written by a YANG Doctor, and hence did not go through a
  YANG Doctor review.



(13) Have all references within this document been identified as either normative or informative?

Shepherd:

  Yes, all the references have been reviewed to be correct.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Shepherd:

  All normative references are published.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Shepherd:

  There are no downward normative references.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Shepherd:

  The publication of this document obsoletes RFC 6991, and it is listed
  as such in the title page header, listed in the abstract, and discussed
  in the introduction.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Shepherd:

  The IANA Considerations section only registers the YANG modules
  and their namespaces.  The registrations look proper, except the
  following change should be applied to reflect latest guidance:

    OLD: Registrant Contact: The NETMOD WG of the IETF.
    NEW: Registrant Contact: The IESG



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Shepherd:

  None of the IANA registration requests require expert review.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Shepherd:

  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint ietf-yang-types@2023-01-23.yang
      $ yanglint ietf-inet-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-yang-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-inet-types@2023-01-23.yang


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Shepherd:

  The Shepherd tested the formatting using these two commands:

    $ pyang -f yang --keep-comments --yang-line-length 69 \
      ietf-yang-types@2023-01-23.yang > new.yang && diff \
      ietf-yang-types@2023-01-23.yang new.yang

    $ pyang -f yang --keep-comments --yang-line-length 69
      ietf-inet-types@2023-01-23.yang > new.yang && diff
      ietf-inet-types@2023-01-23.yang new.yang


  Both of which produced substantial albiet innocuous diffs.
  For example, the author chose to indent one less character
  in 'description' statements which, honestly, is equally
  readable, and some may argue as better.  In another example,
  the formatting output was clearly worse, and so immediately
  discounted.  None of the formatting was structually improved.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Shepherd:

  Proposed Standard.



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Shepherd (from the Abstract):

    This document defines a collection of common data types to be
    used with the YANG data modeling language. This version of the
    document adds several new type definitions and obsoletes RFC 6991.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Shepherd:

  There was a great debate with regards to if the "ipv[46]-address"
  types defined in RFC 6021 should be changed to not support zones.
  Despite RFC 6991 defining "ipv[46]-address-no-zone" types, many
  continued to be surprised that a zone could be configured.  There
  was a rough 50/50 split, to which the chairs decided that no change
  was the most conservative action. 

  There was a last-ditch proposal that seemed viable (to add an
  "ipv[46]-address-with-zone" type and deprecate the existing
  "ipv[46]-address" type, i.e., to have no default) didn't get
  enough support for the chairs to veer off of their "no change"
  decision.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Shepherd:

  The Shepherd is unaware of implementations or commitments,
  but the modules defined in this document are absolutely
  fundamental, so much as that they're coded into the YANG
  utilities `pyang` and `yanglint`, that there is no doubt
  the definitions in this document have been scrutinized.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:

  The Shepherd is Kent Watsen.
  The responsible AD is Robert Wilton.



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Shepherd:

  The Shepherd reread the entire document, which led to requesting
  an update to address numerous non-technical issues that were
  addressed in the -15 update.

  The Shepherd validated the syntactical correctness of the two
  modules defined in this document using both `yanglint` and `pyang`,
  with neither returning any errors or warnings.

      $ yanglint ietf-yang-types@2023-01-23.yang
      $ yanglint ietf-inet-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-yang-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-inet-types@2023-01-23.yang



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Shepherd:

  The Shepherd does not, anymore, have concerns about
  the depth or breadth of the reviews that have been
  performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Shepherd:

  The Shepherd does not believe that portions of the document
  need review from a particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Shepherd:

  The Shepherd has no specific concerns or issues with this document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Shepherd:

  The authors confirmed that he is unaware of any IPR related to
  this document.

  Here is the link to the IPR call request:
      https://mailarchive.ietf.org/arch/msg/netmod/ZMHBDiBvFfLRjV4EDH9D9V5eOj8



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Shepherd:

  No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Shepherd:

  WG consensus behind this document is reasonably strong, as a
  number of folks engaged in discussions over the course of time.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Shepherd:

  No one has threatened an appeal or otherwise indicated
  discontent (extreme or otherwise).



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Shepherd:

  Idnits was tested against -15, which has a number of "line too long"
  warnings, all of which are due to the author using UTF-8 encodings
  for his name.


  Idnits generated the following warning, which is okay given the document
  explicitly identified invaliad IP address ranges:

    == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.


  Idnits also generated this warning, for which I cannot determine why:

    Miscellaneous warnings:
    ----------------------------------------------------------------------------
 
    == The document seems to contain a disclaimer for pre-RFC5378 work, but was
      first submitted on or after 10 November 2008.  The disclaimer is usually
      necessary only for documents that revise or obsolete older RFCs, and that
      take significant amounts of text from those RFCs.  If you can contact all
      authors of the source material and they are willing to grant the BCP78
      rights to the IETF Trust, you can and should remove the disclaimer.
      Otherwise, the disclaimer is needed and you can ignore this comment.
      (See the Legal Provisions document at
      https://trustee.ietf.org/license-info for more information.)




(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:

  The document is written by a YANG Doctor, and hence did not go through a
  YANG Doctor review.



(13) Have all references within this document been identified as either normative or informative?

Shepherd:

  Yes, all the references have been reviewed to be correct.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Shepherd:

  All normative references are published.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Shepherd:

  There are no downward normative references.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Shepherd:

  The publication of this document obsoletes RFC 6991, and it is listed
  as such in the title page header, listed in the abstract, and discussed
  in the introduction.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Shepherd:

  The IANA Considerations section only registers the YANG modules
  and their namespaces.  The registrations look proper, except the
  following change should be applied to reflect latest guidance:

    OLD: Registrant Contact: The NETMOD WG of the IETF.
    NEW: Registrant Contact: The IESG



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Shepherd:

  None of the IANA registration requests require expert review.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Shepherd:

  The Shepherd validated the syntactical correctness of the module
  using both `yanglint` and `pyang`, with neither returning any
  errors or warnings.

      $ yanglint ietf-yang-types@2023-01-23.yang
      $ yanglint ietf-inet-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-yang-types@2023-01-23.yang
      $ pyang --ietf --strict ietf-inet-types@2023-01-23.yang


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Shepherd:

  The Shepherd tested the formatting using these two commands:

    $ pyang -f yang --keep-comments --yang-line-length 69 \
      ietf-yang-types@2023-01-23.yang > new.yang && diff \
      ietf-yang-types@2023-01-23.yang new.yang

    $ pyang -f yang --keep-comments --yang-line-length 69
      ietf-inet-types@2023-01-23.yang > new.yang && diff
      ietf-inet-types@2023-01-23.yang new.yang


  Both of which produced substantial albiet innocuous diffs.
  For example, the author chose to indent one less character
  in 'description' statements which, honestly, is equally
  readable, and some may argue as better.  In another example,
  the formatting output was clearly worse, and so immediately
  discounted.  None of the formatting was structually improved.