--On 27. mars 2004 15:53 -0800 "Paul Hoffman / VPNC" <paul.hoffman@xxxxxxxx> wrote:
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.
The concept of boilerplate disclaimers is already in there. Are you suggesting alternate text for the disclaimers?
I'm suggesting that this be added to, not replace, the current boilerplate for non-IESG-reviewed RFCs.
Do you intend XXXX to point to draft-iesg-rfced-documents when it's published, or to some other resource?
To the RFC that comes from draft-iesg-rfced-documents.
- 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.
Requirement on the RFC Editor - doesn't sound unreasonable, but out of scope for this document.
Not really. Currently, when the IESG reviews non-standards-track documents, it makes a decision (or approves a request) for the status. This document puts that decision into the RFC Editor's hands. It would be good to give on-record advice for how the RFC Editor should make that decision, particularly since the recent experiences with making things Experimental are not consistent with the wording in 2026.
- 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.
I don't quite see the point of this, but anyway think that such a disclaimer belongs on the RFC Editor's pages, not in this document....
Probably true. Just taking another opportunity to try to reduce the work load of the IETF...
--Paul Hoffman, Director --VPN Consortium