Keith Moore wrote:
I think various people have made a good case for eventually publishing
this particular document, once appropriate revisions have been made.
I'm very supportive of the notion of free exchange of ideas, even
through the RFC mechanism - with the understanding that:
- IETF and the RFC Editor have limited resources and cannot publish
everything that comes their way
- it's inappropriate to use Experimental or Informational publications in
the RFC series to promote or claim legitimacy for ideas that are embroynic
or experimental in nature, especially when those ideas are violations of
Internet standards. there should be a clear distinction between
"this is somebody's idea for an experiment" and "this is the sense
of the Internet technical community"
- some experiments are better carried out under controlled conditions.
I'm in favor of the free exchange of ideas, with the caveat that
breaking existing standards or proposed standards must be addressed
prior to publication.
It is common for the RFC Editor to require augmentation of a proposed
informational RFC prior to publication. E.g., when the Security Issues
section has not been sufficiently developed.
There may be utility in considering a uniform "Standards Issues"
section. Just as the Security Issues must be sufficiently addressed when
an RFC affects or compromises security, the Standards Issues would be
necessary when an RFC affects or compromises current (STANDARD) or
'proposed' (DRAFT STANDARD, PROPOSED STANDARD) Internet standards.
The Standards Issues section could be required even if the RFC is
informational or experimental, as in the case of Security Issues. In
fact, I would prefer if it were always required, as in Sec Iss, even if
stating "this system is conformant with and does not affect any Internet
STANDARD, DRAFT STANDARD, or PROPOSED STANDARD as of this writing."
(e.g., as an update to RFC 2223)
Joe