On Wed, Jun 01, 2016 at 05:08:16AM -0700, Andy Bierman wrote: > On Wed, Jun 1, 2016 at 2:10 AM, Juergen Schoenwaelder < > [email protected]> wrote: > > On Tue, May 31, 2016 at 03:36:40PM -0400, Jeffrey Haas wrote: > > > I agree that your observation covers the general intent. The > > requirements > > > language above is attempting to be a bit too specific for a given > > > implementation detail, namely instantiation of ephemeral behaviors in a > > data > > > tree. > > > > > > Could you please supply alternative text? > > > > It is difficult since I am not sure what the original intention > > was. There is augmentation at the schema tree level and then there is > > augmentation at the data tree level. My understanding (which may be > > wrong) is that I2RS primarily looks at data tree level augmentations > > of operational state data and not so much at configuration datastore > > data. Part of the openconfig inspired discussion is to do away with > > the /foo and /foo-state division and that has an impact how the schema > > trees are constructed. > > > > > This REQ-05 doesn't give any reason why data nodes need to be tagged as > ephemeral > in the schema tree, or what it means to be tagged as ephemeral. > > My intention for suggesting an "i2rs:ephemeral" YANG extension was to > identify > the I2RS conformance requirements for a server claiming to implement I2RS > for a specific YANG module. > > A node tagged as ephemeral MUST be accessible in the ephemeral datastore > using I2RS if the module (or feature) is supported. An untagged node MAY be > accessible.
This covers the intent properly. Your suggestion of a mechanism in yang is probably reasonable, but as Jürgen would say, this is all about the requirements. So, could you suggest text covering the requirement? > An I2RS data model could define read-only nodes. These nodes could > be considered ephemeral operational state. Should these nodes live in > this datastore or an "operational" datastore? I don't know. > That's why we probably need your draft. If the implementation detail for ephemeral state is that it is part of a datastore, then having the operational state in the ephemeral datastore seems to make sense. However, I find it more likely that we'll need a mechanism to get the "union view after precedence" (i.e. panes of glass model) for a conceptional datastore that covers state from local and ephemeral. But again, that's a protocol detail which we're trying to avoid in the requirements. If you think it belongs in the strawman or another document, we'd love text. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
