doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc7758.txt b/doc/rfc/rfc7758.txt
new file mode 100644
index 0000000..d2715ab
--- /dev/null
+++ b/doc/rfc/rfc7758.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Mizrahi
+Request for Comments: 7758                                      Y. Moses
+Category: Experimental                                          Technion
+ISSN: 2070-1721                                            February 2016
+
+
+                       Time Capability in NETCONF
+
+Abstract
+
+   This document defines a capability-based extension to the Network
+   Configuration Protocol (NETCONF) that allows time-triggered
+   configuration and management operations.  This extension allows
+   NETCONF clients to invoke configuration updates according to
+   scheduled times and allows NETCONF servers to attach timestamps to
+   the data they send to NETCONF clients.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7758.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 1]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 2]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Conventions Used in This Document ...............................4
+      2.1. Key Words ..................................................4
+      2.2. Abbreviations ..............................................5
+      2.3. Terminology ................................................5
+   3. Using Time in NETCONF ...........................................5
+      3.1. The Time Capability in a Nutshell ..........................5
+      3.2. Notifications and Cancellation Messages ....................7
+      3.3. Synchronization Aspects ....................................9
+      3.4. Scheduled Time Format .....................................10
+      3.5. Scheduling Tolerance ......................................10
+      3.6. Scheduling the Near vs. Far Future ........................11
+      3.7. Time-Interval Format ......................................13
+   4. Time Capability ................................................14
+      4.1. Overview ..................................................14
+      4.2. Dependencies ..............................................14
+      4.3. Capability Identifier .....................................14
+      4.4. New Operations ............................................14
+      4.5. Modifications to Existing Operations ......................15
+           4.5.1. Affected Operations ................................15
+           4.5.2. Processing Scheduled Operations ....................16
+      4.6. Interactions with Other Capabilities ......................16
+   5. Examples .......................................................17
+      5.1. <scheduled-time> Example ..................................17
+      5.2. <get-time> Example ........................................18
+      5.3. Error Example .............................................19
+   6. Security Considerations ........................................19
+      6.1. General Security Considerations ...........................19
+      6.2. YANG Module Security Considerations .......................20
+   7. IANA Considerations ............................................21
+   8. References .....................................................22
+      8.1. Normative References ......................................22
+      8.2. Informative References ....................................22
+   Appendix A. YANG Module for the Time Capability ...................24
+   Acknowledgments ...................................................32
+   Authors' Addresses ................................................32
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 3]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+1.  Introduction
+
+   The Network Configuration Protocol (NETCONF), defined in [RFC6241],
+   provides mechanisms to install, manipulate, and delete the
+   configuration of network devices.  NETCONF allows clients to
+   configure and monitor NETCONF servers using remote procedure calls
+   (RPCs).
+
+   NETCONF is asynchronous; when a client invokes an RPC, it has no
+   control over the time at which the RPC is executed, nor does it have
+   any feedback from the server about the execution time.
+
+   Time-based configuration ([OneClock] [Time4]) can be a useful tool
+   that enables an entire class of coordinated and scheduled
+   configuration procedures.  Time-triggered configuration allows
+   coordinated network updates in multiple devices; a client can invoke
+   a coordinated configuration change by sending RPCs to multiple
+   servers with the same scheduled execution time.  A client can also
+   invoke a time-based sequence of updates by sending n RPCs with n
+   different update times, T1, T2, ..., Tn, determining the order in
+   which the RPCs are executed.
+
+   This memo defines the :time capability in NETCONF.  This extension
+   allows clients to determine the scheduled execution time of RPCs they
+   send.  It also allows a server that receives an RPC to report its
+   actual execution time to the client.
+
+   The NETCONF time capability is intended for scheduling RPCs that
+   should be performed in the near future, allowing the coordination of
+   simultaneous configuration changes or specification of an order of
+   configuration updates.  Time-of-day-based policies and far-future
+   scheduling, e.g., [Cond], are outside the scope of this memo.
+
+   This memo is defined for experimental purposes and will allow the
+   community to experiment with the NETCONF time capability.  Based on
+   the lessons learned from this experience, it is expected that the
+   NETCONF working group will be able to consider whether to adopt the
+   time capability.
+
+2.  Conventions Used in This Document
+
+2.1.  Key Words
+
+   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 [RFC2119].
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 4]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+2.2.  Abbreviations
+
+   NETCONF  Network Configuration Protocol
+
+   RPC      Remote Procedure Call
+
+2.3.  Terminology
+
+   o  Capability [RFC6241]: A functionality that supplements the base
+      NETCONF specification.
+
+   o  Client [RFC6241]: Invokes protocol operations on a server.  In
+      addition, a client can subscribe to receive notifications from a
+      server.
+
+   o  Execution time: The execution time of an RPC is defined as the
+      time at which a server completes the execution of an RPC, before
+      it sends the <rpc-reply> message.
+
+   o  Scheduled RPC: an RPC that is scheduled to be performed at a
+      predetermined time, which is included in the <rpc> message.
+
+   o  Scheduled time: The scheduled time of an RPC is the time at which
+      the RPC should be started, as determined by the client.  It is the
+      server's role to enforce the execution of the scheduled time.
+
+   o  Server [RFC6241]: Executes protocol operations invoked by a
+      client.  In addition, a server can send notifications to a client.
+
+3.  Using Time in NETCONF
+
+3.1.  The Time Capability in a Nutshell
+
+   The :time capability provides two main functions:
+
+   o  Scheduling:
+
+      When a client sends an RPC to a server, the <rpc> message MAY
+      include the scheduled-time element, denoted by Ts in Figure 1.
+      The server then executes the RPC at the scheduled time Ts; once
+      completed, the server can respond with an RPC reply message.
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 5]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   o  Reporting:
+
+      When a client sends an RPC to a server, the <rpc> message MAY
+      include a get-time element (see Figure 2), requesting the server
+      to return the execution time of the RPC.  In this case, after the
+      server performs the RPC, it responds with an RPC reply that
+      includes the execution time, Te.
+
+                      RPC _________
+                    executed       \
+                                   \/
+                                   Ts
+            server  ---------------+-------------        ----> time
+                              /\      \
+                          rpc /        \ rpc-reply
+                         (Ts)/          \
+                            /           \/
+            client  -----------------------------
+
+            Figure 1: Scheduled RPC
+
+                   RPC _________
+                 executed       \
+                                \/
+                                Te
+            server  ------------+----------------        ----> time
+                              /\   \
+                       rpc    /     \ rpc-reply
+                   (get-time)/       \ (Te)
+                            /        \/
+            client  -----------------------------
+
+            Figure 2: Reporting the Execution Time of an RPC
+
+   Example 1.  A client needs to trigger a commit at n servers, so that
+   the n servers perform the commit as close as possible to
+   simultaneously.  Without the time capability, the client sends a
+   sequence of n commit messages; thus, each server performs the commit
+   at a different time.  By using the time capability, the client can
+   send commit messages that are scheduled to take place at a chosen
+   time Ts, for example, 5 seconds in the future, causing the servers to
+   invoke the commit as close as possible to time Ts.
+
+   Example 2.  In many applications, it is desirable to monitor events
+   or collect statistics regarding a common time reference.  A client
+   can send a set of get-config messages that is scheduled to be
+   executed at multiple servers at the same time, providing a
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 6]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   simultaneous system-wide view of the state of the servers.  Moreover,
+   a client can use the get-time element in its get-config messages,
+   providing a time reference to the sampled element.
+
+   The scenarios of Figures 1 and 2 imply that a third scenario can also
+   be supported (Figure 3), where the client invokes an RPC that
+   includes a scheduled time, Ts, as well as the get-time element.  This
+   allows the client to receive feedback about the actual execution
+   time, Te.  Ideally, Ts=Te.  However, the server may execute the RPC
+   at a slightly different time than Ts, for example, if the server is
+   tied up with other tasks at Ts.
+
+                      RPC _________
+                    executed       \
+                                   \/
+                                Ts Te
+            server  -------------+-+-------------        ----> time
+                            /\        \
+                   rpc      /          \ rpc-reply
+            (Ts + get-time)/            \ (Te)
+                          /             \/
+            client  -----------------------------
+
+            Figure 3: Scheduling and Reporting
+
+3.2.  Notifications and Cancellation Messages
+
+   Notifications
+
+      As illustrated in Figure 1, after a scheduled RPC is executed, the
+      server sends an <rpc-reply>.  The <rpc-reply> may arrive a long
+      period of time after the RPC was sent by the client, leaving the
+      client without a clear indication of whether the RPC was received.
+
+      This document defines a new notification, the netconf-scheduled-
+      message notification, which provides an immediate acknowledgement
+      of the scheduled RPC.
+
+      The <netconf-scheduled-message> notification is sent to the client
+      if it is subscribed to the NETCONF notifications [RFC6470]; as
+      illustrated in Figure 4, when the server receives a scheduled RPC,
+      it sends a notification to the client.
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 7]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+      The <netconf-scheduled-message> notification includes a <schedule-
+      id> element.  The <schedule-id> is a unique identifier that the
+      server assigns to every scheduled RPC it receives.  Thus, a client
+      can keep track of all the pending scheduled RPCs; a client can
+      uniquely identify a scheduled RPC by the tuple {server, schedule-
+      id}.
+
+                      RPC ____________
+                    executed          \
+                                      \/
+                                      Ts
+            server  -------------------+---------        ----> time
+                        /\  \            \
+                    rpc /    \notifi-     \ rpc-reply
+                   (Ts)/      \cation      \
+                      /       \/           \/
+            client  -----------------------------
+
+            Figure 4: Scheduled RPC with Notification
+
+   Cancellation Messages
+
+      A client can cancel a scheduled RPC by sending a <cancel-schedule>
+      RPC.  The <cancel-schedule> RPC includes the <schedule-id> of the
+      scheduled RPC that needs to be cancelled.
+
+      The <cancel-schedule> RPC, defined in this document, can be used
+      to perform a coordinated all-or-none procedure, where either all
+      the servers perform the operation on schedule or the operation is
+      aborted.
+
+      Example 3.  A client sends scheduled <rpc> messages to server 1
+      and server 2, both scheduled to be performed at time Ts.  Server 1
+      sends a notification indicating that it has successfully scheduled
+      the RPC, while server 2 replies with an unknown-element error
+      [RFC6241] that indicates that it does not support the time
+      capability.  The client sends a <cancel-schedule> RPC to server 1
+      and receives an <rpc-reply>.  The message exchange between the
+      client and server 1 in this example is illustrated in Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                      [Page 8]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+                                RPC not __________
+                                executed          \
+                                                  \/
+                                                   Ts
+            server  --------------------------------+---      ----> time
+                        /\ \            /\        \
+                    rpc /   \notifi-    /cancel-   \ rpc-reply
+                   (Ts)/     \cation   /schedule    \
+                      /      \/       /             \/
+            client  ------------------------------------
+
+                  Figure 5: Cancellation Message
+
+   A <cancel-schedule> RPC MUST NOT include the scheduled-time
+   parameter.  A server that receives a <cancel-schedule> RPC should try
+   to cancel the schedule as soon as possible.  If the server is unable
+   to cancel the scheduled RPC, for example, because it has already been
+   executed, it should respond with an <rpc-error> [RFC6241], in which
+   the error-type is 'protocol', and the error-tag is 'operation-
+   failed'.
+
+3.3.  Synchronization Aspects
+
+   The time capability defined in this document requires clients and
+   servers to maintain clocks.  It is assumed that clocks are
+   synchronized by a method that is outside the scope of this document,
+   e.g., [RFC5905] or [IEEE1588].
+
+   This document does not define any requirements pertaining to the
+   degree of accuracy of performing scheduled RPCs.  Note that two
+   factors affect how accurately the server can perform a scheduled RPC:
+   one factor is the accuracy of the clock synchronization method used
+   to synchronize the clients and servers and the second factor is the
+   server's ability to execute real-time configuration changes, which
+   greatly depends on how it is implemented.  Typical networking devices
+   are implemented by a combination of hardware and software.  While the
+   execution time of a hardware module can typically be predicted with a
+   high level of accuracy, the execution time of a software module may
+   be variable and hard to predict.  A configuration update would
+   typically require the server's software to be involved, thus
+   affecting how accurately the RPC can be scheduled.
+
+   Another important aspect of synchronization is monitoring; a client
+   should be able to check whether a server is synchronized to a
+   reference time source.  Typical synchronization protocols, such as
+   the Network Time Protocol [RFC5905], provide the means ([RFC5907],
+   [RFC7317]) to verify that a clock is synchronized to a time reference
+   by querying its Management Information Base (MIB).  The get-time
+
+
+
+Mizrahi & Moses               Experimental                      [Page 9]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   feature defined in this document (see Figure 2) allows a client to
+   obtain a rough estimate of the time offset between the client's clock
+   and the server's clock.
+
+   Since servers do not perform configuration changes instantaneously,
+   the processing time of an RPC should not be overlooked.  The
+   scheduled time always refers to the start time of the RPC, and the
+   execution time always refers to its completion time.
+
+3.4.  Scheduled Time Format
+
+   The scheduled time and execution time fields in <rpc> messages use a
+   common time format field.
+
+   The time format used in this document is the date-and-time format,
+   defined in Section 5.6 of [RFC3339] and Section 3 of [RFC6991].
+
+       leaf scheduled-time {
+         type yang:date-and-time;
+         description
+         "The time at which the RPC is scheduled to be performed.";
+       }
+
+       leaf execution-time {
+         type yang:date-and-time;
+         description
+         "The time at which the RPC was executed.";
+       }
+
+3.5.  Scheduling Tolerance
+
+   When a client sends an RPC that is scheduled to Ts, the server MUST
+   verify that the value Ts is not too far in the past or in the future.
+   As illustrated in Figure 6, the server verifies that Ts is within the
+   scheduling-tolerance range.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 10]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+                  RPC _________
+                received       \
+                               \/
+                                     Ts
+            -----+--------------+-----+------------+-------> time
+
+                  <------------> <---------------->
+                  sched-max-past  sched-max-future
+
+                  <------------------------------->
+                       scheduling tolerance
+
+               Figure 6: Scheduling Tolerance
+
+   The scheduling tolerance is determined by two parameters: sched-max-
+   future and sched-max-past.  These two parameters use the time-
+   interval format (Section 3.7.), and their default value is 15
+   seconds.
+
+   If the scheduled time, Ts, is within the scheduling-tolerance range,
+   the scheduled RPC is performed; if Ts occurs in the past and within
+   the scheduling tolerance, the server performs the RPC as soon as
+   possible; whereas if Ts is a future time, the server performs the RPC
+   at Ts.
+
+   If Ts is not within the scheduling-tolerance range, the scheduled RPC
+   is discarded, and the server responds with an error message [RFC6241]
+   including a bad-element error-tag.  An example is provided in Section
+   5.3.
+
+3.6.  Scheduling the Near vs. Far Future
+
+   The scheduling bound defined by sched-max-future guarantees that
+   every scheduled RPC is restricted to a scheduling time in the near
+   future.
+
+   The scheduling mechanism defined in this document is intended for
+   near-future scheduling, on the order of seconds.  Far-future
+   scheduling is outside the scope of this document.
+
+   Example 1 is a typical example of using near-future scheduling; the
+   goal in the example is to perform the RPC at multiple servers at the
+   same time; therefore, it is best to schedule the RPC to be performed
+   a few seconds in the future.
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 11]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   The Challenges of Far-Future Scheduling
+
+      When an RPC is scheduled to be performed at a far-future time,
+      during the long period between the time at which the RPC is sent
+      and the time at which it is scheduled to be executed, the
+      following erroneous events may occur:
+
+      o  The server may restart.
+
+      o  The client's authorization level may be changed.
+
+      o  The client may restart and send a conflicting RPC.
+
+      o  A different client may send a conflicting RPC.
+
+      In these cases, if the server performs the scheduled operation, it
+      may perform an action that is inconsistent with the current
+      network policy or inconsistent with the currently active clients.
+
+      Near-future scheduling guarantees that external events, such as
+      the examples above, have a low probability of occurring during the
+      sched-max-future period, and even when they do, the period of
+      inconsistency is limited to sched-max-future, which is a short
+      period of time.
+
+   The Trade-off in Setting the sched-max-future Value
+
+      The sched-max-future parameter should be configured to a value
+      that is high enough to allow the client to:
+
+      1. Send the scheduled RPC, potentially to multiple servers.
+
+      2. Receive notifications or <rpc-error> messages from the
+         server(s) or wait for a timeout and decide that if no response
+         has arrived then something is wrong.
+
+      3. If necessary, send a cancellation message, potentially to
+         multiple servers.
+
+      On the other hand, sched-max-future should be configured to a
+      value that is low enough to allow a low probability of the
+      erroneous events above, typically on the order of a few seconds.
+      Note that, even if sched-max-future is configured to a low value,
+      it is still possible (with a low probability) that an erroneous
+      event will occur.  However, this short, potentially hazardous
+      period is not significantly worse than in conventional
+      (unscheduled) RPCs, as even a conventional RPC may in some cases
+      be executed a few seconds after it was sent by the client.
+
+
+
+Mizrahi & Moses               Experimental                     [Page 12]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   The Default Value of sched-max-future
+
+      The default value of sched-max-future is defined to be 15 seconds.
+      This duration is long enough to allow the scheduled RPC to be sent
+      by the client, potentially to multiple servers, and in some cases
+      to send a cancellation message, as described in Section 3.2.  On
+      the other hand, the 15-second duration yields a very low
+      probability of a reboot or a permission change.
+
+3.7.  Time-Interval Format
+
+   The time-interval format is used for representing the length of a
+   time interval and is based on the date-and-time format.  It is used
+   for representing the scheduling tolerance parameters, as described in
+   the previous section.
+
+   While the date-and-time type uniquely represents a specific point in
+   time, the time-interval type defined below can be used to represent
+   the length of a time interval without specifying a specific date.
+
+   The time-interval type is defined as follows:
+
+      typedef time-interval {
+        type string {
+          pattern '\d{2}:\d{2}:\d{2}(\.\d+)?';
+        }
+        description
+          "Defines a time interval, up to 24 hours.
+           The format is specified as HH:mm:ss.f,
+           consisting of two digits for hours,
+           two digits for minutes, two digits
+           for seconds, and zero or more digits
+           representing second fractions.";
+      }
+
+   Example
+
+   The sched-max-future parameter is defined (Appendix A) as a time-
+   interval, as follows:
+
+      leaf sched-max-future {
+        type time-interval;
+        default 00:00:15.0;
+      }
+
+   The default value specified for sched-max-future is 0 hours, 0
+   minutes, and 15 seconds.
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 13]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+4.  Time Capability
+
+   The structure of this section is as defined in Appendix D of
+   [RFC6241].
+
+4.1.  Overview
+
+   A server that supports the time capability can perform time-triggered
+   operations as defined in this document.
+
+   A server implementing the :time capability:
+
+   o  MUST support the ability to receive <rpc> messages that include a
+      time element and perform a time-triggered operation accordingly.
+
+   o  MUST support the ability to include a time element in the <rpc-
+      reply> messages that it transmits.
+
+4.2.  Dependencies
+
+   With-defaults Capability
+
+      The time-capability YANG module (Appendix A) uses default values;
+      thus, it is assumed that the with-defaults capability [RFC6243] is
+      supported.
+
+4.3.  Capability Identifier
+
+   The :time capability is identified by the following capability
+   string:
+
+   urn:ietf:params:netconf:capability:time:1.0
+
+4.4.  New Operations
+
+   <cancel-schedule>
+
+      The <cancel-schedule> RPC is used for cancelling an RPC that was
+      previously scheduled.
+
+      A <cancel-schedule> RPC MUST include the <cancelled-message-id>
+      element, which specifies the message ID of the scheduled RPC that
+      needs to be cancelled.
+
+      A <cancel-schedule> RPC MAY include the <get-time> element.  In
+      this case, the <rpc-reply> includes the <execution-time> element,
+      specifying the time at which the scheduled RPC was cancelled.
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 14]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+4.5.  Modifications to Existing Operations
+
+4.5.1.  Affected Operations
+
+   The :time capability defined in this memo can be applied to any of
+   the following operations:
+
+   o  get-config
+
+   o  get
+
+   o  copy-config
+
+   o  edit-config
+
+   o  delete-config
+
+   o  lock
+
+   o  unlock
+
+   o  commit
+
+   Three new elements are added to each of these operations:
+
+   o  <scheduled-time> This element is added to the input of each
+      operation, indicating the time at which the server is scheduled to
+      invoke the operation.  Every <rpc> message MAY include the
+      <scheduled-time> element.  A server that supports the :time
+      capability and receives an <rpc> message with a <scheduled-time>
+      element MUST perform the operation as close as possible to the
+      scheduled time.
+
+      The <scheduled-time> element uses the date-and-time format
+      (Section 3.4.).
+
+   o  <get-time> This element is added to the input of each operation.
+      An <rpc> message MAY include a <get-time> element, indicating that
+      the server MUST include an <execution-time> element in its
+      corresponding <rpc-reply>.
+
+   o  <execution-time> This element is added to the output of each
+      operation, indicating the time at which the server completed the
+      operation.  An <rpc-reply> MAY include the <execution-time>
+      element.  A server that supports the :time capability and receives
+      an operation with the <get-time> element MUST include the
+      execution time in its response.
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 15]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+      The <execution-time> element uses the date-and-time format
+      (Section 3.4.).
+
+4.5.2.  Processing Scheduled Operations
+
+   A server that receives a scheduled RPC MUST start executing the RPC
+   as close as possible to its scheduled execution time.
+
+   If a session between a client and a server is terminated, the server
+   MUST cancel all pending scheduled RPCs that were received in this
+   session.
+
+   Scheduled RPCs are processed serially, in an order that is defined by
+   their scheduled times.  Thus, the server sends <rpc-reply> messages
+   to scheduled RPCs according to the order of their corresponding
+   schedules.  Note that this is a modification to the behavior defined
+   in [RFC6241], which states that replies are sent in the order the
+   requests were received.  Interoperability with [RFC6241] is
+   guaranteed by the NETCONF capability exchange; a server that does not
+   support the :time capability responds to RPCs in the order the
+   requests were received.  A server that supports the :time capability
+   replies to conventional (non-scheduled) RPCs in the order they were
+   received and replies to scheduled RPCs in the order of their
+   scheduled times.
+
+   If a server receives two or more RPCs that are scheduled to be
+   performed at the same time, the server executes the RPCs serially in
+   an arbitrary order.
+
+4.6.  Interactions with Other Capabilities
+
+   Confirmed Commit Capability
+
+      The confirmed commit capability is defined in Section 8.4 of
+      [RFC6241].  According to that document, a confirmed <commit>
+      operation MUST be reverted if a confirming commit is not issued
+      within the timeout period (which is 600 seconds by default).
+
+      When the time capability is supported, and a confirmed <commit>
+      operation is used with the <scheduled-time> element, the
+      confirmation timeout MUST be counted from the scheduled time,
+      i.e., the client begins the timeout measurement starting at the
+      scheduled time.
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 16]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+5.  Examples
+
+5.1.  <scheduled-time> Example
+
+   The following example extends the example presented in Section 7.2 of
+   [RFC6241] by adding the time capability.  In this example, the
+   <scheduled-time> element is used to specify the scheduled execution
+   time of the configuration update (as shown in Figure 1).
+
+   <rpc message-id="101"
+       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <edit-config>
+       <target>
+         <running/>
+       </target>
+       <scheduled-time
+          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-time">
+           2015-10-21T04:29:00.235Z
+       </scheduled-time>
+       <config>
+         <top xmlns="http://example.com/schema/1.2/config">
+           <interface>
+             <name>Ethernet0/0</name>
+             <mtu>1500</mtu>
+           </interface>
+         </top>
+       </config>
+     </edit-config>
+   </rpc>
+
+   <rpc-reply message-id="101"
+        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <ok/>
+   </rpc-reply>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 17]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+5.2.  <get-time> Example
+
+   The following example is similar to the one presented in Section 5.1,
+   except that, in this example, the client includes a <get-time>
+   element in its RPC and the server consequently responds with an
+   <execution-time> element (as shown in Figure 2).
+
+   <rpc message-id="101"
+       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <edit-config>
+       <target>
+         <running/>
+       </target>
+       <get-time
+        xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-time">
+       </get-time>
+       <config>
+         <top xmlns="http://example.com/schema/1.2/config">
+           <interface>
+             <name>Ethernet0/0</name>
+             <mtu>1500</mtu>
+           </interface>
+         </top>
+       </config>
+     </edit-config>
+   </rpc>
+
+   <rpc-reply message-id="101"
+        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <ok/>
+     <execution-time>
+         2015-10-21T04:29:00.235Z
+     </execution-time>
+   </rpc-reply>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 18]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+5.3.  Error Example
+
+   The following example presents a scenario in which the scheduled-time
+   is not within the scheduling tolerance, i.e., it is too far in the
+   past; therefore, an <rpc-error> is returned.
+
+   <rpc message-id="101"
+       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <edit-config>
+       <target>
+         <running/>
+       </target>
+       <scheduled-time
+          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-time">
+           2010-10-21T04:29:00.235Z
+       </scheduled-time>
+       <config>
+         <top xmlns="http://example.com/schema/1.2/config">
+           <interface>
+             <name>Ethernet0/0</name>
+             <mtu>1500</mtu>
+           </interface>
+         </top>
+       </config>
+     </edit-config>
+   </rpc>
+
+   <rpc-reply message-id="101"
+        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <rpc-error>
+       <error-type>application</error-type>
+       <error-tag>bad-element</error-tag>
+       <error-severity>error</error-severity>
+       <error-info>
+         <bad-element>scheduled-time</bad-element>
+       </error-info>
+     </rpc-error>
+   </rpc-reply>
+
+6.  Security Considerations
+
+6.1.  General Security Considerations
+
+   The security considerations of the NETCONF protocol in general are
+   discussed in [RFC6241].
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 19]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   The usage of the time capability defined in this document can assist
+   an attacker in gathering information about the system, such as the
+   exact time of future configuration changes.  Moreover, the time
+   elements can potentially allow an attacker to learn information about
+   the system's performance.  Furthermore, an attacker that sends
+   malicious <rpc> messages can use the time capability to amplify her
+   attack; for example, by sending multiple <rpc> messages with the same
+   scheduled time.  It is important to note that the security measures
+   described in [RFC6241] can prevent these vulnerabilities.
+
+   The time capability relies on an underlying time synchronization
+   protocol.  Thus, by attacking the time protocol, an attack can
+   potentially compromise NETCONF when using the time capability.  A
+   detailed discussion about the threats against time protocols and how
+   to mitigate them is presented in [RFC7384].
+
+   The time capability can allow an attacker to attack a NETCONF server
+   by sending malicious RPCs that are scheduled to take place in the
+   future.  For example, an attacker can send multiple scheduled RPCs
+   that are scheduled to be performed at the same time.  Another
+   possible attack is to send a large number of scheduled RPCs to a
+   NETCONF server, potentially causing the server's buffers to overflow.
+   These attacks can be mitigated by a carefully designed NETCONF
+   server; when a server receives a scheduled RPC that exceeds its
+   currently available resources, it should reply with an <rpc-error>
+   and discard the scheduled RPC.
+
+   Note that if an attacker has been detected and revoked, its future
+   scheduled RPCs are not executed; as defined in Section 4.5.2, once
+   the session with the attacker has been terminated, the corresponding
+   scheduled RPCs are discarded.
+
+6.2.  YANG Module Security Considerations
+
+   This memo defines a new YANG module, as specified in Appendix A.
+
+   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 Secure SHell (SSH) [RFC6242].  The NETCONF access
+   control model [RFC6536] provides the means to restrict access for
+   particular NETCONF users to a preconfigured subset of all available
+   NETCONF protocol operations and content.
+
+   This YANG module defines <sched-max-future> and <sched-max-past>,
+   which are writable/creatable/deletable.  These data nodes may be
+   considered sensitive or vulnerable in some network environments.  An
+   attacker may attempt to maliciously configure these parameters to a
+
+
+
+Mizrahi & Moses               Experimental                     [Page 20]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   low value, thereby causing all scheduled RPCs to be discarded.  For
+   instance, if a client expects <sched-max-future> to be 15 seconds,
+   but in practice it is maliciously configured to 1 second, then a
+   legitimate scheduled RPC that is scheduled to be performed 5 seconds
+   in the future will be discarded by the server.
+
+   This YANG module defines the <cancel-schedule> RPC.  This RPC may be
+   considered sensitive or vulnerable in some network environments.
+   Since the value of the <schedule-id> is known to all the clients that
+   are subscribed to notifications from the server, the <cancel-
+   schedule> RPC may be used maliciously to attack servers by cancelling
+   their pending RPCs.  This attack is addressed in two layers: (i)
+   security at the transport layer, limiting the attack only to clients
+   that have successfully initiated a secure session with the server,
+   and (ii) the authorization level required to cancel an RPC should be
+   the same as the level required to schedule it, limiting the attack
+   only to attackers with an authorization level that is equal to or
+   higher than that of the client that initiated the scheduled RPC.
+
+7.  IANA Considerations
+
+   The following capability identifier URN has been registered in the
+   "Network Configuration Protocol (NETCONF) Capability URNs" registry:
+
+      urn:ietf:params:netconf:capability:time:1.0
+
+   The following XML namespace URN has been registered in the "IETF XML
+   Registry", following the format defined in [RFC3688]:
+
+      URI: urn:ietf:params:xml:ns:yang:ietf-netconf-time
+
+      Registrant Contact: The IESG.
+
+      XML: N/A, the requested URI is an XML namespace.
+
+   The following module name has been registered in the "YANG Module
+   Names" registry, defined in [RFC6020].
+
+      name: ietf-netconf-time
+
+      prefix: nct
+
+      namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-time
+
+      RFC: 7758
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 21]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119,
+               DOI 10.17487/RFC2119, March 1997,
+               <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3339]   Klyne, G. and C. Newman, "Date and Time on the Internet:
+               Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
+               <http://www.rfc-editor.org/info/rfc3339>.
+
+   [RFC3688]   Mealling, M., "The IETF XML Registry", BCP 81,
+               RFC 3688, DOI 10.17487/RFC3688, January 2004,
+               <http://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC6241]   Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J.,
+               Ed., and A. Bierman, Ed., "Network Configuration Protocol
+               (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+               <http://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6470]   Bierman, A., "Network Configuration Protocol (NETCONF)
+               Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
+               February 2012,
+               <http://www.rfc-editor.org/info/rfc6470>.
+
+   [RFC6991]   Schoenwaelder, J., Ed., "Common YANG Data Types",
+               RFC 6991, DOI 10.17487/RFC6991, July 2013,
+               <http://www.rfc-editor.org/info/rfc6991>.
+
+8.2.  Informative References
+
+   [Cond]      Watsen, K., "Conditional Enablement of Configuration
+               Nodes", draft-kwatsen-conditional-enablement-00, Work in
+               Progress, February 2013.
+
+   [IEEE1588]  IEEE, "IEEE Standard for a Precision Clock
+               Synchronization Protocol for Networked Measurement and
+               Control Systems Version 2", IEEE Standard 1588.
+
+   [OneClock]  Mizrahi, T. and Y. Moses, "OneClock to Rule Them All:
+               Using Time in Networked Applications", IEEE/IFIP Network
+               Operations and Management Symposium (NOMS), 2016.
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 22]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+   [RFC5905]   Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+               "Network Time Protocol Version 4: Protocol and Algorithms
+               Specification", RFC 5905,
+               DOI 10.17487/RFC5905, June 2010,
+               <http://www.rfc-editor.org/info/rfc5905>.
+
+   [RFC5907]   Gerstung, H., Elliott, C., and B. Haberman, Ed.,
+               "Definitions of Managed Objects for Network Time Protocol
+               Version 4 (NTPv4)", RFC 5907,
+               DOI 10.17487/RFC5907, June 2010,
+               <http://www.rfc-editor.org/info/rfc5907>.
+
+   [RFC6020]   Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+               the Network Configuration Protocol (NETCONF)",
+               RFC 6020, DOI 10.17487/RFC6020, October 2010,
+               <http://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6242]   Wasserman, M., "Using the NETCONF Protocol over Secure
+               Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
+               <http://www.rfc-editor.org/info/rfc6242>.
+
+   [RFC6243]   Bierman, A. and B. Lengyel, "With-defaults Capability for
+               NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011,
+               <http://www.rfc-editor.org/info/rfc6243>.
+
+   [RFC6536]   Bierman, A. and M. Bjorklund, "Network Configuration
+               Protocol (NETCONF) Access Control Model", RFC 6536, DOI
+               10.17487/RFC6536, March 2012,
+               <http://www.rfc-editor.org/info/rfc6536>.
+
+   [RFC7317]   Bierman, A. and M. Bjorklund, "A YANG Data Model for
+               System Management", RFC 7317, DOI 10.17487/RFC7317,
+               August 2014, <http://www.rfc-editor.org/info/rfc7317>.
+
+   [RFC7384]   Mizrahi, T., "Security Requirements of Time Protocols in
+               Packet Switched Networks", RFC 7384,
+               DOI 10.17487/RFC7384, October 2014,
+               <http://www.rfc-editor.org/info/rfc7384>.
+
+   [Time4]     Mizrahi, T. and Y. Moses, "Software Defined Networks:
+               It's About Time", IEEE INFOCOM, 2016.
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 23]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+Appendix A.  YANG Module for the Time Capability
+
+   This section is normative.
+
+<CODE BEGINS> file "ietf-netconf-time@2016-01-26.yang"
+
+module ietf-netconf-time {
+
+   namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-time";
+
+   prefix nct;
+   import ietf-netconf { prefix nc; }
+
+   import ietf-yang-types { prefix yang; }
+
+   import ietf-netconf-monitoring { prefix ncm; }
+
+   organization
+     "IETF";
+
+   contact
+     "Editor: Tal Mizrahi
+         <dew@tx.technion.ac.il>
+      Editor: Yoram Moses
+         <moses@ee.technion.ac.il>";
+
+   description
+     "This module defines a capability-based extension to the
+      Network Configuration Protocol (NETCONF) that allows
+      time-triggered configuration and management operations.
+      This extension allows NETCONF clients to invoke configuration
+      updates according to scheduled times and allows NETCONF
+      servers to attach timestamps to the data they send to NETCONF
+      clients.
+
+      Copyright (c) 2016 IETF Trust and the persons identified as
+      the authors of the code.  All rights reserved.
+
+      Redistribution and use in source and binary forms, with or
+      without modification, is permitted pursuant to, and subject
+      to the license terms contained in, the Simplified BSD License
+      set forth in Section 4.c of the IETF Trust's Legal Provisions
+      Relating to IETF Documents
+      (http://trustee.ietf.org/license-info).";
+
+   revision 2016-01-26 {
+     description
+       "Initial version.";
+
+
+
+Mizrahi & Moses               Experimental                     [Page 24]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+     reference
+       "RFC 7758:
+        Time Capability in NETCONF";
+   }
+
+   typedef time-interval {
+     type string {
+       pattern '\d{2}:\d{2}:\d{2}(\.\d+)?';
+     }
+     description
+       "Defines a time interval, up to 24 hours.
+        The format is specified as HH:mm:ss.f,
+        consisting of two digits for hours,
+        two digits for minutes, two digits
+        for seconds, and zero or more digits
+        representing second fractions.";
+   }
+
+   grouping scheduling-tolerance-parameters {
+     leaf sched-max-future {
+       type time-interval;
+       default 00:00:15.0;
+       description
+         "When the scheduled time is in the future, i.e., greater
+          than the present time, this leaf defines the maximal
+          difference between the scheduled time
+          and the present time that the server is willing to
+          accept.  If the difference exceeds this number, the
+          server responds with an error.";
+     }
+
+     leaf sched-max-past {
+       type time-interval;
+       default 00:00:15.0;
+       description
+         "When the scheduled time is in the past, i.e., less
+          than the present time, this leaf defines the maximal
+          difference between the present time
+          and the scheduled time that the server is willing to
+          accept.  If the difference exceeds this number, the
+          server responds with an error.";
+     }
+
+     description
+       "Contains the parameters of the scheduling tolerance.";
+   }
+   // extending the get-config operation
+   augment /nc:get-config/nc:input {
+
+
+
+Mizrahi & Moses               Experimental                     [Page 25]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <get-config>.";
+   }
+
+   augment /nc:get-config/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <get-config>.";
+   }
+
+   augment /nc:get/nc:input {
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <get>.";
+   }
+
+   augment /nc:get/nc:output {
+     leaf execution-time {
+
+
+
+Mizrahi & Moses               Experimental                     [Page 26]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <get>.";
+   }
+
+   augment /nc:copy-config/nc:input {
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <copy-config>.";
+   }
+
+   augment /nc:copy-config/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <copy-config>.";
+   }
+
+   augment /nc:edit-config/nc:input {
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+
+
+
+Mizrahi & Moses               Experimental                     [Page 27]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <edit-config>.";
+   }
+
+   augment /nc:edit-config/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <edit-config>.";
+   }
+
+   augment /nc:delete-config/nc:input {
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+      "Adds the time element to <delete-config>.";
+   }
+
+   augment /nc:delete-config/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+     description
+       "Adds the time element to <delete-config>.";
+   }
+
+   augment /nc:lock/nc:input {
+
+
+
+Mizrahi & Moses               Experimental                     [Page 28]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <lock>.";
+   }
+   augment /nc:lock/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <lock>.";
+   }
+
+   augment /nc:unlock/nc:input {
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <unlock>.";
+   }
+
+   augment /nc:unlock/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+
+
+
+Mizrahi & Moses               Experimental                     [Page 29]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <unlock>.";
+   }
+   augment /nc:commit/nc:input {
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+
+     leaf get-time {
+       type empty;
+       description
+         "Indicates that the rpc-reply should include the
+          execution-time.";
+     }
+
+     description
+       "Adds the time element to <commit>.";
+   }
+
+   augment /nc:commit/nc:output {
+     leaf execution-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC was executed.";
+     }
+
+     description
+       "Adds the time element to <commit>.";
+   }
+
+   augment /ncm:netconf-state {
+     container scheduling-tolerance {
+       uses scheduling-tolerance-parameters;
+       description
+         "The scheduling tolerance when the time capability
+          is enabled.";
+     }
+     description
+       "The scheduling tolerance of the server.";
+   }
+
+   rpc cancel-schedule {
+
+
+
+Mizrahi & Moses               Experimental                     [Page 30]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+     description
+       "Cancels a scheduled message.";
+     reference
+       "RFC 7758:
+        Time Capability in NETCONF";
+
+     input {
+       leaf cancelled-message-id {
+         type string;
+         description
+           "The ID of the message to be cancelled.";
+       }
+       leaf get-time {
+         type empty;
+         description
+           "Indicates that the rpc-reply should include
+            the execution-time.";
+       }
+     }
+     output {
+       leaf execution-time {
+         type yang:date-and-time;
+         description
+           "The time at which the RPC was executed.";
+       }
+     }
+   }
+
+   notification netconf-scheduled-message {
+     leaf schedule-id {
+       type string;
+       description
+         "The ID of the scheduled message.";
+     }
+
+     leaf scheduled-time {
+       type yang:date-and-time;
+       description
+         "The time at which the RPC is scheduled to be performed.";
+     }
+     description
+       "Indicates that a scheduled message was received.";
+     reference
+       "RFC 7758:
+        Time Capability in NETCONF";
+   }
+
+}
+
+
+
+Mizrahi & Moses               Experimental                     [Page 31]
+
+RFC 7758               Time Capability in NETCONF          February 2016
+
+
+<CODE ENDS>
+
+Acknowledgments
+
+   The authors gratefully acknowledge Joe Marcus Clarke, Andy Bierman,
+   Balazs Lengyel, Jonathan Hansford, John Heasley, Robert Sparks, Al
+   Morton, Olafur Gudmundsson, Juergen Schoenwaelder, Joel Jaeggli, Alon
+   Schneider, and Eylon Egozi for their insightful comments.
+
+   This work was supported in part by Israel Science Foundation grant
+   ISF 1520/11.
+
+Authors' Addresses
+
+   Tal Mizrahi
+   Department of Electrical Engineering
+   Technion - Israel Institute of Technology
+   Technion City, Haifa, 32000
+   Israel
+
+   Email: dew@tx.technion.ac.il
+
+
+   Yoram Moses
+   Department of Electrical Engineering
+   Technion - Israel Institute of Technology
+   Technion City, Haifa, 32000
+   Israel
+
+   Email: moses@ee.technion.ac.il
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi & Moses               Experimental                     [Page 32]
+