diff --git a/yang-schema-comparison/draft-verdt-netmod-yang-schema-comparision.txt b/yang-schema-comparison/draft-verdt-netmod-yang-schema-comparision.txt
new file mode 100755
index 0000000..dd28329
--- /dev/null
+++ b/yang-schema-comparison/draft-verdt-netmod-yang-schema-comparision.txt
@@ -0,0 +1,728 @@
+
+
+
+
+Network Working Group                                          R. Wilton
+Internet-Draft                                       Cisco Systems, Inc.
+Intended status: Standards Track                       November 12, 2019
+Expires: May 15, 2020
+
+
+                         YANG Schema Comparison
+              draft-verdt-netmod-yang-schema-comparison-00
+
+Abstract
+
+   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.
+
+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 15, 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
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 1]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   4
+   3.  Generic YANG schema tree comparison algorithm . . . . . . . .   4
+     3.1.  YANG module revision scope extension annotations  . . . .   5
+   4.  YANG module comparison algorithm  . . . . . . . . . . . . . .   5
+   5.  YANG schema comparison algorithms . . . . . . . . . . . . . .   6
+     5.1.  Standard YANG schema comparison algorithm . . . . . . . .   6
+     5.2.  Advanced YANG schema comparison algorithm . . . . . . . .   6
+   6.  Comparision tooling . . . . . . . . . . . . . . . . . . . . .   7
+   7.  Module Versioning Extension YANG Modules  . . . . . . . . . .   7
+   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
+     10.1.  YANG Module Registrations  . . . . . . . . . . . . . . .  11
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13
+
+1.  Introduction
+
+   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.
+
+   This document defines a solution to Requirement 2.2 in
+   [I-D.verdt-netmod-yang-versioning-reqs].  Complementary documents
+   provide a complete solution to the YANG versioning requirements, with
+   the overall relationship of the solution drafts described in
+   [I-D.verdt-netmod-yang-solutions].
+
+   YANG module 'revision-labels'
+   [I-D.verdt-netmod-yang-module-versioning] and the use of YANG
+   semantic version numbers [I-D.verdt-netmod-yang-semver] can be used
+   to help manage and report changes between revisions of individual
+   YANG modules.
+
+   YANG packages [I-D.rwilton-netmod-yang-packages] along with YANG
+   semantic version numbers can be used to help manage and report
+   changes between revisions of YANG schema.
+
+
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 2]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+   [I-D.verdt-netmod-yang-module-versioning] and
+   [I-D.rwilton-netmod-yang-packages] define how to classify changes
+   between two module or package revisions, respectively, as backwards
+   compatible or non-backwards-compatible.
+   [I-D.verdt-netmod-yang-semver] refines the definition, to allow
+   backwards compatible changes to be classified as 'minor changes' or
+   'editorial changes'.
+
+   '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.
+
+   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.
+
+   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.
+
+   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.
+
+   Open issues are tracked at <https://github.com/netmod-wg/yang-ver-dt/
+   issues>, tagged with 'schema-comparison'.
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 3]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+2.  Terminology and Conventions
+
+   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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document uses terminology introduced in the YANG versioning
+   requirements document [I-D.verdt-netmod-yang-versioning-reqs].
+
+   This document makes of the following terminology introduced in the
+   YANG Packages [I-D.rwilton-netmod-yang-packages]:
+
+   o  YANG schema
+
+   In addition, this document defines the terminology:
+
+   o  Change scope: Whether a change between two revisions is classified
+      as non-backwards-compatible, backwards-compatible, or editorial.
+
+3.  Generic YANG schema tree comparison algorithm
+
+   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.
+
+   The algorithm performs a recursive tree wise comparison of two
+   revisions of a YANG schema, with the following behavior:
+
+      The comparision algorithm primarily acts on the parts of the
+      schema defined by unique identifiers.
+
+      Each identifier is qualified with the name of the module that
+      defines the identifier.
+
+      Identifiers in different namespaces (as defined in 6.2.1 or RFC
+      7950) are compared separately.  E.g., 'features' are compared
+      separately from 'identities'.
+
+      Within an identifer namespace, the identifiers are compared
+      between the two schema revisions by qualified identifier name.
+      The 'renamed-from' extension allow for meaningful comparison where
+      the name of the identifier has changed between revisions.  The
+      'renamed-from' identifier parameter is only used when an identifer
+      in the new schema revision cannot be found in the old schema
+      evision.
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 4]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+      YANG extensions, features, identities, typedefs are checked by
+      comparing the properties defined by their YANG substatements
+      between the two revisions.
+
+      YANG groupings, top-level data definition statements, rpcs, and
+      notifications are checked by comparing the top level properties
+      defined by their direct child YANG substatements, and also by
+      recursively checking the data definition statements.
+
+      The rules specified in section 3 of
+      [I-D.verdt-netmod-yang-module-versioning] determine whether the
+      changes are backwards-compatible or non-backwards-compatible.
+
+      The rules specified in section 3.2 of
+      [I-D.rwilton-netmod-yang-packages] determine whether backwards-
+      compatible changes are 'minor' or 'editorial'.
+
+      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 my 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.
+
+      Submodules are not relevant for schema comparison purposes, i.e.
+      the comparison is performed after submodule resolution has been
+      completed.
+
+3.1.  YANG module revision scope extension annotations
+
+4.  YANG module comparison algorithm
+
+   The schema comparision algorithm defined in Section 3 can be used to
+   compare the schema for individual modules, but with the following
+   modifications:
+
+      Changes to the module's metadata information (i.e. module level
+      description, contact, organization, reference) should be checked
+      (as potential editorial changes).
+
+      The module's revision history should be ignored from the
+      comparison.
+
+      Changes to augmentations and deviations should be sorted by path
+      and compared.
+
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 5]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+5.  YANG schema comparison algorithms
+
+5.1.  Standard YANG schema comparison algorithm
+
+   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 Section 4 and then
+   aggregating the results together: If all implemented module in the
+   schema have only changed in an editorial way then the schema is
+   changed in an editorial way, but 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,
+   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.
+
+   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).
+
+5.2.  Advanced YANG schema comparison algorithm
+
+   A more accurate method to compare YANG schema, that is less likely to
+   report inconsequential differences, is to construct full schema trees
+   for the two schema versions, and then directly apply a version of the
+   comparison algorithm defined in Section 3.  This may be particular
+   useful when the schema represents a complete datastore schema for a
+   server because it allows various refinements to the comparison
+   algorithm to provide a more specific answer about what changes may
+   impact a particular client.
+
+   The full schema tree can easily be constructed from a YANG package
+   definition, or alternative YANG schema definition.
+
+   Controlled by input parameters to the comparison algorithm, the
+   following parts of the schema trees can optionally be ignored during
+   the comparison:
+
+      All "grouping" statements can be ignored (after all "use"
+      statements have been processed when constructing the schema).
+
+      All module and submodule metadata information (i.e. module level
+      description, contact, organization, reference) can be ignored.
+
+
+
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 6]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+      The comparison can be restricted to the set of features that are
+      of interest (different sets of features may apply to each schema
+      versions).
+
+      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.
+
+      The comparison could filter out backwards-compatible 'editorial'
+      changes.
+
+   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.
+
+6.  Comparision tooling
+
+   'pyang' has some support for comparison two module revisions, but
+   this is currently limited to a linear module history.
+
+   TODO, it would be helpful if there is reference tooling for schema
+   comparison.
+
+7.  Module Versioning Extension YANG Modules
+
+   YANG module with extension statements for annotating NBC changes,
+   revision label, status description, and importing by version.
+
+   <CODE BEGINS> file "ietf-yang-rev-annotations@2019-11-11.yang"
+   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:   <https://datatracker.ietf.org/wg/netmod/>
+        WG List:  <mailto:netmod@ietf.org>
+
+        Author:   Robert Wilton
+                  <mailto:rwilton@cisco.com>";
+
+     description
+       "This YANG 1.1 module contains extensions to annotation to YANG
+        module with additional metadata information on the nature of
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 7]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+        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.
+
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 8]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+          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
+
+
+
+Wilton                    Expires May 15, 2020                  [Page 9]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+          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";
+     }
+   }
+   <CODE ENDS>
+
+8.  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 the design team and have worked on the YANG versioning
+   project:
+
+   o  Balazs Lengyel
+
+   o  Benoit Claise
+
+   o  Bo Wu
+
+   o  Ebben Aries
+
+   o  Jason Sterne
+
+   o  Joe Clarke
+
+   o  Juergen Schoenwaelder
+
+   o  Mahesh Jethanandani
+
+   o  Michael Wang
+
+   o  Qin Wu
+
+
+
+Wilton                    Expires May 15, 2020                 [Page 10]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+   o  Reshad Rahman
+
+   o  Rob Wilton
+
+   The ideas for a tooling based comparision of YANG module revisions
+   was first described in [I-D.clacla-netmod-yang-model-update].  This
+   document extends upon those initial ideas.
+
+9.  Security Considerations
+
+   The document does not define any new protocol or data model.  There
+   are no security impacts.
+
+10.  IANA Considerations
+
+10.1.  YANG Module Registrations
+
+   The following YANG module is requested to be registred in the "IANA
+   Module Names" registry:
+
+   The ietf-yang-rev-annotations module:
+
+      Name: ietf-yang-rev-annotations
+
+      XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-rev-
+      annotations
+
+      Prefix: rev-ext
+
+      Reference: [RFCXXXX]
+
+11.  References
+
+11.1.  Normative 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.
+
+
+
+
+
+
+
+Wilton                    Expires May 15, 2020                 [Page 11]
+
+Internet-Draft           YANG Schema Comparison            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.verdt-netmod-yang-solutions]
+              Wilton, R., "YANG Versioning Solution Overview", draft-
+              verdt-netmod-yang-solutions-01 (work in progress), July
+              2019.
+
+   [I-D.verdt-netmod-yang-versioning-reqs]
+              Clarke, J., "YANG Module Versioning Requirements", draft-
+              verdt-netmod-yang-versioning-reqs-02 (work in progress),
+              November 2018.
+
+   [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>.
+
+   [RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
+              Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
+              <https://www.rfc-editor.org/info/rfc7895>.
+
+   [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>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
+              Documents Containing YANG Data Models", BCP 216, RFC 8407,
+              DOI 10.17487/RFC8407, October 2018,
+              <https://www.rfc-editor.org/info/rfc8407>.
+
+   [RFC8525]  Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
+              and R. Wilton, "YANG Library", RFC 8525,
+              DOI 10.17487/RFC8525, March 2019,
+              <https://www.rfc-editor.org/info/rfc8525>.
+
+11.2.  Informative References
+
+
+
+
+
+
+
+Wilton                    Expires May 15, 2020                 [Page 12]
+
+Internet-Draft           YANG Schema Comparison            November 2019
+
+
+   [I-D.clacla-netmod-yang-model-update]
+              Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New
+              YANG Module Update Procedure", draft-clacla-netmod-yang-
+              model-update-06 (work in progress), July 2018.
+
+   [I-D.ietf-netmod-yang-instance-file-format]
+              Lengyel, B. and B. Claise, "YANG Instance Data File
+              Format", draft-ietf-netmod-yang-instance-file-format-04
+              (work in progress), August 2019.
+
+   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+              <https://www.rfc-editor.org/info/rfc8340>.
+
+   [semver]   "Semantic Versioning 2.0.0", <https://www.semver.org>.
+
+Author's Address
+
+   Robert Wilton
+   Cisco Systems, Inc.
+
+   Email: rwilton@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wilton                    Expires May 15, 2020                 [Page 13]
diff --git a/yang-schema-comparison/draft-verdt-netmod-yang-schema-comparision.xml b/yang-schema-comparison/draft-verdt-netmod-yang-schema-comparision.xml
new file mode 100644
index 0000000..159bc62
--- /dev/null
+++ b/yang-schema-comparison/draft-verdt-netmod-yang-schema-comparision.xml
@@ -0,0 +1,493 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY RFC6020 SYSTEM "reference.RFC.6020.xml">
+<!ENTITY RFC7895 SYSTEM "reference.RFC.7895.xml">
+<!ENTITY RFC7950 SYSTEM "reference.RFC.7950.xml">
+<!ENTITY RFC8407 SYSTEM "reference.RFC.8407.xml">
+<!ENTITY OPENCONFIG-YANG-CATALOG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.openconfig-netmod-model-catalog.xml">
+<!ENTITY CLAISE-SEMVER "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.claise-semver.xml">
+<!ENTITY OPENCONFIG-YANG-CATALOG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.openconfig-netmod-model-catalog.xml">
+<!ENTITY CLACLA-NETMOD-MODEL-CATALOG "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clacla-netmod-model-catalog.xml">
+<!ENTITY VERDT-NETMOD-YANG-VERSIONING-REQS "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.verdt-netmod-yang-versioning-reqs.xml">
+]>
+<?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 category="std" ipr="trust200902" docName="draft-verdt-netmod-yang-schema-comparison-00">
+<front>
+<title abbrev="YANG Schema Comparison">YANG Schema Comparison</title>
+
+
+  <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" title="Introduction">
+   <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.verdt-netmod-yang-versioning-reqs"/>.  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.verdt-netmod-yang-solutions"/>.</t>
+
+   <t>YANG module 'revision-labels' <xref
+   target="I-D.verdt-netmod-yang-module-versioning"/> and the use of YANG
+   semantic version numbers <xref target="I-D.verdt-netmod-yang-semver"/> can
+   be used to help manage and report changes between revisions of individual
+   YANG modules.</t>
+   
+   <t>YANG packages <xref target="I-D.rwilton-netmod-yang-packages"/> 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.verdt-netmod-yang-module-versioning"/> and <xref
+   target="I-D.rwilton-netmod-yang-packages"/> define how to classify changes
+   between two module or package revisions, respectively, as backwards
+   compatible or non-backwards-compatible. <xref
+   target="I-D.verdt-netmod-yang-semver"/> 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" title="Terminology and Conventions">
+   <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"/> <xref target="RFC8174"/> 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.verdt-netmod-yang-versioning-reqs"/>.</t>
+   <t>This document makes of the following terminology introduced in the
+   YANG Packages <xref target="I-D.rwilton-netmod-yang-packages"/>:
+     <list style="symbols">
+       <t>YANG schema</t>
+     </list>
+   </t>      
+   <t>In addition, this document defines the terminology:
+      <list style="symbols">	
+        <t>Change scope: Whether a change between two revisions is classified as
+        non-backwards-compatible, backwards-compatible, or editorial.</t>
+        </list>
+   </t>
+ </section>
+ 
+ <section anchor="generic_comparison_algorithm" title="Generic YANG schema tree comparison algorithm">
+   <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:
+   <list>
+     <t>The comparision algorithm primarily acts on the parts of the schema
+     defined by unique identifiers.</t>
+     <t>Each identifier is qualified with the name of the module that
+     defines the identifier.</t>
+     <t>Identifiers in different namespaces (as defined in 6.2.1 or RFC 7950)
+     are compared separately.  E.g., 'features' are compared separately from
+     'identities'.</t>
+     <t>Within an identifer namespace, the identifiers are compared between the
+     two schema revisions by qualified identifier name.  The 'renamed-from'
+     extension allow for meaningful comparison where the name of the identifier
+     has changed between revisions.  The 'renamed-from' identifier parameter is
+     only used when an identifer in the new schema revision cannot be found in
+     the old schema evision.</t>
+     <t>YANG extensions, features, identities, typedefs are checked by comparing
+     the properties defined by their YANG substatements between the two
+     revisions.</t>
+     <t>YANG groupings, top-level data definition statements, rpcs, and
+     notifications are checked by comparing the top level properties defined by
+     their direct child YANG substatements, and also by recursively checking the
+     data definition statements.</t>
+     <t>The rules specified in section 3 of <xref
+     target="I-D.verdt-netmod-yang-module-versioning"/> determine whether the
+     changes are backwards-compatible or non-backwards-compatible.</t>
+     <t>The rules specified in section 3.2 of <xref
+     target="I-D.rwilton-netmod-yang-packages"/> determine whether
+     backwards-compatible changes are 'minor' or 'editorial'.</t>
+     <t>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 my 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.</t>
+     <t>Submodules are not relevant for schema comparison purposes, i.e. the
+     comparison is performed after submodule resolution has been completed.</t>
+   </list>
+   </t>
+   <section anchor="change_scope_statements" title="YANG module revision scope extension annotations">
+   <t></t>
+   </section>
+ </section>
+
+ <section anchor="module_comparison_algorithm" title="YANG module comparison algorithm">
+   <t>The schema comparision algorithm defined in <xref
+   target="generic_comparison_algorithm"/> can be used to compare the schema for
+   individual modules, but with the following modifications:
+   <list>
+     <t>Changes to the module's metadata information (i.e. module level
+     description, contact, organization, reference) should be checked (as
+     potential editorial changes).</t>
+     <t>The module's revision history should be ignored from the comparison.</t>
+     <t>Changes to augmentations and deviations should be sorted by path and
+     compared.</t>
+   </list></t>
+ </section>
+
+ <section anchor="schema_comparison_algorithm" title="YANG schema comparison algorithms">
+   <section anchor="standard_schema_comparison_algorithm" title="Standard YANG schema comparison algorithm">
+     <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"/>
+     and then aggregating the results together: If all implemented module in the
+     schema have only changed in an editorial way then the schema is changed in
+     an editorial way, but 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, 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.</t>
+     <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" title="Advanced YANG schema comparison algorithm">
+     <t>A more accurate method to compare YANG schema, that is less likely to
+     report inconsequential differences, is to construct full schema trees for
+     the two schema versions, and then directly apply a version of the
+     comparison algorithm defined in <xref
+     target="generic_comparison_algorithm"/>.  This may be particular useful
+     when the schema represents a complete datastore schema for a server because
+     it allows various refinements 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 ignored during the
+     comparison:
+     <list>
+       <t>All "grouping" statements can be ignored (after all "use" statements
+       have been processed when constructing the schema).</t>
+       <t>All module and submodule metadata information (i.e. module level
+       description, contact, organization, reference) can be ignored.</t>
+       <t>The comparison can be restricted to the set of features that are of
+       interest (different sets of features may apply to each schema
+       versions).</t>
+       <t>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.</t>
+       <t>The comparison could filter out backwards-compatible 'editorial'
+       changes.</t>
+     </list>
+     </t>
+
+     <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" title="Comparision tooling">
+   <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" title="Module Versioning Extension YANG Modules">
+  <t>
+    <figure>
+      <preamble> YANG module with extension statements for annotating NBC changes, revision label, status description,
+      and importing by version.</preamble>
+      <artwork><![CDATA[
+<CODE BEGINS> file "ietf-yang-rev-annotations@2019-11-11.yang"
+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:   <https://datatracker.ietf.org/wg/netmod/>
+     WG List:  <mailto:netmod@ietf.org>
+
+     Author:   Robert Wilton
+               <mailto:rwilton@cisco.com>";
+
+  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";
+  }
+}
+<CODE ENDS>
+]]></artwork>
+</figure>
+</t>
+</section>
+
+<section anchor="contributor" title="Contributors">
+  <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>
+      <t>
+        <list style="symbols">
+          <t>Balazs Lengyel</t>
+          <t>Benoit Claise</t>
+          <t>Bo Wu</t>
+          <t>Ebben Aries</t>
+          <t>Jason Sterne</t>
+          <t>Joe Clarke</t>
+          <t>Juergen Schoenwaelder</t>
+          <t>Mahesh Jethanandani</t>
+          <t>Michael Wang</t>
+          <t>Qin Wu</t>
+          <t>Reshad Rahman</t>
+          <t>Rob Wilton</t>
+        </list>
+      </t>
+
+   <t>The ideas for a tooling based comparision of YANG module revisions was
+   first described in <xref target="I-D.clacla-netmod-yang-model-update"/>.
+   This document extends upon those initial ideas.</t>
+</section>
+
+<section anchor="security" title="Security Considerations">
+  <t>The document does not define any new protocol or data model.  There
+  are no security impacts.</t>
+</section>
+<section anchor="iana" title="IANA Considerations">
+  <section anchor="yang-module-registrations" title="YANG Module Registrations">
+  <t>The following YANG module is requested to be registred in the "IANA
+  Module Names" registry:</t>
+
+  <t>The ietf-yang-rev-annotations module:</t>
+
+  <t><list>
+    <t>Name: ietf-yang-rev-annotations</t>
+    <t>XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-rev-annotations</t>
+    <t>Prefix: rev-ext</t>
+    <t>Reference: [RFCXXXX]</t>
+  </list></t>
+</section>
+</section>
+</middle>
+<?rfc needLines="20"?>
+<back>
+<references title="Normative References">
+   <?rfc include='reference.RFC.2119'?>
+   <?rfc include='reference.RFC.8174'?>
+   <?rfc include='reference.RFC.7950'?>
+   <?rfc include='reference.RFC.7895'?>
+   <?rfc include='reference.RFC.8407'?>
+   <?rfc include='reference.RFC.8525'?>
+   <?rfc include="reference.I-D.verdt-netmod-yang-solutions"?>
+   <?ref include='reference.I-D.verdt-netmod-yang-versioning-reqs'?>
+   <?rfc include='reference.I-D.rwilton-netmod-yang-packages'?>
+   <?ref include='reference.I-D.verdt-netmod-yang-semver'?>
+   <?ref include='reference.I-D.verdt-netmod-yang-module-versioning'?>
+</references>
+<references title="Informative References">
+   <?rfc include='reference.RFC.8340'?>
+   <?rfc include='reference.I-D.clacla-netmod-yang-model-update'?>
+   <?rfc include='reference.I-D.ietf-netmod-yang-instance-file-format'?>
+   <reference anchor="semver" target="https://www.semver.org">
+      <front>
+       <title>Semantic Versioning 2.0.0</title>
+       <author/>
+       <date/>
+    </front>
+  </reference>
+</references>
+<?rfc needLines="100"?>
+</back>
+</rfc>
+<!-- Local Variables: -->
+<!-- fill-column:120 -->
+<!-- End: -->
diff --git a/yang-schema-comparison/ietf-yang-rev-annotations.yang b/yang-schema-comparison/ietf-yang-rev-annotations.yang
new file mode 100644
index 0000000..788dad7
--- /dev/null
+++ b/yang-schema-comparison/ietf-yang-rev-annotations.yang
@@ -0,0 +1,133 @@
+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:   <https://datatracker.ietf.org/wg/netmod/>
+     WG List:  <mailto:netmod@ietf.org>
+
+     Author:   Robert Wilton
+               <mailto:rwilton@cisco.com>";
+
+  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";
+  }
+}
diff --git a/yang-ver-schemes/draft-verdt-netmod-yang-semver.xml b/yang-ver-schemes/draft-verdt-netmod-yang-semver.xml
deleted file mode 100644
index 90b9c84..0000000
--- a/yang-ver-schemes/draft-verdt-netmod-yang-semver.xml
+++ /dev/null
@@ -1,838 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
-<!ENTITY RFC6020 SYSTEM "reference.RFC.6020.xml">
-<!ENTITY RFC7895 SYSTEM "reference.RFC.7895.xml">
-<!ENTITY RFC7950 SYSTEM "reference.RFC.7950.xml">
-<!ENTITY RFC8407 SYSTEM "reference.RFC.8407.xml">
-<!ENTITY OPENCONFIG-YANG-CATALOG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.openconfig-netmod-model-catalog.xml">
-<!ENTITY CLAISE-SEMVER "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.claise-semver.xml">
-<!ENTITY OPENCONFIG-YANG-CATALOG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.openconfig-netmod-model-catalog.xml">
-<!ENTITY CLACLA-NETMOD-MODEL-CATALOG "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clacla-netmod-model-catalog.xml">
-<!ENTITY VERDT-NETMOD-YANG-VERSIONING-REQS "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.verdt-netmod-yang-versioning-reqs.xml">
-]>
-<?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 updates="7950" category="std" ipr="trust200902" docName="draft-verdt-netmod-yang-semver-00">
-<front>
-<title abbrev="YANG Semantic Versioning Scheme">A Semantic Versioning Scheme for YANG</title>
-
-<author initials="B." surname="Claise" fullname="Benoit Claise">
-  <organization abbrev="Cisco Systems, Inc.">
-    Cisco Systems, Inc.
- </organization>
-  <address>
-    <postal>
-<street>De Kleetlaan 6a b1</street>
-<city>1831 Diegem</city>
-<country>Belgium</country>
-    </postal>
-    <phone>+32 2 704 5622</phone>
-    <email>bclaise@cisco.com</email>
-  </address>
-</author>
-
-  <author initials="J." surname="Clarke" fullname="Joe Clarke">
-    <organization>Cisco Systems, Inc.</organization>
-    <address>
-      <postal>
-        <street>7200-12 Kit Creek Rd</street>
-        <city>Research Triangle Park</city>
-        <region>North Carolina</region>
-        <country>United States of America</country>
-      </postal>
-      <phone>+1-919-392-2867</phone>
-      <email>jclarke@cisco.com</email>
-    </address>
-  </author>
-
-  <author initials="R." surname="Rahman" fullname="Reshad Rahman">
-  <organization abbrev="Cisco Systems, Inc.">
-    Cisco Systems, Inc.
-  </organization>
-    <address>
-      <email>rrahman@cisco.com</email>
-    </address>
-  </author>
-
-  <author initials="R." role="editor" surname="Wilton" fullname="Robert Wilton">
-  <organization abbrev="Cisco Systems, Inc.">
-    Cisco Systems, Inc.
-  </organization>
-    <address>
-      <email>rwilton@cisco.com</email>
-    </address>
-  </author>
-
-  <author initials="B." surname="Lengyel" fullname="Balazs Lengyel">
-    <organization abbrev="Ericsson"> Ericsson </organization>
-    <address>
-      <postal>
-        <street>Magyar Tudosok Korutja</street>
-        <city>1117 Budapest</city>
-        <country>Hungary</country>
-      </postal>
-      <phone>+36-70-330-7909</phone>
-      <email>balazs.lengyel@ericsson.com</email>
-    </address>
-  </author>
-
- <author initials="J." surname="Sterne" fullname="Jason Sterne">
- <organization abbrev="Nokia">
-    Nokia
-  </organization>
-    <address>
-      <email>jason.sterne@nokia.com</email>
-    </address>
-  </author>
-
-
-<date/>
-<abstract>
-  <t>This document defines a semantic versioning scheme for describing
-  the revision lifecycle of YANG modules.  It builds upon the revision
-  label described in XXX.</t>
-</abstract>
-</front>
-<middle>
-  <section anchor="intro" title="Introduction">
-    <t>XXX allows for implementations to specify an optional 'revision
-    alias' to ascribe additional meaning to a particular revision.</t>
-    <t>This document describes some common version schemes that can be used.</t>
-  <t>This document defines a solution to the YANG module lifecycle
-  problems described in <xref
-  target="I-D.verdt-netmod-yang-versioning-reqs"/>, covering all of the
-  specified requirements except for requirements: 2.2, 3.1, and 3.2.</t>
-
-  <t>Specifically, this document recognises a need to sometimes allow
-  YANG modules to evolve with non-backwards-compatible changes, which
-  might end up breaking clients.  The solution makes use of semantic
-  version numbers to help manage the lifecycle of YANG modules.</t>
-  
-  <t>
-  The solution is comprised of the following seven parts:
-       <list style="bullets">
-       <t>A definition for the YANG semantic versioning scheme for
-       modules, and an explanation of how the semver extension can be
-       used to annotate modules with their semantic version
-       number.</t>
-       <t>A YANG extension to allow YANG module imports to be restricted
-       to modules with particular semantic versions, allowing
-       inter-module version dependencies to be captured within YANG
-       module definitions.</t>
-       <t>Updates to the YANG 1.1 module update rules to accommodate the
-       semantic versioning scheme.</t>
-       <t>Updates and augmentations to ietf-yang-library to include the
-       YANG semantic version number in the module descriptions, to
-       report how 'deprecated' and 'obsolete' nodes are handled by a
-       server, and to clarify how module imports are resolved when
-       multiple versions could otherwise be chosen.</t>
-       <t>A YANG extension to add a 'description' statement to the YANG
-       'status' statement to allow additional documentation as to why a
-       node is being deprecated, and what alternatives may be
-       available.</t>
-       <t>A description of how YANG semantic versioning applies to YANG
-       instance data.</t>
-       <t>Guidelines to YANG module authors on how the YANG semantic
-       versioning rules should be used, along with examples.</t>
-     </list>
-  </t>
-
-  <t>Open issues are listed at <xref target="open_issues"/>, and
-  tracked at <eref target="https://github.com/netmod-wg/yang-ver-dt/issues"/>.</t>
-  </section>
-  
-  <section anchor="yang_semver" title="Semantic versioning with API bugfixes">
-  <t>The chapter defines YANG Semantic Versioning, explains how it is
-  used with YANG modules, and the rules associated with changing a
-  module's semantic version number when the module definitions are
-  updated.</t>
-
-  <t>The YANG semantic versioning scheme applies only to YANG modules.
-  YANG submodules are not independently versioned by the YANG semantic
-  versioning scheme.  Instead, if a versioned module includes one or
-  more submodules then those submodules are implicitly versioned as part
-  of the module's 'semver:version' statements, and all the module's
-  'include' statements MUST specify the revision-date for each of the
-  included submodules.</t>
-
-
-  <section anchor="version_classification" title="Classification of changes between module revisions">
-    <t>The principle aim of YANG semantic versioning is to allow a user
-    of a YANG module to understand the overall significance of any
-    changes between two module revisions solely based on the semantic
-    version number.</t>
-    
-    <t>The semantic version change between any two arbitrary revisions
-    of a YANG module can be classified into one of four categories:
-    'unchanged', 'editorial, 'backwards-compatible' or
-    'non-backwards-compatible'.  A summary of the classification is
-    given below, with the specific rules as they apply to YANG
-    statements provided in XXX [update_rules].
-    <list style="bullets">
-      <t>The semantic version change between two module revisions is
-      defined as 'unchanged' if, after excluding 'revision' and
-      'semver:version' statements and their substatements, the only
-      remaining changes are insignificant white space changes.</t>
-      
-      <t>An 'editorial' module semantic version change is where there
-      are changes in the module's statements, between the two module
-      revisions, but those changes do not affect the syntax or semantic
-      meaning of the module in any way.  An example of an editorial
-      change would be a fix to a spelling mistake in a description
-      statement. </t>
-
-      <t>A 'backwards-compatible' module semantic version change is
-      where some syntax or semantic changes exists between the two
-      module revisions, but all changes follow the rules specified in
-      XXX [bc_update_rules].</t>
-
-      <t>A 'non-backwards-compatible' module semantic version change is
-      where some syntax or semantic changes exists between the two
-      module revisions, and those changes do not follow the rules for a
-      'backwards-compatible' version change.</t>
-    </list>
-    </t>
-  </section>
-
-       
-  <section anchor="versioning_scheme" title="YANG Semantic Versioning Scheme for Modules">
-    <t>This document defines the YANG semantic versioning scheme that is
-    used for YANG modules. The versioning scheme has the following
-    properties:
-    <list style="bullets">
-      <t>The YANG semantic versioning scheme is extended from version
-      2.0.0 of the semantic versioning scheme defined at semver.org <xref
-      target="semver"/> to cover the additional requirements for the
-      management of YANG module lifecyles that cannot be addressed using
-      the semver.org 2.0.0 versioning scheme alone.</t>
-      
-      <t>Unlike the semver.org 2.0.0 versioning scheme, the YANG
-      semantic versioning scheme supports limited updates to older
-      versions of YANG modules, to allow for bug fixes and enhancements
-      to module versions that are not the latest.</t>
-
-      <t>Module definitions that follow the semver.org 2.0.0 versioning
-      scheme are fully compatible with implementations that understand
-      the YANG semantic versioning scheme.</t>
-
-      <t>If module updates are always restricted to the latest version
-      of the module only, then the version numbers used by the YANG
-      semantic versioning scheme are exactly the same as those defined
-      by the semver.org 2.0.0 versioning scheme.</t>
-    </list>
-    </t>
-    <t>Every YANG module versioned using the YANG semantic versioning
-    scheme specifies the module's semantic version number by including
-    the 'semver:module-version' statement according to the following
-    rules:
-    <list>
-    <t>The module MUST include at least one revision statement.</t>
-    <t>The most recent module revision statement MUST include a
-    'semver:module-version' sub-statement, that defines the module's
-    YANG semantic version.</t>
-    <t>The preceding module revision statement SHOULD also include a
-    'semver:module-version' sub-statement, to allow the module's
-    semantic version history to be derived.</t>
-    <t>All other revision statements MAY include a
-    'semver:module-version' sub-statement if they have an associated
-    YANG semantic version.</t>
-    </list>
-    </t>
-
-    <t>
-     "The YANG semver version number is expressed as a string of the
-     form: 'X.Y.Zv'; where X, Y, and Z each represent non-negative
-     integers smaller than 32768, and v represents an optional single
-     character suffix: 'm' or 'M'.
-     
-     <list style="symbols">
-       <t>'X' is the MAJOR version.  Changes in the major version number
-       indicate changes that are non-backwards-compatible to versions
-       with a lower major version number.</t>
-
-       <t>'Y' is the MINOR version.  Changes in the minor version number
-       indicate changes that are backwards-compatible to versions with
-       the same major version number, but a lower minor version number
-       and no patch 'm' or 'M' modifier.</t>
-
-       <t>'Zv' is the PATCH version and modifier.  Changes in the patch
-       version number can indicate editorial, backwards-compatible, or
-       non-backwards-compatible changes relative to versions with the
-       same major and minor version numbers, but lower patch version
-       number, depending on what form modifier 'v' takes:
-       <list style="symbols">
-	 <t>If the modifier letter is absent, the change represents an
-	 editorial change</t>
-	 <t>'m' - the change represents a backwards-compatible change</t>
-	 <t>'M' - the change represents a non-backwards-compatible change</t>
-       </list>
-       </t>
-     </list>
-    </t>
-    <t>The YANG module name and YANG semantic version number uniquely
-    identifies a revision of a module, with an associated revision date.
-    There MUST NOT be multiple instances of a YANG module definition
-    with the same module name and YANG semantic version number but
-    different content or revision date.</t>
-    <t>There MUST NOT be multiple versions of a YANG module that have
-    the same MAJOR, MINOR and PATCH version numbers, but different patch
-    modifier letter.  E.g., module version "1.2.3M" MUST NOT be defined
-    if module version "1.2.3" has already been defined.</t>
-    <section anchor="example_versions" title="Examples for YANG semantic version numbers">
-      <t>The following diagram and explanation illustrates how YANG semantic version numbers work.</t>
-      <figure>
-        <preamble>Example YANG semantic version numbers for an example module:</preamble>
-      <artwork>
-        0.1.0
-          |
-        0.2.0
-          |  
-        1.0.0
-          |  \
-          |   1.1.0 -> 1.1.1m -> 1.1.2M
-          |    |
-          |   1.2.0 -> 1.2.1M -> 1.2.2M
-          |    |
-          |   1.3.0 -> 1.3.1
-          |
-        2.0.0
-          |
-        3.0.0
-             \
-              3.1.0
-      </artwork>
-    </figure>
-    <t>The tree diagram above illustrates how an example modules version
-    history might evolve.  For example, the tree might represent the
-    following changes, listed in chronological order from oldest
-    revision to newest:
-    <list>
-      <t>0.1.0  - first beta module version</t>
-      <t>0.2.0  - second beta module version (with NBC changes)</t>
-      <t>1.0.0  - first release (may have NBC changes from 0.2.0)</t>
-      <t>1.1.0  - added new functionality, leaf "foo" (BC)</t>
-      <t>1.2.0  - added new functionality, leaf "baz" (BC)</t>
-      <t>1.3.0  - improve existing functionality, added leaf "foo-64" (BC)</t>
-      <t>1.3.1  - improve description wording for "foo-64" (Editorial)</t>
-      <t>1.1.1m - backport "foo-64" leaf to 1.1.x to avoid implementing "baz" from 1.2.0 (BC)</t>
-      <t>2.0.0  - change existing model for performance reasons, e.g. re-key list (NBC)</t>
-      <t>1.1.2M - NBC point bug fix, not required in 2.0.0 due to model changes (NBC)</t>
-      <t>3.0.0  - NBC bugfix, rename "baz" to "bar"; also add new BC leaf "wibble"; (NBC)</t>
-      <t>1.2.1M - backport NBC fix, changing "baz" to "bar"</t>
-      <t>1.2.2M - backport "wibble".  This is a BC change but "M" modifier is sticky.</t>
-      <t>3.1.0  - introduce new leaf "wobble" (BC)</t>
-    </list>
-    </t>
-    <t>The partial ordering relationships based on the semantic versioning numbers can be defined as follows:
-    <list>
-      <t>1.0.0 &lt; 1.1.0 &lt; 1.2.0 &lt; 1.3.0 &lt; 2.0.0 &lt; 3.0.0 &lt; 3.1.0</t>
-      <t>1.0.0 &lt; 1.1.0 &lt; 1.1.1m &lt; 1.1.2M</t>
-      <t>1.0.0 &lt; 1.1.0 &lt; 1.2.0 &lt; 1.2.1M &lt; 1.2.2M</t>
-    </list>
-    </t>
-    <t>There is no ordering relationship between 1.1.1M and either 1.2.0 or
-    1.2.1M, except that they share the common ancestor of 1.1.0.</t>
-    <t>Looking at the version number alone, the module definition in
-    2.0.0 does not necessarily contain the contents of 1.3.0.  However,
-    the module revision history in 2.0.0 would likely indicate that it
-    was edited from module version 1.3.0.</t>
-    </section>
-  </section>
-  
-  <section anchor="semver_update_rules" title="YANG Semantic Version Update Rules">
-    <t>When a new revision of a module is produced, then the following
-    rules define how the YANG semantic version number for the new module
-    revision is calculated, based on the changes between the two module
-    revisions, and the YANG semantic version number of the base module
-    revision that the changes are derived from.  A two step process is
-    used:</t>
-
-    <t>The first step is to classify the module change as 'editorial',
-    'backwards-compatible', or 'non-backwards-compatible version' using
-    the rules defined in <xref target="version_classification"/>.</t>
-
-    <t>The second step is to calculate the value of the 'semver:version'
-    field for the new module revision, based on the value of the
-    'semver:version' field in the base module, any how the module
-    changes have been classified.</t>
-
-    <t>The following rules define how the value for the 'semver:version'
-    argument in the new module revision is calculated:
-    <list style="numbers">
-      <t>If a module is being updated in a non-backwards-compatible
-      way, then the module version "X.Y.Z[m|M]" MUST be updated to
-      "X+1.0.0" unless that module version has already been defined with
-      different content, in which case the module version "X.Y.Z+1M MUST
-      be used instead.</t>
-
-      <t>If a module is being updated in a backwards-compatible way,
-      then the next version number depends on the format of the current
-      version number:
-      <list style="format %i">
-	<t>"X.Y.Z" - the module version MUST be updated to "X.Y+1.0",
-	unless that module version has already been defined with
-	different content, when the module version MUST be updated to
-	"X.Y.Z+1m instead".</t>
-	<t>"X.Y.Zm" - the module version MUST be updated to
-	"X.Y.Z+1m".</t>
-	<t>"X.Y.ZM" - the module version MUST be updated to
-	"X.Y.Z+1M".</t>
-      </list>
-      </t>
-
-      <t>If a module is being updated in an editorial way, then the next
-      version number depends on the format of the current version
-      number:
-      <list style="format %i">
-	<t>"X.Y.Z" - the module version MUST be updated to "X.Y.Z+1"</t>
-	<t>"X.Y.Zm" - the module version MUST be updated to
-	"X.Y.Z+1m".</t>
-	<t>"X.Y.ZM" - the module version MUST be updated to
-	"X.Y.Z+1M".</t>
-      </list>
-      </t>
-
-      <t>YANG module semantic version numbers beginning with 0, i.e
-      "0.X.Y" are regarded as beta definitions and need not follow the
-      rules above.  Either the MINOR or PATCH version numbers may be
-      updated, regardless of whether the changes are
-      non-backwards-compatible, backwards-compatible, or editorial.</t>
-    </list>
-    </t>
-  </section>
-  <section anchor="semver_extension" title="YANG Module Semver Extension">
-    <t>This document defines a YANG extension to add the YANG module
-    semantic version to a Module.  The complete definition of this YANG
-    module is in <xref target="yang_modules"/>.
-    </t>
-
-    <figure>
-      <artwork>
-        extension module-version {
-          argument semver;
-        }
-      </artwork>
-    </figure>
-    <t>The extension would typically be used this way:
-    </t>
-    <figure>
-      <artwork>
-    module yang-module-name {
-
-      namespace "name-space";
-      prefix "prefix-name";
-
-      import ietf-semver { prefix "semver"; }
-      
-      description
-        "to be completed";
-
-      revision 2018-02-28 {
-        description "Added leaf 'wobble'";
-        semver:module-version "3.1.0";
-      }
-
-      revision 2017-12-31 {
-        description "Rename 'baz' to 'bar', added leaf 'wibble'";
-        semver:module-version "3.0.0";
-      }
-	
-      revision 2017-10-30 {
-        description "Change the module structure";
-        semver:module-version "2.0.0";
-      }
-
-      revision 2017-08-30 {
-        description "Clarified description of 'foo-64' leaf";
-        semver:module-version "1.3.1";
-      }
-
-      revision 2017-07-30 {
-        description "Added leaf foo-64";
-        semver:module-version "1.3.0";
-      }
-
-      revision 2017-04-20 {
-        description "Add new functionality, leaf 'baz'";
-        semver:module-version "1.2.0";
-      }
-
-      revision 2017-04-03 {
-        description "Add new functionality, leaf 'foo'";
-        semver:module-version "1.1.0";
-      }
-
-      revision 2017-04-03 {
-        description "First release version.";
-        semver:module-version "1.0.0";
-      }
-
-      revision 2017-01-30 {
-        description "NBC changes to initial revision";
-        semver:module-version "0.2.0";
-      }
-
-      revision 2017-01-26 {
-        description "Initial module version";
-        semver:module-version "0.1.0";
-      }
-
-      //YANG module definition starts here
-      </artwork>
-    </figure>
-   <t>See also "Semantic Versioning and Structure for IETF
-   Specifications" <xref target="I-D.claise-semver"/> for a mechanism to
-   combine the semantic versioning, the GitHub tools, and a potential
-   change to the IETF process.
-    </t>
-  </section>
-</section>
-
-<section title="Stuff to merge in">
-       <t>TODO - Move.  Implementations that implement the YANG semantic versioning scheme defined in this document MUST set the
-     'deprecated-nodes-implemented' leaf because the refined module update rules in XXX
-     require that this is how servers handle 'deprecated' and 'obsolete' nodes to comply with YANG module semantic
-     versioning.</t>
-     <t>TODO - Move.  If a server does not set the 'deprecated-nodes-implemented' leaf, then clients MUST NOT rely
-     solely on the YANG module semantic version number to determine whether two module versions are backwards
-     compatible, and MUST also consider whether the status of any nodes has changed to 'deprecated' and whether those
-     nodes are implemented by the server.</t>
-
-</section>
-
-<section anchor="guidelines" title="Guidelines">
-   <section anchor="guidelines_authors" title="Guidelines to YANG model authors">
-      <t>NBC changes to YANG models may cause problems to clients, who are consumers of YANG models, and SHOULD be 
-         avoided.  However, there are cases where NBC changes are required, e.g. to fix an incorrect YANG model.</t>
-      <t>YANG model authors are recommended to minimize NBC changes and keep changes BC whenever possible.</t>
-      <t>The use of status "deprecated" with the status-description statement allows clients to plan a migration to alternative 
-         data nodes.</t>
-      <t>When NBC changes are introduced, consideration should be given to the impact on clients and YANG model authors SHOULD 
-         try to mitigate that impact.</t>
-      <section anchor="authors_semver" title="Use of YANG semantic versioning">
-	<t>Module authors should use the following guidance when applying the module version update rules specified in XXX.</t>
-	<t>Updates to modules SHOULD be applied to the latest version of
-	YANG modules, avoiding the use the 'm|M' patch modifier.  When
-	used in this way, the YANG semantic version numbers are
-	compatible with the versioning scheme defined by the semver.org
-	2.0.0 rules.</t>
-	<t>Changes to older versions of published YANG modules SHOULD be
-	minimized, since there may be a greater impact on clients, and
-	comparing between version numbers becomes more limited if the
-	'm|M' modifiers are used.  However, if it is necessary to make such
-	changes then the following guidelines apply:
-	<list>
-	  <t>Any changes SHOULD also be made to a new latest version of the YANG module, if appropriate.</t>
-	  <t>Where possible, changes SHOULD be restricted to backwards-compatible changes only.</t>
-	  <t>NBC changes MAY be made, subject to the constraints defined in XXX. The impact to clients SHOULD be carefully considered and minimized if possible.</t>
-	</list>    
-	</t>
-	<t>The version numbers associated with a module MUST never be reused.  E.g., when updating module version 3.4.0 in a NBC manner the module author must verify whether version 4.0.0 is available for use and if that version was already used, the updated module must use version 3.4.1M instead.</t> 
-	<t>Patch modifier letters (i.e. 'm' or 'M') are sticky.  For example if version 3.4.1M is modified in a BC way, the next
-         version is 3.4.2M. This is to indicate that 3.4.2M is not BC with 3.4.0, however it comes at the cost of not being able to indicate the 
-         type of  change between 3.4.1M and 3.4.2M.</t>
-      <t>As explained in <xref target="implementation_experience"/>, while programatically determining a semantic version is possible
-         using tools (e.g. the pyang utility), human oversight is highly recommended because of some special cases which can not be detected by tools.
-         Therefore, a model author SHOULD use both means to determine a model's semantic version.</t>
-       </section>
-   </section>
-   <section anchor="guidelines_clients" title="Guidelines to YANG model clients">
-     <t>Guidelines for clients of modules using YANG semantic versioning:
-     </t>
-   </section>
-</section>
-
-<section anchor="yang_modules" title="Semantic Version Types YANG Module">
-  <t>
-    <figure>
-      <preamble>YANG module that provides a formal type definition of
-      the YANG semantic version number.</preamble>
-      <artwork><![CDATA[
-<CODE BEGINS> file "ietf-semver-types@2019-05-03.yang"
-module ietf-semver-types {
-  yang-version 1.1;
-  namespace "urn:ietf:params:xml:ns:yang:ietf-semver-types";
-  prefix semver;
-
-  organization
-    "IETF NETMOD (Network Modeling) Working Group";
-  contact
-    "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
-     WG List:  <mailto:netmod@ietf.org>
-
-     Author:   Benoit Claise
-               <mailto:bclaise@cisco.com>
-
-     Author:   Joe Clarke
-               <mailto:jclarke@cisco.com>
-
-     Author:   Reshad Rahman
-               <mailto:rrahman@cisco.com>
-
-     Author:   Robert Wilton
-               <mailto:rwilton@cisco.com>
-
-     Author:   Kevin D'Souza
-               <mailto:kd6913@att.com>
-
-     Author:   Balazs Lengyel
-               <mailto:balazs.lengyel@ericsson.com>
-
-     Author:   Jason Sterne
-               <mailto:jason.sterne@nokia.com>";
-  description
-    "This module contains a definition for a YANG 1.1 extension to
-     express the semantic version of YANG modules.";
-
-  revision 2019-05-03 {
-    description
-      "Initial revision, derived from ietf-semver.yang@2019-02-27";
-    reference
-      "draft-verdt-netmod-yang-semver: 
-       YANG Semantic Versioning for Modules";
-    rev:label "0.1.0";
-  }
-
-  typedef version {
-    type string {
-      pattern '[0-9]{1,5}\.[0-9]{1,5}\.[0-9]{1,5}(m|M)?';
-    }
-    description
-      "The type used to represent a YANG semantic version number.
-
-      The YANG semver version number is expressed as a string of the
-      form: 'X.Y.Zv'; where X, Y, and Z each represent non-negative
-      integers smaller than 32768, and v represents an optional
-      single character suffix: 'm' or 'M'.
-
-      o 'X' is the MAJOR version.  Changes in the major version
-        number indicate changes that are non-backwards-compatible to
-        versions with a lower major version number.
-
-      o 'Y' is the MINOR version.  Changes in the minor version
-         number indicate changes that are backwards-compatible to
-         versions with the same major version number, but a lower
-         minor version number.
-
-     o 'Zv' is the PATCH version and modifier.  Changes in the patch
-        version number can indicate editorial, backwards-compatible,
-        or non-backwards-compatible changes relative to versions with
-        the same major and minor version numbers, but lower patch
-        version number, depending on what form modifier 'v' takes:
-
-        *  'M' - the change represents a non-backwards-compatible
-                 change
-
-        *  'm' - the change represents a backwards-compatible change
-
-        * If the modifier letter is absent, the change represents an
-          editorial change";
-
-    reference
-      "draft-verdt-netmod-yang-semver: YANG Semantic Versioning";
-  }
-}
-<CODE ENDS>
-]]></artwork>
-</figure>
-</t>
-</section>
-
-<section anchor="contributor" title="Contributors">
-  <t>This document grew out of the YANG module versioning design team
-  that started after IETF 101. The design team consists of the following
-  members whom have worked on the YANG versioning project:</t>
-      <t>
-        <list style="symbols">
-          <t>Balazs Lengyel</t>
-          <t>Benoit Claise</t>
-          <t>Ebben Aries</t>
-          <t>Jason Sterne</t>
-          <t>Joe Clarke</t>
-          <t>Juergen Schoenwaelder</t>
-          <t>Mahesh Jethanandani</t>
-          <t>Michael (Wangzitao)</t>
-          <t>Qin Wu</t>
-          <t>Reshad Rahman</t>
-          <t>Rob Wilton</t>
-        </list>
-      </t>
-   
-   <t>The initial revision of this document was refactored and built
-   upon <xref target="I-D.clacla-netmod-yang-model-update"/>.</t>
-   <t>Discussons on the use of Semver for YANG versioning has been held
-   with authors of the OpenConfig YANG models.  We would like thank both
-   Anees Shaikh and Rob Shakir for their input into this problem
-   space.</t>
-</section>
-
-<section anchor="security" title="Security Considerations">
-  <t>The document does not define any new protocol or data model.  There
-  are no security impacts.</t>
-</section>
-<section anchor="iana" title="IANA Considerations">
-  <t>At the moment none are proposed.  Possibly something needs to be
-  addded if there needs to be a registry of supported YANG versioning
-  schemes.</t>
-</section>
-</middle>
-<?rfc needLines="20"?>
-<back>
-<references title="Normative References">
-   <?rfc include='reference.RFC.7950'?>
-   <?rfc include='reference.RFC.7895'?>
-   <?rfc include='reference.RFC.8407'?>
-   <?rfc include='reference.RFC.8525'?>
-   <?ref include='reference.I-D.verdt-netmod-yang-versioning-reqs'?>
-</references>
-<references title="Informative References">
-   <?rfc include='reference.I-D.openconfig-netmod-model-catalog'?>
-   <?rfc include='reference.I-D.claise-semver'?>
-   <?rfc include='reference.I-D.clacla-netmod-yang-model-update'?>
-   <?rfc include='reference.I-D.clacla-netmod-model-catalog'?>
-   <?rfc include='reference.I-D.ietf-netmod-yang-instance-file-format'?>
-   <?rfc include='reference.I-D.rwilton-netmod-yang-packages'?>
-   <reference anchor="openconfigsemver" target="http://www.openconfig.net/docs/semver/">
-     <front>
-      <title>Semantic Versioning for Openconfig Models</title>
-      <author/>
-      <date/>
-    </front>
-   </reference>
-      <reference anchor="semver" target="https://www.semver.org">
-      <front>
-       <title>Semantic Versioning 2.0.0</title>
-       <author/>
-       <date/>
-    </front>
-   </reference>
-   <reference anchor="yangcatalog" target="https://yangcatalog.org">
-     <front>
-       <title>YANG Catalog</title>
-       <author/>
-       <date/>
-     </front>
-   </reference>
-</references>
-<?rfc needLines="100"?>
-
-<section anchor="appendix" title="Appendix">
-  <section anchor="open_issues" title="Open Issues">
-    <t>Open issues are being tracked at <eref target="https://github.com/netmod-wg/yang-ver-dt/issues"/>.  Currently open issues are:
-      
-      <list style="symbols">
-	<t>Add a naming convention for versioned YANG file<eref
-	target="https://github.com/netmod-wg/yang-ver-dt/issues/13">#13</eref></t>
-
-	<t>Define editorial, bc, nbc impact of adding, changing, removing extension stmts<eref
-	target="https://github.com/netmod-wg/yang-ver-dt/issues/12">#12</eref></t>
-
-	<t>The solution does not strictly support semver 2.0.0<eref
-	target="https://github.com/netmod-wg/yang-ver-dt/issues/9">#9</eref></t>
-
-	<t>Are whitespace changes allow between two module instances with the same version (or revision)?<eref
-	target="https://github.com/netmod-wg/yang-ver-dt/issues/8">#8</eref></t>
-
-	<t>Do we assume that a module has an implicit semver if none as been specified?<eref
-	target="https://github.com/netmod-wg/yang-ver-dt/issues/7">#7</eref></t>
-
-	<t>Status obsolete nodes<eref target="https://github.com/netmod-wg/yang-ver-dt/issues/2">#2</eref></t>
-      </list>
-    </t>
-  </section>
-  <section anchor="derived_semver" title="Derived Semantic Version">
-    <t>This temporary text is intended to be moved to a separate draft
-    the describes the tool based approach for versioning YANG modules
-    mentioned in XXX [Solutions overview.].</t>
-    <section anchor="the_derived_semantic_versioning" title="The Derived Semantic Version">
-      <t>
-	If an explicitly defined semantic version is not available in
-	the YANG module, it is possible to algoritmically calculate a
-	derived semantic version. This can be used for modules not
-	containing a definitive semantic-version as defined in this
-	document or as a starting value when specifying the definitive
-	semantic-version. Be aware that this algorithm may sometimes
-	incorrectly classify changes between the categories
-	non-compatible, compatible or error-correction.
-	</t>
-    </section>
-    <section anchor="implementation_experience" title="Implementation Experience">
-      <t>
-	<xref target="yangcatalog"/> uses the pyang utility to calculate
-	the derived-semantic-version for all of the modules contained
-	within the catalog.  <xref target="yangcatalog"/> contains many
-	revisions of the same module in order to provide its
-	derived-semantic-version for module consumers to know what has
-	changed between revisions of the same module.
-      </t>
-      <t>
-	Two distinct leafs in the YANG module <xref target="I-D.clacla-netmod-model-catalog"/> contain this semver notation:
-      </t>
-      <t>
-	<list style="symbols">
-	  <t>the semantic-version leaf contains the value embedded
-	  within a YANG module (if it is available).
-	  </t>
-	  <t>the derived-semantic-version leaf is established by
-	  examining the the YANG module themselves.  As such
-	  derived-semantic-version only takes syntax into account as
-	  opposed to the meaning of various elements when it computes
-	  the semantic version.</t>
-
-	  <t>The algorithm used to produce the derived-semantic-version is as follows:
-            <list style="numbers">
-              <t>Order all modules of the same name by revision from
-              oldest to newest.  Include module revisions that are not
-              available, but which are defined in the revision
-              statements in one of the available module versions. </t>
-              <t>If module A, revision N+1 has failed compilation, bump
-              its derived semantic MAJOR version.  For unavailable
-              module versions assume non-backward compatible changes
-              were done., thus bump its derived semantic MAJOR
-              version.</t>
-              <t>Else, run "pyang --check-update-from" on module A,
-              revision N and revision N+1 to see if
-              backward-incompatible changes exist.</t>
-              <t>If backward-incompatible changes exist, bump module A,
-              revision N+1's derived MAJOR semantic version.</t>
-              <t>If no backward-incompatible changes exist, compare the
-              pyang trees of module A, revision N and revision N+1.</t>
-              <t>If there are structural differences (e.g., new nodes),
-              bump module A, revision N+1's derived MINOR semantic
-              version.</t>
-              <t>If no structural differences exist, bump module A,
-              revision N+1's derived PATCH semantic version.</t>
-            </list>
-          </t>
-	</list>
-      </t>
-      <t>
-	The pyang utility checks many of the points listed in section 11
-	of <xref target="RFC7950"/> for known module incompatibilities.
-	While this approach is a good way to programmatically obtain a
-	semantic version number, it does not address all cases whereby a
-	major version number might need to be increased.  For example, a
-	node may have the same name and same type, but its meaning may
-	change from one revision of a module to another.  This
-	represents a semantic change that breaks backward compatibility,
-	but the above algorithm would not find it.  Therefore,
-	additional, sometimes manual, rigor must be done to ensure a
-	proper version is chosen for a given module revision.
-      </t>
-    </section>
-  </section>
-</section>
-</back>
-</rfc>
-<!-- Local Variables: -->
-<!-- fill-column:72 -->
-<!-- End: -->