On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwat...@juniper.net> wrote:
> > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional module > > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because it’s not tricky ;) > > The client and server developers still need to know about this auto-generated module and implement it. Operators might have to know about it to use it. > > Of course this solution only works if the value-set of operational data > > is exactly the same as the configurable value-set (which is sometimes > > not the case at all). > > The value-set of the operational data would be the combination of both the > config true and config false nodes. [Did you see this in my last > response? I received an offline message indicating that my previous > response was somewhat malformed, so you might’ve missed it...]. The > config false nodes are obviously part of the operational data. For the > config true nodes, I’ve been swayed to believe that every config true node > can also have an operational value. I didn’t think so at first, using > ‘hostname’ as an example to make my point, but it was pointed out that the > admin might circumvent the YANG-driven config engine completely and set the > hostname via the UNIX command line instead. In this case, the intended > hostname value might differ from the operational hostname value. Even for > nodes where we’re convinced there can never be an operational value that > differs from the intended value, there still might be a propagation delay > that causes a difference to be perceived in time. All this points to a > rather conservative and thankfully simple solution that the value-set of > opstate is the combination of *all* the config true and config false nodes. > > But the foo-state node is being omitted from the module. How does the pyang plugin know how to produce the extra values so the auto-generated foo-state node has all the combined values? > > > What is an "opstate-aware tree". > > I should’ve written “opstate-aware data model”. > > To be clear, by “opstate-aware tree”, I meant the YANG module would only > have a top-level /foo tree that has both config true and config false > nodes, with the expectation that the solution provided by > draft-ietf-netmod-revised-datastores enables 1) opstate for both > system-generated objects as well as for config true nodes and 2) opstate > for all config true nodes also (note: this doesn’t remove the need for > explicit config false nodes for negotiated values like MTU). > > Similarly, by “opstate-unaware tree”, I meant the YANG module would have > both top-level /foo and /foo-state trees. Essentially, what we have today, > which we’re trying to get away from. > > > > The point of this work is that the opstate tree goes away and is > replaced by > > a protocol operation instead. > > Correct, the hope is that the top-level /foo-state tree no longer needs to > be defined in YANG modules. This is the goal as we believe it will make > YANG modules easier to read and write. > > > > In fact, there are no new datastores needed whatsoever to > > add the RPC <resource-ready>, or even <get-operational>. > > I’m not sure what you mean by RPC <resource-ready>. True, a > <get-operational> RPC could be defined now, but we’d still want the YANG > modules to be a certain way and we’d still want to define a conceptual > operational-state datastore so that we could describe it unambiguously. > > I could have an RPC that tested a config subtree. It would return 'true' if intended=applied for that subtree. I agree it is good to have clear definitions that are widely understood. It would be nice to have any clear definition of config=false YANG nodes, whether datastores are used or not. (e.g., does operational state include counters?) > Kent // as a contributor > > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
