Re: [netmod] Review comments for module-tags-02

[Vladimir Vassilev <[e-mail]>]

Hi,

Adding  -state modules to all new drafts seems like unnecessary 
overhead. Even mentioning NMDA in a draft that has no logical 
relationship to NMDA also seems like unnecessary overhead.

Not a great set of alternatives. The positive thing is that vendors that 
do not have to worry about existing applications should really have no 
problem responding to the pressure.

Vladimir

On 10/17/18 4:39 PM, Christian Hopps wrote:
> 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 <[e-mail]> 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:[e-mail]]
>>> Sent: 17 October 2018 18:18
>>> To: Rohit R Ranade <[e-mail]>
>>> Cc: Christian Hopps <[e-mail]>; [e-mail]
>>> 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:[e-mail]]
>>>> Sent: 17 October 2018 17:22
>>>> To: Rohit R Ranade <[e-mail]>
>>>> Cc: Christian Hopps <[e-mail]>; [e-mail]
>>>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>> -- 
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod