Re: The Evils of Informational RFC's

[Brian E Carpenter <[e-mail]>]

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
>