[要約] RFC 7923は、YANGデータストアへのサブスクリプションの要件を定義しています。その目的は、ネットワークデバイスの状態変更を監視するための効果的なメカニズムを提供することです。
Internet Engineering Task Force (IETF) E. Voit
Request for Comments: 7923 A. Clemm
Category: Informational A. Gonzalez Prieto
ISSN: 2070-1721 Cisco Systems
June 2016
Requirements for Subscription to YANG Datastores
YANGデータストアのサブスクリプションの要件
Abstract
概要
This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.
このドキュメントでは、クライアントアプリケーションがYANGデータストアの更新をサブスクライブできるようにするサービスの要件について説明します。サブスクリプションの一部として交渉された基準に基づいて、更新が対象の受信者にプッシュされます。このような機能により、アプリケーションによるYANGデータストアの定期的なポーリングが不要になり、既存のYANGトランスポート（つまり、ネットワーク構成プロトコル（NETCONF）とRESTCONF）の機能ギャップが埋められます。このようなサービスは、YANGデータストア更新用の「pub / sub」サービスとして要約できます。サービスの一連の基本的な要件以外にも、さまざまな改良が行われています。これらの改良には、オブジェクト更新の周期性、要求されたサブツリーの下のオブジェクトのフィルタリング、および配信QoS保証が含まれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc7923.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7923で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Business Drivers ................................................3
2.1. Pub/Sub in the Interface to the Routing System (I2RS) ......4
2.2. Pub/Sub Variants on Network Elements .......................5
2.3. Existing Generalized Pub/Sub Implementations ...............6
3. Terminology .....................................................6
4. Requirements ....................................................7
4.1. Assumptions for Subscriber Behavior ........................7
4.2. Subscription Service Requirements ..........................8
4.2.1. General .............................................8
4.2.2. Negotiation .........................................9
4.2.3. Update Distribution ................................10
4.2.4. Transport ..........................................11
4.2.5. Security Requirements ..............................11
4.2.6. Subscription QoS ...................................13
4.2.7. Filtering ..........................................14
4.2.8. Assurance and Monitoring ...........................15
5. Security Considerations ........................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................18
Applications interacting with YANG datastores require capabilities beyond the traditional client-server configuration of network elements. One class of such applications are service-assurance applications, which must maintain a continuous view of operational data and state. Another class of applications are security applications, which must continuously track changes made upon network elements to ensure compliance with corporate policy.
YANGデータストアと対話するアプリケーションには、ネットワーク要素の従来のクライアントサーバー構成を超える機能が必要です。そのようなアプリケーションの1つのクラスはサービス保証アプリケーションであり、運用データと状態の継続的なビューを維持する必要があります。別のクラスのアプリケーションはセキュリティアプリケーションで、企業のポリシーに確実に準拠するために、ネットワーク要素に加えられた変更を継続的に追跡する必要があります。
Periodic fetching of data is not an adequate solution for applications requiring frequent or prompt updates of remote object state. Applying polling-based solutions here imposes a load on networks, devices, and applications. Additionally, polling solutions are brittle in the face of communication glitches, and have limitations in their ability to synchronize and calibrate retrieval intervals across a network. These limitations can be addressed by including generic object subscription mechanisms within network elements, and allowing these mechanisms to be applied in the context of data that is conceptually contained in YANG datastores.
データの定期的なフェッチは、リモートオブジェクトの状態を頻繁に、または迅速に更新する必要があるアプリケーションには適切なソリューションではありません。ここでポーリングベースのソリューションを適用すると、ネットワーク、デバイス、およびアプリケーションに負荷がかかります。さらに、ポーリングソリューションは通信の問題に直面して壊れやすく、ネットワーク全体で検索間隔を同期および調整する機能に制限があります。これらの制限は、ネットワーク要素内に汎用オブジェクトサブスクリプションメカニズムを含め、YANGデータストアに概念的に含まれているデータのコンテキストでこれらのメカニズムを適用できるようにすることで対処できます。
This document aggregates requirements for such subscription from a variety of deployment scenarios.
このドキュメントでは、さまざまな展開シナリオからのそのようなサブスクリプションの要件をまとめています。
For decades, information delivery of current network state has been accomplished either by fetching from operations interfaces, or via dedicated, customized networking protocols. With the growth of centralized orchestration infrastructures, imperative policy distribution, and YANG's ascent as the dominant data modeling language for use in programmatic interfaces to network elements, this mixture of fetch plus custom networking protocols is no longer sufficient. What is needed is a push mechanism that is able to deliver object changes as they happen.
何十年もの間、現在のネットワーク状態の情報配信は、操作インターフェースからフェッチするか、専用のカスタマイズされたネットワークプロトコルを介して行われてきました。集中化されたオーケストレーションインフラストラクチャの成長、命令型のポリシー配布、およびネットワーク要素へのプログラムインターフェイスで使用する主要なデータモデリング言語としてのYANGの上昇により、フェッチとカスタムネットワークプロトコルのこの混合ではもはや十分ではありません。必要なのは、オブジェクトの変更が発生したときにそれを配信できるプッシュメカニズムです。
These push distribution mechanisms will not replace existing networking protocols. Instead they will supplement these protocols, providing different response time, peering, scale, and security characteristics.
これらのプッシュ配信メカニズムは、既存のネットワークプロトコルを置き換えるものではありません。代わりに、これらはこれらのプロトコルを補足し、異なる応答時間、ピアリング、スケール、およびセキュリティ特性を提供します。
Push solutions will not displace all existing operations infrastructure needs. And SNMP and MIBs will remain widely deployed and the de facto choice for many monitoring solutions. But some functions could be displaced. Arguably the biggest shortcoming of SNMP for those applications concerns the need to rely on periodic polling, because it introduces an additional load on the network and devices, because it is brittle if polling cycles are missed, and because it is hard to synchronize and calibrate across a network. If applications can only use polling type interaction patterns with YANG datastores, similar issues can be expected.
プッシュソリューションは、既存の運用インフラストラクチャのニーズすべてを置き換えるものではありません。また、SNMPとMIBは広く導入されたままであり、多くの監視ソリューションの事実上の選択です。ただし、一部の機能が置き換えられる可能性があります。間違いなく、これらのアプリケーションのSNMPの最大の欠点は、定期的なポーリングに依存する必要があることです。これは、ネットワークとデバイスに追加の負荷をもたらし、ポーリングサイクルが失われると脆弱になり、全体で同期および調整が困難になるためです。ネットワーク。アプリケーションがYANGデータストアでポーリングタイプの相互作用パターンのみを使用できる場合、同様の問題が予想されます。
Various documents about the Interface to the Routing System (I2RS) highlight the need to provide pub/sub capabilities between network elements. From [RFC7921], there are references throughout the document beginning in Section 6.2. Some specific examples include:
ルーティングシステムへのインターフェイス（I2RS）に関するさまざまなドキュメントでは、ネットワーク要素間にpub / sub機能を提供する必要性が強調されています。 [RFC7921]から、セクション6.2から始まるドキュメント全体に参照があります。いくつかの具体的な例は次のとおりです。
o Section 7.6 of [RFC7921] provides high-level pub/sub (notification) guidance.
o [RFC7921]のセクション7.6は、高レベルのpub / sub（通知）ガイダンスを提供します。
o Section 6.4.2 of [RFC7921] identifies "subscribing to an information stream of route changes" and "receiving notifications about peers coming up or going down".
o [RFC7921]のセクション6.4.2は、「ルート変更の情報ストリームへのサブスクライブ」と「ピアのアップまたはダウンに関する通知の受信」を示しています。
o Section 6.3 of [RFC7921] notes that when Local Configuration preempts I2RS, external notification might be necessary.
o [RFC7921]のセクション6.3は、ローカル構成がI2RSを横取りするときに、外部通知が必要になる場合があることを述べています。
In addition, [USECASE] has relevant requirements. A small subset includes:
さらに、[USECASE]には関連する要件があります。小さなサブセットには以下が含まれます：
o L-Data-REQ-12: The I2RS interface should support user subscriptions to data with the following parameters: push of data synchronously or asynchronously via registered subscriptions...
o L-Data-REQ-12：I2RSインターフェイスは、次のパラメーターを持つデータへのユーザーサブスクリプションをサポートする必要があります：登録済みサブスクリプションを介したデータの同期または非同期のプッシュ...
o L-DATA-REQ-07: The I2RS interface (protocol and instant messages (IMs)) should allow a subscriber to select portions of the data model.
o L-DATA-REQ-07：I2RSインターフェイス（プロトコルとインスタントメッセージ（IM））により、サブスクライバーはデータモデルの一部を選択できます。
o PI-REQ01: Monitor the available routes installed in the Routing Information Base (RIB) of each forwarding device, including near real-time notification of route installation and removal.
o PI-REQ01：ルートのインストールと削除のほぼリアルタイムの通知を含め、各転送デバイスのルーティング情報ベース（RIB）にインストールされている利用可能なルートを監視します。
o BGP-REQ10: The I2RS client SHOULD be able to instruct the I2RS agent(s) to notify the I2RS client when the BGP processes on an associated routing system observe a route change to a specific set of IP Prefixes and associated prefixes.... The I2RS agent should be able to notify the client via the publish or subscribe mechanism.
o BGP-REQ10：I2RSクライアントは、関連するルーティングシステムのBGPプロセスが特定のIPプレフィックスと関連するプレフィックスのセットへのルート変更を観察したときにI2RSクライアントに通知するようにI2RSエージェントに指示できる必要があります（SHOULD）。 I2RSエージェントは、パブリッシュまたはサブスクライブメカニズムを介してクライアントに通知できる必要があります。
o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a mechanism where the I2RS Clients can subscribe to the I2RS Agent's notification of critical node IGP events.
o IGP-REQ-07：I2RSインターフェイス（プロトコルとIM）は、I2RSクライアントがI2RSエージェントの重要なノードIGPイベントの通知にサブスクライブできるメカニズムをサポートする必要があります。
o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS client to subscribe to a stream of state changes regarding the LDP sessions or LDP Label Switched Paths (LSPs) from the I2RS Agent.
o MPLS-LDP-REQ-03：I2RSエージェント通知は、I2RSクライアントが、I2RSエージェントからのLDPセッションまたはLDPラベルスイッチドパス（LSP）に関する状態変更のストリームにサブスクライブできるようにする必要があります。
o L-Data-REQ-01: I2RS must be able to collect large data sets from the network with high frequency and resolution, and with minimal impact to the device's CPU and memory.
o L-Data-REQ-01：I2RSは、ネットワークから大きなデータセットを高い周波数と解像度で収集でき、デバイスのCPUとメモリへの影響を最小限に抑える必要があります。
Also, Section 7.4.3 of [RFC7922] includes this pub/sub requirement:
また、[RFC7922]のセクション7.4.3には、このpub / sub要件が含まれています。
o I2RS agents MUST support publishing I2RS trace log information to that feed as described in [this document]. Subscribers would then receive a live stream of I2RS interactions in trace log format and could flexibly choose to do a number of things with the log messages.
o [このドキュメント]で説明されているように、I2RSエージェントは、そのフィードへのI2RSトレースログ情報の公開をサポートする必要があります。その後、サブスクライバーは、I2RS対話のライブストリームをトレースログ形式で受信し、ログメッセージを使用してさまざまな処理を柔軟に選択できます。
This document is intended to cover requirements beyond I2RS. Looking at history, there are many examples of switching and routing protocols that have done explicit or implicit pub/sub in the past. In addition, new policy notification mechanisms that operate on switches and routers are being specified now. A small subset of current and past subscription mechanisms includes:
このドキュメントは、I2RSを超える要件を対象としています。歴史を見ると、過去に明示的または暗黙的なpub / subを行ったスイッチングおよびルーティングプロトコルの例がたくさんあります。さらに、スイッチとルーターで動作する新しいポリシー通知メカニズムが現在指定されています。現在および過去のサブスクリプションメカニズムの小さなサブセットは次のとおりです。
o Multicast topology establishment is accomplished before any content delivery is made to endpoints (IGMP, PIM, etc.).
o マルチキャストトポロジの確立は、エンドポイント（IGMP、PIMなど）へのコンテンツ配信が行われる前に行われます。
o Secure Automation and Continuous Monitoring (SACM) allows subscription into devices, which may then push spontaneous changes in their configured hardware and software [SACMREQ].
o Secure Automation and Continuous Monitoring（SACM）は、デバイスへのサブスクリプションを許可します。これにより、構成されたハードウェアおよびソフトウェアの自発的な変更がプッシュされる可能性があります[SACMREQ]。
o In MPLS VPNs [RFC6513], a Customer Edge router exchanges PIM control messages before Provider Edge (PE) Routing Adjacencies are passed [RFC6513].
o MPLS VPN [RFC6513]では、カスタマーエッジルーターはプロバイダーエッジ（PE）ルーティング隣接が渡される前にPIM制御メッセージを交換します[RFC6513]。
o After OSPF establishes its adjacencies, Link State Advertisement will then commence [RFC2328].
o OSPFが隣接関係を確立した後、リンクステートアドバタイズメントが開始されます[RFC2328]。
Worthy of note in the examples above is the wide variety of underlying transports. A generalized pub/sub mechanism, therefore should be structured to support alternative transports. Based on current I2RS requirements, NETCONF should be the initially supported transport due to the need for connection-oriented/unicast communication. Eventual support for multicast and broadcast subscription update distribution will be needed as well.
上記の例で注目に値するのは、基礎となるさまざまなトランスポートです。したがって、一般化されたpub / subメカニズムは、代替トランスポートをサポートするように構成する必要があります。現在のI2RS要件に基づいて、接続指向/ユニキャスト通信が必要なため、NETCONFが最初にサポートされるトランスポートである必要があります。マルチキャストおよびブロードキャストのサブスクリプション更新配布の最終的なサポートも必要になります。
TIBCO, RSS, Common Object Request Broker Architecture (CORBA), and other technologies all show precursor pub/sub technologies. However, there are new needs (described in Section 4 below) that these technologies do not serve. We need a new pub/sub technology.
TIBCO、RSS、Common Object Request Broker Architecture（CORBA）、およびその他のテクノロジーはすべて、先行するpub / subテクノロジーを示しています。ただし、これらのテクノロジーでは対応できない新しいニーズがあります（以下のセクション4で説明）。新しいpub / subテクノロジーが必要です。
There are at least two widely deployed generalized pub/sub implementations that come close to current needs: Extensible Messaging and Presence Protocol (XMPP) [XEP-0060] and Data Distribution Service (DDS) [OMG-DDS]. Both serve as proof-points that a highly scalable distributed datastore implementation connecting millions of edge devices is possible.
現在のニーズに近い、少なくとも2つの広く展開されている一般化されたpub / subの実装があります。拡張可能なメッセージングとプレゼンスプロトコル（XMPP）[XEP-0060]とデータ配布サービス（DDS）[OMG-DDS]です。どちらも、何百万ものエッジデバイスを接続する非常にスケーラブルな分散データストアの実装が可能であることを証明する役割を果たします。
Because of these proof-points, we can be comfortable that the underlying technologies can enable reusable generalized YANG object distribution. Analysis will need to fully dimension the speed and scale of such object distribution for various subtree sizes and transport types.
これらの証拠により、基盤となるテクノロジーが再利用可能な一般化されたYANGオブジェクトの配布を可能にすることは安心できます。分析では、さまざまなサブツリーサイズとトランスポートタイプについて、そのようなオブジェクト分散の速度とスケールを完全に分析する必要があります。
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]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。このドキュメントはプロトコル仕様ではありませんが、この言語を使用することで、このドキュメントに記載されている要件を満たすソリューションを作成するプロトコル設計者への指示が明確になります。
A Subscriber makes requests for set(s) of YANG object data.
サブスクライバーは、YANGオブジェクトデータのセットを要求します。
A Publisher is responsible for distributing subscribed YANG object data per the terms of a subscription. In general, a Publisher is the owner of the YANG datastore that is subjected to the subscription.
パブリッシャーは、サブスクリプションの条件に従ってサブスクライブされたYANGオブジェクトデータを配布する責任があります。通常、パブリッシャーはサブスクリプションの対象となるYANGデータストアの所有者です。
A Receiver is the target to which a Publisher pushes updates. In general, the Receiver and Subscriber will be the same entity. A Subscription Service provides subscriptions to Subscribers of YANG data.
レシーバーは、パブリッシャーが更新をプッシュするターゲットです。一般に、レシーバーとサブスクライバーは同じエンティティになります。 Subscription Serviceは、YANGデータのサブスクライバーにサブスクリプションを提供します。
A Subscription Service interacts with the Publisher of the YANG data as needed to provide the data per the terms of the subscription.
サブスクリプションサービスは、必要に応じてYANGデータのパブリッシャーと対話し、サブスクリプションの条件に従ってデータを提供します。
A subscription request for one or more YANG subtrees (including single leafs) is made by the Subscriber of a Publisher and is targeted to a Receiver. A subscription may include constraints that dictate how often or under what conditions YANG information updates might be sent.
1つ以上のYANGサブツリー（単一のリーフを含む）のサブスクリプション要求は、パブリッシャーのサブスクライバーによって行われ、レシーバーをターゲットとします。サブスクリプションには、YANG情報の更新が送信される頻度または条件を決定する制約が含まれる場合があります。
A subscription is a contract between a Subscription Service and a Subscriber that stipulates the data to be pushed and the associated terms.
サブスクリプションは、プッシュされるデータと関連する条件を規定するサブスクリプションサービスとサブスクライバーの間の契約です。
A datastore is defined in [RFC6241].
データストアは[RFC6241]で定義されています。
An Update provides object changes that have occurred within subscribed YANG subtree(s). An Update must include the current status of (data) node instances for which filtering has indicated they have different status than previously provided. An Update may include a bundled set of ordered/sequential changes for a given object that have been made since the last update.
Updateは、サブスクライブされたYANGサブツリー内で発生したオブジェクトの変更を提供します。更新には、（データ）ノードインスタンスの現在のステータスが含まれている必要があります。これにより、フィルタリングによって、以前に提供されたものとは異なるステータスを持つことが示されます。更新には、最後の更新以降に行われた、指定されたオブジェクトの順序付き/順次変更のバンドルされたセットが含まれる場合があります。
A Filter contains evaluation criteria, which are evaluated against YANG object(s) within a subscription. There are two types of Filters: Subtree Filters, which identify selected objects/nodes published under a target data node, and object element and attribute Filters where an object should only be published if it has properties meeting specified Filter criteria.
フィルターには、サブスクリプション内のYANGオブジェクトに対して評価される評価基準が含まれています。フィルターには、ターゲットデータノードの下で公開されている選択されたオブジェクト/ノードを識別するサブツリーフィルターと、指定されたフィルター基準を満たすプロパティがある場合にのみオブジェクトが公開されるオブジェクトエレメントおよび属性フィルターの2種類があります。
Many of the requirements within this section have been adapted from the XMPP [XEP-0060] and DDS [OMG-DDS] requirements specifications.
このセクション内の要件の多くは、XMPP [XEP-0060]およびDDS [OMG-DDS]要件仕様から適合されています。
This document provides requirements for the Subscription Service. It does not define all the requirements for the Subscriber/Receiver. However in order to frame the desired behavior of the Subscription Service, it is important to specify key input constraints.
このドキュメントでは、サブスクリプションサービスの要件について説明します。サブスクライバー/レシーバーのすべての要件を定義しているわけではありません。ただし、サブスクリプションサービスの望ましい動作をフレーミングするには、キー入力制約を指定することが重要です。
A Subscriber SHOULD avoid attempting to establish multiple subscriptions pertaining to the same information, i.e., referring to the same datastore YANG subtrees.
サブスクライバーは、同じ情報に関連する複数のサブスクリプションを確立すること、つまり同じデータストアのYANGサブツリーを参照することを試みないでください。
A Subscriber MAY provide subscription QoS criteria to the Subscription Service; if the Subscription Service is unable to meet those criteria, the subscription SHOULD NOT be established.
サブスクライバーは、サブスクリプションサービスにサブスクリプションQoS基準を提供できます。サブスクリプションサービスがこれらの基準を満たせない場合、サブスクリプションを確立してはなりません（SHOULD NOT）。
When a Subscriber and Receiver are the same entity and the transport session is lost/terminated, the Subscriber MUST re-establish any subscriptions it previously created via signaling over the transport session. That is, there is no requirement for the life span of such signaled subscriptions to extend beyond the life span of the transport session.
サブスクライバーとレシーバーが同じエンティティであり、トランスポートセッションが失われた/終了した場合、サブスクライバーは、トランスポートセッションを介したシグナリングによって以前に作成したサブスクリプションを再確立する必要があります。つまり、そのような通知されたサブスクリプションの寿命がトランスポートセッションの寿命を超えて延長する必要はありません。
A Subscriber MUST be able to infer when a Subscription Service is no longer active and when no more updates are being sent.
サブスクライバーは、サブスクリプションサービスがアクティブでなくなったとき、および更新が送信されなくなったときを推測できる必要があります。
A Subscriber MAY check with a Subscription Service to validate the existence and monitored subtrees of a subscription.
サブスクライバーは、サブスクリプションサービスをチェックして、サブスクリプションの存在と監視されているサブツリーを検証できます。
A Subscriber MUST be able to periodically lease and extend the lease of a subscription from a Subscription Service.
サブスクライバーは定期的にサブスクリプションサービスからサブスクリプションのリースをリースおよび延長できる必要があります。
A Subscription Service MUST support the ability to create, renew, time out, and terminate a subscription.
サブスクリプションサービスは、サブスクリプションを作成、更新、タイムアウト、および終了する機能をサポートする必要があります。
A Subscription Service MUST be able to support and independently track multiple subscription requests by the same Subscriber.
サブスクリプションサービスは、同じサブスクライバーによる複数のサブスクリプション要求をサポートし、独立して追跡できる必要があります。
A Subscription Service MUST be able to support an add/change/delete of subscriptions to multiple YANG subtrees as part of the same subscription request.
サブスクリプションサービスは、同じサブスクリプション要求の一部として、複数のYANGサブツリーへのサブスクリプションの追加/変更/削除をサポートできる必要があります。
A Subscription Service MUST support subscriptions against operational datastores, configuration datastores, or both.
サブスクリプションサービスは、運用データストア、構成データストア、またはその両方に対するサブスクリプションをサポートする必要があります。
A Subscription Service MUST be able support filtering so that the subscribed updates under a target node might publish only operational data, only configuration data, or both.
サブスクリプションサービスは、ターゲットノードでサブスクライブされた更新が運用データのみ、構成データのみ、またはその両方を公開できるように、フィルタリングをサポートできる必要があります。
A subscription MAY include Filters as defined within a subscription request, therefore the Subscription Service MUST publish only data nodes that meet the Filter criteria within a subscription.
サブスクリプションには、サブスクリプション要求内で定義されたフィルターが含まれる場合があります。そのため、サブスクリプションサービスは、サブスクリプション内のフィルター条件を満たすデータノードのみをパブリッシュする必要があります。
A Subscription Service MUST support the ability to subscribe to periodic updates. The subscription period MUST be configurable as part of the subscription request.
サブスクリプションサービスは、定期的な更新をサブスクライブする機能をサポートする必要があります。サブスクリプション期間は、サブスクリプション要求の一部として構成可能でなければなりません。
A Subscription Service SHOULD support the ability to subscribe to updates on-change, i.e., whenever values of subscribed data objects change.
サブスクリプションサービスは、変更時に更新をサブスクライブする機能をサポートする必要があります（つまり、サブスクライブされたデータオブジェクトの値が変更されるたびに）。
For on-change updates, the Subscription Service MUST support a dampening period that needs to be passed before the first or subsequent on-change updates are sent. The dampening period SHOULD be configurable as part of the subscription request.
変更時の更新の場合、サブスクリプションサービスは、最初または後続の変更時の更新が送信される前に渡す必要があるダンプニング期間をサポートする必要があります。ダンプニング期間は、サブスクリプション要求の一部として構成可能である必要があります（SHOULD）。
A Subscription Service MUST allow subscriptions to be monitored. Specifically, a Subscription Service MUST at a minimum maintain information about which subscriptions are being serviced, the terms of those subscriptions (e.g., what data is being subscribed, associated Filters, update policy -- on change, periodic), and the overall status of the subscription -- e.g., active or suspended.
サブスクリプションサービスでは、サブスクリプションを監視する必要があります。具体的には、サブスクリプションサービスは、サービスを提供しているサブスクリプション、それらのサブスクリプションの条件（たとえば、どのデータがサブスクライブされているか、関連するフィルター、更新ポリシー-変更時、定期的）、およびサブスクリプション-たとえば、アクティブまたは一時停止。
A Subscription Service MUST support the termination of a subscription when requested by the Subscriber.
サブスクリプションサービスは、サブスクライバーによって要求されたときにサブスクリプションの終了をサポートする必要があります。
A Subscription Service SHOULD support the ability to suspend and to resume a subscription on request of a client.
サブスクリプションサービスは、クライアントの要求に応じてサブスクリプションを一時停止および再開する機能をサポートする必要があります（SHOULD）。
A Subscription Service MAY at its discretion revoke or suspend an existing subscription. Reasons may include transitory resource limitation, credential expiry, failure to reconfirm a subscription, loss of connectivity with the Receiver, operator command-line interface (CLI), and/or others. When this occurs, the Subscription Service MUST notify the Subscriber and update the subscription status.
サブスクリプションサービスは、その裁量により、既存のサブスクリプションを無効または一時停止する場合があります。理由には、一時的なリソースの制限、資格情報の有効期限切れ、サブスクリプションの再確認の失敗、Receiverとの接続の喪失、オペレーターのコマンドラインインターフェイス（CLI）などが含まれます。これが発生した場合、サブスクリプションサービスはサブスクライバーに通知し、サブスクリプションのステータスを更新する必要があります。
A Subscription Service MAY offer the ability to modify a subscription Filter. If such an ability is offered, the service MUST provide subscribers with an indication telling at what point the modified subscription goes into effect.
サブスクリプションサービスは、サブスクリプションフィルターを変更する機能を提供する場合があります。そのような機能が提供されている場合、サービスは、変更されたサブスクリプションが有効になる時点を示す指示をサブスクライバーに提供する必要があります。
A Subscription Service MUST be able to negotiate the following terms of a subscription:
サブスクリプションサービスは、サブスクリプションの以下の条件をネゴシエートできる必要があります。
o The policy, i.e., whether updates are on-change or periodic
o ポリシー、つまり、更新が変更中か定期的か
o The interval, for periodic publication policy
o 定期的な発行ポリシーの間隔
o The on-change policy dampening period (if the on-change policy is supported)
o 変更時ポリシーのダンプニング期間（変更時ポリシーがサポートされている場合）
o Any Filters associated with a subtree subscription
o サブツリーサブスクリプションに関連付けられているすべてのフィルター
A Subscription Service SHOULD be able to negotiate QoS criteria for a subscription. Examples of subscription QoS criteria may include reliability of the Subscription Service, reaction time between a monitored YANG subtree/object change and a corresponding notification push, and the Subscription Service's ability to support certain levels of object liveliness.
サブスクリプションサービスは、サブスクリプションのQoS基準をネゴシエートできる必要があります（SHOULD）。サブスクリプションQoS基準の例には、サブスクリプションサービスの信頼性、監視対象のYANGサブツリー/オブジェクトの変更と対応する通知プッシュの間の反応時間、および特定のレベルのオブジェクトの活性をサポートするサブスクリプションサービスの機能が含まれます。
In cases where a subscription request cannot be fulfilled due to insufficient platform resources, the Subscription Service SHOULD include within its decline hints on criteria that would have been acceptable when the subscription request was made. For example, if periodic updates were requested with update intervals that were too short for the specified data set, an alternative acceptable interval period might be returned from the Publisher. If on-change updates were requested with too aggressive a dampening period, then an acceptable dampening period may be returned, or alternatively an indication that only periodic updates are supported for the requested object(s).
プラットフォームリソースが不足しているためにサブスクリプション要求を実行できない場合、サブスクリプションサービスは、サブスクリプション要求が行われたときに受け入れ可能であったであろう基準に関する拒否ヒントをその中に含める必要があります（SHOULD）。たとえば、指定されたデータセットに対して短すぎる更新間隔で定期的な更新が要求された場合、代替の許容可能な間隔期間がパブリッシャーから返されることがあります。過度のダンピング期間で変更時の更新が要求された場合、許容できるダンプニング期間が返されるか、要求されたオブジェクトに対して定期的な更新のみがサポートされているという表示が返されます。
For on-change updates, the Subscription Service MUST only send deltas to the object data for which a change occurred. (Otherwise the subscriber might not know what has actually undergone change.) The updates for each object MUST include an indication of whether it was removed, added, or changed.
変更時の更新の場合、サブスクリプションサービスは、変更が発生したオブジェクトデータにのみデルタを送信する必要があります。 （そうでない場合、サブスクライバーは実際に何が変更されたかを知らない可能性があります。）各オブジェクトの更新には、削除、追加、または変更されたかどうかの指示が含まれている必要があります。
When a Subscription Service is not able to send updates per its subscription contract, the subscription MUST notify subscribers and put the subscription into a state indicating that the subscription was suspended by the service. When able to resume service, subscribers need to be notified as well. If unable to resume service, the Subscription Service MAY terminate the subscription and notify Subscribers accordingly.
サブスクリプションサービスがサブスクリプション契約に従って更新を送信できない場合、サブスクリプションはサブスクライバーに通知し、サブスクリプションがサービスによって中断されたことを示す状態にする必要があります。サービスを再開できる場合は、加入者にも通知する必要があります。サービスを再開できない場合、サブスクリプションサービスはサブスクリプションを終了し、それに応じてサブスクライバーに通知する場合があります。
When a subscription with on-change updates is suspended and then resumed, the first update SHOULD include updates of any changes that occurred while the subscription was suspended, with the current value. The Subscription Service MUST provide a clear indication when this capability is not supported (because in this case, a client application may have to synchronize state separately).
変更時の更新を含むサブスクリプションが一時停止されてから再開された場合、最初の更新には、サブスクリプションの一時停止中に発生したすべての変更の更新が現在の値で含まれる必要があります（SHOULD）。この機能がサポートされていない場合、サブスクリプションサービスは明確な指示を提供する必要があります（この場合、クライアントアプリケーションは状態を個別に同期する必要がある場合があるため）。
Multiple objects being pushed to a Subscriber, perhaps from different subscriptions, SHOULD be bundled together into a single Update.
おそらく異なるサブスクリプションからサブスクライバーにプッシュされる複数のオブジェクトは、1つの更新に一緒にバンドルする必要があります（SHOULD）。
The sending of an Update MUST NOT be delayed beyond the Push Latency of any enclosed object changes.
更新の送信は、囲まれたオブジェクト変更のプッシュレイテンシを超えて遅延してはなりません。
The sending of an Update MUST NOT be delayed beyond the dampening period of any enclosed object changes.
更新の送信は、囲まれたオブジェクト変更のダンプニング期間を超えて遅延してはなりません（MUST NOT）。
The sending of an Update MUST NOT occur before the dampening period expires for any enclosed object changes.
囲まれたオブジェクトの変更のダンプニング期間が終了する前に、更新の送信が発生してはなりません。
A Subscription Service MAY, as an option, support a replay capability so that a set of updates generated during a previous time internal can be sent to a Receiver.
サブスクリプションサービスは、オプションとして、前回の内部処理中に生成された一連の更新をレシーバーに送信できるように、再生機能をサポートする場合があります。
It is possible for updates coming from a Subscription Service to be pushed over different types of transports such as NETCONF, RESTCONF, and HTTP. Beyond existing transports, this Subscription Service will be applicable for emerging protocols such as those being defined in [USECASE]. The need for such transport flexibility drives the following requirements:
サブスクリプションサービスからの更新が、NETCONF、RESTCONF、HTTPなどのさまざまな種類のトランスポートにプッシュされる可能性があります。このサブスクリプションサービスは、既存のトランスポートを超えて、[USECASE]で定義されているプロトコルなどの新しいプロトコルに適用できます。このような輸送の柔軟性の必要性により、次の要件が生じます。
o A Subscription Service SHOULD support different transports.
o サブスクリプションサービスは、さまざまなトランスポートをサポートする必要があります（SHOULD）。
o A Subscription Service SHOULD support different encodings of a payload.
o Subscription Serviceは、ペイロードのさまざまなエンコーディングをサポートする必要があります（SHOULD）。
o It MUST be possible for Receivers to associate the update with a specific subscription.
o 受信者が更新を特定のサブスクリプションに関連付けることが可能でなければなりません。
o In the case of connection-oriented transport, when a transport connection drops, the associated subscription SHOULD be terminated. It is up the Subscriber to request a new subscription.
o コネクション型トランスポートの場合、トランスポート接続がドロップすると、関連付けられているサブスクリプションを終了する必要があります（SHOULD）。新しいサブスクリプションを要求するのはサブスクライバーです。
Some uses of this Subscription Service will push privacy-sensitive updates and metadata. For privacy-sensitive deployments, subscription information MUST be bound within secure, encrypted transport-layer mechanisms. For example, if NETCONF is used as transport, then [RFC7589] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging privacy-sensitive deployment contexts as well. As an example, deployments based on [USECASE] would apply these requirements in conjunction with those documented within [I2RS-ENV-SEC] and [I2RS-PROT-SEC] to secure ephemeral state information being pushed from a network element.
このサブスクリプションサービスの一部の用途は、プライバシーに配慮した更新とメタデータをプッシュします。プライバシーに配慮した展開の場合、サブスクリプション情報は、安全で暗号化されたトランスポート層メカニズム内にバインドする必要があります。たとえば、NETCONFがトランスポートとして使用される場合、[RFC7589]はトランスポートされた情報を保護するための有効なオプションになります。サブスクリプションサービスは、プライバシーに配慮した新しい展開コンテキストでも使用できます。例として、[USECASE]に基づく展開では、これらの要件を[I2RS-ENV-SEC]および[I2RS-PROT-SEC]に記載されている要件と組み合わせて適用し、ネットワーク要素からプッシュされる一時的な状態情報を保護します。
As part of the subscription establishment, mutual authentication MUST be used between the Subscriber and the Subscription Service.
サブスクリプション確立の一部として、サブスクライバーとサブスクリプションサービスの間で相互認証を使用する必要があります。
Subscribers MUST NOT be able to pose as the original Subscription Service.
加入者は、元のサブスクリプションサービスを装うことはできません。
Versioning of any subscription protocols MUST be supported so that the capabilities and behaviors expected of specific technology implementations can be exposed.
特定のテクノロジ実装に期待される機能と動作を公開できるように、サブスクリプションプロトコルのバージョン管理をサポートする必要があります。
A subscription could be used to attempt to retrieve information to which a client has no authorized access. Therefore, it is important that data being pushed based on subscriptions is authorized in the same way that regular data retrieval operations are authorized. Data being pushed to a client MUST be filtered accordingly, just like if the data were being retrieved on demand. For Unicast transports, the NETCONF Authorization Control Model applies.
サブスクリプションを使用して、クライアントが許可されたアクセス権を持たない情報を取得しようとする可能性があります。したがって、サブスクリプションに基づいてプッシュされるデータは、通常のデータ取得操作が許可されるのと同じ方法で許可されることが重要です。クライアントにプッシュされるデータは、データがオンデマンドで取得されている場合と同様に、それに応じてフィルタリングする必要があります。ユニキャストトランスポートの場合、NETCONF Authorization Control Modelが適用されます。
Additions or changes within a subscribed subtree structure MUST be validated against authorization methods before subscription updates, including new subtree information, are pushed.
新しいサブツリー情報を含むサブスクリプションの更新がプッシュされる前に、サブスクライブされたサブツリー構造内の追加または変更を承認メソッドに対して検証する必要があります。
A loss of authenticated access to the target subtree or node SHOULD be communicated to the Subscriber.
ターゲットサブツリーまたはノードへの認証済みアクセスが失われた場合、サブスクライバーに通知する必要があります（SHOULD）。
For any encrypted information exchanges, commensurate strength security mechanisms MUST be available and SHOULD be used. This includes all stages of the subscription and update push process.
暗号化された情報交換については、相応の強度のセキュリティメカニズムを利用できなければならず、使用する必要があります。これには、サブスクリプションと更新のプッシュプロセスのすべての段階が含まれます。
Subscription requests, including requests to create, terminate, suspend, and resume subscriptions MUST be properly authorized.
サブスクリプションの作成、終了、一時停止、および再開の要求を含むサブスクリプション要求は、適切に承認される必要があります。
When the Subscriber and Receiver are different, the Receiver MUST be able to terminate any subscription to it where objects are being delivered over a Unicast transport.
サブスクライバとレシーバが異なる場合、レシーバは、オブジェクトがユニキャストトランスポートを介して配信されているサブスクライバへのサブスクリプションを終了できる必要があります。
A Subscription Service SHOULD decline a subscription request if it is likely to deplete its resources. It is preferable to decline a subscription when originally requested, rather than having to terminate it prematurely later.
サブスクリプションサービスは、リソースを使い果たす可能性がある場合、サブスクリプションリクエストを拒否する必要があります（SHOULD）。後で途中で終了する必要がなく、最初にリクエストされたときにサブスクリプションを拒否することが望ましいです。
When the Subscriber and Receiver are different, and when the underlying transport connection passes credentials as part of transport establishment, then potentially pushed objects MUST be excluded from a push update if that object doesn't have read access visibility for that Receiver.
サブスクライバーとレシーバーが異なり、基になるトランスポート接続がトランスポート確立の一部として資格情報を渡す場合、そのオブジェクトにそのレシーバーに対する読み取りアクセスの可視性がない場合は、プッシュされる可能性のあるオブジェクトをプッシュ更新から除外する必要があります。
A Subscription Service SHOULD be able to negotiate the following subscription QoS parameters with a Subscriber: Dampening, Reliability, Deadline, and Bundling.
サブスクリプションサービスは、次のサブスクリプションQoSパラメータをサブスクライバーとネゴシエートできる必要があります（SHOULD）：ダンプニング、信頼性、期限、およびバンドリング。
A Subscription Service SHOULD be able to interpret subscription QoS parameters, and only establish a subscription if it is possible to meet the QoS needs of the provided QoS parameters.
サブスクリプションサービスは、サブスクリプションQoSパラメータを解釈でき、提供されたQoSパラメータのQoSニーズを満たすことが可能である場合にのみサブスクリプションを確立できます。
A Subscription Service MUST be able to respond to requests to verify the Liveliness of a subscription.
サブスクリプションサービスは、サブスクリプションの活性を確認する要求に応答できなければなりません。
A Subscription Service MUST be able to report the currently monitored Nodes of a subscription.
サブスクリプションサービスは、サブスクリプションの現在監視されているノードを報告できる必要があります。
A Subscription Service MUST be able to negotiate the minimum time separation since the previous update before transmitting a subsequent update for subscription. (Note: this is intended to confine the visibility of volatility into something digestible by the receiver.)
サブスクリプションサービスは、サブスクリプションの後続の更新を送信する前に、前の更新以降の最小時間間隔をネゴシエートできる必要があります。 （注：これは、ボラティリティの可視性をレシーバーが消化できるものに限定することを目的としています。）
A Subscription Service MAY send Updates over Best Effort and Reliable transports.
サブスクリプションサービスは、ベストエフォートおよび信頼性の高いトランスポートを介して更新を送信する場合があります。
For a particular subscription, every update to a subscribed object MUST be sent to the Receiver in sequential order.
特定のサブスクリプションの場合、サブスクライブされたオブジェクトに対するすべての更新は、シーケンシャルな順序でレシーバーに送信される必要があります。
The Subscription Service MAY have the ability to bundle a set of discrete object notifications into a single publishable update for a subscription. A bundle MAY include information on different Data Nodes and/or multiple updates about a single Data Node.
サブスクリプションサービスは、一連の個別のオブジェクト通知をサブスクリプションの1つの発行可能な更新にバンドルする機能を備えている場合があります。バンドルには、異なるデータノードに関する情報や単一のデータノードに関する複数の更新が含まれる場合があります。
For any bundled updates, the Subscription Service MUST provide information for a Receiver to reconstruct the order and timing of updates.
バンドルされたアップデートの場合、サブスクリプションサービスは、レシーバがアップデートの順序とタイミングを再構築するための情報を提供する必要があります。
The Subscription Service MUST be able to push updates at a regular cadence that corresponds with the Subscriber's specified start and end timestamps. (Note: the regular cadence can drive one update, a discrete quantity of updates, or an unbounded set of periodic updates.)
サブスクリプションサービスは、サブスクライバーの指定された開始タイムスタンプと終了タイムスタンプに対応する定期的なリズムで更新をプッシュできる必要があります。 （注：通常のケイデンスは、1つの更新、個別の量の更新、または無制限の定期的な更新のセットを駆動できます。）
The Subscription Service SHOULD be able to delay Updates on object push for a configurable period per Subscriber.
サブスクリプションサービスは、サブスクライバーごとに構成可能な期間、オブジェクトプッシュの更新を遅延できる必要があります（SHOULD）。
It MUST be possible for an administrative entity to determine the Push latency between object change in a monitored subtree and the Subscription Service Push of the update transmission.
管理エンティティは、監視対象のサブツリーでのオブジェクト変更と更新送信のサブスクリプションサービスプッシュの間のプッシュレイテンシを決定できる必要があります。
The Subscription Service SHOULD support the relative prioritization of subscriptions so that the dequeuing and discarding of push updates can consider this if there is insufficient bandwidth between the Publisher and the Receiver.
サブスクリプションサービスは、サブスクリプションの相対的な優先順位付けをサポートする必要があるため（SHOULD）、パブリッシャーとレシーバーの間に十分な帯域幅がない場合、プッシュ更新のデキューと破棄でこれを考慮することができます。
If no filtering criteria are provided, or if filtering criteria are met, updates for a subscribed object MUST be pushed, subject to the QoS limits established for the subscription.
フィルタリング基準が提供されない場合、またはフィルタリング基準が満たされる場合、サブスクリプションに対して確立されたQoS制限に従って、サブスクライブされたオブジェクトの更新をプッシュする必要があります。
It MUST be possible for the Subscription Service to receive Filter(s) from a Subscriber and apply them to the corresponding object(s) within a subscription.
サブスクリプションサービスがサブスクライバーからフィルターを受け取り、サブスクリプション内の対応するオブジェクトに適用できるようにする必要があります。
It MUST be possible to attach one or more Subtree and/or object element and attribute Filters to a subscription. Mandatory Filter types include:
サブスクリプションに1つ以上のサブツリーおよび/またはオブジェクト要素と属性フィルターをアタッチできる必要があります。必須フィルターのタイプは次のとおりです。
o For character-based object properties, Filter values that are exactly equal to a provided string, not equal to the string, or containing a string.
o 文字ベースのオブジェクトプロパティの場合、指定された文字列と完全に等しい、文字列と等しくない、または文字列を含む値をフィルターします。
o For numeric object properties, Filter values that are =, !=, <, <=, >, or >= a provided number.
o 数値オブジェクトプロパティの場合、=、！=、<、<=、>、または> =であるフィルター値は、指定された数値です。
It SHOULD be possible for Filtering criteria to evaluate more than one property of a particular subscribed object as well as apply multiple Filters against a single object.
フィルタリング基準が特定のサブスクライブされたオブジェクトの複数のプロパティを評価し、単一のオブジェクトに対して複数のフィルターを適用することが可能であるべきです。
It SHOULD be possible to establish query match criteria on additional objects to be used in conjunction with Filtering criteria on a subscribed object. (For example, if A has changed and B=1, then Push A.) Query match capability may be done on objects within the datastore even if those objects are not included within the subscription. This of course assumes that the subscriber has read access to those objects.
サブスクライブされたオブジェクトのフィルタリング基準と組み合わせて使用される追加のオブジェクトのクエリ一致基準を確立することが可能である必要があります。 （たとえば、Aが変更され、B = 1の場合、Aをプッシュします。）データストア内のオブジェクトがサブスクリプションに含まれていなくても、クエリ照合機能はデータストア内のオブジェクトで実行できます。もちろん、これはサブスクライバーがそれらのオブジェクトへの読み取りアクセス権を持っていることを前提としています。
For on-change subscription updates, an object MUST pass a Filter through a Filter if it has changed since the previous update. This includes if the object has changed multiple times since the last update, and if the value happens to be the exact same value as the last one sent.
変更時のサブスクリプションの更新では、前回の更新以降に変更されている場合、オブジェクトはフィルターを介してフィルターを渡す必要があります。これには、最後の更新以降にオブジェクトが複数回変更された場合、および値が最後に送信されたものとまったく同じ値である場合が含まれます。
It MUST be possible to fetch the state of a single subscription from a Subscription Service.
サブスクリプションサービスから単一のサブスクリプションの状態をフェッチできる必要があります。
It MUST be possible to fetch the state of all subscriptions of a particular Subscriber.
特定のサブスクライバーのすべてのサブスクリプションの状態をフェッチできる必要があります。
It MUST be possible to fetch a list and status of all subscription requests over a period of time. If there is a failure, some failure reasons might include:
一定期間内にすべてのサブスクリプション要求のリストとステータスをフェッチできる必要があります。障害がある場合、いくつかの障害の理由には次のものがあります。
o Improper security credentials provided to access the target node;
o ターゲットノードにアクセスするために提供された不適切なセキュリティ資格情報。
o Target node referenced does not exist;
o 参照されているターゲットノードは存在しません。
o Subscription type requested is not available upon the target node;
o リクエストされたサブスクリプションタイプはターゲットノードでは使用できません。
o Out of resources, or resources not available;
o リソース不足、またはリソースが利用できない。
o Incomplete negotiations with the Subscriber.
o サブスクライバーとの交渉が不完全です。
There are no additional security considerations beyond the requirements listed in Section 4.2.5.
セクション4.2.5にリストされている要件以外にセキュリティに関する考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E、エド。およびR. Aggarwal編、「MPLS / BGP IP VPNでのマルチキャスト」、RFC 6513、DOI 10.17487 / RFC6513、2012年2月、<http://www.rfc-editor.org/info/rfc6513>。
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, <http://www.rfc-editor.org/info/rfc7589>.
[RFC7589] Badra、M.、Luchuk、A。、およびJ. Schoenwaelder、「トランスポート層セキュリティ（TLS）での相互X.509認証でのNETCONFプロトコルの使用」、RFC 7589、DOI 10.17487 / RFC7589、2015年6月、< http://www.rfc-editor.org/info/rfc7589>。
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://www.rfc-editor.org/info/rfc7921>.
[RFC7921] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「An Routing for the Interface to the Routing System」、RFC 7921、DOI 10.17487 / RFC7921、2016年6月、<http://www.rfc-editor.org/info/rfc7921>。
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, <http://www.rfc-editor.org/info/rfc7922>.
[RFC7922] Clarke、J.、Salgueiro、G。、およびC. Pignataro、「Interface to the Routing System（I2RS）Traceability：Framework and Information Model」、RFC 7922、DOI 10.17487 / RFC7922、June 2016、<http：/ /www.rfc-editor.org/info/rfc7922>。
[I2RS-ENV-SEC] Migault, D., Ed., Halpern, J., and S. Hares, "I2RS Environment Security Requirements", Work in Progress, draft-ietf-i2rs-security-environment-reqs-01, April 2016.
[I2RS-ENV-SEC] Migault、D.、Ed。、Halpern、J。、およびS. Hares、「I2RS Environment Security Requirements」、Work in Progress、draft-ietf-i2rs-security-environment-reqs-01、 2016年4月。
[I2RS-PROT-SEC] Hares, S., Migault, D., and J. Halpern, "I2RS Security Related Requirements", Work in Progress, draft-ietf-i2rs-protocol-security-requirements-06, May 2016.
[I2RS-PROT-SEC] Hares、S.、Migault、D。、およびJ. Halpern、「I2RS Security Related Requirements」、Work in Progress、draft-ietf-i2rs-protocol-security-requirements-06、May 2016。
[OMG-DDS] Object Management Group (OMG), "Data Distribution Service for Real-time Systems, Version 1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>.
[OMG-DDS]オブジェクト管理グループ（OMG）、「リアルタイムシステム用データ配布サービス、バージョン1.2」、2007年1月、<http://www.omg.org/spec/DDS/1.2/>。
[SACMREQ] Nancy, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", Work in Progress, draft-ietf-sacm-requirements-13, March 2016.
[SACMREQ]ナンシー、N.、L。ローレンジン、「セキュリティの自動化と継続的監視（SACM）の要件」、進行中の作業、draft-ietf-sacm-requirements-13、2016年3月。
[USECASE] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Work in Progress, draft-ietf-i2rs-usecase-reqs-summary-02, March 2016.
[USECASE] Hares、S.、M。Chen、「Summary of I2RS Use Case Requirements」、Work in Progress、draft-ietf-i2rs-usecase-reqs-summary-02、March 2016。
[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP-0060, July 2010, <http://xmpp.org/extensions/xep-0060.html>.
[XEP-0060] Millard、P.、Saint-Andre、P。、およびR. Meijer、「Publish-Subscribe」、XSF XEP-0060、2010年7月、<http://xmpp.org/extensions/xep-0060 .html>。
Acknowledgments
謝辞
We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Ambika Tripathy and Prabhakara Yellai as well as the helpfulness of related end-to-end system context info from Nancy Cam Winget, Ken Beck, and David McGrew.
Ambika TripathyとPrabhakara Yellaiから受け取った有益な貢献、コメント、提案、およびNancy Cam Winget、Ken Beck、David McGrewからの関連するエンドツーエンドのシステムコンテキスト情報の有用性に感謝します。
Authors' Addresses
著者のアドレス
Eric Voit Cisco Systems
Eric Voit Cisco Systems
Email: evoit@cisco.com
Alexander Clemm Cisco Systems
Alexander Clemm Cisco Systems
Email: alex@cisco.com
Alberto Gonzalez Prieto Cisco Systems
Alberto Gonzalez Prieto Cisco Systems
Email: albertgo@cisco.com