]>

superuser@gmail.com

General internet-drafts This document specifies a procedure for referencing external standards and specifications from IETF-produced documents on the Standards Track. In doing so, it updates BCP 9 (RFC 2026).

Section 7 of BCP 9 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.

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 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 . If such an RFC is produced at Informational or Experimental status, the normal process governing references to it (i.e., BCP 97) still applies.

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.

&RFC2026; &RFC3339; &RFC4052;

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.