From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
...
Why do you think that the re-chartered WG will have any more luck
with these than the current one? There are a zillion hardware vendors
and service providers who have reasons to want the dozens of
documents that are in the current WGs, and it takes very little
effort on their part to promote their views. The IETF structure does
poorly in such an environment; maybe a different standards body would
do better.
...
And why should the IETF care at all about these? There are other fora
for layer-2 interworking.
That's an interesting pair of thoughts. The obvious guess is that
interested parties are happy with the bad job the IETF has been doing and
are doing a little forum shopping. In the areas I've been watching (which
do not include IPSEC, DNSSEC, or VPNs), the bad jobs consist of rubber
stamping ideas whose lameness is exceeded only by their complete lack of
interest and any trace of originality. It's amazing how many people feel
compelled to take a well established idea with many ancient implementations
and write an RFC standardizing a redundant, unnecessary version elsewhere.
(Is that also the deal with this tunnel stuff?)
I suspect the IESG is overtaxed, overextended, and doesn't have enough
thumbs to stick in all of holes in the dikes holding back the floods
of wonderful ideas from marketing departments and junior, not-quite
engineers with ambitions in marketing.
A modest proposal: Limit the supply of RFC (not to mention BCP)
numbers. If only 50 RFC numbers were available for the next 12 months,
there would be an incentive for competent people to stick their necks
out and stomp on some of the nonsense to ensure that things that need
consideration would get it. I doubt the IETF could produce 10 good
RFCs in the next 12 months, so 50 numbers would be generous.
Without that, an equivalent of the IEEE PAR, or some other effective
mechanism, the IETF is going to suffer the fate dictated by Gresham's
Law of any mint that fails to control its output.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com