• YANG formatting
  • with formatting being a step recommended by draft-ietf-netmod-rfc8407bis-28, does the RPC need to continue to check the format?
    

    To ensure that a module fits into the line limits  of an I-D, the command
    "pyang -f yang --keep-comments --yang-line-length 69" 
    should be used.

Discussion (7/20/2025):

Conclusion: continue to use pyang to format

pyang not being actively maintained - still works but not being updated. yanglint is more current compared with pyang.

Q: What checkers do YANG docs use? Do they rely on the datatracker? A: No. They usually run their own checks.

Add link to wiki pointing to YANG template (template for drafting I-D with YANG).
Add pointer from authors.ietf.org.
Mahesh/Med to add pointer from YANG pages (from OPs wiki).

• IANA-maintained modules: how to ensure the module in the document matches the current registry? For example:
  Iana-icmpv6-types - where RFC 3810 has been obsoleted by RFC 9777. In this case, the RPC should notice the obsolete reference as part of our checks, but we would not know about things like additions to the registry since the module was generated.
  

  https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/17/
  }
          enum Version2MulticastListenerReport {
            value 143;
            description
              "Version 2 Multicast Listener Report.";
            reference
              "RFC 3810";
          }
  
  ICMPv6 "type" Numbers registry (https://www.iana.org/assignments/icmpv6-parameters/):
  143	Version 2 Multicast Listener Report	[RFC9777]

Ideally, have authors and IANA use the same script to generate the modules of registries. Then do not need to edit or check the references.

Q: are there any IANA-maintained modules that are not of a registry? A: don't think so.

Mahesh - a few different issues:

• What happens if registry changes since the authors created the initial version of the module?

• Do we need to check for reference updates?

• How does hte process differ between an IANA-maintained module and an IETF module? If someone wants source, should they look at RFC or repository -- which is the official source? What do we do to make sure changes are reflected back and forth?

• Potential to have modules not published in RFCs, but point to official repository. How does the doc get updated to point to the current thing.
  • could the repository point to the update?

• Reference format: format of references other than RFCs (i.e., other than what is shown in 8407bis
  • Section 3.2, Code Components
  • Section 3.5, Narrative Sections

These are some quick examples of possible issues with references in YANG modules for the meeting between RPC and YANG ODs during IETF 123 on 20 July 2025.

Discussion (7/20/2025):

Issues:

• Q: What should the intro text cover? References should be captured as document reference.
  • A: should contain all RFCs that module is referencing, directly or indirectly.
  • format: RFC XXXX: title, section.

need tool to check refs in module match intro text. no currently defined guidance to authors on how to do intro text.

In addition to references already cited, this module also references/imports from:

intentional: - not enforcing that intro text be comprehensive - allowing intro text to refer to IMPORTs and/or references

Need to clarify how it works if YANG modules are removed from RFC before publication. Consider: if modules removed from the document, then they won't be read by the editor.

Reference format: - add section number example to 8407bis should not include “topics” or “keywords” - specify sections, table, etc.

draft-ietf-ospf-sr-yang-50

[RFC2328], [RFC4915], [RFC5340], [RFC6991], [RFC8102], [RFC8294], [RFC8349], [RFC9587], and [RFCYYY1] are referenced in the YANG

<!-- [rfced] Note to PE:
 
Current:
   [RFC2328], [RFC4915], [RFC5340], [RFC6991], [RFC8102], [RFC8294],
   [RFC8349], [RFC9587], and [RFCYYY1] are
   referenced in the YANG module.
 
[RFC2328] and [RFC5340] do not appear to be referenced in the YANG module.
-->

draft-ietf-i2nsf-capability-data-model-32

identity dscp {
  base ipv4;
  base ipv6;
  description
    "Identity for the capability of matching IPv4 annd IPv6
     Differentiated Services Codepoint (DSCP) condition";
  reference
    "RFC 791: Internet Protocol - Type of Service
     RFC 2474: Definition of the Differentiated
     Services Field (DS Field) in the IPv4 and
     IPv6 Headers
     RFC 8200: Internet Protocol, Version 6 (IPv6)
     Specification - Traffic Class";
}

What is the content after the '-'? How should we define the follows the reference title? In this case, “Type of Service” from RFC 791 is a part of the “Internet Header Format” defined in Section 3.1 of RFC 791. “Traffic Class” is a part of the “IPv6 Header Format” defined in Section 3 of RFC 8200 (note that there is a section in RFC 8200 title “Traffic Classes”).

draft-ietf-i2nsf-capability-data-model-32

identity icmp {
  base protocol;
  description
    "Base identity for ICMPv4 and ICMPv6 condition capability";
  reference
    "RFC 792: Internet Control Message Protocol
     RFC 4443: Internet Control Message Protocol (ICMPv6)
     for the Internet Protocol Version 6 (IPv6) Specification
     - ICMPv6";
}

“ICMPv6” appears in multiple places throughout this document - the short title is “ICMPv6 (ICMP for IPv6)”, Section 2 is titled “ICMPv6 (ICMP for IPv6)”, etc. What exactly is meant by adding “ICMPv6” after the number and title of the RFC?

draft-ietf-i2nsf-capability-data-model-32

leaf-list ipv6-capability {
  type identityref {
    base ipv6;
  }
  description
    "IPv6 packet capabilities";
  reference
    "RFC 8200: Internet Protocol, Version 6 (IPv6)
     Specification - IPv6";
}

another example of the ambiguity after the “-”.

draft-ietf-ospf-sr-yang-50

identity prefix-sid-flag {
  description
    "Base identity for prefix SID sub-TLV flags.";
  reference
    "RFC 8665: OSPF Extensions for Segment Routing, Section 5
     RFC 8666: OSPFv3 Extensions for Segment Routing, Section 6";
}

draft-ietf-ospf-sr-yang-50

augment "/rt:routing/"
      + "rt:control-plane-protocols/rt:control-plane-protocol/"
      + "ospf:ospf/ospf:areas/"
      + "ospf:area/ospf:database/"
      + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/"
      + "ospf:area-scope-lsa/ospf:version/ospf:ospfv2/"
      + "ospf:ospfv2/ospf:body/ospf:opaque/"
      + "ospf:extended-prefix-opaque" {
  when "derived-from(/rt:routing/rt:control-plane-protocols/"
     + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
    description
      "This augmentation is only valid for OSPFv2.";
  }
  description
    "SR Extended Prefix Range TLV in OSPFv2 Type 10 (area-scoped)
     Extended Prefix Opaque LSAs.";
  reference
    "RFC 8665: OSPF Extensions for Segment Routing
     (Section 4)";
  uses ospfv2-extended-prefix-range-tlvs;
}

Section number placed in parentheses rather than after a “-”.

New item introduced by Mahesh:

Revisions of modules: will start to see more of these. If module is not backwards compatible, need check to make sure module importing it is updated.
Older RFC might point to older RFC in imports statement, which could cause problems.
Potential options for module users:

• continue to reference older version
  • if this is the case, then the statement needs to indicate which version of the module should be pulled
• pull from the new version
  • make changes needed to make it compatible

RPC: need to check for updates relationships, not only obsoleting ones

Want to see which docs reference the RFC https://datatracker.ietf.org/doc/rfc6991/referencedby/ These are backward compatible, but what if weren’t

For I-Ds, if bis doc published before the I-Ds are published, should the ref in the I-D be updated? If author says no, They need to add version statement to specify which version they’re using

AQ: if reference is mentioned in module, need to also check for updates

• Obsoletes, they need to fix
• Updates, AQ if any changes are needed? Add version statement or update reference to point to bis RFC

Is there a tool to flag this early?

RFC A → imports from RFC B
RFC B → updated by Internet-Draft C
When I-D C is approved and enters the RFC Editor queue,
Docs that rely on RFC B need to notified that they should consider updates to their drafts to account I-D C

Tool idea: Requires that the intro text to the module mention ALL RFC/refs in the module.

I-D C approved, notify all authors of drafts that ref I-D C to consider updates based on I-D C.

RPC still needs check to catch these if author has not addressed the issue. How to check for this?

How to actively notify draft authors? - intended status notifications? - referenced by notifications?