At 7:32 AM -0800 3/30/04, Harald Tveit Alvestrand wrote:
--On 27. mars 2004 15:53 -0800 "Paul Hoffman / VPNC"
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> 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