BCP Series: Best Current Practices
The memo that established the Best Current Practices RFC subseries.
Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995, <https://www.rfc-editor.org/info/rfc1818>.
@misc{rfc1818,
series = {Request for Comments},
number = 1818,
howpublished = {RFC 1818},
publisher = {RFC Editor},
doi = {10.17487/RFC1818},
url = {https://www.rfc-editor.org/info/rfc1818},
author = {J. Postel and T. Li and Y. Rekhter},
title = {{Best Current Practices}},
pagetotal = 3,
year = 1995,
month = aug,
} RFC text
Contents
Network Working Group J. Postel
Request for Comments: 1818 ISI
BCP: 1 T. Li
Category: Best Current Practice cisco Systems
Y. Rekhter
cisco Systems
August 1995
Best Current Practices
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
This document describes a new series of documents which describe best
current practices for the Internet community. Documents in this
series carry the endorsement of the Internet Engineering Steering
Group (IESG).
Discussion
The current IETF process has two types of RFCs: standards track
documents and other RFCs (e.g., informational, experimental, FYIs)
[1]. The intent of the standards track documents is clear, and
culminates in an official Internet Standard [2,3]. Informational
RFCs can be published on a less formal basis, subject to the
reasonable constraints of the RFC editor. Informational RFCs are not
subject to peer review and carry no significance whatsoever within
the IETF process [4].
The IETF currently has no other mechanism or means of publishing
relevant technical information which it endorses. This document
creates a new subseries of RFCs, entitled Best Current Practices
BCPs).
The BCP process is similar to that for proposed standards. The BCP
is submitted to the IESG for review, and the existing review process
applies, including a "last call" on the IETF announcement mailing
list. However, once the IESG has approved the document, the process
ends and the document is published. The resulting document is viewed
as having the technical approval of the IETF, but it is not, and
cannot become an official Internet Standard.
Possible examples of technical information to which BCPs could be
applied are "OSI NSAP Allocation" [5], and "OSPF Applicability
Statement" [6].
References
[1] IAB, and IESG, "Internet Standards Process -- Revision 2", RFC
1602, IAB and IESG, March 1994.
[2] Postel, J., Editor, "Internet Official Protocol Standards", STD
1, RFC 1800, IAB, July 1995.
[3] Hinden, R., "Internet Engineering Task Force Internet Routing
Protocol Standardization Criteria", RFC 1264, BBN, October 1991.
[4] Waitzman, D., "Standard for the Transmission of IP Datagrams on
Avian Carriers", RFC 1149, BBN, April 1990.
[5] Collela, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines
for OSI NSAP Allocation in the Internet", RFC 1629, NIST,
Wellfleet, Mitre, IBM, May 1994.
[6] Chapin, L., "Applicability Statement for OSPF", RFC 1370, IAB,
October 1992.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Jon Postel
USC - ISI, Suite 1001
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: postel@isi.edu
Yakov Rekhter
cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: 914-528-0090
EMail: yakov@cisco.com
Tony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
EMail: tli@cisco.com
ISO Plain Language
On this page
§1A Gap in RFC Publication
The RFC process described in this memo had standards-track documents, which could lead to an official Internet Standard, and other RFCs such as informational, experimental, and FYI documents. Informational RFCs had a less formal publication process and, according to the memo, no significance within the IETF process.
The IETF had no other way to publish relevant technical information that it endorsed. RFC 1818 creates a new subseries to fill that gap.
The process had formal standards and informal notes, but no category for technical guidance endorsed by the IETF. The BCP series was created for that purpose.
§2Reviewing a Best Current Practice
Documents in the Best Current Practices series carry the endorsement of the Internet Engineering Steering Group (IESG). The process resembles the proposed-standard process: the IESG reviews the document, including the existing last-call process on the IETF announcement mailing list.
Once the IESG approves a BCP, the process ends and the document is published. The memo gives OSI NSAP allocation and the OSPF applicability statement as possible subjects for BCPs.
A BCP is reviewed by the IESG, and the community gets a last call to comment. Once approved, it is published without moving through a standards maturity ladder.
§3BCPs and Internet Standards
A published BCP is viewed as having the IETF's technical approval. The memo clearly distinguishes that approval from an official Internet Standard: a BCP is not a standard and cannot become one.
This RFC is itself BCP 1. The unit metadata lists it as Historic and records no replacement RFC.
A BCP is endorsed technical guidance, not an Internet Standard. The distinction is part of the publication category itself.