rfc2360.txt

RFC 的详细文档！


RFC 2360          Guide for Internet Standards Writers         June 1998


2.16  Network Stability

   A standard should discuss the relationship between network topology
   and convergence behavior.  As part of this, any topology that would
   be troublesome for the protocol should be identified.  Additionally,
   the specification should address any possible destabilizing events,
   and means by which the protocol resists or recovers from them.  The
   purpose is to insure that the network will stabilize, in a timely
   fashion, after a change, and that a combination of errors or events
   will not plunge the network into chaos.  The STD 34/RFC 1058, as an
   example, has sections which discuss how that protocol handles the
   affects of changing topology.

   The obvious case this would apply to is a routing protocol.  However,
   an application protocol could also have dynamic behavior that would
   affect the network.  For example, a messaging protocol could suddenly
   dump a large number of messages onto the network.  Therefore, editors
   of an application protocol will have to consider possible impacts to
   network stability and convergence behavior.

2.17 Internationalization

   At one time the Internet had a geographic boundary and was English
   only.  The Internet now extends internationally.  Therefore, data is
   interchanged in a variety of languages and character sets.  In order
   to meet the requirements of an international Internet, a standard
   must conform to the policies stated in BCP 18/RFC 2277, "IETF Policy
   on Character Sets and Languages".

2.18  Glossary

   Every standards track RFC should have a glossary, as words can have
   many meanings.  By defining any new words introduced, the author can
   avoid confusing or misleading the implementers.  The definition
   should appear on the word's first appearance within the text of the
   protocol specification, and in a separate glossary section.

   It is likely that definition of the protocol will rely on many words
   frequently used in IETF documents.  All authors must be knowledgeable
   of the common accepted definitions of these frequently used words.
   FYI 18/RFC 1983, "Internet Users' Glossary", provides definitions
   that are specific to the Internet.  Any deviation from these
   definitions by authors is strongly discouraged.  If circumstances
   require deviation, an author should state that he is altering the
   commonly accepted definition, and provide rationale as to the
   necessity of doing so.  The altered definition must be included in
   the Glossary section.




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


   If the author uses the word as commonly defined, she does not have to
   include the definition in the glossary.  As a minimum, FYI 18/RFC
   1983 should be referenced as a source.

3  Specific Guidelines

   The following are guidelines on how to present specific technical
   information in standards.

3.1  Packet Diagrams

   Most link, network, and transport layer protocols have packet
   descriptions.  Packet diagrams included in the standard are very
   helpful to the reader.  The preferred form for packet diagrams is a
   sequence of long words in network byte order, with each word
   horizontal on the page and bit numbering at the top:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Prio. |                   Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In cases where a packet is strongly byte-aligned rather than word-
   aligned (e.g., when byte-boundary variable-length fields are used),
   display packet diagrams in a byte-wide format.  The author can use
   different height boxes for short and long words, and broken boxes for
   variable-length fields:

                           0 1 2 3 4 5 6 7
                          +-+-+-+-+-+-+-+-+
                          |    Length N   |
                          +-+-+-+-+-+-+-+-+
                          |               |
                          +    Address    +
                                 ...
                          +   (N bytes)   +
                          |               |
                          +-+-+-+-+-+-+-+-+
                          |               |
                          +  2-byte field +
                          |               |
                          +-+-+-+-+-+-+-+-+








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


3.2  Summary Tables

   The specifications of some protocols are particularly lengthy,
   sometimes covering a hundred pages or more.  In such cases, the
   inclusion of a summary table can reduce the risk of conformance
   failure by an implementation through oversight.  A summary table
   itemizes what in a protocol is mandatory, optional, or prohibited.
   Summary tables do not guarantee conformance, but serve to assist an
   implementer in checking that they have addressed all protocol
   features.

   The summary table will consist of, as a minimum, four (4) columns:
   Protocol Feature, Section Reference, Status, and
   References/Footnotes.  The author may add columns if they further
   explain or clarify the protocol.

   In the Protocol Feature column, list the protocol's characteristics,
   for example, a command word.  We recommend grouping series of related
   transactions under descriptive headers, for example, RECEPTION.

   Section reference directs the implementer to the section, paragraph,
   or page that describes the protocol feature in detail.

   Status indicates whether the feature is mandatory, optional, or
   prohibited.  The author can use either a separate column for each
   possibility, or a single column with appropriate codes.  These codes
   need to be defined at the start of the summary table to avoid
   confusion.  Possible status codes:

       M    - must or mandatory
       MN   - must not
       O    - optional
       S    - should
       SN   - should not
       X    - prohibited

   In the References/Footnotes column authors can point to other RFCs
   that are necessary to consider in implementing this protocol feature,
   or any footnotes necessary to explain the implementation further.

   The STD 3/RFC 1122/RFC 1123 provides examples of summary tables.

3.3  State Machine Descriptions

   A convenient method of presenting a protocol's behavior is as a
   state-machine model.  That is, a protocol can be described by a
   series of states resulting from a command, operation, or transaction.
   State-machine models define the variables and constants that



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


   establish a state, the events that cause state transitions and the
   actions that result from those transitions.  Through these models, an
   understanding of the protocol's dynamic operation as sequence of
   state transitions that occur for any given event is possible.  State
   transitions can be detailed by diagrams, tables, or time lines.

   Note that state-machine models are never to take the place of
   detailed text description of the specification.  They are adjuncts to
   the text.  The protocol specification shall always take precedence in
   the case of a conflict.

   When using a state transition diagram, show each possible protocol
   state as a box connected by state transition arcs.  The author should
   label each arc with the event that causes the transition, and, in
   parentheses, any actions taken during the transition.  The STD 5/RFC
   1112 provides an example of such a diagram.  As ASCII text is the
   preferred storage format for RFCs, only simple diagrams are possible.
   Tables can summarize more complex or extensive state transitions.

   In a state transition table, the different events are listed
   vertically and the different states are listed horizontally.  The
   form, action/new state, represents state transitions and actions.
   Commas separate multiple actions, and succeeding lines are used as
   required.  The authors should present multiple actions in the order
   they must be executed, if relevant.  Letters that follow the state
   indicate an explanatory footnote.  The dash ('-') indicates an
   illegal transition.  The STD 51/RFC 1661 provides an example of such
   a state transition table.  The initial columns and rows of that table
   follow as an example:

           | State
           |    0         1         2         3         4         5
     Events| Initial   Starting  Closed    Stopped   Closing   Stopping
     ------+-----------------------------------------------------------
      Up   |    2     irc,scr/6     -         -         -         -
      Down |    -         -         0       tls/1       0         1
      Open |  tls/1       1     irc,scr/6     3r        5r        5r
      Close|    0       tlf/0       2         2         4         4
           |
       TO+ |    -         -         -         -       str/4     str/5
       TO- |    -         -         -         -       tlf/2     tlf/3

   The STD 18/RFC 904 also presents state transitions in table format.
   However, it lists transitions in the form n/a, where n is the next
   state and a represents the action.  The method in RFC 1661 is
   preferred as new state logically follows action.  In addition, RFC
   904's Appendix C models transitions as the Cartesian product of two
   state machines.  This is a more complex representation that may be



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


   difficult to comprehend for those readers that are unfamiliar with
   the format.  We recommend that authors present tables as defined in
   the previous paragraph.

   A final method of representing state changes is by a time line.  The
   two sides of the time line represent the machines involved in the
   exchange.  The author lists the states the machines enter as time
   progresses (downward) along the outside of time line.  Within the
   time line, show the actions that cause the state transitions.  An
   example:

            client                                     server

               |                                          |
               |                                          |   LISTEN
   SYN_SENT    |-----------------------                   |
               |                       \ syn j            |
               |                        ----------------->|   SYN_RCVD
               |                                          |
               |                        ------------------|
               |        syn k, ack j+1 /                  |
   ESTABLISHED |<----------------------                   |
               |                                          |

4  Document Checklist

   The following is a checklist based on the above guidelines that can
   be applied to a document:

   o Does it identify the security risks?  Are countermeasures for each
     potential attack provided?  Are the effects of the security
     measures on the operating environment detailed?
   o Does it explain the purpose of the protocol or procedure?  Are the
     intended functions and services addressed?  Does it describe how it
     relates to existing protocols?
   o Does it consider scaling and stability issues?
   o Have procedures for assigning numbers been coordinated with IANA?
   o Does it discuss how to manage the protocol being specified?  Is a
     MIB defined?
   o Is a target audience defined?
   o Does it reference or explain the algorithms used in the protocol?
   o Does it give packet diagrams in recommended form, if applicable?
   o Is there a change log?
   o Does it describe differences from previous versions, if
     applicable?
   o Does it separate explanatory portions of the document from
     requirements?
   o Does it give examples of protocol operation?



Scott                    Best Current Practice                 [Page 15]