Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7758 Y. Moses
Category: Experimental Technion
ISSN: 2070-1721 February 2016
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
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.
本文档定义了网络配置协议（NETCONF）的基于功能的扩展，允许时间触发的配置和管理操作。此扩展允许NETCONF客户端根据计划的时间调用配置更新，并允许NETCONF服务器将时间戳附加到发送给NETCONF客户端的数据上。
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.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7758.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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).
[RFC6241]中定义的网络配置协议（NETCONF）提供了安装、操作和删除网络设备配置的机制。NETCONF允许客户端使用远程过程调用（RPC）配置和监视NETCONF服务器。
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.
NETCONF是异步的；当客户端调用RPC时，它无法控制RPC的执行时间，也无法从服务器获得有关执行时间的任何反馈。
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.
基于时间的配置（[OneClock][Time4]）是一个有用的工具，可以支持整个类别的协调和计划配置过程。时间触发配置允许在多个设备中协调网络更新；客户端可以通过使用相同的计划执行时间将RPC发送到多个服务器来调用协调的配置更改。客户端还可以通过发送具有n个不同更新时间T1、T2、…、Tn的n个rpc来调用基于时间的更新序列，从而确定rpc的执行顺序。
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.
此备忘录定义了NETCONF中的：时间功能。此扩展允许客户端确定它们发送的RPC的计划执行时间。它还允许接收RPC的服务器向客户端报告其实际执行时间。
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.
NETCONF时间功能用于调度应在不久的将来执行的RPC，允许协调同步配置更改或指定配置更新顺序。基于时间的政策和远期计划（如[Cond]）不在本备忘录的范围内。
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.
此备忘录是为实验目的而定义的，它将允许社区对NETCONF时间功能进行实验。基于这一经验的经验教训，预计NETCONF工作组将能够考虑是否采用时间能力。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
NETCONF Network Configuration Protocol
网络配置协议
RPC Remote Procedure Call
远程过程调用
o Capability [RFC6241]: A functionality that supplements the base NETCONF specification.
o 功能[RFC6241]：补充基本NETCONF规范的功能。
o Client [RFC6241]: Invokes protocol operations on a server. In addition, a client can subscribe to receive notifications from a server.
o 客户端[RFC6241]：调用服务器上的协议操作。此外，客户端可以订阅以接收来自服务器的通知。
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 执行时间：RPC的执行时间定义为服务器在发送<RPC reply>消息之前完成RPC执行的时间。
o Scheduled RPC: an RPC that is scheduled to be performed at a predetermined time, which is included in the <rpc> message.
o 预定RPC：预定在预定时间执行的RPC，包含在<RPC>消息中。
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 计划时间：RPC的计划时间是由客户端确定的RPC应该启动的时间。强制执行计划时间是服务器的角色。
o Server [RFC6241]: Executes protocol operations invoked by a client. In addition, a server can send notifications to a client.
o 服务器[RFC6241]：执行客户端调用的协议操作。此外，服务器可以向客户端发送通知。
The :time capability provides two main functions:
时间功能提供两个主要功能：
o Scheduling:
o 行程安排：
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.
当客户机向服务器发送RPC时，<RPC>消息可能包括计划时间元素，如图1中的Ts所示。然后，服务器在预定时间Ts执行RPC；完成后，服务器可以使用RPC回复消息进行响应。
o Reporting:
o 报告：
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时，<RPC>消息可能包含一个get time元素（参见图2），请求服务器返回RPC的执行时间。在这种情况下，在服务器执行RPC之后，它将使用包含执行时间Te的RPC应答进行响应。
RPC _________
executed \
\/
Ts
server ---------------+------------- ----> time
/\ \
rpc / \ rpc-reply
(Ts)/ \
/ \/
client -----------------------------
RPC _________
executed \
\/
Ts
server ---------------+------------- ----> time
/\ \
rpc / \ rpc-reply
(Ts)/ \
/ \/
client -----------------------------
Figure 1: Scheduled RPC
图1：调度的RPC
RPC _________
executed \
\/
Te
server ------------+---------------- ----> time
/\ \
rpc / \ rpc-reply
(get-time)/ \ (Te)
/ \/
client -----------------------------
RPC _________
executed \
\/
Te
server ------------+---------------- ----> time
/\ \
rpc / \ rpc-reply
(get-time)/ \ (Te)
/ \/
client -----------------------------
Figure 2: Reporting the Execution Time of an RPC
图2：报告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.
例1。客户端需要在n台服务器上触发提交，以便n台服务器尽可能同时执行提交。如果没有时间功能，客户端发送n个提交消息序列；因此，每个服务器在不同的时间执行提交。通过使用时间功能，客户端可以发送预定在选定时间Ts（例如，未来5秒）发生的提交消息，从而使服务器在尽可能接近时间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
例2。在许多应用程序中，需要监视事件或收集有关公共时间参考的统计信息。客户端可以发送一组get config消息，这些消息计划在多个服务器上同时执行，从而提供
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.
服务器状态的同步系统范围视图。此外，客户机可以在其get config消息中使用get time元素，为采样的元素提供时间引用。
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.
图1和图2的场景意味着还可以支持第三个场景（图3），其中客户端调用一个RPC，该RPC包括一个调度时间Ts以及get time元素。这允许客户端接收关于实际执行时间Te的反馈。理想情况下，Ts=Te。但是，服务器可能在与Ts稍有不同的时间执行RPC，例如，如果服务器在Ts与其他任务绑定。
RPC _________
executed \
\/
Ts Te
server -------------+-+------------- ----> time
/\ \
rpc / \ rpc-reply
(Ts + get-time)/ \ (Te)
/ \/
client -----------------------------
RPC _________
executed \
\/
Ts Te
server -------------+-+------------- ----> time
/\ \
rpc / \ rpc-reply
(Ts + get-time)/ \ (Te)
/ \/
client -----------------------------
Figure 3: Scheduling and Reporting
图3：计划和报告
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.
如图1所示，在执行调度的RPC之后，服务器发送一个<RPC reply>。<rpc reply>可能在客户端发送rpc后很长一段时间内到达，使客户端无法清楚指示是否收到了rpc。
This document defines a new notification, the netconf-scheduled-message notification, which provides an immediate acknowledgement of the scheduled RPC.
本文档定义了一个新的通知，即netconf计划消息通知，它提供了对计划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.
如果订阅了netconf通知[RFC6470]，则会向客户端发送<netconf scheduled message>通知；如图4所示，当服务器接收到调度的RPC时，它会向客户端发送通知。
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}.
<netconf scheduled message>通知包含一个<schedule id>元素。<schedule id>是服务器分配给其接收的每个计划RPC的唯一标识符。因此，客户端可以跟踪所有挂起的预定RPC；客户端可以通过元组{server，schedule id}唯一地标识调度的RPC。
RPC ____________
executed \
\/
Ts
server -------------------+--------- ----> time
/\ \ \
rpc / \notifi- \ rpc-reply
(Ts)/ \cation \
/ \/ \/
client -----------------------------
RPC ____________
executed \
\/
Ts
server -------------------+--------- ----> time
/\ \ \
rpc / \notifi- \ rpc-reply
(Ts)/ \cation \
/ \/ \/
client -----------------------------
Figure 4: Scheduled RPC with Notification
图4：带有通知的计划RPC
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.
客户端可以通过发送<cancel schedule>RPC来取消计划的RPC。<cancel schedule>RPC包括需要取消的计划RPC的<schedule id>。
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.
本文档中定义的<cancel schedule>RPC可用于执行协调的all或none过程，其中所有服务器按计划执行操作或中止操作。
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.
例3。客户端向服务器1和服务器2发送计划的<rpc>消息，这两个消息都计划在Ts时执行。服务器1发送通知，指示它已成功计划rpc，而服务器2则回复未知元素错误[RFC6241]，指示它不支持时间功能。客户端向服务器1发送<cancel schedule>RPC并接收<RPC reply>。本例中客户端和服务器1之间的消息交换如图5所示。
RPC not __________
executed \
\/
Ts
server --------------------------------+--- ----> time
/\ \ /\ \
rpc / \notifi- /cancel- \ rpc-reply
(Ts)/ \cation /schedule \
/ \/ / \/
client ------------------------------------
RPC not __________
executed \
\/
Ts
server --------------------------------+--- ----> time
/\ \ /\ \
rpc / \notifi- /cancel- \ rpc-reply
(Ts)/ \cation /schedule \
/ \/ / \/
client ------------------------------------
Figure 5: Cancellation Message
图5：取消消息
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'.
<cancel schedule>RPC不能包含计划时间参数。接收到<cancel schedule>RPC的服务器应尽快尝试取消该计划。例如，如果服务器无法取消计划的RPC，因为它已被执行，则它应以<RPC error>[RFC6241]响应，其中错误类型为“protocol”，错误标记为“operation failed”。
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].
本文档中定义的时间功能要求客户端和服务器维护时钟。假设时钟通过本文件范围之外的方法同步，例如[RFC5905]或[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.
本文件未定义与执行计划RPC的准确度相关的任何要求。请注意，有两个因素会影响服务器执行计划RPC的准确性：一个因素是用于同步客户端和服务器的时钟同步方法的准确性，第二个因素是服务器执行实时配置更改的能力，这在很大程度上取决于如何实现。典型的网络设备是通过硬件和软件的结合来实现的。虽然硬件模块的执行时间通常可以高精度地预测，但软件模块的执行时间可能是可变的且难以预测。配置更新通常需要涉及服务器的软件，从而影响RPC调度的准确性。
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
同步的另一个重要方面是监视；客户端应该能够检查服务器是否与参考时间源同步。典型的同步协议，例如网络时间协议[RFC5905]，提供了通过查询时钟的管理信息库（MIB）来验证时钟是否与时间基准同步的方法（[RFC5907]，[RFC7317]）。时间
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.
此文档中定义的特性（参见图2）允许客户机获得客户机时钟和服务器时钟之间时间偏移的粗略估计。
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.
由于服务器不会立即执行配置更改，因此不应忽略RPC的处理时间。计划时间始终指RPC的开始时间，执行时间始终指RPC的完成时间。
The scheduled time and execution time fields in <rpc> messages use a common time format field.
<rpc>消息中的计划时间和执行时间字段使用公共时间格式字段。
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].
本文件中使用的时间格式为[RFC3339]第5.6节和[RFC6991]第3节中定义的日期和时间格式。
leaf scheduled-time {
type yang:date-and-time;
description
"The time at which the RPC is scheduled to be performed.";
}
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.";
}
leaf execution-time {
type yang:date-and-time;
description
"The time at which the RPC was executed.";
}
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.
当客户端向Ts发送计划的RPC时，服务器必须验证Ts值在过去或将来是否过远。如图6所示，服务器验证Ts是否在调度容差范围内。
RPC _________
received \
\/
Ts
-----+--------------+-----+------------+-------> time
RPC _________
received \
\/
Ts
-----+--------------+-----+------------+-------> time
<------------> <---------------->
sched-max-past sched-max-future
<------------> <---------------->
sched-max-past sched-max-future
<------------------------------->
scheduling tolerance
<------------------------------->
scheduling tolerance
Figure 6: Scheduling Tolerance
图6：调度容差
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.
调度容差由两个参数确定：sched max future和sched max pass。这两个参数使用时间间隔格式（第3.7节），其默认值为15秒。
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.
如果调度时间Ts在调度容差范围内，则执行调度RPC；如果Ts发生在过去并且在调度容差内，则服务器将尽快执行RPC；而如果Ts是将来的时间，则服务器将在Ts处执行RPC。
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.
如果Ts不在计划容差范围内，则计划的RPC将被丢弃，服务器将响应错误消息[RFC6241]，其中包括错误元素错误标记。第5.3节提供了一个示例。
The scheduling bound defined by sched-max-future guarantees that every scheduled RPC is restricted to a scheduling time in the near future.
sched max future定义的调度界限保证每个调度的RPC在不久的将来被限制在一个调度时间内。
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.
示例1是使用近期调度的典型示例；示例中的目标是同时在多个服务器上执行RPC；因此，最好将RPC安排在未来几秒钟内执行。
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:
当计划在遥远的将来执行RPC时，在发送RPC的时间和计划执行RPC的时间之间的很长时间内，可能会发生以下错误事件：
o The server may restart.
o 服务器可能会重新启动。
o The client's authorization level may be changed.
o 客户端的授权级别可能会更改。
o The client may restart and send a conflicting RPC.
o 客户端可能会重新启动并发送冲突的RPC。
o A different client may send a conflicting RPC.
o 不同的客户端可能发送冲突的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.
近期计划保证外部事件（如上述示例）在sched max future期间发生的概率较低，即使发生，不一致的时间也仅限于sched max future，这是一个较短的时间段。
The Trade-off in Setting the sched-max-future Value
设置sched最大未来值时的权衡
The sched-max-future parameter should be configured to a value that is high enough to allow the client to:
sched max future参数应配置为足够高的值，以允许客户端：
1. Send the scheduled RPC, potentially to multiple servers.
1. 发送计划的RPC，可能会发送到多个服务器。
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.
2. 接收来自服务器的通知或<rpc error>消息，或等待超时，并确定如果没有响应，则表示出现问题。
3. If necessary, send a cancellation message, potentially to multiple servers.
3. 如有必要，发送取消消息，可能会发送到多个服务器。
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.
另一方面，sched max future应配置为一个足够低的值，以允许上述错误事件的低概率，通常为几秒钟。请注意，即使sched max future配置为低值，仍有可能（以低概率）发生错误事件。然而，这一短暂的潜在危险期并不比传统（计划外）RPC严重，因为在某些情况下，即使是传统RPC也可能在客户端发送几秒钟后执行。
The Default Value of sched-max-future
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.
sched max future的默认值定义为15秒。如第3.2节所述，此持续时间足够长，以允许客户端将计划的RPC发送到多个服务器，并在某些情况下发送取消消息。另一方面，15秒的持续时间导致重新启动或权限更改的可能性非常低。
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.";
}
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:
sched max future参数定义为时间间隔（附录A），如下所示：
leaf sched-max-future {
type time-interval;
default 00:00:15.0;
}
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.
为sched max future指定的默认值为0小时、0分钟和15秒。
The structure of this section is as defined in Appendix D of [RFC6241].
本节的结构如[RFC6241]附录D所述。
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 必须支持接收包含时间元素的<rpc>消息，并相应地执行时间触发的操作。
o MUST support the ability to include a time element in the <rpc-reply> messages that it transmits.
o 必须支持在其传输的<rpc reply>消息中包含时间元素的功能。
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.
时间能力模块（附录A）使用默认值；因此，假设支持带默认值的功能[RFC6243]。
The :time capability is identified by the following capability string:
时间能力由以下能力字符串标识：
urn:ietf:params:netconf:capability:time:1.0
urn:ietf:params:netconf:capability:time:1.0
<cancel-schedule>
<取消日程>
The <cancel-schedule> RPC is used for cancelling an RPC that was previously scheduled.
<cancel schedule>RPC用于取消以前计划的RPC。
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.
<cancel schedule>RPC必须包含<cancelled message id>元素，该元素指定需要取消的调度RPC的消息id。
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.
<cancel schedule>RPC可能包含<get time>元素。在这种情况下，<rpc reply>包含<execution time>元素，指定计划的rpc被取消的时间。
The :time capability defined in this memo can be applied to any of the following operations:
本备忘录中定义的：时间功能可应用于以下任何操作：
o get-config
o 获取配置
o get
o 收到
o copy-config
o 复制配置
o edit-config
o 编辑配置
o delete-config
o 删除配置
o lock
o 锁
o unlock
o 解锁
o commit
o 犯罪
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.
o <scheduled time>此元素添加到每个操作的输入中，指示服务器计划调用该操作的时间。每个<rpc>消息都可能包含<scheduled time>元素。支持：time功能并接收带有<scheduled time>元素的<rpc>消息的服务器必须在尽可能接近计划时间的情况下执行操作。
The <scheduled-time> element uses the date-and-time format (Section 3.4.).
<scheduled time>元素使用日期和时间格式（第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 <get time>此元素添加到每个操作的输入中。<rpc>消息可能包含<get time>元素，指示服务器必须在其相应的<rpc reply>中包含<execution time>元素。
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.
o <execution time>此元素添加到每个操作的输出中，指示服务器完成操作的时间。<rpc reply>可以包括<executiontime>元素。支持：time功能并接收带有<get time>元素的操作的服务器必须在其响应中包含执行时间。
The <execution-time> element uses the date-and-time format (Section 3.4.).
<execution time>元素使用日期和时间格式（第3.4节）。
A server that receives a scheduled RPC MUST start executing the RPC as close as possible to its scheduled execution time.
接收计划RPC的服务器必须在尽可能接近其计划执行时间的情况下开始执行RPC。
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.
如果客户端和服务器之间的会话终止，服务器必须取消在此会话中接收的所有挂起的计划RPC。
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.
计划的RPC按其计划时间定义的顺序进行串行处理。因此，服务器根据其相应调度的顺序向调度的rpc发送<rpc reply>消息。请注意，这是对[RFC6241]中定义的行为的修改，该行为表示响应是按照接收请求的顺序发送的。与[RFC6241]的互操作性由NETCONF能力交换保证；不支持：time功能的服务器按照接收请求的顺序响应RPC。支持：time功能的服务器按接收顺序回复常规（非计划）RPC，并按计划时间顺序回复计划的RPC。
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.
如果服务器接收到计划同时执行的两个或多个RPC，则服务器将以任意顺序串行执行这些RPC。
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).
[RFC6241]第8.4节定义了确认提交能力。根据该文档，如果在超时期间（默认为600秒）内未发出确认提交，则必须恢复确认的<commit>操作。
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.
当支持时间功能，并且确认的<commit>操作与<scheduled time>元素一起使用时，确认超时必须从计划时间开始计算，即客户端从计划时间开始测量超时。
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).
以下示例通过添加时间功能扩展了[RFC6241]第7.2节中的示例。在本例中，<scheduled time>元素用于指定配置更新的计划执行时间（如图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 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>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
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).
以下示例与第5.1节中的示例类似，不同之处在于，在本示例中，客户端在其RPC中包含一个<get time>元素，服务器因此使用<execution time>元素进行响应（如图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 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>
<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>
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 error>。
<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 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>
<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>
The security considerations of the NETCONF protocol in general are discussed in [RFC6241].
[RFC6241]中讨论了NETCONF协议的一般安全注意事项。
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.
使用本文档中定义的时间功能可以帮助攻击者收集有关系统的信息，例如未来配置更改的确切时间。此外，时间元素可能允许攻击者了解有关系统性能的信息。此外，发送恶意<rpc>消息的攻击者可以利用时间功能放大其攻击；例如，通过使用相同的计划时间发送多个<rpc>消息。需要注意的是，[RFC6241]中描述的安全措施可以防止这些漏洞。
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].
时间功能依赖于底层的时间同步协议。因此，通过攻击时间协议，当使用时间功能时，攻击可能会危及NETCONF。[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.
时间功能允许攻击者通过发送计划在将来发生的恶意RPC来攻击NETCONF服务器。例如，攻击者可以发送多个计划同时执行的RPC。另一种可能的攻击是向NETCONF服务器发送大量计划的RPC，这可能导致服务器缓冲区溢出。这些攻击可以通过精心设计的NETCONF服务器来缓解；当服务器接收到超过其当前可用资源的计划RPC时，它应该用<RPC error>回复并放弃计划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.
请注意，如果检测到并撤销了攻击者，则不会执行其未来计划的RPC；如第4.5.2节所述，一旦与攻击者的会话终止，相应的计划RPC将被丢弃。
This memo defines a new YANG module, as specified in Appendix A.
本备忘录定义了附录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.
本备忘录中定义的模块旨在通过NETCONF协议[RFC6241]访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全SHell（SSH）[RFC6242]。NETCONF访问控制模型[RFC6536]提供了将特定NETCONF用户的访问限制为所有可用NETCONF协议操作和内容的预配置子集的方法。
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
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
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.
低值，从而导致丢弃所有计划的RPC。例如，如果客户端预期<sched max future>为15秒，但实际上恶意将其配置为1秒，则服务器将丢弃计划在未来5秒执行的合法计划RPC。
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.
此模块定义<cancel schedule>RPC。在某些网络环境中，此RPC可能被视为敏感或易受攻击。由于订阅服务器通知的所有客户端都知道<schedule id>的值，因此<cancel schedule>RPC可能被恶意使用，通过取消其挂起的RPC来攻击服务器。此攻击分为两层：（i）传输层的安全性，将攻击仅限于已成功启动与服务器的安全会话的客户端，以及（ii）取消RPC所需的授权级别应与调度RPC所需的级别相同，将攻击仅限于授权级别等于或高于启动计划RPC的客户端授权级别的攻击者。
The following capability identifier URN has been registered in the "Network Configuration Protocol (NETCONF) Capability URNs" registry:
以下功能标识符URN已在“网络配置协议（NETCONF）功能URN”注册表中注册：
urn:ietf:params:netconf:capability:time:1.0
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]:
以下XML名称空间URN已按照[RFC3688]中定义的格式在“IETF XML注册表”中注册：
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-time
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-time
Registrant Contact: The IESG.
注册人联系人：IESG。
XML: N/A, the requested URI is an XML namespace.
XML:N/A，请求的URI是一个XML名称空间。
The following module name has been registered in the "YANG Module Names" registry, defined in [RFC6020].
以下模块名称已在[RFC6020]中定义的“模块名称”注册表中注册。
name: ietf-netconf-time
名称：ietf网络配置时间
prefix: nct
前缀：nct
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-time
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-time
RFC: 7758
传真：7758
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<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>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<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>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<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>.
[RFC6470]Bierman，A.，“网络配置协议（NETCONF）基本通知”，RFC 6470，DOI 10.17487/RFC6470，2012年2月<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>.
[RFC6991]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年7月<http://www.rfc-editor.org/info/rfc6991>.
[Cond] Watsen, K., "Conditional Enablement of Configuration Nodes", draft-kwatsen-conditional-enablement-00, Work in Progress, February 2013.
[Cond]Watsen，K.，“配置节点的有条件启用”，draft-kwatsen-Conditional-Enablement-00，正在进行的工作，2013年2月。
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", IEEE Standard 1588.
[IEEE1588]IEEE，“网络测量和控制系统精确时钟同步协议的IEEE标准版本2”，IEEE标准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.
[OneClock]Mizrahi，T.和Y.Moses，“一个时钟控制一切：在网络应用中使用时间”，IEEE/IFIP网络运营和管理研讨会（NOMS），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>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<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>.
[RFC5907]Gerstung，H.，Elliott，C.，和B.Haberman，编辑，“网络时间协议版本4（NTPv4）的托管对象定义”，RFC 5907，DOI 10.17487/RFC5907，2010年6月<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>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<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>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<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>.
[RFC6243]Bierman，A.和B.Lengyel，“NETCONF的默认功能”，RFC 6243，DOI 10.17487/RFC6243，2011年6月<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>.
[RFC6536]Bierman，A.和M.Bjorklund，“网络配置协议（NETCONF）访问控制模型”，RFC 6536，DOI 10.17487/RFC6536，2012年3月<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>.
[RFC7317]Bierman，A.和M.Bjorklund，“系统管理的杨数据模型”，RFC 7317，DOI 10.17487/RFC73172014年8月<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>.
[RFC7384]Mizrahi，T.，“分组交换网络中时间协议的安全要求”，RFC 7384，DOI 10.17487/RFC7384，2014年10月<http://www.rfc-editor.org/info/rfc7384>.
[Time4] Mizrahi, T. and Y. Moses, "Software Defined Networks: It's About Time", IEEE INFOCOM, 2016.
[Time4]Mizrahi，T.和Y.Moses，“软件定义网络：是时候了”，IEEE INFOCOM，2016年。
This section is normative.
本节是规范性的。
<CODE BEGINS> file "ietf-netconf-time@2016-01-26.yang"
<CODE BEGINS> file "ietf-netconf-time@2016-01-26.yang"
module ietf-netconf-time {
模块ietf网络配置时间{
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-time";
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-time";
prefix nct;
import ietf-netconf { prefix nc; }
prefix nct;
import ietf-netconf { prefix nc; }
import ietf-yang-types { prefix yang; }
import ietf-yang-types { prefix yang; }
import ietf-netconf-monitoring { prefix ncm; }
import ietf-netconf-monitoring { prefix ncm; }
organization "IETF";
“IETF”组织；
contact
"Editor: Tal Mizrahi
<dew@tx.technion.ac.il>
Editor: Yoram Moses
<moses@ee.technion.ac.il>";
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.
description“此模块定义了网络配置协议（NETCONF）的基于功能的扩展允许时间触发的配置和管理操作。此扩展允许NETCONF客户端根据计划的时间调用配置更新，并允许NETCONF服务器将时间戳附加到发送给NETCONF客户端的数据上。
Copyright (c) 2016 IETF Trust and the persons identified as the authors of the code. All rights reserved.
版权所有（c）2016 IETF信托基金和被确定为代码作者的人员。版权所有。
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).";
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(http://trustee.ietf.org/license-info).";
revision 2016-01-26 {
description
"Initial version.";
revision 2016-01-26 {
description
"Initial version.";
reference
"RFC 7758:
Time Capability in NETCONF";
}
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.";
}
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.";
}
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.";
}
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 {
description
"Contains the parameters of the scheduling tolerance.";
}
// extending the get-config operation
augment /nc:get-config/nc:input {
leaf scheduled-time {
type yang:date-and-time;
description
"The time at which the RPC is scheduled to be performed.";
}
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.";
}
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <get-config>.";
}
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.";
}
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>.";
}
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.";
}
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.";
}
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <get>.";
}
description
"Adds the time element to <get>.";
}
augment /nc:get/nc:output {
leaf execution-time {
augment /nc:get/nc:output {
leaf execution-time {
type yang:date-and-time;
description
"The time at which the RPC was executed.";
}
type yang:date-and-time;
description
"The time at which the RPC was executed.";
}
description
"Adds the time element to <get>.";
}
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.";
}
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.";
}
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <copy-config>.";
}
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.";
}
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>.";
}
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.";
}
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
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <edit-config>.";
}
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.";
}
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>.";
}
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.";
}
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.";
}
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <delete-config>.";
}
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: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 {
augment /nc:lock/nc:input {
leaf scheduled-time {
type yang:date-and-time;
description
"The time at which the RPC is scheduled to be performed.";
}
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.";
}
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: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>.";
}
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.";
}
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.";
}
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <unlock>.";
}
description
"Adds the time element to <unlock>.";
}
augment /nc:unlock/nc:output {
leaf execution-time {
type yang:date-and-time;
augment /nc:unlock/nc:output {
leaf execution-time {
type yang:date-and-time;
description
"The time at which the RPC was executed.";
}
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.";
}
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.";
}
leaf get-time {
type empty;
description
"Indicates that the rpc-reply should include the
execution-time.";
}
description
"Adds the time element to <commit>.";
}
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.";
}
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>.";
}
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.";
}
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 {
rpc取消计划{
description
"Cancels a scheduled message.";
reference
"RFC 7758:
Time Capability in NETCONF";
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.";
}
}
}
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.";
}
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";
}
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";
}
}
}
<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.
作者感谢Joe Marcus Clarke、Andy Bierman、Balazs Lengyel、Jonathan Hansford、John Heasley、Robert Sparks、Al Morton、Olafur Gudmundsson、Juergen Schoenwaeld、Joel Jaeggli、Alon Schneider和Eylon Egozi发表的见解。
This work was supported in part by Israel Science Foundation grant ISF 1520/11.
这项工作得到了以色列科学基金资助ISF 1520/11的支持。
Authors' Addresses
作者地址
Tal Mizrahi Department of Electrical Engineering Technion - Israel Institute of Technology Technion City, Haifa, 32000 Israel
Tal Mizrahi电气工程技术系-以色列理工学院技术城，海法，32000以色列
Email: dew@tx.technion.ac.il
Email: dew@tx.technion.ac.il
Yoram Moses Department of Electrical Engineering Technion - Israel Institute of Technology Technion City, Haifa, 32000 Israel
约拉姆·摩西电气工程技术系-以色列理工学院技术城，以色列海法，32000
Email: moses@ee.technion.ac.il
Email: moses@ee.technion.ac.il