< draft-verdt-netmod-yang-solutions-02.txt   draft-verdt-netmod-yang-solutions-03.txt >
Network Working Group R. Wilton, Ed. Network Working Group R. Wilton, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational November 3, 2019 Intended status: Informational February 19, 2020
Expires: May 6, 2020 Expires: August 22, 2020
YANG Versioning Solution Overview YANG Versioning Solution Overview
draft-verdt-netmod-yang-solutions-02 draft-verdt-netmod-yang-solutions-03
Abstract Abstract
This document gives a brief overview of the different drafts that This document gives an overview of the different documents that
comprise a full solution to the YANG versioning requirements draft. comprise a full solution to the YANG versioning requirements
The purpose of this draft is to help readers understand how the document. The purpose of this document is to help readers understand
discrete parts of the YANG versioning solution fit together during how the discrete parts of the YANG versioning solution fit together
working group development of the solution drafts. during working group development of the solution documents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 6, 2020. This Internet-Draft will expire on August 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Solution Drafts . . . . . . . . . . . . . . . . . . . . . . . 2 2. Solution Documents . . . . . . . . . . . . . . . . . . . . . 3
2.1. Updated YANG Module Revision Handling . . . . . . . . . . 3 2.1. Updated YANG Module Revision Handling . . . . . . . . . . 3
2.2. Module semantic version number scheme . . . . . . . . . . 4 2.2. YANG Semantic Versioning . . . . . . . . . . . . . . . . 4
2.3. Versioned YANG packages . . . . . . . . . . . . . . . . . 4 2.3. Versioned YANG packages . . . . . . . . . . . . . . . . . 4
2.4. Protocol operations for package version selection . . . . 5 2.4. Dynamic YANG schema selection . . . . . . . . . . . . . . 5
2.5. YANG schema comparison tooling . . . . . . . . . . . . . 5 2.5. YANG Schema Comparison . . . . . . . . . . . . . . . . . 6
3. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[I-D.ietf-netmod-yang-versioning-reqs] documents the requirements for [I-D.ietf-netmod-yang-versioning-reqs] documents the requirements for
any solution to the YANG [RFC7950] versioning problem. Chapter 5 any solution to the YANG [RFC7950] versioning problem. In
lists the formal requirements that a complete solution requires. particular, chapter 5 lists the formal requirements that a solution
requires.
The aim of this draft is to help readers understand how the different The complete solution to all of the YANG versioning requirements is
solution drafts fit together, and also which drafts contribute comprised of five documents, each addressing different aspects of the
solutions to particular individual requirements. The overall solution. These documents are:
solution comprises five individual drafts:
1. [I-D.verdt-netmod-yang-module-versioning] 1. [I-D.verdt-netmod-yang-module-versioning]
2. [I-D.verdt-netmod-yang-semver] 2. [I-D.verdt-netmod-yang-semver]
3. [I-D.rwilton-netmod-yang-packages] 3. [I-D.rwilton-netmod-yang-packages]
4. [I-D.wilton-netmod-yang-ver-selection] 4. [I-D.wilton-netmod-yang-ver-selection]
5. YANG schema comparison tooling (not yet published) 5. [I-D.verdt-netmod-yang-schema-comparison]
Open issues, across all of the solution drafts are tracked at The aim of this document is to help readers understand how these
<https://github.com/netmod-wg/yang-ver-dt/issues>. different solution documents fit together, and also which documents
contribute solutions that address particular individual requirements.
2. Solution Drafts Open issues, across all of the solution documents are tracked at
<https://github.com/netmod-wg/yang-ver-dt/issues>.
The complete solution to the YANG versioning requirements comprises 2. Solution Documents
five solution drafts, that are summarized below.
2.1. Updated YANG Module Revision Handling 2.1. Updated YANG Module Revision Handling
In summary, [I-D.verdt-netmod-yang-module-versioning] specifies In summary, [I-D.verdt-netmod-yang-module-versioning] specifies
minimal extensions and updates to the YANG language, YANG Library, minimal extensions and updates to the YANG language, YANG Library,
and YANG author guidelines to provide more flexible YANG module and YANG author guidelines to provide more flexible YANG module
revision handling. The intent is that these changes and extensions revision handling. The intent is that these changes and extensions
could be folded into future revisions of the updated specifications. could be folded into future revisions of the updated specifications.
The draft provides a solution for all requirements except Req 2.2, The document provides a base solution for all requirements except Req
Req 3.1 and Req 3.2. 2.2, Req 3.1 and Req 3.2.
The extensions and changes in the draft can be summarized thus: The extensions and changes in the document can be summarized thus:
o It defines a YANG extension statement to indicate where non- o It defines a YANG extension statement to indicate where non-
backwards-compatible changes have occurred in a module's revision backwards-compatible changes have occurred in a module's revision
history. history.
o It relaxes the rules for the module revision history to allow for o It relaxes the rules for the module revision history to allow for
a non-linear module revision history. I.e., any given module a non-linear module revision history. I.e., any given module
revision may have multiple revisions directly derived from it. revision may have multiple revisions directly derived from it.
o It defines a new import extension statement that restricts the o It defines a new import extension statement that restricts the
skipping to change at page 4, line 9 skipping to change at page 4, line 9
o It provides an extension statement to allow a description o It provides an extension statement to allow a description
statement to be associated with a YANG status statement, providing statement to be associated with a YANG status statement, providing
more information about why the status has changed. more information about why the status has changed.
o It defines how versioning relates to YANG instance data. o It defines how versioning relates to YANG instance data.
o It refines the guidelines for updating modules, taking into o It refines the guidelines for updating modules, taking into
consideration that non-backwards-compatible changes are sometimes consideration that non-backwards-compatible changes are sometimes
necessary for various pragmatic reasons. necessary for various pragmatic reasons.
2.2. Module semantic version number scheme 2.2. YANG Semantic Versioning
[I-D.verdt-netmod-yang-semver] defines a semantic versioning scheme [I-D.verdt-netmod-yang-semver] defines a semantic versioning scheme,
derived from the semver.org 2.0.0 specification that can be used in derived from the semver.org 2.0.0 specification, that can be used in
conjunction with the revision label extension statement defined in conjunction with the revision label extension statement defined in
Section 2.1 to allow semantic version numbers to be used to manage Section 2.1 to allow semantic version numbers to be used to manage
the revision lifecycle of YANG modules. This draft provides an the revision lifecycle of YANG modules and other related YANG assets,
enhanced solution for Req 2.1, but organizations authoring modules e.g., YANG packages. This document provides an enhanced solution for
are not obliged to use this specific versioning scheme, and could Req 2.1, but organizations authoring modules are not obliged to use
choose a different overlaid versioning scheme, or none at all and this specific versioning scheme, and could choose a different
rely solely on revision dates. overlaid versioning scheme, or none at all and rely solely on
revision dates.
The aims of the YANG semantic versioning scheme are: The aims of the YANG semantic versioning scheme are:
To generally allow clients to determine whether NBC changes have o to generally allow clients to determine whether NBC changes have
occurred between two revisions from the version number alone, occurred between two revisions from the version number alone,
without having to check the full revision history. without having to check the full revision history;
To give a more informative identifier for a branched revision o to give a more informative identifier for a branched revision
history over revision dates alone. history over revision dates alone;
To allow revision branches that contain fixes for published non- o to allow revision branches that contain fixes for published non-
latest releases. latest releases.
2.3. Versioned YANG packages 2.3. Versioned YANG packages
The two previous drafts address version and revision management of The two previous solution documents primarily address version and
individual modules. [I-D.rwilton-netmod-yang-packages] provides a revision management of individual modules.
mechanism to group a set of related YANG modules revisions together, [I-D.rwilton-netmod-yang-packages] provides a mechanism to group sets
into a construct called a YANG package, and to apply a version scheme of related YANG modules revisions together, into constructs called
to the group. YANG packages, and to apply a versioning scheme to the groups.
The core part of this draft are YANG module definitions that define a The core part of this document are YANG module definitions that
YANG package, that are used as an augmentation to YANG library, and define a YANG package. The definitions are used as an augmentation
also in YANG instance data documents for offline access. to YANG library and also in YANG instance data documents for offline
access.
The principle aims of the packages draft are: The principle aims of YANG packages are:
To provide an alternative simpler mechanism to manage conformance To define an efficient hierarchical structure that can precisely
specify a YANG schema.
To provide an simple alternative mechanism to manage conformance
of modules. Rather than checking conformance against a set of of modules. Rather than checking conformance against a set of
individual YANG module revisions, it should be easier to check for individual YANG module revisions and enabled features, it should
conformance against a much smaller set of YANG package versions. be easier to check for conformance against a much smaller set of
YANG package versions.
To provide an easier mechanism for clients to check conformance To provide a more efficient mechanism for servers to share
with a server. Rather that downloading and comparing all conformance information with clients. Rather that downloading and
individual module revisions, the client can just check whether the comparing all individual module revisions and features via YANG
package version is compatible. The package definition could be library, the client can just check whether the package version is
retrieved and cached from multiple sources. compatible instead. The package definition could be retrieved and
cached from multiple sources.
The YANG packages draft does not address any of the versioning To define constructs that can be used for YANG schema selection.
requirements directly, but provides the foundation building blocks
for the version selection solution, described in Section 2.4, that
addresses Reqs 3.1 and 3.2.
2.4. Protocol operations for package version selection Although the YANG packages document does not satisfy any versioning
requirements directly, it provides foundational building blocks for
the schema selection solution, described in Section 2.4, that does
address two of the requirements.
2.4. Dynamic YANG schema selection
[I-D.wilton-netmod-yang-ver-selection] specifies a solution for [I-D.wilton-netmod-yang-ver-selection] specifies a solution for
requirements 3.1 and 3.2 via the use of requirements 3.1 and 3.2 via the use of
[I-D.rwilton-netmod-yang-packages] and a protocol based version [I-D.rwilton-netmod-yang-packages] and a model and protocol based
selection scheme that can be used by clients to choose a particular schema selection scheme that can be used by clients to choose which
YANG datastore schema from the set of datastore schema that are schemas to use when interacting with the device from the available
supported by the server. schema that are supported and advertised by the server.
The version selection optionally allows: The dynamic YANG schema selection solution:
Servers to support a single, selectable YANG package at a allows servers to define named 'schema-sets' which specify the
particular version, that is used for all NETCONF/RESTCONF schema for each supported datastore via references to YANG
interactions. packages;
Servers to support multiple selectable YANG packages and package can support clients choosing a single default schema-set (from
versions, with different clients able to concurrently access those advertised by the server) that is used for all NETCONF/
different packages and different package versions. RESTCONF protocol sessions;
2.5. YANG schema comparison tooling can support clients enabling multiple compatible secondary schema-
sets that can be used on separate NETCONF/RESTCONF protocol
sessions;
A tooling based solution is proposed for Req 2.2, that allows two can support clients configuring named custom schema-sets that can
YANG schema versions to be algorithmically compared, with the be selected as default or secondary schema-sets;
algorithm reporting the list of differences between the two YANG
schema and whether each change is regarded as being backwards-
compatible, or non-backwards-compatible. Annotations to the YANG
modules, via the use of extension statements, may help improve the
accuracy of the comparison algorithm, particularly for statements
that are very hard to algorithmically classify the scope of any
differences (e.g., a change in the semantic behaviour of a data node
defined via modifications to the associated YANG description
statement). Given that Req 2.2 is a softer requirement, and
practical experience with the tooling is required, it is proposed
that this work is deferred at this time.
When comparing a module schema, a tool would also be able to take can support different module versions via placing them in
into account enabled features, deviations, and the subset of the different schema-sets;
schema being used by the client. This would allow a tooling based can support different schema families (e.g., IETF YANG modules ,
approach to give a more accurate answer as to whether a client would native vendor, or OpenConfig);
be affected when upgrading between two software versions, than
looking at the revision history, or comparing semantic version allows considerable freedom in the schema selection capabilities
numbers. that servers choose to support.
2.5. YANG Schema Comparison
The final piece of the solution jigsaw is a document that describes
how to algorithmically compare YANG schema, addressing Req 2.2.
[I-D.verdt-netmod-yang-schema-comparison] specifies an algorithm that
can be used to compare two revisions of a YANG schema to determine
the overall scope of the changes, and a list of the specific changes,
between the two revisions.
The YANG Schema Comparison solution:
defines a algorithm for comparing two YANG schema, identifying the
differences and classifying them as backwards-compatible, non-
backwards-compatible or editorial;
can be used to compare individual YANG module revisions;
can be used to compare YANG schema defined using YANG packages;
can filter the comparison output to the subset of the schema nodes
that are of interest, providing a more precise answer for clients
to determine whether they would likely be affected when upgrading
between two schema versions;
defines YANG extensions to improve the accuracy of the comparison
algorithm by explicitly annotating the type of change to
statements within a YANG module, for use where the type of change
would otherwise be ambiguous to a simple programmatic comparison
algorithm.
3. Contributors 3. Contributors
This document grew out of the YANG module versioning design team that This document grew out of the YANG module versioning design team that
started after IETF 101. The following individuals are (or have been) started after IETF 101. The following individuals are (or have been)
members of that design team and have contributed to defining the members of that design team and have contributed to defining the
problem, specifying the requirements, and working on a solution: problem, specifying the requirements, and working on a solution:
o Balazs Lengyel o Balazs Lengyel
skipping to change at page 7, line 7 skipping to change at page 7, line 33
o Wu Bo o Wu Bo
4. Security Considerations 4. Security Considerations
The document does not define any new protocol or data model. There The document does not define any new protocol or data model. There
is no security impact. is no security impact.
5. IANA Considerations 5. IANA Considerations
None None.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-netmod-yang-versioning-reqs] [I-D.ietf-netmod-yang-versioning-reqs]
Clarke, J., "YANG Module Versioning Requirements", draft- Clarke, J., "YANG Module Versioning Requirements", draft-
ietf-netmod-yang-versioning-reqs-01 (work in progress), ietf-netmod-yang-versioning-reqs-02 (work in progress),
July 2019. December 2019.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
6.2. Informative References 6.2. Informative References
[I-D.rwilton-netmod-yang-packages] [I-D.rwilton-netmod-yang-packages]
Wilton, R., "YANG Packages", draft-rwilton-netmod-yang- Wilton, R., "YANG Packages", draft-rwilton-netmod-yang-
packages-02 (work in progress), October 2019. packages-02 (work in progress), October 2019.
[I-D.verdt-netmod-yang-module-versioning] [I-D.verdt-netmod-yang-module-versioning]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "Updated YANG Module B., Sterne, J., and K. D'Souza, "Updated YANG Module
Revision Handling", draft-verdt-netmod-yang-module- Revision Handling", draft-verdt-netmod-yang-module-
versioning-01 (work in progress), October 2019. versioning-01 (work in progress), October 2019.
[I-D.verdt-netmod-yang-schema-comparison]
Wilton, R., "YANG Schema Comparison", draft-verdt-netmod-
yang-schema-comparison-00 (work in progress), November
2019.
[I-D.verdt-netmod-yang-semver] [I-D.verdt-netmod-yang-semver]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "YANG Semantic B., Sterne, J., and K. D'Souza, "YANG Semantic
Versioning", draft-verdt-netmod-yang-semver-01 (work in Versioning", draft-verdt-netmod-yang-semver-01 (work in
progress), October 2019. progress), October 2019.
[I-D.wilton-netmod-yang-ver-selection] [I-D.wilton-netmod-yang-ver-selection]
Wilton, R., Rahman, R., and J. Clarke, "YANG Schema Wilton, R., Rahman, R., and J. Clarke, "YANG Schema
Version Selection", draft-wilton-netmod-yang-ver- Version Selection", draft-wilton-netmod-yang-ver-
selection-01 (work in progress), November 2019. selection-01 (work in progress), November 2019.
 End of changes. 43 change blocks. 
102 lines changed or deleted 139 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/