Summary

  • RFC 3967 made a lower-maturity normative dependency visible at IETF Last Call rather than treating every exception as an invisible shortcut.
  • RFC 4897 and RFC 8067 later moved some cases from waiting to annotation and IESG discretion; neither made the referenced document more mature.

Standards can inherit a dependency that is useful before it is mature enough to sit comfortably beneath them. An implementation may need an algorithm described in an Informational RFC. A migration standard may have to explain how to coexist with an older protocol. An IETF specification may point to an external or proprietary system that the IETF cannot simply republish at a higher status. The awkward question is not whether the reference exists. It is whether a document presented as a standard now relies, in a normative sense, on something whose own status signals less review or stability.

RFC 2026’s normal rule was intended to keep that distinction legible: standards-track specifications normally should not depend on lower-maturity standards-track work or on non-standards-track specifications, apart from standards from other bodies. RFC 3967, published in December 2004 as BCP 97, explains the concern in plain institutional terms: readers should not be given the impression that a standard is more mature than it is. Maturity is a process label, not a direct score of technical merit. But a normative dependency matters because it can contain information needed to implement the referring specification fully.

If that dependency is unstable, unavailable, or misunderstood, the referring document may not stand alone.

The alternative was not to pretend that the maturity rule had no cost. RFC 3967 accepted that downward references were sometimes necessary and specified a visible exception path. A Standards Track or Best Current Practice document could proceed through normal IETF Last Call, but the Last Call notice had to identify the downward reference. Community comments on whether it was appropriate would enter the IESG’s deliberation. An Area Director could waive later notices only for the same document and version, after the community had already seen it several times and the AD judged its use accepted in the technical area.

That was a disclosure mechanism with a boundary. RFC 3967 did not say that every lower-level reference was acceptable once mentioned. It warned against using the procedure when the proper action was to move the referenced document into the appropriate category. Nor did it turn an exception into an upgrade: the target document kept its own status. The point was to let the community see the dependency and contest it before publication, not to disguise a maturity mismatch as consensus.

Three years later, RFC 4897 named a different cost. Its introduction says the old rule had sometimes produced very long publication delays and that some people considered it a major obstacle to advancing documents. Yet the evidence should be read carefully: the acknowledgments also say the author was unsure how valid some complaints were and that the proposal was partly a way to test them. This is a record of a process dispute, not a measured study proving how much time the rule cost.

RFC 4897 changed the treatment of already-published lower-maturity Standards-Track and BCP targets. Instead of holding the newer document until the target advanced, an author could annotate the normative reference: readers should use caution because the target may be less stable, and the note could explain why the dependency was appropriate. The IESG could still establish guidance about when to delay, and the community could still raise objections during the document’s life cycle. There was no separate review detached from the document itself. For target documents outside Standards Track, RFC 3967’s procedure remained in force.

RFC 4897 called advancement preferable when appropriate; “note and move on” was not the new universal rule.

RFC 8067, in 2017, adjusted the notice requirement again. Explicitly listing a down-reference in the Last Call message became strongly recommended rather than mandatory. The responsible Area Director still had to check for one. If a reference was discovered during Last Call or IESG review, the IESG could decide whether another Last Call was useful. Skipping a repeat did not change the target’s maturity, and the reference would still be governed by the down-reference process if used again. The record of the omission belonged in the Datatracker.

Read together, the three BCP 97 documents show a shift in what the process asks the institution to carry. RFC 3967 put the mismatch in front of the community before the IESG decided. RFC 4897 let selected references travel with an explicit warning rather than wait automatically for a status upgrade. RFC 8067 gave the IESG discretion over whether an unnoticed reference required renewed consultation, while preserving the maturity signal and a record of the choice. The transition was from a mostly procedural delay to a more explicit allocation of disclosure, review, annotation and judgment.

That change does not tell us whether publication became faster in practice, whether security improved or how often the exception was used. The RFCs state the rules and the authors’ reasons; they do not supply a before-and-after dataset. The durable historical point is narrower: a standards system can acknowledge that dependency and document maturity do not always move together, while still refusing to let a reference quietly inherit authority it has not earned.

Sources: RFC 2026, RFC 3967, RFC 4897, RFC 8067, RFC 7841.