]> YANG deVELpment PrOCEss & maintenance (VELOCE) Orange
mohamed.boucadair@orange.com
quick but well YANG modules This document describes a YANG deVELpment PrOCEss & maintenance (VELOCE) that is more suitable for the development of YANG modules within the IETF. Discussion Venues Source for this draft and an issue tracker can be found at .
Introduction RFCs are not suited for documenting and maintaining YANG modules. However, implementers/vendors are looking for reference models and sufficiently stable models to refer to. To that aim, this document proposes a new approach for documenting IETF-endorsed YANG modules. Guidance for writing YANG modules are discussed in . Guidelines related to code components () or citations to references listed in the YANG module do not apply for VELOCE. This document mainly focuses on IETF modules. Note that includes provisons for IANA-maintained modules to not be included in RFCs:
Designers of IANA-maintained modules MAY supply the full initial version of the module in a specification document that registers the module or only a script to be used (including by IANA) for generating the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108]).
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
VELOCE Procedure The following procedure is followed when a WG adopts a YANG module:
  • 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 andd 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.
Security Considerations The same considerations discussed in apply here.
IANA Considerations This document has no IANA actions.
References Normative References Guidelines for Authors and Reviewers of Documents Containing YANG Data Models YumaWorks Orange Huawei This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Working Group GitHub Usage Guidance This document provides a set of guidelines for working groups that choose to use GitHub for their work. IETF Working Group Guidelines and Procedures This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Working Group GitHub Administration The use of GitHub in IETF working group processes is increasing. This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub. YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References The IETF XML Registry This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
Acknowledgments This draft is triggered by the discussion in NEMOPS IAB workshop. Thanks to Kristian Larsson and Italo Busi for the comments.