draft-ietf-netmod-yang-versioning-reqs-04.txt   draft-ietf-netmod-yang-versioning-reqs-05.txt 
Network Working Group J. Clarke, Ed. Network Working Group J. Clarke, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational January 5, 2021 Intended status: Informational July 6, 2021
Expires: July 9, 2021 Expires: January 7, 2022
YANG Module Versioning Requirements YANG Module Versioning Requirements
draft-ietf-netmod-yang-versioning-reqs-04 draft-ietf-netmod-yang-versioning-reqs-05
Abstract Abstract
This document describes the problems that can arise because of the This document describes the problems that can arise because of the
YANG language module update rules, that require all updates to YANG YANG language module update rules, that require all updates to YANG
module preserve strict backwards compatibility. It also defines the module preserve strict backwards compatibility. It also defines the
requirements on any solution designed to solve the stated problems. requirements on any solution designed to solve the stated problems.
This document does not consider possible solutions, nor endorse any This document does not consider possible solutions, nor endorse any
particular solution. particular solution.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2021. This Internet-Draft will expire on January 7, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 36 skipping to change at page 3, line 36
standardized YANG modules have to be perfect on day one (at least the standardized YANG modules have to be perfect on day one (at least the
structure and meaning), which in turn might explain why IETF YANG structure and meaning), which in turn might explain why IETF YANG
modules take so long to standardize. Shooting for perfection is modules take so long to standardize. Shooting for perfection is
obviously a noble goal, but if the perfect standard comes too late, obviously a noble goal, but if the perfect standard comes too late,
it doesn't help the industry. it doesn't help the industry.
2.2. Some YANG Modules Are Not Backwards-Compatible 2.2. Some YANG Modules Are Not Backwards-Compatible
As we learn from our mistakes, we're going to face more and more non- As we learn from our mistakes, we're going to face more and more non-
backwards-compatible YANG modules. An example is the YANG data model backwards-compatible YANG modules. An example is the YANG data model
for L3VPN service delivery [RFC8049], which, based on implementation for L3VPN service delivery [RFC8049] , which, based on implementation
experience, has been updated in a non-backwards-compatible way by experience, has been updated in a non-backwards-compatible way by
[RFC8299]. [RFC8299] .
While Standards Development Organization (SDO) YANG modules are While Standards Development Organization (SDO) YANG modules are
obviously better for the industry, we must recognize that many YANG obviously better for the industry, we must recognize that many YANG
modules are actually generated YANG modules (for example, from modules are actually generated YANG modules (for example, from
internal databases), which is sometimes the case for vendor modules internal databases), which is sometimes the case for vendor modules
[RFC8199]. From time to time, the new YANG modules are not [RFC8199] . From time to time, the new YANG modules are not
backwards-compatible. backwards-compatible.
Old module parts that are no longer needed, no longer supported, or Old module parts that are no longer needed, no longer supported, or
are not used by consumers need to be removed from modules. It is are not used by consumers need to be removed from modules. It is
often hard to decide which parts are no longer needed/used; still the often hard to decide which parts are no longer needed/used; still the
need and practice of removing old parts exist. While it is rare in need and practice of removing old parts exist. While it is rare in
standard modules it is more common in vendor YANG modules where the standard modules it is more common in vendor YANG modules where the
usage of modules is more controlled. usage of modules is more controlled.
The problems described in Section 2.7 may also result in incompatible The problems described in Section 2.7 may also result in incompatible
skipping to change at page 7, line 11 skipping to change at page 7, line 11
is not a trivial thing to do. This "may or may not" is unacceptable is not a trivial thing to do. This "may or may not" is unacceptable
in a contract. In effect, this works as if there would be an if- in a contract. In effect, this works as if there would be an if-
feature statement on each deprecated schema node where the server feature statement on each deprecated schema node where the server
does not advertise whether the feature is supported or not. Why is does not advertise whether the feature is supported or not. Why is
it not advertised? it not advertised?
3. Terminology and Conventions 3. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119] .
In addition, this document uses the following terminology: In addition, this document uses the following terminology:
o YANG module revision: An instance of a YANG module, with no o YANG module revision: An instance of a YANG module, with no
implied ordering or backwards compatibility between different implied ordering or backwards compatibility between different
revisions of the same module." revisions of the same module."
o YANG module version: A YANG module revision, but also with an o YANG module version: A YANG module revision, but also with an
implied partial ordering relationship between other versions of implied partial ordering relationship between other versions of
the same module. Each module version must be uniquely the same module. Each module version must be uniquely
identifiable. identifiable.
o Non-backwards-compatible (NBC): In the context of this document, o Non-backwards-compatible (NBC): In the context of this document,
the term 'non-backwards-compatible' refers to a change or set of the term 'non-backwards-compatible' refers to a change or set of
changes between two YANG module revisions that do not adhere to changes between two YANG module revisions that do not adhere to
the list of allowable changes specified in Section 11 "Updating a the list of allowable changes specified in Section 11 "Updating a
Module" of [RFC7950], with the following additional clarification: Module" of [RFC7950] , with the following additional
clarification:
* Any addition of, or change to, a "status" statement that allows * Any addition of, or change to, a "status" statement that allows
a server to remove support for a schema node is considered a a server to remove support for a schema node is considered a
non-backwards-compatible change non-backwards-compatible change
4. The Problem Statement 4. The Problem Statement
Considering the issues described in the background, the problem Considering the issues described in the background, the problem
definition can be summarized as follows. definition can be summarized as follows.
 End of changes. 8 change blocks. 
9 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/