Hi, here are few comments on the latest version.
Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a constraints. I am not sure what 'must be able to utilized temporary operational state as constraints' means. The text in the parenthesis does not help me understand this better. Did you want to say something like: 'Ephemeral configuration state may have constraints that refer to operational state'? I am using 'ephemeral configuration state' since this is used in other places (although sometimes worded slightly different). Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state for purposes of implementing constraints. Hm, now I wonder whether this is just a special case of Ephemeral-REQ-03 and if so it is not clear why we need this as a separate requirement. If this is not the case but something different, then likely my interpretation of Ephemeral-REQ-03 is wrong. s/2RS/I2RS in Ephemeral-REQ-05. I would actually rewrite the beginning of Ephemeral-REQ-05 as follows: Ephemeral-REQ-05: I2RS interactions 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 interactions, 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. I would remove the Note: since I believe the key observation here are the potentially high volume of I2RS interactions and not the fact that there is a datastore involved that is ephemeral. I am still struggling with Ephemeral-REQ-06: Ephemeral-REQ-06: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as any one of the following: yang module, submodule or components of submodule, or schema node. Perhaps this is what you wanted to say? Ephemeral-REQ-06: The ability to augment YANG schema nodes with additional YANG schema nodes that have the property of being ephemeral. I wonder why there are some ephemeral state requirements in sections labeled with "I2RS Protocol version 1" while others seem to be protocol version agnostic. What is the definition of I2RS protocol versions? Perhaps this notion of protocol version should simply be removed; I am not sure it helps with the requirements. Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model that nodes have the following properties: ephemeral, writable/not- writable, and status/configuration. This is confusing because it says 'nodes' while in YANG we distinguish data nodes and schema nodes. For example, in YANG a schema node has a property config true|false. This schema node property defines whether corresponding data nodes are writable/non-writable. In other words, some of this requirement seems to be covered by YANG already; so what remains is the 'ephemeral' property - does the requirement expect this to be a property of a schema node? Editorial: s/prevent was the oscillation/prevent oscillation/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
