[要約] RFC 8640は、NETCONFを介してYANGイベントとデータストアに動的にサブスクライブするための仕様です。その目的は、ネットワークデバイスの状態変更やデータの変更をリアルタイムで監視し、効率的なネットワーク管理を可能にすることです。
Internet Engineering Task Force (IETF) E. Voit
Request for Comments: 8640 Cisco Systems
Category: Standards Track A. Clemm
ISSN: 2070-1721 Futurewei
A. Gonzalez Prieto
Microsoft
E. Nilsen-Nygaard
A. Tripathy
Cisco Systems
September 2019
Dynamic Subscription to YANG Events and Datastores over NETCONF
NETCONFを介したYANGイベントおよびデータストアへの動的サブスクリプション
Abstract
概要
This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.
このドキュメントは、サブスクライブされた通知とYANG-Pushの両方の動的サブスクリプション機能へのネットワーク構成プロトコル（NETCONF）バインディングを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8640.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8640で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Compatibility with <create-subscription> as Defined in
RFC 5277 ........................................................4
4. Mandatory XML, Event Stream, and Datastore Support ..............4
5. NETCONF Connectivity and Dynamic Subscriptions ..................4
6. Notification Messages ...........................................5
7. Dynamic Subscriptions and RPC Error Responses ...................5
8. Security Considerations .........................................7
9. IANA Considerations .............................................7
10. References .....................................................7
10.1. Normative References ......................................7
10.2. Informative References ....................................8
Appendix A. Examples ...............................................9
A.1. Event Stream Discovery ......................................9
A.2. Dynamic Subscriptions ......................................10
A.3. Subscription State Notifications ...........................15
A.4. Filter Examples ............................................17
Acknowledgments ...................................................19
Authors' Addresses ................................................19
This document specifies the binding of a stream of events that form part of a dynamic subscription to the Network Configuration Protocol (NETCONF) [RFC6241]. Dynamic subscriptions are defined in [RFC8639]. In addition, as [RFC8641] is itself built upon [RFC8639], this document enables a NETCONF client to request via a dynamic subscription, and receive, updates from a YANG datastore located on a NETCONF server.
このドキュメントは、ネットワーク構成プロトコル（NETCONF）[RFC6241]への動的サブスクリプションの一部を形成するイベントのストリームのバインディングを指定します。動的サブスクリプションは[RFC8639]で定義されています。さらに、[RFC8641]自体は[RFC8639]に基づいて構築されているため、このドキュメントにより、NETCONFクライアントは動的サブスクリプションを介して要求し、NETCONFサーバーにあるYANGデータストアから更新を受信できます。
This document assumes that the reader is familiar with the terminology and concepts defined in [RFC8639].
このドキュメントは、読者が[RFC8639]で定義されている用語と概念に精通していることを前提としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following terms are defined in [RFC8639]: dynamic subscription, event stream, notification message, publisher, receiver, subscriber, and subscription. This document does not define any additional terms.
[RFC8639]で定義されている用語は、動的サブスクリプション、イベントストリーム、通知メッセージ、パブリッシャー、レシーバー、サブスクライバー、サブスクリプションです。このドキュメントでは、追加の用語を定義していません。
A publisher is allowed to concurrently support dynamic subscription RPCs as defined in [RFC8639] at the same time as the <create-subscription> RPC defined in [RFC5277]. However, a single NETCONF transport session MUST NOT support both this specification and a subscription established by the <create-subscription> RPC defined in [RFC5277]. To protect against any attempts to use a single NETCONF transport session in this way:
[RFC5277]で定義されている<create-subscription> RPCと同時に、[RFC8639]で定義されている動的サブスクリプションRPCをパブリッシャーが同時にサポートできます。ただし、単一のNETCONFトランスポートセッションは、この仕様と、[RFC5277]で定義されている<create-subscription> RPCによって確立されたサブスクリプションの両方をサポートしてはなりません（MUST NOT）。この方法で単一のNETCONFトランスポートセッションを使用する試みから保護するには：
o A solution MUST reply with the <rpc-error> element [RFC6241] containing the "error-tag" value of "operation-not-supported" if a <create-subscription> RPC is received on a NETCONF session where an established subscription per [RFC8639] exists.
o <create-subscription> RPCがNETCONFセッションで受信された場合、ソリューションは、<rpc-error>要素[RFC6241]で応答する必要があります。 [RFC8639]が存在します。
o A solution MUST reply with the <rpc-error> element [RFC6241] containing the "error-tag" value of "operation-not-supported" if an "establish-subscription" request has been received on a NETCONF session where the <create-subscription> RPC [RFC5277] has successfully created a subscription.
o <create-subscription "リクエストがNETCONFセッションで受信された場合、ソリューションは、" operation-not-supported "の" error-tag "値を含む<rpc-error>要素[RFC6241]で応答する必要があります。 -subscription> RPC [RFC5277]がサブスクリプションを正常に作成しました。
If a publisher supports this specification but not subscriptions via [RFC5277], the publisher MUST NOT advertise "urn:ietf:params:netconf:capability:notification:1.0".
パブリッシャーがこの仕様をサポートするが[RFC5277]経由のサブスクリプションをサポートしない場合、パブリッシャーは「urn：ietf：params：netconf：capability：notification：1.0」を宣伝してはなりません。
The "encode-xml" feature of [RFC8639] MUST be supported. This indicates that XML is a valid encoding for RPCs, state change notifications, and subscribed content.
[RFC8639]の "encode-xml"機能はサポートされなければならない（MUST）。これは、XMLがRPC、状態変更通知、およびサブスクライブされたコンテンツの有効なエンコーディングであることを示しています。
A NETCONF publisher supporting event stream subscription via [RFC8639] MUST support the "NETCONF" event stream identified in that document.
[RFC8639]を介したイベントストリームのサブスクリプションをサポートするNETCONFパブリッシャーは、そのドキュメントで識別される「NETCONF」イベントストリームをサポートする必要があります。
Management of dynamic subscriptions occurs via RPCs as defined in [RFC8641] and [RFC8639]. For a dynamic subscription, if the NETCONF session involved with the "establish-subscription" terminates, the subscription MUST be terminated.
動的サブスクリプションの管理は、[RFC8641]および[RFC8639]で定義されているRPCを介して行われます。動的サブスクリプションの場合、「establish-subscription」に関連するNETCONFセッションが終了すると、サブスクリプションを終了する必要があります。
For a dynamic subscription, any "modify-subscription", "delete-subscription", or "resync-subscription" RPCs MUST be sent using the same NETCONF session upon which the referenced subscription was established.
動的サブスクリプションの場合、「変更サブスクリプション」、「削除サブスクリプション」、または「再同期サブスクリプション」のRPCは、参照されるサブスクリプションが確立されたのと同じNETCONFセッションを使用して送信する必要があります。
Notification messages transported over NETCONF MUST be encoded in a <notification> message as defined in [RFC5277], Section 4. And per the <eventTime> object definition provided in [RFC5277], <eventTime> is populated with the event occurrence time.
NETCONFを介して転送される通知メッセージは、[RFC5277]のセクション4で定義されている<notification>メッセージにエンコードする必要があります。[RFC5277]で提供されている<eventTime>オブジェクトの定義に従って、<eventTime>にイベント発生時刻が入力されます。
For dynamic subscriptions, all notification messages MUST use the NETCONF transport session used by the "establish-subscription" RPC.
動的サブスクリプションの場合、すべての通知メッセージは、「establish-subscription」RPCで使用されるNETCONFトランスポートセッションを使用する必要があります。
When an RPC error occurs as defined in [RFC8639], Section 2.4.6 and [RFC8641], Appendix A, the NETCONF RPC reply MUST include an <rpc-error> element per [RFC6241] with the error information populated as follows:
[RFC8639]、セクション2.4.6および[RFC8641]、付録Aで定義されているようにRPCエラーが発生した場合、NETCONF RPC応答には、[RFC6241]ごとに<rpc-error>要素を含め、エラー情報を次のように入力する必要があります。
o An "error-type" node of "application".
o 「アプリケーション」の「エラータイプ」ノード。
o An "error-tag" node, where the value is a string that corresponds to an identity associated with the error. For the mechanisms specified in this document, this "error-tag" will correspond to the error identities in either (1) [RFC8639], Section 2.4.6, for general subscription errors:
o 「エラータグ」ノード。値は、エラーに関連付けられたIDに対応する文字列です。このドキュメントで指定されているメカニズムの場合、この「エラータグ」は、一般的なサブスクリプションエラーの場合、（1）[RFC8639]、セクション2.4.6のいずれかのエラーIDに対応します。
error identity uses error-tag
---------------------- -----------------------
dscp-unavailable invalid-value
encoding-unsupported invalid-value
filter-unsupported invalid-value
insufficient-resources resource-denied
no-such-subscription invalid-value
replay-unsupported operation-not-supported
or (2) [RFC8641], Appendix A.1, for subscription errors specific to YANG datastores:
または（2）[RFC8641]、付録A.1、YANGデータストアに固有のサブスクリプションエラーの場合：
error identity uses error-tag
--------------------------- -----------------------
cant-exclude operation-not-supported
datastore-not-subscribable invalid-value
no-such-subscription-resync invalid-value
on-change-unsupported operation-not-supported
on-change-sync-unsupported operation-not-supported
period-unsupported invalid-value
update-too-big too-big
sync-too-big too-big
unchanging-selection operation-failed
o An "error-severity" of "error" (this MAY be included).
o 「エラー」の「エラー重大度」（これは含まれる場合があります）。
o An "error-app-tag" node, where the value is a string that corresponds to an identity associated with the error, as defined in [RFC8639], Section 2.4.6 for general subscriptions and [RFC8641], Appendix A.1 for datastore subscriptions. The specific identity to use depends on the RPC for which the error occurred. Each error identity will be inserted as the "error-app-tag" following the form <modulename>:<identityname>. An example of such a valid encoding would be "ietf-subscribed-notifications:no-such-subscription". Viable errors for different RPCs are as follows:
o 「error-app-tag」ノード。値はエラーに関連付けられたIDに対応する文字列であり、[RFC8639]、一般的なサブスクリプションのセクション2.4.6および[RFC8641]、付録A.1で定義されています。データストアのサブスクリプション。使用する特定のIDは、エラーが発生したRPCによって異なります。各エラーIDは、<errorname-app-tag "として、<modulename>：<identityname>の形式で挿入されます。このような有効なエンコードの例は、「ietf-subscribed-notifications：no-such-subscription」です。さまざまなRPCの実行可能なエラーは次のとおりです。
RPC has base identity
---------------------- ----------------------------
establish-subscription establish-subscription-error
modify-subscription modify-subscription-error
delete-subscription delete-subscription-error
kill-subscription delete-subscription-error
resync-subscription resync-subscription-error
o In the case of error responses to an "establish-subscription" or "modify-subscription" request, there is the option of including an "error-info" node. This node may contain XML-encoded data with hints for parameter settings that might lead to successful RPC requests in the future. The yang-data structures from [RFC8639] and [RFC8641] that may be returned are as follows:
o 「establish-subscription」または「modify-subscription」リクエストに対するエラー応答の場合、「error-info」ノードを含めるオプションがあります。このノードには、将来のRPCリクエストの成功につながる可能性のあるパラメーター設定のヒントを含むXMLエンコードデータが含まれる場合があります。返される可能性がある[RFC8639]と[RFC8641]からのヤンデータ構造は次のとおりです。
establish-subscription returns hints in yang-data structure
---------------------- -------------------------------------------
target: event stream establish-subscription-stream-error-info
target: datastore establish-subscription-datastore-error-info
modify-subscription returns hints in yang-data structure
---------------------- ----------------------------------------
target: event stream modify-subscription-stream-error-info
target: datastore modify-subscription-datastore-error-info
The yang-data included in "error-info" SHOULD NOT include the optional leaf "reason", as such a leaf would be redundant with information that is already placed in the "error-app-tag".
"error-info"に含まれるyang-dataには、オプションのリーフ "reason"を含めないでください。そのようなリーフは、 "error-app-tag"に既に配置されている情報と重複するためです。
In the case of an RPC error resulting from a "delete-subscription", "kill-subscription", or "resync-subscription" request, no "error-info" needs to be included, as the "subscription-id" is the only RPC input parameter and no hints regarding this RPC input parameter need to be provided.
「subscription-id」は「subscription-id」であるため、「delete-subscription」、「kill-subscription」、または「resync-subscription」リクエストに起因するRPCエラーの場合、「error-info」を含める必要はありません。 RPC入力パラメーターのみを提供し、このRPC入力パラメーターに関するヒントを提供する必要はありません。
This document does not introduce additional security considerations for dynamic subscriptions beyond those discussed in [RFC8639]. But there is one consideration worthy of more refinement based on the connection-oriented nature of NETCONF. Specifically, if a buggy or compromised NETCONF subscriber sends a number of "establish-subscription" requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions MAY be terminated by terminating the underlying NETCONF session. The publisher MAY also suspend or terminate a subset of the active subscriptions on that NETCONF session in order to reclaim resources and preserve normal operation for the other subscriptions.
このドキュメントでは、[RFC8639]で説明されているものを超える、動的サブスクリプションのセキュリティに関する追加の考慮事項は紹介していません。ただし、NETCONFの接続指向の性質に基づいて、さらに改良する価値のある考慮事項が1つあります。具体的には、バグの多いまたは侵害されたNETCONFサブスクライバが多数の「確立サブスクリプション」要求を送信すると、これらのサブスクリプションが蓄積し、システムリソースを使い果たす可能性があります。このような状況では、基になるNETCONFセッションを終了することにより、サブスクリプションを終了することができます。パブリッシャは、リソースを再利用し、他のサブスクリプションの通常の操作を維持するために、そのNETCONFセッションでアクティブなサブスクリプションのサブセットを一時停止または終了する場合もあります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.
[RFC5277] Chisholm、S。およびH. Trevino、「NETCONFイベント通知」、RFC 5277、DOI 10.17487 / RFC5277、2008年7月、<https://www.rfc-editor.org/info/rfc5277>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、A。Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.
[RFC8639] Voit、E.、Clemm、A.、Gonzalez Prieto、A.、Nilsen-Nygaard、E。、およびA. Tripathy、「Subscription to YANG Notifications」、RFC 8639、DOI 10.17487 / RFC8639、2019年9月、< https://www.rfc-editor.org/info/rfc8639>。
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8641] Clemm、A。およびE. Voit、「データストア更新のためのYANG通知のサブスクリプション」、RFC 8641、DOI 10.17487 / RFC8641、2019年9月、<https://www.rfc-editor.org/info/rfc8641> 。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<https://www.w3.org/TR/2008/REC-xml-20081126>。
[RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. Zhang, "A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)", RFC 8347, DOI 10.17487/RFC8347, March 2018, <https://www.rfc-editor.org/info/rfc8347>.
[RFC8347] Liu、X.、Ed。、Kyparlis、A.、Parikh、R.、Lindem、A.、and M. Zhang、 "A YANG Data Model for the Virtual Router Redundancy Protocol（VRRP）"、RFC 8347、 DOI 10.17487 / RFC8347、2018年3月、<https://www.rfc-editor.org/info/rfc8347>。
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", November 1999, <https://www.w3.org/TR/1999/REC-xpath-19991116>.
[XPATH] Clark、J.およびS. DeRose、「XML Path Language（XPath）Version 1.0」、1999年11月、<https://www.w3.org/TR/1999/REC-xpath-19991116>。
This appendix is non-normative. Additionally, the subscription "id" values of 22, 23, 39, and 99 used below are just examples. In production, the actual values of "id" might not be small integers.
この付録は非規範的です。さらに、以下で使用されるサブスクリプションの「id」値22、23、39、および99は単なる例です。本番環境では、「id」の実際の値は短整数ではない場合があります。
As defined in [RFC8639], an event stream exposes a continuous set of events available for subscription. A NETCONF client can retrieve the list of available event streams from a NETCONF publisher using the <get> operation against the top-level "streams" container defined in [RFC8639], Section 3.1.
[RFC8639]で定義されているように、イベントストリームは、サブスクリプションに使用できる一連のイベントを公開します。 NETCONFクライアントは、[RFC8639]のセクション3.1で定義されている最上位の「ストリーム」コンテナに対して<get>操作を使用して、NETCONFパブリッシャーから使用可能なイベントストリームのリストを取得できます。
The following XML example [W3C.REC-xml-20081126] illustrates the retrieval of the list of available event streams:
次のXMLの例[W3C.REC-xml-20081126]は、使用可能なイベントストリームのリストの取得を示しています。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<streams
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"/>
</filter>
</get>
</rpc>
Figure 1: <get> Request for Retrieval of Event Streams
After such a request, the NETCONF publisher returns a list of available event streams as well as additional information that might exist in the container.
このような要求の後、NETCONFパブリッシャーは、使用可能なイベントストリームのリストと、コンテナーに存在する可能性のある追加情報を返します。
Figure 2 shows two successful "establish-subscription" RPC requests as per [RFC8639]. The first request is given a subscription "id" of 22, and the second is given an "id" of 23.
図2は、[RFC8639]による2つの成功した「確立サブスクリプション」RPC要求を示しています。最初のリクエストには22のサブスクリプション「id」が与えられ、2番目のリクエストには23の「id」が与えられます。
+------------+ +-----------+
| Subscriber | | Publisher |
+------------+ +-----------+
| |
| Capability Exchange |
|<---------------------------->|
| |
| |
| establish-subscription |
|----------------------------->| (a)
| RPC Reply: OK, id = 22 |
|<-----------------------------| (b)
| |
| notification message (for 22)|
|<-----------------------------|
| |
| |
| establish-subscription |
|----------------------------->|
| notification message (for 22)|
|<-----------------------------|
| RPC Reply: OK, id = 23 |
|<-----------------------------|
| |
| |
| notification message (for 22)|
|<-----------------------------|
| notification message (for 23)|
|<-----------------------------|
| |
Figure 2: Multiple Subscriptions over a NETCONF Session
図2：NETCONFセッションでの複数のサブスクリプション
To provide examples of the information being transported, example messages for interactions (a) and (b) in Figure 2 are detailed below (Figures 3 and 4):
転送される情報の例を提供するために、図2の相互作用（a）および（b）のメッセージ例を以下に示します（図3および4）。
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<stream-xpath-filter xmlns:ex="https://example.com/events">
/ex:foo/
</stream-xpath-filter>
<stream>NETCONF</stream>
<dscp>10</dscp>
</establish-subscription>
</rpc>
Figure 3: "establish-subscription" Request (a)
図3：「サブスクリプションの確立」リクエスト（a）
As the NETCONF publisher was able to fully satisfy the request (a), the publisher sends the subscription "id" of the accepted subscription in its reply message (b):
NETCONFパブリッシャーは要求を完全に満たすことができたため（a）、パブリッシャーは応答メッセージで受け入れられたサブスクリプションのサブスクリプション "id"を送信します（b）：
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
22
</id>
</rpc-reply>
Figure 4: A Successful "establish-subscription" (b)
図4：成功した「確立サブスクリプション」（b）
If the NETCONF publisher had not been able to fully satisfy the request or the subscriber has no authorization to establish the subscription, the publisher would have sent an RPC error response. For instance, if the "dscp" value of 10 asserted by the subscriber in Figure 3 proved unacceptable, the publisher may have returned:
NETCONFパブリッシャーが要求を完全に満たすことができなかった場合、またはサブスクライバーにサブスクリプションを確立する権限がない場合、パブリッシャーはRPCエラー応答を送信したはずです。たとえば、図3のサブスクライバーによってアサートされた「dscp」値10が受け入れられない場合、パブリッシャーは次のように返した可能性があります。
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-app-tag>
ietf-subscribed-notifications:dscp-unavailable
</error-app-tag>
</rpc-error>
</rpc-reply>
Figure 5: An Unsuccessful "establish-subscription"
図5：失敗した「確立サブスクリプション」
The subscriber can use this information in future attempts to establish a subscription.
サブスクライバーは、サブスクリプションを確立するための将来の試みでこの情報を使用できます。
An existing subscription may be modified. The following exchange shows a negotiation of such a modification via several exchanges between a subscriber and a publisher. This negotiation consists of a failed RPC modification request/response followed by a successful one.
既存のサブスクリプションは変更される場合があります。次のエクスチェンジは、サブスクライバーとパブリッシャー間のいくつかのエクスチェンジを介したこのような変更のネゴシエーションを示しています。このネゴシエーションは、RPC変更要求/応答が失敗した後に成功したもので構成されます。
+------------+ +-----------+
| Subscriber | | Publisher |
+------------+ +-----------+
| |
| notification message (for 23)|
|<-----------------------------|
| |
| modify-subscription (id = 23)|
|----------------------------->| (c)
| RPC error (with hint) |
|<-----------------------------| (d)
| |
| modify-subscription (id = 23)|
|----------------------------->|
| RPC Reply: OK |
|<-----------------------------|
| |
| notification message (for 23)|
|<-----------------------------|
| |
Figure 6: Interaction Model for Successful Subscription Modification
図6：サブスクリプションの変更を成功させるための相互作用モデル
If the subscription being modified in Figure 6 is a datastore subscription as per [RFC8641], the modification request made in (c) may look like that shown in Figure 7. As can be seen, the modifications being attempted are the application of a new XPath filter as well as the setting of a new periodic time interval.
図6で変更されているサブスクリプションが[RFC8641]のデータストアサブスクリプションである場合、（c）で行われた変更要求は、図7に示されているもののようになる可能性があります。 XPathフィルター、および新しい定期的な時間間隔の設定。
<rpc message-id="303"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<modify-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>23</id>
<yp:datastore-xpath-filter xmlns:ex="https://example.com/datastore">
/ex:foo/ex:bar
</yp:datastore-xpath-filter>
<yp:periodic>
<yp:period>500</yp:period>
</yp:periodic>
</modify-subscription>
</rpc>
Figure 7: Subscription Modification Request (c)
図7：サブスクリプション変更リクエスト（c）
If the NETCONF publisher can satisfy both changes, the publisher sends a positive result for the RPC. If the NETCONF publisher cannot satisfy either of the proposed changes, the publisher sends an RPC error response (d). Figure 8 shows an example RPC error response for (d) that includes a hint. This hint is an alternative time period value that might have resulted in a successful modification:
NETCONFパブリッシャーが両方の変更を満たすことができる場合、パブリッシャーはRPCの肯定的な結果を送信します。 NETCONFパブリッシャーが提案された変更のいずれかを満たすことができない場合、パブリッシャーはRPCエラー応答（d）を送信します。図8は、ヒントを含む（d）のRPCエラー応答の例を示しています。このヒントは、変更が成功した可能性のある別の期間値です。
<rpc-reply message-id="303"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-app-tag>
ietf-yang-push:period-unsupported
</error-app-tag>
<error-info>
<modify-subscription-datastore-error-info
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<period-hint>
3000
</period-hint>
</modify-subscription-datastore-error-info>
</error-info>
</rpc-error>
</rpc-reply>
Figure 8: "modify-subscription" Failure with Hint (d)
図8：ヒント付きの「サブスクリプションの変更」の失敗（d）
Figure 9 demonstrates the deletion of a subscription. This subscription may have been to either a stream or a datastore.
図9は、サブスクリプションの削除を示しています。このサブスクリプションは、ストリームまたはデータストアのいずれかであった可能性があります。
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<id>22</id>
</delete-subscription>
</rpc>
Figure 9: "delete-subscription"
図9：「サブスクリプションの削除」
If the NETCONF publisher can satisfy the request, the publisher returns a reply indicating success.
NETCONFパブリッシャーが要求を満たすことができる場合、パブリッシャーは成功を示す応答を返します。
If the NETCONF publisher cannot satisfy the request, the publisher sends an <rpc-error> element indicating that the modification didn't work. Figure 10 shows a valid response for an existing valid subscription "id", but that subscription "id" was created on a different NETCONF transport session:
NETCONFパブリッシャーが要求を満たすことができない場合、パブリッシャーは<rpc-error>要素を送信して、変更が機能しなかったことを示します。図10は、既存の有効なサブスクリプション「id」に対する有効な応答を示していますが、そのサブスクリプション「id」は別のNETCONFトランスポートセッションで作成されています。
<rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-app-tag>
ietf-subscribed-notifications:no-such-subscription
</error-app-tag>
</rpc-error>
</rpc-reply>
Figure 10: An Unsuccessful "delete-subscription"
図10：失敗した「サブスクリプションの削除」
A publisher will send subscription state notifications for dynamic subscriptions according to the definitions in [RFC8639].
パブリッシャーは、[RFC8639]の定義に従って、動的サブスクリプションのサブスクリプション状態通知を送信します。
As per Section 2.7.2 of [RFC8639], a "subscription-modified" might be sent over NETCONF if the definition of a configured filter changes. A subscription state notification encoded in XML would look like:
[RFC8639]のセクション2.7.2に従って、構成されたフィルターの定義が変更された場合、「サブスクリプション変更」がNETCONF経由で送信される可能性があります。 XMLでエンコードされたサブスクリプション状態通知は次のようになります。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-modified
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<id>39</id>
<stream-xpath-filter xmlns:ex="https://example.com/events">
/ex:foo
</stream-xpath-filter>
<stream>NETCONF</stream>
</subscription-modified>
</notification>
Figure 11: "subscription-modified" Subscription State Notification
図11：「サブスクリプションが変更された」サブスクリプション状態通知
A "subscription-resumed" would look like:
「サブスクリプション再開」は次のようになります。
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-resumed
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<id>39</id>
</subscription-resumed>
</notification>
Figure 12: "subscription-resumed" Notification
図12：「サブスクリプション再開」通知
The "replay-complete" is virtually identical, with "subscription-resumed" simply being replaced by "replay-complete".
「リプレイ完了」は実質的に同一であり、「サブスクリプション再開」は単に「リプレイ完了」に置き換えられます。
A "subscription-terminated" would look like:
「サブスクリプション終了」は次のようになります。
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-terminated
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<id>39</id>
<reason>
suspension-timeout
</reason>
</subscription-terminated>
</notification>
Figure 13: "subscription-terminated" Subscription State Notification
図13：「サブスクリプション終了」サブスクリプション状態通知
The "subscription-suspended" is virtually identical, with "subscription-terminated" simply being replaced by "subscription-suspended".
「サブスクリプションの一時停止」は実質的に同一であり、「サブスクリプション終了」は単に「サブスクリプションの一時停止」に置き換えられます。
This appendix provides examples that illustrate both XPath and subtree methods of filtering event record contents. The examples are based on the YANG notification "vrrp-protocol-error-event" as defined per the ietf-vrrp YANG data model in [RFC8347]. Event records based on this specification that are generated by the publisher might appear as:
この付録では、イベントレコードの内容をフィルタリングするXPathメソッドとサブツリーメソッドの両方を示す例を示します。これらの例は、[RFC8347]のietf-vrrp YANGデータモデルで定義されているYANG通知「vrrp-protocol-error-event」に基づいています。この仕様に基づいて発行元によって生成されたイベントレコードは、次のように表示されます。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2018-09-14T08:22:33.44Z</eventTime>
<vrrp-protocol-error-event
xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
<protocol-error-reason>checksum-error</protocol-error-reason>
</vrrp-protocol-error-event>
</notification>
Figure 14: Example VRRP Notification per RFC 8347
図14：RFC 8347に基づくVRRP通知の例
Suppose that a subscriber wanted to establish a subscription that only passes instances of event records where there is a "checksum-error" as part of a Virtual Router Redundancy Protocol (VRRP) protocol event. Also, assume that the publisher places such event records into the NETCONF stream. To get a continuous series of matching event records, the subscriber might request the application of an XPath filter against the NETCONF stream. An "establish-subscription" RPC to meet this objective might be:
サブスクライバーが、仮想ルーター冗長プロトコル（VRRP）プロトコルイベントの一部として「チェックサムエラー」があるイベントレコードのインスタンスのみを渡すサブスクリプションを確立したいとします。また、パブリッシャーがそのようなイベントレコードをNETCONFストリームに配置するとします。連続する一連の一致するイベントレコードを取得するには、サブスクライバーがNETCONFストリームに対してXPathフィルターの適用を要求する場合があります。この目標を達成するための「確立サブスクリプション」RPCは次のようになります。
<rpc message-id="601" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<stream>NETCONF</stream>
<stream-xpath-filter xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
/vrrp-protocol-error-event[
vrrp:protocol-error-reason="vrrp:checksum-error"]
</stream-xpath-filter>
</establish-subscription>
</rpc>
Figure 15: Establishing a Subscription Error Reason via XPath
図15：XPathを介したサブスクリプションエラーの理由の確立
For more examples of XPath filters, see [XPATH].
XPathフィルターのその他の例については、[XPATH]を参照してください。
Suppose that the "establish-subscription" in Figure 15 was accepted. And suppose that a subscriber decided later on that they wanted to broaden this subscription to cover all VRRP protocol events (i.e., not just those with a "checksum-error"). The subscriber might attempt to modify the subscription in a way that replaces the XPath filter with a subtree filter that sends all VRRP protocol events to a subscriber. Such a "modify-subscription" RPC might look like:
図15の「establish-subscription」が受け入れられたとします。そして、サブスクライバーが後ですべてのVRRPプロトコルイベント（つまり、「チェックサムエラー」があるイベントだけではない）をカバーするようにこのサブスクリプションを拡大することを決定したと仮定します。サブスクライバーは、XPathフィルターをすべてのVRRPプロトコルイベントをサブスクライバーに送信するサブツリーフィルターに置き換える方法で、サブスクリプションを変更しようとする場合があります。このような「変更サブスクリプション」RPCは次のようになります。
<rpc message-id="602" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<modify-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<id>99</id>
<stream-subtree-filter>
<vrrp-protocol-error-event
xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp"/>
</stream-subtree-filter>
</modify-subscription>
</rpc>
Figure 16: Example "modify-subscription" RPC
図16：「modify-subscription」RPCの例
For more examples of subtree filters, see [RFC6241], Section 6.4.
サブツリーフィルタのその他の例については、[RFC6241]のセクション6.4をご覧ください。
Acknowledgments
謝辞
We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Andy Bierman, Yan Gang, Sharon Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, Qin Wu, and Guangying Zheng.
Andy Bierman、Yan Gang、Sharon Chisholm、Hector Trevino、Peipei Guo、Susan Hares、Tim Jenkins、Balazs Lengyel、Martin Bjorklund、Mahesh Jethanandani、Kent Watsen、Qinから寄せられた有益な貢献、コメント、提案に感謝します呉、広英鄭。
Authors' Addresses
著者のアドレス
Eric Voit Cisco Systems
Eric Voit Cisco Systems
Email: evoit@cisco.com
Alexander Clemm Futurewei
アレクサンダークレムフューチャーウェイ
Email: ludwig@clemm.org
Alberto Gonzalez Prieto Microsoft
アルベルトゴンザレスプリエトマイクロソフト
Email: alberto.gonzalez@microsoft.com
Einar Nilsen-Nygaard Cisco Systems
Einar Nilsen-Nygaard Cisco Systems
Email: einarnn@cisco.com
Ambika Prasad Tripathy Cisco Systems
Ambika Prasad Tripathy Cisco Systems
Email: ambtripa@cisco.com