> 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

Reply via email to