[netmod] Review comments for module-tags-02

Rohit R Ranade <rohitrranade@huawei.com> Wed, 17 October 2018 04:10 UTC

Return-Path: <rohitrranade@huawei.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 1F0B612872C for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 21:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ZYA1y8unNDwh for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 21:10:10 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18242127B92 for <netmod@ietf.org>; Tue, 16 Oct 2018 21:10:10 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AFD99D80A640F for <netmod@ietf.org>; Wed, 17 Oct 2018 05:10:04 +0100 (IST)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 05:10:05 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0382.000; Wed, 17 Oct 2018 12:09:54 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Review comments for module-tags-02
Thread-Index: AdRlz2ZrcdhVQBKIRg2w21rqsHkwQQ==
Date: Wed, 17 Oct 2018 04:09:53 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BC65175dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cY3A_UgibnlZiuHS26Ze9qQFJ_Q>
Subject: [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 04:10:13 -0000

1. In the desrciption of leaf-list tag
  "
  The operational view of this list will contain all
             user-configured tags as well as any predefined tags that
             have not been masked by the user using the masked-tag leaf
             list below.
  "
  ==> So the predefined tags, should be output as <default> origin  in <operational> ?
  If so, I would suggest renaming them to "default" tags.

2. For "masked-tag", if the purpose is to only mask "predefined" tags, why not rename
as masked-default-tag or masked-predefined-tag ?
Also if a tag say tag-1 (not predefined) is added to this list, and tag-1 added to "tag", the tag-1
will still be output in <operational>, which may look confusing to the user as the tag-1 will exist
in both "tag" and "masked-tag". Changing the "masked-tag" may help in this case.

3.  It is still not clear, what is the use-case where user wants to "mask" a predefined tag.

4. What about already existing modules which donot define the tags, should they be output in the
  "module-tags" list ? Or better to use "min-elements" for leaf-list "tags" ?

5. I also agree with other reviewer's comment that this document must standardize what a module-tag must look like.
  Currently it only standardizes a prefix, if the rest of the tag is not standardized a client has no way to parse
  this tag.
  Maybe we can say that a tag will contain 3 parts, 1st part is about organization, 2nd part is about the whether it is service / element, 3rd part
  can be a sub-category of part-2.

With Regards,
Rohit R