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

Robert Wilton <> Wed, 14 November 2018 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35BC712958B; Wed, 14 Nov 2018 09:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tMpHz80t_k8G; Wed, 14 Nov 2018 09:26:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 126C6128D09; Wed, 14 Nov 2018 09:26:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=34171; q=dns/txt; s=iport; t=1542216388; x=1543425988; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9N7IgNjRGbXPRc4E3X1+dGjZsE9Zpx8WgPuTfAdsrAE=; b=fvdLrN26otgJD+gxPhRBFO4wBI80KFHde2LJTbHlSZb2dcZbEwYckntd bK9OtY79aa/K9oBBbt6KMiBRWQ5CEO0yDmXHs9d3sUYIqzwjMW2ltPpNw iekl3ZtEgLTTWJLo1PZGzdn5QjDLTyrfnsLihUQbTRnbCBeWQnTmLLUTL A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABcWuxb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1IgRSBAieDeIgYX4x6LZc2FIFjAw0?= =?us-ascii?q?YAQyEAUYCg2s0DQ0BAwEBAgEBAm0cDIU6AQEBAQIBAQEYCUsLBQsLDgogCgI?= =?us-ascii?q?CJzAGDQYCAQEXgwYBgXkID6gAgS8fhSGEZQWMHIFAP4ERJ4FtfoMbAQECARe?= =?us-ascii?q?BIQ4CgxqCVwKIc1ADgTqECZBVCYZ3iiUGGIFYhQUFgncmhnaBToteg3yGWYF?= =?us-ascii?q?FOIFVMxoIGxU7gmyCJwUSiF6FPj8DMAGLOYJMAQE?=
X-IronPort-AV: E=Sophos;i="5.56,233,1539648000"; d="scan'208,217";a="7988807"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 17:26:23 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id wAEHQNc3016319; Wed, 14 Nov 2018 17:26:23 GMT
To: Christian Hopps <>
Cc: joel jaeggli <>, NETMOD Working Group <>,
References: <> <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Wed, 14 Nov 2018 17:26:22 +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: <>
Content-Type: multipart/alternative; boundary="------------C6D2721EE423D2D585CF3014"
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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: Wed, 14 Nov 2018 17:26:32 -0000

On 14/11/2018 16:43, Christian Hopps wrote:
>> On Nov 14, 2018, at 10:14 AM, Robert Wilton <> wrote:
>> Hi Chris,
>> On 14/11/2018 13:46, Christian Hopps wrote:
>>> Do you have similar objections over comments in CLI config files?
>> No, not at all.
>> But one difference here is that the tags are bound to modules, not to the config, or config paths.
> This has nothing to do with the point I am addressing that you and Alex raised regarding "Servers not using the tags so why should they store them".

My point was not that "servers shouldn't have to do this", but more "it 
is isn't obvious why operators want servers to do this".

> The answer is:
> 1) B/c there's literally no where else they could be stored (no way for a vendor to add tags)
> 2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place.
> Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things.

That is not what I was suggesting.

I was suggesting text something like this:



The use of tags for classification and organization is fairly ubiquitous 
not only within IETF protocols, but in the internet itself (e.g., 
#hashtags). Tags can be usefully standardized, but they can also serve 
as a non-standardized mechanism available for users to define 
themselves. Our solution provides for both cases allowing for the most 
flexibility. In particular, tags may be standardized as well as assigned 
during module definition; assigned by implementations; or dynamically 
defined and set by users.


The use of tags for classification and organization is fairly ubiquitous 
not only within IETF protocols, but in the internet itself (e.g., 
#hashtags). One benefit of using tags for organization over a rigid 
structure is that it is more flexible and can more easily adapt over 
time as technologies evolve. Tags can be usefully standardized, but they 
can also serve as a non-standardized mechanism available for users to 
define themselves. This document provides a mechanism to define tags and 
associate them with YANG modules in a flexible manner. In particular, 
tags may be standardized as well as assigned during module definition; 
assigned by implementations; or dynamically defined and set by users.

NEW: 1.1 Some example use cases of YANG module tags

Tags can be used to help filter different discrete categories of YANG 
modules supported by a device. E.g., if modules are suitably tagged, 
then an XPath query can be used to list all of the vendor modules 
supported by a device.

Tags can also be used to help coordination when multiple 
semi-independent clients are interacting with the same devices. E.g., 
one management client could mark that some modules should not be used 
because they have not been verified to behave correctly, so that other 
management clients avoid querying the data associated with those modules.

Tag classification is useful for users searching module repositories 
(e.g. YANG catalog). A query restricted to the 'ietf:routing' module tag 
could be used to return only the IETF YANG modules associated with 
routing. Without tags, a user would need to know the name of all the 
IETF routing protocol YANG modules.

Future management protocol extensions could allow for filtering queries 
of configuration or operational state on a server based on tags. E.g., 
return all operational state related to system-management.

If you think that this text is helpful, and it allowed, then please add 
it, refining as required.  If you think that it detracts from the 
clarify of document, and is superfluous then leave it out, that is also 
fine with me ...


> And maybe let's put this work on hold until we can find someone that is willing to do all that busy work.
> I understand more and more why openconfig exists.
> Thanks,
> Chris.
>>>   Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense?
>> Yes, perhaps.
>>> Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it.
>> Sorry, I had missed the WG discussion where this was removed. But OK.
>>>   I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it.
>> My apologies, but I had intended to review this more thoroughly during the WG LC but ran out of time.  If was when I read Alex's comments that I thought that he was raising some valid points. The key one that struck a chord is that this document describes a solution but doesn't seem to clearly describe what problem it is solving (other than tags are good), or how it is intending to be used.  When I reviewed this document after reading Alex's comments, I was asking myself how this was going to be used, and the answer I came up with was that I didn't really know.  Or the case that I had in mind (YANG catalog filtering on module tag) doesn't seem to match the authors envisaged use cases.  Looking back at some of the previous comments on this work (not just Alex), others have also questioned what problem it is solving and how it will be used.
>>> I'm OK with taking the editorial suggestions. I'm not so OK with going back and redoing this document or it's fundamental design at the tail end of a WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd given it seemed like we were done, including during the 103 meeting in which you were in attendance.
>>> You say your not trying to hold the work up; however, that is exactly what your last minute public pondering is doing.
>> Yes, I admit that I should have reviewed it earlier.  My aim is not to slow it down but to ensure that the document is as clear as possible.  As I've said lots of times, I like the idea of tags for classifying YANG modules :-)
>> Given all that, it is still my opinion that this document would benefit from the introduction being slightly clearer on the specific problem being solved - e.g. I think that the abstract is more clear than the introduction, and also think that the document would benefit having some examples of how module tags could be used.
>> But I appreciate that my comments are after the WGLC and have no issues if the authors/chairs decide that they are too late.  After all, no one else, other than Alex, has expressed any concern.
>> Thanks,
>> Rob
>>> Thanks,
>>> Chris.
>>>> On Nov 14, 2018, at 5:04 AM, Robert Wilton <> wrote:
>>>> Hi Chris,
>>>> On 13/11/2018 21:05, Christian Hopps wrote:
>>>>> The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module.
>>>> Clients should also be able to know find out the predefined tags from the module definition.  I agree that the any tags added by the implementation can only be known by querying the server, although its not obvious to me what those tags would be.  E.g. if Cisco had a YANG module for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag then it would ideally use the extension and put it in the YANG file.
>>>>> This is not what I thought would hold this work up.
>>>> Sorry, I'm not trying to hold anything up.
>>>> It not obvious to me how the ietf-module-tags modules will actually be used on a device:
>>>>   1) being able to ask a device: "What are all the YANG modules that are implemented on this device that are routing protocols" seems a useful thing to do.  Although personally I would ideally want the answer in the context of YANG library.  I.e. to see the modules with the given tags, along with module evision/version, features and any deviations.  This can probably be achieved today with an appropriate xpath query, if supported, or could perhaps be achieved more easily if the operational list of tags also augmented the module entries in the YANG library structure.  But perhaps for your envisaged use case just getting back the list of modules with that tag is sufficient and is what you are after.
>>>> Is this how you are envisaging YANG module tags would be used, and if so, would it do any harm to add a short section near the intro explaining this (and perhaps the YANG catalogue example as well)?  Or do you think that this would just be needless noise.
>>>> 2) Being able to filter queried data based on tags may also be useful, but this would require protocol extensions, perhaps something to be done in future?
>>>> Thanks,
>>>> Rob
>>>>> Thanks,
>>>>> Chris.
>>>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton <> wrote:
>>>>>> 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 (  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.
>>>>>>> Thanks
>>>>>>> Joel
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>> .
>>> .
> .