[rfc-i] Informational and Experimental RFCs can have Normative references
Brian E Carpenter
brian.e.carpenter at gmail.com
Wed Apr 2 12:27:55 PDT 2014
On 03/04/2014 05:55, Andrew G. Malis wrote:
> I agree with Barry and Nico - the definition and usage of normative
> vs. informative references should be consistently applied throughout
> the RFC series - it's less confusing and makes understanding the
> content easier for the reader, as Nico pointed out, it makes it easier
> to subsequently move an RFC onto the standards track (even if there's
> a low probability of that happening), and there's really no cost
> involved other than a bit of care while preparing the RFC.
You may think I'm being inconsistent with myself, but I agree. The
point is that the normative/informative choice is ultimately a
judgment call, and my observation is that authors often forget
that and make too many references normative (just as they MAY
sometimes use normative keywords when they SHOULD NOT).
Anyway, I think the basic message here is that it's a stream thing.
> On Wed, Apr 2, 2014 at 11:39 AM, Barry Leiba <barryleiba at computer.org> wrote:
>>> The *requirement* to separate the references is not actually enshrined
>>> in any IETF BCP, as far as I know.
>> Sort of yes and no. The letter of what you say is correct: the
>> requirement to separate the references into different sections is in
>> an IESG statement:
>> But the logical separation of references into normative ones and
>> informative ones is in RFC 3967, at least (see Section 1.1), and that
>> logical separation is what drives the physical one.
>> The first two paragraphs of 3967 Section 1.1 are particularly
>> important to this discussion, so here, for easy reference:
>> Within an RFC, references to other documents fall into two general
>> categories: "normative" and "informative". Broadly speaking, a
>> normative reference specifies a document that must be read to fully
>> understand or implement the subject matter in the new RFC, or whose
>> contents are effectively part of the new RFC, as its omission would
>> leave the new RFC incompletely specified. An informative reference
>> is not normative; rather, it provides only additional background
>> An exact and precise definition of what is (and is not) a normative
>> reference has proven challenging in practice, as the details and
>> implications can be subtle. Moreover, whether a reference needs to
>> be normative can depend on the context in which a particular RFC is
>> being published in the first place. For example, in the context of
>> an IETF Standard, it is important that all dependent pieces be
>> clearly specified and available in an archival form so that there is
>> no disagreement over what constitutes a standard. This is not always
>> the case for other documents.
>> Note in particular that "a normative reference specifies a document
>> that must be read to fully understand or implement the subject
>> matter," and that whether a reference is normative "can depend on the
>> context" of the RFC, perhaps being different for standards than for
>> "other documents."
>> To me, that says that Informational documents (and Experimental, but I
>> more often see the argument about Informational) definitely *can* have
>> normative references in them, and those normative references are the
>> ones that "must be read to fully understand [...] the subject matter."
>>> With my Gen-ART and Independent Stream reviewer hats on, I tend to
>>> be very critical of excessive use of Normative References in
>>> Info/Exp documents, because I think it gives them a spurious air
>>> of authority. But that's just me. (It's also vanishingly rare for
>>> an Info/Exp document to be promoted to standards track without
>>> being updated.)
>> I really don't follow that. Authority doesn't come from the
>> references (and, really, I could argue that *being RFCs* gives them a
>> spurious air of authority, and that we should have a different series
>> for Informational documents, but that's a separate discussion). But
>> it's critical that people reading Informational documents know which
>> references they need to chase for essential information (the normative
>> ones), and which "[provide] only additional background information."
>>> At the RFC Editor level it seems to me it should be something that
>>> is allowed but the precise policy is per-stream.
>> As I think should be the case for almost all policies relating to
>> document contents, beyond obvious formatting.
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
More information about the rfc-interest