On Tue, Jan 10, 2017 at 11:08 AM, Kent Watsen <kwat...@juniper.net> wrote:
> I think that there may be a better way here: The data modelers design the
> model on the assumption that an operational state datastore will be
> present. We can then use a pyang plugin to generate an extra YANG model
> that contains the missing state leaves that would be required for the split
> config/state trees. E.g. if it finds a config leaf in foo/speed it creates
> a module that contains foo-state/speed. I've been playing around with
> pyang and I don't think that this would be too hard to do.
>
>
>
> I generally support this approach as stop-gap solution while the industry
> goes thru the transition. However, I recommend a variant whereby the pyang
> plugin only migrates the config false values (not also the config true
> values). The reason for this is as follows:
>
>
>
> Migrating only the config false values is sufficient for matching existing
> functionality (read: a must-have requirement); that is, currently top-level
> /foo-state is used to support conveying the opstate for system-generated
> objects, that have lifetimes independent of config.
>
>
>
> Migrating the config true nodes also is possible, but only needed if
> wanting to report the opstate value for config true nodes (e.g., hostname),
> but this would be above and beyond what is possible today (read: a
> nice-to-have requirement), and hence I’d rather steer folks towards the new
> approach rather than double-down on the approach we’re trying to get away
> from.
>
>
>
>
>
>
>
> > This is a real hack.
>
> >
>
> > I liked the if-feature approach much better
>
> > e.g.
>
> >
>
> > leaf oper-speed {
>
> > if-feature "not operational-datastore";
>
> > ...
>
> > }
>
>
>
> Is your proposal for the YANG modules to simultaneously define both
> opstate-aware and opstate-unaware trees? Wouldn’t that make the modules
> less readable, largely redundant, and ripe for inconsistencies?
>
>
>
>
>
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.
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).
What is an "opstate-aware tree".
The point of this work is that the opstate tree goes away and is replaced by
a protocol operation instead.
In fact, there are no new datastores needed whatsoever to
add the RPC <resource-ready>, or even <get-operational>.
>
> Kent // as a contributor
>
>
>
>
>
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
