Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04

Rohit R Ranade <> Mon, 18 February 2019 02:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B1CD130EB1; Sun, 17 Feb 2019 18:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G0fMnGbjukVO; Sun, 17 Feb 2019 18:57:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24365130EB0; Sun, 17 Feb 2019 18:57:44 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 4E71AAE9D674CD3C844F; Mon, 18 Feb 2019 02:57:42 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Feb 2019 02:57:41 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Mon, 18 Feb 2019 10:57:30 +0800
From: Rohit R Ranade <>
To: Christian Hopps <>
CC: Joel Jaeggli <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04
Thread-Index: AQHUxWBST4whJ9bV6kO/PWNMC6m5PKXk2PSg
Date: Mon, 18 Feb 2019 02:57:30 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Feb 2019 02:57:46 -0000


Thank you for accepting the comments. Few more comments from my side.

1. Section 8.1, " could allocate a top level prefix ", I think there is no concept of top-level prefix now. I think this is a remnant of the versions posted earlier where you had examples of multiple prefixes in a tag. Can be removed now I think.

2. Why should the prefix contain ietf: , vendor:, user: ?  I think the second part of the prefix is more important for classification because most of the vendors / sdo already define their own prefixes for their module-name based on RFC7950 guideline in Section 5.1. By adding the prefix, I feel it will reduce the re-usability by other SDO / vendors.

3. Consider we have defined a module example-bgp which is similar to ietf-bgp.
If we need to add tags to example-bgp, then we need to define new "vendor:" prefixes for this even if it uses some IETF protocols ? 
I think we need to add more clarity in this document as to when the "ietf:" prefix can be used by a module ? Whether a vendor module can/cannot use standard tags ?   
Consider a module which has some part of vendor and some part of IETF protocol , whether vendor can use "ietf:" tags then ?
I suggest adding one more example in this document which may indicate/clarify your stand regarding this point.

4. By defining a module tag as an extension, there is no way to validate this extension's argument during YANG compilation (even though a pattern is defined). The existing YANG compiler tools will be forced to do hard-coding for this. Whether there should be a note to Yang Compiler Developers in this document for clarity ? 

Please not that all these points originated in my mind, by thinking as to how I will use these tags. On the whole, I like the idea and thank you and the co-authors for documenting this.

With Regards,
Rohit R

-----Original Message-----
From: Christian Hopps [] 
Sent: 16 February 2019 00:27
To: Rohit R Ranade <>
Cc: Christian Hopps <>; Joel Jaeggli <>;;;;
Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04

> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade <> wrote:
> Editorial Comments:
> 1.  Section 1, refers to RFC6020 for Yang Module, but since this 
> document uses Yang Version 1.1, I feel it should refer to RFC7950 2.  Section 4.3, " removed with using normal configuration", can use "removed by using normal configuration"


> 3.  Description of statement "leaf-list tag", in the Step 1), " System added tags are added" can be replaced with "tags of 'system' origin are added" as it associates System with "system" origin in a better way.

Adopted with modification. Trying to keep things more readable but still well specified.

           1) System tags (i.e., tags of 'system' origin) are added.
           2) User configured tags (i.e., tags of 'intended' origin)
           are added.
           3) Any tag that is equal to a masked-tag is removed.";

> 4.  Description of statement "leaf-list tag", " The operational view of this list", can be replaced with "The applied configuration of this list", as it uses is a well-known term from RFC 8342.

           The 'operational' state [RFC8342] view of this list is
           constructed using the following steps:

> 5.  Description of statement "leaf-list tag", " User configured tags" 
> can be replaced with "tags of 'intended' origin" as it uses a 
> well-known NMDA term from RFC8342

Adopted with mod, See above.

> Technical:
> 1. Section 4.2, "These tags may be standard or vendor specific tags".  Does this statement exclude other tags from being added by implementations ? If it does not exclude, I feel this statement can be removed.

Going to leave this, standard tags and vendor tags are tags with a specific prefix.

> 2. In the description of Yang statement "leaf-list tag", is there any reason why System tags should be added first and then User configured tags ? Not clear.

This is just the way it worked out on the mailing list. Doesn't hurt to specify an order.

> 3. Description of statement "leaf-list masked-tag", " This user can remove (mask) tags", I think we need to clarify that it will not "apply" the tags which have been configured as "masked-tags", because they are not "removed" from any configuration datastore.
> The tags which have been masked will be present in <intended>, but will not be present in <operational>.
> Suggested description
> " The list of tags that will not be applied to this module. By adding 
> tags to this list, the user can prevent such tags from being applied. 
> It is not an error to add tags to this list that are not associated 
> with the module."

I'm not sure about making these changes. I think the current text (with the modification below) is pretty clear in what is meant, and delving so deeply into NMDA gets distracting, and could in fact end up being wrong (e.g., I think of tags being associated with a module not applied to them).

 I did make the change to the enumerated list to show what is meant by "System" and "User", and in the spirit of your suggestion, I did change it to be more specific about operational state datastore.

          "The list of tags that should not be associated with this
           module. The user can remove (mask) tags from the
           operational state datastore [RFC8342] by adding them to
           this list. It is not an error to add tags to this list
           that are not associated with the module, but they have no
           operational effect.";

Thanks for the review!


> With Regards,
> Rohit R
> -----Original Message-----
> From: netmod [] On Behalf Of Joel 
> Jaeggli
> Sent: 13 February 2019 05:20
> To:
> Cc:; Joel Jaeggli <>; 
> Subject: [netmod] Publication has been requested for 
> draft-ietf-netmod-module-tags-04
> Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as Proposed Standard on behalf of the NETMOD working group.
> Please verify the document's state at 
> _______________________________________________
> netmod mailing list
> _______________________________________________
> netmod mailing list