Operational state often has a different lifetime than config. Hence, keeping config and operational state together in the same structure (with the same naming) causes you problems down the road.
/js On Thu, Mar 31, 2016 at 06:44:06PM +0000, Rajiv Asati (rajiva) wrote: > > While working on MPLS LDP yang model > (https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang), we noticed the > possible confusion around structuring intended config, applied config and > derived state *. > > On one hand, one may have 'intended-config’ (RW) and ‘applied-config’ (RO) in > the same construct (container), and ‘derived state’ (RO) in a separate > construct (container). > > This keeps config together, but doesn’t help operational state, which > requires > Both Applied-config and derived-state. > > On the other hand hand, one may have ‘intended-config’ in one construct > (container), and ‘applied-config’ and ‘derived state’ in a separate construct > (container). > > This simplifies figuring operational-state, but divides the config > types. > > There are pros & cons either way. It would be good to have some guidance/text > around guiding one over another, so that other models can leverage. > Otherwise, we are going to end up with yet one more discrepancy (among > various protocols YANG models), & confusing if not inefficient modeling. > > Perhaps, we ditch both of the above approaches, and settle on keeping all > three of them in the same construct. It might simplify the organization a > bit. Of course, that also has 2 options - have all the data types in > intended-config, and then in applied-config and then in derived-state. Or > have intended-config, applied-config and derived-state for each data type. > Latter might be slightly better, given that not every data type will have all > three. > > > Thoughts? > > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > > > * https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs > <https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04> > https://tools.ietf.org/html/draft-openconfig-netmod-opstate > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
