<?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-base-notification-nmda-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="Base notifications NMDA">Base Notifications for
    NMDA</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="Rohit R Ranade" initials="R." surname="Ranade">
      <organization>Huawei</organization>

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

    <date year="2018"/>

    <area>OPS Area</area>

    <workgroup>NETCONF Working Group</workgroup>

    <abstract>
      <t>The Network Configuration Protocol (NETCONF) provides mechanisms to
      manipulate configuration datastores. NMDA introduces additional
      datastores for systems that support more advanced processing chains
      converting configuration to operational state. However, client
      applications are not able to be aware of common events pertaining to
      additional datstores, such as a data validation state change in NETCONF
      server, that may impact management applications. This document updates
      [RFC6470] to allow a NETCONF client to receive additional notifications
      for some common system events pertaining to the Network Management
      Datastore Architecture (NMDA) defined in [RFC8342].</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The Network Configuration Protocol (NETCONF) [RFC6470] provides
      mechanisms to manipulate configuration datastores. NMDA introduces
      additional datastores (e.g., &lt;intended&gt;, &lt;operational&gt;) for
      systems that support more advanced processing chains converting
      configuration to operational state. However, client applications are not
      able to be aware of common events pertaining to additional datastores,
      e.g., there are many background activities that happen during the time
      that configuration is committed to &lt;running&gt; to the time that the
      configuration is actually applied to &lt;operational&gt;. It is possible
      that some configuration could not be applied to &lt;operational&gt; due
      to either validation issues, or missing resource etc. There is a need
      for user to know the validation result of &lt;intended&gt; data-store
      and the reason why the configuration were not applied.</t>

      <t>This document updates [RFC6470] to allows a NETCONF client to receive
      additional notifications for some common system events pertaining to the
      Network Management Datastore Architecture (NMDA) defined in [RFC8342].
      These notification are not specific to any network management protocols
      such as NETCONF and RESTCONF.</t>

      <t>The solution presented in this document is backwards compatible with
      [RFC6470].</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="summary" title="Summary of Updates to RFC 6470">
      <t>This document is intended to provide an extension of notifications
      initially defined within [RFC6470], with the development of NMDA
      architcture and data model. Key relationships between these two
      documents include:</t>

      <t><list style="symbols">
          <t>The existing notifications defined in [RFC6470] are remain
          unchanged, no additional information is added.</t>

          <t>A new event notification is defined in this document to overcome
          the shortcoming of [RFC6470] for supporting NMDA.</t>
        </list></t>
    </section>

    <!-- summary -->

    <section anchor="extension"
             title="NETCONF Base Notifications YANG Model extension for NMDA">
      <section title="Overview">
        <t>The YANG module in NETCONF Base Notifications [RFC6470] specifies
        the following 5 event notifications for the 'NETCONF' stream to notify
        a client application that the NETCONF server state has changed:</t>

        <t><list style="symbols">
            <t>netconf-config-change</t>

            <t>netconf-capability-change</t>

            <t>netconf-session-start</t>

            <t>netconf-session-end</t>

            <t>netconf-confirmed-commit</t>
          </list></t>

        <t>These event notifications used within the 'NETCONF' stream are
        accessible to clients via the subscription mechanism described in
        [RFC5277].</t>

        <t>This document extends the YANG module defined in [RFC6470] to
        include NMDA specific extension which allows a NETCONF client to
        receive notifications for additional common system event as
        follows:<list style="hanging">
            <t hangText="nmda-data-validate:">Generated when a server with
            network management protocol support detects that a data validation
            event has occurred from the time that configuration is committed
            to &lt;running&gt; to the time that the configuration is actually
            applied to &lt;operational&gt; during management session.
            Indicates the event and the current state of the data validation.
            A server MAY report events for non-NETCONF management sessions
            (such as RESTCONF,gPRC), using the 'session-id' value of zero.</t>
          </list></t>

        <t>These notification messages are accessible to clients via either
        the subscription mechanism described in [RFC5277] or dynamic
        subscription mechanism and configured subscription mechanism described
        in [I-D.ietf-netconf-netconf-event-notifications].</t>

        <t>The following are examples of a nmda-data-validation notification
        message: <figure>
            <artwork>&lt;notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"&gt;
 &lt;eventTime&gt;2017-06-16T16:30:59.137045+09:00&lt;/eventTime&gt;
 &lt;nmda-data-validate xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-notifications"&gt;
     &lt;username&gt;admin&lt;/username&gt;
     &lt;session-id&gt;0&lt;/session-id&gt;
     &lt;source-host&gt;10.251.93.83&lt;/source-host&gt;
     &lt;validate-event&gt;start&lt;validate-event&gt;
     &lt;validate-result&gt;partial-fail&lt;/validate-result&gt;
     &lt;validate-fail-taget&gt;
      &lt;datastore&gt;intended&lt;/datastore&gt;
      &lt;target&gt; /ietf-interfaces:interfaces-state &lt;/target&gt;
     &lt;/validate-fail-target&gt;
     &lt;validate-fail-taget&gt;
      &lt;datastore&gt;intended&lt;/datastore&gt;
      &lt;target&gt; /ietf-system:system &lt;/target&gt;
     &lt;/validate-fail-target&gt;
 &lt;/nmda-data-validate&gt;
&lt;/notification&gt;</artwork>
          </figure></t>
      </section>

      <section title="Definitions">
        <t/>

        <t>This section presents the YANG module defined in this document.
        This module imports data types from the 'ietf-netconf' module defined
        in [RFC6241] and 'ietf-inet-types' module defined in [RFC6021].</t>

        <figure>
          <artwork> &lt;CODE BEGINS&gt; file "ietf-nmda-notifications@2018-04-01.yang"
module ietf-nmda-notifications {
  namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-notifications";
  prefix nmdan;

  import ietf-datastores {
    prefix ds;
  }
  import ietf-inet-types { prefix inet; }
  organization
    "IETF NETCONF (Network Configuration Protocol) Working Group";
  contact
    "WG Web:   &lt;http://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;
     Editor:   Rohit R Ranade
               &lt;mailto:rohitrranade@huawei.com&gt;";
  description
    "This module defines a YANG data model for use with the
     NETCONF protocol that allows the NETCONF client to
     receive additional common NETCONF base event notifications
      related to NMDA.
     Copyright (c) 2012 IETF Trust and the persons identified as
     the document authors.  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.";

  revision 2018-04-01 {
    description
      "Initial version.";
    reference "RFC xxx: NETCONF Base Notifications for NMDA";
  }
  typedef session-id-or-zero-type { 
     type uint32; 
     description 
       "NETCONF Session Id or Zero to indicate none"; 
   } 

  grouping common-session-parms {
    description
      "Common session parameters to identify a
       management session.";

    leaf username {
      type string;
      mandatory true;
      description
        "Name of the user for the session.";
    }

    leaf session-id {
      type session-id-or-zero-type;
      mandatory true;
      description
        "Identifier of the session.
         A NETCONF session MUST be identified by a non-zero value.
         A non-NETCONF session MAY be identified by the value zero.";
    }

    leaf source-host {
      type inet:ip-address;
      description
        "Address of the remote host for the session.";
    }
  }
  notification nmda-data-validate {
    description
      "Generated when a NETCONF server detects that a
       Data validation event has occurred.  Indicates the event
       and the current state of the data validation procedure
       in progress.";
    reference "RFC 8342, Section 5";
    uses common-session-parms;
    leaf validate-event {
      type enumeration {
        enum "start" {
          description
            "The data validate procedure has started.";
        }
        enum "complete" {
          description
            "The data validation procedure has been completed.";
        }
      }
      mandatory true;
      description
        "Indicates the event that caused the notification.";
    }
    leaf validate-result {
      when "../validate-event = 'complete'";
      type enumeration {
        enum "fail" {
          description
            "The &lt;intended&gt; configuration fails to be validated
             before being applied to &lt;operational&gt;, e.g., resources
             are not available or otherwise not physically present
             leads to the whole set of &lt;intended&gt;are not applied.";
        }
        enum "partial-fail" {
          description
            "The &lt;intended&gt; configuration partially fails to be
             validated before being applied to &lt;operational&gt;,e.g.,
             resources are not available or otherwise not physically
             present leads to parts of &lt;intended&gt;are not applied";
        }
        enum "success" {
          description
            "The &lt;intended&gt; configuration is successfully validated
             before being applied to &lt;operational&gt;.";
        }
      }
      description
        "Result of validate";
    }
    list fail-validate-target {
      leaf datastore {
        type identityref {
          base ds:datastore;
        }
        default "ds:operational";
        description
          "Indicates which datastore has changed or which datastore is
           target of edit-data operation.";
      }
      leaf target {
        type instance-identifier;
        description
          "Topmost node associated with the configuration change.
           A server SHOULD set this object to the node within
           the datastore that is being altered.  A server MAY
           set this object to one of the ancestors of the actual
           node that was changed, or omit this object, if the
           exact node is not known.";
      }
      description
        "List for fail validate targets";
    }
  }
}
&lt;CODE ENDS&gt;</artwork>
        </figure>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The YANG module defined in this memo is designed to be accessed via
      the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure
      transport layer and the mandatory-to-implement secure transport is SSH,
      defined in [RFC6242].</t>

      <t>Some of the readable data nodes in this YANG module may be considered
      sensitive or vulnerable in some network environments. It is thus
      important to control read access (e.g., via get, get-config, or
      notification) to these data nodes. These are the subtrees and data nodes
      and their sensitivity/vulnerability:</t>

      <t>/nmda-data-validate/validate-event:<list style="none">
          <t>Indicates the specific validate-event state change that occurred.
          A value of 'complete' probably indicates that data validation
          procedure has completed.</t>
        </list></t>
    </section>

    <section title="IANA Considerations">
      <t>This document registers one XML namespace URN in the 'IETF XML
      registry', following the format defined in [RFC3688]: <list style="none">
          <t>URI: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications</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 module name in the 'YANG Module Names'
      registry, defined in [RFC7950]: <list style="none">
          <t>name: ietf-nmda-notifications</t>

          <t>prefix: ncdn</t>

          <t>namespace:
          urn:ietf:params:xml:ns:yang:ietf-nmda-notifications</t>

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

    <section title="Acknowledgements">
      <t>Thanks to Juergen Schoenwaelder, Alex Clemm,Carey Timothy and Andy
      Berman to review this draft and provide important input to this
      document.</t>
    </section>

    <section title="Contributors">
      <figure>
        <artwork>   Xiaojian Ding
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

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

    <!---->
  </middle>

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

      <?rfc include="reference.RFC.3688.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.8342.xml'?>

      <?rfc include='reference.I-D.ietf-netconf-yang-push'?>

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