Guide for Internet Standards Writers
RFC 2360
Document | Type |
RFC - Best Current Practice
(June 1998; No errata)
Also known as BCP 22
|
|
---|---|---|---|
Author | Gregor Scott | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2360 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group G. Scott, Editor Request for Comments: 2360 Defense Information Systems Agency BCP: 22 June 1998 Category: Best Current Practice Guide for Internet Standards Writers 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors". Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2 2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3 2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4 2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6 2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6 2.8 Response to Out of Specification Behavior . . . . . . . . . 6 2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7 2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8 2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9 2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9 2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10 2.14 Network Management Considerations . . . . . . . . . . . . 10 2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10 2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11 2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11 Scott Best Current Practice [Page 1] RFC 2360 Guide for Internet Standards Writers June 1998 2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12 3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12 3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13 3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13 4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15 5 Security Considerations . . . . . . . . . . . . . . . . . 16 6 References . . . . . . . . . . . . . . . . . . . . . . . . 16 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18 8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18 9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19 10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20 1 Introduction This document is a guide for Internet standard writers. It offers guidelines on how to write a standards-track document with clarity, precision, and completeness. These guidelines are based on both prior successful and unsuccessful IETF specification experiences. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors", or its update. Note that some guidelines may not apply in certain situations. The goal is to increase the possibility that multiple implementations of a protocol will interoperate. Writing specifications to these guidelines will not guarantee interoperability. However, a recognized barrier to the creation of interoperable protocol implementations is unclear specifications. Many will benefit from having well-written protocol specifications. Implementers will have a better chance to conform to the protocol specification. Protocol testers can use the specification to derive unambiguous testable statements. Purchasers and users of the protocol will have a better understanding of its capabilities. For further information on the process for standardizing protocols and procedures please refer to BCP 9/RFC 2026, "The Internet Standards Process -- Revision 3". In addition, some considerations for protocol design are given in RFC 1958, "Architectural Principles of the Internet". 2 General Guidelines It is important that multiple readers and implementers of a standard have the same understanding of a document. To this end, informationShow full document text