Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 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. > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt > > > Thanks > Joel > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 wrote: > > >> >> 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: > > 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 > > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
> > >> 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. > 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. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
On 16/11/2018 00:54, Kent Watsen 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. 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. 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 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
+1 Christian Regards, Jeff > On Nov 16, 2018, at 10:23, Andy Bierman wrote: > > > >> On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps 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. >> >> I think it would be good to get some justification for *not* having the >> server store tags for it’s own modules. >> > > +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, >> Chris. >> > > > Andy > >> >> >> > On Nov 15, 2018, at 19:54, Kent Watsen 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. >> > >> > 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 >> > >> > >> > >> >> ___ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps 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. > > I think it would be good to get some justification for *not* having the > server store tags for it’s own modules. > > +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, > Chris. > > Andy > > > On Nov 15, 2018, at 19:54, Kent Watsen 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. > > > > 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 > > > > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 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. > > 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 > > > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
> 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. 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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: 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 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
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 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".
>
> 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.
>
> >
> >> 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
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
> 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". 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. > >> 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
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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. 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
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 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 >>> (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
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 (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:" 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
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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:" 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. https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt Thanks Joel ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
> On Nov 12, 2018, at 15:36, Alex Campbell wrote: > > Perhaps my opinion also carries less weight, as someone who's only on the > mailing list and didn't actually attend the IETF meeting. > 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
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 on behalf of joel jaeggli Sent: Tuesday, 13 November 2018 5:46 a.m. To: NETMOD Working Group Subject: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
