> On Jul 28, 2017, at 3:34 AM, Robert Wilton <rwil...@cisco.com> wrote: > > Hi Lada, > > > On 26/07/2017 11:46, Ladislav Lhotka wrote: >> "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com >> <mailto:jason.ste...@nokia.com>> 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. > It is perhaps worth noting that the proposed NMDA YANG library allows for > different features to be expressed in different datastores. Not that I am > actually suggesting that this would be a good solution here. > >> >> 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. > I agree that you cannot align config and state schema values in all cases. > However, I think that in the vast majority of cases there is close alignment > between the configured value, and what the system is using. Optimizing for > this common case should make management systems simpler for the mainline > cases. There will always be some exceptions, but that is OK too.
Is this true for if-feature statement only? What happens if I have a ‘must' statement that is written for validating configuration? Will it be enforced on operational datastore? > > For the router-id, I think that my preferred solution would be to: > Define the "configurable-router-id" feature, have a single router-id leaf, > then put in the description that it is only configurable if the > "configurable-router-id" feature is enabled. > > Possibly, in future, we could extend the YANG language to allow if-feature to > be conditionally applied to only config true or config false elements. > > An alternative solution, that works today, is to just have 2 separate, but > co-located, leaves: > 1) cfg-router-id, config true, conditional on if-feature. > 2) router-id, config false, operational. > - In the future, we could define a YANG extension to bind the config and > state leaves together in the model (e.g. a related-config statement). But I > think that we should see how often this issue turns up in practice before we > jump to doing this. > > Thanks, > Rob > >> Lada >> >>> Jason >>> >>> From: Kent Watsen [mailto:kwat...@juniper.net] >>> Sent: Monday, July 24, 2017 20:53 >>> To: Acee Lindem (acee) <a...@cisco.com>; Sterne, Jason (Nokia - CA/Ottawa) >>> <jason.ste...@nokia.com>; netmod@ietf.org >>> 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)" >>> <netmod-boun...@ietf.org >>> <mailto:netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org >>> <mailto:netmod-boun...@ietf.org>> on behalf of a...@cisco.com >>> <mailto:a...@cisco.com><mailto:a...@cisco.com <mailto:a...@cisco.com>>> >>> wrote: >>> >>> Hi Jason, >>> >>> From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com >>> <mailto:jason.ste...@nokia.com><mailto:jason.ste...@nokia.com >>> <mailto:jason.ste...@nokia.com>>> >>> Date: Monday, July 24, 2017 at 4:32 PM >>> To: Acee Lindem <a...@cisco.com >>> <mailto:a...@cisco.com><mailto:a...@cisco.com <mailto:a...@cisco.com>>>, >>> "netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org >>> <mailto:netmod@ietf.org>>" <netmod@ietf.org >>> <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>>> >>> 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:a...@cisco.com <mailto:a...@cisco.com>] >>> Sent: Monday, July 24, 2017 16:22 >>> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com >>> <mailto:jason.ste...@nokia.com><mailto:jason.ste...@nokia.com >>> <mailto:jason.ste...@nokia.com>>>; netmod@ietf.org >>> <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>> >>> Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state >>> >>> Hi Jason, >>> >>> From: netmod <netmod-boun...@ietf.org >>> <mailto:netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org >>> <mailto:netmod-boun...@ietf.org>>> on behalf of "Sterne, Jason (Nokia - >>> CA/Ottawa)" <jason.ste...@nokia.com >>> <mailto:jason.ste...@nokia.com><mailto:jason.ste...@nokia.com >>> <mailto:jason.ste...@nokia.com>>> >>> Date: Monday, July 17, 2017 at 6:22 AM >>> To: "netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org >>> <mailto:netmod@ietf.org>>" <netmod@ietf.org >>> <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>>> >>> 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 >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
