On Wed, Jun 1, 2016 at 5:41 AM, Jeffrey Haas <[email protected]> wrote: > 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? > > I thought I just did.
Andy > > 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
