On Nov 3, 2010, at 1:42 PM, t.petch wrote: > <tp> > Perhaps we should step back a little further, and refuse to charter work that > will become an RFC unless there are two or more independent organisations that > commit to producing code. There is nothing like interoperability for > demonstrating the viability (or not) of a specification, and likewise, two > independent organisations are likely to bring two rival views of what should and > should not be specified. Those not implementing can watch the two slugging it > out, and provide a balanced judgement when something needs consensus. > > And two organisations with an interest might want to see a ROI sooner rather > than later. > > Tom Petch > </tp> That's being a killjoy. Organizations never commit to producing code. Besides, sometimes people get ideas and would like to get them published even before they have convinced their management that implementing is a good idea. Now if someone produces an RFC just to convince management that it's a good idea to implement (because there's an RFC) that's a different thing. Anyway, I have followed three cases where there were competing proposals for doing the same thing, one in NEA, the other two in IPSECME. As it turned out, those not implementing watched the two slugging it out, and provided no judgement whatsoever. In all three cases. I get a feeling that working groups are much better at polishing a single proposal than they are at choosing between competing proposals. I think Martin pointed out a similar thing yesterday. The RI proposal was not the only one on the table, but it was essential to have just one proposal to get the process running. RFCs have one big advantage over all kinds of "blessed" internet drafts. The process of publishing an RFC gets the IANA allocations. Every implementation you make based on a draft will ultimately not work with the finished RFC because you have to use some "private" ranges of numbers. I have a feeling (not backed by any evidence) that part of the reason people rush to publish documents is the need to get IANA assignments for their implementations. If we could have some kind of "viable", "promising" or "1st review" status for an Internet Draft, where the IANA assignments can be done on a temporary basis, I think this could allow for better review later on. I have no idea, though, how to get rid of the "need to support legacy implementations" argument that will arise later on, if changes to the protocol are proposed as part of the review. Yoav _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf