I'll chime in as an operator here, I do not feel there is a need to support 
non-NMDA implementations with this brand new work that won't be finished let 
alone start being used for another so many months (at best). There's nothing 
wrong with simply requiring NMDA for various modules going forward. Indeed I'd 
like more modules to require NMDA if only to add pressure to get it deployed by 
vendors.

Thanks,
Chris.

> On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder 
> <j.schoenwael...@jacobs-university.de> wrote:
> 
> The WG needs to agree whether a -state module in the Appendix is
> needed. I just commented on the proposal to add a subtree, which
> violates the guidelines.
> 
> /js
> 
> On Wed, Oct 17, 2018 at 01:13:06PM +0000, Rohit R Ranade wrote:
>> Either defining a new module in an Appendix or a subtree, I am OK with 
>> either and both of us concur that the draft needs the changes.
>> 
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
>> Sent: 17 October 2018 18:18
>> To: Rohit R Ranade <rohitrran...@huawei.com>
>> Cc: Christian Hopps <cho...@chopps.org>; netmod@ietf.org
>> Subject: Re: [netmod] Review comments for module-tags-02
>> 
>> Obviously, this is now a slightly different statement. There are NMDA 
>> transition guidelines that have been discussed at length and finally been 
>> integated into
>> 
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3
>> 
>> This section 4.23.3 says under case (a):
>> 
>>   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.
>> 
>> In other words, you do not pollute a new NMDA module with non-NMDA subtrees 
>> but instead you create an additional module that goes into an appendix and 
>> is only relevant for transition purposes. I think Rob created tools to 
>> generate such things. Section 4.23.3.1 also provides some guidelines for 
>> creating temporary non NMDA modules.
>> 
>> /js
>> 
>> On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
>>> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, 
>>> then we will need this separate subtree to show the system defined tags.
>>> 
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder 
>>> [mailto:j.schoenwael...@jacobs-university.de]
>>> Sent: 17 October 2018 17:22
>>> To: Rohit R Ranade <rohitrran...@huawei.com>
>>> Cc: Christian Hopps <cho...@chopps.org>; netmod@ietf.org
>>> Subject: Re: [netmod] Review comments for module-tags-02
>>> 
>>> On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
>>> 
>>>> I think we need to define a subtree for non-NMDA clients to get the 
>>>> operational tags.
>>> 
>>> It is not much of a change for a _client_ to read a different datastore 
>>> hence I do not think this is needed.
>>> 
>>> /js
>>> 
>>> -- 
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103         <https://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         <https://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         <https://www.jacobs-university.de/>
> 

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to