<?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">
]>
<rfc category="std" docName="draft-wu-netconf-restconf-factory-restore-00"
     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="Factory Default Setting Capability">Factory default Setting
    Capability for RESTCONF</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="Ye Niu" initials="Y." surname="Niu">
      <organization>Huawei</organization>

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

    <date year="2018"/>

    <area>OPS Area</area>

    <workgroup>NETCONF Working Group</workgroup>

    <abstract>
      <t>This document defines capability based extension to RESTCONF protocol
      that allows RESTCONF client to configure newly deployed devices with
      just its preconfigured initial state (i.e., factory default settings)
      during zero touch bootstrapping process or restore the configuration to
      its preconfigured initial state or system restore point either during
      device rooting process or at the time of system fatal error or
      malfunction.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>RESTCONF uses HTTP methods such as HTTP POST, PUT, PATCH, and DELETE
      to provide CRUD operations on a conceptual datastore containing YANG-
      defined data, which is compatible with a server that implements NETCONF
      datastores. As described in [RFC8040], the HTTP PUT method on the
      datastore resource can be used to replace the entire content of the
      Datasore, however it can not be used to return any datastore (e.g.,
      &lt;startup&gt;) to factory default setting or previous system restore
      point,especially when the RESTCONF server is implemented in a device
      that does not have NETCONF support.</t>

      <t>This document defines capability based extension to RESTCONF protocol
      that allows RESTCONF client to configure newly deployed devices with
      just its preconfigured initial state (i.e., factory default settings)
      during zero touch bootstrapping process or restore the configuration to
      its preconfigured initial state or system restore point either during
      device rooting process or at the time of system fatal error.</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>operational state datastore</t>

            <t>running configuration datastore</t>

            <t>intended configuration datastore</t>
          </list></t>
      </section>
    </section>

    <!-- intro -->

    <section anchor="datastore" title="Datastore">
      <t>A RESTCONF server implementing this document MUST be NMDA-compliant
      [I-D.ietf-netconf-nmda-restconf] and is implemented in a device that
      does not have a NETCONF server [RFC8040]. A RESTCONF server supports
      both the operational state Datastore and the intended configuration
      datastore.</t>

      <section title="The factory default setting Configuration Datastore">
        <t>This document introduces a new configuration datastore named
        'Factory default setting' that represents datastore with its
        preconfigured initial state.</t>

        <t>The Factory default setting datastore is essentially a special case
        of startup configuration datastore. The new name is used in order to
        emphasize the narrower semantics: the factory default setting
        datastore MUST be preconfigured with initial state of factory default
        setting.</t>

        <t>The factory default setting datastore assumes the place of the
        datastore resource as defined in [RFC8040] Section 3.4. This means
        that the entire datastore resources inside the "{+restconf}/data"
        subtree correspond to data instances in the factory default setting
        datastore. Therefore, the contents of the factory default setting
        datastore can be retrieved by means of the GET method as specified in
        [RFC8040] and but can not be modified by means of PUT methods as
        specified in [RFC8040].</t>
      </section>
    </section>

    <!-- summary -->

    <section anchor="operation" title="New Operations">
      <t>In order to support factory restore and system restore capability in
      RESTCONF, the YANG module "ietf-restconf-restore" defines three
      operations below. The factory-restore operation is is similar to NETCONF
      &lt;delete-config&gt; and defined to support Factory default Setting
      Capability in RESTCONF.</t>

      <section title="factory-restore">
        <t>The &lt;factor-restore&gt; operation atomically returns any target
        datastore to factory default setting. The
        &lt;factor-restore&gt;operation replaces the entire contents of a
        writable Datastore with the contents of complete factory default
        setting, similar to the &lt;delete-config&gt; operation defined in
        [RFC6241], but with additional flexibility in specifying the target
        Datastore. If the target datastore exists, it is overwritten.
        Otherwise, a new one is created, if allowed. If an
        &lt;factory-restore&gt; operation is invoked on a non-writable
        datastore, then an error is returned, as specified
        in"ietf-netconf-nmda".</t>

        <t>The "source" parameter is a datastore identity that indicates the
        desired source of &lt;factor-restore&gt; operation.</t>

        <t>The "target" parameter is a name of the configuration datastore to
        use as the destination of the &lt;factory-restore&gt; operation.</t>

        <t>The &lt;url&gt; element can appear as the &lt;source&gt; or
        &lt;target&gt; parameter.</t>

        <t>The "restart" parameter is used to indicate whether to use
        bootstrapping to return target datastore to factory default setting in
        the &lt; factor-restore &gt; operation. If bootstrapping is used, the
        "source" parameter MAY not be specified.</t>

        <section title="Example: return &lt;running&gt; to factory default setting  without zero touch bootstrapping support">
          <t>The client(e.g.,NMS) might send the following POST request
          message to invoke the "factory-recovery" RPC operation: <figure>
              <artwork>      POST /restconf/operations/ietf-restconf-factory-default:factory-recovery HTTP/1.1
      Host: example.com
      Content-Type: application/yang-data+xml       
     &lt;input xmlns="https://example.com/ns/ ietf-restconf-factory-default "&gt;
       &lt;source&gt;
       &lt;url&gt;file://checkpoint.conf&lt;/url&gt;
       &lt;/source&gt;
        &lt;target&gt;running&lt;/target&gt;
        &lt;restart&gt;false&lt;/restart&gt;
      &lt;/input&gt;</artwork>
            </figure></t>

          <t>In this request, &lt;restart&gt; element should be set to false,
          &lt;source&gt; element MUST be specified. If URL Capability is
          supported, &lt;url&gt;element in the &lt;source&gt; element MUST be
          specified. The server will use HTTP GET method to retrieve content
          of &lt;source&gt; corresponding to factory default setting datastore
          and copy the entire content to &lt;target&gt;. In successful case,
          the server might respond as follows: <figure>
              <artwork>      HTTP/1.1 204 No Content
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server</artwork>
            </figure></t>
        </section>

        <section title="Example: return &lt;running&gt; to factory default setting  with zero touch bootstrapping support">
          <t>The client(e.g.,NMS) might send the following POST request
          message to invoke the "factory-recovery" RPC operation: <figure>
              <artwork>      POST /restconf/operations/ietf-restconf-factory-default:factory-recovery HTTP/1.1
      Host: example.com
      Content-Type: application/yang-data+xml       
        &lt;input xmlns="https://example.com/ns/ ietf-restconf-factory-default "&gt;
        &lt;target&gt;running&lt;/target&gt;
        &lt;restart&gt;true&lt;/restart&gt;
      &lt;/input&gt;</artwork>
            </figure></t>

          <t>In this request, &lt;restart&gt; element should be set to true,
          &lt;source&gt; element is not specified. The server will use
          zerotouch bootstrap service defined in [I-D.ietf-netconf-zerotouch]
          to get factory default setting configuration and copy the entire
          content to &lt;target&gt;. In successful case, the server might
          respond as follows: <figure>
              <artwork>      HTTP/1.1 204 No Content
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server</artwork>
            </figure></t>
        </section>
      </section>
    </section>

    <section title="YANG Module">
      <figure>
        <artwork>   &lt;CODE BEGINS&gt; file "ietf-restconf-restore@2018-06-21.yang"
   module ietf-restconf-restore {
     namespace
       "urn:ietf:params:xml:ns:yang:ietf-restconf-restore";
     prefix rct;

    import ietf-inet-types {
      prefix inet;
    }
     organization
       "IETF NETCONF (Network Configuration) Working Group";

     contact
       "WG Web:   &lt;https://tools.ietf.org/wg/netconf/&gt;
        WG List:  &lt;mailto:netconf@ietf.org&gt;

        WG Chair: Kent Watsen
                  &lt;mailto:kwatsen@juniper.net&gt;

        WG Chair: Mahesh Jethanandani
                  &lt;mailto:mjethanandani@gmail.com&gt;

        Editor:   Qin Wu
                  &lt;mailto:bill.wu@huawei.com&gt;";

     description
       "This module defines operations that implement factory-default and
        system restore capability in the RESTCONF protocol.

        Copyright (c) 2018 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
        (https://trustee.ietf.org/license-info).

        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
        'OPTIONAL' in the module text are to be interpreted as described
        in RFC 2119 (https://tools.ietf.org/html/rfc2119).

        This version of this YANG module is part of RFC XXXX
        (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
        full legal notices.";

     revision 2018-06-21 {
       description
         "Initial revision.";
       reference
         "RFC XXXX: Factory default Setting Capability for RESTCONF";
     }

// NETCONF capabilities defined as features
    feature startup {
      description
        "NETCONF :startup capability;
         If the server advertises the :startup
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.7";
    }

    feature url {
      description
        "NETCONF :url capability;
         If the server advertises the :url
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.8";
    }
      feature writable-running {
      description
        "NETCONF :writable-running capability;
         If the server advertises the :writable-running
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.2";
    }

    feature candidate {
      description
        "NETCONF :candidate capability;
         If the server advertises the :candidate
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.3";
    }

     /* Operations */

     rpc factory-recovery {
       description
         "The &lt;factor-restore&gt; operation atomically returns any target datastore
         to factory default setting.  The &lt;factor-restore&gt;operation replaces the
          entire contents of a writable Datastore with the contents of complete
         factory default setting, similar to the &lt;delete-config&gt; operation defined in
         [RFC6241], but with additional flexibility in specifying the target Datastore.
          ";

      input {
        container target {
          description
            "Particular configuration to return factory default setting to.";
          choice config-target {
            mandatory true;
            description
              "The configuration target of the copy operation.";
            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              if-feature writable-running;
              type empty;
              description
                "The running configuration is the config target.
                 This is optional-to-implement on the server.";
            }

            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config target.";
            }
          }
        }

        container source {
          description
            "Particular configuration to copy from.";
          choice config-source {
            mandatory true;
           description
              "The configuration source for the copy operation.";

            leaf factory {
              if-feature candidate;
              type empty;
              description
                "The factory-default-setting configuration is the config source.";
            }

            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config source.";
            }
          }
        }
      leaf restart {
       type boolean;
            description
              "indicate whether restart or zero touch bootstrapping
               service is enabled.";
        }
      }
     }        
}
   &lt;CODE ENDS&gt;</artwork>
      </figure>
    </section>

    <section title="IANA Considerations">
      <t>This document registers one URI in the IETF XML Registry [RFC3688].
      The following registration has been made: <list style="none">
          <t>URI: urn:ietf:params:xml:ns:yang:ietf-restconf-restore</t>

          <t>Registrant Contact: The IESG.</t>

          <t>XML: N/A, the requested URI is an XML namespace.</t>
        </list></t>

      <t>This document registers one YANG module in the YANG Module Names
      Registry [RFC6020]. The following registration has been made: <list
          style="none">
          <t>name: ietf-restconf-restore</t>

          <t>namespace: urn:ietf:params:xml:ns:yang:ietf-restconf- restore</t>

          <t>prefix: rcf</t>

          <t>RFC: xxxx</t>
        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <!---->
  </middle>

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-netconf-zerotouch'?>
    </references>
  </back>
</rfc>
