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

• 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]

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

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 “-”.