[要約] RFC 7758はNETCONFプロトコルにおける時間機能の要件を定義し、デバイスの時刻設定や同期に関するガイドラインを提供する。目的は、ネットワークデバイスの時刻管理を効率化し、正確な時刻情報の取得と同期を実現すること。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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の：time機能を定義します。この拡張により、クライアントは送信する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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
NETCONF Network Configuration Protocol
NETCONFネットワーク構成プロトコル
RPC Remote Procedure Call
RPCリモートプロシージャコール
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の実行を完了してから<rpc-reply>メッセージを送信するまでの時間として定義されます。
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:
：time機能は、2つの主要な機能を提供します。
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で示されているscheduled-time要素が含まれる場合があります（MAY）。次に、サーバーはRPCを予定時刻Tsに実行します。完了すると、サーバーは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 -----------------------------
Figure 1: Scheduled RPC
図1：スケジュールされたRPC
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 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.
例2.多くのアプリケーションでは、イベントを監視するか、共通の時間参照に関する統計を収集することが望ましいです。クライアントは、同時に複数のサーバーで実行されるようにスケジュールされたget-configメッセージのセットを送信して、サーバーの状態をシステム全体で同時に表示できます。さらに、クライアントは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番目のシナリオもサポートできることを示しています（図3）。この場合、クライアントは、スケジュールされた時間Tsとget-time要素を含むRPCを呼び出します。これにより、クライアントは実際の実行時間Teに関するフィードバックを受け取ることができます。理想的には、Ts = Teです。ただし、サーバーがTsで他のタスクと関連付けられている場合など、サーバーはRPCをTsとは少し異なる時間に実行する可能性があります。
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-scheduled-message通知を定義しています。これは、スケジュールされた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-scheduled-message>通知は、NETCONF通知[RFC6470]にサブスクライブされている場合、クライアントに送信されます。図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 -----------------------------
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を使用して、すべてのサーバーが調整された手順を実行できます。この手順では、すべてのサーバーがスケジュールどおりに操作を実行するか、操作が中止されます。
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.クライアントは、スケジュールされた<rpc>メッセージをサーバー1とサーバー2に送信します。どちらも時刻Tsに実行されるようにスケジュールされています。サーバー1はRPCを正常にスケジュールしたことを示す通知を送信し、サーバー2は時間機能をサポートしていないことを示す不明な要素のエラー[RFC6241]で応答します。クライアントは<cancel-schedule> RPCをサーバー1に送信し、<rpc-reply>を受信します。この例のクライアントとサーバー1間のメッセージ交換を図5に示します。
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には、scheduled-timeパラメータを含めてはなりません（MUST NOT）。 <cancel-schedule> RPCを受信したサーバーは、できるだけ早くスケジュールをキャンセルしようとする必要があります。たとえば、すでに実行されているためにサーバーがスケジュールされたRPCをキャンセルできない場合、サーバーは<rpc-error> [RFC6241]で応答する必要があります。この場合、エラータイプは「プロトコル」、エラーはタグは「操作失敗」です。
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を実行する精度に2つの要因が影響することに注意してください。1つ目の要因は、クライアントとサーバーの同期に使用されるクロック同期方法の精度であり、2つ目の要因は、リアルタイムの構成変更を実行するサーバーの能力です。実装方法によって異なります。一般的なネットワークデバイスは、ハードウェアとソフトウェアの組み合わせによって実装されます。ハードウェアモジュールの実行時間は通常、高レベルの精度で予測できますが、ソフトウェアモジュールの実行時間は変動する可能性があり、予測が難しい場合があります。構成の更新には、通常、サーバーのソフトウェアが関与する必要があるため、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 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.
同期のもう1つの重要な側面は監視です。クライアントは、サーバーが基準時刻ソースと同期しているかどうかを確認できる必要があります。ネットワークタイムプロトコル[RFC5905]などの一般的な同期プロトコルは、管理情報ベース（MIB）に問い合わせることにより、クロックが時間参照に同期していることを確認する手段（[RFC5907]、[RFC7317]）を提供します。このドキュメントで定義されているget-time機能（図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の開始時間を指し、実行時間は常にその完了時間を指します。
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 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
<------------> <---------------->
sched-max-past sched-max-future
<------------------------------->
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-pastの2つのパラメーターによって決定されます。これらの2つのパラメーターは時間間隔形式（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が送信されてから実行がスケジュールされている時間までの長い期間中に、以下の誤ったイベントが発生することがあります。
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-max-future値を設定する際のトレードオフ
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秒に定義されています。この期間は、スケジュールされたRPCがクライアントによって送信され、場合によっては複数のサーバーに送信され、セクション3.2で説明されているように、キャンセルメッセージを送信するのに十分な長さです。一方、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.";
}
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;
}
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:
：time機能を実装するサーバー：
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.
時間能力YANGモジュール（付録A）はデフォルト値を使用します。したがって、デフォルト設定機能[RFC6243]がサポートされていると想定されます。
The :time capability is identified by the following capability string:
：time機能は、次の機能文字列によって識別されます。
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には、キャンセルする必要があるスケジュールされたRPCのメッセージIDを指定する<cancelled-message-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>要素を含めることができます（MAY）。この場合、<rpc-reply>には<execution-time>要素が含まれ、スケジュールされたRPCがキャンセルされた時刻を指定します。
The :time capability defined in this memo can be applied to any of the following operations:
このメモで定義されている：time機能は、次の操作のいずれにも適用できます。
o get-config
o get-config
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:
これらの各操作に3つの新しい要素が追加されます。
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>メッセージには、サーバーが対応する<rpc-reply>に<execution-time>要素を含めなければならないことを示す<get-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>には<execution-time>要素が含まれる場合があります。 ：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.
サーバーが同時に実行するようにスケジュールされた2つ以上の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-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-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-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].
一般的なNETCONFプロトコルのセキュリティに関する考慮事項は、[RFC6241]で説明されています。
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を送信できます。別の可能性のある攻撃は、スケジュールされた多数のRPCをNETCONFサーバーに送信することで、サーバーのバッファーがオーバーフローする可能性があります。これらの攻撃は、慎重に設計された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で指定されているように、新しいYANGモジュールを定義します。
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.
このメモで定義されているYANGモジュールは、NETCONFプロトコル[RFC6241]を介してアクセスされるように設計されています。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、必須から実装までのセキュアなトランスポートはセキュアシェル（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 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.
このYANGモジュールは、<sched-max-future>および<sched-max-past>を定義します。これらは、書き込み可能/作成可能/削除可能です。これらのデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。攻撃者はこれらのパラメータを悪意を持って低い値に設定しようとする可能性があり、それによりすべてのスケジュールされた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.
このYANGモジュールは、<cancel-schedule> RPCを定義します。このRPCは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。 <schedule-id>の値はサーバーからの通知をサブスクライブしているすべてのクライアントに知られているため、<cancel-schedule> RPCは悪意を持って使用され、保留中のRPCをキャンセルすることでサーバーを攻撃する可能性があります。この攻撃は2つの層で対処されます：（i）トランスポート層のセキュリティ、攻撃をサーバーとの安全なセッションを正常に開始したクライアントにのみ制限し、（ii）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
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
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]で定義されている「YANG Module Names」レジストリに登録されています。
name: ietf-netconf-time
名前：ietf-netconf-time
prefix: nct
接頭辞：nct
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-time
RFC: 7758
RFC：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。、「The IETF XML Registry」、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。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（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。、「Network Configuration Protocol（NETCONF）Base Notifications」、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] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年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。、「Conditional Enablement of Configuration Nodes」、draft-kwatsen-conditional-enablement-00、Work in Progress、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、「ネットワーク化された測定および制御システムバージョン2の高精度クロック同期プロトコルのIEEE標準」、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]ミズラヒ、T。およびY.モーゼス、「OneClockがすべてを支配する：ネットワークアプリケーションでの時間の使用」、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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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。、編、「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。、「Secure Shell（SSH）を介したNETCONFプロトコルの使用」、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、「Network Configuration Protocol（NETCONF）Access Control Model」、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、「システム管理のためのYANGデータモデル」、RFC 7317、DOI 10.17487 / RFC7317、2014年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]ミズラヒ、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]ミズラヒ、T。およびY.モーゼス、「ソフトウェア定義ネットワーク：時間について」、IEEE INFOCOM、2016年。
This section is normative.
このセクションは規範的です。
<CODE BEGINS> file "ietf-netconf-time@2016-01-26.yang"
module ietf-netconf-time {
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";
組織「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.
説明「このモジュールは、ネットワーク構成プロトコル（NETCONF）の機能ベースの拡張機能を定義します。これにより、時間トリガー構成と管理操作が可能になります。この拡張機能により、NETCONFクライアントはスケジュールされた時間に従って構成更新を呼び出し、NETCONFサーバーがタイムスタンプをNETCONFクライアントに送信するデータ。
Copyright (c) 2016 IETF Trust and the persons identified as the authors of the code. All rights reserved.
Copyright（c）2016 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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に記載されているSimplified BSD Licenseに準拠し、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info） ";
revision 2016-01-26 {
description
"Initial version.";
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 {
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 {
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
"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 {
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;
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 {
rpc cancel-schedule {
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";
}
}
｝
<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 Schoenwaelder、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
タルミズラヒ電気工学技術部-イスラエル工科大学テクニオンシティ、ハイファ、32000イスラエル
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