Just wondering, but is an RFC the appropriate vehicle for this content? Would a wiki be better?
K. -- Lets do it this way then. If we plan to revise this again in ~1 year, so be it. We started this revision in Feb 2014. ;-) /js On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote: > Juergen, > > > On August 23, 2017 2:17:43 AM Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > > 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. > > Well, this approach works for those who are deeply enmeshed in netmod > and the IETF, it doesn't help those designing models/solutions during > the current transition period. IMO we can't forget about this important > class of model developers and users. > > > If people want to include transition > > aspects, it should be in the appendix (i.e., easy to remove / ignore > > later on). > > > I don't see a material difference here. Either way the document needs > to be updated. See below for a specific proposed wording update. > > > 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. > > > I mean the time when implementors can reasonably be told that the old > way has been replaced by a fully defined (and able to be implemented) > NMDA solution. I think includes both netconf and restconf NMDA > definitions. I don't think it's reasonable to require implementation of > drafts that are in-flux. > > > > > /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]. > >> > remove (a) and re-letter rest of list > >> (a) New models and models that are not concerned with the > >> operational state of configuration information SHOULD > >> immediately be structured to be NMDA-compatible. > > Add: > The remaining options MAY be followed during the time that > NMDA mechanisms are being defined. These options will be > removed in a future update of this document once this definition > is complete. > > Does this work for you? Moving it to an appendix just makes it harder > for the reader and, again, the document needs to be revised either way > in the future. > > Lou > > >> > >> (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/> > > > -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
