I have the same preference. The suggested text doesn't seem to provide actual modeling recommendations. Aren't there details beyond how or when a module transitions to NMDA that should be mentioned? For instance, the text doesn't say anything about how to best locate config false nodes, or how to handle the case when the value-space for a node's configured and operational values differ. Is the plan then to remove this section entirely once the NMDA-transition is complete?
As I recall, the main reason why we are not progressing the guidelines draft is because we didn't want the short-term text in an RFC. Putting essentially the same text into another RFC seems inconsistent. But, if this is what people want, I suppose it's better to churn this document than to introduce a distinct "guidelines" RFC... K. // contributor -- My preference is to have the guidelines say what people should do, namely design NMDA models. I would prefer to keep any transition aspects out of the guidelines. If people want to include transition aspects, it should be in the appendix (i.e., easy to remove / ignore later on). I understand that there is a timing issue. The question is what you mean with "NMDA solution makes it to publication (request)". If you mean the core NMDA document, this is pretty much in reach and keeping this guidelines document on hold until then may be an option. If you mean the complete solution set, including model updates and moving the protocol extensions in NETCONF to publication request, then this may take a bit more time. /js On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote: > 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 > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
