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
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传输（即网络配置协议（NETCONF）和RESTCONF）的功能空白。这种服务可以概括为数据存储更新的“发布/订阅”服务。除了服务的一组基本要求外，还解决了各种改进。这些改进包括：对象更新的周期性，从请求的子树下过滤出对象，以及交付QoS保证。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................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
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.
与数据存储交互的应用程序需要的功能超出了网络元素的传统客户机-服务器配置。其中一类应用程序是服务保证应用程序，它必须保持对操作数据和状态的连续查看。另一类应用程序是安全应用程序，它必须持续跟踪对网络元素所做的更改，以确保符合公司策略。
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.
对于需要频繁或及时更新远程对象状态的应用程序，定期获取数据不是一个适当的解决方案。在这里应用基于轮询的解决方案会给网络、设备和应用程序带来负载。此外，轮询解决方案在通信故障面前很脆弱，并且在跨网络同步和校准检索间隔的能力方面存在限制。这些限制可以通过在网络元素中包含通用对象订阅机制来解决，并允许在数据存储中概念上包含的数据上下文中应用这些机制。
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作为网络元素编程接口中使用的主要数据建模语言的崛起，fetch和自定义网络协议的混合已不再足够。我们需要的是一种推动机制，它能够在对象发生更改时传递这些更改。
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
推送解决方案不会取代所有现有运营基础设施需求。SNMP和MIB将继续广泛部署，并成为许多监控解决方案的实际选择。但有些功能可能会被取代。可以说，对于这些应用程序，SNMP的最大缺点在于需要依赖定期轮询，因为它在网络和设备上引入了额外的负载，因为如果错过轮询周期，它很脆弱，并且
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.
因为很难跨网络进行同步和校准。如果应用程序只能对数据存储使用轮询类型的交互模式，则可能会出现类似的问题。
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）接口的各种文档强调了在网络元素之间提供发布/订阅功能的需要。从[RFC7921]开始，本文件从第6.2节开始有参考文献。一些具体例子包括：
o Section 7.6 of [RFC7921] provides high-level pub/sub (notification) guidance.
o [RFC7921]第7.6节提供了高级发布/订阅（通知）指南。
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节指出，当本地配置抢占I2R时，可能需要外部通知。
In addition, [USECASE] has relevant requirements. A small subset includes:
此外，[用例]还有相关的要求。一小部分包括：
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接口（协议和即时消息（IMs））应允许用户选择数据模型的部分。
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：当相关路由系统上的BGP进程观察到一组特定IP前缀和相关前缀的路由更改时，I2RS客户端应能够指示I2RS代理通知I2RS客户端。。。。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接口（协议和IMs）应支持一种机制，其中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节包括以下发布/子要求：
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:
本文件旨在涵盖I2R以外的要求。回顾历史，有很多交换和路由协议的例子，它们在过去都做过显式或隐式发布/订阅。此外，现在正在指定在交换机和路由器上运行的新策略通知机制。当前和过去订阅机制的一小部分包括：
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 安全自动化和连续监控（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.
在上面的例子中值得注意的是各种各样的底层传输。因此，应该构造一个通用的发布/订阅机制来支持替代传输。根据当前的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、公共对象请求代理体系结构（CORBA）和其他技术都展示了早期的发布/订阅技术。然而，这些技术无法满足新的需求（见下文第4节）。我们需要一种新的发布/订阅技术。
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.
至少有两种广泛部署的通用发布/订阅实现符合当前需求：可扩展消息和状态协议（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.
因为有了这些证据，我们可以放心，底层技术可以实现可重用的对象分布。分析将需要充分考虑不同子树大小和传输类型的此类对象分布的速度和规模。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。尽管本文件不是协议规范，但本语言的使用澄清了协议设计师的指示，以生产满足本文件规定要求的解决方案。
A Subscriber makes requests for set(s) of YANG object data.
订户请求一组或多组对象数据。
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.
发布者负责按照订阅条款分发订阅的对象数据。通常，发布者是受订阅约束的数据存储的所有者。
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.
接收者是发布者将更新推送到的目标。一般来说，接收方和订户将是同一实体。订阅服务向数据订阅方提供订阅。
A Subscription Service interacts with the Publisher of the YANG data as needed to provide the data per the terms of the subscription.
订阅服务根据需要与数据发布者交互，以根据订阅条款提供数据。
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.
一个或多个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.
更新提供在订阅的子树中发生的对象更改。更新必须包括（数据）节点实例的当前状态，对于这些节点实例，筛选表明它们的状态与以前提供的不同。更新可能包括自上次更新以来对给定对象进行的一组有序/顺序更改。
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.
筛选器包含评估标准，这些标准根据订阅中的对象进行评估。有两种类型的过滤器：子树过滤器（用于标识在目标数据节点下发布的选定对象/节点）和对象元素和属性过滤器（仅当对象的属性满足指定的过滤器条件时才应发布该对象）。
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.
订阅者应避免尝试建立与相同信息相关的多个订阅，即引用相同的数据存储和子树。
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标准；如果订阅服务无法满足这些条件，则不应建立订阅。
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.
订阅服务必须能够支持在同一订阅请求中添加/更改/删除对多个子树的订阅。
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.
对于更改时更新，订阅服务必须支持在发送第一个或后续更改时更新之前需要经过的缓冲期。缓冲期应作为订阅请求的一部分进行配置。
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.
订阅服务应支持在客户端请求时暂停和恢复订阅的功能。
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.
订阅服务可自行决定撤销或暂停现有订阅。原因可能包括暂时性资源限制、凭据过期、无法重新确认订阅、与接收器、操作员命令行界面（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标准。订阅QoS标准的示例可包括订阅服务的可靠性、受监视的子树/对象更改与相应的通知推送之间的反应时间，以及订阅服务支持特定级别的对象活跃性的能力。
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).
如果由于平台资源不足而无法满足订阅请求，订阅服务应在其拒绝提示中包含在发出订阅请求时可接受的标准。例如，如果请求的定期更新的更新间隔对于指定的数据集来说太短，则发布服务器可能会返回一个可接受的替代间隔期。如果请求更改时更新的缓冲期太长，则可能会返回一个可接受的缓冲期，或者指示仅支持请求对象的定期更新。
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).
当具有更改时更新的订阅被挂起然后恢复时，第一次更新应包括在该订阅挂起时发生的所有更改的更新，以及当前值。订阅服务必须在不支持此功能时提供明确指示（因为在这种情况下，客户端应用程序可能必须单独同步状态）。
Multiple objects being pushed to a Subscriber, perhaps from different subscriptions, SHOULD be bundled together into a single Update.
推送到订阅者的多个对象（可能来自不同的订阅）应该捆绑在一起，形成一个更新。
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.
更新的发送不得延迟超过任何封闭对象更改的缓冲期。
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 订阅服务应支持不同的传输。
o A Subscription Service SHOULD support different encodings of a payload.
o 订阅服务应支持有效负载的不同编码。
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 对于面向连接的传输，当传输连接断开时，应终止关联的订阅。由订阅者请求新的订阅。
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授权控制模型适用。
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.
对目标子树或节点的身份验证访问丢失应通知订户。
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.
如果订阅服务可能耗尽其资源，则应拒绝订阅请求。最好在最初请求时拒绝订阅，而不是在以后过早终止订阅。
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参数：抑制、可靠性、截止日期和绑定。
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.
订阅服务可以将一组离散对象通知捆绑到订阅的单个可发布更新中。捆绑包可以包括关于不同数据节点的信息和/或关于单个数据节点的多个更新。
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.)
订阅服务必须能够以与订阅者指定的开始和结束时间戳相对应的常规节奏推送更新。（注意：常规cadence可以驱动一次更新、离散的更新量或无限的定期更新集。）
The Subscription Service SHOULD be able to delay Updates on object push for a configurable period per Subscriber.
订阅服务应该能够将对象推送的更新延迟每个订阅服务器一段可配置的时间。
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.
订阅服务应该支持订阅的相对优先级，以便如果发布者和接收者之间带宽不足，则推送更新的排队和丢弃可以考虑这一点。
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:
必须能够将一个或多个子树和/或对象元素和属性筛选器附加到订阅。强制过滤器类型包括：
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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[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]Rosen，E.，Ed.和R.Aggarwal，Ed.，“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.Schoenwaeld，“在传输层安全（TLS）上使用NETCONF协议，并进行相互X.509身份验证”，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，“路由系统接口架构”，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，“路由系统接口（I2RS）可追溯性：框架和信息模型”，RFC 7922，DOI 10.17487/RFC7922，2016年6月<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环境安全要求”，在建工程，草案-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安全相关要求”，在建工程，草案-ietf-I2RS-protocol-Security-Requirements-062016年5月。
[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]Nancy，N.和L.Lorenzin，“安全自动化和连续监测（SACM）要求”，在建工程，草案-ietf-SACM-Requirements-132016年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.
[用例]Hares，S.和M.Chen，“I2RS用例需求摘要”，正在进行的工作，草稿-ietf-I2RS-USECASE-reqs-Summary-022016年3月。
[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，“发布-订阅”，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.
我们希望感谢安比卡Tripathy和Prabhakara Yellai提供的有用的贡献、评论和建议，以及南希·坎温吉、肯·贝克和大卫·麦克格雷夫提供的相关端到端系统上下文信息的帮助。
Authors' Addresses
作者地址
Eric Voit Cisco Systems
Eric Voit思科系统公司
Email: evoit@cisco.com
Email: evoit@cisco.com
Alexander Clemm Cisco Systems
亚历山大克莱姆思科系统公司
Email: alex@cisco.com
Email: alex@cisco.com
Alberto Gonzalez Prieto Cisco Systems
Alberto Gonzalez Prieto思科系统公司
Email: albertgo@cisco.com
Email: albertgo@cisco.com