ietf
[Top] [All Lists]

Re: The Evils of Informational RFC's

2010-09-08 17:12:57
It seems to me that one of the issues here is that architecture models are published as Informational when they're clearly not in the same level of authority as most Informational RFCs. An architecture document is meant to guide future work on standards track RFCs, and has been regarded historically as more or less binding.

The easy fix is to create an "Architectural" category within the standards track. There's obviously a big difference between RFC 2475 and IP for Avian Carriers.

RB

On 9/8/2010 2:43 PM, Brian E Carpenter 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