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

From: joel jaeggli <[email-masked]>
Date: Mon, 12 Nov 2018 08:46:17 -0800

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

---

From: Alex Campbell <[email-masked]>
Date: Mon, 12 Nov 2018 23:36:55 +0000

Hi,

I was not at the IETF meeting unfortunately.

I see that the technical issues raised in the WGLC have been fixed, which is good.

However I still have reservations about the utility of the proposed standard. It seems to me like a solution in search of a problem, and I can't understand why it should be pushed forward to an RFC. Maybe there is some context I am missing. The use-cases that have been described to me so far seem like they would be better served by a client-side mechanism. Perhaps the client-side data store can still be modelled in YANG, but in that case, I think the document should say so.

I asked why the server should hold the data. The reason I am given is "so that clients can read it." Why is the data not on the client in the first place?
The client can make modifications to the data, so that the client can read it back later. Why does the client need to store these modifications outside of itself?

I am told this is a general-purpose tool. In that case, I would like to see at least two or three separate use-cases so that I can be sure this is actually a *useful general-purpose abstraction*, and not something specific to the one (or zero!) use-cases the authors seem to envision. I am aware that the cost of creating bad standards can be quite high, if the next person who wants some YANG module metadata feels obligated to use the existing tag mechanism instead of something new, but finds it doesn't quite fit their needs. See also https://blog.codinghorror.com/rule-of-three/ and https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

I think the draft could also do with describing how this module is supposed to be used. A YANG module in isolation means nothing. Most of the YANG modules I am familiar with are to define configuration and/or state data to be stored on a network element or a provisioning/orchestration system, and accessed over NETCONF. I believe it is implicit that unless otherwise specified, YANG modules are intended for NETCONF use, but I am unclear on which kinds of NETCONF servers should implement this module.

Perhaps my opinion also carries less weight, as someone who's only on the mailing list and didn't actually attend the IETF meeting.

________________________________________
From: netmod <[email-masked]> on behalf of joel jaeggli <[email-masked]>
Sent: Tuesday, 13 November 2018 5:46 a.m.
To: NETMOD Working Group
Subject: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

Thanks
Joel
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: joel jaeggli <[email-masked]>
Date: Mon, 12 Nov 2018 16:02:56 -0800

> On Nov 12, 2018, at 15:36, Alex Campbell <[email-masked]> wrote:
> 

So, the reason we take the discussion back to the list is precisely to insure that we capture the opinions of those not present in the working group meeting. I think that is a point to be addressed separately from the question of whether the document is ready to go or not.

Thanks
Joel

---

From: Robert Wilton <[email-masked]>
Date: Tue, 13 Nov 2018 10:58:25 +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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 13 Nov 2018 16:05:11 -0500

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.

This is not what I thought would hold this work up.

Thanks,
Chris.

> On Nov 13, 2018, at 5:58 AM, Robert Wilton <[email-masked]> 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 (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.
> 
> 
> 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"
> 
> 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.
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Nov 2018 10:04:34 +0000

Hi Chris,

> 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 impleme…

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

> .

---

From: Christian Hopps <[email-masked]>
Date: Wed, 14 Nov 2018 08:46:01 -0500

Do you have similar objections over comments in CLI config files? 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?

Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it. 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.

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.

Thanks,
Chris.

> On Nov 14, 2018, at 5:04 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Chris,
> 
> 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.
> 
> 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.
>>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Nov 2018 15:14:19 +0000

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.

>   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.

> 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

---

From: Christian Hopps <[email-masked]>
Date: Wed, 14 Nov 2018 11:43:59 -0500

> On Nov 14, 2018, at 10:14 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Chris,
> 
> 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".

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.

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.

> 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.
> 
> 
> 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.
>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Nov 2018 09:00:38 -0800

Hi,

I think there are some legitimate issues that should be addressed for this
work to go forward
wrt/ how it will be used.

1) IANA registry: is this really needed at all? Doesn't the module-tag
extension
make the registry unnecessary?

2) Standard solution: will there be one or is the intent to have
proprietary solutions
to actually utilize module-tags?

3) If there is going to be a standard protocol solution to use module-tags,
then is it
really wise to nail down the tag format before starting work on mechanisms
that use
module tags?

4) How do I distinguish openconfig from mef from bbf from my router vendor?
All their tags seem to share the same prefix "vendor:"  What if I want to
match all routing modules? Then the prefix actually gets in the way because
I have to specify 3 tags ("ietf:routing", "vendor:routing" and
"user:routing")

5) Who decides what module tags apply to a new IETF YANG module?
Is it each independent WG? A design team? The IESG? What guidelines exist
for reviewers to determine if the correct module tags have been assigned?

I do not agree this work is being held up because there is no way to use
a module-tag with any standard protocols.

Andy

On Wed, Nov 14, 2018 at 8:44 AM Christian Hopps <[email-masked]> wrote:

> 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".
>
> The answer is:
>
> 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.
>
> >>  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.
> >
> >>  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.
> >
> 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.
> >
> 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 :-)
> >
> from the introduction being slightly clearer on the specific problem being
> solved - e.g. I think that the abstract is more clear than the
> >>>> 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.
> 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.
> >>>
> >>>  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
> 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.
> >>>
> 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.
> >>>
> but this would require protocol extensions, perhaps something to be done in
> future?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>>> Thanks,
> >>>> Chris.
> >>>>
> >>>>> 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).
> >>>>>
> >>>>> 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
> 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.
> >>>>>
> >>>>>
> >>>>> 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
> >>>>> 8) Section 7, Guidelines to authors.  I was wondering if this
> section should state that YANG modules SHOULD define standard tags that are
> vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a module
> name, and possibly "classification-" would be better.
> >>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Nov 2018 17:26:22 +0000

> 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".

> 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:

Introduction:

OLD:

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.

NEW:

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 ...

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Fri, 16 Nov 2018 00:54:22 +0000

> cannot come from anywhere *but* the server that implements the module.

Predefined tags from the implementer only needs to come from the 
implementor.  Whether it is provided by the server itself or via
some out-of-band mechanism (e.g., module catalog) seems to be the
question.

Of course, one might say that user-tags must be provided by the 
server itself, in order to provide an inter-client communication 
mechanism of some sort, as otherwise a single client, even if 
distributed, could keep the user-tags in its local database.

Though this begs the question, would it be better for the clients
to use a centralized service of some sort (perhaps within the
deployment's infrastructure, assuming the user-tags are private)
to have user-tags once per module, rather than (redundantly?) on
each server, thus ensuring consistency as well as avoiding 
potential race conditions?  Or are these user-tags truly 
server-specific (not just module-specific)?

Is it accurate to assume that two servers running identical 
software would have identical user-tags?  Of course, the servers
might be running different software (either different releases
for the same hardware, or different hardware, potentially from
different vendors).  Accommodating such would complicate the
construction of a centralized module-tagging service, though
it could still be done.

I suppose that the value of this document is not in any one of
the use-cases, as they each seem minor and having alternate 
(potentially better) workarounds, but in the multitude of them
all, and how a single mechanism can help.

> This is not what I thought would hold this work up.

My experience is that Last Calls tend to drive people to question
basics again.  By example, it's rather common for a draft's title
to change during a Last Call.  That said, this suitability question
has been lingering since the day Joel kicked off the Adoption Call,
that it is still with us seems to be the problem.

Kent // contributor

---

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Nov 2018 21:57:16 -0500

So I would now have a new tags server to store tags associated with the modules for each of my actual servers in my network?

This seems a bit convoluted to me, and I haven’t heard anyone say what the problem is with the servers storing the tags associated with their modules, there are obvious problems (that you highlight) with the servers *not* storing the tags.

I think this is a rather simple thing we’ve proposed, and the server is the seemingly natural/simple place to do it.

I think it would be good to get some justification for *not* having the server store tags for it’s own modules.

Thanks,
Chris.

> On Nov 15, 2018, at 19:54, Kent Watsen <[email-masked]> wrote:
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Nov 2018 19:23:01 -0800

On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps <[email-masked]> wrote:

> So I would now have a new tags server to store tags associated with the
> modules for each of my actual servers in my network?
>
> This seems a bit convoluted to me, and I haven’t heard anyone say what the
> problem is with the servers storing the tags associated with their modules,
> there are obvious problems (that you highlight) with the servers *not*
> storing the tags.
>
> I think this is a rather simple thing we’ve proposed, and the server is
> the seemingly natural/simple place to do it.
>
+1 to all.
Hopefully, the standard and vendor tags automatically installed by the
server are good enough,
but if not, then the user can configure tags as well.

It would be good to get away from complex data silos in the client, or a
mega-tags-server
that does the same thing. The tag mappings could get complex and keeping
them in the config
on each server seems the easiest to manage,

Thanks,

Andy

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 16 Nov 2018 11:51:27 +0700

+1 Christian 

Regards,
Jeff

> On Nov 16, 2018, at 10:23, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> Hopefully, the standard and vendor tags automatically installed by the server are good enough,
> It would be good to get away from complex data silos in the client, or a mega-tags-server
> that does the same thing. The tag mappings could get complex and keeping them in the config

---

From: Robert Wilton <[email-masked]>
Date: Fri, 16 Nov 2018 10:00:49 +0000

> some out-of-band mechanism (e.g., module catalog) seems to be the

I wasn't trying to argue that tags shouldn't be on the server.  I was 
just trying to say that the reason for doing so wasn't immediately 
intuitive to me from reading the draft.  In particular, I hadn't 
considered the use case of multiple clients coordinating via the tag 
information in the server config/state that Chris suggested.  I can see 
that having one client store the tag information on the server may make 
it a lot easier to code a different client (that might be monitoring 
devices for consistency).  E.g. client B only fetch the data for modules 
marked with a tag set by client A.

For the catalog use case, I wasn't particularly suggesting that tooling 
needs to pull tags from a catalog, although I have no issues with that.  
It was more my observation that once we start classifying modules using 
tags then an obvious use case (at least to me ;-) for that meta-data 
information is for humans to be able to search library repositories 
using tags.  E.g. in a similar way to how RPM repositories might be 
searched (https://rpmfind.net/linux/RPM/Groups.html).

I think that Chris is going to add some brief use case text to the 
draft.  With that addition, I have no further objections and I'm happy 
for document to progress.

Thanks,
Rob

---

From: joel jaeggli <[email-masked]>
Date: Thu, 22 Nov 2018 07:15:39 -0800

> 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 k…

So the backup slides I had for the talk basically asked if more proscriptive text was required on their use. Which is a bit different then working how they are to be used. 

The three cases of module tags, IETF, Vendor and User come from different sources. The IETF source comes with a demand for IETF consensus. The others do not. 

Ultimately I can imagine all sorts of user classification schemes that might emerge so my general conclusion that that any description should come in the form of guidance rather than proscription.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 22 Nov 2018 07:25:40 -0800

Something like the text below addresses the question of guidance. I think we get a better draft if we close off this discussion on the list.

I think the question about where the tags reside generally is settled.

Thanks
joel

> On Nov 14, 2018, at 09:26, Robert Wilton <[email-masked]> wrote:
> 
> 
>> 
>> The answer is:
>> 
>   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.
> 
> NEW:
> 
>   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
> 
>   (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 ... 
> 
> Thanks,
> Rob
> 
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 28 Nov 2018 10:47:18 -0800

This confirms the completion of this period.

I think we can conclude the following:

The Question of whether better guidance for usage can be applied was raised and discussed. Robert Wilton proposed some text which seems both reasonable and which does not change the substance of the draft.

The Question of where tags reside was raised, it appears resolved.

From the meeting, there remains the request for the addition of an example.

Kent - can we add an example

Chris - what format would you like it in.

Kent: xml/netconf or json/restconf is fine, just identify which is used.

On this basis I think we can do a writeup and forward a draft 04 to the IESG for review / IETF last call.

Thanks 
Joel 

> On Nov 12, 2018, at 08:46, joel jaeggli <[email-masked]> wrote:
>