Differences

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

--- yang-ietf123 [2025/07/20 07:40] – 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). \\
+------------------------------
   * IANA-maintained modules: how to ensure the module in the document matches the current registry?  For example: \\ [[https://www.iana.org/assignments/yang-parameters/|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. \\ <code>
@@ Line 21: / Line 39: @@
 </code>
-Mahesh - 3 different issues:
+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?
@@ Line 28: / Line 52: @@
   * 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
@@ Line 37: / 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 161: / 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?