> 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
