<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wang-netmod-module-revision-management-01"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Module Revision Management">A YANG Data Model for module
    revision management</title>

    <author fullname="Michael Wang" initials="M." surname="Wang">
      <organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <street/>

          <city>Nanjing</city>

          <region/>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>wangzitao@huawei.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>
	
    <author fullname="Aijun Wang" initials="A." surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>wangaj.bri@chinatelecom.cn</email>
      </address>
    </author>
	
    <date year="2018"/>

    <area>OPS Area</area>

    <workgroup>NETMOD Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document defines a YANG Data Model for module revision change
      management. It is intended this model be used by vendors who support
      multiple revisions of the same YANG module in their systems but
      implement only one revision of a module. In addition, this document
      introduces a new generic mechanism based on RPC, denoted as module-
      revision-change, that allow datanode backwards compatibility detection
      and provide a report on change type and change details of a YANG module
      with two or multiple revisions that is defined in design time.,
      e.g.,identifies a place in the node hierarchy where data node gets
      changed or new data gets inserted and indicate whether the change to the
      data node is backward compatible. </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The revised Network Management Datastore Architecture (NMDA) defines
      a set of new datastores that each hold YANG-defined data <xref
      target="RFC7950"/> and represent a different "viewpoint" on the data
      that is maintained by a server. To support the NMDA, many modules may
      need to be updated or restructured especially for some published
      non-NMDA modules, the model should be republished with an
      NMDA-compatible structure, deprecating non-NMDA constructs <xref
      target="I-D.ietf-netmod-rfc6087bis"/>. Therefore, how to support
      hackward-compatible and indicate the module's changes is an issue.</t>

      <t>As described in <xref target="RFC7950"/> , a module name MUST NOT be
      changed when definitions contained in a module are available to be
      imported by any other module and are referenced in "import" statements
      via the module name. In some case, when we make non-backward compatible
      updates, the module name might be forced to change, according to<xref
      target="RFC7950"/> module update rule.</t>

      <t>In order to provide an easy way to indicate how backward-compatible a
      given YANG module actually is, this document defines a YANG Data Model
      for module revision change management. It is intended this model be used
      by vendors who support multiple revisions of the same YANG module in
      their systems but implement only one revision of a module. In addition,
      this document introduces a new generic mechanism based on RPC, denoted
      as module-revision-change, that allow Datanode backwards compatibility
      detection and provide a report on change type and change details of a
      YANG module with two or multiple revisions that is defined in design
      time., e.g.,identifies a place in the node hierarchy where data node
      gets changed or new data gets inserted and indicate whether the change
      to the data node is backward compatible. </t>

      <t>In addition, in order to identify whether changes between two
      revisions represent bug fixes, new functionality, or both, etc <xref
      target="I-D.verdt-netmod-yang-versioning-reqs"/>, this document also
      defines a new YANG extension statement which can help the user to
      understand the purpose of changing a specific node. See More details in
      section 4.</t>
    </section>

    <section title="Terminologies">
      <t>The keywords "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].</t>

      <t>The following terms are defined in [RFC6241] and are not redefined
      here: <list style="symbols">
          <t>client</t>

          <t>notification</t>

          <t>server</t>
        </list></t>

      <t>The following terms are defined in [RFC7950] and are not redefined
      here: <list>
          <t>action</t>

          <t>container</t>

          <t>list</t>

          <t>operation</t>
        </list></t>
    </section>

    <section title="Design of YANG data model for module revision management">
      <t>The "ietf-module-revision-management" module provides per revision
      the module change type and change details used by a server. This module
      is defined using YANG version 1.1, but it supports the description of
      YANG modules written in any revision of YANG.</t>

      <t>All data nodes in "ietf-module-revision-management" are "config
      false", and thus accessible in the operational state datastore.</t>

      <t>Following is the YANG Tree Diagram for the
      "ietf-module-revision-management" module:<figure>
          <artwork>
module: ietf-module-revision
    +--ro yang-modules
       +--ro module* [name revision]
          +--ro name                   yang:yang-identifier
          +--ro revision               yanglib:revision-identifier
          +--ro backward-compatible?   boolean
          +--ro revision-change-log* [index]
             +--ro index               uint32
             +--ro change-operation    identityref
             +--ro (yang-statements)?
                +--:(data-definition-statement)
                |  +--ro data-definition
                |     +--ro target-node        yang:xpath1.0
                |     +--ro location-point?    yang:xpath1.0
                |     +--ro where?             enumeration
                |     +--ro data-definition?   
                +--:(other-statement)
                   +--ro other-statement
                      +--ro statement-name?         identityref
                      +--ro statement-definition?   
                      +--ro substatements* [statement-name]
                         +--ro statement-name             identityref
                         +--ro substatement-definition?   
  augment /yanglib:yang-library/yanglib:module-set/yanglib:module:
    +--ro backward-compatible?   boolean
  augment /yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:submodule:
    +--ro backward-compatible?   boolean

  rpcs:
    +---x module-revision-change
       +---w input
       |  +---w source module-name yang:yang-identifier
       |  +---w source-revision?   yanglib:revision-identifier
       |  +---w target module-name yang:yang-identifier
       |  +---w target-revision?   yanglib:revision-identifier
       +--ro output
          +--ro (status-response)?
          |  +--:(wrong-match)
          |  |  +--ro wrong-match?    empty
          |  +--ro data-nodes* [data-node-name]
          |     +--ro data-node-name      string
          |     +--ro is-new-node?        boolean
          |     +--ro change-operation?   identityref</artwork>
        </figure></t>

      <section title="yang-modules">
        <t>This container holds all per revision the module discrepancy
        information used by a server.</t>

        <section title="yang-modules/module">
          <t>This mandatory list contains one entry for each revision of each
          YANG module that is used by the server. It is possible for multiple
          revisions of the same module to be imported, in addition to an entry
          for the revision that is implemented by the server. Multiple
          revisions of the same module are either backward-compatible or non
          backward-compatible.</t>
        </section>

        <section title="yang-modules/change-log">
          <t>This list contains one entry for each schema node change from
          previous revision known by the server, and identifies schema node
          change path,location, operation and associated with corresponding
          schema node in the "change-log" list. Each revision of the YANG
          module has multiple entries.</t>

          <t>A change log is an ordered collection of changes that are applied
          to one revision of YANG module. Each change is identified by an
          "index", and it has an change operation ("create", "delete","move",
          "modify") that is applied to the target resource. Each change can be
          applied to a sub-resource "target" within the target resource. If
          the operation is "move", then the "where" parameter indicates how
          the node is moved. For values "before" and "after", the "point"
          parameter specifies the data node insertion point.</t>

          <t>Each entry within a change log MUST identify exactly one data
          definition change or other statement change.</t>
        </section>
      </section>

      <section title="RPC definition for module revision change">
        <t>The "module-revision-change" rpc statement is defined to retrieve
        the schema data node changes between any two revisions of the same
        module, i.e. the data node that get updated or newly added during
        module revision change. This rpc statement takes module identification
        information as input, and provides the list of data nodes that make
        changes or are newly added in the later revision.</t>

        <section title="Usage Example">
          <t>For example, there are two revisions of the same module, the yang
          codes are shown as below:</t>

          <figure>
            <artwork>
     module example-a{
       yang-version 1.1;
       namespace "urn:example:a";
       prefix "a";

       organization "foo.";
       contact "fo@example.com";
       description
         "foo.";

       revision 2017-12-01 {
         description "Initial revision.";
       }

       container system {
         leaf host-name {
           type string;
           description
             "Hostname for this system.";
         }
       }
      }

     module example-a{
       yang-version 1.1;
       namespace "urn:example:a";
       prefix "a";

       organization "foo.";
       contact "fo@example.com";
       description
         "foo.";

       revision 2017-12-20{
         description "Initial revision.";
       }

       container system {
         leaf host-name {
           type string;
           description
             "Hostname for this system.";
         }
         leaf b {
           type string;
           description
             "foo";
        }
       }    
</artwork>
          </figure>

          <t>If we initiate a "module-revision-change" RPC to retrieve the
          changes between two revisions of module "a", the NETCONF XML example
          are shown as below:</t>

          <figure>
            <artwork>
     &lt;rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
       &lt;module-revision-change xmlns="http://example.com/system"&gt;
         &lt;module-name&gt;example-a&lt;/module-namee&gt;
         &lt;source-revisions&gt;1.0.0&lt;/source-revisions&gt;
         &lt;target-revisions&gt;2.0.0&lt;/target-revisions&gt;   
       &lt;/module-revision-change&gt;
     &lt;/rpc&gt;

     &lt;rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
       &lt;data-nodes&gt;
        &lt;id&gt;0001&lt;/id&gt;
        &lt;data-node-name&gt;b&lt;/data-node-name&gt;
        &lt;is-new-node&gt;true&lt;/is-new-node&gt;
        &lt;data-node-change&gt;major-change&lt;/data-node-change&gt;
       &lt;/data-nodes&gt;  
     &lt;/rpc-reply&gt;

</artwork>
          </figure>
        </section>
      </section>
    </section>

    <section title="YANG Extension for Purpose Marking">
      <t>In order to identify whether changes between two revisions represent
      bug fixes, new functionality, or both, etc <xref
      target="I-D.verdt-netmod-yang-versioning-reqs"/>, purpose marking are
      defined via the YANG extension "mr:purpose". This YANG extension
      statement is defined in the module "ietf-module-revision" (Section 7).
      This YANG extension can help the user to understand the purpose of
      changing a specific node.</t>

      <section title="Usage Example: Add New Function">
        <t>For example, there is a YANG data model "example-a", the yang codes
        are shown as below:</t>

        <figure>
          <artwork>
        module example-a{
          yang-version 1.1;
          namespace "urn:example:a";
          prefix "a";

          organization "foo.";
          contact "fo@example.com";
          description
            "foo.";

          revision 2017-12-01 {
            description "Initial revision.";
          }

          container system {
            leaf host-name {
              type string;
              description
                "Hostname for this system.";
            }
          }
         }
   
</artwork>
        </figure>

        <t>When the author of "example-a" designs a new revision to add some
        new attributes, the "mr:purpose" marking can be used to mark the
        purpose of the updates. For example:</t>

        <figure>
          <artwork>

        module example-a{
          yang-version 1.1;
          namespace "urn:example:a";
          prefix "a";

          organization "foo.";
          contact "fo@example.com";
          description
            "foo.";

          revision 2017-12-20{
            description "Initial revision.";
          }

          container system {
            leaf host-name {
              type string;
              description
                "Hostname for this system.";
            }
            leaf b {
              type string;
              mr:purpose "new-function";
              description
                "foo";
              
           }
          }
</artwork>
        </figure>
      </section>

      <section title="Usage example: Bug Fix">
        <t>For example, there are some bugs in a published model "example-b",
        the yang codes are shown as below:</t>

        <figure>
          <artwork>

        module example-b{
          yang-version 1.1;
          namespace "urn:example:b";
          prefix "b";

          organization "foo.";
          contact "fo@example.com";
          description
            "foo.";

          revision 2017-12-01 {
            description "Initial revision.";
          }

          container system {
            leaf host-name {
              type uint32;
              description
                "Hostname for this system.";
            }
          }
         }

</artwork>
        </figure>

        <t>The following updates allow to fix bugs in a backward-compatible
        way:</t>

        <figure>
          <artwork>

        module example-b{
          yang-version 1.1;
          namespace "urn:example:b";
          prefix "b";

          organization "foo.";
          contact "fo@example.com";
          description
            "foo.";

          revision 2017-12-01 {
            description "Initial revision.";
          }

          container system {
            leaf host-name-update {
             type string;
             mr:purpose "bug-fix";
             description
             "Hostname for this system.";
            }
            leaf host-name {
              type uint32;
              status deprecated;
              description
                "Hostname for this system.";
            }
          }
         }


</artwork>
        </figure>
      </section>
    </section>

    <section title="Library Augmentation">
      <t>Backward compatibility for each revision of YANG module can also be
      read using the yang library <xref target="I-D.ietf-netconf-rfc7895bis"/>
      if a server supports both YANG library and the augmentation defined
      below. If a server supports indication of backward compatibility forone
      revision of and the YANG module, it SHOULD also support the
      "ietf-module-revision" module.</t>

      <t>The tree associated with the defined augmentation is:</t>

      <figure>
        <artwork>
module: ietf-module-revisions
  augment /yanglib:yang-library/yanglib:modules/yanglib:module:
+--ro backward-compatible?   bool

augment /yanglib:yanglibrary/yanglib:modules/yanglib:module
/yanglib:submodule:
    +--ro backward-compatible?   bool</artwork>
      </figure>
    </section>

    <section title="Multiple revisions module management">
      <t>As experience is gained with a module, it may be desirable to support
      multiple revisions of that module in their systems but implement one
      revision of a module at each time. To indicate the details changes of
      that module, e.g., identifies schema node change path,location,
      operation and associated with corresponding schema node, it will be
      desirable to use 'ietf-module-revision' defined in this document to
      manage all the revisions of that module and keep track of module change
      discrepancy in different revision, especially when the new revision is
      not backward compatible with previous revision.</t>
    </section>

    <section title="Yang Data Model Definition">
      <t>&lt;CODE BEGINS&gt; file "ietf-module-revision@2018-08-08.yang"</t>

      <figure>
        <artwork>module ietf-module-revision {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-module-revision";
  prefix ml;

  import ietf-yang-library {
    prefix yanglib;
  }
  import ietf-yang-types {
    prefix yang;
  }

  organization
    "IETF Network Modeling (NETMOD) Working Group";
  contact
    "WG Web:   &lt;https://datatracker.ietf.org/wg/netmod/&gt;
     
     WG List:  &lt;mailto:netmod@ietf.org&gt;
     
     Author:   Qin Wu
               &lt;mailto:bill.wu@huawei.com&gt;
               Zitao Wang
               &lt;mailto:wangzitao@huawei.com&gt;";
  description
    "This YANG module defines an module log.";

  revision 2018-08-08 {
    description
      "Initial revision.";
    reference "RFC XXXX: Using Metadata with YANG for Module revisions";
  }

  identity operation-type {
    description
      "Abstract base identity for the operation type ";
  }

  identity create {
    base operation-type;
    description
      "Denotes create new data nodes";
  }

  identity delete {
    base operation-type;
    description
      "Denotes delete the target node";
  }

  identity move {
    base operation-type;
    description
      "Denote move the target node.";
  }

  identity modify {
    base operation-type;
    description
      "Denote modify the target data node.";
  }

  identity statement-type {
    description
      "Base identity for statement type";
  }

  identity feature-statement {
    base statement-type;
    description
      "feature statement, if this type be chose, it means that the 
       feature or if-feature statement been modified";
  }

  identity identity-statement {
    base statement-type;
    description
      "identity statement, if this type be chose, it means that the 
       identity statement been modified, for example, add new identity, etc.";
  }

  identity grouping-statement {
    base statement-type;
    description
      "grouping statement, if this type be chose, it means that the grouping
       statement been modified.";
  }

  identity typedef-statement {
    base statement-type;
    description
      "typedef statement, if this type be chose, it means that the typedef
       statement been modified.";
  }

  identity augment-statement {
    base statement-type;
    description
      "augment statement, if this type be chose, it means that the augment
       statement been modified.";
  }

  identity rpc-statement {
    base statement-type;
    description
      "rpc statement, if this type be chose, it means that the rpc
       statement been modified.";
  }

  identity notification-statement {
    base statement-type;
    description
      "notification statement, if this type be chose, it means that the notification
       statement been modified.";
  }

  extension purpose {
   argument name;
    description
      "The purpose can be used to mark the data nodes change purpose.
       The name argument can be specified in the following recommended mode
     
       - bug-fix, which can help user to understand the data nodes' changes present bug fix,
       - new-function, which can help user to understand the data nodes' changes present new function,
       - nmda-conform, which can help user to understand the data nodes' changes conform to NMDA,
     
       and note that the user can argument the purpose name according to their sepcific requirements.";
  }  
  
  grouping data-definition {
    container data-definition {
      leaf target-node {
        type yang:xpath1.0;
        mandatory true;
        description
          "Identifies the target data node for update. 
           Notice that, if the update-type equal to move or delete, 
           this target-node must point to the data node of old version.
           \t 
           For example, suppose the target node is a YANG leaf named a, 
           and the previous version is:
           \t 
           container foo {
            leaf a { type string; }
            leaf b { type int32; }
           }
           \t  
           the new version is:
            container foo {
           leaf b {type int32;}
            }
           \t   
           Therefore, the targe-node should be /foo/a.";
      }
      leaf location-point {
        type yang:xpath1.0;
        description
          "Identifies the location point where the updates happened.";
      }
      leaf where {
        when "derived-from-or-self(../../change-operation, 'move')" {
          description
            "This leaf only applies for 'move'
             updates.";
        }
        type enumeration {
          enum "before" {
            description
              "Insert or move a data node before the data resource
               identified by the 'point' parameter.";
          }
          enum "after" {
            description
              "Insert or move a data node after the data resource
               identified by the 'point' parameter.";
          }
          enum "first" {
            description
              "Insert or move a data node so it becomes ordered
                  as the first entry.";
          }
          enum "last" {
            description
              "Insert or move a data node so it becomes ordered
               as the last entry.";
          }
        }
        default "last";
        description
          "Identifies where a data resource will be inserted
              or moved.";
      }
      anydata data-definition {
        when "derived-from-or-self(../../change-operation, 'modify')" {
          description
            "This nodes only be present when
                the 'change-operation' equal to 'modify'.";
        }
        description
          "This nodes used for present the definitions before updated. 
           And this nodes only be present when
           the 'change-operation' equal to 'modify'.";
      }
      description
        "Container for data statement";
    }
    description
      "Grouping for data definition";
  }

  grouping other-statement {
    container other-statement {
      leaf statement-name {
        type identityref {
          base statement-type;
        }
        description
          "Statement name, for example, identity, feature, typedef, etc.";
      }
      anydata statement-definition {
        description
          "This nodes used for present new the definitions.";
      }
      list substatements {
        key "statement-name";
        leaf statement-name {
          type identityref {
            base statement-type;
          }
          description
            "Statement name, for example, identity, feature, typedef, etc.";
        }
        anydata substatement-definition {
          description
            "This nodes used for present new the definitions.";
        }
        description
          "List for substatements updates";
      }
      description
        "Container for header statement updates";
    }
    description
      "Grouping for header statement";
  }

  grouping change-log {
    list revision-change-log {
      key "index";
      leaf index {
        type uint32;
        description
          "Index for module change log";
      }
      leaf change-operation {
        type identityref {
          base operation-type;
        }
        mandatory true;
        description
          "This leaf indicate the change operation, such as create, move, delete, modify, etc.";
      }
      choice yang-statements {
        description
          "Choice for various YANG statements that have been impacted.";
        case data-definition-statement {
          uses data-definition;
        }
        case other-statement {
          uses other-statement;
        }
      }
      description
        "List for module revision change log";
    }
    description
      "Grouping for module revision change log";
  }

  container yang-modules {
    config false;
    list module {
      key "name revision";
      leaf name {
        type yang:yang-identifier;
        description
          "The YANG module or submodule name.";
      }
      leaf revision {
        type yanglib:revision-identifier;
        description
          "The YANG module or submodule revision date.  If no revision
           statement is present in the YANG module or submodule, this
           leaf is not instantiated.";
      }
      leaf backward-compatible {
        type boolean;
        description
          "Indicates whether it is a backward compatible version.
           If this parameter is set to true, it means that this version is
           a backwards compatible version";
      }
      uses change-log;
      description
        "List for module updated log";
    }
    description
      "This container present the modules updated log.";
  }
  augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
    description
      "Augment the yang library with backward compatibility indication.";
    leaf backward-compatible {
      type boolean;
      description
        "backward compatibility indication.";
    }
  }
  augment "/yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:submodule" {
    description
      "Augment the yang library with backward compatibility indication.";
    leaf backward-compatible {
      type boolean;
      description
        "backward compatibility indication.";
    }
  }
  rpc module-revision-change {
    description
      "Module Node change query operation.";
    input {
      leaf source-module-name {
        type yang:yang-identifier;
        mandatory true;
        description
          "The Source YANG module or submodule name.";
      }
      leaf source-revision {
        type yanglib:revision-identifier;
        description
          "The Source YANG module revision date.  If no revision
           statement is present in the YANG module or submodule, this
           leaf is not instantiated.";
      }
     leaf target-module-name {
        type yang:yang-identifier;
        mandatory true;
        description
          "The Target YANG module or submodule name.";
      }
      leaf target-revision {
        type yanglib:revision-identifier;
        description
          "The target YANG module revision date.  If no revision
           statement is present in the YANG module or submodule, this
           leaf is not instantiated.";
      }
    }
    output {
      choice status-response{
      leaf wrong-match{
          type empty;
          description
            "This leaf indicates that two modules have nothing in common.";
      }
      list data-nodes {
        key "data-node-name";
        description
          "Each entry represents a data node of a given module that
           have been changed from source revision of
           a module to target revision of the module.";
        leaf data-node-name {
          type string;
          description
            "a data node name of a given module that
             has been changed.";
        }
        leaf is-new-node {
          type boolean;
          description
            "indicate the data node is newly introduced node in the target revision.";
        }
        leaf change-operation {
          type identityref {
            base operation-type;
          }
          description
          "This leaf indicate the change operation, 
           such as create, move, delete, modify, etc.";
        }
      }
     }
    }
  }
} </artwork>
      </figure>

      <t>&lt;CODE ENDS&gt;</t>
    </section>

    <section title="Security Considerations">
      <t>This document defines a mechanism that is put at a place in the node
      hierarchy where data node gets changed or new data gets inserted and
      indicate whether the change to the data node is backward compatible and
      as such doesn't introduce new security issues.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document registers a URI in the IETF XML registry <xref
      target="RFC3688"/>. Following the format in <xref target="RFC3688"/>,
      the following registration is requested to be made:</t>

      <figure>
        <artwork>---------------------------------------------------------------------
   URI: urn:ietf:params:xml:ns:yang:ietf-module-revision

   Registrant Contact: The NETMOD WG of the IETF.

   XML: N/A, the requested URI is an XML namespace.
---------------------------------------------------------------------</artwork>
      </figure>

      <t>This document registers a YANG module in the YANG Module Names
      registry <xref target="RFC6020"/>.</t>

      <figure>
        <artwork>---------------------------------------------------------------------
   Name:         ietf-module-revision
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-module-revision
   Prefix:       md
   Reference:    RFC xxxx
---------------------------------------------------------------------</artwork>
      </figure>
    </section>

    <section title="Acknowledgements">
      <t>This work is motivated from the discussions of module version in IETF
      100 Singapore meeting. Thanks to Juergen Schoenwaelder and Adrian Farrel
      for useful comments on this work.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>+1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997"/>

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
                "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
                "OPTIONAL" in this document are to be interpreted as described
                in RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <?rfc include="reference.RFC.7950.xml"?>

      <?rfc include="reference.RFC.7952.xml"?>

      <?rfc include="reference.RFC.3688.xml"?>

      <?rfc include="reference.RFC.6020.xml"?>

      <?rfc include="reference.RFC.7223.xml"?>

      <?rfc include="reference.I-D.draft-ietf-netmod-rfc6087bis-15"?>

      <?rfc include="reference.I-D.draft-ietf-netconf-rfc7895bis-04"?>

      <?rfc include="reference.I-D.draft-verdt-netmod-yang-versioning-reqs-00"?>
    </references>

    <section title="Example of Module Revision Management">
      <t>This section provides an example to generate XML snippet of ietf-
      module-revision based on the changes between the new revision of
      interface model as specified in [draft-ietf-netmod-rfc7223bis] and the
      old revision of interface model as specified in [RFC7223].</t>

      <figure>
        <artwork>
   &lt;yang-modules&gt;
    &lt;module&gt;
     &lt;name&gt;ietf-interfaces&lt;/name&gt;
     &lt;revision&gt;2018-01-09&lt;/revision&gt;
     &lt;backwards-compatible&gt;false&lt;/backwards-compatible&gt;
     &lt;revision-change-log&gt;
      &lt;index&gt;0001&lt;/index&gt;
      &lt;change-operation&gt;delete&lt;/change-operation&gt;
      &lt;yang-statements&gt;
       &lt;data-definition-statement&gt;
        &lt;data-definition&gt;  
         &lt;target&gt;/if:interfaces-state&lt;/target&gt;
        &lt;/data-definition&gt;
       &lt;/data-definition-statement&gt;  
      &lt;/yang-statements&gt;
     &lt;/revision-change-log&gt;
 
     &lt;revision-change-log&gt;
      &lt;index&gt;0002&lt;/index&gt;
      &lt;change-operation&gt;create&lt;/change-operation&gt;
      &lt;yang-statements&gt;
       &lt;other-statement&gt;
        &lt;statement&gt;   
         &lt;statement-name&gt;feature-statement&lt;/statement-name&gt;
         &lt;statement-definition&gt;
          feature if-mib {
           description
           "This feature indicates that the device implements
            the IF-MIB.";
           reference
           "RFC 2863: The Interfaces Group MIB";
          }
         &lt;/statement-definition&gt;
        &lt;/statement&gt;
       &lt;/other-statement&gt;   
      &lt;/yang-statements&gt; 
     &lt;/revision-change-log&gt;

     &lt;revision-change-log&gt;
      &lt;index&gt;0003&lt;/index&gt;
      &lt;change-operation&gt;modify&lt;/change-operation&gt;
      &lt;yang-statements&gt;
       &lt;data-definition-statement&gt;
        &lt;data-definition&gt;  
         &lt;target&gt;
         /if:interfaces/if:interface/if:link-up-down-trap-enable
         &lt;/target&gt;
         &lt;data-node&gt;
          leaf link-up-down-trap-enable {
          if-feature if-mib; // add if-feature statement
           type enumeration {
           ....
         &lt;/data-node&gt; 
        &lt;/data-definition&gt;
       &lt;/data-definition-statement&gt;   
      &lt;/yang-statements&gt; 
     &lt;/revision-change-log&gt;

     &lt;revision-change-log&gt;
      &lt;index&gt;0004&lt;/index&gt;
      &lt;change-operation&gt;move&lt;/change-operation&gt;
      &lt;yang-statements&gt;
       &lt;data-definition-statement&gt;
        &lt;data-definition&gt;      
         &lt;target&gt;
         /if:interfaces-state/if:interface/if:admin-status
         &lt;/target&gt;
        &lt;location-point&gt;
         /if:interfaces/if:interface/link-up-down-trap-enable
        &lt;/location-point&gt;
        &lt;where&gt;after&lt;/where&gt;
       &lt;/data-definition-statement&gt;   
      &lt;/yang-statements&gt;
     &lt;/revision-change-log&gt;

     &lt;revision-change-log&gt;
      &lt;index&gt;0005&lt;/index&gt;
      &lt;change-operation&gt;move&lt;/change-operation&gt;
      &lt;yang-statements&gt;
       &lt;data-definition-statement&gt;
        &lt;data-definition&gt;  
         &lt;target&gt;
         /if:interfaces-state/if:interface/if:statistics
         &lt;/target&gt;
         &lt;location-point&gt;
         /if:interfaces/if:interface/if:speed
         &lt;/location-point&gt;
         &lt;where&gt;after&lt;/where&gt;
       &lt;/data-definition-statement&gt;   
      &lt;/yang-statements&gt;
     &lt;/revision-change-log&gt;
     .......
    &lt;/module&gt;
   &lt;/yang-modules&gt;</artwork>
      </figure>
    </section>
  </back>
</rfc>
