Internet Engineering Task Force (IETF) J. Haas
Request for Comments: 8242 Juniper
Category: Informational S. Hares
ISSN: 2070-1721 Huawei
September 2017
Internet Engineering Task Force (IETF) J. Haas
Request for Comments: 8242 Juniper
Category: Informational S. Hares
ISSN: 2070-1721 Huawei
September 2017
Interface to the Routing System (I2RS) Ephemeral State Requirements
与路由系统（I2RS）临时状态要求的接口
Abstract
摘要
"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System (I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol.
“路由系统接口架构”（RFC 7921）抽象地描述了任何试图满足路由系统接口（I2RS）协议需求的协议套件必须提供的短暂状态（在能力和行为方面）的许多要求。本文件详细描述了实施I2RS协议的人员对短暂状态的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8242.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8242.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Architectural Requirements for Ephemeral State ..................4
3. Ephemeral State Requirements ....................................5
3.1. Persistence ................................................5
3.2. Constraints ................................................6
3.3. Hierarchy ..................................................6
3.4. Ephemeral Configuration Overlapping Local Configuration ....6
4. YANG Features for Ephemeral State ...............................7
5. NETCONF Features for Ephemeral State ............................7
6. RESTCONF Features for Ephemeral State ...........................7
7. Requirements regarding Supporting Multi-Head Control via
Client ..........................................................7
8. Multiple Message Transactions ...................................9
9. Pub/Sub Requirements Expanded for Ephemeral State ...............9
10. IANA Considerations ...........................................10
11. Security Considerations .......................................10
12. Normative References ..........................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Architectural Requirements for Ephemeral State ..................4
3. Ephemeral State Requirements ....................................5
3.1. Persistence ................................................5
3.2. Constraints ................................................6
3.3. Hierarchy ..................................................6
3.4. Ephemeral Configuration Overlapping Local Configuration ....6
4. YANG Features for Ephemeral State ...............................7
5. NETCONF Features for Ephemeral State ............................7
6. RESTCONF Features for Ephemeral State ...........................7
7. Requirements regarding Supporting Multi-Head Control via
Client ..........................................................7
8. Multiple Message Transactions ...................................9
9. Pub/Sub Requirements Expanded for Ephemeral State ...............9
10. IANA Considerations ...........................................10
11. Security Considerations .......................................10
12. Normative References ..........................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
The Interface to the Routing System (I2RS) Working Group (WG) is chartered with providing architecture and mechanisms to inject into and retrieve information from the routing system. The I2RS Architecture document [RFC7921] abstractly documents a number of requirements for implementing the I2RS and defines ephemeral state as "state that does not survive the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device" (see Section 1.1 of [RFC7921]). Section 2 of this document describes the specific requirements that the I2RS WG has identified based on the I2RS architecture's abstract requirements. The Interface to the Routing System (I2RS) Working Group (WG) is chartered with providing architecture and mechanisms to inject into and retrieve information from the routing system. The I2RS Architecture document [RFC7921] abstractly documents a number of requirements for implementing the I2RS and defines ephemeral state as "state that does not survive the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device" (see Section 1.1 of [RFC7921]). Section 2 of this document provides a summary of these abstract requirements, and section 3 recasts these abstract requirements into specific requirements for the Ephemeral state for any IETF network management system.
路由系统（I2RS）工作组（WG）的接口特许提供架构和机制，以向路由系统中注入和检索信息。I2RS体系结构文件[RFC7921]抽象地记录了实施I2RS的许多要求，并将短暂状态定义为“路由设备重新启动或路由设备上处理I2RS软件的软件重新启动后无法生存的状态”（参见[RFC7921]第1.1节）。本文件第2节描述了I2RS工作组根据I2RS体系结构的抽象需求确定的具体需求。路由系统（I2RS）工作组（WG）的接口特许提供架构和机制，以向路由系统中注入和检索信息。I2RS体系结构文件[RFC7921]抽象地记录了实施I2RS的许多要求，并将短暂状态定义为“路由设备重新启动或路由设备上处理I2RS软件的软件重新启动后无法生存的状态”（参见[RFC7921]第1.1节）。本文件第2节概述了这些抽象需求，第3节将这些抽象需求重新定义为任何IETF网络管理系统短暂状态的具体需求。
The I2RS WG has chosen to use the YANG data modeling language [RFC7950] as the basis to implement its mechanisms.
I2RS工作组选择使用YANG数据建模语言[RFC7950]作为实现其机制的基础。
Additionally, the I2RS WG has chosen to reuse two existing protocols, NETCONF [RFC6241] and its similar but lighter-weight relative RESTCONF [RFC8040], as the protocols for carrying I2RS.
此外，I2RS工作组选择重用两个现有协议NETCONF[RFC6241]及其类似但重量较轻的相对restcconf[RFC8040]作为承载I2RS的协议。
What does reuse of a protocol mean? Reuse means that while the combination of the YANG modeling language and the NETCONF and RESTCONF protocols is a good starting basis for the I2RS data modeling language and protocol, the requirements for I2RS protocol implementations should:
协议的重用意味着什么？重用意味着，虽然YANG建模语言与NETCONF和RESTCONF协议的结合是I2RS数据建模语言和协议的良好开端，但I2RS协议实现的要求应：
1. select features from the YANG modeling language and the NETCONF and RESTCONF protocols per version of the I2RS protocol (see Sections 4, 5, and 6), and
1. 根据I2RS协议的版本，从YANG建模语言和NETCONF和RESTCONF协议中选择功能（参见第4、5和6节），并
2. propose additions to YANG, NETCONF, and RESTCONF per version of the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability).
2. 建议在I2RS协议的每个版本中增加YANG、NETCONF和RESTCONF的关键功能（临时状态、协议安全性、发布/订阅服务、可追溯性）。
The purpose of these requirements is to ensure clarity during I2RS protocol creation.
这些要求的目的是确保I2RS协议创建期间的清晰性。
Support for ephemeral state is an I2RS protocol requirement that necessitates datastore changes (see Section 3), YANG additions (see Section 4), NETCONF additions (see Section 5), and RESTCONF additions (see Section 6).
对临时状态的支持是I2RS协议的要求，需要对数据存储进行更改（参见第3节）、添加数据（参见第4节）、添加NETCONF（参见第5节）和添加RESTCONF（参见第6节）。
Sections 7-9 provide details that expand upon the changes in Sections 3-6 to clarify requirements discussed by the I2RS and NETCONF WGs. Section 7 provides additional requirements that detail how write-conflicts should be resolved if two I2RS client write the same data. Section 8 describes I2RS requirements for support of multiple message transactions. Section 9 highlights two requirements for I2RS publication/subscription [RFC7923] that must be expanded for ephemeral state.
第7-9节详细介绍了第3-6节中的变更，以澄清I2RS和NETCONF工作组讨论的要求。第7节提供了附加要求，详细说明了如果两个I2RS客户端写入相同的数据，应如何解决写入冲突。第8节描述了支持多个消息事务的I2RS要求。第9节强调了I2RS发布/订阅[RFC7923]的两项要求，这些要求必须针对短暂状态进行扩展。
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]所述进行解释。
The I2RS architecture [RFC7921] and the I2RS problem statement [RFC7920] define the important high-level requirements for the I2RS protocol in abstract terms. This section distills this high-level abstract guidance into specific requirements for the I2RS protocol. To aid the reader, there are references back to the abstract descriptions in the I2RS architecture document and the I2RS problem statement, but the reader should note the requirements below are not explicitly stated in the I2RS architecture document or in the I2RS problem statement.
I2RS体系结构[RFC7921]和I2RS问题陈述[RFC7920]抽象地定义了I2RS协议的重要高级需求。本节将此高级抽象指南提炼为I2RS协议的具体要求。为了帮助读者，在I2RS架构（architecture）文档和I2RS问题陈述中有对抽象描述的引用，但读者应注意，以下要求未在I2RS架构（architecture）文档或I2RS问题陈述中明确说明。
Requirements:
要求：
1. The I2RS protocol SHOULD support an asynchronous programmatic interface with properties described in Section 5 of [RFC7920] (e.g., high throughput) with support for target information streams, filtered events, and thresholded events (real-time events) sent by an I2RS agent to an I2RS client (from Section 1.1 of [RFC7921]).
1. I2RS协议应支持具有[RFC7920]第5节所述属性的异步编程接口（例如，高吞吐量），并支持I2RS代理发送给I2RS客户端（来自[RFC7921]第1.1节）的目标信息流、过滤事件和阈值事件（实时事件）。
2. An I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded (from Section 4 of [RFC7921]).
2. I2RS代理必须在创建或修改节点时记录客户端标识。I2RS代理应该能够读取节点的客户端标识，并使用客户端标识的关联优先级来解决冲突。二级标识有助于可追溯性，也可记录（来自[RFC7921]第4节）。
3. An I2RS client identity MUST have only one priority for the client's identifier. A collision on writes is considered an error, but the priority associated with each client identifier is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client that is higher priority can modify an existing entry (first entry wins). Priority only has meaning at the time of use (from Section 7.8 of [RFC7921]).
3. I2RS客户端标识必须只有一个客户端标识符的优先级。写入冲突被视为错误，但与每个客户端标识符关联的优先级用于比较来自两个不同客户端的请求，以便修改现有节点条目。只有来自优先级较高的客户端的条目才能修改现有条目（第一条条目获胜）。优先权仅在使用时具有意义（根据[RFC7921]第7.8节）。
4. An I2RS client's secondary identity data is read-only metadata that is recorded by the I2RS agent associated with a data model's node when the data node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written (from Sections 7.4 of [RFC7921].)
4. I2RS客户端的次要标识数据是只读元数据，在写入数据节点时，由与数据模型节点关联的I2RS代理记录。与主客户端标识一样，只有在写入数据节点时才应记录辅助标识（参见[RFC7921]第7.4节）
5. An I2RS agent MAY have a lower-priority I2RS client attempting to modify a higher-priority client's entry in a data model. The filtering out of lower-priority clients attempting to write or modify a higher-priority client's entry in a data model SHOULD be effectively handled and SHOULD not put an undue strain on the I2RS agent. (See Section 7.8 of [RFC7921] augmented by the resource limitation language in Section 8 [RFC7921].)
5. I2RS代理可能有一个低优先级的I2RS客户端试图修改数据模型中高优先级客户端的条目。对试图写入或修改数据模型中的高优先级客户端条目的低优先级客户端的筛选应得到有效处理，并且不应给I2RS代理带来过度压力。（见[RFC7921]第7.8节，并在第8节[RFC7921]中增加了资源限制语言。）
In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state is defined as potentially including in a data model ephemeral configuration and operational state which is flagged as ephemeral.
在需求Ephemeral-REQ-01至Ephemeral-REQ-15中，Ephemeral state定义为可能包含在数据模型中，Ephemeral配置和操作状态标记为Ephemeral。
Ephemeral-REQ-01: I2RS requires ephemeral state, i.e., state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent.
Ephemeral-REQ-01:I2RS需要短暂状态，即在重新启动期间不会持续的状态。如果必须恢复状态，则只能通过I2RS代理从I2RS客户端执行重播操作。
At first glance, the I2RS ephemeral state may seem equivalent to the writable-running datastore in NETCONF (e.g., running-config), which can be copied to a datastore that persists across a reboot (software or hardware). However, I2RS ephemeral state MUST NOT persist across a reboot (software or hardware).
乍一看，I2RS短暂状态可能相当于NETCONF中的可写运行数据存储（例如，running config），可以将其复制到在重新启动（软件或硬件）过程中持续存在的数据存储。但是，I2RS短暂状态不得在重新启动（软件或硬件）期间持续存在。
Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral state for constraint purposes; it SHALL be considered a validation error if it does.
临时状态-REQ-02：非临时状态不得为约束目的引用临时状态；如果存在，则应将其视为验证错误。
Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast-changing or short-lived operational state nodes, such as MPLS LSP-ID (label-switched path ID) or a BGP Adj-RIB-IN (Adjacent RIB Inbound). Ephemeral state constraints should be assessed when the ephemeral state is written, and if any of the constraints change to make the constraints invalid after that time, the I2RS agent SHOULD notify the I2RS client.
Ephemeral-REQ-03：Ephemeral状态必须能够具有参考操作状态的约束，这包括可能快速变化或短期存在的操作状态节点，例如MPLS LSP-ID（标签交换路径ID）或BGP Adj RIB IN（相邻RIB入站）。在写入临时状态时，应评估临时状态约束，如果任何约束在该时间后发生更改，使约束无效，I2RS代理应通知I2RS客户端。
Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state.
临时状态-REQ-04：临时状态必须能够将非临时状态引用为约束。非临时状态可以是配置状态或操作状态。
Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC, or other mechanisms may lead to undesirable or unsustainable resource consumption on a system implementing an I2RS agent. It is RECOMMENDED that mechanisms be made available to permit prioritization of I2RS operations, when appropriate, to permit implementations to shed work load when operating under constrained resources. An example of such a work-shedding mechanism is rate-limiting.
Ephemeral-REQ-05:I2RS发布订阅[RFC7923]、跟踪[RFC7922]、RPC或其他机制可能会导致在实现I2RS代理的系统上产生不希望的或不可持续的资源消耗。建议提供机制，以便在适当的情况下对I2RS操作进行优先级排序，以便在资源受限的情况下操作时，允许实施减轻工作量。这种裁员机制的一个例子是限速。
Ephemeral-REQ-06: YANG MUST have the ability to do the following:
Ephemeral-REQ-06:YANG必须具备以下能力：
1. define a YANG module or submodule schema that only contains data nodes with the property of being ephemeral, and
1. 定义仅包含具有短暂属性的数据节点的模块或子模块架构，以及
2. augment a YANG module with additional YANG schema nodes that have the property of being ephemeral.
2. 使用具有短暂属性的附加YANG模式节点扩充YANG模块。
Ephemeral-REQ-07: Local configuration MUST have a priority that is comparable with individual I2RS client priorities for making changes. This priority will determine whether local configuration changes or individual ephemeral configuration changes take precedence as described in [RFC7921]. The I2RS protocol MUST support this mechanism.
Ephemeral-REQ-07：本地配置的优先级必须与单个I2RS客户端进行更改的优先级相当。此优先级将决定本地配置更改还是单个临时配置更改优先，如[RFC7921]中所述。I2RS协议必须支持这种机制。
Ephemeral-REQ-08: In addition to config true/false, there MUST be a way to indicate that YANG schema nodes represent ephemeral state. It is desirable to allow for, and have a way to indicate, config false YANG schema nodes that are writable operational state.
Ephemeral-REQ-08：除了config true/false之外，还必须有一种方法来指示模式节点表示临时状态。理想的做法是允许并有方法指示可写操作状态的模式节点。
Ephemeral-REQ-09: The changes to NETCONF must include:
Ephemeral-REQ-09：对NETCONF的更改必须包括：
1. Support for communication mechanisms to enable an I2RS client to determine that an I2RS agent supports the mechanisms needed for I2RS operation.
1. 支持通信机制，使I2RS客户端能够确定I2RS代理支持I2RS操作所需的机制。
2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in Section 7 (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
2. 临时状态必须支持使用第7节中定义的优先级要求通知写冲突（参见要求临时状态-REQ-11至临时状态-REQ-14）。
Ephemeral-REQ-10: The conceptual changes to RESTCONF are:
Ephemeral-REQ-10：RESTCONF的概念性更改如下：
1. Support for communication mechanisms to enable an I2RS client to determine that an I2RS agent supports the mechanisms needed for I2RS operation.
1. 支持通信机制，使I2RS客户端能够确定I2RS代理支持I2RS操作所需的机制。
2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in Section 7 (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
2. 临时状态必须支持使用第7节中定义的优先级要求通知写冲突（参见要求临时状态-REQ-11至临时状态-REQ-14）。
7. Requirements regarding Supporting Multi-Head Control via Client Priority
7. 关于通过客户端优先级支持多头控制的要求
To support multi-headed control, I2RS requires that there be a decidable means of arbitrating the correct state of data when multiple clients attempt to manipulate the same piece of data. This is done via a priority mechanism with the highest priority winning. This priority is per client.
为了支持多头控制，I2RS要求当多个客户端试图操作同一数据段时，有一种可判定的方法来仲裁数据的正确状态。这是通过具有最高优先级的优先级机制实现的。此优先级为每个客户端。
Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol in order to support I2RS client identity and priority:
Ephemeral-REQ-11：为了支持I2RS客户端标识和优先级，I2RS协议必须支持以下要求：
o the data nodes MUST store I2RS client identity and MAY store the effective priority at the time the data node is stored.
o 数据节点必须存储I2RS客户端标识，并且可以在存储数据节点时存储有效优先级。
o Per SEC-REQ-07 in Section 4.3 of [RFC8241], an I2RS Identifier MUST have just one priority. The I2RS protocol MUST support the ability to have data nodes store I2RS client identity and not the effective priority of the I2RS client at the time the data node is stored.
o 根据[RFC8241]第4.3节中的SEC-REQ-07，I2RS标识符必须只有一个优先级。I2RS协议必须支持数据节点存储I2RS客户端标识的能力，而不是在存储数据节点时I2RS客户端的有效优先级。
o The priority MAY be dynamically changed by AAA, but the exact actions are part of the protocol definition as long as collisions are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14.
o AAA可以动态更改优先级，但只要冲突按照Ephemeral-REQ-12、Ephemeral-REQ-13和Ephemeral-REQ-14中的描述进行处理，则确切的操作就是协议定义的一部分。
Ephemeral-REQ-12: When a collision occurs as two I2RS clients are trying to write the same data node, this collision is considered an error. The I2RS priorities are used to provide a deterministic resolution to the conflict. When there is a collision, and the data node is changed, a notification (which includes indicating the data node the collision occurred on) MUST be sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state.
Ephemeral-REQ-12：当两个I2RS客户端试图写入同一数据节点时发生冲突时，此冲突被视为错误。I2RS优先级用于为冲突提供确定性解决方案。发生冲突且数据节点发生更改时，必须向原始客户端发送通知（其中包括指示发生冲突的数据节点），以使原始客户端有机会处理围绕冲突的问题。原始客户端可能需要修复其状态。
Explanation: RESTCONF and NETCONF updates can come in concurrently from alternative sources. Therefore, the collision detection and comparison of priority needs to occur for any type of update.
说明：RESTCONF和NETCONF更新可以同时从其他来源获得。因此，任何类型的更新都需要进行冲突检测和优先级比较。
For example, RESTCONF tracks the source of configuration change via the entity-tag (see Section 3.5.2 of [RFC8040]), which the server returns to the client along with the value in GET or HEAD methods. RESTCONF requires that this resource entity-tag be updated whenever a resource or configuration resource within the resource is altered. In the RESTCONF processing, when the resource or a configuration resource within the resource is altered, the processing of the configuration change for two I2RS clients must detect an I2RS collision and resolve the collision using the priority mechanism.
例如，RESTCONF通过实体标记（参见[RFC8040]的第3.5.2节）跟踪配置更改的来源，服务器将实体标记与GET或HEAD方法中的值一起返回给客户端。RESTCONF要求每当资源中的资源或配置资源发生更改时，都更新此资源实体标记。在RESTCONF处理中，当资源或资源中的配置资源发生更改时，两个I2RS客户端的配置更改处理必须检测到I2RS冲突，并使用优先级机制解决冲突。
Ephemeral-REQ-13: Multi-headed control is required for collisions and the priority resolution of collisions. Multi-headed control is not tied to ephemeral state. The I2RS protocol MUST NOT mandate the internal mechanism for how AAA protocols (e.g., Radius or Diameter) or mechanisms distribute priority per identity except that any AAA protocols MUST operate over a secure transport layer (see Radius [RFC6614] and Diameter [RFC6733]). Mechanisms that prevent collisions of two clients trying to modify the same node of data are the focus.
Ephemeral-REQ-13：碰撞和碰撞优先级解析需要多头控制。多头控制与短暂状态无关。I2RS协议不得强制规定AAA协议（如Radius或Diameter）或机制如何分配每个身份的优先级的内部机制，除非任何AAA协议必须在安全传输层上运行（请参阅Radius[RFC6614]和Diameter[RFC6733]）。重点在于防止两个试图修改同一数据节点的客户端发生冲突的机制。
Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST be provided to handle the error scenario in which two clients, with the same priority, update the same configuration data node. The I2RS architecture gives one way that this could be achieved: by specifying that the first update wins. Other solutions that prevent oscillation of the config data node are also acceptable.
Ephemeral-REQ-14：必须提供确定性冲突解决机制，以处理两个具有相同优先级的客户端更新相同配置数据节点的错误场景。I2RS体系结构提供了一种实现这一点的方法：指定第一次更新获胜。防止配置数据节点振荡的其他解决方案也是可以接受的。
Ephemeral-REQ-15: Section 7.9 of the [RFC7921] states the I2RS architecture does not include multi-message atomicity and roll-back mechanisms. The I2RS protocol implementation MUST NOT require the support of these features. As part of this requirement, the I2RS protocol should support:
Ephemeral-REQ-15:[RFC7921]第7.9节指出，I2RS体系结构不包括多消息原子性和回滚机制。I2RS协议的实施不需要这些功能的支持。作为该要求的一部分，I2RS协议应支持：
multiple operations in one message. An error in one operation MUST NOT stop additional operations from being carried out, nor can it cause previous operations to be rolled back.
一条消息中包含多个操作。一个操作中的错误不能阻止执行其他操作，也不能导致回滚以前的操作。
multiple operations in multiple messages, but multiple message-command error handling MUST NOT insert errors into the I2RS ephemeral state.
多条消息中的多个操作，但多条消息命令错误处理不得将错误插入I2RS临时状态。
I2RS clients require the ability to monitor changes to ephemeral state. While subscriptions are well defined for receiving notifications, the need to create a notification set for all ephemeral configuration state may be overly burdensome to the user.
I2RS客户端需要能够监视短暂状态的变化。虽然订阅是为接收通知而定义的，但为所有临时配置状态创建通知集的需要可能会让用户负担过重。
Thus, there is a need for a general subscription mechanism that can provide notification of changed state, with sufficient information to permit the client to retrieve the impacted nodes. This should be doable without requiring the notifications to be created as part of every single I2RS module.
因此，需要一种通用的订阅机制，该机制可以提供更改状态的通知，并提供足够的信息以允许客户端检索受影响的节点。这应该是可行的，无需将通知创建为每个I2RS模块的一部分。
The publication/subscription requirements for I2RS are in [RFC7923], and the following general requirements SHOULD be understood to be expanded to include ephemeral state:
I2R的发布/订阅要求见[RFC7923]，以下一般要求应理解为扩展到包括短暂状态：
o Pub-Sub-REQ-01: The subscription service MUST support subscriptions against ephemeral state in operational datastores, configuration datastores, or both.
o Pub-Sub-REQ-01：订阅服务必须支持针对操作数据存储、配置数据存储或两者中的短暂状态的订阅。
o Pub-Sub-REQ-02: The subscription service MUST support filtering so that subscribed updates under a target node might publish either:
o Pub-Sub-REQ-02:订阅服务必须支持筛选，以便目标节点下的订阅更新可以发布：
1. only ephemeral state in operational data or configuration data, or
1. 运行数据或配置数据中的短暂状态，或
2. both ephemeral and operational data.
2. 临时数据和操作数据。
o Pub-Sub-REQ-03: The subscription service MUST support subscriptions that are ephemeral. (For example, an ephemeral data model that has ephemeral subscriptions.)
o Pub-Sub-REQ-03:订阅服务必须支持短暂的订阅。（例如，具有临时订阅的临时数据模型。）
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The security requirements for the I2RS protocol are covered in [RFC8241].
[RFC8241]中介绍了I2RS协议的安全要求。
[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>.
[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>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<https://www.rfc-editor.org/info/rfc6614>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<https://www.rfc-editor.org/info/rfc6733>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7920, DOI 10.17487/RFC7920, June 2016, <https://www.rfc-editor.org/info/rfc7920>.
[RFC7920]Atlas，A.，Ed.，Nadeau，T.，Ed.，和D.Ward，“路由系统接口问题声明”，RFC 7920，DOI 10.17487/RFC7920，2016年6月<https://www.rfc-editor.org/info/rfc7920>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <https://www.rfc-editor.org/info/rfc7921>.
[RFC7921]Atlas，A.，Halpern，J.，Hares，S.，Ward，D.，和T.Nadeau，“路由系统接口架构”，RFC 7921，DOI 10.17487/RFC7921，2016年6月<https://www.rfc-editor.org/info/rfc7921>.
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, <https://www.rfc-editor.org/info/rfc7922>.
[RFC7922]Clarke，J.，Salgueiro，G.，和C.Pignataro，“路由系统接口（I2RS）可追溯性：框架和信息模型”，RFC 7922，DOI 10.17487/RFC7922，2016年6月<https://www.rfc-editor.org/info/rfc7922>.
[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>.
[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>.
[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>.
[RFC8241] Hares, S., Migault, D., and J. Halpern, "Interface to the Routing System (I2RS) Security-Related Requirements", RFC 8241, DOI 10.17487/RFC8241, September 2017, <https://www.rfc-editor.org/info/rfc8241>.
[RFC8241]Hares，S.，Migault，D.，和J.Halpern，“路由系统（I2RS）安全相关要求的接口”，RFC 8241，DOI 10.17487/RFC82412017年9月<https://www.rfc-editor.org/info/rfc8241>.
Acknowledgements
致谢
This document is an attempt to distill lengthy conversations on the I2RS mailing list for an architecture that was, for a long period of time, a moving target. Some individuals in particular warrant specific mention for their extensive help in providing the basis for this document:
本文档试图从I2RS邮件列表中提取出一个长期以来一直是移动目标的体系结构的冗长对话。特别值得一提的是，一些个人在为本文件提供基础方面提供了广泛的帮助：
Alia Atlas, Andy Bierman, Martin Bjorklund, Dean Bogdanavic, Rex Fernando, Joel Halpern, Thomas Nadeau, Juergen Schoenwaelder, Kent Watsen, Robert Wilton, and Joe Clarke.
Alia Atlas、Andy Bierman、Martin Bjorklund、Dean Bogdanavic、Rex Fernando、Joel Halpern、Thomas Nadeau、Juergen Schoenwaeld、Kent Watsen、Robert Wilton和Joe Clarke。
Authors' Addresses
作者地址
Jeff Haas Juniper
杰夫·哈斯·朱尼珀
Email: jhaas@juniper.net
Email: jhaas@juniper.net
Susan Hares Huawei Saline United States of America
Susan Hares，美利坚合众国
Email: shares@ndzh.com
Email: shares@ndzh.com