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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf