Re: [netmod] rfc6087bis S4.23 replacement text

[Andy Bierman <[e-mail]>]

On Wed, Aug 23, 2017 at 2:19 PM, Lou Berger <[e-mail]> 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
> >> <[e-mail]> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>> --
> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >>>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>