"Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> writes:
> 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. This is easier said than done: will there be "foo" and "foo-state" as sibling leaves, both present in <operational>, as sec. 4.7 indicates? Apart from value space mismatch, there are other potential issues like the one that I mentioned in Prague: "if-feature" applies to configuration but not to state data. An example is in ietf-routing: in config, "router-id" leaf is only present if "router-id" feature is advertised (other servers derive router-id by other means), but in state data "router-id" does not depend on the feature. The assumption made in NMDA that config and state data schemas can be unified is IMO simply broken. YANG, being basically a document-oriented schema language, is not designed to support such tricks. Lada > > 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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
