Kent/WG, This seems a bit terse to me and not provide needed guidance during the current transition period. I understood the discussion ended up with the options being to either (1) provide the guidance as a standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a pointer to it from 6087bis or (2) just move those sections to 6087 bis. Either way, we'll need a new bis once the full NMDA solution makes it to publication (request).
I thought the plan was to do (s). If so, we need the full text. Looking at the current repo (https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt) it would be: 4.23 Operational Data The following guidelines are meant to help modelers develop YANG models that will maximize the utility of the model with both current implementations and NMDA-capable implementations [draft-ietf-netmod-revised-datastores]. (a) New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible. (b) Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. A non-NMDA version of these models SHOULD exist, either an existing model or a model created either by hand or with suitable tools that mirror the current modeling strategies. Both the NMDA and the non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in a non-normative appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. (c) For published models, the model should be republished with an NMDA-compatible structure, deprecating non-NMDA constructs. For example, the "ietf-interfaces" model in ^RFC7223^ will be restructured as an NMDA-compatible model. The "/interfaces-state" hierarchy will be marked "status deprecated". Models that mark their "/foo-state" hierarchy with "status deprecated" will allow NMDA-capable implementations to avoid the cost of duplicating the state nodes, while enabling non-NMDA-capable implementations to utilize them for access to the operational values. (d) For models that augment models which have not been structured with the NMDA, the modeler will have to consider the structure of the base model and the guidelines listed above. Where possible, such models should move to new revisions of the base model that are NMDA-compatible. When that is not possible, augmenting "state" containers SHOULD be avoided, with the expectation that the base model will be re-released with the state containers marked as deprecated. It is RECOMMENDED to augment only the "/foo" hierarchy of the base model. Where this recommendation cannot be followed, then any new "state" elements SHOULD be included in their own module. To create the temporary non-NMDA model from an NMDA model, the following steps can be taken: - Rename the module name by postpending "-state" to the original module's name - Change the namespace by postpending "-state" to the original namespace value - Change the prefix by postpending "-s" to the original prefix value - Set all top-level nodes to have a "config" statement of value "false" - add an import to the original module (e.g., for typedef definitions) - modify any imports, used for leafrefs or identityrefs, to import the -state version of the module - remove any 'typedef' or 'identity' definitions - prefix any uses of the typedefs and identities accordingly - update leafref and augment paths to use the new "-s" prefix For me (with any/all hats) the key downside is that we'll need to rev this text (again) in the not too distant future, but that we don't have an alternative as LC on the full solution is still a bit away. What do people think? Lou On 8/22/2017 3:53 PM, Kent Watsen wrote: > Hi, > > During the meeting in Chicago, the NMDA authors took an action to > propose some text for S4.23. After a little review, the following > emerged. Yes, it's short, but was anything left anything out? > > > =====START===== > > 4.23 Operational Data > > Operational data includes both config "false" nodes as well as, > on servers supporting <operational> [draft-ietf-netmod-revised-datastores], > the applied value of config "true" nodes. > > YANG modules SHOULD be designed assuming they will be used on > servers supporting <operational>. With this in mind, YANG > modules SHOULD define config "false" wherever they make sense > to the data model. Config "false" nodes SHOULD NOT be defined > to provide the operational value for configuration nodes, > except when the value space of a configured and operational > values may differ, in which case a distinct config "false" > node SHOULD be defined to hold the operational value for the > configured node. > > =====STOP===== > > > One question that came up is if "operational data" is a well-defined > term. This string appears 10 times in rfc6087bis. Most interestingly, > appendix Section A.8. (v05 to v06) includes this line item: > > Changed term "operational state" to "operational data" > > So it seems to be deliberate... > > > Kent // contributor > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
