There is also a "speed of convergence" issue: For a new area with little operational experience, one might want to eventually have one solution, but there is no technical way to objectively arrive at a single answer, given the set of participants and knowledge available, as the weight of the engineering trade-offs can't be established objectively. In that case, there are three choices: (1) decide arbitrarily by fiat; given limited information, the choice may well turn out to be wrong and may well add a lot of process overhead if the losing party is sufficiently aggrieved. (2) have a fight to the death in the WG, until one side or the other is exhausted. Again, not necessarily likely to correspond to technical merit, but sure to delay things, meaning that users are deprived of any standard solution, meaning that a proprietary, possibly inferior to both, solution "wins" by default. Given that external parties may well desire such an outcome, it is easy to have them game the system by providing ammunition to both combatants. (3) Let multiple efforts proceed, but establish as much commonality as you can, in terms of data formats, security mechanisms, terminology or whatever else can be agreed upon. During the process of actually working out the details, one or more solutions may find that they are converging naturally or that the differences are a matter of taste. IMPP went roughly through (2) and (3). I'm not claiming that the particular process and duration spend in state (2) and (3) are role models. "Joel M. Halpern" wrote: > > My personal opinions on the matter of "when should we allow multiple > protocols for the same thing" are roughly: > 1) No hard and fast rule will work. This is something the relevant ADs, > and sometimes the whole IESG, must judge. > 2) It is reasonable to allow two (or even more) protocols when they have > clear and distinct areas of applicability. Thus, while I may technically > like a routing solution that applies to intra and inter domain, it is quite > reasonable from a standardization perspective to have two different > protocols for the two spaces. > 3) History is relevant. We frequently get solutions evolving independently > that turn out to have significant overlap. It requires significant care to > determinewhat should be used, when, and how. Often, this will require > allowing more than one standard for a time while we determine what works, > is technically complete, ... > > In general, multiple protocols for the exact same thing are a bad > idea. Translating that into practice is complicated. > > Yours, > Joel M. Halpern