On Fri, Aug 25, 2017 at 10:56 AM, Kent Watsen <[email protected]> wrote:
> > 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? > > Obviously NMDA cannot be used for objects where the configuration value set and the operstate value set differ, such as with the interface admin-status/oper-status. Do you want a sentence added that says to use config false leafs as needed within the configuration entry? A sentence that says operational data is embedded in the configuration entry? > 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... 6087bis was supposed to be a minor update, not a living draft that doubles as a YANG tutorial and ongoing issues list. > > K. // contributor > > > Andy > -- > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
