FWIW, I'm not at all confused by the various RFC streams
and see no negatives and some positives in their existence.
So let's keep it as-is please.
Stephen.
PS: I know of no "evil" RFCs but would welcome contrary
opinions (not including rfc3514's version of evil). Maybe
there are, recently, one or more companies espousing
equivalent levels of evil to those envisaged in rfc3514,
but who knows.
On 09/09/10 00: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?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf