On Tue, Jan 10, 2017 at 3:54 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> I believe that shortening tranistion pain is in the longer term better
> than prociding tools that at the end just extend the transition pain.
>
>
That is a good goal, but ending up with a stable and useful solution
is more important.
The WG decided that an RPC-based solution was preferrred under the
assumption
that the data model design would not be impacted and existing YANG modules
could
report intended vs. actual values without any changes.
I certainly agree with Kent that real systems can override config values in
ways
that were not anticipated at module design-time. All the more reason for
an RPC-based solution.
I am willing to accept the design team output as the architectural model.
I liked Phil's approach -- identify all the state transitions and decide
which
ones need to be exposed in the standard. I don't see how tweaking this model
will have any impact on the transition pain of the solution path.
Until the basic show-stoppers are solved, the redundant opstate objects are
not important.
Removing the foo-state objects means they are now invisible wrt/ YANG
constraints
(must, when, leafref, min/max, etc). IMO this is a show-shopper. YANG can
only cross-reference
YANG statements. Invisible opstate hiding behind a datastore label seems
elegant
wrt/ <get>, but it looks like a disaster wrt/ YANG.
/js
>
Andy
>
> On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen 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?
> >
> >
> >
> > Kent // as a contributor
> >
> >
>
> > _______________________________________________
> > Netconf mailing list
> > netc...@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
