Procedure for Standards Track Documents to Refer Normatively to External Documents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 November 2024.¶

Copyright Notice

Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Section 7 of BCP 9 [RFC2026] specifies the processes for allowing IETF documents to refer to externally produced standards and specifications.¶

Since the publication of BCP 9, such external references have become more common. Some of these external references, however, present a challenge, as they may not be freely available. This can impede thorough review or raise interoperability concerns.¶

BCP 9 also discusses references from standards track specifications to those of lower maturity levels. Updated guidance on this matter, and the first definition of the notion of "normative" versus "informative" references, can be found in BCP 97. BCP 97 also defines the terms "source" and "target" documents.¶

This document presents a procedure to be used when evaluating standards track IETF documents that make normative references to external specifications.¶

2. Procedure

A reference to a non-IETF document provides a few challenges relative to the RFC series:¶

• its development may not have been as rigorous as the Standards-Track document referencing it;¶

• the actual reference to it (e.g., a web link) may have dubious location stability;¶

• it may be subject to unexpected revision in situ; or¶

• it may not be freely available.¶

Authors and editors should try to avoid such references due to the challenges they present, as they affect the IETF's ability to ensure the quality of its output. However, such references are not always avoidable.¶

Authors/editors of source documents may be required by the IESG to secure freely available copies of the target documents for use by all anticipated reviewers during the source document's life cycle, which includes working group participants, any member of the community that chooses to participate in Last Call discussions, area review teams, IANA expert reviewers, and members of the IESG. The mechanism for acquiring access to those documents is to be specified in the shepherd writeup. Document authors and shepherds should avail themselves of any relevant liaison relationships [RFC4052] that may exist.¶

Note that there is no requirement for a freely available copy of the reference after the publication of the draft as an RFC, nor is there any requirement that the copies be provided to the general public.¶

Another path forward may be to generate an RFC of appropriate status that captures the important parts of the intended target document. This document can then be normative for the IETF's future work on that same topic. Although this is initially more work for the IETF, it secures the stability of the referenced work and avoids the problem of inaccessible later references to the original target material. A possible example of this practice is [RFC3339]. If such an RFC is produced at Informational or Experimental status, the normal process governing references to it (i.e., BCP 97) still applies.¶

3. Security Considerations

This document is not known to create any new vulnerabilities for the Internet. On the other hand, inappropriate or excessive use of these processes might be considered a downgrade attack on the quality of IETF standards or, worse, on the rigorous review of security aspects of standards.¶

Appendix A. Acknowledgments

This document benefited from contributions by Carsten Bormann, Mohamed Boucadair, Scott Bradner, Brian Carpenter, Ned Freed, Russ Housley, John Klensin, Michael Richardson, and Rich Salz.¶

Author's Address