Hi Juergen, > Operational state often has a different lifetime than config. Hence,
Hmm..Could you please clarify the above a bit more? -- Cheers, Rajiv -----Original Message----- From: Juergen Schoenwaelder <[email protected]> Reply-To: Juergen Schoenwaelder <[email protected]> Date: Friday, April 1, 2016 at 5:02 AM To: Rajiv Asati <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! >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
