Problem: Multiple Incompatible Specifications

[Brian E Carpenter]

Scott Bradner wrote:
> 
> note that in saying that there are times when more than one solution
> may need to be worked on I do not mean to imply that we should
> progress multiple standards track documents - in the cases I can think of
> it is a better idea to publish the competing ideas as
> experimental RFCs to see what the market thinks and then, if a clear
> message can be seen at some later date, focus attention on one solution
> which can then be brought to the standards track
> 
> there are exceptions (SNMP vs CMOT is one and OSPF & ISIS is another) but I
> do not think that it is the general case that there should be multiple stds
> track technologies addressing the same problem.

Exactly. While the general principle of avoiding duplicate solutions
is clearly correct, there will be exceptions, but I don't see this
as an active problem in the IETF.

You can find occasional errors of judgement perhaps -- but where's
the evidence of a systematic problem?

By the way, this principle is documented in RFC 1958:

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

       Brian