Difference between revisions of "IETF-Request for Comment-RFC best practices"
(establish a page for the RCP best practices) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
== The Internet Engineering Task Force (IETF) == | == The Internet Engineering Task Force (IETF) == | ||
The goal of the IETF is to make the Internet work better. | The goal of the [http://www.ietf.org Internet Engineering Task Force] (IETF) is to make the Internet work better. | ||
The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Newcomers to the IETF should start here. | The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Newcomers to the IETF should start here. | ||
| Line 15: | Line 15: | ||
== Best Current Practice == | == Best Current Practice == | ||
The best current practice (BCP) subseries collects administrative documents and other texts which are considered as official rules and not only informational, but which do not affect over the wire data. The border between standards track and BCP is often unclear. If a document only affects the Internet Standards Process, like BCP 9,[14] or IETF administration, it is clearly a BCP. If it only defines rules and regulations for Internet Assigned Numbers Authority (IANA) registries it is less clear; most of these documents are BCPs, but some are on the standards track. | The [http://www.apps.ietf.org/rfc/bcplist.html best current practice (BCP)] subseries collects administrative documents and other texts which are considered as official rules and not only informational, but which do not affect over the wire data. The border between standards track and BCP is often unclear. If a document only affects the Internet Standards Process, like BCP 9,[14] or IETF administration, it is clearly a BCP. If it only defines rules and regulations for Internet Assigned Numbers Authority (IANA) registries it is less clear; most of these documents are BCPs, but some are on the standards track. | ||
The BCP series also covers technical recommendations for how to practice Internet standards; for instance the recommendation to use source filtering to make DoS attacks more difficult (RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing") is BCP 38. | The BCP series also covers technical recommendations for how to practice Internet standards; for instance the recommendation to use source filtering to make DoS attacks more difficult (RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing") is BCP 38. | ||
{{#seo: | |||
|title=IETF-Request for Comment-RFC best practices | |||
|keywords=Internet best practices, IETF best practices, Internet Standards Process best practices | |||
|description=Website of the IETF to improve the Internet through RFC process for best practices to improve the Internet. | |||
}} | |||
Latest revision as of 10:01, 27 February 2014
The Internet Engineering Task Force (IETF)
The goal of the Internet Engineering Task Force (IETF) is to make the Internet work better.
The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Newcomers to the IETF should start here.
Request for Comments (RFC)
A Request for Comments (RFC) is a publication of the Internet Engineering Task Force (IETF) and the Internet Society, the principal technical development and standards-setting bodies for the Internet.
An RFC is authored by engineers and computer scientists in the form of a memorandum describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems. It is submitted either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The IETF adopts some of the proposals published as RFCs as Internet standards.
Request For Comments documents were invented by Steve Crocker in 1969 to help record unofficial notes on the development of the ARPANET. They have since become the official record for Internet specifications, protocols, procedures, and events.[1]
Best Current Practice
The best current practice (BCP) subseries collects administrative documents and other texts which are considered as official rules and not only informational, but which do not affect over the wire data. The border between standards track and BCP is often unclear. If a document only affects the Internet Standards Process, like BCP 9,[14] or IETF administration, it is clearly a BCP. If it only defines rules and regulations for Internet Assigned Numbers Authority (IANA) registries it is less clear; most of these documents are BCPs, but some are on the standards track.
The BCP series also covers technical recommendations for how to practice Internet standards; for instance the recommendation to use source filtering to make DoS attacks more difficult (RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing") is BCP 38.