> From: Paul Hoffman / IMC <[EMAIL PROTECTED]> > ... > 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 [EMAIL PROTECTED]
