At 4:21 PM -0500 3/26/04, Keith Moore wrote:
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