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

Vladimir Vassilev <vladimir@transpacket.com> Wed, 17 October 2018 17:39 UTC

Return-Path: <vladimir@transpacket.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01E130EDC for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 10:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8n-8KYHr5eq for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 10:39:55 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004E91293FB for <netmod@ietf.org>; Wed, 17 Oct 2018 10:39:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 809B7154169C; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wnB7G0EIGQWx; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5528E154169D; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7lDid9aCkwrF; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id F02D21541699; Wed, 17 Oct 2018 19:39:51 +0200 (CEST)
To: Christian Hopps <chopps@chopps.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: "netmod@ietf.org" <netmod@ietf.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com> <E9770126-7345-4E0F-B03A-08F22D2A867D@chopps.org> <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com> <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC65548@dggeml510-mbx.china.huawei.com> <20181017142307.h4sfqmxjjyzbeght@anna.jacobs.jacobs-university.de> <6EC0B63D-A4AF-4879-A9C2-842205DEBFF2@chopps.org>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <8d738b2b-268c-c117-99cc-ed5518252bb0@transpacket.com>
Date: Wed, 17 Oct 2018 19:39:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <6EC0B63D-A4AF-4879-A9C2-842205DEBFF2@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/w0hs0nTJ1ec1q6W9TQAu77EMioQ>
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2018 17:39:57 -0000

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 <j.schoenwaelder@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.schoenwaelder@jacobs-university.de]
>>> Sent: 17 October 2018 18:18
>>> To: Rohit R Ranade <rohitrranade@huawei.com>;
>>> Cc: Christian Hopps <chopps@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.schoenwaelder@jacobs-university.de]
>>>> Sent: 17 October 2018 17:22
>>>> To: Rohit R Ranade <rohitrranade@huawei.com>;
>>>> Cc: Christian Hopps <chopps@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