Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !!

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 <j.schoenwaelder@jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Date: Friday, April 1, 2016 at 5:02 AM
To: Rajiv Asati <rajiva@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
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
>> netmod@ietf.org
>> 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/>