Differences

This shows you the differences between two versions of the page.

--- yang-ietf123 [2025/07/20 07:44] – sginoza
+++ yang-ietf123 [2026/02/12 05:44] (current) – external edit 127.0.0.1
@@ Line 5: / Line 5: @@
 "pyang -f yang --keep-comments --yang-line-length 69"
 should be used.</code>
+**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). \\
 ------------------------------
@@ Line 22: / Line 38: @@
 	Version 2 Multicast Listener Report	[RFC9777]
 </code>
+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:
@@ Line 43: / Line 65: @@
 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.
 ==== RFCs mentioned in introduction sentence - not referenced in YANG module ====
@@ Line 167: / Line 215: @@
 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?