]> 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 be suited for documenting 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 . All these guidelines apply expect those related to narrative text.

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 document with) a YANG module:

• A new repository MUST be created by the WG Chairs following the procedure in to maintain the YANG Module, with the apprpriate CI/CD YANG validation in place.
• Contributing methods to YANG module are those defined in .
• The WG Chairs MUST seek in a timely manner after the adoption of the document 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.
• The YANG module MUST NOT be inserted in the document; instead a link to the Github repository MUST be included.
• Bis versions of the initial RFC MAY be considered, to document major changes or their rationale.

Security Considerations The same considerations discussed in apply here.

IANA Considerations This document has no IANA actions.

References Normative References 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. 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. 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. This document provides a set of guidelines for working groups that choose to use GitHub for their work. Informative References 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. 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]

Acknowledgments This draft is triggered by the discussion in NEMOPS IAB workshop.