<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" ipr="trust200902" docName="draft-ietf-netmod-yang-schema-comparison-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.3.0 -->
  <front>
    <title abbrev="YANG Schema Comparison">YANG Schema Comparison</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-schema-comparison-01"/>
    <author initials="R." surname="Wilton" fullname="Robert Wilton">
      <organization abbrev="Cisco Systems, Inc.">
    Cisco Systems, Inc.
      </organization>
      <address>
        <email>rwilton@cisco.com</email>
      </address>
    </author>
    <date/>
    <abstract>
      <t>This document specifies an algorithm for comparing two revisions of a YANG
  schema to determine the scope of changes, and a list of changes, between the
  revisions.  The output of the algorithm can be used to help select an
  appropriate revision-label or YANG semantic version number for a new revision.
  This document defines a YANG extension that provides YANG annotations to help
  the tool accurately determine the scope of changes between two revisions.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Warning, this is an early (-00) draft with the intention of scoping the
   outline of the solution, hopefully for the WG to back the direction of the
   solution.  Refinement of the solution details is expected, if this approach
   is accepted by the WG.</t>
      <t>This document defines a solution to Requirement 2.2 in <xref target="I-D.ietf-netmod-yang-versioning-reqs" format="default"/>.  Complementary documents
   provide a complete solution to the YANG versioning requirements, with the
   overall relationship of the solution drafts described in <xref target="I-D.ietf-netmod-yang-solutions" format="default"/>.</t>
      <t>YANG module 'revision-labels' <xref target="I-D.ietf-netmod-yang-module-versioning" format="default"/> and the use of YANG
   semantic version numbers <xref target="I-D.ietf-netmod-yang-semver" format="default"/> can
   be used to help manage and report changes between revisions of individual
   YANG modules.</t>
      <t>YANG packages <xref target="I-D.ietf-netmod-yang-packages" format="default"/> along with
   YANG semantic version numbers can be used to help manage and report changes
   between revisions of YANG schema.</t>
      <t><xref target="I-D.ietf-netmod-yang-module-versioning" format="default"/> and <xref target="I-D.ietf-netmod-yang-packages" format="default"/> define how to classify changes
   between two module or package revisions, respectively, as backwards
   compatible or non-backwards-compatible. <xref target="I-D.ietf-netmod-yang-semver" format="default"/> refines the definition, to allow
   backwards compatible changes to be classified as 'minor changes' or
   'editorial changes'.</t>
      <t>'Revision-label's and YANG semantic version numbers, whilst being
   generally simple and helpful in the mainline revision history case, are not
   sufficient in all scenarios.  For example, when comparing two
   revisions/versions on independent revision branches, without a direct
   ancestor relationship between the two revisions/versions.  In this cases, an
   algorithmic comparison approach is beneficial.</t>
      <t>In addition, the module revision history's 'nbc-changes' extension
   statement, and YANG semantic version numbers, effectively declare the worst
   case scenario.  If any non-backwards-compatible changes are restricted to
   only parts of the module/schema that are not used by an operator, then the
   operator is able to upgrade, and effectively treat the differences between
   the two revisions/versions as backwards compatible because they are not
   materially impacted by the non-backwards-compatible changes.</t>
      <t>Hence, this document defines algorithms that can be applied to revisions
   of YANG modules or versions of YANG schema (e.g., as represented by YANG
   packages), to determine the changes, and scope of changes between the
   revisions/versions.</t>
      <t>For many YANG statements, programmatic tooling can determine whether the
   changes between the statements constitutes a backwards-compatible or
   non-backwards-compatible change.  However, for some statements, it is not
   feasible for current tooling to determine whether the changes are
   backwards-compatible or not.  For example, in the general case, tooling
   cannot determine whether the change in a YANG description statement causes a
   change in the semantics of a YANG data node.  If the change is to fix a typo
   or spelling mistake then the change can be classified as an editorial
   backwards-compatible change.  Conversely, if the change modifies the
   behavioral specification of the data node then the change would need to be
   classified as either a non editorial backwards-compatible change or a
   non-backwards-compatible change.  Hence, extension statements are defined to
   annotate a YANG module with additional information to clarify the scope of
   changes in cases that cannot be determined by algorithmic comparison.</t>
      <t>Open issues are tracked at <eref target="https://github.com/netmod-wg/yang-ver-dt/issues"/>, tagged with
   'schema-comparison'.</t>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology and Conventions</name>
      <t>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
   <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
   appear in all capitals, as shown here.</t>
      <t>This document uses terminology introduced in the YANG versioning
   requirements document <xref target="I-D.ietf-netmod-yang-versioning-reqs" format="default"/>.</t>
      <t>This document makes of the following terminology introduced in the
   YANG Packages <xref target="I-D.ietf-netmod-yang-packages" format="default"/>:
      </t>
      <ul spacing="normal">
        <li>YANG schema</li>
      </ul>
      <t>In addition, this document defines the terminology:
      </t>
      <ul spacing="normal">
        <li>Change scope: Whether a change between two revisions is classified as
        non-backwards-compatible, backwards-compatible, or editorial.</li>
      </ul>
    </section>
    <section anchor="generic_comparison_algorithm" numbered="true" toc="default">
      <name>Generic YANG schema tree comparison algorithm</name>
      <t>The generic schema comparison algorithm works on any YANG schema.  This
   could be a schema associated with an individual YANG module, or a YANG schema
   represented by a set of modules, e.g., specified by a YANG package.</t>
      <t>The algorithm performs a recursive tree wise comparison of two revisions
   of a YANG schema, with the following behavior:
      </t>
      <ul empty="true" spacing="normal">
        <li>The comparison algorithm primarily acts on the parts of the schema
     defined by unique identifiers.</li>
        <li>Each identifier is qualified with the name of the module that
     defines the identifier.</li>
        <li>Identifiers in different namespaces (as defined in 6.2.1 or RFC 7950)
     are compared separately.  E.g., 'features' are compared separately from
     'identities'.</li>
        <li>Within an identifier namespace, the identifiers are compared between the
     two schema revisions by qualified identifier name.  The 'renamed-from'
     extension allow for a meaningful comparison where the name of the identifier
     has changed between revisions.  The 'renamed-from' identifier parameter is
     only used when an identifier in the new schema revision cannot be found in
     the old schema revision.</li>
        <li>YANG extensions, features, identities, typedefs are checked by comparing
     the properties defined by their YANG sub-statements between the two
     revisions.</li>
        <li>YANG groupings, top-level data definition statements, rpcs, and
     notifications are checked by comparing the top level properties defined by
     their direct child YANG sub-statements, and also by recursively checking the
     data definition statements.</li>
        <li>The rules specified in section 3 of <xref target="I-D.ietf-netmod-yang-module-versioning" format="default"/> determine whether the
     changes are backwards-compatible or non-backwards-compatible.</li>
        <li>The rules specified in section 3.2 of <xref target="I-D.ietf-netmod-yang-packages" format="default"/> determine whether
     backwards-compatible changes are 'minor' or 'editorial'.</li>
        <li>For YANG description", "must", and "when" statements, the
     "backwards-compatible" and "editorial" extension statements can be used to
     mark instances when the statements have changed in a backwards-compatible
     or editorial way.  Since by default the comparison algorithm assumes that
     any changes in these statements are non-backwards-compatible.  XXX, more
     info required here, since the revisions in the module history probably need
     to be available for this to work in the general branched revisions
     case.</li>
        <li>Submodules are not relevant for schema comparison purposes, i.e. the
     comparison is performed after submodule resolution has been completed.</li>
      </ul>
      <section anchor="change_scope_statements" numbered="true" toc="default">
        <name>YANG module revision scope extension annotations</name>
        <t/>
      </section>
    </section>
    <section anchor="module_comparison_algorithm" numbered="true" toc="default">
      <name>YANG module comparison algorithm</name>
      <t>The schema comparison algorithm defined in <xref target="generic_comparison_algorithm" format="default"/> can be used to compare the schema for
   individual modules, but with the following modifications:
      </t>
      <ul empty="true" spacing="normal">
        <li>Changes to the module's metadata information (i.e. module level
     description, contact, organization, reference) should be checked (as
     potential editorial changes).</li>
        <li>The module's revision history should be ignored from the comparison.</li>
        <li>Changes to augmentations and deviations should be sorted by path and
     compared.</li>
      </ul>
    </section>
    <section anchor="schema_comparison_algorithm" numbered="true" toc="default">
      <name>YANG schema comparison algorithms</name>
      <section anchor="standard_schema_comparison_algorithm" numbered="true" toc="default">
        <name>Standard YANG schema comparison algorithm</name>
        <t>The standard method for comparing two YANG schema versions is to individually
     compare the module revisions for each module implemented by the schema
     using the algorithm defined in <xref target="module_comparison_algorithm" format="default"/>
     and then aggregating the results together: 
        </t>
        <ul spacing="normal">
          <li>If all implemented modules in the schema have only changed in an editorial way then the schema 
           is changed in an editorial way</li>
          <li>If all implemented modules in the schema have only been changed in an editorial or backwards-compatible 
           way then the schema is changed in a backwards-compatible way</li>
          <li>Otherwise if any implemented module in the schema has been changed in a non-backwards-compatible way then the
           schema is changed in a non-backwards-compatible way.</li>
        </ul>
        <t>The standard schema comparison method is the RECOMMENDED scheme to
     calculate the version number change for new versions of YANG packages,
     because it allows the package version to be calculated based on changes to
     implemented modules revision history (or YANG semantic version number if
     used to identify module revisions).</t>
      </section>
      <section anchor="advanced_schema_comparison_algorithm" numbered="true" toc="default">
        <name>Filtered YANG schema comparison algorithm</name>
        <t>Another method to compare YANG schema, that is less likely to report inconsequential differences, is to
     construct full schema trees for the two schema versions, directly apply a version of the comparison
     algorithm defined in <xref target="generic_comparison_algorithm" format="default"/>.  This may be
     particular useful when the schema represents a complete datastore schema for a server because it allows various
     filtered to the comparison algorithm to provide a more specific answer about what changes may impact a
     particular client.</t>
        <t>The full schema tree can easily be constructed from a YANG package
     definition, or alternative YANG schema definition.</t>
        <t>Controlled by input parameters to the comparison algorithm, the
     following parts of the schema trees can optionally be filtered during the
     comparison:
        </t>
        <ul empty="true" spacing="normal">
          <li>All "grouping" statements can be ignored (after all "use" statements
       have been processed when constructing the schema).</li>
          <li>All module and submodule metadata information (i.e. module level
       description, contact, organization, reference) can be ignored.</li>
          <li>The comparison can be restricted to the set of features that are of
       interest (different sets of features may apply to each schema
       versions).</li>
          <li>The comparison can be restricted to the subset of data nodes, RPCs,
       notifications and actions, that are of interest (e.g., the subset
       actually used by a particular client), providing a more meaningful
       result.</li>
          <li>The comparison could filter out backwards-compatible 'editorial'
       changes.</li>
        </ul>
        <t>In addition to reporting the overall scope of changes at the schema
     level, the algorithm output can also optionally generate a list of specific
     changes between the two schema, along with the classification of those
     individual changes.</t>
      </section>
    </section>
    <section anchor="comparison_tooling" numbered="true" toc="default">
      <name>Comparison tooling</name>
      <t>'pyang' has some support for comparison two module revisions, but this is
   currently limited to a linear module history.</t>
      <t>TODO, it would be helpful if there is reference tooling for schema
   comparison.</t>
    </section>
    <section anchor="yang_modules" numbered="true" toc="default">
      <name>Module Versioning Extension YANG Modules</name>
      <t keepWithNext="true"> YANG module with extension statements for annotating NBC changes, revision label, status description,
      and importing by version.</t>
      <sourcecode name="ietf-yang-rev-annotations@2019-11-11.yang" type="" markers="true">
module ietf-yang-rev-annotations {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-yang-rev-annotations";
  prefix rev-ext;

  organization
    "IETF NETMOD (Network Modeling) Working Group";
  contact
    "WG Web:   &lt;https://datatracker.ietf.org/wg/netmod/&gt;
     WG List:  &lt;mailto:netmod@ietf.org&gt;

     Author:   Robert Wilton
               &lt;mailto:rwilton@cisco.com&gt;";

  description
    "This YANG 1.1 module contains extensions to annotation to YANG
     module with additional metadata information on the nature of
     changes between two YANG module revisions.

     XXX, maybe these annotations could also be included in
     ietf-yang-revisions?

     Copyright (c) 2019 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.

     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 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";

  // RFC Ed.: update the date below with the date of RFC publication
  // and remove this note.
  // RFC Ed.: replace XXXX (inc above) with actual RFC number and
  // remove this note.

  revision 2019-11-11 {
    description
      "Initial version.";
    reference
      "XXXX: YANG Schema Comparison";
  }

  extension backwards-compatible {
    argument revision-date-or-label;
    description
      "Identifies a revision (by revision-label, or revision date if
       a revision-label is not available) where a
       backwards-compatible change has occurred relative to the
       previous revision listed in the revision history.

       The format of the revision-label argument MUST conform to the
       pattern defined for the ietf-yang-revisions
       revision-date-or-label typedef.

       The following YANG statements MAY have zero or more
       'rev-ext:non-backwards-compatible' statements:
           description
           must
           when

       Each YANG statement MUST only a have a single
       non-backwards-compatible, backwards-compatible, or editorial
       extension statement for a particular revision-label, or
       corresponding revision-date.";

    reference
      "XXXX: YANG Schema Comparison;
       Section XXX, XXX";
  }

  extension editorial {
    argument revision-date-or-label;
    description
      "Identifies a revision (by revision-label, or revision date if
       a revision-label is not available) where an editorial change
       has occurred relative to the previous revision listed in the
       revision history.

       The format of the revision-label argument MUST conform to the
       pattern defined for the ietf-yang-revisions
       revision-date-or-label typedef.

       The following YANG statements MAY have zero or more
       'rev-ext:non-backwards-compatible' statements:
           description

       Each YANG statement MUST only a have a single
       non-backwards-compatible, backwards-compatible, or editorial
       extension statement for a particular revision-label or
       corresponding revision-date.";

    reference
      "XXXX: YANG Schema Comparison;
       Section XXX, XXX";
  }

  extension renamed-from {
    argument yang-identifier;
    description
      "Specifies a previous name for this identifier.

       This can be used when comparing schema to optimize handling
       for data nodes that have been renamed rather than naively
       treated them as data nodes that have been deleted and
       recreated.

       The argument 'yang-identifier' MUST take the form of a YANG
       identifier, as defined in section 6.2 of RFC 7950.

       Any YANG statement that takes a YANG identifier as its
       argument MAY have a single 'rev-ext:renamed-from'
       sub-statement.

       TODO, we should also facilitate identifiers being moved into
       other modules, e.g. by supporting a module-name qualified
       identifier.";

    reference
      "XXXX: YANG Schema Comparison;
       Section XXX, XXX";
  }
}
</sourcecode>
    </section>
    <section anchor="contributor" numbered="true" toc="default">
      <name>Contributors</name>
      <t>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 the design team and have worked on the YANG versioning project:</t>
      <ul spacing="normal">
        <li>Balazs Lengyel</li>
        <li>Benoit Claise</li>
        <li>Bo Wu</li>
        <li>Ebben Aries</li>
        <li>Jason Sterne</li>
        <li>Joe Clarke</li>
        <li>Juergen Schoenwaelder</li>
        <li>Mahesh Jethanandani</li>
        <li>Michael Wang</li>
        <li>Qin Wu</li>
        <li>Reshad Rahman</li>
        <li>Rob Wilton</li>
      </ul>
      <t>The ideas for a tooling based comparison of YANG module revisions was
   first described in <xref target="I-D.clacla-netmod-yang-model-update" format="default"/>.
   This document extends upon those initial ideas.</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The document does not define any new protocol or data model.  There
  are no security impacts.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="yang-module-registrations" numbered="true" toc="default">
        <name>YANG Module Registrations</name>
        <t>The following YANG module is requested to be registered in the "IANA
  Module Names" registry:</t>
        <t>The ietf-yang-rev-annotations module:</t>
        <ul empty="true" spacing="normal">
          <li>Name: ietf-yang-rev-annotations</li>
          <li>XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-rev-annotations</li>
          <li>Prefix: rev-ext</li>
          <li>Reference: [RFCXXXX]</li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-yang-solutions" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-solutions.xml">
          <front>
            <title>YANG Versioning Solution Overview</title>
            <author initials="R" surname="Wilton" fullname="Robert Wilton">
              <organization/>
            </author>
            <date month="March" day="19" year="2020"/>
            <abstract>
              <t>This document gives an overview of the different documents that comprise a full solution to the YANG versioning requirements document.  The purpose of this document is to help readers understand how the discrete parts of the YANG versioning solution fit together during working group development of the solution documents.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-solutions-00"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-solutions-00.txt"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-yang-versioning-reqs" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-versioning-reqs.xml">
          <front>
            <title>YANG Module Versioning Requirements</title>
            <author initials="J" surname="Clarke" fullname="Joe Clarke">
              <organization/>
            </author>
            <date month="June" day="29" year="2020"/>
            <abstract>
              <t>This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility.  It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-versioning-reqs-03"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-versioning-reqs-03.txt"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-yang-packages" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-packages.xml">
          <front>
            <title>YANG Packages</title>
            <author initials="R" surname="Wilton" fullname="Robert Wilton">
              <organization/>
            </author>
            <author initials="R" surname="Rahman" fullname="Reshad Rahman">
              <organization/>
            </author>
            <author initials="J" surname="Clarke" fullname="Joe Clarke">
              <organization/>
            </author>
            <author initials="J" surname="Sterne" fullname="Jason Sterne">
              <organization/>
            </author>
            <author initials="W" surname="Bo" fullname="Wu Bo">
              <organization/>
            </author>
            <date month="March" day="17" year="2020"/>
            <abstract>
              <t>This document defines YANG packages, a versioned organizational structure holding a set of related YANG modules, that collectively define a YANG schema.  It describes how packages: are represented on a server, can be defined in offline YANG instance data documents, and can be used to define the schema associated with YANG instance data documents.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-packages-00"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-packages-00.txt"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-yang-semver" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-semver.xml">
          <front>
            <title>YANG Semantic Versioning</title>
            <author initials="B" surname="Claise" fullname="Benoit Claise">
              <organization/>
            </author>
            <author initials="J" surname="Clarke" fullname="Joe Clarke">
              <organization/>
            </author>
            <author initials="R" surname="Rahman" fullname="Reshad Rahman">
              <organization/>
            </author>
            <author initials="R" surname="Wilton" fullname="Robert Wilton">
              <organization/>
            </author>
            <author initials="B" surname="Lengyel" fullname="Balazs Lengyel">
              <organization/>
            </author>
            <author initials="J" surname="Sterne" fullname="Jason Sterne">
              <organization/>
            </author>
            <author initials="K" surname="D'Souza" fullname="Kevin D'Souza">
              <organization/>
            </author>
            <date month="July" day="13" year="2020"/>
            <abstract>
              <t>This document specifies a scheme and guidelines for applying a modified set of semantic versioning rules to revisions of YANG modules.  Additionally, this document defines a revision-label for this modified semver scheme.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-semver-01"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-semver-01.txt"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-yang-module-versioning" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-module-versioning.xml">
          <front>
            <title>Updated YANG Module Revision Handling</title>
            <author initials="R" surname="Wilton" fullname="Robert Wilton">
              <organization/>
            </author>
            <author initials="R" surname="Rahman" fullname="Reshad Rahman">
              <organization/>
            </author>
            <author initials="B" surname="Lengyel" fullname="Balazs Lengyel">
              <organization/>
            </author>
            <author initials="J" surname="Clarke" fullname="Joe Clarke">
              <organization/>
            </author>
            <author initials="J" surname="Sterne" fullname="Jason Sterne">
              <organization/>
            </author>
            <author initials="B" surname="Claise" fullname="Benoit Claise">
              <organization/>
            </author>
            <author initials="K" surname="D'Souza" fullname="Kevin D'Souza">
              <organization/>
            </author>
            <date month="July" day="10" year="2020"/>
            <abstract>
              <t>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.  This document updates RFC 7950, RFC 8407 and RFC 8525.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-module-versioning-01"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-module-versioning-01.txt"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.clacla-netmod-yang-model-update" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.clacla-netmod-yang-model-update.xml">
          <front>
            <title>New YANG Module Update Procedure</title>
            <author initials="B" surname="Claise" fullname="Benoit Claise">
              <organization/>
            </author>
            <author initials="J" surname="Clarke" fullname="Joe Clarke">
              <organization/>
            </author>
            <author initials="B" surname="Lengyel" fullname="Balazs Lengyel">
              <organization/>
            </author>
            <author initials="K" surname="D'Souza" fullname="Kevin D'Souza">
              <organization/>
            </author>
            <date month="July" day="2" year="2018"/>
            <abstract>
              <t>This document specifies a new YANG module update procedure in case of backward-incompatible changes, as an alternative proposal to the YANG 1.1 specifications.  This document updates RFC 7950.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-clacla-netmod-yang-model-update-06"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-clacla-netmod-yang-model-update-06.txt"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
<!-- Local Variables: -->
<!-- fill-column:120 -->
<!-- End: -->
