YANG deVELpment PrOCEss and maintenance (VELOCE)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

IETF has used RFCs to publish its documents. However, RFCs, which are text documents, are not well-suited for iterative development of YANG modules that come in the form of source code.¶

This document proposes a new approach for documenting and publishing IETF YANG modules. While this document mainly focuses on the IETF modules, IANA modules that are included in drafts, and removed ultimately on publication, can follow a similar process during the development of the IANA module.¶

This document proposes that the publishing of a YANG module should be split into two parts: the text portion, hereby referred to as the document, and the YANG module. The document SHOULD continue to be used for describing the model, defining IANA Considerations, defining the Security Considerations, describing any Operational Considerations, capturing the Normative and the Informative References, etc. The YANG module should be developed and maintained in a separate Source Code Mechanism (SCM) repository such as GitHub. The SCM SHOULD provide a stable link to the YANG module, which should then be included as a reference in the document.¶

There are several reasons to develop the YANG module in an SCM. SCM provides version control and improves traceability of changes. Modern SCM provides the ability for Continuous Integration/Continuous Development (CI/CD). YANG modules can be fully validated before they are published. Changes to the module can be submitted by providing changes to the affected portions of the source code instead of the entire module. Reviews and comments can be gathered on the changes being proposed. This iterative approach lends itself to faster development and fixing of issues.¶

Guidance for writing YANG modules is discussed in [I-D.ietf-netmod-rfc8407bis]. Guidelines related to code components (Section 3.2 of [I-D.ietf-netmod-rfc8407bis]) or citations to references listed in the YANG module do not apply to VELOCE.¶

2. VELOCE Procedure

The following practices should provide the necessary guidance on how a WG develops a new YANG module or updates an existing YANG module:¶

It is RECOMMENDED that IETF-hosted repositories be used. See Section 1.3 of Working Group GitHub Usage Guidance [RFC8874]. Integration using third-party hosted repositories MAY be used for experimentation purposes.¶

A new repository MUST be created by the WG Chairs following the procedure in Section 3.2 of Working Group GitHub Usage Guidance [RFC8874] to develop or maintain a YANG Module. For a new module, this SHOULD happen when the module is adopted as a WG item. It MAY happen for individual drafts, and that is left to the discretion of the chairs. However, once the document is adopted as a WG item, the repository SHOULD reside under the WG. The name of the repository SHOULD reflect the name of the draft. In addition, the chairs MAY make sure that an appropriate CI/CD YANG validation is in place.¶

The procedure for managing WG documents (e.g., assign editors) applies for managing YANG modules (Section 6.1 of IETF Working Group Guidelines and Procedures [RFC2418]). For considerations related to granting editors write and administrators' right refer to Section 3.3 of Working Group GitHub Usage Guidance [RFC8874].¶

Other administrative policies as they relate to migration, personal change or the WG closing is defined in the Working Group GitHub Administration [RFC8875].¶

A release tagging mechanism should be defined to track the intermediate versions referenced by WG I-Ds and by the RFC, once published. This can come in the form of a 'git tag' or by having a branch that corresponds to the version of the draft.¶

Contribution methods for the YANG module are similar to those defined in Section 4 of Working Group GitHub Usage Guidance [RFC8874]. This includes the use of Issues to track open issues regarding the module. They, along with corresponding links to the Pull Request (PR), are a useful way to record decisions made by the WG.¶

PR allow for a user to request a change to the repository. A user does not need to have write access to the repository. A fork of the repository allows the user to make changes, validate them, and post the changes as a PR against the WG repository. Editors of the YANG module are encouraged not to accept changes into the "main" or "master" branch of the repository. Instead, they should be directed to a branch.¶

A procedure for assessing consensus is discussed in Section 7 of Working Group GitHub Usage Guidance [RFC8874] and SHOULD be followed when accepting changes to the module.¶

The YANG module MUST NOT be inserted in the document; instead, a link to the above repository MUST be included in the document.¶

A bis version of the initial RFC MAY be considered if a major change needs to be added in the document. Such a decision is left to the WG. WG may decide to update an adopted YANG module in the IETF repository and only update the RFC to change the reference to the YANG module.¶

3. Experimental Plan

Much like other experimental documents, this document tries to answer the following four questions as they relate to experimental documents.¶

4. Operational Considerations

This document has no operational considerations at this time.¶

5. Security Considerations

The security considerations discussed in Section 10 of [RFC8874] apply here.¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Acknowledgments

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

Thanks to the participants of OPSAWG for their comments that have helped shape this draft.¶

Author's Address