<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,               
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.             
    There has to be one entity for each item to be referenced.                    
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2697 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2697.xml">
<!ENTITY RFC2698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2698.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wu-netconf-nmda-compatibility-01"
     ipr="trust200902">
  <front>
    <title abbrev="NMDA Backwards-Compatibility">NMDA protocol operation
    Backwards-Compatibility with Legacy Devices</title>

    <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="Chong Feng" initials="C." surname="Feng">
      <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>frank.fengchong@huawei.com</email>
      </address>
    </author>

    <date year="2019"/>

    <area>OPS Area</area>

    <workgroup>NETCONF Working Group</workgroup>

    <abstract>
      <t>NMDA architectural framework eliminates the need to duplicate data
      structures to provide separate configuration and operational state
      sections and uses different datastores and new protocol operations to
      distinct configuration from operation state. However when non-NMDA
      clients communicate with NMDA aware server, it is not clear whether the
      NMDA aware server can use existing operation to return the same results
      with &lt;rpc-reply&gt; as non-NMDA-aware server does.</t>

      <t>This document identifies some of the major challenges, and provides
      solutions that are able to mitigate those challenges and smooth the
      migration towards NMDA deployment.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>NMDA architectural framework introduces additional datastores for
      systems that support more advanced processing chains converting
      configuration to operational state. It eliminates the need to duplicate
      data structures to provide separate configuration and operational state
      sections and uses different datastores and new protocol operations
      (e.g.,&lt;get-data&gt;,&lt;edit-data&gt; to distinct configuration from
      operation state).</t>

      <t>However when a NMDA client communicates with NMDA aware server, it is
      not clear whether the NMDA aware server can return the same results with
      &lt;rpc-reply&gt; to non-NMDA clients as non-NMDA-aware server does
      since the system configuration and default configuration originally part
      of conventional configuration datastores have been explicitly separated
      and moved to operational state datastore under NMDA architecture. Also
      it is not clear whether the server should maintain protocol operation
      backwards-compatibility when the NMDA aware server is upgraded from
      non-NMDA-aware server to NMDA aware server.</t>

      <t>NMDA Transition Guidelines in section 4.23.3 of [RFC8407] only
      provides guidelines to transform non-NMDA compliant model into NMDA
      compatible model, but doesn't provide guidelines on whether existing
      NETCONF protocol operations such as get/get-config/edit-config change
      semantics when they are exchanged between the non NMDA client and the
      NMDA arware server.</t>

      <t>This document identifies some of the major challenges, and provides
      solutions that are able to address those challenges which provide smooth
      migration towards NMDA deployment.<list style="symbols">
          <t>Use protocol operation to indicate whether the client NMDA
          support.</t>

          <t>An extension to Default handling Behaviour.</t>

          <t>Protocol Operation Clarification.</t>
        </list></t>

      <section title="Terminology">
        <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 [RFC2119] [RFC8174] when, and only when, they appear in all
        capitals, as shown here.</t>

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

        <t><list style="symbols">
            <t>startup configuration datastore</t>

            <t>candiate configuration datastore</t>

            <t>running configuration datastore</t>

            <t>intended configuration datastore</t>

            <t>operational state datastore</t>
          </list></t>

        <t>The following terms are defined in this document:<list>
            <t>Server Protocol Operation Backwards-Compatibility: The client
            can use the same protocol operation to get the same results from
            both NMDA compliant server and Non NMDA server.</t>
          </list></t>
      </section>
    </section>

    <!-- intro -->

    <section title="Problems">
      <section title="NMDA Client vs Non-NMDA Client">
        <t>When a server is upgraded to NMDA aware server and needs to support
        both NMDA client and non-NMDA clients, there is no standards-based way
        for the server to know whether the client supports NMDA.</t>
      </section>

      <section title="NETCONF Server Back-Compatibility">
        <t>When a server is upgraded to NMDA server and needs to support both
        NMDA client and non-NMDA clients, without NETCONF server protocol
        operation backwards-comability, a NMDA server can return the results
        with &lt;rpc-reply&gt; to non-NMDA clients different from
        non-NMDA-aware server does. Since in some cases ('report-all'
        Retrieval Mode or client set Explicit Mode) default configuration
        originally part of conventional configuration datastores have been
        explicitly separated and moved to operational state datastore, so does
        the system configuration. For non-NMDA client, the configuration
        retrieved by &lt;get-config&gt; on the running datastore will be
        reduced without including system configuration and default
        configuration set by the server. Non-NMDA client also has no way to
        retrieve system configuration without new operations support on
        operational state datstore.</t>
      </section>

      <section title="Feed System Configuration Back into Running Datastore">
        <t>As we know, the system configuration and default configuration
        originally part of conventional configuration datastores before NMDA
        is introduced have been separated and moved to operational state
        datastore. When further configuration is needed within the system
        configuration, e.g., configure IP address of the interface after such
        interface configuration (i.e.,system configuration) is auto-created,
        such auto-created interface configuration needs to set by the client
        since it doesn't exist in the conventional configuration datastore.
        The effect is the same as feed auto-created interface configuration
        into running datastore and make it become client set configuration.
        After the interface configuration is applied, it will be merged with
        the other existing system configuration in the operational state
        datastore.</t>
      </section>
    </section>

    <section title="Solution">
      <section title="Client NMDA Support">
        <t>When a NMDA aware sever needs to support both NMDA client and
        non-NMDA clients, server NMDA support can be advertised to the client
        via capability identifier :yang-library:1.1 to the client. Client NMDA
        support should be indicated by protocol operations. If
        &lt;get&gt;/&lt;get-config&gt;/&lt;edit-config&gt; operation is
        recieved from the client, the server should assume the client is
        Non-NMDA client. If &lt;get-data&gt;/&lt;edit-data&gt; operation is
        recieved from the client, the server should assume the client is NMDA
        client.</t>

        <t>Editor-Note: There are three ways to Indicate client support on
        NMDA:<list style="numbers">
            <t>Define capability identifier for client NMDA support and
            advertising this capability identifier to the server;</t>

            <t>Use new or old protocol operation to indicate client NMDA
            support;</t>

            <t>Use whether module type is NMDA aware to indicate client NMDA
            support ;</t>
          </list> Either advertising capability identifier to the server or
        using module type to indicate client NMDA support adds server
        implementation complexity. We argue to use protocol operation to
        indicate whether the client support NMDA.</t>
      </section>

      <section title="Default handling Behaviour">
        <t>With-default capability defined in [RFC6243] is designed for
        conventional configuration datatore. As described in
        [I-D.ietf-netconf-nmda-netconf], semantics for "with-defaults" in
        &lt;edit-data&gt; operations is the same as for &lt;edit-config&gt;,
        as described in section 4.5.2 of [RFC6243]. However when the NMDA is
        introduced, the default configuration is clearly separated from
        conventional configuration datastore, the semantics of "with-defaults"
        parameter have made a few changes.</t>

        <section title="Default-Handling Basic Modes">
          <t>A NMDA aware server still supports three basic modes defined in
          [RFC6243] for handling default data. In addition to 'report-all'
          Retrieval Mode, the 'report-all' basic mode should be also treated
          in the same way as 'explicit' basic model in case of NMDA since the
          default configuration has been moved to operational state datastore
          and therefore the NMDA aware server should not consider the default
          configuration is part of conventional configuration datastore unless
          it is explicitly set by the client.</t>

          <section title="'report-all' Basic Mode Retrieval">
            <t>When the data is retrieved from a server using the 'report-all'
            basic mode, and the &lt;with-defaults&gt; parameter is not
            present, data nodes MUST be reported if explicitly set by the
            client, even if they contain the schema default value.</t>
          </section>

          <section anchor="edit"
                   title="'report-all' &lt;edit-config&gt; and &lt;copy-config&gt; Behaviour">
            <t>For backwards compatibility consideration, the server consider
            the default data part of conventional configuration datastore. A
            valid 'create' operation attribute for a data node that has been
            set by a client to its schema default value MUST fail with a
            'data-exists' error-tag. A valid 'delete' operation attribute for
            a data node that has been set by a client to its schema default
            value MUST succeed.</t>
          </section>

          <section title="'report-all' &lt;edit-data&gt; Behaviour">
            <t>If the 'with-defaults' capability is supported by the server,
            the 'report-all' basic mode, defined in section 3.2.1.1, is
            supported for &lt;edit-data&gt; operations that target
            conventional configuration datastores.</t>

            <t>A valid 'create' operation attribute for a data node that has
            been set by a client to its schema default value MUST succeed. A
            valid 'delete' operation attribute for a data node that has been
            set by a client to its schema default value MUST fail with a
            'data-missing' error-tag.</t>

            <t>Since the default configuration doesn't exist in the
            conventional configuration datastore, the default configuration
            MUST be created without error being returned, irrespectively
            "with-defaults" parameter being set to basic-mode, trim or
            report-all.</t>
          </section>
        </section>

        <section anchor="get" title="get/get-config Operation">
          <t>For backwards compatibility consideration, when the basic mode is
          set to 'report-all' or 'with-defaults' capability parameter is set
          to report all, the NMDA aware server should return all the data
          based on filtering selection criteria including all the data from
          conventional configuration datastore and default configuration from
          operational state datastore.</t>
        </section>

        <section anchor="getdata" title="get-data Operation">
          <t>When the basic mode is set to report-all or 'with-defaults'
          capability parameter is set to report all, the NMDA aware server
          should return all the data based on filtering selection criteria
          including all the data from conventional configuration datastore,
          but not include default configuration from operational state
          datastore unless they are explicitly set by the client.</t>
        </section>
      </section>

      <section title="Protocol Operation Clarification">
        <section title="&lt;get&gt;">
          <t>As described in [RFC6241], the NETCONF &lt;get&gt; operation
          returns the contents of &lt;running&gt; together with the
          operational state.</t>

          <t>If the client supports NMDA and sends &lt;get&gt; request to the
          NMDA aware server, the server should assume the client is non-NMDA
          client and retrieve specified configuration from running
          configuration and system configuration from operational state
          datastore and return it together with the system configuration to
          the client in &lt;rpc-reply&gt;.</t>

          <t>If the client doesn't support NMDA and sends &lt;get&gt; request
          to the NMDA aware server, the server should retrieve running
          configuration and system configuration from operational state
          datastore and return the same results as it retrieves from non-NMDA
          aware server.</t>

          <t>For default handling basic modes, please refer to <xref
          target="get"/>.</t>
        </section>

        <section title="&lt;get-config&gt;">
          <t>As described in [RFC6241], the NETCONF &lt;get-config&gt;
          operation can be used to retrieve all or part of a specified
          configuration datastore.</t>

          <t>If the client supports NMDA and sends &lt;get-config&gt; request
          to the NMDA aware Server, the server should assume the client is
          non-NMDA client and retrieve specified configuration from
          &lt;running&gt; together with the system configuration.</t>

          <t>If the client doesn't support NMDA and send &lt;get-config&gt;
          request to the NMDA aware server, the server should retrieve
          &lt;running&gt; configuration together with the system configuration
          and return the same result as it retrieves from non-NMDA aware
          server.</t>

          <t>For default handling basic modes, please refer to <xref
          target="get"/>.</t>
        </section>

        <section title="&lt;edit-config&gt;">
          <t>As described in [RFC6241], the NETCONF &lt;edit-config&gt;
          operation can be used to load all or part of a specified
          configuration to the specified target configuration datastore.</t>

          <t>If the client sends &lt;edit-config&gt; request to the NMDA aware
          server and wants to have further configuration based on the system
          configuration,(e.g.,configure IP address within auto-created
          physical interface configuration), the server should create IP
          address configuration corresponding to specific physical interface
          without error to be returned to the client as long as IP address
          configuration is validated. The effect is the same as the physical
          interface has already been part of conventional configuration
          datastore. If the system configuration is set by the client sending
          &lt;edit-config&gt;operation request, the error should be returned
          as if the system configuration has already been part of conventional
          configuration datastore.</t>

          <t>For default handling basic modes, please refer to <xref
          target="edit"/>.</t>
        </section>

        <section title="&lt;get-data&gt;">
          <t>As described in [I-D.ietf-netconf-nmda-netconf], the
          &lt;get-data&gt; operation retrieves data from a specific NMDA
          datastore,similar to NETCONF's &lt;get-config&gt; operation defined
          in [RFC6241].</t>

          <t>If the client sends &lt;get-data&gt; request with specified
          target configuration datastore set to the running datastore, the
          server should assume the client is NMDA client and retrieve
          specified configuration from &lt;running&gt; without system
          configuration set by the server since the system configuration is
          separated from conventional configuration datastore.</t>

          <t>For default handling basic modes, please refer to <xref
          target="getdata"/>.</t>
        </section>

        <section title="&lt;edit-data&gt;">
          <t>As described in [I-D.ietf-netconf-nmda-netconf], the NETCONF
          &lt;edit-data&gt; operation can be used to load all or part of a
          specified configuration to the specified target configuration
          datastore.</t>

          <t>For the NMDA client sending &lt;edit-data&gt; operation request
          with specified target configuration datastore set to the
          configuration datastore such as running datastore, since the system
          configuration is separated from conventional configuration
          datastore, if the NMDA client wants to use system configuration or
          configure other parameter (e.g., IP address) within system
          configuration(e.g., auto-created interface configuration),
          Explicitly creating the system configuration by the client MUST be
          allowed without error being returned.</t>
        </section>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>There is no IANA action in this document.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document does not introduce any security vulnerability besides
      one defined in [RFC6241] [I-D.ietf-netconf-nmda-netconf].</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks Robert Wilton,Guangying Zheng,Shouchuan Yang,Dan Qu, Ye Niu to
      discuss NMDA comability issues on existing protocol operation and
      provide important input to this document.</t>
    </section>

    <section title="Contributors">
      <figure>
        <artwork>   Michael Wang
   Huawei Technologies, Co., Ltd
   101 Software Avenue, Yuhua District
   Nanjing  210012
   China

   Email: wangzitao@huawei.com</artwork>
      </figure>
    </section>

    <!---->
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>

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

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

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

      <?rfc include="reference.RFC.8407.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-netconf-nmda-netconf"?>
    </references>
  </back>
</rfc>
