Skip to main content

YANG Versioning Solution Overview
draft-verdt-netmod-yang-solutions-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Robert Wilton
Last updated 2019-07-03
Replaced by draft-ietf-netmod-yang-solutions
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-verdt-netmod-yang-solutions-01
Network Working Group                                     R. Wilton, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                              July 3, 2019
Expires: January 4, 2020

                   YANG Versioning Solution Overview
                  draft-verdt-netmod-yang-solutions-01

Abstract

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

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 4, 2020.

Copyright Notice

   Copyright (c) 2019 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.

Wilton                   Expires January 4, 2020                [Page 1]
Internet-Draft      YANG Versioning Solution Overview          July 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Summary of requirements . . . . . . . . . . . . . . . . . . .   2
   3.  Solution Drafts . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Updated YANG Module Revision Handling . . . . . . . . . .   4
     3.2.  Module semantic version number scheme . . . . . . . . . .   5
     3.3.  Versioned YANG packages . . . . . . . . . . . . . . . . .   5
     3.4.  Protocol operations for package version selection . . . .   6
     3.5.  YANG schema comparison tooling  . . . . . . . . . . . . .   6
   4.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

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

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

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

   2.  Module semantic version number scheme (not yet published)

   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 are tracked at
   <https://github.com/netmod-wg/yang-ver-dt/issues>.

2.  Summary of requirements

   The requirements are formally documented in section 5 of
   [I-D.ietf-netmod-yang-versioning-reqs].  A shortened, non normative,
   summary of each of the requirements (using the same requirement

Wilton                   Expires January 4, 2020                [Page 2]
Internet-Draft      YANG Versioning Solution Overview          July 2019

   numbers) is provided below to help understand how the solutions
   drafts address the particular requirements.

      Req 1.1 - MUST allow nbc updates to a module without breaking
      imports.

      Req 1.2 - MUST allow nbc updates to a module without affecting
      existing client code using only unchanged data nodes.

      Req 1.3 - MUST support import statement restricted to only some
      revisions.

      Req 1.4 - MUST allow for fixes to non-latest published modules.

      Req 2.1 - MUST be able to determine if two arbitrary versions of
      any module are backwards-compatible.

      Req 2.2 - SHOULD be able to determine if two arbitrary versions of
      any data node are backwards-compatible.

      Req 3.1 - MUST allow servers to support existing clients.

      Req 3.2 - MUST allow simultaneously support of clients using
      different (perhaps restricted) revisions.

      Req 3.3 - MAY assume clients can handle unexpected instance data
      gracefully.

      Req 4.1 - MUST provide a way to indicate if deprecated nodes are
      implemented.

      Req 4.2 - MUST be able to document the reason for data node
      lifecycle changes, and possible alternative data nodes.

      Req 4.3 - MUST be able to forewarn of future data node lifecycle
      changes.

      Req 5.1 - MUST provide guidance on how to use the new scheme.

      Req 5.2 - MUST provide, and document, an upgrade path from
      existing YANG/protocols.

      Req 5.3 - MUST consider the impact of versioning on instance data.

Wilton                   Expires January 4, 2020                [Page 3]
Internet-Draft      YANG Versioning Solution Overview          July 2019

3.  Solution Drafts

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

3.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 provides a solution for all requirements except Req 2.2,
   Req 3.1 and Req 3.2.

   The extensions and changes in the draft 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.

Wilton                   Expires January 4, 2020                [Page 4]
Internet-Draft      YANG Versioning Solution Overview          July 2019

   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.

3.2.  Module semantic version number scheme

   [TODO - Insert draft ref] defines a semantic versioning scheme
   derived from the semver.org 2.0.0 specification that can be used in
   conjunction with the revision label extension statement defined in
   Section 3.1 to allow semantic version numbers to be used to manage
   the revision lifecycle of YANG modules.  This draft 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:

      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 give a more informative identifier for a branched revision
      history over revision dates alone.

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

3.3.  Versioned YANG packages

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

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

   The principle aims of the packages draft are:

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

Wilton                   Expires January 4, 2020                [Page 5]
Internet-Draft      YANG Versioning Solution Overview          July 2019

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

   The YANG packages draft does not address any of the versioning
   requirements directly, but provides the foundation building blocks
   for the version selection solution, described in Section 3.4, that
   addresses Reqs 3.1 and 3.2.

   This draft requires updates to accommodate the split between revision
   management in [I-D.verdt-netmod-yang-module-versioning] and the
   semantic versioning scheme.

3.4.  Protocol operations for package version selection

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

   The version selection optionally allows:

      Servers to support a single, selectable YANG package at a
      particular version, that is used for all NETCONF/RESTCONF
      interactions.

      Servers to support multiple selectable YANG packages and package
      versions, with different clients able to concurrently access
      different packages and different package versions.

3.5.  YANG schema comparison tooling

   A tooling based solution is proposed for Req 2.2, that allows two
   YANG schema versions to be algorithmically compared, with the
   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

Wilton                   Expires January 4, 2020                [Page 6]
Internet-Draft      YANG Versioning Solution Overview          July 2019

   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
   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 a more accurate answer as to whether a client would
   be affected when upgrading between two software versions, than
   looking at the revision history, or comparing semantic version
   numbers.

4.  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 and specifying the requirements:

   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

5.  Security Considerations

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

Wilton                   Expires January 4, 2020                [Page 7]
Internet-Draft      YANG Versioning Solution Overview          July 2019

6.  IANA Considerations

   None

7.  References

7.1.  Normative References

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

   [I-D.rwilton-netmod-yang-packages]
              Wilton, R., "YANG Packages", draft-rwilton-netmod-yang-
              packages-01 (work in progress), March 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-00 (work in progress), July 2019.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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>.

7.2.  Informative References

   [RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
              Model for L3VPN Service Delivery", RFC 8049,
              DOI 10.17487/RFC8049, February 2017,
              <https://www.rfc-editor.org/info/rfc8049>.

   [RFC8199]  Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
              Classification", RFC 8199, DOI 10.17487/RFC8199, July
              2017, <https://www.rfc-editor.org/info/rfc8199>.

Wilton                   Expires January 4, 2020                [Page 8]
Internet-Draft      YANG Versioning Solution Overview          July 2019

   [RFC8299]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
              "YANG Data Model for L3VPN Service Delivery", RFC 8299,
              DOI 10.17487/RFC8299, January 2018,
              <https://www.rfc-editor.org/info/rfc8299>.

Author's Address

   Robert Wilton (editor)
   Cisco Systems, Inc.

   Email: rwilton@cisco.com

Wilton                   Expires January 4, 2020                [Page 9]