On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps <[email protected]> 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 <[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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
