> Discussion of I2RS Ephemeral State > > Questions: > > 1. Do you think Ephemeral-REQ-05 covers the resource constraint > issue discussed on the list and at IETF-95? >
I read: Ephemeral-REQ-05: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as Yang module, schema tree, a schema node, submodule or components of a submodule (derived types, groupings, data node, RPCs, actions, and notifications". I have trouble to parse this since the 1st sentence does not seem to make sense for each element that you consider an object. That said, the real issue here are lifetimes. The lifetime of a config true object is determined by config changes, the lifetime of config false objects is determined by operational state changes. What happens to an ephemeral augmentation of objects if their lifetime expires? The revised datastore model I have described in draft-schoenw-netmod-revised-datastores-00 links the ephemeral state only to operational state, not at all to configuration. Does this model not satisfy the I2RS requirements and make things much simpler? 2. Does Ephemeral-REQ-06 provide the Yang requirements in > a clear fashion? Do you have any suggestions for alternative text? I think it is clear but broken. In particular the part about indicating secure/non-secure transport. > 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes > are not necessary? If so, what changes would you leave out? > Do the "policy-knobs" seem useful to you? > > 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes > are not necessary? If so, what changes would you leave out? > Do we need all the features (yang module library, call-home, > server)? I think this needs to be trimmed down. I think it should be avoided to create I2RS specific solutions for things that are already in place (e.g., NETCONF has a mechanism for protocol capability discovery and negotiation, NETCONF already supports multiple (secure) transports). I think that having a clear architectural view is essential. I am not sure the 'single pane of glass' model is the way to go. I think the decision on the architectural model is key because it impacts many of the other requirements and solutions. You want both NC and RC to support XML and JSON and SSH and TLS and (plaintext) TCP? Does this maximum of variability and flexibility really help interoperability? Perhaps things should be reorganized into things that are protocol agnostic (and should not be repeated) and things that are protocol specific - if there is indeed a need to work with multiple protocols. I also think that it is not needed to write down requirements to NETCONF for things that are already solved or being worked on. > 5. Do you think the pub/sub requirements are sufficient? > > (PUB-SUB-REQ-01, PUB-SUB-REQ-02) I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers everything that is needed. Again, this is linked to architectural question. The text, for example, assumes that there is an 'operational data stores'. As of today, this is not really the case. See draft-schoenw-netmod-revised-datastores-00 for more details. > 6. Do you have any concerns about Ephemeral-REQ-01 to > > Ephemeral-REQ-04? I think this sentence in Ephemeral-REQ-04 should be taken out: The designer of ephemeral state modules are advised that such constraints may impact the speed of processing ephemeral state commits and should avoid them when speed is essential. First, it may depend on the architectural model that will be used and it likely also depends on implementation details whether something is fast or not. Or is there in inherent reason why a reference to non-ephemeral state has to be 'slow'? /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
