RFC5277 日本語訳
5277 NETCONF Event Notifications. S. Chisholm, H. Trevino. July 2008. (Format: TXT=70878 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Chisholm
Request for Comments: 5277 Nortel
Category: Standards Track H. Trevino
Cisco
July 2008
コメントを求めるワーキンググループS.チスホルム要求をネットワークでつないでください: 5277年のノーテルカテゴリ: 標準化過程H.トレビノコクチマス2008年7月
NETCONF Event Notifications
NETCONFイベント通知
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service.
このドキュメントはNetwork Configurationプロトコル(NETCONF)に非同期なメッセージ通知デリバリ・サービスを提供するメカニズムを定義します。 これはベースNETCONF定義の上で築き上げられた任意の能力です。 このドキュメントはこのサービスを支持するのに必要な能力と操作を定義します。
Chisholm & Trevino Standards Track [Page 1] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Event Notifications in NETCONF . . . . . . . . . . . . . . 5
2. Notification-Related Operations . . . . . . . . . . . . . . . 5
2.1. Subscribing to Receive Event Notifications . . . . . . . . 5
2.1.1. <create-subscription> . . . . . . . . . . . . . . . . 6
2.2. Sending Event Notifications . . . . . . . . . . . . . . . 9
2.2.1. <notification> . . . . . . . . . . . . . . . . . . . . 9
2.3. Terminating the Subscription . . . . . . . . . . . . . . . 9
3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10
3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 10
3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 10
3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 10
3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 12
3.2.2. Event Stream Content Format . . . . . . . . . . . . . 12
3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 12
3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 12
3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 12
3.3. Notification Replay . . . . . . . . . . . . . . . . . . . 15
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2. Creating a Subscription with Replay . . . . . . . . . 16
3.4. Notification Management Schema . . . . . . . . . . . . . . 16
3.5. Subscriptions Data . . . . . . . . . . . . . . . . . . . . 20
3.6. Filter Mechanics . . . . . . . . . . . . . . . . . . . . . 20
3.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 20
3.7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 20
4. XML Schema for Event Notifications . . . . . . . . . . . . . . 22
5. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 28
5.2. XPATH Filters . . . . . . . . . . . . . . . . . . . . . . 29
6. Interleave Capability . . . . . . . . . . . . . . . . . . . . 30
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Capability Identifier . . . . . . . . . . . . . . . . . . 30
6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 31
6.5. Modifications to Existing Operations . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
10. Normative References . . . . . . . . . . . . . . . . . . . . . 33
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語. . . . . . . . . . . . . . . . . . . 3 1.2の定義。 動機. . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 NETCONF. . . . . . . . . . . . . . 5 2のイベント通知。 通知関連の操作. . . . . . . . . . . . . . . 5 2.1。 イベント通知. . . . . . . . 5 2.1.1を受け取るために申し込むこと。 購読を作成している<>. . . . . . . . . . . . . . . . 6 2.2。 イベント通知. . . . . . . . . . . . . . . 9 2.2.1を送ります。 <通知>. . . . . . . . . . . . . . . . . . . . 9 2.3。 購読. . . . . . . . . . . . . . . 9 3を終えます。 概念. . . . . . . . . . . . . . . . . . . . . 10 3.1を支持します。 能力交換. . . . . . . . . . . . . . . . . . 10 3.1.1。 能力識別子. . . . . . . . . . . . . . . . 10 3.1.2。 能力の例. . . . . . . . . . . . . . . . . . 10 3.2。 出来事は.1に.103.2を流します。 イベント流れの定義. . . . . . . . . . . . . . . 12 3.2.2。 イベントの流れの満足している形式. . . . . . . . . . . . . 12 3.2.3。 デフォルトイベントの流れ. . . . . . . . . . . . . . . . . 12 3.2の.4。 イベント流れの源. . . . . . . . . . . . . . . . . 12 3.2の.5。 イベント流れの発見. . . . . . . . . . . . . . . . 12 3.3。 通知再生. . . . . . . . . . . . . . . . . . . 15 3.3.1。 概観. . . . . . . . . . . . . . . . . . . . . . . 15 3.3.2。 再生. . . . . . . . . 16 3.4との購読を作成します。 通知管理図式. . . . . . . . . . . . . . 16 3.5。 購読データ. . . . . . . . . . . . . . . . . . . . 20 3.6 整備士. . . . . . . . . . . . . . . . . . . . . 20 3.6.1をフィルターにかけてください。 .203.7をフィルターにかけます。 メッセージ流動. . . . . . . . . . . . . . . . . . . . . . . 20 4。 イベント通知. . . . . . . . . . . . . . 22 5のためのXML図式。 例. . . . . . . . . . . . . . . . . . . . . . 26 5.1をフィルターにかけます。 下位木フィルタリング. . . . . . . . . . . . . . . . . . . . 28 5.2。 XPATHは.296をフィルターにかけます。 能力. . . . . . . . . . . . . . . . . . . . 30 6.1をはさみ込んでください。 記述. . . . . . . . . . . . . . . . . . . . . . . 30 6.2。 依存. . . . . . . . . . . . . . . . . . . . . . . 30 6.3。 能力識別子. . . . . . . . . . . . . . . . . . 30 6.4。 新しい操作. . . . . . . . . . . . . . . . . . . . . . 31 6.5。 既存の操作. . . . . . . . . . . 31 7への変更。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 31 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 32 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 33 10。 引用規格. . . . . . . . . . . . . . . . . . . . . 33
Chisholm & Trevino Standards Track [Page 2] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[2ページ]。
1. Introduction
1. 序論
[NETCONF] can be conceptually partitioned into four layers:
概念的に[NETCONF]を4つの層に仕切ることができます:
Layer Example
+-------------+ +-------------------------------------------+
| Content | | Configuration data |
+-------------+ +-------------------------------------------+
| |
+-------------+ +-------------------------------------------+
| Operations | |<get-config>, <edit-config>, <notification>|
+-------------+ +-------------------------------------------+
| | |
+-------------+ +-----------------------------+ |
| RPC | | <rpc>, <rpc-reply> | |
+-------------+ +-----------------------------+ |
| | |
+-------------+ +-------------------------------------------+
| Transport | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-------------------------------------------+
層の例+-------------+ +-------------------------------------------+ | 内容| | コンフィギュレーション・データ| +-------------+ +-------------------------------------------+ | | +-------------+ +-------------------------------------------+ | 操作| |コンフィグ>、<編集コンフィグ>を手に入れている<<通知>| +-------------+ +-------------------------------------------+ | | | +-------------+ +-----------------------------+ | | RPC| | <rpc>、<rpc-回答>。| | +-------------+ +-----------------------------+ | | | | +-------------+ +-------------------------------------------+ | 輸送| | BEEP、SSH、SSL、コンソール| | プロトコル| | | +-------------+ +-------------------------------------------+
Figure 1
図1
This document defines mechanisms that provide an asynchronous message notification delivery service for the [NETCONF] protocol. This is an optional capability built on top of the base NETCONF definition. This memo defines the capabilities and operations necessary to support this service.
このドキュメントは[NETCONF]プロトコルのための非同期なメッセージ通知デリバリ・サービスを提供するメカニズムを定義します。 これはベースNETCONF定義の上で築き上げられた任意の能力です。 このメモはこのサービスを支持するのに必要な能力と操作を定義します。
1.1. Definition of Terms
1.1. 用語の定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Element: An [XML] Element.
要素: [XML]要素。
Subscription: An agreement and method to receive event notifications
over a NETCONF session. A concept related to the delivery of
notifications (if there are any to send) involving destination and
selection of notifications. It is bound to the lifetime of a
session.
購読: 協定とNETCONFセッションの間にイベント通知を受け取る方法。 概念は、通知の目的地と品揃えにかかわりながら、通知(発信するためにいずれかあれば)の配送に関連しました。 それはセッションの生涯まで縛られます。
Chisholm & Trevino Standards Track [Page 3] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[3ページ]。
Operation: This term is used to refer to NETCONF protocol operations
[NETCONF]. Within this document, operation refers to NETCONF
protocol operations defined in support of NETCONF notifications.
操作: 今期は、NETCONFプロトコル操作[NETCONF]について言及するのに使用されます。 このドキュメントの中では、操作はNETCONF通知を支持して定義されたNETCONFプロトコル操作について言及します。
Event: An event is something that happens that may be of interest -
a configuration change, a fault, a change in status, crossing a
threshold, or an external input to the system, for example.
Often, this results in an asynchronous message, sometimes referred
to as a notification or event notification, being sent to
interested parties to notify them that this event has occurred.
出来事: 出来事は何かです。興味があるかもしれないそれは起こります--構成は変化します、欠点、状態の変化、敷居、または外部の入力に例えば、システムと交差していて しばしば、これはこの出来事が起こったことを彼らに通知するために利害関係者に送られる時々通知かイベント通知と呼ばれた非同期なメッセージをもたらします。
Replay: The ability to send/re-send previously logged notifications
upon request. These notifications are sent asynchronously. This
feature is implemented by the NETCONF server and invoked by the
NETCONF client.
以下を再演してください。 以前に登録された通知を要求に送るか、または再送する能力。 これらの通知を非同期に送ります。 この特徴は、NETCONFサーバによって実行されて、NETCONFクライアントによって呼び出されます。
Stream: An event stream is a set of event notifications matching
some forwarding criteria and available to NETCONF clients for
subscription.
以下を流してください。 イベントの流れはいくつかの推進評価基準に合っているイベント通知で設定していてNETCONFクライアントにとって、購読に利用可能なaです。
Filter: A parameter that indicates which subset of all possible
events are of interest. A filter is defined as one or more filter
elements [NETCONF], each of which identifies a portion of the
overall filter.
以下をフィルターにかけてください。 すべての可能な出来事のどの部分集合が興味があるかを示すパラメタ。 フィルタは1個以上のフィルタエレメント[NETCONF]と定義されます。それはそれぞれ総合的なフィルタの一部を特定します。
1.2. Motivation
1.2. 動機
The motivation for this work is to enable the sending of asynchronous messages that are consistent with the data model (content) and security model used within a NETCONF implementation.
この仕事に関する動機はNETCONF実現の中で使用されるデータモデル(内容)と機密保護モデルと一致した非同期なメッセージの発信を可能にすることです。
The scope of the work aims at meeting the following operational needs:
仕事の範囲は以下の操作上の需要を満たすのを目的とします:
o Initial release should ensure it supports notifications in support
of configuration operations.
o 初期のリリースは、構成操作を支持して通知を支持するのを確実にするべきです。
o It should be possible to use the same data model for notifications
as for configuration operations.
o 通知に構成操作のように同じデータモデルを使用するのは可能であるべきです。
o The solution should support a reasonable message size limit (i.e.,
not too short).
o 解決策は妥当なメッセージサイズ限界(すなわち、短過ぎるというわけではない)を支持するべきです。
o The notifications should be carried over a connection-oriented
delivery mechanism.
o 通知は接続指向の排紙機構の上まで運ばれるべきです。
Chisholm & Trevino Standards Track [Page 4] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[4ページ]。
o A subscription mechanism for notifications should be provided.
This takes into account that a NETCONF server does not send
notifications before being asked to do so, and that it is the
NETCONF client who initiates the flow of notifications.
o 通知のための購読メカニズムを提供するべきです。 これはそうするように頼まれる前にNETCONFサーバが通告を送っていなくて、それが通知の流れを起こすNETCONFクライアントであることを考慮に入れます。
o A filtering mechanism for sending notifications should be put in
place within the NETCONF server.
o 通告を送るためのフィルタリングメカニズムはNETCONFサーバの中に適所に置かれるべきです。
o The information contained in a notification should be sufficient
so that it can be analyzed independent of the transport mechanism.
In other words, the data content fully describes a notification;
protocol information is not needed to understand a notification.
o 通知に含まれた情報は、移送機構の如何にかかわらずそれを分析できるくらい十分であるべきです。 言い換えれば、データ内容は通知について完全に説明します。 プロトコル情報は、通知を理解するのに必要ではありません。
o The server should have the capability to replay locally logged
notifications.
o サーバには、局所的に登録された通知を再演する能力があるべきです。
1.3. Event Notifications in NETCONF
1.3. NETCONFのイベント通知
This memo defines a mechanism whereby the NETCONF client indicates interest in receiving event notifications from a NETCONF server by creating a subscription to receive event notifications. The NETCONF server replies to indicate whether the subscription request was successful and, if it was successful, begins sending the event notifications to the NETCONF client as the events occur within the system. These event notifications will continue to be sent until either the NETCONF session is terminated or the subscription terminates for some other reason. The event notification subscription allows a number of options to enable the NETCONF client to specify which events are of interest. These are specified when the subscription is created. Note that a subscription cannot be modified once created.
このメモはNETCONFクライアントがNETCONFサーバからイベント通知を受け取るために購読を作成することによってイベント通知を受け取ることへの関心を示すメカニズムを定義します。 出来事がシステムの中に起こるのに応じて、NETCONFサーバは、購読要求がうまくいったかどうかを示すために返答して、それがうまくいったなら、イベント通知をNETCONFクライアントに送り始めます。 これらのイベント通知は、NETCONFセッションが終えられるか、または購読がある他の理由で終わるまで送られ続けるでしょう。 イベント通知購読で、多くのオプションが、NETCONFクライアントが、どのイベントが興味があるかを指定するのを可能にすることができます。 購読が作成されると、これらは指定されています。 いったん作成される後購読を変更できないことに注意してください。
The NETCONF server MUST accept and process the <close-session> operation, even while the notification subscription is active. The NETCONF server MAY accept and process other commands; otherwise, they will be rejected and the server MUST send a 'resource-denied' error. A NETCONF server advertises support of the ability to process other commands via the :interleave capability.
NETCONFサーバは、<の厳密なセッションの>操作を受け入れて、処理しなければなりませんが、通知購読は活発でさえあります。 NETCONFサーバは、他のコマンドを受け入れて、処理するかもしれません。 さもなければ、それらは拒絶されるでしょう、そして、サーバは'リソースで否定された'誤りを送らなければなりません。 NETCONFサーバは:interleave能力で他のコマンドを処理する能力のサポートの広告を出します。
2. Notification-Related Operations
2. 通知関連の操作
2.1. Subscribing to Receive Event Notifications
2.1. イベント通知を受け取るために、申し込みます。
The event notification subscription is initiated by the NETCONF client and responded to by the NETCONF server. A subscription is bound to a single stream for the lifetime of the subscription. When the event notification subscription is created, the events of interest are specified.
イベント通知購読はNETCONFクライアントによって開始されます、そして、NETCONFサーバによって応じられて. 購読は購読の生涯のためのただ一つの流れに縛られます。 イベント通知購読が作成されるとき、興味があるイベントは指定されます。
Chisholm & Trevino Standards Track [Page 5] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[5ページ]。
Content for an event notification subscription can be selected by applying user-specified filters.
ユーザによって指定されたフィルタを適用することによって、イベント通知購読のための内容を選択できます。
2.1.1. <create-subscription>
2.1.1. 購読を作成している<>。
Description:
記述:
This operation initiates an event notification subscription that
will send asynchronous event notifications to the initiator of the
command until the subscription terminates.
この操作は購読が終わるまで非同期的なイベント通知をコマンドの創始者に送るイベント通知購読を開始します。
Parameters:
パラメタ:
Stream:
以下を流してください。
An optional parameter, <stream>, that indicates which stream of
events is of interest. If not present, events in the default
NETCONF stream will be sent.
任意のパラメタ、<流れの>、それは出来事のどの流れが興味があるかを示します。 プレゼントでないなら、デフォルトNETCONFの流れにおける出来事を送るでしょう。
Filter:
以下をフィルターにかけてください。
An optional parameter, <filter>, that indicates which subset of
all possible events is of interest. The format of this
parameter is the same as that of the filter parameter in the
NETCONF protocol operations. If not present, all events not
precluded by other parameters will be sent. See section 3.6
for more information on filters.
任意のパラメタ、<フィルタ>、それはすべての可能な出来事のどの部分集合が興味があるかを示します。 このパラメタの形式はNETCONFプロトコル操作におけるフィルタパラメタのものと同じです。 プレゼントでないなら、他のパラメタによって排除されなかったすべての出来事を送るでしょう。 フィルタの詳しい情報に関してセクション3.6を見てください。
Start Time:
開始時刻:
A parameter, <startTime>, used to trigger the replay feature
and indicate that the replay should start at the time
specified. If <startTime> is not present, this is not a replay
subscription. It is not valid to specify start times that are
later than the current time. If the <startTime> specified is
earlier than the log can support, the replay will begin with
the earliest available notification. This parameter is of type
dateTime and compliant to [RFC3339]. Implementations must
support time zones.
指定されるとき、パラメタ(<startTime>)は、再生機能の引き金となって、以前はよく再生が始まるべきであるのを示していました。 <startTime>が存在していないなら、これは再生購読ではありません。 スタート時間現在の時間より後半であることを指定するのは有効ではありません。 >が指定した<startTimeがログが支持できるより初期であるなら、再生は最も初期の利用可能な通知で始まるでしょう。 このパラメタは、タイプdateTimeにはあって、[RFC3339]に言いなりになります。 実現は時間帯を支持しなければなりません。
Chisholm & Trevino Standards Track [Page 6] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[6ページ]。
Stop Time:
停止時間:
An optional parameter, <stopTime>, used with the optional
replay feature to indicate the newest notifications of
interest. If <stopTime> is not present, the notifications will
continue until the subscription is terminated. Must be used
with and be later than <startTime>. Values of <stopTime> in
the future are valid. This parameter is of type dateTime and
compliant to [RFC3339]. Implementations must support time
zones.
任意のパラメタ、示す中で興味がある通知最も新しい任意の再生機能で中古の<stopTime>。 <stopTime>が存在していないと、購読が終えられるまで、通知は続くでしょう。 使用しなければならない、<より遅いstartTime>はそうです。 <stopTime>の値は将来、有効です。 このパラメタは、タイプdateTimeにはあって、[RFC3339]に言いなりになります。 実現は時間帯を支持しなければなりません。
Positive Response:
積極的な応答:
If the NETCONF server can satisfy the request, the server sends an
<ok> element.
NETCONFサーバが要望に応じることができるなら、サーバは<の間違いない>要素を送ります。
Negative Response:
否定応答:
An <rpc-error> element is included within the <rpc-reply> if the
request cannot be completed for any reason. Subscription requests
will fail if a filter with invalid syntax is provided or if the
name of a non-existent stream is provided.
どんな理由でも要求を終了できないなら、<のrpc誤りの>要素は<rpc-回答>の中に含まれています。 無効の構文があるフィルタを提供するか、または実在しない流れの名前を提供すると、購読要求は失敗するでしょう。
If a <stopTime> is specified in a request without having specified
a <startTime>, the following error is returned:
<stopTime>が要求で<startTime>を指定していなくて指定されるなら、以下の誤りは返されます:
Tag: missing-element
以下にタグ付けをしてください。 なくなった要素
Error-type: protocol
誤りタイプ: プロトコル
Severity: error
厳しさ: 誤り
Error-info: <bad-element>: startTime
誤りインフォメーション: <の悪い要素の>: startTime
Description: An expected element is missing.
記述: 予想された要素はなくなっています。
If the optional replay feature is requested but it is not
supported by the NETCONF server, the following error is returned:
任意の再生機能が要求されていますが、それがNETCONFサーバによって支持されないなら、以下の誤りは返されます:
Tag: operation-failed
以下にタグ付けをしてください。 操作で、失敗されています。
Error-type: protocol
誤りタイプ: プロトコル
Severity: error
厳しさ: 誤り
Error-info: none
誤りインフォメーション: なし
Chisholm & Trevino Standards Track [Page 7] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[7ページ]。
Description: Request could not be completed because the
requested operation failed for some reason not covered by any
other error condition.
記述: 要求された操作がいかなる他のエラー条件でもカバーされなかった何らかの理由で失敗したので、要求は終了できませんでした。
If a <stopTime> is requested that is earlier than the specified
<startTime>, the following error is returned:
指定された<startTime>より初期の<stopTime>が要求されるなら、以下の誤りは返されます:
Tag: bad-element
以下にタグ付けをしてください。 悪い要素
Error-type: protocol
誤りタイプ: プロトコル
Severity: error
厳しさ: 誤り
Error-info: <bad-element>: stopTime
誤りインフォメーション: <の悪い要素の>: stopTime
Description: An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.
記述: 要素値は正しくはありません。 範囲から、例えば、間違ったタイプはミスマッチを型に基づいて作ります。
If a <startTime> is requested that is later than the current time,
the following error is returned:
現在の時間より遅れる<startTime>が要求されるなら、以下の誤りは返されます:
Tag: bad-element
以下にタグ付けをしてください。 悪い要素
Error-type: protocol
誤りタイプ: プロトコル
Severity: error
厳しさ: 誤り
Error-info: <bad-element>: startTime
誤りインフォメーション: <の悪い要素の>: startTime
Description: An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.
記述: 要素値は正しくはありません。 範囲から、例えば、間違ったタイプはミスマッチを型に基づいて作ります。
2.1.1.1. Usage Example
2.1.1.1. 使用例
The following demonstrates creating a simple subscription. More complex examples can be found in section 5.
以下は、簡単な購読を作成しながら、示されます。 セクション5で、より複雑な例を見つけることができます。
<netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
</create-subscription>
</netconf:rpc>
<netconf: rpcメッセージイドが「101」xmlns: netconf=と等しい、「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの>、<、購読を作成する、xmlnsは購読を」 つぼ:ietf:params:xml:ナノ秒:netconf:通知: 1インチの></作成している></netconf: rpc>と等しいです。
Chisholm & Trevino Standards Track [Page 8] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[8ページ]。
2.2. Sending Event Notifications
2.2. 送付イベント通知
Once the subscription has been set up, the NETCONF server sends the event notifications asynchronously over the connection.
購読がいったんセットアップされると、NETCONFサーバはイベント通知を接続の上に非同期に送ります。
2.2.1. <notification>
2.2.1. <通知>。
Description:
記述:
An event notification is sent to the client who initiated a
<create-subscription> command asynchronously when an event of
interest (i.e., meeting the specified filtering criteria) has
occurred. An event notification is a complete and well-formed XML
document. Note that <notification> is not a Remote Procedure Call
(RPC) method but rather the top-level element identifying the one-
way message as a notification.
興味があるイベント(すなわち、指定されたフィルタリング評価基準を満たす)が起こったとき購読を作成している<>コマンドを非同期に開始したクライアントにイベント通知を送ります。 イベント通知は完全でよく形成されたXMLドキュメントです。 >がRemote Procedure Call(RPC)方法ではなく、むしろトップレベル要素であるという1つの方法を特定する<通知が通知として通信することに注意してください。
Parameters:
パラメタ:
eventTime
eventTime
The time the event was generated by the event source. This
parameter is of type dateTime and compliant to [RFC3339].
Implementations must support time zones.
出来事がイベントソースで発生した時。 このパラメタは、タイプdateTimeにはあって、[RFC3339]に言いなりになります。 実現は時間帯を支持しなければなりません。
Also contains notification-specific tagged content, if any. With
the exception of <eventTime>, the content of the notification is
beyond the scope of this document.
また、もしあれば通知特有のタグ付けをされた内容を含んでいます。 <eventTime>を除いて、通知の内容はこのドキュメントの範囲を超えています。
Response:
応答:
No response. Not applicable.
応答がありません。 適切でない。
2.3. Terminating the Subscription
2.3. 購読を終えます。
Closing of the event notification subscription can be done by using the <close-session> operation from the subscriptions session or terminating the NETCONF session ( <kill-session> ) or the underlying transport session from another session. If a stop time is provided when the subscription is created, the subscription will terminate after the stop time is reached. In this case, the NETCONF session will still be an active session.
購読セッションから<の厳密なセッションの>操作を使用するか、またはNETCONFセッション(セッションを殺している<>)か別のセッションからの基本的な輸送セッションを終えることによって、イベント通知購読の閉鎖ができます。 購読を作成するとき、停止時間を提供すると、停止時間に達した後に購読は終わるでしょう。 この場合、NETCONFセッションはまだ活発なセッションになっているでしょう。
Chisholm & Trevino Standards Track [Page 9] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[9ページ]。
3. Supporting Concepts
3. 概念を支持します。
3.1. Capabilities Exchange
3.1. 能力交換
The ability to process and send event notifications is advertised during the capability exchange between the NETCONF client and server.
NETCONFクライアントとサーバの間の能力交換の間、イベント通知を処理して、送る能力の広告を出します。
3.1.1. Capability Identifier
3.1.1. 能力識別子
"urn:ietf:params:netconf:capability:notification:1.0"
「つぼ:ietf:params:netconf:能力:通知:1インチ」
3.1.2. Capability Example
3.1.2. 能力の例
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:xml:ns:netconf:base:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:notification:1.0
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
<、こんにちは、xmlns=、「つぼ:ietf:params:xml:ナノ秒:netconf:ベース: 1インチの><能力><能力>つぼ: ietf:params:xml:ナノ秒:netconf:ベース:1.0</能力><能力>つぼ:ietf:params:netconf:能力:始動:1.0</能力><能力>つぼ:ietf:params:netconf:能力:通知:1.0能力></能力><セッション</イド>4</セッション-イド><、こんにちは、/>、」
3.2. Event Streams
3.2. イベントの流れ
An event stream is defined as a set of event notifications matching some forwarding criteria.
イベントの流れはいくつかの推進評価基準に合っている1セットのイベント通知と定義されます。
Figure 2 illustrates the notification flow and concepts identified in this document. It does not mandate and/or preclude an implementation. The following is observed from the diagram below: System components (c1..cn) generate event notifications that are passed to a central component for classification and distribution. The central component inspects each event notification and matches the event notification against the set of stream definitions. When a match occurs, the event notification is considered to be a member of that event stream (stream 1..stream n). An event notification may be part of multiple event streams.
図2は本書では特定された通知流動と概念を例証します。 それは、実現を強制する、そして/または、排除しません。 以下は以下のダイヤグラムから観測されます: システムの部品(c1..cn)は分類と分配のために中心性成分に合格されるイベント通知を発生させます。 中心性成分は、流れの定義のセットに対してそれぞれのイベント通知を点検して、イベント通知に匹敵します。 マッチが現れるとき、イベント通知はそのイベントの流れ(流れの1..stream n)のメンバーであると考えられます。 イベント通知は複数のイベントの流れの一部であるかもしれません。
Chisholm & Trevino Standards Track [Page 10] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[10ページ]。
At some point after the NETCONF server receives the internal event from a stream, it is converted to an appropriate XML encoding by the server, and a <notification> element is ready to send to all NETCONF sessions subscribed to that stream.
NETCONFサーバが流れからの内部の出来事を受けた後に何らかのポイントでは、それはサーバでコード化する適切なXMLに変換されます、そして、<通知>要素は加入される流れるすべてのNETCONFセッションまで発信する準備ができています。
After generation of the <notification> element, access control is applied by the server. If a session does not have permission to receive the <notification>, then it is discarded for that session, and processing of the internal event is completed for that session.
<通知>要素の世代後に、アクセス管理はサーバによって適用されます。セッションに<通知>を受け取る許可がないなら、それはそのセッションのために捨てられます、そして、内部の出来事の処理はそのセッションのために終了しています。
When a NETCONF client subscribes to a given event stream, user- defined filter elements, if applicable, are applied to the event stream and matching event notifications are forwarded to the NETCONF server for distribution to subscribed NETCONF clients. A filter is transferred from the client to the server during the <create- subscription> operation and applied against each <notification> element generated by the stream. For more information on filtering, see Section 3.6.
NETCONFクライアントが与えられたイベントの流れに加入すると、適切であるなら、ユーザの定義されたフィルタエレメントをイベントの流れに適用します、そして、申し込まれたNETCONFクライアントへの分配のためのNETCONFサーバに合っているイベント通知を転送します。 購読>操作を作成していて流れで発生するそれぞれの<通知>要素に対して適用された<の間、クライアントからサーバまでフィルタを移します。 フィルタリングの詳しい情報に関しては、セクション3.6を見てください。
A notification-logging service may also be available, in which case, the central component logs notifications. The NETCONF server may later retrieve logged notifications via the optional replay feature. For more information on replay, see section 3.3.
また、通知を登録するサービスも利用可能であるかもしれない、その場合、中心性成分は通知を登録します。 NETCONFサーバは後で任意の再生機能で登録された通知を検索するかもしれません。 再生の詳しい情報に関しては、セクション3.3を見てください。
+----+
| c1 |----+ available streams
+----+ | +---------+
+----+ | |central |-> stream 1
| c2 | +--->|event |-> stream 2 filter +-------+
+----+ | |processor|-> NETCONF stream ----->|NETCONF|
... | | |-> stream n |server |
System | +---------+ +-------+
Components| | /\
... | | ||
+----+ | | (------------) ||
| cn |----+ | (notification) ||
+----+ +-----> ( logging ) ||
( service ) ||
(------------) ||
||
||
\/
+-------+
|NETCONF|
|client |
+-------+
+----+ | c1|----+ 利用可能な流れ+----+ | +---------+ +----+ | |中央|->流れ1| c2| +--->|出来事|->流れの2フィルタ+-------+ +----+ | |プロセッサ|->NETCONFの流れ----->|NETCONF| ... | | |->の流れn|サーバ| システム| +---------+ +-------+ コンポーネント| | /\ ... | | || +----+ | | (------------) || | cn|----+ | (通知) || +----+ +----->(伐採)|| (サービス) || (------------) || || || \/ +-------+ |NETCONF| |クライアント| +-------+
Figure 2
図2
Chisholm & Trevino Standards Track [Page 11] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[11ページ]。
3.2.1. Event Stream Definition
3.2.1. イベント流れの定義
Event streams are predefined on the managed device. The configuration of event streams is outside the scope of this document. However, it is envisioned that event streams are either pre- established by the vendor (pre-configured), user configurable (e.g., part of the device's configuration), or both. Device vendors may allow event stream configuration via the NETCONF protocol (i.e., <edit-config> operation).
イベントの流れは管理された装置で事前に定義されます。 このドキュメントの範囲の外にイベントの流れの構成があります。 しかしながら、思い描かれて、そのイベントの流れが業者(あらかじめ設定される)、構成可能なユーザ(例えば、装置の構成の一部)、または両方によってあらかじめ確立されるということです。 NETCONFプロトコル(すなわち、コンフィグを編集している<>操作)で装置業者はイベント流れの構成を許すかもしれません。
3.2.2. Event Stream Content Format
3.2.2. イベントの流れの満足している形式
The contents of all event streams made available to a NETCONF client (i.e., the notification sent by the NETCONF server) MUST be encoded in XML.
XMLでNETCONFクライアント(すなわち、NETCONFサーバによって送られた通知)にとって利用可能にされたすべてのイベントの流れのコンテンツをコード化しなければなりません。
3.2.3. Default Event Stream
3.2.3. デフォルトイベントの流れ
A NETCONF server implementation supporting the notification capability MUST support the "NETCONF" notification event stream. This stream contains all NETCONF XML event notifications supported by the NETCONF server. The exact string "NETCONF" is used during the advertisement of stream support during the <get> operation on <streams> and during the <create-subscription> operation. Definition of the event notifications and their contents, beyond the inclusion of <eventTime>, for this event stream is outside the scope of this document.
通知能力を支持するNETCONFサーバ実現は"NETCONF"通知イベントストリームを支持しなければなりません。 この流れはNETCONFサーバで後押しされているすべてのNETCONF XMLイベント通知を含んでいます。使用される正確なストリング"NETCONF"は<の間の流れのサポートの広告の間、>と<の間の<の流れの>操作を購読>操作を作成するのに得ます。 このドキュメントの範囲の外にこのイベントの流れのためのイベント通知の定義と<eventTime>の包含を超えたそれらのコンテンツがあります。
3.2.4. Event Stream Sources
3.2.4. イベント流れの源
With the exception of the default event stream (NETCONF), specification of additional event stream sources (e.g., Simple Network Management Protocol (SNMP), syslog) is outside the scope of this document. NETCONF server implementations may leverage any desired event stream source in the creation of supported event streams.
デフォルトイベントの流れ(NETCONF)を除いて、このドキュメントの範囲の外に追加イベント流れの源(例えば、Simple Network Managementプロトコル(SNMP)、syslog)の仕様があります。 NETCONFサーバ実現は支持されたイベントの流れの創造でどんな必要なイベント流れの源にも投機するかもしれません。
3.2.5. Event Stream Discovery
3.2.5. イベント流れの発見
A NETCONF client retrieves the list of supported event streams from a NETCONF server using the <get> operation.
NETCONFクライアントは<を使用すると>操作が得られるNETCONFサーバから支持されたイベントの流れのリストを検索します。
3.2.5.1. Name Retrieval Using <get> Operation
3.2.5.1. 名前検索使用<は>操作を得ます。
The list of available event streams is retrieved by requesting the <streams> subtree via a <get> operation. Available event streams for the requesting session are returned in the reply containing the <name> and <description> elements, where the <name> element is
<を通した<流れの>下位木が>操作を得るよう要求することによって、利用可能なイベントの流れのリストは検索されます。 <名前>と<記述>要素を含む回答で要求セッションのための利用可能なイベント小川を返します。そこでは、<名前>要素がそうです。
Chisholm & Trevino Standards Track [Page 12] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[12ページ]。
mandatory, and its value is unique within the scope of a NETCONF server. An empty reply is returned if there are no available event streams, due to user-specified filters on the <get> operation.
値はNETCONFサーバの範囲の中でユニークです。義務的である、どんな利用可能なイベントの流れもなければ、空の回答を返して、<の上のユーザによって指定されたフィルタは>操作を得ますか?
Additional information available about a stream includes whether notification replay is available and, if so, the timestamp of the earliest possible notification to replay.
そして、流れに関して利用可能な追加情報が、通知再生が利用可能であるかどうかを含んでいる、そうだとすれば、再演する可能な限り初期の通知に関するタイムスタンプ。
The following example shows retrieving the list of available event stream list using the <get> operation.
<を使用することで利用可能なイベント流れのリストのリストを検索する以下の例のショーが>操作を得ます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
<streams/>
</netconf>
</filter>
</get>
</rpc>
「><流れ/></netconf></フィルタ></は></rpc>を手に入れる」という<rpcメッセージイド=「101」xmlns=「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの><は><フィルタタイプ=を得」下位木「><netconf xmlns=」つぼ:ietf:params:xml:ナノ秒:netmod:通知
Chisholm & Trevino Standards Track [Page 13] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[13ページ]。
The NETCONF server returns a list of event streams available for subscription: NETCONF, SNMP, and syslog-critical in this example.
NETCONFサーバは購読に利用可能なイベントの流れのリストを返します: NETCONF、SNMP、およびsyslogこれで批判的な例。
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
<streams>
<stream>
<name>NETCONF</name>
<description>default NETCONF event stream
</description>
<replaySupport>true</replaySupport>
<replayLogCreationTime>
2007-07-08T00:00:00Z
</replayLogCreationTime>
</stream>
<stream>
<name>SNMP</name>
<description>SNMP notifications</description>
<replaySupport>false</replaySupport>
</stream>
<stream>
<name>syslog-critical</name>
<description>Critical and higher severity
</description>
<replaySupport>true</replaySupport>
<replayLogCreationTime>
2007-07-01T00:00:00Z
</replayLogCreationTime>
</stream>
</streams>
</netconf>
</data>
</rpc-reply>
「101」<rpc-応答メッセージイド=xmlnsが「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの><データ><netconf xmlns=」つぼ:ietf:paramsと等しいです: xml:ナノ秒:netmod: 「><は><流れの><名前>NETCONF</名の><記述>デフォルトNETCONFイベント流れの</記述の>の<のreplaySupportの>の本当の</replaySupport><replayLogCreationTime>2007-07-08T00: 00を流す」という通知; 00Z</replayLogCreationTime>の</流れの><流れの><名前>SNMP</名の><記述>SNMP通知</記述の>の<のreplaySupportの>の偽の</replaySupport>の</流れの> <流れの><名前>syslog批判的な</名前><記述>Criticalと、より高い厳しさ</記述の>の<のreplaySupportの>の本当の</replaySupport><replayLogCreationTime>2007-07-01T00:; 00: 00Z</replayLogCreationTime>の</流れの>の</流れの></netconf>データ></rpc</回答>。
3.2.5.2. Event Stream Subscription
3.2.5.2. イベント流れの購読
A NETCONF client may request from the NETCONF server the list of event streams available to this session and then issue a <create- subscription> request with the desired event stream name. Omitting the event stream name from the <create-subscription> request results in subscription to the default NETCONF event stream.
NETCONFクライアントは、NETCONFサーバからこのセッションに利用可能なイベントの流れのリストを要求して、次に、必要なイベント流れの名で購読を作成している<>要求を出すかもしれません。 デフォルトNETCONFイベントの流れの購読で購読>要求結果を作成している<からイベント流れの名を省略します。
Chisholm & Trevino Standards Track [Page 14] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[14ページ]。
3.2.5.2.1. Filtering Event Stream Contents
3.2.5.2.1. イベント流れのコンテンツをフィルターにかけます。
The set of event notifications delivered in an event stream may be further refined by applying a user-specified filter supplied at subscription creation time ( <create-subscription> ). This is a transient filter associated with the event notification subscription and does not modify the event stream configuration. The filter element is applied against the contents of the <notification> wrapper and not the wrapper itself. See section 5 for examples. Either subtree or XPATH filtering can be used.
イベントの流れで提供されたイベント通知のセットは、購読創造時間(購読を作成している<>)に供給されたユーザによって指定されたフィルタを適用することによって、さらに洗練されるかもしれません。 これは、イベント通知購読に関連している一時的なフィルタであり、イベント流れの構成を変更しません。 フィルタエレメントは包装紙自体ではなく、<通知>包装紙のコンテンツに対して適用されます。 例に関してセクション5を見てください。 下位木かXPATHフィルタリングのどちらかを使用できます。
XPATH support for the Notification capability is advertised as part of the normal XPATH capability advertisement. If XPATH support is advertised via the XPATH capability, then XPATH is supported for notification filtering. If this capability is not advertised, XPATH is not supported for notification filtering.
通常のXPATH能力広告の一部としてNotification能力のXPATHサポートの広告を出します。 XPATHサポートがXPATH能力で広告に掲載されるなら、XPATHは通知フィルタリングのために支持されます。 この能力が広告に掲載されないなら、XPATHは通知フィルタリングのために支持されません。
3.3. Notification Replay
3.3. 通知再生
3.3.1. Overview
3.3.1. 概観
Replay is the ability to create an event subscription that will resend recently generated notifications, or in some cases send them for the first time to a particular NETCONF client. These notifications are sent the same way as normal notifications.
再生は最近発生している通知を再送するイベント購読を作成するか、またはいくつかの場合、特定のNETCONFクライアントに初めてそれらを送る能力です。 通常の通知としてこれらの通知を同じ道に送ります。
A replay of notifications is specified by including the optional <startTime> parameter to the subscription command, which indicates the start time of the replay. The end time is specified using the optional <stopTime> parameter. If not present, notifications will continue to be sent until the subscription is terminated.
通知の再生は、任意の<startTime>パラメタを購読命令に含めることによって、指定されます。(命令は再生の開始時刻を示します)。 終わりの時間は、任意の<stopTime>パラメタを使用することで指定されます。 プレゼントでないなら、通知は、購読が終えられるまで送られ続けるでしょう。
A notification stream that supports replay is not expected to have an unlimited supply of saved notifications available to accommodate any replay request. Clients can query <replayLogCreationTime> and <replayLogAgedTime> to learn about the availability of notifications for replay.
サポートが再演する通知ストリームがどんな再生要求にも対応するために利用可能な救われた通知の無制限な供給を持っていないと予想されます。 クライアントは、再生のための通知の有用性に関して学ぶために<replayLogCreationTime>と<replayLogAgedTime>について質問できます。
The actual number of stored notifications available for retrieval at any given time is a NETCONF server implementation-specific matter. Control parameters for this aspect of the feature are outside the scope of this document.
その時々で検索に利用可能な格納された通知の実数はNETCONFのサーバの実現特有の問題です。 このドキュメントの範囲の外に特徴のこの局面のための管理パラメータがあります。
Replay is dependent on a notification stream supporting some form of notification logging, although it puts no restrictions on the size or form of the log, or where it resides within the device. Whether or not a stream supports replay can be discovered by doing a <get> operation on the <streams> element of the Notification Management
再生は何らかの形式の通知伐採を支持する通知ストリームに依存しています、ログのサイズかフォームの上、または、それが装置の中に住んでいるところに制限を全く置きませんが。 再生を発見できる<をする流れのサポートが<で>操作を得るかどうかがNotification Managementの>要素を流します。
Chisholm & Trevino Standards Track [Page 15] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[15ページ]。
Schema and looking at the value of the <replaySupport> object. This schema also provides the <replayLogCreationTime> element to indicate the earliest available logged notification.
図式と<replaySupport>物の値を見ること。 また、この図式は、最も初期の利用可能な登録された通知を示すために<replayLogCreationTime>要素を提供します。
3.3.2. Creating a Subscription with Replay
3.3.2. 再生との購読を作成します。
This feature uses optional parameters to the <create-subscription> command called <startTime> and <stopTime>. <startTime> identifies the earliest date and time of interest for event notifications being replayed and also indicates that a subscription will be providing replay of notifications. Events generated before this time are not matched. <stopTime> specifies the latest date and time of interest for event notifications being replayed. If it is not present, then notifications will continue to be sent until the subscription is terminated.
この特徴は<startTime>と<stopTime>と呼ばれる購読>命令を<に作成している任意のパラメタを使用します。 <startTime>は、再演されるイベント通知のために日時を興味がある最も前半特定して、また、購読が通知の再生を提供するのを示します。 今回の以前発生した出来事は取り組んでいません。 <stopTime>は再演されるイベント通知のための興味がある最終期限と時間を指定します。 それが存在していないと、通知は、購読が終えられるまで送られ続けるでしょう。
Note that <startTime> and <stopTime> are associated with the time an event was generated by the event source.
<startTime>と<stopTime>が出来事がイベントソースで発生した時に関連していることに注意してください。
A <replayComplete> notification is sent to indicate that all of the replay notifications have been sent and must not be sent for any other reason. If this subscription has a stop time, then this session becomes a normal NETCONF session again. The NETCONF server will then accept <rpc> operations even if the server did not previously accept such operations due to lack of interleave support. In the case of a subscription without a stop time, after the <replayComplete> notification has been sent, it can be expected that any notifications generated since the start of the subscription creation will be sent, followed by notifications as they arise naturally within the system.
<replayComplete>通知は再生通知のすべてを送るのを示すために送って、いかなる他の理由でも送ってはいけません。 この購読に停止時間があるなら、このセッションは再び通常のNETCONFセッションになります。 そして、サーバが以前にインタリーブサポートの不足によるそのような操作を受け入れなかったとしても、NETCONFサーバは<rpc>操作を受け入れるでしょう。 停止時間のない購読の場合では、<replayComplete>通知を送った後に購読創造の始まり以来発生するどんな通知も送られると予想できます、システムの中に自然に起こるのに従って通知があとに続いていて。
The <replayComplete> and <notificationComplete> notifications cannot be filtered out. They will always be sent on a replay subscription that specified a <startTime> and <stopTime>, respectively.
<replayComplete>と<notificationComplete>通知を無視できません。 いつもそれぞれ<startTime>と<stopTime>を指定した再生購読にそれらを送るでしょう。
3.4. Notification Management Schema
3.4. 通知管理図式
This Schema is used to learn about the event streams supported on the system. It also contains the definition of the <replayComplete> and <notificationComplete> notifications, which are sent to indicate that an event replay has sent all applicable notifications and that the subscription has terminated, respectively.
このSchemaは、システムの上で支持されたイベントの流れに関して学ぶのに使用されます。 また、それはそれぞれ<replayComplete>と<notificationComplete>通知の定義を含んでいます。(通知は、イベント再生がすべての適切な通知を送って、購読が終わったのを示すために送られます)。
Chisholm & Trevino Standards Track [Page 16] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[16ページ]。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification"
targetNamespace="urn:ietf:params:xml:ns:netmod:notification"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en" version="1.0">
<xs:annotation>
<xs:documentation xml:lang="en">
A schema that can be used to learn about current
event streams. It also contains the replayComplete
and notificationComplete notification.
</xs:documentation>
</xs:annotation>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><xs: 図式xmlns: " http://www.w3.org/2001/XMLSchema "xs=xmlns: netconf=「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチのxmlns: ncEvent=」つぼ:ietf:params: xml:ナノ秒:netconf:通知:1インチのxmlns:; 「適切である」「つぼ:ietf:params:xml:ナノ秒:netmod:通知」「つぼ:ietf:params:xml:ナノ秒:netmod:通知」manageEvent=targetNamespace=elementFormDefault=attributeFormDefaultは「資格のない」xmlと等しいです: 「流それが使用されている場合がある>A図式がほとんど現在の出来事を学ぶぶ」lang=「アン」バージョン=「xml: 1インチの><xs: 注釈><xs: ドキュメンテーションlang=」アン; また、それはreplayCompleteとnotificationComplete通知を含んでいます。 </xs: ドキュメンテーション></xs: 注釈>。
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
schemaLocation="netconf.xsd"/>
<xs:import namespace=
"urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation="notification.xsd"/>
<xs: 輸入名前空間=" http://www.w3.org/XML/1998/namespace "schemaLocationは" http://www.w3.org/2001/xml.xsd "/><xsと等しいです: 名前空間=を輸入してください、「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチのschemaLocationは"netconf.xsd"/><xs: 輸入名前空間=「つぼ:ietf:params:xml:ナノ秒:netconf:通知: 1インチのschemaLocationは"notification.xsd"/>と等しいこと」と等しいです。
<xs:element name="netconf" type="manageEvent:Netconf"/>
<xs: 要素名前="netconf"タイプは「manageEvent: Netconf」/>と等しいです。
<xs:complexType name="Netconf">
<xs:sequence>
<xs:element name="streams" >
<xs:annotation>
<xs:documentation>
The list of event streams supported by the
system. When a query is issued, the returned
set of streams is determined based on user
privileges.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="stream">
<xs:annotation>
<xs:documentation>
Stream name, description, and other information.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs: complexTypeは「「><xs: 系列><xs: 要素は=を命名する」というNetconfの流れ」><xsと=を命名します: イベントの流れのリストがシステムで支持した注釈><xs: ドキュメンテーション>。 質問が発行されるとき、返されたセットの流れはユーザ特権に基づいて決定しています。 </xs: ドキュメンテーション></xs: 注釈><xs: complexType><xs: 系列minOccursは「><xs: 要素は=を命名する」という「1インチのmaxOccurs=」限りない流れと等しいです。「><xs: ><xs: ドキュメンテーション>Streamが命名する注釈、記述、および他の情報。」 </xs: ドキュメンテーション></xs: 注釈><xs: complexType><xs: 系列>。
Chisholm & Trevino Standards Track [Page 17] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[17ページ]。
<xs:element name="name"
type="ncEvent:streamNameType">
<xs:annotation>
<xs:documentation>
The name of the event stream. If this is
the default NETCONF stream, this must have
the value "NETCONF".
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="description"
type="xs:string">
<xs:annotation>
<xs:documentation>
A description of the event stream, including
such information as the type of events that
are sent over this stream.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="replaySupport"
type="xs:boolean">
<xs:annotation>
<xs:documentation>
An indication of whether or not event replay
is available on this stream.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="replayLogCreationTime"
type="xs:dateTime" minOccurs="0">
<xs:annotation>
<xs:documentation>
The timestamp of the creation of the log
used to support the replay function on
this stream.
Note that this might be earlier then
the earliest available
notification in the log. This object
is updated if the log resets
for some reason. This
object MUST be present if replay is
supported.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="replayLogAgedTime"
type="xs:dateTime" minOccurs="0">
<xs: 要素名前=「名前」タイプが等しい、「ncEvent: streamNameType、「><xs: 注釈><はxsされます: 出来事の名前が流すドキュメンテーション>」 デフォルトNETCONFの流れであるなら、これには、値の"NETCONF"がなければなりません。 </xs: ドキュメンテーション></xs: 注釈></xs: 要素><xs: 要素名前=「記述」タイプが等しい、「xs: 「><xs: 注釈><xs: この流れで送られる出来事のタイプのような情報を含むイベントの流れのドキュメンテーション>A記述」を結んでください。 </xs: ドキュメンテーション></xs: 注釈></xs: 要素><xs: 要素名=の"replaySupport"タイプが等しい、「xs: 論理演算子、「><xs: 注釈><xs: イベント再生がこの流れのときに利用可能であるかどうかドキュメンテーション>Anしるし。」 </xs: ドキュメンテーション></xs: 注釈></xs: 要素><xs: 要素名=の"replayLogCreationTime"は=「xs: dateTime」minOccurs=「ログの創造に関するタイムスタンプがこの流れでの再生機能をサポートするのに使用した0インチの><xs: 注釈><xs: ドキュメンテーション>」をタイプします。 これが次に、より早いのがログで最も初期の利用可能な通知であるならそうすることに注意してください。 いくつかのためのログリセットが推論するなら、この物をアップデートします。 再生が支持されるなら、この物は存在していなければなりません。 </xs: ドキュメンテーション></xs: 注釈></xs: 要素><xs: 要素名=の"replayLogAgedTime"タイプ=「xs: dateTime」minOccursは「0インチの>」と等しいです。
Chisholm & Trevino Standards Track [Page 18] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[18ページ]。
<xs:annotation>
<xs:documentation>
The timestamp of the last notification
aged out of the log. This
object MUST be present if replay is
supported and any notifications
have been aged out of the log.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs: 注釈><xs: 最後の通知に関するタイムスタンプがログから年をとらせたドキュメンテーション>。 再生が支持されて、何か通知がログから熟成したなら、この物は存在していなければなりません。 </xs: ></xs: ドキュメンテーション></xs: 注釈></xs: 要素></xs: 系列></xs: complexType></xs: 要素></xs: 系列></xs: complexType></xs: 要素></xs: 系列complexType>。
<xs:complexType name="ReplayCompleteNotificationType">
<xs:complexContent>
<xs:extension base="ncEvent:NotificationContentType"/>
</xs:complexContent>
</xs:complexType>
<xs: complexTypeが=を命名する、「ReplayCompleteNotificationType、「></xs: complexContent></xs: ><xs: complexContent><xs: 拡大ベース=「ncEvent: NotificationContentType」/complexType>」
<xs:element name="replayComplete"
type="manageEvent:ReplayCompleteNotificationType"
substitutionGroup="ncEvent:notificationContent">
<xs:annotation>
<xs:documentation>
This notification is sent to signal the end of a replay
portion of a subscription.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs: 要素名=の"replayComplete"が=「manageEvent: ReplayCompleteNotificationType」substitutionGroup=をタイプする、「ncEvent: notificationContent、「購読の再生部分の端に合図するために><xs: 注釈><xs: ドキュメンテーション>This通知を送ります」。 </xs: ドキュメンテーション></xs: 注釈></xs: 要素>。
<xs:complexType name="NotificationCompleteNotificationType">
<xs:complexContent>
<xs:extension base="ncEvent:NotificationContentType"/>
</xs:complexContent>
</xs:complexType>
<xs: complexTypeが=を命名する、「NotificationCompleteNotificationType、「></xs: complexContent></xs: ><xs: complexContent><xs: 拡大ベース=「ncEvent: NotificationContentType」/complexType>」
<xs:element name="notificationComplete"
type="manageEvent:NotificationCompleteNotificationType"
substitutionGroup="ncEvent:notificationContent">
<xs:annotation>
<xs:documentation>
This notification is sent to signal the end of a
<xs: 要素名=の"notificationComplete"が=「manageEvent: NotificationCompleteNotificationType」substitutionGroup=をタイプする、「ncEvent: 「aの終わりに合図するために><xs: 注釈><xs: ドキュメンテーション>This通知を送る」notificationContent
Chisholm & Trevino Standards Track [Page 19] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[19ページ]。
notification subscription. It is sent in the case
that stopTime was specified during the creation of
the subscription.
</xs:documentation>
</xs:annotation>
</xs:element>
通知購読。 stopTimeが購読の創造の間、指定されて、それを送ります。 </xs: ドキュメンテーション></xs: 注釈></xs: 要素>。
</xs:schema>
</xs: 図式>。
3.5. Subscriptions Data
3.5. 購読データ
Subscriptions are non-persistent state information, and their lifetime is defined by their session or by the <stopTime> parameter.
購読は非しつこい州の情報です、そして、彼らの寿命は彼らのセッションか<stopTime>パラメタによって定義されます。
3.6. Filter Mechanics
3.6. フィルタ整備士
If a filter element is specified to look for data of a particular value, and the data item is not present within a particular event notification for its value to be checked against, the notification will be filtered out. For example, if one were to check for 'severity=critical' in a configuration event notification where this field was not supported, then the notification would be filtered out.
フィルタエレメントが特定の価値に関するデータを探すために指定されて、データ項目が値がチェックされる特定のイベント通知の中に存在していないと、通知は無視されるでしょう。 '例えば、'の厳しさ=に、重要なチェックに1つがあるなら、次にこの分野が支持されなかった構成イベント通知では、通知は無視されるでしょうに。
For subtree filtering, a non-empty node set means that the filter matches. For XPath filtering, the mechanisms defined in [XPATH] should be used to convert the returned value to boolean.
下位木フィルタリングのために、非空のノードセットは、フィルタが合っていることを意味します。 XPathフィルタリングにおいて、[XPATH]で定義されたメカニズムは、戻り値を論理演算子に変換するのに使用されるべきです。
3.6.1. Filtering
3.6.1. フィルタリング
Filtering is explicitly stated when the event notification subscription is created. This is specified via the 'filter' parameter. A Filter only exists as a parameter to the subscription.
フィルタリングはイベント通知であるときに、明らかに述べられていて、購読が作成されるということです。 これは'フィルタ'パラメタで指定されます。 Filterはパラメタとして購読に存在するだけです。
3.7. Message Flow
3.7. メッセージ流動
The following figure depicts message flow between a NETCONF client (C) and NETCONF server (S) in order to create a subscription and begin the flow of notifications. This subscription specifies a <startTime>, so the server starts by replaying logged notifications. It is possible that many rpc/rpc-reply sequences occur before the subscription is created, but this is not depicted in the figure.
以下の図は、(S) 購読を作成して、通知の流れを始めるためにNETCONFクライアント(C)とNETCONFサーバの間のメッセージ流動について表現します。 この購読が<startTime>を指定するので、サーバは登録された通知を再演することによって、始まります。 購読が作成されますが、これが図に表現されない前に多くのrpc/rpc-回答系列が起こるのは、可能です。
Chisholm & Trevino Standards Track [Page 20] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[20ページ]。
C S
| |
| capability exchange |
|-------------------------->|
|<------------------------->|
| |
| <create-subscription> | (startTime)
|-------------------------->|
|<--------------------------|
| <rpc-reply> |
| |
| <notification> |
|<--------------------------|
| |
| <notification> |
|<--------------------------|
| <notification> | (replayComplete)
|<--------------------------|
| |
| |
| |
| <notification> |
|<--------------------------|
| |
| |
| <notification> |
|<--------------------------|
| |
| |
C S| | | 能力交換| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 購読を作成している<>。| (startTime) |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| <rpc-回答>。| | | | <通知>。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| <通知>。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| <通知>。| (replayComplete) |<--------------------------| | | | | | | | <通知>。| |<--------------------------| | | | | | <通知>。| |<--------------------------| | | | |
Figure 3
図3
The following figure depicts message flow between a NETCONF client (C) and NETCONF server (S) in order to create a subscription and begin the flow of notifications. This subscription specified a <startTime> and <stopTime> so it starts by replaying logged notifications and then returns to be a normal command-response NETCONF session after the <replayComplete> and <notificationComplete> notifications are sent and it is available to process <rpc> requests. It is possible that many rpc/rpc-reply sequences occur before the subscription is created, but this is not depicted in the figure.
以下の図は、(S) 購読を作成して、通知の流れを始めるためにNETCONFクライアント(C)とNETCONFサーバの間のメッセージ流動について表現します。 この購読が<startTime>を指定して、再演することによって始まって、<stopTime>は通知を登録して、次に、戻って、<replayComplete>と<notificationComplete>通知を送って、<rpc>要求を処理するのが利用可能になった後に通常のコマンド応答NETCONFセッションになります。 購読が作成されますが、これが図に表現されない前に多くのrpc/rpc-回答系列が起こるのは、可能です。
Chisholm & Trevino Standards Track [Page 21] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[21ページ]。
C S
| |
| capability exchange |
|-------------------------->|
|<------------------------->|
| |
| <create-subscription> | (startTime,
|-------------------------->| stopTime)
|<--------------------------|
| <rpc-reply> |
| |
| <notification> |
|<--------------------------|
| |
| <notification> |
|<--------------------------|
| <notification> | (replayComplete)
|<--------------------------|
| <notification> |(notificationComplete)
|<--------------------------|
| |
| |
| |
| <rpc> |
|-------------------------->|
|<--------------------------|
| <rpc-reply> |
| |
C S| | | 能力交換| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 購読を作成している<>。| (startTime、|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| stopTime、) | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| <rpc-回答>。| | | | <通知>。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| <通知>。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| <通知>。| (replayComplete) | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| <通知>。|(notificationComplete) |<--------------------------| | | | | | | | <rpc>。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| <rpc-回答>。| | |
Figure 4
図4
4. XML Schema for Event Notifications
4. イベント通知のためのXML図式
The following [XMLSchema] defines NETCONF Event Notifications.
以下の[XMLSchema]はNETCONF Event Notificationsを定義します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace=
"urn:ietf:params:xml:ns:netconf:notification:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en">
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ「" http://www.w3.org/2001/XMLSchema "xmlns: ><xs: 図式xs=xmlnsは「つぼ:ietf:params:xml:ナノ秒:netconf:通知: 1インチのxmlns: netconf=」つぼ:ietf:paramsと等しいです: xml:ナノ秒:netconf:ベース:1インチのtargetNamespace=「つぼ:ietf:params:xml:ナノ秒:netconf:通知: 1インチのelementFormDefault=」は資格を得た」attributeFormDefaultが「資格のない」xml: lang=と等しい、「アン">"
Chisholm & Trevino Standards Track [Page 22] RFC 5277 NETCONF Event Notifications July 2008
チスホルムとトレビノStandardsはNETCONFイベント通知2008年7月にRFC5277を追跡します[22ページ]。
<!-- import standard XML definitions -->
<!--輸入の標準のXML定義-->。
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xs:annotation>
<xs:documentation>
This import accesses the xml: attribute groups for the
xml:lang as declared on the error-message element.
</xs:documentation>
</xs:annotation>
</xs:import>
<xs: 名前空間=" http://www.w3.org/XML/1998/namespace "schemaLocation=を輸入してください、「 http://www.w3.org/2001/xml.xsd 、「><xs: 注釈><xs: ドキュメンテーション>This輸入はxmlにアクセスします」。 xmlのためにグループを結果と考えてください: エラーメッセージ要素の上で申告されるlang。 </xs: ></xs: ドキュメンテーション></xs: 注釈輸入>。
<!-- import base netconf definitions -->
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
schemaLocation="netconf.xsd"/>
<!--輸入ベースnetconf定義--><xs: 輸入名前空間=「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチのschemaLocationは"netconf.xsd"/>と等しいです」。
<!-- ************** Symmetrical Operations ********************-->
<!--対称の***操作*******************************-->。
<!-- <create-subscription> operation -->
<!--購読を作成している<>操作-->。
<xs:complexType name="createSubscriptionType">
<xs:complexContent>
<xs:extension base="netconf:rpcOperationType">
<xs:sequence>
<xs:element name="stream"
type="streamNameType" minOccurs="0">
<xs:annotation>
<xs:documentation>
An optional parameter that indicates
which stream of events is of interest.
If not present, then events in the
default NETCONF stream will be sent.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="filter"
type="netconf:filterInlineType"
minOccurs="0">
<xs:annotation>
<xs:documentation>
An optional parameter that indicates
which subset of all possible events
is of interest. The format of this
parameter is the same as that of the
filter parameter in the NETCONF
protocol operations. If not
present, all events not precluded
by other parameters will be sent.
<xs:complexType name="createSubscriptionType"> <xs:complexContent> <xs:extension base="netconf:rpcOperationType"> <xs:sequence> <xs:element name="stream" type="streamNameType" minOccurs="0"> <xs:annotation> <xs:documentation> An optional parameter that indicates which stream of events is of interest. If not present, then events in the default NETCONF stream will be sent. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"> <xs:annotation> <xs:documentation> An optional parameter that indicates which subset of all possible events is of interest. The format of this parameter is the same as that of the filter parameter in the NETCONF protocol operations. If not present, all events not precluded by other parameters will be sent.
Chisholm & Trevino Standards Track [Page 23] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 23] RFC 5277 NETCONF Event Notifications July 2008
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="startTime" type="xs:dateTime"
minOccurs="0" >
<xs:annotation>
<xs:documentation>
A parameter used to trigger the replay
feature indicating that the replay
should start at the time specified. If
start time is not present, this is not a
replay subscription.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="stopTime" type="xs:dateTime"
minOccurs="0" >
<xs:annotation>
<xs:documentation>
An optional parameter used with the
optional replay feature to indicate the
newest notifications of interest. If
stop time is not present, the
notifications will continue until the
subscription is terminated. Must be
used with startTime.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="streamNameType">
<xs:annotation>
<xs:documentation>
The name of an event stream.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:documentation> </xs:annotation> </xs:element> <xs:element name="startTime" type="xs:dateTime" minOccurs="0" > <xs:annotation> <xs:documentation> A parameter used to trigger the replay feature indicating that the replay should start at the time specified. If start time is not present, this is not a replay subscription. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="stopTime" type="xs:dateTime" minOccurs="0" > <xs:annotation> <xs:documentation> An optional parameter used with the optional replay feature to indicate the newest notifications of interest. If stop time is not present, the notifications will continue until the subscription is terminated. Must be used with startTime. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:simpleType name="streamNameType"> <xs:annotation> <xs:documentation> The name of an event stream. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>
Chisholm & Trevino Standards Track [Page 24] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 24] RFC 5277 NETCONF Event Notifications July 2008
<xs:element name="create-subscription"
type="createSubscriptionType"
substitutionGroup="netconf:rpcOperation">
<xs:annotation>
<xs:documentation>
The command to create a notification subscription. It
takes as argument the name of the notification stream
and filter. Both of those options
limit the content of the subscription. In addition,
there are two time-related parameters, startTime and
stopTime, which can be used to select the time interval
of interest to the notification replay feature.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="create-subscription" type="createSubscriptionType" substitutionGroup="netconf:rpcOperation"> <xs:annotation> <xs:documentation> The command to create a notification subscription. It takes as argument the name of the notification stream and filter. Both of those options limit the content of the subscription. In addition, there are two time-related parameters, startTime and stopTime, which can be used to select the time interval of interest to the notification replay feature. </xs:documentation> </xs:annotation> </xs:element>
<!-- ************** One-way Operations ******************-->
<!-- ************** One-way Operations ******************-->
<!-- <Notification> operation -->
<xs:complexType name="NotificationContentType"/>
<!-- <Notification> operation --> <xs:complexType name="NotificationContentType"/>
<xs:element name="notificationContent"
type="NotificationContentType" abstract="true"/>
<xs:element name="notificationContent" type="NotificationContentType" abstract="true"/>
<xs:complexType name="NotificationType">
<xs:sequence>
<xs:element name="eventTime" type="xs:dateTime">
<xs:annotation>
<xs:documentation>
The time the event was generated by the event source.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element ref="notificationContent"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NotificationType"> <xs:sequence> <xs:element name="eventTime" type="xs:dateTime"> <xs:annotation> <xs:documentation> The time the event was generated by the event source. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="notificationContent"/> </xs:sequence> </xs:complexType>
<xs:element name="notification" type="NotificationType"/>
</xs:schema>
<xs:element name="notification" type="NotificationType"/> </xs:schema>
Chisholm & Trevino Standards Track [Page 25] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 25] RFC 5277 NETCONF Event Notifications July 2008
5. Filtering Examples
5. Filtering Examples
The following section provides examples to illustrate the various methods of filtering content on an event notification subscription.
The following section provides examples to illustrate the various methods of filtering content on an event notification subscription.
In order to illustrate the use of filter expressions, it is necessary to assume some of the event notification content. The examples below assume that the event notification schema definition has an <event> element at the top level consisting of the event class (e.g., fault, state, config), reporting entity, and either severity or operational state.
In order to illustrate the use of filter expressions, it is necessary to assume some of the event notification content. The examples below assume that the event notification schema definition has an <event> element at the top level consisting of the event class (e.g., fault, state, config), reporting entity, and either severity or operational state.
Examples in this section are generated from the following fictional Schema.
Examples in this section are generated from the following fictional Schema.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://example.com/event/1.0"
xmlns="http://example.com/event/1.0"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0">
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://example.com/event/1.0" xmlns="http://example.com/event/1.0" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0">
<xs:import namespace=
"urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation="notification.xsd"/>
<xs:import namespace= "urn:ietf:params:xml:ns:netconf:notification:1.0" schemaLocation="notification.xsd"/>
<xs:complexType name="eventType">
<xs:complexContent>
<xs:extension base="ncEvent:NotificationContentType">
<xs:sequence>
<xs:element name="eventClass" />
<xs:element name="reportingEntity">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any"
processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element name="severity"/>
<xs:element name="operState"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="eventType"> <xs:complexContent> <xs:extension base="ncEvent:NotificationContentType"> <xs:sequence> <xs:element name="eventClass" /> <xs:element name="reportingEntity"> <xs:complexType> <xs:sequence> <xs:any namespace="##any" processContents="lax"/> </xs:sequence> </xs:complexType> </xs:element> <xs:choice> <xs:element name="severity"/> <xs:element name="operState"/> </xs:choice> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>
Chisholm & Trevino Standards Track [Page 26] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 26] RFC 5277 NETCONF Event Notifications July 2008
<xs:element name="event"
type="eventType"
substitutionGroup="ncEvent:notificationContent"/>
<xs:element name="event" type="eventType" substitutionGroup="ncEvent:notificationContent"/>
</xs:schema>
</xs:schema>
The above fictional notification definition could result in the following sample notification list, which is used in the examples in this section.
The above fictional notification definition could result in the following sample notification list, which is used in the examples in this section.
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<reportingEntity>
<card>Ethernet0</card>
</reportingEntity>
<severity>major</severity>
</event>
</notification>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2007-07-08T00:01:00Z</eventTime> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <reportingEntity> <card>Ethernet0</card> </reportingEntity> <severity>major</severity> </event> </notification>
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-07-08T00:02:00Z</eventTime>
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<reportingEntity>
<card>Ethernet2</card>
</reportingEntity>
<severity>critical</severity>
</event>
</notification>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2007-07-08T00:02:00Z</eventTime> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <reportingEntity> <card>Ethernet2</card> </reportingEntity> <severity>critical</severity> </event> </notification>
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-07-08T00:04:00Z</eventTime>
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<reportingEntity>
<card>ATM1</card>
</reportingEntity>
<severity>minor</severity>
</event>
</notification>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2007-07-08T00:04:00Z</eventTime> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <reportingEntity> <card>ATM1</card> </reportingEntity> <severity>minor</severity> </event> </notification>
Chisholm & Trevino Standards Track [Page 27] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 27] RFC 5277 NETCONF Event Notifications July 2008
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-07-08T00:10:00Z</eventTime>
<event xmlns="http://example.com/event/1.0">
<eventClass>state</eventClass>
<reportingEntity>
<card>Ethernet0</card>
</reportingEntity>
<operState>enabled</operState>
</event>
</notification>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2007-07-08T00:10:00Z</eventTime> <event xmlns="http://example.com/event/1.0"> <eventClass>state</eventClass> <reportingEntity> <card>Ethernet0</card> </reportingEntity> <operState>enabled</operState> </event> </notification>
5.1. Subtree Filtering
5.1. Subtree Filtering
XML subtree filtering is not well-suited for creating elaborate filter definitions given that it only supports equality comparisons and application of the logical OR operators (e.g., in an event subtree, give me all event notifications that have severity=critical, severity=major, or severity=minor). Nevertheless, it may be used for defining simple event notification forwarding filters as shown below.
XML subtree filtering is not well-suited for creating elaborate filter definitions given that it only supports equality comparisons and application of the logical OR operators (e.g., in an event subtree, give me all event notifications that have severity=critical, severity=major, or severity=minor). Nevertheless, it may be used for defining simple event notification forwarding filters as shown below.
The following example illustrates how to select fault events which have severities of critical, major, or minor. The filtering criteria evaluation is as follows:
The following example illustrates how to select fault events which have severities of critical, major, or minor. The filtering criteria evaluation is as follows:
((fault & severity=critical) | (fault & severity=major) | (fault & severity=minor))
((fault & severity=critical) | (fault & severity=major) | (fault & severity=minor))
<netconf:rpc netconf:message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<filter netconf:type="subtree">
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<severity>critical</severity>
</event>
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<severity>major</severity>
</event>
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<severity>minor</severity>
</event>
</filter>
</create-subscription>
</netconf:rpc>
<netconf:rpc netconf:message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <filter netconf:type="subtree"> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <severity>critical</severity> </event> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <severity>major</severity> </event> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <severity>minor</severity> </event> </filter> </create-subscription> </netconf:rpc>
Chisholm & Trevino Standards Track [Page 28] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 28] RFC 5277 NETCONF Event Notifications July 2008
The following example illustrates how to select state or config EventClasses or fault events that are related to card Ethernet0. The filtering criteria evaluation is as follows:
The following example illustrates how to select state or config EventClasses or fault events that are related to card Ethernet0. The filtering criteria evaluation is as follows:
( state | config | ( fault & ( card=Ethernet0)))
( state | config | ( fault & ( card=Ethernet0)))
<netconf:rpc netconf:message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<filter netconf:type="subtree">
<event xmlns="http://example.com/event/1.0">
<eventClass>state</eventClass>
</event>
<event xmlns="http://example.com/event/1.0">
<eventClass>config</eventClass>
</event>
<event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass>
<reportingEntity>
<card>Ethernet0</card>
</reportingEntity>
</event>
</filter>
</create-subscription>
</netconf:rpc>
<netconf:rpc netconf:message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <filter netconf:type="subtree"> <event xmlns="http://example.com/event/1.0"> <eventClass>state</eventClass> </event> <event xmlns="http://example.com/event/1.0"> <eventClass>config</eventClass> </event> <event xmlns="http://example.com/event/1.0"> <eventClass>fault</eventClass> <reportingEntity> <card>Ethernet0</card> </reportingEntity> </event> </filter> </create-subscription> </netconf:rpc>
5.2. XPATH Filters
5.2. XPATH Filters
The following [XPATH] example illustrates how to select fault EventClass notifications that have severities of critical, major, or minor. The filtering criteria evaluation is as follows:
The following [XPATH] example illustrates how to select fault EventClass notifications that have severities of critical, major, or minor. The filtering criteria evaluation is as follows:
((fault) & ((severity=critical) | (severity=major) | (severity = minor)))
((fault) & ((severity=critical) | (severity=major) | (severity = minor)))
<netconf:rpc netconf:message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<filter netconf:type="xpath"
xmlns:ex="http://example.com/event/1.0"
select="/ex:event[ex:eventClass='fault' and
(ex:severity='minor' or ex:severity='major'
or ex:severity='critical')]"/>
</create-subscription>
</netconf:rpc>
<netconf:rpc netconf:message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <filter netconf:type="xpath" xmlns:ex="http://example.com/event/1.0" select="/ex:event[ex:eventClass='fault' and (ex:severity='minor' or ex:severity='major' or ex:severity='critical')]"/> </create-subscription> </netconf:rpc>
Chisholm & Trevino Standards Track [Page 29] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 29] RFC 5277 NETCONF Event Notifications July 2008
The following example illustrates how to select state and config EventClasses or fault events of any severity that come from card Ethernet0. The filtering criteria evaluation is as follows:
The following example illustrates how to select state and config EventClasses or fault events of any severity that come from card Ethernet0. The filtering criteria evaluation is as follows:
( state | config | (fault & card=Ethernet0))
( state | config | (fault & card=Ethernet0))
<netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<filter netconf:type="xpath"
xmlns:ex="http://example.com/event/1.0"
select="/ex:event[
(ex:eventClass='state' or ex:eventClass='config') or
((ex:eventClass='fault' and ex:card='Ethernet0'))]"/>
</create-subscription>
</netconf:rpc>
<netconf:rpc message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <filter netconf:type="xpath" xmlns:ex="http://example.com/event/1.0" select="/ex:event[ (ex:eventClass='state' or ex:eventClass='config') or ((ex:eventClass='fault' and ex:card='Ethernet0'))]"/> </create-subscription> </netconf:rpc>
6. Interleave Capability
6. Interleave Capability
6.1. Description
6.1. Description
The :interleave capability indicates that the NETCONF peer supports the ability to interleave other NETCONF operations within a notification subscription. This means the NETCONF server MUST receive, process, and respond to NETCONF requests on a session with an active notification subscription. This capability helps scalability by reducing the total number of NETCONF sessions required by a given operator or management application.
The :interleave capability indicates that the NETCONF peer supports the ability to interleave other NETCONF operations within a notification subscription. This means the NETCONF server MUST receive, process, and respond to NETCONF requests on a session with an active notification subscription. This capability helps scalability by reducing the total number of NETCONF sessions required by a given operator or management application.
6.2. Dependencies
6.2. Dependencies
This capability is dependent on the notification capability being supported.
This capability is dependent on the notification capability being supported.
6.3. Capability Identifier
6.3. Capability Identifier
The :interleave capability is identified by the following capability string:
The :interleave capability is identified by the following capability string:
urn:ietf:params:netconf:capability:interleave:1.0
urn:ietf:params:netconf:capability:interleave:1.0
Chisholm & Trevino Standards Track [Page 30] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 30] RFC 5277 NETCONF Event Notifications July 2008
6.4. New Operations
6.4. New Operations
None.
None.
6.5. Modifications to Existing Operations
6.5. Modifications to Existing Operations
When a <create-subscription> is sent while another subscription is active on that session, the following error will be returned:
When a <create-subscription> is sent while another subscription is active on that session, the following error will be returned:
Tag: operation-failed
Tag: operation-failed
Error-type: protocol
Error-type: protocol
Severity: error
Severity: error
Error-info: none
Error-info: none
Description: Request could not be completed because the requested
operation failed for some reason not covered by any other error
condition.
Description: Request could not be completed because the requested operation failed for some reason not covered by any other error condition.
7. Security Considerations
7. Security Considerations
The security considerations from the base [NETCONF] document also apply to the Notification capability.
The security considerations from the base [NETCONF] document also apply to the Notification capability.
The access control framework and the choice of transport will have a major impact on the security of the solution.
The access control framework and the choice of transport will have a major impact on the security of the solution.
The <notification> elements are never sent before the transport layer and the NETCONF layer, including capabilities exchange, have been established and the manager has been identified and authenticated.
The <notification> elements are never sent before the transport layer and the NETCONF layer, including capabilities exchange, have been established and the manager has been identified and authenticated.
It is recommended that care be taken to secure execution:
It is recommended that care be taken to secure execution:
o <create-subscription> invocation
o <create-subscription> invocation
o <get> on read-only data models
o <get> on read-only data models
o <notification> content
o <notification> content
Secure execution means ensuring that a secure transport is used as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific subset of NETCONF content involved. When a <get> is received that refers to the content defined in this memo, clients should only be able to view the content for which they have sufficient privileges. A create <create-subscription> operation can be considered like a deferred
Secure execution means ensuring that a secure transport is used as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific subset of NETCONF content involved. When a <get> is received that refers to the content defined in this memo, clients should only be able to view the content for which they have sufficient privileges. A create <create-subscription> operation can be considered like a deferred
Chisholm & Trevino Standards Track [Page 31] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 31] RFC 5277 NETCONF Event Notifications July 2008
<get>, and the content that different users can access may vary. This different access is reflected in the <notification> that different users are able to subscribe to.
<get>, and the content that different users can access may vary. This different access is reflected in the <notification> that different users are able to subscribe to.
One potential security issue is the transport of data from non- NETCONF streams, such as syslog and SNMP. This data may be more vulnerable (or less vulnerable) when being transported over NETCONF than when being transported using the protocol normally used for transporting it, depending on the security credentials of the two subsystems. The NETCONF server is responsible for applying access control to stream content.
One potential security issue is the transport of data from non- NETCONF streams, such as syslog and SNMP. This data may be more vulnerable (or less vulnerable) when being transported over NETCONF than when being transported using the protocol normally used for transporting it, depending on the security credentials of the two subsystems. The NETCONF server is responsible for applying access control to stream content.
The contents of notifications, as well as the names of event streams, may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. The NETCONF server MUST NOT include any content in a notification that the user is not authorized to view.
The contents of notifications, as well as the names of event streams, may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. The NETCONF server MUST NOT include any content in a notification that the user is not authorized to view.
If a subscription is created with a <stopTime>, the NETCONF session will return to being a normal command-response NETCONF session when the replay is completed. It is the responsibility of the NETCONF client to close this session when it is no longer of use.
If a subscription is created with a <stopTime>, the NETCONF session will return to being a normal command-response NETCONF session when the replay is completed. It is the responsibility of the NETCONF client to close this session when it is no longer of use.
If a malicious or buggy NETCONF client sends a number of <create- subscription> requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the <kill-session> operation.
If a malicious or buggy NETCONF client sends a number of <create- subscription> requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the <kill-session> operation.
8. IANA Considerations
8. IANA Considerations
This document registers three URIs for the NETCONF XML namespace in the IETF XML registry [RFC3688].
This document registers three URIs for the NETCONF XML namespace in the IETF XML registry [RFC3688].
Following the format in RFC 3688, IANA has made the following registration. Note that the capability URNs are also compliant to section 10.3 of [NETCONF].
Following the format in RFC 3688, IANA has made the following registration. Note that the capability URNs are also compliant to section 10.3 of [NETCONF].
+--------------------+----------------------------------------------+ | Index | Capability Identifier | +--------------------+----------------------------------------------+ | :notification | urn:ietf:params:netconf:capability: | | | notification:1.0 | | | | | :interleave | urn:ietf:params:netconf:capability: | | | interleave:1.0 | +--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+ | Index | Capability Identifier | +--------------------+----------------------------------------------+ | :notification | urn:ietf:params:netconf:capability: | | | notification:1.0 | | | | | :interleave | urn:ietf:params:netconf:capability: | | | interleave:1.0 | +--------------------+----------------------------------------------+
Chisholm & Trevino Standards Track [Page 32] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 32] RFC 5277 NETCONF Event Notifications July 2008
URI: urn:ietf:params:xml:ns:netmod:notification
URI: urn:ietf:params:xml:ns:netmod:notification
URI: urn:ietf:params:xml:ns:netconf:notification:1.0
URI: urn:ietf:params:xml:ns:netconf:notification:1.0
Registrant Contact: The IESG.
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
XML: N/A, the requested URI is an XML namespace.
In addition, IANA registered the XML Schema defined in Section 4.
In addition, IANA registered the XML Schema defined in Section 4.
9. Acknowledgements
9. Acknowledgements
Thanks to Gilbert Gagnon, Greg Wilbur, and Kim Curran for providing their input into the early work on this document. In addition, the editors would like to acknowledge input at the Vancouver editing session from the following people: Orly Nicklass, James Balestriere, Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave Partain, Ray Atarashi, David Perkins, and the following additional people from the Montreal editing session: Balazs Lengyel, Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen, Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, and William Chow. We would also like to thank Li Yan for his numerous reviews, as well as Suresh Krishnan for his gen-art review of the document.
Thanks to Gilbert Gagnon, Greg Wilbur, and Kim Curran for providing their input into the early work on this document. In addition, the editors would like to acknowledge input at the Vancouver editing session from the following people: Orly Nicklass, James Balestriere, Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave Partain, Ray Atarashi, David Perkins, and the following additional people from the Montreal editing session: Balazs Lengyel, Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen, Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, and William Chow. We would also like to thank Li Yan for his numerous reviews, as well as Suresh Krishnan for his gen-art review of the document.
10. Normative References
10. Normative References
[NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol",
RFC 4741, December 2006.
[NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[XMLSchema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C http
://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
structures.html, October 2004.
[XMLSchema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C http ://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ structures.html, October 2004.
Chisholm & Trevino Standards Track [Page 33] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 33] RFC 5277 NETCONF Event Notifications July 2008
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0",
W3C http://www.w3.org/TR/1999/REC-xpath-19991116,
November 1999.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", W3C http://www.w3.org/TR/1999/REC-xpath-19991116, November 1999.
Authors' Addresses
Authors' Addresses
Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada
Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada
EMail: schishol@nortel.com
EMail: schishol@nortel.com
Hector Trevino Cisco Suite 400 9155 E. Nichols Ave Englewood, CO 80112 USA
Hector Trevino Cisco Suite 400 9155 E. Nichols Ave Englewood, CO 80112 USA
EMail: htrevino@cisco.com
EMail: htrevino@cisco.com
Chisholm & Trevino Standards Track [Page 34] RFC 5277 NETCONF Event Notifications July 2008
Chisholm & Trevino Standards Track [Page 34] RFC 5277 NETCONF Event Notifications July 2008
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Chisholm & Trevino Standards Track [Page 35]
チスホルムとトレビノ標準化過程[35ページ]
一覧
スポンサーリンク
