I believe that shortening tranistion pain is in the longer term better
than prociding tools that at the end just extend the transition pain.

/js

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

Reply via email to