[i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-21: (with DISCUSS and COMMENT)
"Benoit Claise" <email@example.com> Thu, 27 October 2016 14:42 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C16E11294F4; Thu, 27 Oct 2016 07:42:08 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: "Benoit Claise" <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Date: Thu, 27 Oct 2016 07:42:08 -0700
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-21: (with DISCUSS and COMMENT)
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2016 14:42:13 -0000
Benoit Claise has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - I read the abstract and title: clearly this is about ephemeral state. I2RS Ephemeral State Requirements draft-ietf-i2rs-ephemeral-state-19.txt Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. Why (re-hashing) requirements not related to ephemeral? What the goal of this section 2? It seems more like adding confusing that being helpful. Too many requirements from different documents in I2RS: "distilling" them between documents is looking for troubles. note: section 9 title " Pub/Sub Requirements Expanded for Ephemeral State" and content area clear - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? 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, 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. I should be missing something. Examples would help me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: - Section 5 versus 6 For NETCONF: 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). For RESTCONF: 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). must versus MUST. If there are some language subtleties here, I didn't grasp them. - "To support Multi-Headed Control," Multi-Headed Control? I guess I know what you mean, but expressed like this (capitalized), I'm looking for a well-known, well-defined term. Later on, I see "Multi-headed control" - s/yang/YANG - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol remove one "I2RS protocol" instance - 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: I would remove: "(e.g. NETCONF/RESTCONF + yang)" - "MUST BE" = MUST Belgium :-) Pretty good feedback from Lionel Morand's OPS DIR review: 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?
- [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs… Benoit Claise