The authors MUST include a note to the RFC Editor requesting that the appendix be removed before publication as RFC and that RFC IIII is replaced with the RFC number that is assigned to the document. Initial versions of IANA-maintained modules that are published in RFCs may be misused despite the appropriate language to refer to the IANA registry to retrieve the up-to-date module. This is problematic for interoperability, e.g., when values are deprecated or are associated with a new meaning.

• A new repository () MUST be created by the WG Chairs following the procedure in to maintain the YANG Module, with the appropriate CI/CD YANG validation in place.
  • The same procedure for managing WG documents (e.g., assign editors) applies for managing YANG modules ().
  • Refer also to for considerations related to granting WG participants write and administrators right.
  • Other administrative policies are defined in .
  • A release tagging mechanism should be defined to track the intermediate versions referenced by WG I-Ds and by the RFC, once published.
• Contributing methods to YANG module (including issues handling and merge procedure) are similar to those defined in . A procedure to assessing consensus is discussed in .
• The WG (WG Chairs) MUST seek in a timely manner after the adoption of the YANG module for the publication of an RFC that describes the initial module objectives and, more importantly, registers the URI in the "ns" subregistry within the "IETF XML Registry" and the YANG module in the "YANG Module Names" subregistry within the "YANG Parameters" registry.
  • Unless we update these rules as well, the publication of the initial RFC is required per , especially the following: "There are no initial assignments. For allocation, RFC publication is required"
• The YANG module MUST NOT be inserted in the document; instead a link to the above repository MUST be included.
• Bis versions of the initial RFC MAY be considered to document major changes and their rationale. Such a decision is left to the WG. The RFC update is scoped to the narrative part describing the updates. WGs may decide to maintain an adopted YANG module in the IETF repository but never seek for an RFC publication of major module revisions.
• Bis versions of the initial RFC should be developed by the same WG which was responsible for producing the intial RFC. If the responsible WG concluded, the alternative WG should be consulted with the ADs.
• All adopted IETF modules are also mirrored in a common IETF repository.

• DISCUSSION: Include a recommendation about the hosting. IANA or some IETF gitlab are examples of self-hosting. Example of third-part hosted facility is GitHub.

• Ease integration for operators by providing readily-available YANG code in a well-identified location.
• Encourage an iterative approach that would fit most of operators needs, rather than waiting for a "perfect" version that solves every deployment case.
• Catalyst to produce fully-validated modules in a timely manner.
• Ease reuse/leveraging by other organizations and hopefully avoid redundant efforts.
• Welcome contributors from the operators community who are more familiar with software development, not only with specification development.