Part of the problem is the familiar one that RFCs are often used as standards even when they carry the Informational or Experimental label.
With respect to Informational RFCs, that was more true five years ago than it is now. The IETF has been largely successful at nailing vendors who try to pass off Informational RFCs as having any weight. It still happens, but is often followed by public rebuke from active IETF members. The last time someone asked me about whether or not they should try "elevating the importance" of an Informational RFC, my response was "sure, if you want to be exposed as a liar".
Experimental RFCs are unfortunately a different matter. We see Working Groups passing out fully-deployed, non-experimental protocols as "Experimental" due to political reasons such as lack of consensus, or as consolation prizes when a different protocol received louder hums.
Noel's observation about the lack of need for RFC publication due to the easy publication on the Web is exactly right. People can find out about information Foo or experiment Bar with a quick search. The Internet might be helped by publication in the RFC series, but it also might not be.
The material in draft-iesg-rfced-documents-00.txt can be greatly improved with a few changes:
- Require that all documents published without IESG technical review say so explicitly in a standardized boilerplate: "The technology in this document was reviewed the RFC Editor, but was not approved by the IESG or any IETF Working Group. See RFC xxxx for more information on the process used in the publication of this document" This will help readers of the RFC who haven't read 2026 et. al., and will also serve as a hindrance to over-marketing the document.
- Require that the RFC Editor not publish any document as an Experimental RFC unless it meets the definition on RFC 2026 or its successors. Publish a non-standards-track protocol as an Informational RFC with the above wording unless it really is "a specification that is part of some research or development effort". It is the responsibility of the RFC Editor to make this determination.
- Add text saying that publication as an RFC may not meet the needs of many publication requesters, and that having an RFC can actually inhibit innovation and flexibility due to the limitations of the series such as long publication times, difficulty of revision, and so on.
--Paul Hoffman, Director --VPN Consortium