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

Christian Hopps <> Fri, 15 February 2019 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A25751271FF; Fri, 15 Feb 2019 10:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WEK-ygSJ1fNJ; Fri, 15 Feb 2019 10:57:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E0C00124BAA; Fri, 15 Feb 2019 10:57:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id AC059604D0; Fri, 15 Feb 2019 13:57:29 -0500 (EST)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_74200E9E-C4A5-4964-B70E-847221EC9546"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 15 Feb 2019 13:57:28 -0500
In-Reply-To: <>
Cc: Christian Hopps <>, Joel Jaeggli <>, "" <>, "" <>, "" <>, "" <>
To: Rohit R Ranade <>
References: <>
X-Mailer: Apple Mail (2.3445.102.3)
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: Fri, 15 Feb 2019 18:57:34 -0000

> 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