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 protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
