what are the real problems

[Thomas Narten]

<john.loughney at nokia.com> writes:

> I agree - I'm not a rabid free-market person, but I do think it is 
> appropriate to allow users of the technology to have some say in this;
> and that may require allowing 2 or 3 protocols that do similar things.

There are pros and cons to having 2-3 protocols doing the same
thing. Not always a simple answer.

In some (or even most?) cases, having multiple protocols doesn't mean
(say) the market (or users) will pick one (and even then the best
one).

Sometimes/often, the market forces vendors to implement *all* the
protocols. This results from a combination of checkmarks on RFPs, or
just fear of being at a disadvantage with competitors in the
marketplace.

Sometimes/often, you need a way for the 2-3 protocols to interoperate
with each other, as they will co-exist in the same enviornment (this
also gets back to the previous point -- if Big Vendor X ships protocol
1, others may be forced to implement it simply because not
implementing it means no workable solution in some deployments, where
there is a mixture of vendor's products).

Having 3 ways of doing essentially the same thing complicates
implementations (raising their cost, increasing bugs, increasing the
number of interoperability issues, etc.) Ditto for operational
considerations. Is the community well-served by this? In most cases, I
think not.

Also, how *quickly* can the market sort these things out? Not always
very quickly. If end hosts are involved, we're often looking 1-3 year
cycles before a protocol gets implemented and shipped in a mainstream
release.

There are some cases where a site/environment can really pick one
approach, and it doesn't matter that other sites do it differently,
because they don't need to interoperate. This tends to be more true (I
suspect) when the set of devices that need to run protocol X is more
constrained (e.g., only routers in my AS). But where end hosts are
involved, it's a lot harder to ensure that a sys admin really has the
choice to (only) use protocol X when there are multple protocols on
the market. If only one vendor doesn't support the protocol (or
doesn't yet in the current release because they opted to implement Y
first, since they can't implement everything at once), the sys
admin/end user really doesn't have a choice, in which case the
argument that "the market can decide" doesn't really hold.

This has led the IESG (from my view) to (as a general rule) prefer a
single solution/protocol for a problem. If there are multiple
protocols, there needs to be good justifications for why this is
necessary and desirable. I.e., an applicability statement that
explains why one might use one vs. the other. Not an absolute rule,
but certainly a preference. And just saying "some vendors prefer X,
others prefer Y" isn't a technical argument that can be scrutinized or
evaluated.

Thomas