[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.

    Brian
> 
> Cheers,
> Andy
> 
> 
> 
> 
> 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:
>> http://www.ietf.org/iesg/statement/normative-informative.html
>>
>> 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
>>    information.
>>
>>    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.
>>
>> Barry
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 


More information about the rfc-interest mailing list