RFC 8067

RFC 8067: Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level 💖

Title block tea ☕: this one is a Best Current Practice (BCP 97 💅), written by B. Leiba at Huawei Technologies, dated January 2017. It updates RFC 3967 🔥 and has no Obsoletes entry in its title block. The ISSN is 2070-1721. Also, the title says it all: it's about when Standards Track documents are allowed to point normatively at lower-maturity documents. Iconic topic 👑

---

Abstract ✨

okay so RFC 3967 has a process for allowing "downrefs" (normative references to documents at lower maturity levels) 🦋. That process says you have to call out the downref explicitly in the Last Call notice. ngl that rule turned out to be way too strict 💀, so this document updates RFC 3967 and gives the IESG more flexibility when accepting downrefs in Standards Track documents 🫶.

Status of This Memo 🌸

This memo documents an Internet Best Current Practice 💜.

This document is a product of the Internet Engineering Task Force (IETF) 🌈. It's been approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check Section 2 of RFC 7841 🧚.

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc8067 🦋.

Copyright Notice 🎀

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved ✨.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication 📜. Please read these carefully, because they describe your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅.

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  The IESG's Responsibility with Respect to Downrefs  . . . . .   2
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
4.  Normative References  . . . . . . . . . . . . . . . . . . . .   3
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3

---

1. Introduction 🦋

okay bestie, so [RFC3967] is all about making sure normative references from Standards Track and Best Current Practice (BCP) documents are actually mature enough 🔥. It sets up a process for downrefs, and that process kicks off at IETF Last Call (see Section 3 of [RFC3967]) 💖:

For Standards Track or BCP documents requiring normative reference to documents of lower maturity, the normal IETF Last Call procedure will be issued, with the need for the downward reference explicitly documented in the Last Call itself. Any community comments on the appropriateness of downward references will be considered by the IESG as part of its deliberations.

Section 2 of [RFC3967] lists some situations where downrefs can make sense 🧚. On top of those, working groups have started producing foundational documents at Informational status 🌈. Those contain the important stuff, like terminology definitions and architecture and design considerations, and they keep getting needed as normative references in the Standards Track protocol documents that come after 🫶.

The "mention every downref and why you need it in the Last Call message" requirement is literally too restrictive 😭. It keeps causing extra rounds of Last Call, which means delays with zero real benefit 💀.

2. The IESG's Responsibility with Respect to Downrefs 👑

So the process in RFC 3967 gets updated: explicitly documenting the downward references in the Last Call message is strongly recommended but not required 💅. The responsible AD should still check for downrefs before sending out the Last Call notice ✨. But if an undetected downref shows up during Last Call or IESG review, whether to repeat the Last Call is up to the IESG 🌸.

Here's the plot twist 🙈: the process in RFC 3967 isn't fundamentally changed. If the IESG decides not to repeat the Last Call, the status of the affected downrefs doesn't change, and the RFC 3967 process still applies if those downrefs get used later 🔥.

This gives the IESG the job of figuring out the actual maturity level of a downward reference for the document at hand. They also decide, case by case, whether they need to explicitly ask the IETF community for comments on that downref 🦋. When making that call, the IESG should take into account the general discussion in RFC 3967 🧚. And the responsible AD should make sure the omission gets recorded as a comment in the datatracker 📝.

3. Security Considerations 🔐

Referencing immature protocols can have security and stability implications 😱. The IESG should take that into account when deciding whether re-consulting the community is useful 💜.

4. Normative References 📚

[RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
           Documents may Refer Normatively to Documents at a Lower
           Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December
           2004, <http://www.rfc-editor.org/info/rfc3967>.

Author's Address 🎀

Barry Leiba
Huawei Technologies

Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI:   http://internetmessagingtechnology.org/

That's the whole thing, bestie 🌈✨ RFC 8067 basically says "chill, the IESG can decide when a downref is fine" 💅🫶