Internet Engineering Task Force (IETF) A. Clemm
Request for Comments: 8641 Futurewei
Category: Standards Track E. Voit
ISSN: 2070-1721 Cisco Systems
September 2019
Internet Engineering Task Force (IETF) A. Clemm
Request for Comments: 8641 Futurewei
Category: Standards Track E. Voit
ISSN: 2070-1721 Cisco Systems
September 2019
Subscription to YANG Notifications for Datastore Updates
订阅数据存储更新通知
Abstract
摘要
This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.
本文档描述了一种机制，该机制允许订户应用程序从数据存储请求连续的自定义更新流。通过提供对更新的这种可视性，可以实现基于远程镜像和对配置和操作状态的监视的新功能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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/rfc8641.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8641.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Definitions .....................................................4
3. Solution Overview ...............................................6
3.1. Subscription Model .........................................6
3.2. Negotiation of Subscription Policies .......................7
3.3. On-Change Considerations ...................................8
3.4. Reliability Considerations .................................9
3.5. Data Encodings ............................................10
3.6. Defining the Selection with a Datastore ...................11
3.7. Streaming Updates .........................................12
3.8. Subscription Management ...................................15
3.9. Receiver Authorization ....................................16
3.10. On-Change Notifiable Datastore Nodes .....................18
3.11. Other Considerations .....................................18
4. A YANG Data Model for Management of Datastore Push
Subscriptions ..................................................20
4.1. Overview ..................................................20
4.2. Subscription Configuration ................................27
4.3. YANG Notifications ........................................28
4.4. YANG RPCs .................................................29
5. YANG Module for YANG-Push ......................................34
6. IANA Considerations ............................................51
7. Security Considerations ........................................51
8. References .....................................................53
8.1. Normative References ......................................53
8.2. Informative References ....................................55
Appendix A. Subscription Errors ...................................56
A.1. RPC Failures ...............................................56
A.2. Failure Notifications ......................................57
Acknowledgments ...................................................58
Contributors ......................................................58
Authors' Addresses ................................................58
1. Introduction ....................................................4
2. Definitions .....................................................4
3. Solution Overview ...............................................6
3.1. Subscription Model .........................................6
3.2. Negotiation of Subscription Policies .......................7
3.3. On-Change Considerations ...................................8
3.4. Reliability Considerations .................................9
3.5. Data Encodings ............................................10
3.6. Defining the Selection with a Datastore ...................11
3.7. Streaming Updates .........................................12
3.8. Subscription Management ...................................15
3.9. Receiver Authorization ....................................16
3.10. On-Change Notifiable Datastore Nodes .....................18
3.11. Other Considerations .....................................18
4. A YANG Data Model for Management of Datastore Push
Subscriptions ..................................................20
4.1. Overview ..................................................20
4.2. Subscription Configuration ................................27
4.3. YANG Notifications ........................................28
4.4. YANG RPCs .................................................29
5. YANG Module for YANG-Push ......................................34
6. IANA Considerations ............................................51
7. Security Considerations ........................................51
8. References .....................................................53
8.1. Normative References ......................................53
8.2. Informative References ....................................55
Appendix A. Subscription Errors ...................................56
A.1. RPC Failures ...............................................56
A.2. Failure Notifications ......................................57
Acknowledgments ...................................................58
Contributors ......................................................58
Authors' Addresses ................................................58
Traditional approaches for providing visibility into managed entities from a remote system have been built on polling. With polling, data is periodically requested and retrieved by a client from a server to stay up to date. However, there are issues associated with polling-based management:
从远程系统提供受管实体可视性的传统方法是基于轮询构建的。通过轮询，客户机定期从服务器请求和检索数据，以保持最新。但是，与基于轮询的管理相关的问题有：
o Polling incurs significant latency. This latency prohibits many types of applications.
o 轮询会导致显著的延迟。此延迟禁止许多类型的应用程序。
o Polling cycles may be missed, and requests may be delayed or get lost -- often when the network is under stress and the need for the data is the greatest.
o 轮询周期可能会错过，请求可能会延迟或丢失——通常是在网络处于紧张状态且对数据的需求最大时。
o Polling requests may undergo slight fluctuations, resulting in intervals of different lengths. The resulting data is difficult to calibrate and compare.
o 轮询请求可能会经历轻微的波动，从而导致不同长度的间隔。结果数据很难校准和比较。
o For applications that monitor for changes, many remote polling cycles place unwanted and ultimately wasteful load on the network, devices, and applications, particularly when changes occur only infrequently.
o 对于监视更改的应用程序，许多远程轮询周期会在网络、设备和应用程序上产生不必要的最终浪费负载，特别是在更改很少发生的情况下。
A more effective alternative to polling is for an application to receive automatic and continuous updates from a targeted subset of a datastore. Accordingly, there is a need for a service that (1) allows applications to subscribe to updates from a datastore and (2) enables the server (also referred to as the "publisher") to push and, in effect, stream those updates. The requirements for such a service have been documented in [RFC7923].
轮询的一个更有效的替代方法是应用程序从数据存储的目标子集接收自动和连续的更新。因此，需要一种服务，该服务（1）允许应用程序订阅来自数据存储的更新，并且（2）允许服务器（也称为“发布者”）推送并且实际上流式传输这些更新。此类服务的要求已记录在[RFC7923]中。
This document defines a corresponding solution that is built on top of [RFC8639]. Supplementing that work are YANG data model augmentations, extended RPCs, and new datastore-specific update notifications. Transport options provided in [RFC8639] will work seamlessly with this solution.
本文档定义了在[RFC8639]基础上构建的相应解决方案。补充这项工作的还有数据模型扩展、扩展的RPC和新的特定于数据存储的更新通知。[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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document uses the terminology defined in [RFC7950], [RFC8341], [RFC8342], and [RFC8639]. In addition, this document defines the following terms:
本文件使用[RFC7950]、[RFC8341]、[RFC8342]和[RFC8639]中定义的术语。此外，本文件定义了以下术语：
o Datastore node: A node in the instantiated YANG data tree associated with a datastore. In this document, datastore nodes are often also simply referred to as "objects".
o 数据存储节点：实例化数据树中与数据存储关联的节点。在本文档中，数据存储节点通常也称为“对象”。
o Datastore node update: A data item containing the current value of a datastore node at the time the datastore node update was created, as well as the path to the datastore node.
o 数据存储节点更新：一个数据项，包含创建数据存储节点更新时数据存储节点的当前值以及数据存储节点的路径。
o Datastore subscription: A subscription to a stream of datastore node updates.
o 数据存储订阅：对数据存储节点更新流的订阅。
o Datastore subtree: A datastore node and all its descendant datastore nodes.
o 数据存储子树：数据存储节点及其所有子代数据存储节点。
o On-change subscription: A datastore subscription with updates that are triggered when changes in subscribed datastore nodes are detected.
o 更改订阅：数据存储订阅，当检测到订阅的数据存储节点中的更改时会触发更新。
o Periodic subscription: A datastore subscription with updates that are triggered periodically according to some time interval.
o 定期订阅：根据某个时间间隔定期触发更新的数据存储订阅。
o Selection filter: Evaluation and/or selection criteria that may be applied against a targeted set of objects.
o 选择过滤器：可针对目标对象集应用的评估和/或选择标准。
o Update record: A representation of one or more datastore node updates. In addition, an update record may contain which type of update led to the datastore node update (e.g., whether the datastore node was added, changed, or deleted). Also included in the update record may be other metadata, such as a subscription ID of the subscription for which the update record was generated. In this document, update records are often also simply referred to as "updates".
o 更新记录：一个或多个数据存储节点更新的表示形式。此外，更新记录可能包含导致数据存储节点更新的更新类型（例如，数据存储节点是否已添加、更改或删除）。更新记录中还可以包括其他元数据，例如为其生成更新记录的订阅的订阅ID。在本文件中，更新记录通常也称为“更新”。
o Update trigger: A mechanism that determines when an update record needs to be generated.
o 更新触发器：确定何时需要生成更新记录的机制。
o YANG-Push: The subscription and push mechanism for datastore updates that is specified in this document.
o YANG Push：本文档中指定的数据存储更新的订阅和推送机制。
This document specifies a solution that provides a subscription service for updates from a datastore. This solution supports dynamic as well as configured subscriptions to updates of datastore nodes. Subscriptions specify when notification messages (also referred to as "push updates") should be sent and what data to include in update records. Datastore node updates are subsequently pushed from the publisher to the receiver per the terms of the subscription.
本文档指定了一个解决方案，该解决方案为数据存储中的更新提供订阅服务。此解决方案支持对数据存储节点更新的动态订阅和配置订阅。订阅指定何时应发送通知消息（也称为“推送更新”），以及更新记录中应包含哪些数据。数据存储节点更新随后根据订阅条款从发布服务器推送到接收方。
YANG-Push subscriptions are defined using a YANG data model. This model enhances the subscription model defined in [RFC8639] with capabilities that allow subscribers to subscribe to datastore node updates -- specifically, to specify the update triggers defining when to generate update records as well as what to include in an update record. Key enhancements include:
YANG推送订阅是使用YANG数据模型定义的。此模型增强了[RFC8639]中定义的订阅模型，其功能允许订阅服务器订阅数据存储节点更新——具体来说，指定定义何时生成更新记录以及在更新记录中包含哪些内容的更新触发器。主要改进包括：
o The specification of selection filters that identify targeted YANG datastore nodes and/or datastore subtrees for which updates are to be pushed.
o 选择筛选器的规范，用于标识要为其推送更新的目标数据存储节点和/或数据存储子树。
o The specification of update policies that contain conditions that trigger the generation and pushing of new update records. There are two types of subscriptions, distinguished by how updates are triggered: periodic and on-change.
o 更新策略的规范，其中包含触发生成和推送新更新记录的条件。有两种订阅类型，根据更新的触发方式进行区分：定期订阅和更改订阅。
* For periodic subscriptions, the update trigger is specified by two parameters that define when updates are to be pushed. These parameters are (1) the period interval with which to report updates and (2) an "anchor-time", i.e., a reference point in time that can be used to calculate at which points in time periodic updates need to be assembled and sent.
* 对于定期订阅，更新触发器由两个参数指定，这两个参数定义何时推送更新。这些参数是（1）报告更新的周期间隔和（2）一个“锚定时间”，即一个参考时间点，可用于计算需要组装和发送定期更新的时间点。
* For on-change subscriptions, an update trigger occurs whenever a change in the subscribed information is detected. The following additional parameters are included:
* 对于更改订阅，只要检测到订阅信息中的更改，就会发生更新触发器。包括以下附加参数：
+ "dampening-period": In an on-change subscription, detected object changes should be sent as quickly as possible. However, it may be undesirable to send a rapid series of object changes. Such behavior has the potential to exhaust resources in the publisher or receiver. In order to protect against this type of scenario, a dampening period MAY be used to specify the interval that has to pass before successive update records for the same subscription are generated for a receiver. The dampening period collectively
+ “缓冲期”：在更改订阅中，应尽快发送检测到的对象更改。但是，可能不希望发送一系列快速的对象更改。这种行为有可能耗尽发布者或接收者的资源。为了防止这种情况，可以使用缓冲期来指定在为接收器生成相同订阅的连续更新记录之前必须经过的间隔。潮湿期
applies to the set of all datastore nodes selected by a single subscription. This means that when there is a change to one or more subscribed objects, an update record containing those objects is created immediately (when no dampening period is in effect) or at the end of a dampening period (when a dampening period is in fact in effect). If multiple changes to a single object occur during a dampening period, only the value that is in effect at the time when the update record is created is included. The dampening period goes into effect every time the assembly of an update record is completed.
应用于由单个订阅选择的所有数据存储节点集。这意味着，当一个或多个订阅对象发生更改时，将立即创建包含这些对象的更新记录（当缓冲期无效时）或在缓冲期结束时（当缓冲期实际上有效时）。如果在缓冲期内对单个对象进行多个更改，则仅包括在创建更新记录时生效的值。每次完成更新记录的组装时，缓冲期都将生效。
+ "change-type": This parameter can be used to reduce the types of datastore changes for which updates are sent (e.g., you might only send an update when an object is created or deleted, but not when an object value changes).
+ “更改类型”：此参数可用于减少为其发送更新的数据存储更改的类型（例如，您可能仅在创建或删除对象时发送更新，但在对象值更改时不发送更新）。
+ "sync-on-start": This parameter defines whether or not a complete "push-update" (Section 3.7) of all subscribed data will be sent at the beginning of a subscription. Such early synchronization establishes the frame of reference for subsequent updates.
+ “启动时同步”：此参数定义是否在订阅开始时发送所有订阅数据的完整“推送更新”（第3.7节）。这种早期同步为后续更新建立了参考框架。
o An encoding (using anydata) for the contents of periodic and on-change push updates.
o 定期更新和更改推送更新内容的编码（使用anydata）。
A dynamic subscription request SHOULD be declined if a publisher determines that it may be unable to provide update records meeting the terms of an "establish-subscription" or "modify-subscription" RPC request. In this case, a subscriber may quickly follow up with a new RPC request using different parameters.
如果发布者确定其无法提供符合“建立订阅”或“修改订阅”RPC请求条款的更新记录，则应拒绝动态订阅请求。在这种情况下，订户可以使用不同的参数快速跟进新的RPC请求。
Random guessing of different parameters by a subscriber is to be discouraged. Therefore, in order to minimize the number of subscription iterations between subscriber and publisher, a dynamic subscription supports a simple negotiation between subscribers and publishers for subscription parameters. This negotiation is in the form of supplemental information that should be inserted into error responses to a failed RPC request. This returned error response information, when considered, should increase the likelihood of success for subsequent RPC requests. Such hints include suggested periodic time intervals, acceptable dampening periods, and size estimates for the number of objects that would be returned from a proposed selection filter. However, there are no guarantees that subsequent requests that consider these hints will be accepted.
不鼓励用户随机猜测不同的参数。因此，为了最小化订阅服务器和发布服务器之间的订阅迭代次数，动态订阅支持订阅服务器和发布服务器之间就订阅参数进行简单协商。此协商以补充信息的形式进行，这些信息应插入到失败RPC请求的错误响应中。如果考虑此返回的错误响应信息，则应增加后续RPC请求成功的可能性。这些提示包括建议的周期性时间间隔、可接受的阻尼周期以及从建议的选择过滤器返回的对象数量的大小估计。但是，不能保证后续的考虑这些提示的请求将被接受。
On-change subscriptions allow receivers to receive updates whenever changes to targeted objects occur. As such, on-change subscriptions are particularly effective for data that changes infrequently but for which applications need to be quickly notified, with minimal delay, whenever a change does occur.
更改时订阅允许接收者在目标对象发生更改时接收更新。因此，更改时订阅对于很少更改但需要在发生更改时以最小延迟快速通知应用程序的数据特别有效。
On-change subscriptions tend to be more difficult to implement than periodic subscriptions. Accordingly, on-change subscriptions may not be supported by all implementations or for every object.
更改订阅往往比定期订阅更难实现。因此，并非所有实现或每个对象都支持更改时订阅。
Whether or not to accept or reject on-change subscription requests when the scope of the subscription contains objects for which on-change is not supported is up to the publisher implementation. A publisher MAY accept an on-change subscription even when the scope of the subscription contains objects for which on-change is not supported. In that case, updates are sent only for those objects within the scope of the subscription that do support on-change updates, whereas other objects are excluded from update records, even if their values change. In order for a subscriber to determine whether objects support on-change subscriptions, objects are marked accordingly on a publisher. Accordingly, when subscribing, it is the responsibility of the subscriber to ensure that it is aware of which objects support on-change and which do not. For more on how objects are so marked, see Section 3.10.
当订阅范围包含不支持更改时的对象时，是否接受或拒绝更改订阅请求取决于发布者实现。即使订阅范围包含不支持更改时订阅的对象，发布服务器也可以接受更改时订阅。在这种情况下，仅为订阅范围内支持更改更新的对象发送更新，而从更新记录中排除其他对象，即使其值发生更改。为了让订阅服务器确定对象是否支持更改订阅，在发布服务器上相应地标记对象。因此，在订阅时，订阅者有责任确保知道哪些对象支持更改，哪些不支持更改。有关如何标记对象的更多信息，请参见第3.10节。
Alternatively, a publisher MAY decide to simply reject an on-change subscription if the scope of the subscription contains objects for which on-change is not supported. In the case of a configured subscription, the publisher MAY suspend the subscription.
或者，如果订阅的作用域包含不支持on change的对象，则发布者可以决定简单地拒绝on change订阅。对于已配置的订阅，发布服务器可以挂起该订阅。
To avoid flooding receivers with repeated updates for subscriptions containing fast-changing objects or objects with oscillating values, an on-change subscription allows for the definition of a dampening period. Once an update record for a given object is generated, no other updates for this particular subscription will be created until the end of the dampening period. Values sent at the end of the dampening period are the values that are current at the end of the dampening period of all changed objects. Changed objects include those objects that were deleted or newly created during that dampening period. If an object has returned to its original value (or even has been created and then deleted) during the dampening period, that value (and not the interim change) will still be sent. This will indicate that churn is occurring on that object.
为了避免对包含快速变化的对象或具有振荡值的对象的订阅进行重复更新，更改时订阅允许定义缓冲期。生成给定对象的更新记录后，在缓冲期结束之前，不会为此特定订阅创建其他更新。阻尼期结束时发送的值是所有更改对象阻尼期结束时的当前值。更改的对象包括在阻尼期间删除或新建的对象。如果对象在缓冲期间已返回其原始值（甚至已创建并删除），则仍将发送该值（而不是临时更改）。这将表明该对象上正在发生搅动。
On-change subscriptions can be refined to let users subscribe only to certain types of changes. For example, a subscriber might only want object creations and deletions, but not modifications of object values.
可以对更改订阅进行优化，以允许用户仅订阅某些类型的更改。例如，订户可能只需要创建和删除对象，而不需要修改对象值。
Putting it all together, the conceptual process for creating an update record as part of an on-change subscription is as follows:
综上所述，创建更新记录作为变更订阅的一部分的概念流程如下：
1. Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules to ensure that a receiver is authorized to view all subscribed datastore nodes (filtering out any nodes for which this is not the case). The result is a set "A" of datastore nodes and subtrees.
1. 在更改之前或缓冲期开始时，评估任何筛选和任何访问控制规则，以确保接收者有权查看所有订阅的数据存储节点（筛选出任何不属于这种情况的节点）。结果是数据存储节点和子树的集合“a”。
2. Just after a change, or at the end of a dampening period, evaluate any filtering and any (possibly new) access control rules. The result is a set "B" of datastore nodes and subtrees.
2. 在更改之后或缓冲期结束时，评估任何过滤和任何（可能是新的）访问控制规则。结果是数据存储节点和子树的集合“B”。
3. Construct an update record, which takes the form of a YANG Patch record [RFC8072] for going from A to B.
3. 构造一个更新记录，它采用从a到B的杨补丁记录[RFC8072]的形式。
4. If there were any changes made between A and B that canceled each other out, insert into the YANG Patch record the last change made, even if the new value is no different from the original value (since changes that were made in the interim were canceled out). If the changes involve creating a new datastore node and then deleting it, the YANG Patch record will indicate the deletion of the datastore node. Similarly, if the changes involve deleting a new datastore node and then recreating it, the YANG Patch record will indicate the creation of the datastore node.
4. 如果A和B之间进行了任何相互抵消的更改，请将最后一次更改插入到修补程序记录中，即使新值与原始值没有差异（因为在此期间进行的更改已被抵消）。如果更改涉及创建新的数据存储节点，然后将其删除，则修补程序记录将指示删除数据存储节点。类似地，如果更改涉及删除新的数据存储节点，然后重新创建它，则修补程序记录将指示数据存储节点的创建。
5. If the resulting YANG Patch record is non-empty, send it to the receiver.
5. 如果生成的YANG Patch记录为非空，则将其发送给接收方。
Note: In cases where a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters.
注意：如果订阅者希望对不同对象有单独的缓冲期，订阅者可以选择使用不同的选择过滤器创建多个订阅者。
A subscription to updates from a datastore is intended to obviate the need for polling. However, in order to do so, it is critical that subscribers can rely on the subscription and have confidence that they will indeed receive the subscribed updates without having to worry about updates being silently dropped. In other words, a subscription constitutes a promise on the side of the publisher to provide the receivers with updates per the terms of the subscription.
订阅数据存储中的更新旨在消除轮询的需要。但是，为了做到这一点，订阅者必须依赖订阅，并确信他们确实会收到订阅的更新，而不必担心更新会被悄悄删除。换句话说，订阅构成了发布方承诺按照订阅条款向接收方提供更新。
Now, there are many reasons why a publisher may at some point no longer be able to fulfill the terms of the subscription, even if the subscription had been initiated in good faith. For example, the volume of datastore nodes may be larger than anticipated, the interval may prove too short to send full updates in rapid succession, or an internal problem may prevent objects from being collected. For this reason, the solution defined in this document (1) mandates that a publisher notify receivers immediately and reliably whenever it encounters a situation in which it is unable to keep the terms of the subscription and (2) provides the publisher with the option to suspend the subscription in such a case. This includes indicating the fact that an update is incomplete as part of a "push-update" or "push-change-update" notification, as well as emitting a "subscription-suspended" notification as applicable. This is described further in Section 3.11.1.
现在，有很多原因导致出版商可能在某个时候不再能够履行订阅条款，即使订阅是善意发起的。例如，数据存储节点的容量可能比预期的要大，间隔可能太短，无法连续快速发送完整更新，或者内部问题可能会阻止收集对象。因此，本文档中定义的解决方案（1）要求发布者在遇到无法遵守订阅条款的情况时立即可靠地通知接收者，（2）向发布者提供在这种情况下暂停订阅的选项。这包括作为“推送更新”或“推送更改更新”通知的一部分指示更新不完整的事实，以及发出“订阅暂停”通知（如适用）。第3.11.1节对此作了进一步说明。
A publisher SHOULD reject a request for a subscription if it is unlikely that the publisher will be able to fulfill the terms of that subscription request. In such cases, it is preferable to have a subscriber request a less resource-intensive subscription than to deal with frequently degraded behavior.
如果发布者不太可能满足订阅请求的条款，则发布者应拒绝订阅请求。在这种情况下，与处理频繁降级的行为相比，最好让订户请求资源密集度较低的订阅。
The solution builds on [RFC8639]. As defined therein, any loss of an underlying transport connection will be detected and result in subscription termination (in the case of dynamic subscriptions) or suspension (in the case of configured subscriptions), ensuring that situations where the loss of update notifications would go unnoticed will not occur.
该解决方案基于[RFC8639]。如其中所定义，将检测到基础传输连接的任何丢失，并导致订阅终止（在动态订阅的情况下）或暂停（在配置订阅的情况下），从而确保不会发生更新通知丢失未被注意到的情况。
In a periodic subscription, the data included as part of an update record corresponds to data that could have been read using a retrieval operation.
在定期订阅中，作为更新记录一部分包含的数据对应于可以使用检索操作读取的数据。
In an on-change subscription, update records need to indicate not only values of changed datastore nodes but also the types of changes that occurred since the last update. Therefore, encoding rules for data in on-change updates will generally follow YANG Patch operations as specified in [RFC8072]. The YANG Patch operations will describe what needs to be applied to the earlier state reported by the preceding update in order to result in the now-current state. Note that objects referred to in an update are not limited to
在更改订阅中，更新记录不仅需要指示更改的数据存储节点的值，还需要指示自上次更新以来发生的更改类型。因此，更改更新中数据的编码规则通常将遵循[RFC8072]中指定的修补程序操作。YANG修补程序操作将描述需要应用于先前更新报告的早期状态的内容，以形成当前状态。请注意，更新中引用的对象不限于
configuration data but can include any objects (including operational data), whereas [RFC8072] patches apply only to configuration data in configuration datastores.
配置数据，但可以包括任何对象（包括操作数据），而[RFC8072]修补程序仅适用于配置数据存储中的配置数据。
A publisher indicates the type of change to a datastore node using the different YANG Patch operations: the "create" operation is used for newly created objects (except entries in a user-ordered list), the "delete" operation is used for deleted objects (including in user-ordered lists), the "replace" operation is used when only the object value changes, the "insert" operation is used when a new entry is inserted in a list, and the "move" operation is used when an existing entry in a user-ordered list is moved.
发布者使用不同的操作指示对数据存储节点的更改类型：“创建”操作用于新创建的对象（用户排序列表中的条目除外），“删除”操作用于已删除的对象（包括用户排序列表中的对象），“替换”操作仅在对象值更改时使用，“插入”操作在列表中插入新条目时使用，“移动”操作在移动用户排序列表中的现有条目时使用。
However, a patch must be able to do more than just describe the delta from the previous state to the current state. As per Section 3.3, it must also be able to identify whether transient changes have occurred on an object during a dampening period. To support this, it is valid to encode a YANG Patch operation so that its application would result in no change between the previous state and the current state. This indicates that some churn has occurred on the object. An example of this would be a patch that indicates a "create" operation for a datastore node where the receiver believes one already exists or a "replace" operation that replaces a previous value with the same value. Note that this means that the "create" and "delete" errors as described in [RFC8072], Section 2.5 are not errors in the case of YANG-Push (i.e., they are considered valid operations for YANG-Push).
然而，补丁必须能够做的不仅仅是描述从先前状态到当前状态的增量。根据第3.3节，它还必须能够识别物体在阻尼期间是否发生瞬态变化。为了支持这一点，对YANG Patch操作进行编码是有效的，以便其应用程序不会导致前一个状态和当前状态之间的变化。这表示对象上发生了一些搅动。这方面的一个例子是一个补丁，该补丁指示一个数据存储节点的“创建”操作，其中接收方认为已经存在一个数据存储节点，或者一个“替换”操作，用相同的值替换以前的值。注意，这意味着[RFC8072]第2.5节中描述的“创建”和“删除”错误在YANG Push情况下不是错误（即，它们被视为YANG Push的有效操作）。
A subscription must specify both the selection filters and the datastore against which these selection filters will be applied. This information is used to choose and subsequently push data from the publisher's datastore to the receivers.
订阅必须同时指定选择筛选器和应用这些选择筛选器的数据存储。此信息用于选择并随后将数据从发布者的数据存储推送到接收者。
Only a single selection filter can be applied to a subscription at a time. An RPC request proposing a new selection filter replaces any existing filter. The following selection filter types are included in the YANG-Push data model and may be applied against a datastore:
一次只能对订阅应用单个选择筛选器。建议新选择筛选器的RPC请求将替换任何现有筛选器。以下选择过滤器类型包括在YANG Push数据模型中，可应用于数据存储：
o subtree: A subtree selection filter identifies one or more datastore subtrees. When specified, update records will only come from the datastore nodes of selected datastore subtree(s). The syntax and semantics correspond to those specified in [RFC6241], Section 6.
o 子树：子树选择过滤器标识一个或多个数据存储子树。指定时，更新记录将仅来自选定数据存储子树的数据存储节点。语法和语义对应于[RFC6241]第6节中规定的语法和语义。
o xpath: An "xpath" selection filter is an XPath expression that returns a node set. (XPath is a query language for selecting nodes in an XML document; see [XPATH] for details.) When specified, updates will only come from the selected datastore nodes.
o xpath：“xpath”选择筛选器是返回节点集的xpath表达式。（XPath是用于在XML文档中选择节点的查询语言；有关详细信息，请参见[XPath]）指定后，更新将仅来自选定的数据存储节点。
These filters are intended to be used as selectors that define which objects are within the scope of a subscription. A publisher MUST support at least one type of selection filter.
这些过滤器用作选择器，用于定义订阅范围内的对象。发布服务器必须至少支持一种类型的选择筛选器。
XPath itself provides powerful filtering constructs, and care must be used in filter definition. Consider an XPath filter that only passes a datastore node when an interface is up. It is up to the receiver to understand the implications of the presence or absence of objects in each update.
XPath本身提供了强大的过滤结构，在过滤器定义中必须谨慎使用。考虑一个XPath筛选器，它只在接口上升时传递数据存储节点。由接收者来理解每次更新中对象的存在或不存在的含义。
When the set of selection-filtering criteria is applied for a periodic subscription, these criteria are applied whenever a periodic update record is constructed, and only datastore nodes that pass the filter and to which a receiver has access are provided to that receiver. If the same filtering criteria are applied to an on-change subscription, only the subset of those datastore nodes supporting on-change is provided. A datastore node that doesn't support on-change is never sent as part of an on-change subscription's "push-update" or "push-change-update" (Section 3.7).
当为定期订阅应用选择筛选条件集时，每当构造定期更新记录时，都会应用这些条件，并且只有通过筛选且接收方有权访问的数据存储节点才会提供给该接收方。如果对更改订阅应用相同的筛选条件，则仅提供支持更改的数据存储节点的子集。不支持更改时的数据存储节点永远不会作为更改时订阅的“推送更新”或“推送更改更新”的一部分发送（第3.7节）。
Contrary to traditional data retrieval requests, datastore subscription enables an unbounded series of update records to be streamed over time. Two generic YANG notifications for update records have been defined for this scenario: "push-update" and "push-change-update".
与传统的数据检索请求相反，数据存储订阅使一系列无限的更新记录能够随时间流式传输。针对此场景定义了两个更新记录的通用通知：“推送更新”和“推送更改更新”。
A "push-update" notification defines a complete, filtered update of the datastore per the terms of a subscription. This type of YANG notification is used for continuous updates of periodic subscriptions. A "push-update" notification can also be used for the on-change subscriptions in two cases. First, it MUST be used as the initial "push-update" if there is a need to synchronize the receiver at the start of a new subscription. Second, it MAY be sent if the publisher later chooses to resync an on-change subscription. The "push-update" update record contains an instantiated datastore subtree with all of the subscribed contents. The content of the update record is equivalent to the contents that would be obtained had the same data been explicitly retrieved using a datastore retrieval operation using the same transport with the same filters applied.
“推送更新”通知根据订阅条款定义数据存储的完整过滤更新。这种类型的通知用于定期订阅的连续更新。在两种情况下，“推送更新”通知也可用于更改订阅。首先，如果需要在新订阅开始时同步接收器，则必须将其用作初始“推送更新”。其次，如果发布者稍后选择在更改订阅时重新同步，则可能会发送该消息。“push update”更新记录包含一个实例化的数据存储子树，其中包含所有订阅的内容。更新记录的内容与使用相同传输并应用相同筛选器的数据存储检索操作显式检索相同数据时获得的内容相同。
A "push-change-update" notification is the most common type of update for on-change subscriptions. The update record in this case contains the set of changes that datastore nodes have undergone since the last notification message. In other words, this indicates which datastore nodes have been created, have been deleted, or have had changes to their values. In cases where multiple changes have occurred over the course of a dampening period and the object has not been deleted, the object's most current value is reported. (In other words, for each object, only one change is reported, not its entire history. Doing so would defeat the purpose of the dampening period.)
“推送更改更新”通知是更改订阅最常见的更新类型。本例中的更新记录包含自上次通知消息以来数据存储节点所经历的一组更改。换句话说，这表示哪些数据存储节点已创建、已删除或其值已更改。如果在阻尼期间发生了多个更改，并且对象未被删除，则会报告对象的最新值。（换句话说，对于每个对象，只报告一个更改，而不是其整个历史。这样做会破坏缓冲期的目的。）
"push-update" and "push-change-update" are encoded and placed in notification messages and are ultimately queued for egress over the specified transport.
“推送更新”和“推送更改更新”被编码并放置在通知消息中，并最终排队等待通过指定传输的出口。
Figure 1 provides an example of a notification message for a subscription tracking the operational status of a single Ethernet interface (per [RFC8343]). This notification message is encoded XML [W3C.REC-xml-20081126] over the Network Configuration Protocol (NETCONF) as per [RFC8640].
图1提供了一个订阅的通知消息示例，用于跟踪单个以太网接口的运行状态（根据[RFC8343]）。根据[RFC8640]，此通知消息通过网络配置协议（NETCONF）编码为XML[W3C.REC-XML-20081126]。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2017-10-25T08:00:11.22Z</eventTime>
<push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>1011</id>
<datastore-contents>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<oper-status>up</oper-status>
</interface>
</interfaces>
</datastore-contents>
</push-update>
</notification>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2017-10-25T08:00:11.22Z</eventTime>
<push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>1011</id>
<datastore-contents>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<oper-status>up</oper-status>
</interface>
</interfaces>
</datastore-contents>
</push-update>
</notification>
Figure 1: Push Example
图1：推送示例
Figure 2 provides an example of an on-change notification message for the same subscription.
图2提供了同一订阅的更改通知消息示例。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2017-10-25T08:22:33.44Z</eventTime>
<push-change-update
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>89</id>
<datastore-changes>
<yang-patch>
<patch-id>0</patch-id>
<edit>
<edit-id>edit1</edit-id>
<operation>replace</operation>
<target>/ietf-interfaces:interfaces</target>
<value>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<oper-status>down</oper-status>
</interface>
</interfaces>
</value>
</edit>
</yang-patch>
</datastore-changes>
</push-change-update>
</notification>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2017-10-25T08:22:33.44Z</eventTime>
<push-change-update
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>89</id>
<datastore-changes>
<yang-patch>
<patch-id>0</patch-id>
<edit>
<edit-id>edit1</edit-id>
<operation>replace</operation>
<target>/ietf-interfaces:interfaces</target>
<value>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<oper-status>down</oper-status>
</interface>
</interfaces>
</value>
</edit>
</yang-patch>
</datastore-changes>
</push-change-update>
</notification>
Figure 2: Push Example for an On-Change Notification Message
图2：更改通知消息的推送示例
Of note in the above example is the "patch-id" with a value of "0". Per [RFC8072], the "patch-id" is an arbitrary string. With YANG-Push, the publisher SHOULD put into the "patch-id" a counter starting at "0" that increments with every "push-change-update" generated for a subscription. If used as a counter, this counter MUST be reset to "0" any time a resynchronization occurs (i.e., with the sending of a "push-update"). Also, if used as a counter, the counter MUST be reset to "0" after passing a maximum value of "4294967295" (i.e., the maximum value that can be represented using the uint32 data type). Such a mechanism allows easy identification of lost or out-of-sequence update records.
上述示例中值得注意的是“补丁id”，其值为“0”。根据[RFC8072]，补丁id是一个任意字符串。对于YANG Push，发布者应该在“补丁id”中输入一个从“0”开始的计数器，该计数器随着为订阅生成的每个“推送更改更新”而递增。如果用作计数器，则每当发生重新同步时（即，发送“推送更新”），必须将此计数器重置为“0”。此外，如果用作计数器，则在通过最大值“4294967295”（即可以使用uint32数据类型表示的最大值）后，计数器必须重置为“0”。这种机制允许轻松识别丢失或无序更新记录。
The RPCs defined in [RFC8639] have been enhanced to support datastore subscription negotiation. Also, new error codes have been added that are able to indicate why a datastore subscription attempt has failed, along with new yang-data that MAY be used to include details on input parameters that might result in a successful subsequent RPC invocation.
[RFC8639]中定义的RPC已得到增强，以支持数据存储订阅协商。此外，还添加了新的错误代码，这些代码能够指示数据存储订阅尝试失败的原因，以及可能用于包含可能导致后续RPC调用成功的输入参数详细信息的新数据。
The establishment or modification of a datastore subscription can be rejected for multiple reasons, including a subtree request that is too large or the inability of the publisher to push update records as frequently as requested. In such cases, no subscription is established. Instead, a subscription result that includes the reason for the failure is returned as part of the RPC response. As part of this response, a set of alternative subscription parameters MAY be returned that would likely have resulted in acceptance of the subscription request. The subscriber may consider including such parameters in future subscription attempts.
数据存储订阅的建立或修改可能会因多种原因而被拒绝，包括子树请求太大或发布者无法按请求的频率推送更新记录。在这种情况下，不会建立订阅。相反，包含失败原因的订阅结果将作为RPC响应的一部分返回。作为此响应的一部分，可能会返回一组可能导致接受订阅请求的替代订阅参数。用户可以考虑在未来的订阅尝试中包含这样的参数。
In the case of a rejected request for establishment of a datastore subscription, if there are hints, the hints SHOULD be transported in a yang-data "establish-subscription-datastore-error-info" container inserted into the RPC error response, in lieu of the "establish-subscription-stream-error-info" that is inserted in the case of a stream subscription.
在建立数据存储订阅的请求被拒绝的情况下，如果存在提示，则应将提示传输到插入RPC错误响应的数据“建立订阅数据存储错误信息”容器中，而不是“建立订阅流错误信息”在流订阅的情况下插入的。
Figure 3 shows a tree diagram for "establish-subscription-datastore-error-info". All tree diagrams used in this document follow the notation defined in [RFC8340].
图3显示了“建立订阅数据存储错误信息”的树形图。本文件中使用的所有树形图均遵循[RFC8340]中定义的符号。
yang-data establish-subscription-datastore-error-info
+--ro establish-subscription-datastore-error-info
+--ro reason? identityref
+--ro period-hint? centiseconds
+--ro filter-failure-hint? string
+--ro object-count-estimate? uint32
+--ro object-count-limit? uint32
+--ro kilobytes-estimate? uint32
+--ro kilobytes-limit? uint32
yang-data establish-subscription-datastore-error-info
+--ro establish-subscription-datastore-error-info
+--ro reason? identityref
+--ro period-hint? centiseconds
+--ro filter-failure-hint? string
+--ro object-count-estimate? uint32
+--ro object-count-limit? uint32
+--ro kilobytes-estimate? uint32
+--ro kilobytes-limit? uint32
Figure 3: "establish-subscription-datastore-error-info" Tree Diagram
图3：“建立订阅数据存储错误信息”树形图
Similarly, in the case of a rejected request for modification of a datastore subscription, if there are hints, the hints SHOULD be transported in a yang-data "modify-subscription-datastore-error-info" container inserted into the RPC error response, in lieu of the "modify-subscription-stream-error-info" that is inserted in the case of a stream subscription.
类似地，在修改数据存储订阅的请求被拒绝的情况下，如果存在提示，则应将提示传输到插入RPC错误响应的数据“修改订阅数据存储错误信息”容器中，而不是“修改订阅流错误信息”在流订阅的情况下插入的。
Figure 4 shows a tree diagram for "modify-subscription-datastore-error-info".
图4显示了“修改订阅数据存储错误信息”的树形图。
yang-data modify-subscription-datastore-error-info
+--ro modify-subscription-datastore-error-info
+--ro reason? identityref
+--ro period-hint? centiseconds
+--ro filter-failure-hint? string
+--ro object-count-estimate? uint32
+--ro object-count-limit? uint32
+--ro kilobytes-estimate? uint32
+--ro kilobytes-limit? uint32
yang-data modify-subscription-datastore-error-info
+--ro modify-subscription-datastore-error-info
+--ro reason? identityref
+--ro period-hint? centiseconds
+--ro filter-failure-hint? string
+--ro object-count-estimate? uint32
+--ro object-count-limit? uint32
+--ro kilobytes-estimate? uint32
+--ro kilobytes-limit? uint32
Figure 4: "modify-subscription-datastore-error-info" Tree Diagram
图4：“修改订阅数据存储错误信息”树形图
A receiver of subscription data MUST only be sent updates for which it has proper authorization. A publisher MUST ensure that no unauthorized data is included in push updates. To do so, it needs to apply all corresponding checks applicable at the time of a specific pushed update and, if necessary, silently remove any unauthorized data from datastore subtrees. This enables YANG data that is pushed based on subscriptions to be authorized in a way that is equivalent to a regular data retrieval ("get") operation.
订阅数据的接收方必须仅发送其具有适当授权的更新。发布者必须确保推送更新中不包含未经授权的数据。为此，它需要应用特定推送更新时适用的所有相应检查，并在必要时从数据存储子树中静默删除任何未经授权的数据。这使得基于订阅推送的数据能够以与常规数据检索（“get”）操作等效的方式获得授权。
Each "push-update" and "push-change-update" MUST have access control applied, as depicted in Figure 5. This includes validating that read access is permitted for any new objects selected since the last notification message was sent to a particular receiver. A publisher MUST silently omit data nodes from the results that the client is not authorized to see. To accomplish this, implementations SHOULD apply the conceptual authorization model of [RFC8341], specifically Section 3.2.4, extended to apply analogously to data nodes included in notifications, not just <rpc-reply> messages sent in response to <get> and <get-config> requests.
每个“推送更新”和“推送更改更新”都必须应用访问控制，如图5所示。这包括验证自上次通知消息发送到特定接收器以来，是否允许对所选的任何新对象进行读取访问。发布者必须悄悄地从客户端无权查看的结果中忽略数据节点。为了实现这一点，实现应该应用[RFC8341]的概念授权模型，特别是第3.2.4节，扩展到类似地应用于通知中包含的数据节点，而不仅仅是响应<get>和<get config>请求而发送的<rpc reply>消息。
+-----------------+ +--------------------+
push-update or --> | datastore node | yes | add datastore node |
push-change-update | access allowed? | ---> | to update record |
+-----------------+ +--------------------+
+-----------------+ +--------------------+
push-update or --> | datastore node | yes | add datastore node |
push-change-update | access allowed? | ---> | to update record |
+-----------------+ +--------------------+
Figure 5: Access Control for Push Updates
图5：推送更新的访问控制
A publisher MUST allow for the possibility that a subscription's selection filter references nonexistent data or data that a receiver is not allowed to access. Such support permits a receiver the ability to monitor the entire lifecycle of some datastore tree without needing to explicitly enumerate every individual datastore node. If, after access control has been applied, there are no objects remaining in an update record, then the effect varies given if the subscription is a periodic or on-change subscription. For a periodic subscription, an empty "push-update" notification MUST be sent, so that clients do not get confused into thinking that an update was lost. For an on-change subscription, a "push-update" notification MUST NOT be sent, so that clients remain unaware of changes made to nodes they don't have read-access for. By the same token, changes to objects that are filtered MUST NOT affect any dampening intervals.
发布者必须考虑订阅的选择筛选器引用不存在的数据或不允许接收者访问的数据的可能性。这种支持允许接收者监视某些数据存储树的整个生命周期，而无需显式枚举每个数据存储节点。如果在应用访问控制后，更新记录中没有剩余对象，则如果订阅是定期订阅或更改订阅，则效果会有所不同。对于定期订阅，必须发送一个空的“推送更新”通知，这样客户端就不会误以为更新丢失了。对于更改订阅，不得发送“推送更新”通知，以便客户端不知道对其没有读取权限的节点所做的更改。同样，对已筛选对象的更改不得影响任何阻尼间隔。
A publisher MAY choose to reject an "establish-subscription" request that selects nonexistent data or data that a receiver is not allowed to access. The error identity "unchanging-selection" SHOULD be returned as the reason for the rejection. In addition, a publisher MAY choose to terminate a dynamic subscription or suspend a configured receiver when the authorization privileges of a receiver change or the access controls for subscribed objects change. In that case, the publisher SHOULD include the error identity "unchanging-selection" as the reason when sending the "subscription-terminated" or "subscription-suspended" notification, respectively. Such a capability enables the publisher to avoid having to support continuous and total filtering of a subscription's content for every update record. It also reduces the possibility of leakage of access-controlled objects.
发布者可以选择拒绝选择不存在的数据或不允许接收者访问的数据的“建立订阅”请求。应返回错误标识“未更改的选择”作为拒绝的原因。此外，当接收器的授权权限或订阅对象的访问控制更改时，发布者可以选择终止动态订阅或挂起已配置的接收器。在这种情况下，发布者在分别发送“订阅已终止”或“订阅已暂停”通知时，应将错误标识“未更改选择”作为原因。这样的功能使发布者不必为每个更新记录支持订阅内容的连续和全面过滤。它还减少了访问控制对象泄漏的可能性。
If read access into previously accessible nodes has been lost due to a receiver permissions change, this SHOULD be reported as a patch "delete" operation for on-change subscriptions. If not capable of handling such receiver permission changes with such a "delete", publisher implementations MUST force dynamic subscription re-establishment or configured subscription reinitialization so that appropriate filtering is installed.
如果由于接收方权限更改而丢失了对以前可访问节点的读取访问，则应将此报告为更改订阅的修补程序“删除”操作。如果无法使用这种“删除”来处理此类接收方权限更改，则发布者实施必须强制重新建立动态订阅或重新初始化已配置的订阅，以便安装适当的筛选。
In some cases, a publisher supporting on-change notifications may not be able to push on-change updates for some object types. Reasons for this might be that the value of the datastore node changes frequently (e.g., the in-octets counter as defined in [RFC8343]), small object changes are frequent and meaningless (e.g., a temperature gauge changing 0.1 degrees), or the implementation is not capable of on-change notification for a particular object.
在某些情况下，支持更改通知的发布者可能无法推动某些对象类型的更改更新。其原因可能是数据存储节点的值经常变化（例如，[RFC8343]中定义的八位字节计数器），小对象变化频繁且无意义（例如，温度计变化0.1度），或者实现无法收到特定对象的变化通知。
In those cases, it will be important for client applications to have a way to identify for which objects on-change notifications are supported and for which ones they are not supported. Otherwise, client applications will have no way of knowing whether they can indeed rely on their on-change subscription to provide them with the change updates that they are interested in. In other words, if implementations do not provide a solution and do not support comprehensive on-change notifiability, clients of those implementations will have no way of knowing what their on-change subscription actually covers.
在这些情况下，客户机应用程序必须有一种方法来确定哪些更改通知对象受支持，哪些不受支持。否则，客户端应用程序将无法知道它们是否确实可以依赖其on change订阅来提供它们感兴趣的更改更新。换句话说，如果实现不提供解决方案，也不支持全面的变更通知性，那么这些实现的客户端将无法知道其变更订阅实际涵盖的内容。
Implementations are therefore strongly advised to provide a solution to this problem. One solution might involve making discoverable to clients which objects are on-change notifiable, specified using another YANG data model. Such a solution is specified in [Yang-Push-Notif-Cap]. Until this solution is standardized, implementations SHOULD provide their own solution.
因此，强烈建议实现提供此问题的解决方案。一种解决方案可能涉及使客户能够发现哪些对象是更改中的可通知对象，这是使用另一个数据模型指定的。[Yang Push Notif Cap]中规定了此类解决方案。在这个解决方案标准化之前，实现应该提供自己的解决方案。
It is important that updates as discussed in this document, and on-change updates in particular, do not get lost. If the loss of an update is unavoidable, it is critical that the receiver be notified accordingly.
重要的是，本文档中讨论的更新，尤其是更改更新，不要丢失。如果无法避免更新丢失，则必须相应地通知接收者。
Update records for a single subscription MUST NOT be resequenced prior to transport.
在传输之前，不得对单个订阅的更新记录重新排序。
It is conceivable that, under certain circumstances, a publisher will recognize that it is unable to include in an update record the full set of objects desired per the terms of a subscription. In this case, the publisher MUST act as follows.
可以想象，在某些情况下，发布者会认识到，它无法在更新记录中包含订阅条款所需的完整对象集。在这种情况下，发布者必须执行以下操作。
o The publisher MUST set the "incomplete-update" flag on any update record that is known to be missing information.
o 发布者必须在已知缺少信息的任何更新记录上设置“未完成更新”标志。
o The publisher MAY choose to suspend the subscription as per [RFC8639]. If the publisher does not create an update record at all, it MUST suspend the subscription.
o 发布者可根据[RFC8639]选择暂停订阅。如果发布者根本不创建更新记录，则必须暂停订阅。
o When resuming an on-change subscription, the publisher SHOULD generate a complete patch from the previous update record. If this is not possible and the "sync-on-start" option is set to "true" for the subscription, then the full datastore contents MAY be sent via a "push-update" instead (effectively replacing the previous contents). If neither scenario above is possible, then an "incomplete-update" flag MUST be included on the next "push-change-update".
o 恢复更改订阅时，发布者应根据以前的更新记录生成完整的修补程序。如果这是不可能的，并且订阅的“启动时同步”选项设置为“true”，则可以通过“推送更新”发送完整的数据存储内容（有效地替换以前的内容）。如果上述两种情况都不可能，则必须在下一次“推送更改更新”中包含“未完成更新”标志。
Note: It is perfectly acceptable to have a series of "push-change-update" notifications (and even "push-update" notifications) serially queued at the transport layer awaiting transmission. It is not required for the publisher to merge pending update records sent at the same time.
注意：一系列“推送更改更新”通知（甚至“推送更新”通知）在传输层串行排队等待传输是完全可以接受的。发布者无需合并同时发送的挂起更新记录。
On the receiver side, what action to take when a record with an "incomplete-update" flag is received depends on the application. It could simply choose to wait and do nothing. It could choose to resync, actively retrieving all subscribed information. It could also choose to tear down the subscription and start a new one, perhaps with a smaller scope that contains fewer objects.
在接收方，接收到带有“未完成更新”标志的记录时要采取的操作取决于应用程序。它可以选择等待，什么也不做。它可以选择重新同步，主动检索所有订阅的信息。它还可以选择取消订阅并启动一个新的订阅，可能使用更小的范围，包含更少的对象。
It is far preferable to decline a subscription request than to accept such a request when it cannot be met.
拒绝订阅请求远比在无法满足时接受此类请求要好得多。
Whether or not a subscription can be supported will be determined by a combination of several factors, such as the subscription update trigger (on-change or periodic), the period in which to report changes (one-second periods will consume more resources than one-hour periods), the amount of data in the datastore subtree that is being subscribed to, and the number and combination of other subscriptions that are concurrently being serviced.
能否支持订阅将取决于多个因素的组合，例如订阅更新触发器（更改或定期）、报告更改的时间段（一秒时间段将消耗比一小时时间段更多的资源）、订阅的数据存储子树中的数据量、，以及同时提供服务的其他订阅的数量和组合。
The YANG data model for datastore push subscriptions is depicted in Figures 6 through 9. The tree diagram that is used follows the notation defined in [RFC8340]. New schema objects defined here (i.e., beyond those from [RFC8639]) are identified with "yp". For the reader's convenience, in order to compact the tree representation, some nodes that are defined in the ietf-subscribed-notifications YANG module [RFC8639] and therefore are not essential to the understanding of the data model defined here have been removed. This is indicated by "..." in the diagram where applicable.
数据存储推送订阅的YANG数据模型如图6至图9所示。使用的树形图遵循[RFC8340]中定义的符号。此处定义的新模式对象（即[RFC8639]中定义的对象之外的对象）用“yp”标识。为方便读者，为了压缩树表示，已删除ietf模块[RFC8639]中定义的一些节点，因此这些节点对于理解此处定义的数据模型不是必需的。在适用的情况下，图中用“…”表示。
Because the tree diagram is quite large, its depiction is broken up into four figures. Figure 6 depicts the augmentations that are introduced in YANG module ietf-yang-push to the subscription configuration specified in YANG module ietf-subscribed-notifications.
因为树形图相当大，它的描绘被分成四个图形。图6描述了YANG模块ietf中引入的对YANG模块ietf订阅通知中指定的订阅配置的扩展。
module: ietf-subscribed-notifications
...
+--rw filters
| ...
| +--rw yp:selection-filter* [filter-id]
| +--rw yp:filter-id string
| +--rw (yp:filter-spec)?
| +--:(yp:datastore-subtree-filter)
| | +--rw yp:datastore-subtree-filter? <anydata>
| | {sn:subtree}?
| +--:(yp:datastore-xpath-filter)
| +--rw yp:datastore-xpath-filter? yang:xpath1.0
| {sn:xpath}?
+--rw subscriptions
+--rw subscription* [id]
| ...
+--rw (target)
| +--:(stream)
| | ...
| +--:(yp:datastore)
| +--rw yp:datastore identityref
| +--rw (yp:selection-filter)?
| +--:(yp:by-reference)
| | +--rw yp:selection-filter-ref
| | selection-filter-ref
| +--:(yp:within-subscription)
| +--rw (yp:filter-spec)?
| +--:(yp:datastore-subtree-filter)
| | +--rw yp:datastore-subtree-filter?
| | <anydata> {sn:subtree}?
| +--:(yp:datastore-xpath-filter)
| +--rw yp:datastore-xpath-filter?
| yang:xpath1.0 {sn:xpath}?
| ...
+--rw (yp:update-trigger)
+--:(yp:periodic)
| +--rw yp:periodic!
| +--rw yp:period centiseconds
| +--rw yp:anchor-time? yang:date-and-time
+--:(yp:on-change) {on-change}?
+--rw yp:on-change!
+--rw yp:dampening-period? centiseconds
+--rw yp:sync-on-start? boolean
+--rw yp:excluded-change* change-type
module: ietf-subscribed-notifications
...
+--rw filters
| ...
| +--rw yp:selection-filter* [filter-id]
| +--rw yp:filter-id string
| +--rw (yp:filter-spec)?
| +--:(yp:datastore-subtree-filter)
| | +--rw yp:datastore-subtree-filter? <anydata>
| | {sn:subtree}?
| +--:(yp:datastore-xpath-filter)
| +--rw yp:datastore-xpath-filter? yang:xpath1.0
| {sn:xpath}?
+--rw subscriptions
+--rw subscription* [id]
| ...
+--rw (target)
| +--:(stream)
| | ...
| +--:(yp:datastore)
| +--rw yp:datastore identityref
| +--rw (yp:selection-filter)?
| +--:(yp:by-reference)
| | +--rw yp:selection-filter-ref
| | selection-filter-ref
| +--:(yp:within-subscription)
| +--rw (yp:filter-spec)?
| +--:(yp:datastore-subtree-filter)
| | +--rw yp:datastore-subtree-filter?
| | <anydata> {sn:subtree}?
| +--:(yp:datastore-xpath-filter)
| +--rw yp:datastore-xpath-filter?
| yang:xpath1.0 {sn:xpath}?
| ...
+--rw (yp:update-trigger)
+--:(yp:periodic)
| +--rw yp:periodic!
| +--rw yp:period centiseconds
| +--rw yp:anchor-time? yang:date-and-time
+--:(yp:on-change) {on-change}?
+--rw yp:on-change!
+--rw yp:dampening-period? centiseconds
+--rw yp:sync-on-start? boolean
+--rw yp:excluded-change* change-type
Figure 6: Data Model Structure: Subscription Configuration
图6：数据模型结构：订阅配置
Figure 7 depicts the augmentations of YANG module ietf-yang-push made to RPCs specified in YANG module ietf-subscribed-notifications [RFC8639]. Specifically, these augmentations concern the "establish-subscription" and "modify-subscription" RPCs, which are augmented with parameters that are needed to specify datastore push subscriptions.
图7描述了YANG模块ietf YANG push对YANG模块ietf订阅通知[RFC8639]中指定的RPC的增强。具体而言，这些扩展涉及“建立订阅”和“修改订阅”RPC，它们通过指定数据存储推送订阅所需的参数进行了扩展。
rpcs:
+---x establish-subscription
| +---w input
| | ...
| | +---w (target)
| | | +--:(stream)
| | | | ...
| | | +--:(yp:datastore)
| | | +---w yp:datastore identityref
| | | +---w (yp:selection-filter)?
| | | +--:(yp:by-reference)
| | | | +---w yp:selection-filter-ref
| | | | selection-filter-ref
| | | +--:(yp:within-subscription)
| | | +---w (yp:filter-spec)?
| | | +--:(yp:datastore-subtree-filter)
| | | | +---w yp:datastore-subtree-filter?
| | | | <anydata> {sn:subtree}?
| | | +--:(yp:datastore-xpath-filter)
| | | +---w yp:datastore-xpath-filter?
| | | yang:xpath1.0 {sn:xpath}?
| | | ...
| | +---w (yp:update-trigger)
| | +--:(yp:periodic)
| | | +---w yp:periodic!
| | | +---w yp:period centiseconds
| | | +---w yp:anchor-time? yang:date-and-time
| | +--:(yp:on-change) {on-change}?
| | +---w yp:on-change!
| | +---w yp:dampening-period? centiseconds
| | +---w yp:sync-on-start? boolean
| | +---w yp:excluded-change* change-type
| +--ro output
| +--ro id subscription-id
| +--ro replay-start-time-revision? yang:date-and-time
| {replay}?
rpcs:
+---x establish-subscription
| +---w input
| | ...
| | +---w (target)
| | | +--:(stream)
| | | | ...
| | | +--:(yp:datastore)
| | | +---w yp:datastore identityref
| | | +---w (yp:selection-filter)?
| | | +--:(yp:by-reference)
| | | | +---w yp:selection-filter-ref
| | | | selection-filter-ref
| | | +--:(yp:within-subscription)
| | | +---w (yp:filter-spec)?
| | | +--:(yp:datastore-subtree-filter)
| | | | +---w yp:datastore-subtree-filter?
| | | | <anydata> {sn:subtree}?
| | | +--:(yp:datastore-xpath-filter)
| | | +---w yp:datastore-xpath-filter?
| | | yang:xpath1.0 {sn:xpath}?
| | | ...
| | +---w (yp:update-trigger)
| | +--:(yp:periodic)
| | | +---w yp:periodic!
| | | +---w yp:period centiseconds
| | | +---w yp:anchor-time? yang:date-and-time
| | +--:(yp:on-change) {on-change}?
| | +---w yp:on-change!
| | +---w yp:dampening-period? centiseconds
| | +---w yp:sync-on-start? boolean
| | +---w yp:excluded-change* change-type
| +--ro output
| +--ro id subscription-id
| +--ro replay-start-time-revision? yang:date-and-time
| {replay}?
+---x modify-subscription
| +---w input
| ...
| +---w (target)
| | ...
| | +--:(yp:datastore)
| | +---w yp:datastore identityref
| | +---w (yp:selection-filter)?
| | +--:(yp:by-reference)
| | | +---w yp:selection-filter-ref
| | | selection-filter-ref
| | +--:(yp:within-subscription)
| | +---w (yp:filter-spec)?
| | +--:(yp:datastore-subtree-filter)
| | | +---w yp:datastore-subtree-filter?
| | | <anydata> {sn:subtree}?
| | +--:(yp:datastore-xpath-filter)
| | +---w yp:datastore-xpath-filter?
| | yang:xpath1.0 {sn:xpath}?
| | ...
| +---w (yp:update-trigger)
| +--:(yp:periodic)
| | +---w yp:periodic!
| | +---w yp:period centiseconds
| | +---w yp:anchor-time? yang:date-and-time
| +--:(yp:on-change) {on-change}?
| +---w yp:on-change!
| +---w yp:dampening-period? centiseconds
+---x delete-subscription
| ...
+---x kill-subscription
...
+---x modify-subscription
| +---w input
| ...
| +---w (target)
| | ...
| | +--:(yp:datastore)
| | +---w yp:datastore identityref
| | +---w (yp:selection-filter)?
| | +--:(yp:by-reference)
| | | +---w yp:selection-filter-ref
| | | selection-filter-ref
| | +--:(yp:within-subscription)
| | +---w (yp:filter-spec)?
| | +--:(yp:datastore-subtree-filter)
| | | +---w yp:datastore-subtree-filter?
| | | <anydata> {sn:subtree}?
| | +--:(yp:datastore-xpath-filter)
| | +---w yp:datastore-xpath-filter?
| | yang:xpath1.0 {sn:xpath}?
| | ...
| +---w (yp:update-trigger)
| +--:(yp:periodic)
| | +---w yp:periodic!
| | +---w yp:period centiseconds
| | +---w yp:anchor-time? yang:date-and-time
| +--:(yp:on-change) {on-change}?
| +---w yp:on-change!
| +---w yp:dampening-period? centiseconds
+---x delete-subscription
| ...
+---x kill-subscription
...
yang-data (for placement into RPC error responses) ...
yang数据（用于放置到RPC错误响应中）。。。
Figure 7: Data Model Structure: RPCs
图7：数据模型结构：RPC
Figure 8 depicts augmentations of YANG module ietf-yang-push to the notifications that are specified in YANG module ietf-subscribed-notifications. The augmentations allow the inclusion of subscription configuration parameters that are specific to datastore push subscriptions as part of "subscription-started" and "subscription-modified" notifications.
图8描述了YANG模块ietf YANG push对YANG模块ietf订阅通知中指定的通知的扩展。这些扩展允许在“订阅已启动”和“订阅已修改”通知中包含特定于数据存储推送订阅的订阅配置参数。
notifications:
+---n replay-completed {replay}?
| ...
+---n subscription-completed
| ...
+---n subscription-started {configured}?
| | ...
| +--ro (target)
| | ...
| | +--:(yp:datastore)
| | +--ro yp:datastore identityref
| | +--ro (yp:selection-filter)?
| | +--:(yp:by-reference)
| | | +--ro yp:selection-filter-ref
| | | selection-filter-ref
| | +--:(yp:within-subscription)
| | +--ro (yp:filter-spec)?
| | +--:(yp:datastore-subtree-filter)
| | | +--ro yp:datastore-subtree-filter?
| | | <anydata> {sn:subtree}?
| | +--:(yp:datastore-xpath-filter)
| | +--ro yp:datastore-xpath-filter?
| | yang:xpath1.0 {sn:xpath}?
| ...
| +--ro (yp:update-trigger)
| +--:(yp:periodic)
| | +--ro yp:periodic!
| | +--ro yp:period centiseconds
| | +--ro yp:anchor-time? yang:date-and-time
| +--:(yp:on-change) {on-change}?
| +--ro yp:on-change!
| +--ro yp:dampening-period? centiseconds
| +--ro yp:sync-on-start? boolean
| +--ro yp:excluded-change* change-type
+---n subscription-resumed
| ...
notifications:
+---n replay-completed {replay}?
| ...
+---n subscription-completed
| ...
+---n subscription-started {configured}?
| | ...
| +--ro (target)
| | ...
| | +--:(yp:datastore)
| | +--ro yp:datastore identityref
| | +--ro (yp:selection-filter)?
| | +--:(yp:by-reference)
| | | +--ro yp:selection-filter-ref
| | | selection-filter-ref
| | +--:(yp:within-subscription)
| | +--ro (yp:filter-spec)?
| | +--:(yp:datastore-subtree-filter)
| | | +--ro yp:datastore-subtree-filter?
| | | <anydata> {sn:subtree}?
| | +--:(yp:datastore-xpath-filter)
| | +--ro yp:datastore-xpath-filter?
| | yang:xpath1.0 {sn:xpath}?
| ...
| +--ro (yp:update-trigger)
| +--:(yp:periodic)
| | +--ro yp:periodic!
| | +--ro yp:period centiseconds
| | +--ro yp:anchor-time? yang:date-and-time
| +--:(yp:on-change) {on-change}?
| +--ro yp:on-change!
| +--ro yp:dampening-period? centiseconds
| +--ro yp:sync-on-start? boolean
| +--ro yp:excluded-change* change-type
+---n subscription-resumed
| ...
+---n subscription-modified
| ...
| +--ro (target)
| | | ...
| | +--:(yp:datastore)
| | +--ro yp:datastore identityref
| | +--ro (yp:selection-filter)?
| | +--:(yp:by-reference)
| | | +--ro yp:selection-filter-ref
| | | selection-filter-ref
| | +--:(yp:within-subscription)
| | +--ro (yp:filter-spec)?
| | +--:(yp:datastore-subtree-filter)
| | | +--ro yp:datastore-subtree-filter?
| | | <anydata> {sn:subtree}?
| | +--:(yp:datastore-xpath-filter)
| | +--ro yp:datastore-xpath-filter?
| | yang:xpath1.0 {sn:xpath}?
| ...
| +--ro (yp:update-trigger)?
| +--:(yp:periodic)
| | +--ro yp:periodic!
| | +--ro yp:period centiseconds
| | +--ro yp:anchor-time? yang:date-and-time
| +--:(yp:on-change) {on-change}?
| +--ro yp:on-change!
| +--ro yp:dampening-period? centiseconds
| +--ro yp:sync-on-start? boolean
| +--ro yp:excluded-change* change-type
+---n subscription-terminated
| ...
+---n subscription-suspended
...
+---n subscription-modified
| ...
| +--ro (target)
| | | ...
| | +--:(yp:datastore)
| | +--ro yp:datastore identityref
| | +--ro (yp:selection-filter)?
| | +--:(yp:by-reference)
| | | +--ro yp:selection-filter-ref
| | | selection-filter-ref
| | +--:(yp:within-subscription)
| | +--ro (yp:filter-spec)?
| | +--:(yp:datastore-subtree-filter)
| | | +--ro yp:datastore-subtree-filter?
| | | <anydata> {sn:subtree}?
| | +--:(yp:datastore-xpath-filter)
| | +--ro yp:datastore-xpath-filter?
| | yang:xpath1.0 {sn:xpath}?
| ...
| +--ro (yp:update-trigger)?
| +--:(yp:periodic)
| | +--ro yp:periodic!
| | +--ro yp:period centiseconds
| | +--ro yp:anchor-time? yang:date-and-time
| +--:(yp:on-change) {on-change}?
| +--ro yp:on-change!
| +--ro yp:dampening-period? centiseconds
| +--ro yp:sync-on-start? boolean
| +--ro yp:excluded-change* change-type
+---n subscription-terminated
| ...
+---n subscription-suspended
...
Figure 8: Data Model Structure: Notifications
图8：数据模型结构：通知
Finally, Figure 9 depicts the parts of YANG module ietf-yang-push that are newly introduced in this document (i.e., that are not simply augmentations of another YANG module).
最后，图9描述了本文档中新引入的YANG模块ietf YANG push的各个部分（即，它们不仅仅是另一个YANG模块的扩展）。
module: ietf-yang-push
模块：ietf yang push
rpcs:
+---x resync-subscription {on-change}?
+---w input
+---w id sn:subscription-id
rpcs:
+---x resync-subscription {on-change}?
+---w input
+---w id sn:subscription-id
yang-data (for placement into RPC error responses):
+-- resync-subscription-error
| +--ro reason? identityref
| +--ro period-hint? centiseconds
| +--ro filter-failure-hint? string
| +--ro object-count-estimate? uint32
| +--ro object-count-limit? uint32
| +--ro kilobytes-estimate? uint32
| +--ro kilobytes-limit? uint32
+-- establish-subscription-error-datastore
| +--ro reason? identityref
| +--ro period-hint? centiseconds
| +--ro filter-failure-hint? string
| +--ro object-count-estimate? uint32
| +--ro object-count-limit? uint32
| +--ro kilobytes-estimate? uint32
| +--ro kilobytes-limit? uint32
+-- modify-subscription-error-datastore
+--ro reason? identityref
+--ro period-hint? centiseconds
+--ro filter-failure-hint? string
+--ro object-count-estimate? uint32
+--ro object-count-limit? uint32
+--ro kilobytes-estimate? uint32
+--ro kilobytes-limit? uint32
yang-data (for placement into RPC error responses):
+-- resync-subscription-error
| +--ro reason? identityref
| +--ro period-hint? centiseconds
| +--ro filter-failure-hint? string
| +--ro object-count-estimate? uint32
| +--ro object-count-limit? uint32
| +--ro kilobytes-estimate? uint32
| +--ro kilobytes-limit? uint32
+-- establish-subscription-error-datastore
| +--ro reason? identityref
| +--ro period-hint? centiseconds
| +--ro filter-failure-hint? string
| +--ro object-count-estimate? uint32
| +--ro object-count-limit? uint32
| +--ro kilobytes-estimate? uint32
| +--ro kilobytes-limit? uint32
+-- modify-subscription-error-datastore
+--ro reason? identityref
+--ro period-hint? centiseconds
+--ro filter-failure-hint? string
+--ro object-count-estimate? uint32
+--ro object-count-limit? uint32
+--ro kilobytes-estimate? uint32
+--ro kilobytes-limit? uint32
notifications:
+---n push-update
| +--ro id? sn:subscription-id
| +--ro datastore-contents? <anydata>
| +--ro incomplete-update? empty
+---n push-change-update {on-change}?
+--ro id? sn:subscription-id
+--ro datastore-changes
| +--ro yang-patch
| +--ro patch-id string
| +--ro comment? string
| +--ro edit* [edit-id]
| +--ro edit-id string
| +--ro operation enumeration
| +--ro target target-resource-offset
| +--ro point? target-resource-offset
| +--ro where? enumeration
| +--ro value? <anydata>
+--ro incomplete-update? empty
notifications:
+---n push-update
| +--ro id? sn:subscription-id
| +--ro datastore-contents? <anydata>
| +--ro incomplete-update? empty
+---n push-change-update {on-change}?
+--ro id? sn:subscription-id
+--ro datastore-changes
| +--ro yang-patch
| +--ro patch-id string
| +--ro comment? string
| +--ro edit* [edit-id]
| +--ro edit-id string
| +--ro operation enumeration
| +--ro target target-resource-offset
| +--ro point? target-resource-offset
| +--ro where? enumeration
| +--ro value? <anydata>
+--ro incomplete-update? empty
Figure 9: Data Model Structure: Non-augmentation Portions
图9：数据模型结构：非扩充部分
Selected components of the data model are summarized below.
数据模型的选定组件总结如下。
Both configured and dynamic subscriptions are represented in the list "subscription". New parameters extending the basic subscription data model in [RFC8639] include:
配置订阅和动态订阅都在列表“订阅”中表示。[RFC8639]中扩展基本订阅数据模型的新参数包括：
o The targeted datastore from which the selection is being made. The potential datastores include those from [RFC8342]. A platform may also choose to support a custom datastore.
o 正在从中进行选择的目标数据存储。潜在的数据存储包括[RFC8342]中的数据存储。平台也可以选择支持自定义数据存储。
o A selection filter identifying YANG nodes of interest in a datastore. Filter contents are specified via a reference to an existing filter or via an in-line definition for only that subscription. Referenced filters allow an implementation to avoid evaluating filter acceptability during a dynamic subscription request. The "case" statement differentiates the options.
o 识别数据存储中感兴趣节点的选择过滤器。通过对现有筛选器的引用或仅通过该订阅的内嵌定义来指定筛选器内容。引用的筛选器允许实现在动态订阅请求期间避免评估筛选器可接受性。“案例”陈述区分了选项。
o For periodic subscriptions, triggered updates will occur at the boundaries of a specified time interval. These boundaries can be calculated from the periodic parameters:
o 对于定期订阅，触发的更新将在指定时间间隔的边界处发生。可根据周期参数计算这些边界：
* a "period" that defines the duration between push updates.
* 定义推送更新之间持续时间的“期间”。
* an "anchor-time"; update intervals fall on the points in time that are a multiple of a "period" from an "anchor-time". If an "anchor-time" is not provided, then the "anchor-time" MUST be set with the creation time of the initial update record.
* “锚定时间”；更新间隔落在时间点上，这些时间点是“锚定时间”的倍数。如果未提供“锚定时间”，则“锚定时间”必须与初始更新记录的创建时间一起设置。
o For on-change subscriptions, assuming that any dampening period has completed, triggering occurs whenever a change in the subscribed information is detected. On-change subscriptions have more-complex semantics that are guided by their own set of parameters:
o 对于更改订阅，假设任何缓冲期都已完成，只要检测到订阅信息中的更改，就会触发。更改订阅具有更复杂的语义，这些语义由它们自己的一组参数指导：
* a "dampening-period" that specifies the interval that must pass before a successive update for the subscription is sent. If no dampening period is in effect, the update is sent immediately. If a subsequent change is detected, another update is only sent once the dampening period has passed for this subscription.
* “缓冲期”，指定在发送订阅的后续更新之前必须经过的时间间隔。如果没有有效的缓冲期，则立即发送更新。如果检测到后续更改，则仅在该订阅的缓冲期结束后发送另一个更新。
* an "excluded-change" that allows the restriction of the types of changes for which updates should be sent (e.g., only add to an update record on object creation).
* 一种“排除的更改”，允许限制应发送更新的更改类型（例如，仅在对象创建时添加到更新记录）。
* a "sync-on-start" that specifies whether a complete update with all the subscribed data is to be sent at the beginning of a subscription.
* “启动时同步”指定是否在订阅开始时发送包含所有订阅数据的完整更新。
Subscription state notifications and mechanisms are reused from [RFC8639]. Notifications "subscription-started" and "subscription-modified" have been augmented to include the datastore-specific objects.
从[RFC8639]重用订阅状态通知和机制。“订阅已启动”和“订阅已修改”通知已扩展，以包括特定于数据存储的对象。
Along with the subscribed content, there are other objects that might be part of a "push-update" or "push-change-update" notification.
除了订阅的内容外，还有其他对象可能是“推送更新”或“推送更改更新”通知的一部分。
o An "id" (that identifies the subscription). This object MUST be transported along with the subscribed contents. It allows a receiver to determine which subscription resulted in a particular update record.
o “id”（用于标识订阅）。此对象必须与订阅的内容一起传输。它允许接收者确定导致特定更新记录的订阅。
o An "incomplete-update" leaf. This leaf indicates that not all changes that have occurred since the last update are actually included with this update. In other words, the publisher has failed to fulfill its full subscription obligations. (For example, a datastore was unable to provide the full set of datastore nodes to a publisher process.) To facilitate the resynchronization of on-change subscriptions, a publisher MAY subsequently send a "push-update" containing a full selection snapshot of subscribed data.
o “不完整更新”叶。此叶表示并非自上次更新以来发生的所有更改都包含在此更新中。换句话说，出版商未能履行其全部订阅义务。（例如，数据存储无法向发布者进程提供完整的数据存储节点集。）为了便于更改订阅的重新同步，发布者可能会随后发送一个“推送更新”，其中包含订阅数据的完整选择快照。
YANG-Push subscriptions are established, modified, and deleted using RPCs augmented from [RFC8639].
使用[RFC8639]扩充的RPC建立、修改和删除推送订阅。
The subscriber sends an "establish-subscription" RPC with the parameters listed in Section 3.1. An example might look like:
订户发送“建立订阅”RPC，参数见第3.1节。例如：
<netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0">
/ex:foo
</yp:datastore-xpath-filter>
<yp:periodic>
<yp:period>500</yp:period>
</yp:periodic>
</establish-subscription>
</netconf:rpc>
<netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0">
/ex:foo
</yp:datastore-xpath-filter>
<yp:periodic>
<yp:period>500</yp:period>
</yp:periodic>
</establish-subscription>
</netconf:rpc>
Figure 10: "establish-subscription" RPC
图10：“建立订阅”RPC
A positive response includes the "id" of the accepted subscription. In that case, a publisher may respond as follows:
肯定响应包括已接受订阅的“id”。在这种情况下，出版商可能会做出如下回应：
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
52
</id>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
52
</id>
</rpc-reply>
Figure 11: "establish-subscription" Positive RPC Response
图11：“建立订阅”积极RPC响应
A subscription can be rejected for multiple reasons, including the lack of authorization to establish a subscription, no capacity to serve the subscription at the publisher, or the inability of the publisher to select datastore content at the requested cadence.
订阅可能会因多种原因而被拒绝，包括缺乏建立订阅的授权、发布服务器无法为订阅提供服务，或者发布服务器无法按请求的间隔选择数据存储内容。
If a request is rejected because the publisher is not able to serve it, the publisher SHOULD include in the returned error hints that help a subscriber understand what subscription parameters might have been accepted for the request. These hints would be included in the yang-data structure "establish-subscription-error-datastore". However, even with these hints, there are no guarantees that subsequent requests will in fact be accepted.
如果请求因发布服务器无法提供服务而被拒绝，则发布服务器应在返回的错误提示中包含这些提示，以帮助订阅服务器了解可能已接受请求的订阅参数。这些提示将包含在数据结构“建立订阅错误数据存储”中。然而，即使有这些提示，也不能保证后续请求实际上会被接受。
The specific parameters to be returned as part of the RPC error response depend on the specific transport that is used to manage the subscription. For NETCONF, those parameters are defined in [RFC8640]. For example, for the following NETCONF request:
作为RPC错误响应的一部分返回的特定参数取决于用于管理订阅的特定传输。对于NETCONF，这些参数在[RFC8640]中定义。例如，对于以下NETCONF请求：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0">
/ex:foo
</yp:datastore-xpath-filter>
<yp:on-change>
<yp:dampening-period>100</yp:dampening-period>
</yp:on-change>
</establish-subscription>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0">
/ex:foo
</yp:datastore-xpath-filter>
<yp:on-change>
<yp:dampening-period>100</yp:dampening-period>
</yp:on-change>
</establish-subscription>
</rpc>
Figure 12: "establish-subscription" Request: Example 2
图12：“建立订阅”请求：示例2
A publisher that cannot serve on-change updates but can serve periodic updates might return the following NETCONF response:
无法提供更改更新但可以提供定期更新的发布服务器可能会返回以下NETCONF响应：
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-path>/yp:periodic/yp:period</error-path>
<error-info>
<yp:establish-subscription-error-datastore>
<yp:reason>yp:on-change-unsupported</yp:reason>
</yp:establish-subscription-error-datastore>
</error-info>
</rpc-error>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-path>/yp:periodic/yp:period</error-path>
<error-info>
<yp:establish-subscription-error-datastore>
<yp:reason>yp:on-change-unsupported</yp:reason>
</yp:establish-subscription-error-datastore>
</error-info>
</rpc-error>
</rpc-reply>
Figure 13: "establish-subscription" Error Response: Example 2
图13：“建立订阅”错误响应：示例2
The subscriber MAY invoke the "modify-subscription" RPC for a subscription it previously established. The subscriber will include newly desired values in the "modify-subscription" RPC. Parameters not included MUST remain unmodified. Figure 14 provides an example where a subscriber attempts to modify the period and datastore XPath filter of a subscription using NETCONF.
订阅者可以为其先前建立的订阅调用“修改订阅”RPC。订阅服务器将在“修改订阅”RPC中包含新的所需值。未包含的参数必须保持不变。图14提供了一个示例，其中订户尝试使用NETCONF修改订阅的句点和数据存储XPath过滤器。
<rpc message-id="102"
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>1011</id>
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0">
/ex:bar
</yp:datastore-xpath-filter>
<yp:periodic>
<yp:period>250</yp:period>
</yp:periodic>
</modify-subscription>
</rpc>
<rpc message-id="102"
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>1011</id>
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0">
/ex:bar
</yp:datastore-xpath-filter>
<yp:periodic>
<yp:period>250</yp:period>
</yp:periodic>
</modify-subscription>
</rpc>
Figure 14: "modify-subscription" Request
图14：“修改订阅”请求
The publisher MUST respond to the subscription modification request. If the request is rejected, the existing subscription is left unchanged, and the publisher MUST send an RPC error response. This response might have hints encapsulated in the yang-data structure "modify-subscription-error-datastore". A subscription MAY be modified multiple times.
发布者必须响应订阅修改请求。如果请求被拒绝，现有订阅将保持不变，发布服务器必须发送RPC错误响应。此响应可能包含封装在数据结构“修改订阅错误数据存储”中的提示。订阅可以修改多次。
The specific parameters to be returned as part of the RPC error response depend on the specific transport that is used to manage the subscription. For NETCONF, those parameters are specified in [RFC8640].
作为RPC错误响应的一部分返回的特定参数取决于用于管理订阅的特定传输。对于NETCONF，这些参数在[RFC8640]中指定。
A configured subscription cannot be modified using a "modify-subscription" RPC. Instead, the configuration needs to be edited as needed.
无法使用“修改订阅”RPC修改配置的订阅。相反，需要根据需要编辑配置。
To stop receiving updates from a subscription and effectively delete a subscription that had previously been established using an "establish-subscription" RPC, a subscriber can send a "delete-subscription" RPC, which takes as its only input the subscription's "id". This RPC is unmodified from [RFC8639].
要停止从订阅接收更新并有效删除以前使用“建立订阅”RPC建立的订阅，订阅服务器可以发送“删除订阅”RPC，该RPC将订阅的“id”作为其唯一输入。此RPC未经[RFC8639]修改。
This RPC is supported only for on-change subscriptions previously established using an "establish-subscription" RPC. For example:
此RPC仅支持以前使用“建立订阅”RPC建立的更改订阅。例如：
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<resync-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>1011</id>
</resync-subscription>
</rpc>
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<resync-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>1011</id>
</resync-subscription>
</rpc>
Figure 15: "resync-subscription"
图15：“重新同步订阅”
On receipt, a publisher must either (1) accept the request and quickly follow with a "push-update" or (2) send an appropriate error in an RPC error response. In its error response, the publisher MAY include, in the yang-data structure "resync-subscription-error", supplemental information about the reasons for the error.
收到请求后，发布者必须（1）接受请求并快速执行“推送更新”，或者（2）在RPC错误响应中发送适当的错误。在其错误响应中，发布者可以在数据结构“resync subscription error”中包含关于错误原因的补充信息。
To make subscription requests, the subscriber needs to know the YANG datastore schemas used by the publisher. These schemas are available in the YANG library module ietf-yang-library.yang as defined in [RFC8525]. The receiver is expected to know the YANG library information before starting a subscription.
要发出订阅请求，订阅服务器需要知道发布服务器使用的数据存储架构。这些模式可在[RFC8525]中定义的YANG库模块ietf-YANG-library.YANG中找到。在开始订阅之前，接收者应该知道YANG图书馆的信息。
The set of modules, revisions, features, and deviations can change at runtime (if supported by the publisher implementation). For this purpose, the YANG library provides a simple "yang-library-change" notification that informs the subscriber that the library has changed. In this case, a subscription may need to be updated to take the updates into account. The receiver may also need to be informed of module changes in order to process updates regarding datastore nodes from changed modules correctly.
模块集、修订版、功能和偏差可以在运行时更改（如果publisher实现支持）。为此，YANG library提供了一个简单的“YANG library change”通知，通知订阅者该库已更改。在这种情况下，可能需要更新订阅以考虑更新。为了正确处理来自已更改模块的关于数据存储节点的更新，还可能需要将模块更改通知接收器。
This YANG module imports typedefs from [RFC6991], identities from
[RFC8342], the "yang-data" extension from [RFC8040], and the
"yang-patch" grouping from [RFC8072]. In addition, it imports and
augments many definitions from [RFC8639]. It also references
[RFC6241], [XPATH] ("XML Path Language (XPath) Version 1.0"), and
[RFC7950].
This YANG module imports typedefs from [RFC6991], identities from
[RFC8342], the "yang-data" extension from [RFC8040], and the
"yang-patch" grouping from [RFC8072]. In addition, it imports and
augments many definitions from [RFC8639]. It also references
[RFC6241], [XPATH] ("XML Path Language (XPath) Version 1.0"), and
[RFC7950].
<CODE BEGINS> file "ietf-yang-push@2019-09-09.yang"
module ietf-yang-push {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-push";
prefix yp;
<CODE BEGINS> file "ietf-yang-push@2019-09-09.yang"
module ietf-yang-push {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-push";
prefix yp;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-subscribed-notifications {
prefix sn;
reference
"RFC 8639: Subscription to YANG Notifications";
}
import ietf-datastores {
prefix ds;
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
import ietf-restconf {
prefix rc;
reference
"RFC 8040: RESTCONF Protocol";
}
import ietf-yang-patch {
prefix ypatch;
reference
"RFC 8072: YANG Patch Media Type";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-subscribed-notifications {
prefix sn;
reference
"RFC 8639: Subscription to YANG Notifications";
}
import ietf-datastores {
prefix ds;
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
import ietf-restconf {
prefix rc;
reference
"RFC 8040: RESTCONF Protocol";
}
import ietf-yang-patch {
prefix ypatch;
reference
"RFC 8072: YANG Patch Media Type";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https:/datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https:/datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Alexander Clemm
作者：亚历山大·克莱姆
<mailto:ludwig@clemm.org>
<mailto:ludwig@clemm.org>
Author: Eric Voit
<mailto:evoit@cisco.com>";
Author: Eric Voit
<mailto:evoit@cisco.com>";
description "This module contains YANG specifications for YANG-Push.
description“此模块包含YANG Push的YANG规格。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可能”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14（RFC 2119）（RFC 8174）所述进行解释。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8641; see the RFC itself for full legal notices.";
该模块的此版本是RFC 8641的一部分；有关完整的法律通知，请参见RFC本身。“；
revision 2019-09-09 {
description
"Initial revision.";
reference
"RFC 8641: Subscriptions to YANG Datastores";
}
revision 2019-09-09 {
description
"Initial revision.";
reference
"RFC 8641: Subscriptions to YANG Datastores";
}
/*
* FEATURES
*/
/*
* FEATURES
*/
feature on-change {
description
"This feature indicates that on-change triggered subscriptions
are supported.";
}
feature on-change {
description
"This feature indicates that on-change triggered subscriptions
are supported.";
}
/*
* IDENTITIES
*/
/*
* IDENTITIES
*/
/* Error type identities for datastore subscription */
/* Error type identities for datastore subscription */
identity resync-subscription-error {
description
"Problem found while attempting to fulfill a
'resync-subscription' RPC request.";
}
identity resync-subscription-error {
description
"Problem found while attempting to fulfill a
'resync-subscription' RPC request.";
}
identity cant-exclude {
base sn:establish-subscription-error;
description
"Unable to remove the set of 'excluded-change' parameters.
This means that the publisher is unable to restrict
'push-change-update' notifications to just the change types
requested for this subscription.";
}
identity cant-exclude {
base sn:establish-subscription-error;
description
"Unable to remove the set of 'excluded-change' parameters.
This means that the publisher is unable to restrict
'push-change-update' notifications to just the change types
requested for this subscription.";
}
identity datastore-not-subscribable {
base sn:establish-subscription-error;
base sn:subscription-terminated-reason;
description
"This is not a subscribable datastore.";
}
identity datastore-not-subscribable {
base sn:establish-subscription-error;
base sn:subscription-terminated-reason;
description
"This is not a subscribable datastore.";
}
identity no-such-subscription-resync {
base resync-subscription-error;
description
"The referenced subscription doesn't exist. This may be as a
result of a nonexistent subscription ID, an ID that belongs to
another subscriber, or an ID for a configured subscription.";
}
identity no-such-subscription-resync {
base resync-subscription-error;
description
"The referenced subscription doesn't exist. This may be as a
result of a nonexistent subscription ID, an ID that belongs to
another subscriber, or an ID for a configured subscription.";
}
identity on-change-unsupported {
base sn:establish-subscription-error;
description
"On-change is not supported for any objects that are
selectable by this filter.";
}
identity on-change-unsupported {
base sn:establish-subscription-error;
description
"On-change is not supported for any objects that are
selectable by this filter.";
}
identity on-change-sync-unsupported {
base sn:establish-subscription-error;
description
"Neither 'sync-on-start' nor resynchronization is supported for
this subscription. This error will be used for two reasons:
(1) if an 'establish-subscription' RPC includes
'sync-on-start' but the publisher can't support sending a
'push-update' for this subscription for reasons other than
'on-change-unsupported' or 'sync-too-big'
identity on-change-sync-unsupported {
base sn:establish-subscription-error;
description
"Neither 'sync-on-start' nor resynchronization is supported for
this subscription. This error will be used for two reasons:
(1) if an 'establish-subscription' RPC includes
'sync-on-start' but the publisher can't support sending a
'push-update' for this subscription for reasons other than
'on-change-unsupported' or 'sync-too-big'
(2) if the 'resync-subscription' RPC is invoked for either an
existing periodic subscription or an on-change subscription
that can't support resynchronization.";
}
(2) if the 'resync-subscription' RPC is invoked for either an
existing periodic subscription or an on-change subscription
that can't support resynchronization.";
}
identity period-unsupported {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base sn:subscription-suspended-reason;
description
"The requested time period or 'dampening-period' is too short.
This can be for both periodic and on-change subscriptions
(with or without dampening). Hints suggesting alternative
periods may be returned as supplemental information.";
}
identity period-unsupported {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base sn:subscription-suspended-reason;
description
"The requested time period or 'dampening-period' is too short.
This can be for both periodic and on-change subscriptions
(with or without dampening). Hints suggesting alternative
periods may be returned as supplemental information.";
}
identity update-too-big {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base sn:subscription-suspended-reason;
description
"Periodic or on-change push update data trees exceed a maximum
size limit. Hints on the estimated size of what was too big
may be returned as supplemental information.";
}
identity update-too-big {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base sn:subscription-suspended-reason;
description
"Periodic or on-change push update data trees exceed a maximum
size limit. Hints on the estimated size of what was too big
may be returned as supplemental information.";
}
identity sync-too-big {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base resync-subscription-error;
base sn:subscription-suspended-reason;
description
"The 'sync-on-start' or resynchronization data tree exceeds a
maximum size limit. Hints on the estimated size of what was
too big may be returned as supplemental information.";
}
identity sync-too-big {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base resync-subscription-error;
base sn:subscription-suspended-reason;
description
"The 'sync-on-start' or resynchronization data tree exceeds a
maximum size limit. Hints on the estimated size of what was
too big may be returned as supplemental information.";
}
identity unchanging-selection {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base sn:subscription-terminated-reason;
description
"The selection filter is unlikely to ever select data tree
nodes. This means that based on the subscriber's current
access rights, the publisher recognizes that the selection
filter is unlikely to ever select data tree nodes that change.
Examples for this might be that the node or subtree doesn't
exist, read access is not permitted for a receiver, or static
identity unchanging-selection {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
base sn:subscription-terminated-reason;
description
"The selection filter is unlikely to ever select data tree
nodes. This means that based on the subscriber's current
access rights, the publisher recognizes that the selection
filter is unlikely to ever select data tree nodes that change.
Examples for this might be that the node or subtree doesn't
exist, read access is not permitted for a receiver, or static
objects that only change at reboot have been chosen.";
}
objects that only change at reboot have been chosen.";
}
/*
* TYPE DEFINITIONS
*/
/*
* TYPE DEFINITIONS
*/
typedef change-type {
type enumeration {
enum create {
description
"A change that refers to the creation of a new
datastore node.";
}
enum delete {
description
"A change that refers to the deletion of a
datastore node.";
}
enum insert {
description
"A change that refers to the insertion of a new
user-ordered datastore node.";
}
enum move {
description
"A change that refers to a reordering of the target
datastore node.";
}
enum replace {
description
"A change that refers to a replacement of the target
datastore node's value.";
}
}
description
"Specifies different types of datastore changes.
typedef change-type {
type enumeration {
enum create {
description
"A change that refers to the creation of a new
datastore node.";
}
enum delete {
description
"A change that refers to the deletion of a
datastore node.";
}
enum insert {
description
"A change that refers to the insertion of a new
user-ordered datastore node.";
}
enum move {
description
"A change that refers to a reordering of the target
datastore node.";
}
enum replace {
description
"A change that refers to a replacement of the target
datastore node's value.";
}
}
description
"Specifies different types of datastore changes.
This type is based on the edit operations defined for
YANG Patch, with the difference that it is valid for a
receiver to process an update record that performs a
'create' operation on a datastore node the receiver believes
exists or to process a delete on a datastore node the
receiver believes is missing.";
reference
"RFC 8072: YANG Patch Media Type, Section 2.5";
}
This type is based on the edit operations defined for
YANG Patch, with the difference that it is valid for a
receiver to process an update record that performs a
'create' operation on a datastore node the receiver believes
exists or to process a delete on a datastore node the
receiver believes is missing.";
reference
"RFC 8072: YANG Patch Media Type, Section 2.5";
}
typedef selection-filter-ref {
type leafref {
path "/sn:filters/yp:selection-filter/yp:filter-id";
}
description
"This type is used to reference a selection filter.";
}
typedef selection-filter-ref {
type leafref {
path "/sn:filters/yp:selection-filter/yp:filter-id";
}
description
"This type is used to reference a selection filter.";
}
typedef centiseconds {
type uint32;
description
"A period of time, measured in units of 0.01 seconds.";
}
typedef centiseconds {
type uint32;
description
"A period of time, measured in units of 0.01 seconds.";
}
/*
* GROUP DEFINITIONS
*/
/*
* GROUP DEFINITIONS
*/
grouping datastore-criteria {
description
"A grouping to define criteria for which selected objects from
a targeted datastore should be included in push updates.";
leaf datastore {
type identityref {
base ds:datastore;
}
mandatory true;
description
"Datastore from which to retrieve data.";
}
uses selection-filter-objects;
}
grouping datastore-criteria {
description
"A grouping to define criteria for which selected objects from
a targeted datastore should be included in push updates.";
leaf datastore {
type identityref {
base ds:datastore;
}
mandatory true;
description
"Datastore from which to retrieve data.";
}
uses selection-filter-objects;
}
grouping selection-filter-types {
description
"This grouping defines the types of selectors for objects
from a datastore.";
choice filter-spec {
description
"The content filter specification for this request.";
anydata datastore-subtree-filter {
if-feature "sn:subtree";
description
"This parameter identifies the portions of the
target datastore to retrieve.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 6";
grouping selection-filter-types {
description
"This grouping defines the types of selectors for objects
from a datastore.";
choice filter-spec {
description
"The content filter specification for this request.";
anydata datastore-subtree-filter {
if-feature "sn:subtree";
description
"This parameter identifies the portions of the
target datastore to retrieve.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 6";
}
leaf datastore-xpath-filter {
if-feature "sn:xpath";
type yang:xpath1.0;
description
"This parameter contains an XPath expression identifying
the portions of the target datastore to retrieve.
}
leaf datastore-xpath-filter {
if-feature "sn:xpath";
type yang:xpath1.0;
description
"This parameter contains an XPath expression identifying
the portions of the target datastore to retrieve.
If the expression returns a node set, all nodes in the node set are selected by the filter. Otherwise, if the expression does not return a node set, the filter doesn't select any nodes.
如果表达式返回节点集，则过滤器将选择节点集中的所有节点。否则，如果表达式不返回节点集，则过滤器不会选择任何节点。
The expression is evaluated in the following XPath context:
表达式在以下XPath上下文中求值：
o The set of namespace declarations is the set of prefix and namespace pairs for all YANG modules implemented by the server, where the prefix is the YANG module name and the namespace is as defined by the 'namespace' statement in the YANG module.
o 命名空间声明集是服务器实现的所有YANG模块的前缀和命名空间对集，其中前缀是YANG模块名称，命名空间由YANG模块中的“namespace”语句定义。
If the leaf is encoded in XML, all namespace declarations in scope on the 'stream-xpath-filter' leaf element are added to the set of namespace declarations. If a prefix found in the XML is already present in the set of namespace declarations, the namespace in the XML is used.
如果叶用XML编码，“stream xpath filter”叶元素上作用域中的所有命名空间声明都将添加到命名空间声明集中。如果在XML中找到的前缀已存在于名称空间声明集中，则使用XML中的名称空间。
o The set of variable bindings is empty.
o 变量绑定集为空。
o The function library is comprised of the core function library and the XPath functions defined in Section 10 in RFC 7950.
o 函数库由核心函数库和RFC 7950第10节中定义的XPath函数组成。
o The context node is the root node of the target
datastore.";
reference
"XML Path Language (XPath) Version 1.0
(https://www.w3.org/TR/1999/REC-xpath-19991116)
RFC 7950: The YANG 1.1 Data Modeling Language,
Section 10";
}
}
}
o The context node is the root node of the target
datastore.";
reference
"XML Path Language (XPath) Version 1.0
(https://www.w3.org/TR/1999/REC-xpath-19991116)
RFC 7950: The YANG 1.1 Data Modeling Language,
Section 10";
}
}
}
grouping selection-filter-objects { description
分组选择筛选器对象{说明
"This grouping defines a selector for objects from a
datastore.";
choice selection-filter {
description
"The source of the selection filter applied to the
subscription. This will either (1) come referenced from a
global list or (2) be provided in the subscription itself.";
case by-reference {
description
"Incorporates a filter that has been configured
separately.";
leaf selection-filter-ref {
type selection-filter-ref;
mandatory true;
description
"References an existing selection filter that is to be
applied to the subscription.";
}
}
case within-subscription {
description
"A local definition allows a filter to have the same
lifecycle as the subscription.";
uses selection-filter-types;
}
}
}
"This grouping defines a selector for objects from a
datastore.";
choice selection-filter {
description
"The source of the selection filter applied to the
subscription. This will either (1) come referenced from a
global list or (2) be provided in the subscription itself.";
case by-reference {
description
"Incorporates a filter that has been configured
separately.";
leaf selection-filter-ref {
type selection-filter-ref;
mandatory true;
description
"References an existing selection filter that is to be
applied to the subscription.";
}
}
case within-subscription {
description
"A local definition allows a filter to have the same
lifecycle as the subscription.";
uses selection-filter-types;
}
}
}
grouping update-policy-modifiable {
description
"This grouping describes the datastore-specific subscription
conditions that can be changed during the lifetime of the
subscription.";
choice update-trigger {
description
"Defines necessary conditions for sending an event record to
the subscriber.";
case periodic {
container periodic {
presence "indicates a periodic subscription";
description
"The publisher is requested to periodically notify the
receiver regarding the current values of the datastore
as defined by the selection filter.";
leaf period {
type centiseconds;
mandatory true;
description
grouping update-policy-modifiable {
description
"This grouping describes the datastore-specific subscription
conditions that can be changed during the lifetime of the
subscription.";
choice update-trigger {
description
"Defines necessary conditions for sending an event record to
the subscriber.";
case periodic {
container periodic {
presence "indicates a periodic subscription";
description
"The publisher is requested to periodically notify the
receiver regarding the current values of the datastore
as defined by the selection filter.";
leaf period {
type centiseconds;
mandatory true;
description
"Duration of time that should occur between periodic
push updates, in units of 0.01 seconds.";
}
leaf anchor-time {
type yang:date-and-time;
description
"Designates a timestamp before or after which a series
of periodic push updates are determined. The next
update will take place at a point in time that is a
multiple of a period from the 'anchor-time'.
For example, for an 'anchor-time' that is set for the
top of a particular minute and a period interval of a
minute, updates will be sent at the top of every
minute that this subscription is active.";
}
}
}
case on-change {
if-feature "on-change";
container on-change {
presence "indicates an on-change subscription";
description
"The publisher is requested to notify the receiver
regarding changes in values in the datastore subset as
defined by a selection filter.";
leaf dampening-period {
type centiseconds;
default "0";
description
"Specifies the minimum interval between the assembly of
successive update records for a single receiver of a
subscription. Whenever subscribed objects change and
a dampening-period interval (which may be zero) has
elapsed since the previous update record creation for
a receiver, any subscribed objects and properties
that have changed since the previous update record
will have their current values marshalled and placed
in a new update record.";
}
}
}
}
}
"Duration of time that should occur between periodic
push updates, in units of 0.01 seconds.";
}
leaf anchor-time {
type yang:date-and-time;
description
"Designates a timestamp before or after which a series
of periodic push updates are determined. The next
update will take place at a point in time that is a
multiple of a period from the 'anchor-time'.
For example, for an 'anchor-time' that is set for the
top of a particular minute and a period interval of a
minute, updates will be sent at the top of every
minute that this subscription is active.";
}
}
}
case on-change {
if-feature "on-change";
container on-change {
presence "indicates an on-change subscription";
description
"The publisher is requested to notify the receiver
regarding changes in values in the datastore subset as
defined by a selection filter.";
leaf dampening-period {
type centiseconds;
default "0";
description
"Specifies the minimum interval between the assembly of
successive update records for a single receiver of a
subscription. Whenever subscribed objects change and
a dampening-period interval (which may be zero) has
elapsed since the previous update record creation for
a receiver, any subscribed objects and properties
that have changed since the previous update record
will have their current values marshalled and placed
in a new update record.";
}
}
}
}
}
grouping update-policy {
description
"This grouping describes the datastore-specific subscription
conditions of a subscription.";
grouping update-policy {
description
"This grouping describes the datastore-specific subscription
conditions of a subscription.";
uses update-policy-modifiable {
augment "update-trigger/on-change/on-change" {
description
"Includes objects that are not modifiable once a
subscription is established.";
leaf sync-on-start {
type boolean;
default "true";
description
"When this object is set to 'false', (1) it restricts an
on-change subscription from sending 'push-update'
notifications and (2) pushing a full selection per the
terms of the selection filter MUST NOT be done for
this subscription. Only updates about changes
(i.e., only 'push-change-update' notifications)
are sent. When set to 'true' (the default behavior),
in order to facilitate a receiver's synchronization,
a full update is sent, via a 'push-update' notification,
when the subscription starts. After that,
'push-change-update' notifications are exclusively sent,
unless the publisher chooses to resync the subscription
via a new 'push-update' notification.";
}
leaf-list excluded-change {
type change-type;
description
"Used to restrict which changes trigger an update. For
example, if a 'replace' operation is excluded, only the
creation and deletion of objects are reported.";
}
}
}
}
uses update-policy-modifiable {
augment "update-trigger/on-change/on-change" {
description
"Includes objects that are not modifiable once a
subscription is established.";
leaf sync-on-start {
type boolean;
default "true";
description
"When this object is set to 'false', (1) it restricts an
on-change subscription from sending 'push-update'
notifications and (2) pushing a full selection per the
terms of the selection filter MUST NOT be done for
this subscription. Only updates about changes
(i.e., only 'push-change-update' notifications)
are sent. When set to 'true' (the default behavior),
in order to facilitate a receiver's synchronization,
a full update is sent, via a 'push-update' notification,
when the subscription starts. After that,
'push-change-update' notifications are exclusively sent,
unless the publisher chooses to resync the subscription
via a new 'push-update' notification.";
}
leaf-list excluded-change {
type change-type;
description
"Used to restrict which changes trigger an update. For
example, if a 'replace' operation is excluded, only the
creation and deletion of objects are reported.";
}
}
}
}
grouping hints {
description
"Parameters associated with an error for a subscription
made upon a datastore.";
leaf period-hint {
type centiseconds;
description
"Returned when the requested time period is too short. This
hint can assert a viable period for either a periodic push
cadence or an on-change dampening interval.";
}
leaf filter-failure-hint {
type string;
description
grouping hints {
description
"Parameters associated with an error for a subscription
made upon a datastore.";
leaf period-hint {
type centiseconds;
description
"Returned when the requested time period is too short. This
hint can assert a viable period for either a periodic push
cadence or an on-change dampening interval.";
}
leaf filter-failure-hint {
type string;
description
"Information describing where and/or why a provided filter
was unsupportable for a subscription.";
}
leaf object-count-estimate {
type uint32;
description
"If there are too many objects that could potentially be
returned by the selection filter, this identifies the
estimate of the number of objects that the filter would
potentially pass.";
}
leaf object-count-limit {
type uint32;
description
"If there are too many objects that could be returned by
the selection filter, this identifies the upper limit of
the publisher's ability to service this subscription.";
}
leaf kilobytes-estimate {
type uint32;
description
"If the returned information could be beyond the capacity
of the publisher, this would identify the estimated
data size that could result from this selection filter.";
}
leaf kilobytes-limit {
type uint32;
description
"If the returned information would be beyond the capacity
of the publisher, this identifies the upper limit of the
publisher's ability to service this subscription.";
}
}
"Information describing where and/or why a provided filter
was unsupportable for a subscription.";
}
leaf object-count-estimate {
type uint32;
description
"If there are too many objects that could potentially be
returned by the selection filter, this identifies the
estimate of the number of objects that the filter would
potentially pass.";
}
leaf object-count-limit {
type uint32;
description
"If there are too many objects that could be returned by
the selection filter, this identifies the upper limit of
the publisher's ability to service this subscription.";
}
leaf kilobytes-estimate {
type uint32;
description
"If the returned information could be beyond the capacity
of the publisher, this would identify the estimated
data size that could result from this selection filter.";
}
leaf kilobytes-limit {
type uint32;
description
"If the returned information would be beyond the capacity
of the publisher, this identifies the upper limit of the
publisher's ability to service this subscription.";
}
}
/*
* RPCs
*/
/*
* RPCs
*/
rpc resync-subscription {
if-feature "on-change";
description
"This RPC allows a subscriber of an active on-change
subscription to request a full push of objects.
rpc resync-subscription {
if-feature "on-change";
description
"This RPC allows a subscriber of an active on-change
subscription to request a full push of objects.
A successful invocation results in a 'push-update' of all datastore nodes that the subscriber is permitted to access. This RPC can only be invoked on the same session on which the subscription is currently active. In the case of an error, a
成功的调用将导致允许订阅者访问的所有数据存储节点的“推送更新”。此RPC只能在订阅当前处于活动状态的同一会话上调用。在发生错误的情况下
'resync-subscription-error' is sent as part of an error
response.";
input {
leaf id {
type sn:subscription-id;
mandatory true;
description
"Identifier of the subscription that is to be resynced.";
}
}
}
'resync-subscription-error' is sent as part of an error
response.";
input {
leaf id {
type sn:subscription-id;
mandatory true;
description
"Identifier of the subscription that is to be resynced.";
}
}
}
rc:yang-data resync-subscription-error {
container resync-subscription-error {
description
"If a 'resync-subscription' RPC fails, the subscription is
not resynced and the RPC error response MUST indicate the
reason for this failure. This yang-data MAY be inserted as
structured data in a subscription's RPC error response
to indicate the reason for the failure.";
leaf reason {
type identityref {
base resync-subscription-error;
}
mandatory true;
description
"Indicates the reason why the publisher has declined a
request for subscription resynchronization.";
}
uses hints;
}
}
rc:yang-data resync-subscription-error {
container resync-subscription-error {
description
"If a 'resync-subscription' RPC fails, the subscription is
not resynced and the RPC error response MUST indicate the
reason for this failure. This yang-data MAY be inserted as
structured data in a subscription's RPC error response
to indicate the reason for the failure.";
leaf reason {
type identityref {
base resync-subscription-error;
}
mandatory true;
description
"Indicates the reason why the publisher has declined a
request for subscription resynchronization.";
}
uses hints;
}
}
augment "/sn:establish-subscription/sn:input" {
description
"This augmentation adds additional subscription parameters
that apply specifically to datastore updates to RPC input.";
uses update-policy;
}
augment "/sn:establish-subscription/sn:input" {
description
"This augmentation adds additional subscription parameters
that apply specifically to datastore updates to RPC input.";
uses update-policy;
}
augment "/sn:establish-subscription/sn:input/sn:target" {
description
"This augmentation adds the datastore as a valid target
for the subscription to RPC input.";
case datastore {
description
"Information specifying the parameters of a request for a
datastore subscription.";
augment "/sn:establish-subscription/sn:input/sn:target" {
description
"This augmentation adds the datastore as a valid target
for the subscription to RPC input.";
case datastore {
description
"Information specifying the parameters of a request for a
datastore subscription.";
uses datastore-criteria;
}
}
uses datastore-criteria;
}
}
rc:yang-data establish-subscription-datastore-error-info {
container establish-subscription-datastore-error-info {
description
"If any 'establish-subscription' RPC parameters are
unsupportable against the datastore, a subscription is not
created and the RPC error response MUST indicate the reason
why the subscription failed to be created. This yang-data
MAY be inserted as structured data in a subscription's
RPC error response to indicate the reason for the failure.
This yang-data MUST be inserted if hints are to be provided
back to the subscriber.";
leaf reason {
type identityref {
base sn:establish-subscription-error;
}
description
"Indicates the reason why the subscription has failed to
be created to a targeted datastore.";
}
uses hints;
}
}
rc:yang-data establish-subscription-datastore-error-info {
container establish-subscription-datastore-error-info {
description
"If any 'establish-subscription' RPC parameters are
unsupportable against the datastore, a subscription is not
created and the RPC error response MUST indicate the reason
why the subscription failed to be created. This yang-data
MAY be inserted as structured data in a subscription's
RPC error response to indicate the reason for the failure.
This yang-data MUST be inserted if hints are to be provided
back to the subscriber.";
leaf reason {
type identityref {
base sn:establish-subscription-error;
}
description
"Indicates the reason why the subscription has failed to
be created to a targeted datastore.";
}
uses hints;
}
}
augment "/sn:modify-subscription/sn:input" {
description
"This augmentation adds additional subscription parameters
specific to datastore updates.";
uses update-policy-modifiable;
}
augment "/sn:modify-subscription/sn:input" {
description
"This augmentation adds additional subscription parameters
specific to datastore updates.";
uses update-policy-modifiable;
}
augment "/sn:modify-subscription/sn:input/sn:target" {
description
"This augmentation adds the datastore as a valid target
for the subscription to RPC input.";
case datastore {
description
"Information specifying the parameters of a request for a
datastore subscription.";
uses datastore-criteria;
}
}
augment "/sn:modify-subscription/sn:input/sn:target" {
description
"This augmentation adds the datastore as a valid target
for the subscription to RPC input.";
case datastore {
description
"Information specifying the parameters of a request for a
datastore subscription.";
uses datastore-criteria;
}
}
rc:yang-data modify-subscription-datastore-error-info {
container modify-subscription-datastore-error-info {
rc:yang-data modify-subscription-datastore-error-info {
container modify-subscription-datastore-error-info {
description
"This yang-data MAY be provided as part of a subscription's
RPC error response when there is a failure of a
'modify-subscription' RPC that has been made against a
datastore. This yang-data MUST be used if hints are to be
provided back to the subscriber.";
leaf reason {
type identityref {
base sn:modify-subscription-error;
}
description
"Indicates the reason why the subscription has failed to
be modified.";
}
uses hints;
}
}
description
"This yang-data MAY be provided as part of a subscription's
RPC error response when there is a failure of a
'modify-subscription' RPC that has been made against a
datastore. This yang-data MUST be used if hints are to be
provided back to the subscriber.";
leaf reason {
type identityref {
base sn:modify-subscription-error;
}
description
"Indicates the reason why the subscription has failed to
be modified.";
}
uses hints;
}
}
/*
* NOTIFICATIONS
*/
/*
* NOTIFICATIONS
*/
notification push-update {
description
"This notification contains a push update that in turn contains
data subscribed to via a subscription. In the case of a
periodic subscription, this notification is sent for periodic
updates. It can also be used for synchronization updates of
an on-change subscription. This notification shall only be
sent to receivers of a subscription. It does not constitute
a general-purpose notification that would be subscribable as
part of the NETCONF event stream by any receiver.";
leaf id {
type sn:subscription-id;
description
"This references the subscription that drove the
notification to be sent.";
}
anydata datastore-contents {
description
"This contains the updated data. It constitutes a snapshot
at the time of update of the set of data that has been
subscribed to. The snapshot corresponds to the same
snapshot that would be returned in a corresponding 'get'
operation with the same selection filter parameters
applied.";
}
leaf incomplete-update {
notification push-update {
description
"This notification contains a push update that in turn contains
data subscribed to via a subscription. In the case of a
periodic subscription, this notification is sent for periodic
updates. It can also be used for synchronization updates of
an on-change subscription. This notification shall only be
sent to receivers of a subscription. It does not constitute
a general-purpose notification that would be subscribable as
part of the NETCONF event stream by any receiver.";
leaf id {
type sn:subscription-id;
description
"This references the subscription that drove the
notification to be sent.";
}
anydata datastore-contents {
description
"This contains the updated data. It constitutes a snapshot
at the time of update of the set of data that has been
subscribed to. The snapshot corresponds to the same
snapshot that would be returned in a corresponding 'get'
operation with the same selection filter parameters
applied.";
}
leaf incomplete-update {
type empty;
description
"This is a flag that indicates that not all datastore
nodes subscribed to are included with this update. In
other words, the publisher has failed to fulfill its full
subscription obligations and, despite its best efforts, is
providing an incomplete set of objects.";
}
}
type empty;
description
"This is a flag that indicates that not all datastore
nodes subscribed to are included with this update. In
other words, the publisher has failed to fulfill its full
subscription obligations and, despite its best efforts, is
providing an incomplete set of objects.";
}
}
notification push-change-update {
if-feature "on-change";
description
"This notification contains an on-change push update. This
notification shall only be sent to the receivers of a
subscription. It does not constitute a general-purpose
notification that would be subscribable as part of the
NETCONF event stream by any receiver.";
leaf id {
type sn:subscription-id;
description
"This references the subscription that drove the
notification to be sent.";
}
container datastore-changes {
description
"This contains the set of datastore changes of the target
datastore, starting at the time of the previous update, per
the terms of the subscription.";
uses ypatch:yang-patch;
}
leaf incomplete-update {
type empty;
description
"The presence of this object indicates that not all changes
that have occurred since the last update are included with
this update. In other words, the publisher has failed to
fulfill its full subscription obligations -- for example,
in cases where it was not able to keep up with a burst of
changes.";
}
}
notification push-change-update {
if-feature "on-change";
description
"This notification contains an on-change push update. This
notification shall only be sent to the receivers of a
subscription. It does not constitute a general-purpose
notification that would be subscribable as part of the
NETCONF event stream by any receiver.";
leaf id {
type sn:subscription-id;
description
"This references the subscription that drove the
notification to be sent.";
}
container datastore-changes {
description
"This contains the set of datastore changes of the target
datastore, starting at the time of the previous update, per
the terms of the subscription.";
uses ypatch:yang-patch;
}
leaf incomplete-update {
type empty;
description
"The presence of this object indicates that not all changes
that have occurred since the last update are included with
this update. In other words, the publisher has failed to
fulfill its full subscription obligations -- for example,
in cases where it was not able to keep up with a burst of
changes.";
}
}
augment "/sn:subscription-started" {
description
"This augmentation adds datastore-specific objects to
the notification that a subscription has started.";
uses update-policy;
augment "/sn:subscription-started" {
description
"This augmentation adds datastore-specific objects to
the notification that a subscription has started.";
uses update-policy;
}
}
augment "/sn:subscription-started/sn:target" {
description
"This augmentation allows the datastore to be included as
part of the notification that a subscription has started.";
case datastore {
uses datastore-criteria {
refine "selection-filter/within-subscription" {
description
"Specifies the selection filter and where it originated
from. If the 'selection-filter-ref' is populated, the
filter in the subscription came from the 'filters'
container. Otherwise, it is populated in-line as part
of the subscription itself.";
}
}
}
}
augment "/sn:subscription-started/sn:target" {
description
"This augmentation allows the datastore to be included as
part of the notification that a subscription has started.";
case datastore {
uses datastore-criteria {
refine "selection-filter/within-subscription" {
description
"Specifies the selection filter and where it originated
from. If the 'selection-filter-ref' is populated, the
filter in the subscription came from the 'filters'
container. Otherwise, it is populated in-line as part
of the subscription itself.";
}
}
}
}
augment "/sn:subscription-modified" {
description
"This augmentation adds datastore-specific objects to
the notification that a subscription has been modified.";
uses update-policy;
}
augment "/sn:subscription-modified" {
description
"This augmentation adds datastore-specific objects to
the notification that a subscription has been modified.";
uses update-policy;
}
augment "/sn:subscription-modified/sn:target" {
description
"This augmentation allows the datastore to be included as
part of the notification that a subscription has been
modified.";
case datastore {
uses datastore-criteria {
refine "selection-filter/within-subscription" {
description
"Specifies the selection filter and where it originated
from. If the 'selection-filter-ref' is populated, the
filter in the subscription came from the 'filters'
container. Otherwise, it is populated in-line as part
of the subscription itself.";
}
}
}
}
augment "/sn:subscription-modified/sn:target" {
description
"This augmentation allows the datastore to be included as
part of the notification that a subscription has been
modified.";
case datastore {
uses datastore-criteria {
refine "selection-filter/within-subscription" {
description
"Specifies the selection filter and where it originated
from. If the 'selection-filter-ref' is populated, the
filter in the subscription came from the 'filters'
container. Otherwise, it is populated in-line as part
of the subscription itself.";
}
}
}
}
/*
* DATA NODES
/*
* DATA NODES
*/
*/
augment "/sn:filters" {
description
"This augmentation allows the datastore to be included as part
of the selection-filtering criteria for a subscription.";
list selection-filter {
key "filter-id";
description
"A list of preconfigured filters that can be applied
to datastore subscriptions.";
leaf filter-id {
type string;
description
"An identifier to differentiate between selection
filters.";
}
uses selection-filter-types;
}
}
augment "/sn:filters" {
description
"This augmentation allows the datastore to be included as part
of the selection-filtering criteria for a subscription.";
list selection-filter {
key "filter-id";
description
"A list of preconfigured filters that can be applied
to datastore subscriptions.";
leaf filter-id {
type string;
description
"An identifier to differentiate between selection
filters.";
}
uses selection-filter-types;
}
}
augment "/sn:subscriptions/sn:subscription" {
when 'yp:datastore';
description
"This augmentation adds objects to a subscription that are
specific to a datastore subscription, i.e., a subscription to
a stream of datastore node updates.";
uses update-policy;
}
augment "/sn:subscriptions/sn:subscription" {
when 'yp:datastore';
description
"This augmentation adds objects to a subscription that are
specific to a datastore subscription, i.e., a subscription to
a stream of datastore node updates.";
uses update-policy;
}
augment "/sn:subscriptions/sn:subscription/sn:target" {
description
"This augmentation allows the datastore to be included as
part of the selection-filtering criteria for a subscription.";
case datastore {
uses datastore-criteria;
}
}
}
augment "/sn:subscriptions/sn:subscription/sn:target" {
description
"This augmentation allows the datastore to be included as
part of the selection-filtering criteria for a subscription.";
case datastore {
uses datastore-criteria;
}
}
}
<CODE ENDS>
<代码结束>
This document registers the following namespace URI in the "IETF XML Registry" [RFC3688]:
本文档在“IETF XML注册表”[RFC3688]中注册以下命名空间URI：
URI: urn:ietf:params:xml:ns:yang:ietf-yang-push
URI: urn:ietf:params:xml:ns:yang:ietf-yang-push
Registrant Contact: The IESG.
注册人联系人：IESG。
XML: N/A; the requested URI is an XML namespace.
XML：不适用；请求的URI是一个XML命名空间。
This document registers the following YANG module in the "YANG Module Names" registry [RFC6020]:
本文件在“YANG模块名称”注册表[RFC6020]中注册以下YANG模块：
Name: ietf-yang-push
姓名：ietf yang push
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-push
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-push
Prefix: yp
前缀：yp
Reference: RFC 8641
参考：RFC 8641
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
本文档中指定的模块为数据定义了一个模式，该模式旨在通过网络管理协议（如NETCONF[RFC6241]或restcconf[RFC8040]）进行访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全Shell（SSH）[RFC6242]。最低的RESTCONF层是HTTPS，实现安全传输的强制层是TLS[RFC8446]。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
网络配置访问控制模型（NACM）[RFC8341]提供了将特定NETCONF或RESTCONF用户的访问限制为所有可用NETCONF或RESTCONF协议操作和内容的预配置子集的方法。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability. (It should be noted that the YANG module defined in this document augments the YANG module defined in [RFC8639]. All security considerations that are listed in
此模块中定义了许多可写/可创建/可删除的数据节点（即，默认为config true）。在某些网络环境中，这些数据节点可能被视为敏感或易受攻击。对这些数据节点的写入操作（如编辑配置）如果没有适当的保护，可能会对网络操作产生负面影响。这些是子树和数据节点及其敏感性/漏洞。（需要注意的是，本文档中定义的YANG模块扩展了[RFC8639]中定义的YANG模块）。中列出的所有安全注意事项
[RFC8639] are also relevant for datastore subscriptions. In the following list, we focus on the new data nodes that are introduced in this document.)
[RFC8639]也与数据存储订阅相关。在下面的列表中，我们将重点介绍本文档中介绍的新数据节点。）
o Subtree "selection-filter" under container "filters": This subtree allows a subscriber to specify which objects or subtrees to include in a datastore subscription. An attacker could attempt to modify the filter. For example, the filter might be modified to result in very few objects being filtered in order to attempt to overwhelm the receiver. Alternatively, the filter might be modified to result in certain objects being excluded from updates, in which case certain changes would go unnoticed.
o 容器“过滤器”下的子树“选择过滤器”：此子树允许订阅者指定要包含在数据存储订阅中的对象或子树。攻击者可能试图修改筛选器。例如，可能会修改过滤器，以导致过滤的对象很少，从而试图压倒接收器。或者，过滤器可能会被修改，导致某些对象被排除在更新之外，在这种情况下，某些更改将不会被注意到。
o Subtree "datastore" in choice "target" in list "subscription": Analogous to "selection filter", an attacker might attempt to modify the objects being filtered in order to overwhelm a receiver with a larger volume of object updates than expected or cause certain changes to go unnoticed.
o 列表“订阅”中选择“目标”中的子树“数据存储”：与“选择过滤器”类似，攻击者可能试图修改正在过滤的对象，以便用比预期更大的对象更新量压倒接收者，或导致某些更改不被注意。
o Choice "update-trigger" in list "subscription": By modifying the update trigger, an attacker might alter the updates that are being sent in order to confuse a receiver, withhold certain updates to be sent to the receiver, and/or overwhelm a receiver. For example, an attacker might modify the period with which updates are reported for a periodic subscription, or it might modify the dampening period for an on-change subscription, resulting in a greater delay for successive updates (potentially affecting the responsiveness of applications that depend on the updates) or in a high volume of updates (to exhaust receiver resources).
o 在“订阅”列表中选择“更新触发器”：通过修改更新触发器，攻击者可能会更改正在发送的更新，以混淆接收者，阻止向接收者发送某些更新，和/或压倒接收者。例如，攻击者可能会修改定期订阅的更新报告周期，或者可能会修改更改订阅的缓冲周期，从而导致后续更新的延迟更大（可能会影响依赖于更新的应用程序的响应）或者在大量更新中（耗尽接收器资源）。
The NACM provides one means to mitigate these threats on the publisher side. In order to address those threats as a subscriber, the subscriber could monitor the subscription configuration for any unexpected changes and subscribe to updates to the YANG datastore nodes that represent its datastore subscriptions. As this volume of data is small, a paranoid subscriber could even revert to occasional polling to guard against a compromised subscription against subscription configuration updates itself.
NACM提供了一种在发布服务器端缓解这些威胁的方法。为了作为订阅者解决这些威胁，订阅者可以监视订阅配置中的任何意外更改，并订阅代表其数据存储订阅的数据存储节点的更新。由于数据量很小，偏执的订阅者甚至可以恢复偶尔的轮询，以防止订阅配置更新本身导致订阅受损。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
在某些网络环境中，此模块中的某些可读数据节点可能被视为敏感或易受攻击。因此，控制对这些数据节点的读取访问（例如，通过get、get config或通知）非常重要。这些是子树和数据节点及其敏感性/漏洞：
o Subtree "selection-filter" under container "filters": If access control is not properly configured, can expose system internals to those who should not have access to this information.
o 容器“过滤器”下的子树“选择过滤器”：如果未正确配置访问控制，可能会将系统内部构件暴露给那些不应该访问此信息的人。
o Subtree "datastore" in choice "target" in list "subscription": If access control is not properly configured, can expose system internals to those who should not have access to this information.
o 列表“订阅”中选择“目标”的子树“数据存储”：如果未正确配置访问控制，则可能会将系统内部内容暴露给那些不应该访问此信息的人。
o Choice "update-trigger" in list "subscription": If access control is not properly configured, can expose system internals to those who should not have access to this information.
o 在“订阅”列表中选择“更新触发器”：如果访问控制配置不正确，可能会将系统内部构件暴露给那些不应该访问此信息的人。
Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:
在某些网络环境中，此模块中的某些RPC操作可能被视为敏感或易受攻击。因此，控制对这些操作的访问非常重要。这些是操作及其敏感性/脆弱性：
o RPC "resync-subscription": This RPC allows a subscriber of an on-change subscription to request a full push of objects in the subscription's scope. This can result in a large volume of data. An attacker could attempt to use this RPC to exhaust resources on the server to generate the data and could then attempt to overwhelm a receiver with the resulting large volume of data.
o RPC“重新同步订阅”：此RPC允许更改订阅的订阅方请求订阅范围内对象的完全推送。这可能会导致大量数据。攻击者可能会尝试使用此RPC耗尽服务器上的资源以生成数据，然后可能会尝试用生成的大量数据压倒接收器。
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年7月<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch Media Type", RFC 8072, DOI 10.17487/RFC8072, February 2017, <https://www.rfc-editor.org/info/rfc8072>.
[RFC8072]Bierman，A.，Bjorklund，M.，和K.Watsen，“YANG Patch Media Type”，RFC 8072，DOI 10.17487/RFC8072，2017年2月<https://www.rfc-editor.org/info/rfc8072>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341]Bierman，A.和M.Bjorklund，“网络配置访问控制模型”，STD 91，RFC 8341，DOI 10.17487/RFC8341，2018年3月<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342]Bjorklund，M.，Schoenwaeld，J.，Shafer，P.，Watsen，K.，和R.Wilton，“网络管理数据存储体系结构（NMDA）”，RFC 8342，DOI 10.17487/RFC8342，2018年3月<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.
[RFC8525]Bierman，A.，Bjorklund，M.，Schoenwaeld，J.，Watsen，K.，和R.Wilton，“杨图书馆”，RFC 8525，DOI 10.17487/RFC85252019年3月<https://www.rfc-editor.org/info/rfc8525>.
[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，“YANG通知订阅”，RFC 8639，DOI 10.17487/RFC8639，2019年9月<https://www.rfc-editor.org/info/rfc8639>.
[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，“可扩展标记语言（xml）1.0（第五版）”，万维网联盟建议REC-xml-20081126，2008年11月<https://www.w3.org/TR/2008/REC-xml-20081126>.
[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路径语言（XPATH）1.0版”，1999年11月<https://www.w3.org/TR/1999/REC-xpath-19991116>.
[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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<https://www.rfc-editor.org/info/rfc6242>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, <https://www.rfc-editor.org/info/rfc7923>.
[RFC7923]Voit，E.，Clemm，A.和A.Gonzalez Prieto，“YANG数据存储订阅要求”，RFC 7923，DOI 10.17487/RFC79232016年6月<https://www.rfc-editor.org/info/rfc7923>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340]Bjorklund，M.和L.Berger，编辑，“杨树图”，BCP 215，RFC 8340，DOI 10.17487/RFC8340，2018年3月<https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343]Bjorklund，M.，“用于接口管理的YANG数据模型”，RFC 8343，DOI 10.17487/RFC8343，2018年3月<https://www.rfc-editor.org/info/rfc8343>.
[RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Dynamic Subscription to YANG Events and Datastores over NETCONF", RFC 8640, DOI 10.17487/RFC8640, September 2019, <https://www.rfc-editor.org/info/rfc8640>.
[RFC8640]Voit，E.，Clemm，A.，Gonzalez-Prieto，A.，Nilsen-Nygaard，E.，和A.Tripathy，“通过NETCONF动态订阅YANG事件和数据存储”，RFC 8640，DOI 10.17487/RFC8640，2019年9月<https://www.rfc-editor.org/info/rfc8640>.
[Yang-Push-Notif-Cap] Lengyel, B., Clemm, A., and B. Claise, "Yang-Push Notification Capabilities", Work in Progress, draft-ietf-netconf-notification-capabilities-04, September 2019.
[Yang Push Notif Cap]Lengyel，B.，Clemm，A.，和B.Claise，“Yang Push通知能力”，正在进行的工作，草稿-ietf-netconf-Notification-Capabilities-042019年9月。
Rejection of an RPC for any reason is indicated via an RPC error response from the publisher. Valid RPC errors returned include both (1) existing transport-layer RPC error codes, such as those seen with NETCONF in [RFC6241] and (2) subscription-specific errors, such as those defined in the YANG data model. As a result, how subscription errors are encoded in an RPC error response is transport dependent.
通过发布服务器的RPC错误响应指示出于任何原因拒绝RPC。返回的有效RPC错误包括（1）现有传输层RPC错误代码，如[RFC6241]中的NETCONF错误代码；（2）订阅特定错误，如数据模型中定义的错误。因此，订阅错误在RPC错误响应中的编码方式取决于传输。
References to specific identities in the ietf-subscribed-notifications YANG module [RFC8639] or the ietf-yang-push YANG module may be returned as part of the error responses resulting from failed attempts at datastore subscription. For errors defined as part of the ietf-subscribed-notifications YANG module, please refer to [RFC8639]. The errors defined in this document, grouped per RPC, are as follows:
对ietf模块[RFC8639]或ietf模块[RFC8639]中特定标识的引用可能会作为错误响应的一部分返回，该错误响应是由于数据存储订阅尝试失败而导致的。有关ietf模块中定义的错误，请参阅[RFC8639]。本文档中定义的错误（按RPC分组）如下所示：
establish-subscription modify-subscription
--------------------------- ---------------------
cant-exclude period-unsupported
datastore-not-subscribable update-too-big
on-change-unsupported sync-too-big
on-change-sync-unsupported unchanging-selection
period-unsupported
update-too-big resync-subscription
sync-too-big ----------------------------
unchanging-selection no-such-subscription-resync
sync-too-big
establish-subscription modify-subscription
--------------------------- ---------------------
cant-exclude period-unsupported
datastore-not-subscribable update-too-big
on-change-unsupported sync-too-big
on-change-sync-unsupported unchanging-selection
period-unsupported
update-too-big resync-subscription
sync-too-big ----------------------------
unchanging-selection no-such-subscription-resync
sync-too-big
There is one final set of transport-independent RPC error elements included in the YANG data model. These are the four yang-data structures for failed datastore subscriptions:
YANG数据模型中包含最后一组与传输无关的RPC错误元素。以下是失败的数据存储订阅的四种数据结构：
1. yang-data "establish-subscription-error-datastore": This MUST be returned if information identifying the reason for an RPC error has not been placed elsewhere in the transport portion of a failed "establish-subscription" RPC response. This MUST be sent if hints are included.
1. yang data“建立订阅错误数据存储”：如果在失败的“建立订阅”RPC响应的传输部分的其他位置未放置识别RPC错误原因的信息，则必须返回此信息。如果包含提示，则必须发送此消息。
2. yang-data "modify-subscription-error-datastore": This MUST be returned if information identifying the reason for an RPC error has not been placed elsewhere in the transport portion of a failed "modify-subscription" RPC response. This MUST be sent if hints are included.
2. yang data“modify subscription error datastore”：如果未在失败的“modify subscription”RPC响应的传输部分的其他位置放置识别RPC错误原因的信息，则必须返回此信息。如果包含提示，则必须发送此消息。
3. yang-data "sn:delete-subscription-error": This MUST be returned if information identifying the reason for an RPC error has not been placed elsewhere in the transport portion of a failed "delete-subscription" or "kill-subscription" RPC response.
3. yang data“sn:delete subscription error”：如果未在失败的“delete subscription”或“kill subscription”RPC响应的传输部分的其他位置放置识别RPC错误原因的信息，则必须返回此信息。
4. yang-data "resync-subscription-error": This MUST be returned if information identifying the reason for an RPC error has not been placed elsewhere in the transport portion of a failed "resync-subscription" RPC response.
4. yang data“resync subscription error”：如果未在失败的“resync subscription”RPC响应的传输部分的其他位置放置识别RPC错误原因的信息，则必须返回此信息。
A subscription may be unexpectedly terminated or suspended independently of any RPC or configuration operation. In such cases, indications of such a failure MUST be provided. To accomplish this, a number of errors can be returned as part of the corresponding subscription state change notification. For this purpose, the following error identities are introduced in this document, in addition to those that were already defined in [RFC8639]:
订阅可能会意外终止或挂起，与任何RPC或配置操作无关。在这种情况下，必须提供此类故障的指示。为此，可以在相应的订阅状态更改通知中返回许多错误。为此，除了[RFC8639]中已经定义的错误标识外，本文还介绍了以下错误标识：
subscription-terminated subscription-suspended
--------------------------- ----------------------
datastore-not-subscribable period-unsupported
unchanging-selection update-too-big
synchronization-size
subscription-terminated subscription-suspended
--------------------------- ----------------------
datastore-not-subscribable period-unsupported
unchanging-selection update-too-big
synchronization-size
Acknowledgments
致谢
For their valuable comments, discussions, and feedback, we wish to acknowledge Tim Jenkins, Martin Bjorklund, Kent Watsen, Susan Hares, Yang Geng, Peipei Guo, Michael Scharf, Guangying Zheng, Tom Petch, Henk Birkholz, Reshad Rahman, Qin Wu, Rohit Ranade, and Rob Wilton.
对于他们的宝贵意见、讨论和反馈，我们要感谢蒂姆·詹金斯、马丁·比约克隆德、肯特·沃特森、苏珊·哈雷斯、杨庚、郭佩佩、迈克尔·沙尔夫、郑光英、汤姆·佩奇、亨克·比克霍兹、雷沙德·拉赫曼、秦武、罗希特·拉纳德和罗布·威尔顿。
Contributors
贡献者
The following individuals made substantial contributions to this document and should be considered coauthors. Their contributions include information contained in the YANG module provided in Section 5 of this document.
以下个人对本文件做出了重大贡献，应被视为共同作者。他们的贡献包括本文件第5节提供的YANG模块中包含的信息。
Alberto Gonzalez Prieto Microsoft Email: alberto.gonzalez@microsoft.com
Alberto Gonzalez Prieto微软电子邮件：Alberto。gonzalez@microsoft.com
Ambika Prasad Tripathy Cisco Systems Email: ambtripa@cisco.com
Ambika Prasad Tripathy Cisco Systems电子邮件：ambtripa@cisco.com
Einar Nilsen-Nygaard Cisco Systems Email: einarnn@cisco.com
Einar Nilsen Nygaard Cisco Systems电子邮件：einarnn@cisco.com
Andy Bierman YumaWorks Email: andy@yumaworks.com
Andy Bierman Yumawers电子邮件：andy@yumaworks.com
Balazs Lengyel Ericsson Email: balazs.lengyel@ericsson.com
Balazs Lengyel Ericsson电子邮件：Balazs。lengyel@ericsson.com
Authors' Addresses
作者地址
Alexander Clemm Futurewei
亚历山大·克莱姆未来
Email: ludwig@clemm.org
Email: ludwig@clemm.org
Eric Voit Cisco Systems
Eric Voit思科系统公司
Email: evoit@cisco.com
Email: evoit@cisco.com