Re: [netmod] rfc6087bis S4.23 replacement text

[Lou Berger <[e-mail]>]

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.

Lou

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/>
>>>