On Tue, May 31, 2016 at 07:13:04PM +0200, Juergen Schoenwaelder wrote: > I understand YANG validation rules and I understand YANG's notion of > configuration datastores. I do not think this matches your ephemeral > configuration validation.
Prior working group discussion had suggested that bypassing validation (e.g. constraints) may be required for sufficiently fast operations. Obviously this point has remained contentious. The functional desire is sufficient speed out of configuration operations in the ephemeral elements of the datastore. If that can be done without compromising on validation - or imposing certain considerations on the structure of i2rs/ephemeral modules - I suspect that would satisfy the working group. > > 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 state may consist of ephemeral configuration > > or ephemeral operational state, or both. > > ======== > > So how is this broken? This is the only time 'ephemeral operational > state' shows up in -09. So please elaborate whether this is by > intention in order to express that 'ephemeral operational state' is > something different than a subset of 'operational state' or even > better please explain how you think 'ephemeral operational state' > relates to 'operational state'. I would suggest that we avoid talking about "ephemeral operational state". While it's possible to discuss the context of such a thing existing as a result of schema rules that config false nodes may be under nodes that are both config true and ephemeral true (using our example keyword modifications), I don't think calling it ephemeral operational state brings too much to the conversation. The one case for possible concern is that in the event the ephemeral datastore is off-line is that such config false nodes may not be present. However, this may be covered by other existing netconf mechanisms depending on how the ephemeral datastore and related modules are instantiated in the protocol. > There are many datastores being proposed and at the end they all need > to work together. Implementations can't support N different datastore > models that are not aligned. I understand that this concern is not > your prime problem since your focus is I2RS but please understand that > other people are proposing other datastores and I do believe > NETMOD/NETCONF needs to find agreement on a bigger architectural > picture that addresses the various requirements and enables > implementations that work in a predictable manner. Some of the frustration comes from the discussion for ephemeral state having been ongoing while the current operational state discussions have been somewhat new. We agree that we need to have a unified datastore architecture. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
