Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Andy Bierman <[e-mail]>]

On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <[e-mail]> 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