This is an old revision of the document!
Table of Contents
Discussion with the OPs ADs about YANG-Related Topics
- 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
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.
RFCs mentioned in introduction sentence - not referenced in YANG module
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. -->
Clarifying information after the reference
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”).
Another example of ambiguity
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?
Similar to the above
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 “-”.
Example of RFC section references
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";
}
Different section format in same module
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?