Network Working Group R. Wilton, Ed.
Internet-Draft Cisco Systems, Inc.
Updates: 7950,8407,8525 (if approved) R. Rahman, Ed.
Intended status: Standards Track
Expires: January 13, 2022 B. Lengyel, Ed.
Ericsson
J. Clarke
Cisco Systems, Inc.
J. Sterne
Nokia
July 12, 2021
Updated YANG Module Revision Handling
draft-ietf-netmod-yang-module-versioning-03
Abstract
This document specifies a new YANG module update procedure that can
document when non-backwards-compatible changes have occurred during
the evolution of a YANG module. It extends the YANG import statement
with an earliest revision filter to better represent inter-module
dependencies. It provides help and guidelines for managing the
lifecycle of YANG modules and individual schema nodes. It provides a
mechanism, via the revision-label YANG extension, to specify a
revision identifier for YANG modules and submodules. This document
updates RFC 7950, RFC 8407 and RFC 8525.
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 January 13, 2022.
Wilton, et al. Expires January 13, 2022 [Page 1]
Internet-Draft Updated YANG Module Revision Handling July 2021
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updates to YANG RFCs . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Refinements to YANG revision handling . . . . . . . . . . . . 5
3.1. Updating a YANG module with a new revision . . . . . . . 6
3.1.1. Backwards-compatible rules . . . . . . . . . . . . . 6
3.1.2. Non-backwards-compatible changes . . . . . . . . . . 7
3.2. non-backwards-compatible revision extension statement . . 7
3.3. Removing revisions from the revision history . . . . . . 7
3.4. Revision label . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. File names . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Revision label scheme extension statement . . . . . . 9
3.5. Examples for updating the YANG module revision history . 9
4. Import by derived revision . . . . . . . . . . . . . . . . . 12
4.1. Module import examples . . . . . . . . . . . . . . . . . 14
5. Updates to ietf-yang-library . . . . . . . . . . . . . . . . 15
5.1. Resolving ambiguous module imports . . . . . . . . . . . 15
5.2. YANG library versioning augmentations . . . . . . . . . . 16
5.2.1. Advertising revision-label . . . . . . . . . . . . . 16
5.2.2. Reporting how deprecated and obsolete nodes are
handled . . . . . . . . . . . . . . . . . . . . . . . 16
6. Versioning of YANG instance data . . . . . . . . . . . . . . 17
7. Guidelines for using the YANG module update rules . . . . . . 17
7.1. Guidelines for YANG module authors . . . . . . . . . . . 17
7.1.1. Making non-backwards-compatible changes to a YANG
module . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Versioning Considerations for Clients . . . . . . . . . . 20
8. Module Versioning Extension YANG Modules . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
Wilton, et al. Expires January 13, 2022 [Page 2]
Internet-Draft Updated YANG Module Revision Handling July 2021
11.1. YANG Module Registrations . . . . . . . . . . . . . . . 30
11.2. Guidance for versioning in IANA maintained YANG modules 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Examples of changes that are NBC . . . . . . . . . . 34
Appendix B. Examples of applying the NBC change guidelines . . . 35
B.1. Removing a data node . . . . . . . . . . . . . . . . . . 35
B.2. Changing the type of a leaf node . . . . . . . . . . . . 36
B.3. Reducing the range of a leaf node . . . . . . . . . . . . 37
B.4. Changing the key of a list . . . . . . . . . . . . . . . 37
B.5. Renaming a node . . . . . . . . . . . . . . . . . . . . . 38
B.6. Changing a default value . . . . . . . . . . . . . . . . 39
Appendix C. Changes between revisions . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction
This document defines a solution to the YANG module lifecycle
problems described in [I-D.ietf-netmod-yang-versioning-reqs].
Complementary documents provide a complete solution to the YANG
versioning requirements, with the overall relationship of the
solution drafts described in [I-D.ietf-netmod-yang-solutions].
Specifically, this document recognises a need (within standards
organizations, vendors, and the industry) to sometimes allow YANG
modules to evolve with non-backwards-compatible changes, which could
cause breakage to clients and importing YANG modules. Accepting that
non-backwards-compatible changes do sometimes occur, it is important
to have mechanisms to report where these changes occur, and to manage
their effect on clients and the broader YANG ecosystem.
The document comprises five parts:
Refinements to the YANG 1.1 module revision update procedure,
supported by new extension statements to indicate when a revision
contains non-backwards-compatible changes, and an optional
revision label.
A YANG extension statement allowing YANG module imports to specify
an earliest module revision that may satisfy the import
dependency.
Updates and augmentations to ietf-yang-library to include the
revision label in the module and submodule descriptions, to report
how "deprecated" and "obsolete" nodes are handled by a server, and
to clarify how module imports are resolved when multiple revisions
could otherwise be chosen.
Wilton, et al. Expires January 13, 2022 [Page 3]
Internet-Draft Updated YANG Module Revision Handling July 2021
Considerations of how versioning applies to YANG instance data.
Guidelines for how the YANG module update rules defined in this
document should be used, along with examples.
Note to RFC Editor (To be removed by RFC Editor)
Open issues are tracked at <https://github.com/netmod-wg/yang-ver-dt/
issues>.
1.1. Updates to YANG RFCs
This document updates [RFC7950] section 11. Section 3 describes
modifications to YANG revision handling and update rules, and
Section 4 describes a YANG extension statement to do import by
derived revision.
This document updates [RFC7950] section 5.2. Section 3.4.1 describes
the use of a revision label in the name of a file containing a YANG
module or submodule.
This document updates [RFC7950] section 5.6.5. Section 5.1 defines
how a client of a YANG library datastore schema resolves ambiguous
imports for modules which are not "import-only".
This document updates [RFC8407] section 4.7. Section 7 provides
guidelines on managing the lifecycle of YANG modules that may contain
non-backwards-compatible changes and a branched revision history.
This document updates [RFC8525] with augmentations to include
revision labels in the YANG library data and two boolean leaves to
indicate whether status deprecated and status obsolete schema nodes
are implemented by the server.
2. Terminology and Conventions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In addition, this document uses the terminology:
o YANG module revision: An instance of a YANG module, uniquely
identified with a revision date, with no implied ordering or
backwards compatibility between different revisions of the same
module.
Wilton, et al. Expires January 13, 2022 [Page 4]
Internet-Draft Updated YANG Module Revision Handling July 2021
o Backwards-compatible (BC) change: A backwards-compatible change
between two YANG module revisions, as defined in