OK – so the same leaf (in the schema) has the same value space in the conventional datastores and in the operational datastore. That probably makes sense since a single schema describes the model for that leaf whether it is accessed in conventional DSes or the operational DS.
But I think that also means that *if* you need slightly different value spaces for an item, then you’ll need to split it into multiple leafs in the schema. Jason From: Kent Watsen [mailto:[email protected]] Sent: Monday, July 24, 2017 20:53 To: Acee Lindem (acee) <[email protected]>; Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; [email protected] Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state Related, revised-datastores-03#section-4.7 says: As a result of remnant configuration, the semantic constraints defined in the data model cannot be relied upon for <operational>, since the system may have remnant configuration whose constraints were valid with the previous configuration and that are not valid with the current configuration. Since constraints on "config false" nodes may refer to "config true" nodes, remnant configuration may force the violation of those constraints. The constraints that may not hold include "when", "must", "min-elements", and "max-elements". Note that syntactic constraints cannot be violated, including hierarchical organization, identifiers, and type-based constraints. The last sentence implies that the value-space must be the same between nodes in <operational> and the conventional datastores. Kent // contributor On 7/24/17, 4:35 PM, "netmod on behalf of Acee Lindem (acee)" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: Hi Jason, From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]<mailto:[email protected]>> Date: Monday, July 24, 2017 at 4:32 PM To: Acee Lindem <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [netmod] nmda-guidelines-01: value space for config vs state Hi Acee, OK – maybe this example isn’t the best. But in the general case my concern about using a super-set would be that it implies all those values are valid input values for an edit-config in the candidate/running. I can’t immediately see a clean way to indicate that some of the values aren’t valid for writing. Another possible approach we could use is that if the value space is different, then it means we should have separate leafs. The model designer could have 1 typedef for the common values (i.e. for applied/intended config), and then use a union with additional values for the state/operational leaf that supports the extra values. Right – if there additional values that the leaf can take, then it is probably pure operational state as opposed to applied config. Thanks, Acee Jason From: Acee Lindem (acee) [mailto:[email protected]] Sent: Monday, July 24, 2017 16:22 To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state Hi Jason, From: netmod <[email protected]<mailto:[email protected]>> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]<mailto:[email protected]>> Date: Monday, July 17, 2017 at 6:22 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [netmod] nmda-guidelines-01: value space for config vs state Hi all, A note in Rob Wilton’s presentation today in rtgwg mentioned something about consistency in the value space for config vs state leafs. The NMDA approach results in the same leaf for both config & state in many cases (at least for the cases where the separate config & state leafs were only there to represent intended vs applied config). But aren’t there some cases where the value space for state will be different than the value space for config ? I’m thinking of the basic admin/oper state for interfaces for example where config may allow enable/disable but state may have additional values like ‘testing’. If the config & state value spaces aren’t 100% the same, are module designers recommended to create a separate state leaf ? In this particular example, the leaf you are describing would be read-only system state as opposed to applied state. If there were such a leaf that could take on a wider range of values of applied state values than the intended state, I’d expect the value space would need to be the superset. Thanks, Acee Rgds, Jason
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
