> 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 ;) > 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. > 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. Kent // as a contributor _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
