Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

Robert Wilton <rwilton@cisco.com> Tue, 13 November 2018 10:58 UTC

Return-Path: <rwilton@cisco.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 0AB191286E7; Tue, 13 Nov 2018 02:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 xO_k3RSxTdxk; Tue, 13 Nov 2018 02:58:30 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9BF126DBF; Tue, 13 Nov 2018 02:58:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3485; q=dns/txt; s=iport; t=1542106709; x=1543316309; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=W5+e4bvPtRhqCif7zOhSN0hMtmHkz0v5JtR0fdRHcbA=; b=IxYAMt1li0ubPSqfI8s8Q2u/S4ZVlQ2L2AbkQK9EGBZINIL4AVKXwAQJ LAsBgj9xgUtaanwj4kLio0kloNbeigAgt3kcHQhQZkPkC4VmoU6ERuCxS COlm3kXzFfvrZuJLiA9eY+lSWQWObs9vrT++skk+F6g3vuQFhC1mCmCvg I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAAD1rOpb/xbLJq1iGgEBAQEBAgEBAQEHAgEBAQGBUgQBAQEBCwGCaXASJ4N4iHeNBCWXNYF6DRgNhAFGAoNVNQwNAQMBAQIBAQJtHAyFOwEBBAEBIQ8BBTYbCxgCAiYCAicwBgEMBgIBAYMdAYIBD6dOgS+FQIRoBYELiw2BQD+BEScMgWF+gxsBAQIBF4EhgyqCVwKKfYQIkFEJhneKJQYYgViIACaGdYFOi1qDfIZZgUUCNIFVMxoIGxU7gmyCLBKIXoU+PwMwAYtigkwBAQ
X-IronPort-AV: E=Sophos;i="5.54,498,1534809600"; d="scan'208";a="8014511"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 10:58:27 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wADAwQcD003141; Tue, 13 Nov 2018 10:58:26 GMT
To: joel jaeggli <joelja@gmail.com>, NETMOD Working Group <netmod@ietf.org>, draft-ietf-netmod-module-tags.authors@ietf.org
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <c6d24aae-267e-1b0e-0602-7e9d2e9d3961@cisco.com>
Date: Tue, 13 Nov 2018 10:58:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hmgVasbGgTe1ggYFf215TZzfcPc>
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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: Tue, 13 Nov 2018 10:58:32 -0000

Hi Joel, authors,

I have to confess that I didn't have time to review this during the last 
call (but have reviewed/provided comments on previous versions).

These comments may be too late, but I will provide them anyway, so make 
of them what you will :-)

In summary, I like the idea of tags and I think that they are a good fit 
for classifying YANG models.  In particular, I think that a flexible 
classification of YANG modules is better than a rigid structure that can 
never be changed.

For me the one of the great utilities of module tags could be in 
applications like YANG catalog search 
(https://yangcatalog.org/yang-search/).  Being able to search for 
modules by tag seems like it would be a particularly useful thing to be 
able to do.

However, I do have some sympathy with Alex's comment, in that it is a 
bit unclear as to benefits of configuring the tag information on the 
devices.  At the moment, the configuration doesn't have any material 
affect on the device, and the only thing that a client can do is read 
back the tag configuration.  Is the intention that the protocols may be 
extended in future to allow filter queries to be based on module tags?

So, I am supportive of Alex's comment that it would give the document 
more clarity if some of the specific use cases could be described.


Some other random comments/nits:

1) 6087bis references can be updated to RFC 8407.  Is a reference even 
allowed in the abstract?

2) Abstract: "writing a modules tags" => "writing a module's tags" or 
"writing module tags"

3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.

4) Section 3.4: Should there be a tag prefix for "experimental"? Or 
perhaps this would be "ietf:experimental:<tag-name>" anyway.

5) Section 5.1: It might be useful if the tags were also reported under 
YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this would 
report the same information as "modules-tags/module[name]/tag" leaf-list.

6) YANG module: Should you limit the maximum size of a tag? Perhaps to 
255, or 1000 characters.

7) Line length for "The operational view of this list is constructed 
..." looks like it may be too long.

8) Section 7, Guidelines to authors.  I was wondering if this section 
should state that YANG modules SHOULD define standard tags that are 
associated with it.  At the moment, it just states what can be done, 
without providing guidance of what should be done.

9) Section 9.2.  A few more possible categories: discovery protocol, 
vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a 
module name, and possibly "classification-" would be better.

Apologies for the tardy review comments,
Rob


On 12/11/2018 16:46, joel jaeggli wrote:
> During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags which addresses comments and concerns raised during the WGLC. In the meeting there were none. This commences a comment period to confirm that call. As this follows closely on the heels of the IETF 103 meeting we’ll let the call run through Monday the 26th of November.
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
>
>
> Thanks
> Joel
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod