rfc2360.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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, information
   should be orderly and detailed.  The following are general guidelines
   intended to help in the production of such a document.  The IESG may
   require that all or some of the following sections appear in a



Scott                    Best Current Practice                  [Page 2]

RFC 2360          Guide for Internet Standards Writers         June 1998


   standards track document.

2.1  Discussion of Security

   If the Internet is to achieve its full potential in commercial,
   governmental, and personal affairs, it must assure users that their
   information transfers are free from tampering or compromise.  Well-
   written security sections in standards-track documents can help
   promote the confidence level required.  Above all, new protocols and
   practices must not worsen overall Internet security.

   A significant threat to the Internet comes from those individuals who
   are motivated and capable of exploiting circumstances, events, or
   vulnerabilities of the system to cause harm.  In addition, deliberate
   or inadvertent user behavior may expose the system to attack or
   exploitation.  The harm could range from disrupting or denying
   network service, to damaging user systems.  Additionally, information
   disclosure could provide the means to attack another system, or
   reveal patterns of behavior that could be used to harm an individual,
   organization, or network.  This is a particular concern with
   standards that define a portion of the Management Information Base
   (MIB).

   Standards authors must accept that the protocol they specify will be
   subject to attack.  They are responsible for determining what attacks
   are possible, and for detailing the nature of the attacks in the
   document.  Otherwise, they must convincingly argue that attack is not
   realistic in a specific environment, and restrict the use of the
   protocol to that environment.

   After the document has exhaustively identified the security risks the
   protocol is exposed to, the authors must formulate and detail a
   defense against those attacks.  They must discuss the applicable
   countermeasures employed, or the risk the user is accepting by using
   the protocol.  The countermeasures may be provided by a protocol
   mechanism or by reliance on external mechanisms.  Authors should be
   knowledgeable of existing security mechanisms, and reuse them if
   practical.  When a cryptographic algorithm is used, the protocol
   should be written to permit its substitution with another algorithm
   in the future.  Finally, the authors should discuss implementation
   hints or guidelines, e.g., how to deal with untrustworthy data or
   peer systems.

   Security measures will have an impact within the environment that
   they are used.  Perhaps users will now be constrained on what they
   can do in the Internet, or will experience degradation in the speed
   of service.  The effects the security measures have on the protocol's
   use and performance should be discussed.



Scott                    Best Current Practice                  [Page 3]

RFC 2360          Guide for Internet Standards Writers         June 1998


   The discussion of security can be concentrated in the Security
   Considerations section of the document, or throughout the document
   where it is relevant to particular parts of the specification.  An
   advantage of the second approach is that it ensures security is an
   integral part of the protocol's development, rather than something
   that is a follow-on or secondary effort.  If security is discussed
   throughout the document, the Security Considerations section must
   summarize and refer to the appropriate specification sections.  This
   will insure that the protocol's security measures are emphasized to
   implementer and user both.

   Within the Security Considerations section, a discussion of the path
   not taken may be appropriate.  There may be several security
   mechanisms that were not selected for a variety of reasons: cost or
   difficulty of implementation, or ineffectiveness for a given network
   environment.  By listing the mechanisms they did not use and the
   reasons, editors can demonstrate that the protocol's WG gave security
   the necessary thought.  In addition, this gives the protocol's users
   the information they need to consider whether one of the non-selected
   mechanisms would be better suited to their particular requirements.

   A document giving further guidance on security topics is in
   development.  Authors should obtain a copy of the completed RFC to
   help them prepare the security portion of the standard.

   Finally, it is no longer acceptable that Security Considerations
   sections consist solely of statements to the effect that security was
   not considered in preparing the standard.

   Some examples of Security Considerations sections are found in STD
   33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939.  RFC 2316, "Report
   of the IAB Security Architecture Workshop", provides additional
   information in this topic area.

2.2  Protocol Description

   Standards track documents must include a description of the protocol.
   This description must address the protocol's purpose, intended
   functions, services it provides, and, the arena, circumstances, or
   any special considerations of the protocol's use.

   The authors of a protocol specification will have a great deal of
   knowledge as to the reason for the protocol.  However, the reader is
   more likely to have general networking knowledge and experience,
   rather than expertise in a particular protocol.  An explanation of
   it's purpose and use will give the reader a reference point for





Scott                    Best Current Practice                  [Page 4]

RFC 2360          Guide for Internet Standards Writers         June 1998


   understanding the protocol, and where it fits in the Internet.  The
   STD 54/RFC 2328 was recommended to the STDGUIDE working group as
   providing a good example of this in its "Protocol Overview" section.

   The protocol's general description must also provide information on
   the relationship between the different parties to the protocol. This
   can be done by showing typical packet sequences.

   This also applies to the algorithms used by a protocol.  A detailed
   description of the algorithms or citation of readily available
   references that give such a description is necessary.

2.3  Target Audience

   RFCs have been written with many different purposes, ranging from the
   technical to the administrative.  Those written as standards should
   clearly identify the intended audience, for example, designers,
   implementers, testers, help desk personnel, educators, end users, or
   others.  If there are multiple audiences being addressed in the
   document, the section for each audience needs to be identified.  The
   goal is to help the reader discover and focus on what they have
   turned to the document for, and avoid what they may find confusing,
   diverting, or extraneous.

2.4  Level of Detail

   The author should consider what level of descriptive detail best
   conveys the protocol's intent.  Concise text has several advantages.
   It makes the document easier to read.  Such text reduces the chance
   for conflict between different portions of the specification.  The
   reader can readily identify the required protocol mechanisms in the
   standard.  In addition, it makes it easier to identify the
   requirements for protocol implementation.  A disadvantage of concise
   descriptions is that a reader may not fully comprehend the reasoning
   behind the protocol, and thus make assumptions that will lead to
   implementation errors.

   Longer descriptions may be necessary to explain purpose, background,
   rationale, implementation experience, or to provide tutorial
   information.  This helps the reader understand the protocol.  Yet,
   several dangers exist with lengthy text.  Finding the protocol
   requirements in the text is difficult or confusing.  The same
   mechanism may have multiple descriptions, which leads to
   misinterpretation or conflict.  Finally, it is more difficult to
   comprehend, a consideration as English is not the native language of
   the many worldwide readers of IETF standards.