Paul Hoffman wrote:
At 12:08 PM +0300 6/13/07, <Pasi(_dot_)Eronen(_at_)nokia(_dot_)com> wrote:
The hurdle of getting IETF consensus and publishing an RFC does
weed out many crazy proposals that, in all fairness, would not
have made the Internet work better, and would not have promoted
interoperability.
It does not need to promote interoperability; being interop-neutral
is sufficient. How does giving a codepoint to someone with a crazy
(and let's say even dangerous to the Internet) idea hurt
interoperability? It seems to be interop-neutral.
I think giving out codepoints freely would in many cases encourage
having multiple (often half-baked) solutions to the same problem.
To give one example we both worked on: I think it's good we didn't
allocate codepoints to all the individual MOBIKE protocol proposals
(mine, Tero's, Francis's), and instead were "forced" to work together
and converge on a single protocol.
Probably the "market" would have eventually picked one of them as
the winner, but meanwhile, the situation would IMHO not have been
interop-neutral. (And working together also produced a better
protocol than any of the individual drafts were.)
I'm not saying that this particular cooperation would not have
happened with less strict IANA policies -- but I do believe that
if the bar for getting codepoints and publishing an RFC would be
significantly lower than today, we would have a much larger number
of poorly concieved and overlapping extensions to various IETF
protocols. (And IMHO that would not always be interop-neutral.)
However: I do agree with John Klensin's statement that "there is a
difference between registering a parameter for a non-standard
specification that is already deployed and in successful use and
registering one for a wild idea by one person."
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf