+1 Christian Regards, Jeff
> On Nov 16, 2018, at 10:23, Andy Bierman <a...@yumaworks.com> wrote: > > > >> On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps <cho...@chopps.org> 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 <kwat...@juniper.net> 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
