wdiff draft-verdt-netmod-yang-solutions-02.txt draft-verdt-netmod-yang-solutions-03.txt

Network Working Group R. Wilton, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Informational November 3, 2019 February 19, 2020
Expires: May 6, August 22, 2020

YANG Versioning Solution Overview
draft-verdt-netmod-yang-solutions-02
draft-verdt-netmod-yang-solutions-03

Abstract

This document gives a brief an overview of the different drafts documents that
comprise a full solution to the YANG versioning requirements draft.
document. The purpose of this draft document is to help readers understand
how the discrete parts of the YANG versioning solution fit together
during working group development of the solution drafts. documents.

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 May 6, August 22, 2020.

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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Solution Drafts . . Documents . . . . . . . . . . . . . . . . . . . . . 2 3
2.1. Updated YANG Module Revision Handling . . . . . . . . . . 3
2.2. Module semantic version number scheme YANG Semantic Versioning . . . . . . . . . . . . . . . . 4
2.3. Versioned YANG packages . . . . . . . . . . . . . . . . . 4
2.4. Protocol operations for package version Dynamic YANG schema selection . . . . . . . . . . . . . . 5
2.5. YANG schema comparison tooling Schema Comparison . . . . . . . . . . . . . 5 . . . . 6
3. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 8

1. Introduction

[I-D.ietf-netmod-yang-versioning-reqs] documents the requirements for
any solution to the YANG [RFC7950] versioning problem. Chapter In
particular, chapter 5 lists the formal requirements that a complete solution
requires.

The complete solution to all of the YANG versioning requirements is
comprised of five documents, each addressing different aspects of the
solution. These documents are:

1. [I-D.verdt-netmod-yang-module-versioning]

2. [I-D.verdt-netmod-yang-semver]

3. [I-D.rwilton-netmod-yang-packages]

4. [I-D.wilton-netmod-yang-ver-selection]

5. [I-D.verdt-netmod-yang-schema-comparison]

The aim of this draft document is to help readers understand how the these
different solution drafts documents fit together, and also which drafts documents
contribute solutions to that address particular individual requirements. The overall
solution comprises five individual drafts:

1. [I-D.verdt-netmod-yang-module-versioning]

2. [I-D.verdt-netmod-yang-semver]

3. [I-D.rwilton-netmod-yang-packages]

4. [I-D.wilton-netmod-yang-ver-selection]

5. YANG schema comparison tooling (not yet published)

Open issues, across all of the solution drafts documents are tracked at
<https://github.com/netmod-wg/yang-ver-dt/issues>.

2. Solution Drafts

The complete solution to the YANG versioning requirements comprises
five solution drafts, that are summarized below. Documents

2.1. Updated YANG Module Revision Handling

In summary, [I-D.verdt-netmod-yang-module-versioning] specifies
minimal extensions and updates to the YANG language, YANG Library,
and YANG author guidelines to provide more flexible YANG module
revision handling. The intent is that these changes and extensions
could be folded into future revisions of the updated specifications.
The draft document provides a base solution for all requirements except Req
2.2, Req 3.1 and Req 3.2.

The extensions and changes in the draft document can be summarized thus:

o It defines a YANG extension statement to indicate where non-
backwards-compatible changes have occurred in a module's revision
history.

o It relaxes the rules for the module revision history to allow for
a non-linear module revision history. I.e., any given module
revision may have multiple revisions directly derived from it.

o It defines a new import extension statement that restricts the
allowed module revisions that satisfy the import to only those
derived from a specified module revision.

o It defines a revision label extension statement to allow an
informative name to be associated with a particular revision date,
and to be used in import statements, YANG module filenames, and is
available in YANG library. One example of how the revision label
could be used is to associate a semantic versioning scheme to YANG
module revisions.

o It updates the YANG rules for changes between module revisions
that are allowed to be classified as backwards-compatible. In
particular, marking a node as obsolete is no longer classified as
a backwards compatible change.

o It provides updated guidance on how servers handle deprecated and
obsolete YANG nodes and augments YANG library with additional
leaves to report the server's behavior to clients.

o It provides an extension statement to allow a description
statement to be associated with a YANG status statement, providing
more information about why the status has changed.

o It defines how versioning relates to YANG instance data.

o It refines the guidelines for updating modules, taking into
consideration that non-backwards-compatible changes are sometimes
necessary for various pragmatic reasons.

2.2. Module semantic version number scheme YANG Semantic Versioning

[I-D.verdt-netmod-yang-semver] defines a semantic versioning scheme scheme,
derived from the semver.org 2.0.0 specification specification, that can be used in
conjunction with the revision label extension statement defined in
Section 2.1 to allow semantic version numbers to be used to manage
the revision lifecycle of YANG modules. modules and other related YANG assets,
e.g., YANG packages. This draft document provides an enhanced solution for
Req 2.1, but organizations authoring modules are not obliged to use
this specific versioning scheme, and could choose a different
overlaid versioning scheme, or none at all and rely solely on
revision dates.

The aims of the YANG semantic versioning scheme are:

o to generally allow clients to determine whether NBC changes have
occurred between two revisions from the version number alone,
without having to check the full revision history.

To history;

o to give a more informative identifier for a branched revision
history over revision dates alone.

To alone;

o to allow revision branches that contain fixes for published non-
latest releases.

2.3. Versioned YANG packages

The two previous drafts solution documents primarily address version and
revision management of individual modules.
[I-D.rwilton-netmod-yang-packages] provides a mechanism to group a set sets
of related YANG modules revisions together, into a construct constructs called a
YANG package, packages, and to apply a version versioning scheme to the group. groups.

The core part of this draft document are YANG module definitions that
define a YANG package, that package. The definitions are used as an augmentation
to YANG library, library and also in YANG instance data documents for offline
access.

The principle aims of the YANG packages draft are:

To define an efficient hierarchical structure that can precisely
specify a YANG schema.

To provide an simple alternative simpler mechanism to manage conformance
of modules. Rather than checking conformance against a set of
individual YANG module revisions, revisions and enabled features, it should
be easier to check for conformance against a much smaller set of
YANG package versions.

To provide an easier a more efficient mechanism for clients servers to check share
conformance information with a server. clients. Rather that downloading and
comparing all individual module revisions, revisions and features via YANG
library, the client can just check whether the package version is compatible.
compatible instead. The package definition could be retrieved and
cached from multiple sources.

The

To define constructs that can be used for YANG schema selection.

Although the YANG packages draft document does not address satisfy any of the versioning
requirements directly, but it provides the foundation foundational building blocks for
the version schema selection solution, described in Section 2.4, that
addresses Reqs 3.1 and 3.2. does
address two of the requirements.

2.4. Protocol operations for package version Dynamic YANG schema selection

[I-D.wilton-netmod-yang-ver-selection] specifies a solution for
requirements 3.1 and 3.2 via the use of
[I-D.rwilton-netmod-yang-packages] and a model and protocol based version
schema selection scheme that can be used by clients to choose a particular
YANG datastore schema which
schemas to use when interacting with the device from the set of datastore available
schema that are supported and advertised by the server.

The version dynamic YANG schema selection optionally allows:

Servers solution:

allows servers to define named 'schema-sets' which specify the
schema for each supported datastore via references to support a single, selectable YANG package at
packages;

can support clients choosing a
particular version, single default schema-set (from
those advertised by the server) that is used for all NETCONF/RESTCONF
interactions.

Servers to NETCONF/
RESTCONF protocol sessions;

can support clients enabling multiple selectable YANG packages and package
versions, with different compatible secondary schema-
sets that can be used on separate NETCONF/RESTCONF protocol
sessions;

can support clients able to concurrently access configuring named custom schema-sets that can
be selected as default or secondary schema-sets;

can support different packages and module versions via placing them in
different package versions.

2.5. schema-sets;
can support different schema families (e.g., IETF YANG modules ,
native vendor, or OpenConfig);

allows considerable freedom in the schema comparison tooling

A tooling based selection capabilities
that servers choose to support.

2.5. YANG Schema Comparison

The final piece of the solution jigsaw is proposed for a document that describes
how to algorithmically compare YANG schema, addressing Req 2.2, 2.2.

[I-D.verdt-netmod-yang-schema-comparison] specifies an algorithm that allows
can be used to compare two revisions of a YANG schema versions to be algorithmically compared, with determine
the
algorithm reporting overall scope of the changes, and a list of differences the specific changes,
between the two revisions.

The YANG
schema Schema Comparison solution:

defines a algorithm for comparing two YANG schema, identifying the
differences and whether each change is regarded classifying them as being backwards-
compatible, backwards-compatible, non-
backwards-compatible or non-backwards-compatible. Annotations editorial;

can be used to the compare individual YANG
modules, via the use of extension statements, may help improve the
accuracy of the comparison algorithm, particularly for statements
that are very hard module revisions;

can be used to algorithmically classify the scope of any
differences (e.g., a change in the semantic behaviour of a data node compare YANG schema defined via modifications to the associated using YANG description
statement). Given that Req 2.2 is a softer requirement, and
practical experience with packages;

can filter 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 comparison output to take
into account enabled features, deviations, and the subset of the schema being used by the client. This would allow a tooling based
approach to give nodes
that are of interest, providing a more accurate precise answer as for clients
to determine whether a client they would likely be affected when upgrading
between two software versions, than
looking at schema versions;

defines YANG extensions to improve the revision history, or comparing semantic version
numbers. 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

This document grew out of the YANG module versioning design team that
started after IETF 101. The following individuals are (or have been)
members of that design team and have contributed to defining the
problem, specifying the requirements, and working on a solution:

o Balazs Lengyel

o Benoit Claise
o Ebben Aries

o Jason Sterne

o Joe Clarke

o Juergen Schoenwaelder

o Mahesh Jethanandani

o Michael (Wangzitao)

o Qin Wu

o Reshad Rahman

o Rob Wilton

o Susan Hares

o Wu Bo

4. Security Considerations

The document does not define any new protocol or data model. There
is no security impact.

5. IANA Considerations

None

None.

6. References

6.1. Normative References

[I-D.ietf-netmod-yang-versioning-reqs]
Clarke, J., "YANG Module Versioning Requirements", draft-
ietf-netmod-yang-versioning-reqs-01
ietf-netmod-yang-versioning-reqs-02 (work in progress),
July
December 2019.

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.

6.2. Informative References

[I-D.rwilton-netmod-yang-packages]
Wilton, R., "YANG Packages", draft-rwilton-netmod-yang-
packages-02 (work in progress), October 2019.

[I-D.verdt-netmod-yang-module-versioning]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "Updated YANG Module
Revision Handling", draft-verdt-netmod-yang-module-
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]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "YANG Semantic
Versioning", draft-verdt-netmod-yang-semver-01 (work in
progress), October 2019.

[I-D.wilton-netmod-yang-ver-selection]
Wilton, R., Rahman, R., and J. Clarke, "YANG Schema
Version Selection", draft-wilton-netmod-yang-ver-
selection-01 (work in progress), November 2019.

Author's Address

Robert Wilton (editor)
Cisco Systems, Inc.

Email: rwilton@cisco.com