I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-i2rs-ephemeral-state-19 Summary: This document describes the requirements for the support for ephemeral state in the I2RS protocol, which can be supported by NETCONF/RESTCONF and the related impacts on the YANG model, the NETCONF and RESTCONF protocols. Main feedback: The rational for this document is unclear. It is somehow positioned between the high-level requirements given in the RFC7921 and a future document that will further investigate the impacts on YANG, NETCONF and RESTCONF. Some of the critical requirements listed in this draft seem to challenge the current design of YANG model and NETCONF/RESTCONG protocols and then jeopardize the whole basic assumption of "re-use" highlighted in the RFC7921. IMHO, it would be more useful to capture in a single document the specific requirements on ephemeral state, impacts on YANG/NETCONG/RESTCONF and the conclusion on the feasibility/required enhancements. Detailed review provided below. Regards, Lionel ************************ 1. Introduction The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. Additionally, the I2RS Working group has chosen to re-use two existing protocols, NETCONF [RFC6241] and its similar but lighter- weight relative RESTCONF [I-D.ietf-netconf-restconf], as the protocols for carrying I2RS. What does re-use of a protocol mean? Re-use means that while YANG, NETCONF and RESTCONF are a good starting basis for the I2RS protocol, the creation of the I2RS protocol implementations requires that the I2RS requirements 1. select features from YANG, NETCONF, and RESTCONF per version of the I2RS protocol (See sections 4, 5, and 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), The purpose of these requirements is to ensure clarity during I2RS protocol creation. [LM] The aim of the document is not so clear. The working assumption is : re-use but with "addition". What does addition mean? Who is in charge to check that the proposed "additions" can be supported by YANG/NETCONF/RESTCONF without protocol updates? Where is the need to first derive specific requirements from RFC7921 and then check if they can be fulfilled by the model and the protocols, instead of doing both in the same document? 2. Review of Requirements from I2RS architecture document The I2RS architecture defines important high-level requirements for the I2RS protocol. The following are requirements distilled from [RFC7921] that provide context for the ephemeral data state requirements given in sections 3-8: [LM] What is the meaning of "distilled" here? Are these requirements explicitly part of the RFC7921 or the requirements listed in this draft may be "relative" or even complementary requirements compared to the RFC7921? 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. [LM] Is it a requirement related to the I2RS protocol or to the transport protocol? 2. I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD to 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. [LM] I think that the first sentence is not so related to the I2RS protocol but rather to the mechanism to provision the I2RS agent with this info (e.g. AAA). 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 which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use [LM] If I'm correct, "First entry wins" is for clients associated with the same priority, right? If it is, it is not only about 'higher' priority. 4. I2RS Client's secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written. [LM] Not sure of the relevance of this requirement in the context of the I2RS protocol design if this info is opaque for the agent. 5. 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 not put an undue strain on the I2RS agent. [LM] This requirement seems to imply that the priority associated with the client ID is transitively associated with the client's entry in the I2RS agent. If it is, this requirement should be clarified along with Req 3 or just after. 3.1. Persistence 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. [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG model. As defined in RFC7950 (recently published), there are only two flavors of data managed with YANG: configuration data and state data, differentiated by the "config" statement with the argument the string "true" or "false". This requirement seems to imply a new "flavor" i.e. ephemeral state, which seems not compatible with the existing model that cannot be accommodated using a Boolean value. Does it mean that a new version of the YANG model would be required to fulfil this requirement? [LM] Most of the other requirements are derived from and/or dependent on the req 1. [LM] Other specific comments: 5. NETCONF Features for Ephemeral State 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). [LM] I wonder how this impacts the recommendation on the use of configuration lock mechanism when it is known that multiple instances may update the same configuration data as per RFC6241. Here, it seems that the priority is able to override the lock in place, which is not allowed in NETCONF. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: o the data nodes MAY store I2RS client identity and not the effective priority at the time the data node is stored. [LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage. 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. [LM] there are several references to the use of AAA-based solutions for priority handling. Does it require any action in RADEXT or Dime to support these requirements, at least as a default standard mechanism for I2RS? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.