[rfc-i] Informational and Experimental RFCs can have Normative references

Andrew G. Malis agmalis at gmail.com
Wed Apr 2 09:55:16 PDT 2014


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.

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