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

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 31 Mar 2016 18:44:06 +0000

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