On Wed, Aug 23, 2017 at 2:19 PM, Lou Berger <[email protected]> wrote:
> My view is wikis are fine for folks "in the know" but RFCs are good for > the wide distribution of interoperability standards and information > related to their implementation. > > It seems to me that this is a case of the latter. > > Oh, RFCS are also sometimes used to ensure community consensus on IETF > operation. > > This work item is over 3 1/2 years old already. The feature-creep just doesn't end. > Lou > Andy > > On 8/23/2017 12:38 PM, Kent Watsen wrote: > > 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 > >> <[email protected]> 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 > >>>>> [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
