rfc2360.txt

RFC 的详细文档！

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


   One approach is to divide the standard into sections: one describing
   the protocol concisely, while another section consists of explanatory
   text.  The STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 provides
   examples of this method.

2.5  Change Logs

   As a document moves along the standards track, from Proposed to Draft
   or Draft to Full, or cycles in level, it will undergo changes due to
   better understanding of the protocol or implementation experience. To
   help implementers track the changes being made a log showing what has
   changed from the previous version of the specification is required
   (see Appendix).

2.6  Protocol Versions

   Often the standard is specifying a new version of an existing
   protocol.  In such a case, the authors should detail the differences
   between the previous version and the new version.  This should
   include the rationale for the changes, for example, implementation
   experience, changes in technology, responding to user demand, etc.

2.7  Decision History

   In standards development, reaching consensus requires making
   difficult choices.  These choices are made through working group
   discussions or from implementation experience.  By including the
   basis for a contentious decision, the author can prevent future
   revisiting of these disagreements when the original parties have
   moved on.  In addition, the knowledge of the "why" is as useful to an
   implementer as the description of "how".  For example, the
   alternative not taken may have been simpler to implement, so
   including the reasons behind the choice may prevent future
   implementers from taking nonstandard shortcuts.

2.8  Response to Out of Specification Behavior

   A detail description of the actions taken in case of behavior that is
   deviant from or exceeds the specification is useful.  This is an area
   where implementers often differ in opinion as to the appropriate
   response.  By specifying a common response, the standard author can
   reduce the risk that different implementations will come in to
   conflict.

   The standard should describe responses to behavior explicitly
   forbidden or out of the boundaries defined by the specification.  Two
   possible approaches to such cases are discarding, or invoking error-
   handling mechanisms.  If discarding is chosen, detailing the



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


   disposition may be necessary.  For instance, treat dropped frames as
   if they were never received, or reset an existing connection or
   adjacency state.

   The specification should describe actions taken when a critical
   resource or a performance-scaling limit is exceeded.  This is
   necessary for cases where a risk of network degradation or
   operational failure exists.  In such cases, a consistent behavior
   between implementations is necessary.

2.9  The Liberal/Conservative Rule

   A rule, first stated in STD 5/RFC 791, recognized as having benefits
   in implementation robustness and interoperability is:

                    "Be liberal in what you accept, and
                      conservative in what you send".

   Or establish restrictions on what a protocol transmits, but be able
   to deal with every conceivable error received.  Caution is urged in
   applying this approach in standards track protocols.  It has in the
   past lead to conflicts between vendors when interoperability fails.
   The sender accuses the receiver of failing to be liberal enough, and
   the receiver accuses the sender of not being conservative enough.
   Therefore, the author is obligated to provide extensive detail on
   send and receive behavior.

   To avoid any confusion between the two, recommend that standard
   authors specify send and receive behavior separately.  The
   description of reception will require the most detailing.  For
   implementations are expected to continue operating regardless of
   error received.  Therefore, the actions taken to achieve that result,
   need to be laid out in the protocol specification.  Standard authors
   should concern themselves on achieving a level of cooperation that
   limits network disruption, not just how to survive on the network.
   The appearance of undefined information or conditions must not cause
   a network or host failure.  This requires specification on how to
   attempt acceptance of most of the packets.  Two approaches are
   available, either using as much of the packet's content as possible,
   or invoking error procedures.  The author should specify a dividing
   line on when to take which approach.

   A case for consideration is that of a routing protocol, where
   acceptance of flawed information can cause network failure.  For
   protocols such as this, the specification should identify packets
   that could have different interpretations and mandate that they be
   rejected completely or the nature of the attempt to recover some
   information from them.  For example, routing updates that contain



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


   more data than the tuple count shows.  The protocol authors should
   consider whether some trailing data can be accepted as additional
   routes, or to reject the entire packet as suspect because it is non-
   conformant.

2.10  Handling of Protocol Options

   Specifications with many optional features increase the complexity of
   the implementation and the chance of non-interoperable
   implementations.  The danger is that different implementations may
   specify some combination of options that are unable to interoperate
   with each other.

   As the document moves along the standard track, implementation
   experience shall determine the need for each option.  Implementation
   shall show whether the option should be a mandatory part of the
   protocol or remain an option.  If an option is not implemented as the
   document advances, it must be removed from the protocol before it
   reaches draft standard status.

   Therefore, options shall only be present in a protocol to address a
   real requirement.  For example, options can support future
   extensibility of the protocol, a particular market, e.g., the
   financial industry, or a specific network environment, e.g., a
   network constrained by limited bandwidth.  They shall not be included
   as a means to "buy-off" a minority opinion.  Omission of the optional
   item shall have no interoperability consequences for the
   implementation that does so.

   One possible approach is to document protocol options in a separate
   specification.  This keeps the main protocol specification clean and
   makes it clear that the options are not required to implement the
   protocol.  Regardless of whether they appear within the specification
   or in a separate document, the text shall discuss the full
   implications of either using the option or not, and the case for
   choosing either course.  As part of this, the author needs to
   consider and describe how the options are used alongside other
   protocols.  The text must also specify the default conditions of all
   options.  For security checking options the default condition is on
   or enabled.

   There are occasions when mutually exclusive options appear within the
   protocol.  That is, the implementation of an optional feature
   precludes the implementation of the other optional feature.  For
   clarity, the author needs to state when to implement one or the
   other, what the effect of choosing one over the other is, and what





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


   problems the implementer or user may face.  The choice of one or the
   other options shall have no interoperability consequences between
   multiple implementations.

2.11  Indicating Requirement Levels

   The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate
   Requirement Level", defines several words that are necessary for
   writing a standards track document.  Editors of standards track
   documents must not deviate from the definitions provided as they are
   intended to identify interoperability requirements or limit
   potentially harmful behavior.  The capitalization of these words is
   the accepted norm, and can help in identifying an unintentional or
   unreasonable requirement.  These words have been used in several RFCs
   the first instances being STD 3/RFC 1122/RFC 1123.

2.12  Notational Conventions

   Formal syntax notations can be used to define complicated protocol
   concepts or data types, and to specify values of these data types.
   This permits the protocol to be written without concern on how the
   implementation is constructed, or how the data type is represented
   during transfer.  The specification is simplified because it can be
   presented as "axioms" that will be proven by implementation.

   The formal specification of the syntax used should be referenced in
   the text of the standard.  Any extensions, subsets, alterations, or
   exceptions to that formal syntax should be defined within the
   standard.

   The STD 11/RFC 822 provides an example of this.  In RFC 822 (Section
   2 and Appendix D) the Backus-Naur Form (BNF) meta-language was
   extended to make its representation smaller and easier to understand.
   Another example is STD 16/RFC 1155 (Section 3.2) where a subset of
   the Abstract Syntax Notation One (ASN.1) is defined.

   The author of a standards track protocol needs to consider several
   things before they use a formal syntax notation.  Is the formal
   specification language being used parseable by an existing machine?
   If no parser exists, is there enough information provided in the
   specification to permit the building of a parser?  If not, it is
   likely the reader will not have enough information to decide what the
   notation means.  In addition, the author should remember machine
   parseable syntax is often unreadable by humans, and can make the
   specification excessive in length.  Therefore, syntax notations
   cannot take the place of a clearly written protocol description.





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


2.13  IANA Considerations

   The common use of the Internet standard track protocols by the
   Internet community requires that unique values be assigned to
   parameter fields.  An IETF WG does not have the authority to assign
   these values for the protocol it developed.  The Internet Assigned
   Numbers Authority (IANA) is the central authority for the assignment
   of unique parameter values for Internet protocols.  The authors of a
   developing protocol need to coordinate with the IANA the rules and
   procedures to manage the number space.  This coordination needs to be
   completed prior to submitting the Internet Draft to the standards
   track.

   A document is in preparation that discusses issues related to
   identifier assignment policy and guidelines on specific text to task
   IANA with its administration.  Standard authors should obtain a copy
   of it when it is finalized as an RFC.

   For further information on parameter assignment and current
   assignments, authors can reference STD 2, RFC 1700, "Assigned
   Numbers" (http://www.iana.org).

2.14  Network Management Considerations

   When relevant, each standard needs to discuss how to manage the
   protocol being specified.  This management process should be
   compatible with the current IETF Standard management protocol.  In
   addition, a MIB must be defined within the standard or in a companion
   document.  The MIB must be compatible with current Structure of
   Management Information (SMI) and parseable using a tool such as
   SMICng.  Where management or a MIB is not necessary this section of
   the standard should explain the reason it is not relevant to the
   protocol.

2.15  Scalability Considerations

   The standard should establish the limitations on the scale of use,
   e.g., tens of millions of sessions, gigabits per second, etc., and
   establish limits on the resources used, e.g., round trip time,
   computing resources, etc.  This is important because it establishes
   the ability of the network to accommodate the number of users and the
   complexity of their relations.  The STD 53/RFC 1939 has an example of
   such a section.  If this is not applicable to the protocol, an
   explanation of why not should be included.







Scott                    Best Current Practice                 [Page 10]