+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(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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(_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