Re: The Evils of Informational RFC's

[Stephen Farrell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>