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
"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.
Joel M. Halpern