+1 to everything Brian says. There are very many good reasons to have Informational RFCs, whether they're an independent submission, an RFC that represents IETF consensus but doesn't define protocol elements, or from one of the other streams, such as the IAB or IRTF. And speaking as someone who works at an operator and evaluates vendor equipment, believe me, the customers know the difference between standards-track and non-standards-track RFCs, and what it means to be compliant to a particular RFC. Cheers, Andy On Wed, Sep 8, 2010 at 5:43 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > On 2010-09-09 09:08, Richard L. Barnes wrote: >> s/Informational RFCs/independent stream/ >> >> If what you're after is RFC == IETF, shouldn't we be eliminating the >> independent submission process instead of informational RFCs in >> general. Things like RFC 3693 or draft-ietf-geopriv-arch, which don't >> specify a protocol, but describe an architecture, seem to properly be >> Informational, but still reflect IETF consensus. > > Er, this whole discussion is hardly new, and is the reason that both > RFC 1796 and RFC 5741 were produced. > > I think we all understand why there need to be non-normative IETF > documents; RFC 2475 is a good example. Therefore, RFC /= normative. > > We also have good reasons for publishing IAB and IRTF documents, which > by their very nature cannot be normative. Therefore, RFC /= IETF. > > 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. > > Incidentally it took me quite a while to accept the last point. > My own initial reaction to the Independent Submission stream was that > it enabled end runs. However, there are solid mechanisms in place to > prevent that. I think arguments given in RFC 4846 are convincing. > > In any case, you can't put this toothpaste back in the tube. > > Brian (all IMHO, but I am a member of both the RSAG and the > ISEB, which are explained at > http://www.rfc-editor.org/RFCeditor.html) > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf