On 2010-09-09 11:25, Richard L. Barnes wrote:
Finally, we are an open community encouraging a diversity of views, and
it's sometimes necessary (and often desirable) to publish material from
the community that meets none of the above criteria. Hence the
Independent stream of RFCs. As everyone should know, the independence
of the Independent stream is now guaranteed by a much more robust
process than before (RFC 4846 and RFC 5620). Since RFC 4846 gives a
complete explanation of why the Independent series exists, I won't
repeat it here.
Echoing somewhat Eric's original point -- we have the web now. There
are a multitude of fora in which material that doesn't meet the above
criteria can be published. Why does it need to be part of the RFC
series, other than the fact that we've always done it?
In one word: archival.
In several words: systematic archival rather than the vagueness
of transient URLs and search engine caches.
Obviously, that presupposes a judgment that the document is
worthy of archival, which is why there is an editor and an
editorial board.
Brian
I fail to find any of the justifications in RFC 4846 all that
persuasive. Choosing a few examples:
o Discussion of Internet-related technologies that are not part of
the IETF agenda.
o Critiques and discussions of alternatives to IETF Standards-Track
protocols. The potential for such critiques provides an important
check on the IETF's standards processes and should be seen in that
light.
o Informational discussions of technologies, options, or experience
with protocols.
o Technical contributions (e.g., RFC 1810 [RFC1810]).
These discussions happen all the time, all over the Internet. My
favorite recent example:
<http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars>
One venue more or less for these discussions isn't going to make a huge
difference, and using the RFC stream for them simply causes confusion as
to what's a "real" RFC.
o Informational publication of vendor-specific protocols.
Nowadays, vendors have web sites that describe their protocols. See,
for example:
<http://code.google.com/apis/gears/geolocation_network_protocol.html>
--Richard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf