draft-ietf-stdguide-ops-06.txt   rfc2360.txt 
Network Working Group G. Scott, Editor Network Working Group G. Scott, Editor
INTERNET DRAFT Defense Information Systems Agency Request for Comments: 2360 Defense Information Systems Agency
March 1998 BCP: 22 June 1998
Category: Best Current Practice
Guide for Internet Standards Writers Guide for Internet Standards Writers
<draft-ietf-stdguide-ops-06.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document specifies an Internet Best Current Practices for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet Community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Distribution of this memo is unlimited.
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is not appropriate to use Internet Drafts as reference
material or to cite them other than as a "working draft" or "work in
progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this document is unlimited. Copyright Notice
This Internet Draft expires on 15 September 1998. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This document is a guide for Internet standard writers. It defines This document is a guide for Internet standard writers. It defines
those characteristics that make standards coherent, unambiguous, and those characteristics that make standards coherent, unambiguous, and
easy to interpret. Also, it singles out usage believed to have led easy to interpret. In addition, it singles out usage believed to
to unclear specifications, resulting in non-interoperable have led to unclear specifications, resulting in non-interoperable
interpretations in the past. These guidelines are to be used with interpretations in the past. These guidelines are to be used with
RFC 1543, "Instructions to RFC Authors." RFC 2223, "Instructions to RFC Authors".
This version of the document is a draft.
CHANGES FROM DRAFT -04
A paragraph pointing to a pending document that further addresses
security was updated.
References to RFC 1583 were changed to RFC 2178 which obsoleted it.
Editorial changes and corrections were also made.
CHANGES FROM DRAFT -05
A sentence pointing to a pending document that further addresses IANA
considerations was added to section 2.13. The current draft of that
document is draft-iesg-iana-considerations-02.txt. A clause stating
that the IANA established the assignment policies was removed since
it appeared to conflict with the intent of the referenced ID. Place
holders for the BCP and RFC number have been added to the text and
reference section.
A new section (2.5) requiring change logs as documents progress along
the standards track was added.
References to RFC 2044 were changed to RFC 2279 which obsoleted it.
Spelling and grammar corrections were made.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 General Guidelines . . . . . . . . . . . . . . . . . . . . . . 3 2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2
2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . . 3 2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3
2.2 Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4
2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . . . 7 2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6
2.7 Decision History . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6
2.8 Response to Out of Specification Behavior . . . . . . . . . . . 7 2.8 Response to Out of Specification Behavior . . . . . . . . . 6
2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . . . 8 2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7
2.10 Handling of Protocol Options . . . . . . . . . . . . . . . . . 9 2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8
2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . . . 10 2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9
2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . . 10 2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9
2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10
2.14 Network Management Considerations . . . . . . . . . . . . . . . 11 2.14 Network Management Considerations . . . . . . . . . . . . 10
2.15 Scalability Considerations . . . . . . . . . . . . . . . . . . 11 2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10
2.16 Network Stability . . . . . . . . . . . . . . . . . . . . . . . 12 2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11
2.17 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11
3 Specific Guidelines . . . . . . . . . . . . . . . . . . . . . . 13 2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12
3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12
3.3 State Machine Descriptions . . . . . . . . . . . . . . . . . . 14 3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13
3.4 Character Sets . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13
4 Document Checklist . . . . . . . . . . . . . . . . . . . . . . 16 4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 5 Security Considerations . . . . . . . . . . . . . . . . . 16
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6 References . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18
8 Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 19 8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18
9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19
10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20
1 Introduction 1 Introduction
This document is a guide for Internet standard writers. It offers This document is a guide for Internet standard writers. It offers
guidelines on how to write a standards-track document with clarity, guidelines on how to write a standards-track document with clarity,
precision, and completeness. These guidelines are based on both precision, and completeness. These guidelines are based on both
prior successful and unsuccessful IETF specification experiences. prior successful and unsuccessful IETF specification experiences.
These guidelines are to be used with RFC 1543, "Instructions to RFC These guidelines are to be used with RFC 2223, "Instructions to RFC
Authors," or its update. Note that some guidelines may not apply in Authors", or its update. Note that some guidelines may not apply in
certain situations. certain situations.
The goal is to increase the possibility that multiple implementations The goal is to increase the possibility that multiple implementations
of a protocol will interoperate. Writing specifications to these of a protocol will interoperate. Writing specifications to these
guidelines will not guarantee interoperability. However, a guidelines will not guarantee interoperability. However, a
recognized barrier to the creation of interoperable protocol recognized barrier to the creation of interoperable protocol
implementations is unclear specifications. implementations is unclear specifications.
Many will benefit from having well-written protocol specifications. Many will benefit from having well-written protocol specifications.
Implementors will have a better chance to conform to the protocol Implementers will have a better chance to conform to the protocol
specification. Protocol testers can use the specification to derive specification. Protocol testers can use the specification to derive
unambiguous testable statements. Purchasers and users of the unambiguous testable statements. Purchasers and users of the
protocol will have a better understanding of its capabilities. protocol will have a better understanding of its capabilities.
For further information on the process for standardizing protocols For further information on the process for standardizing protocols
and procedures please refer to BCP 9/RFC 2026, "The Internet and procedures please refer to BCP 9/RFC 2026, "The Internet
Standards Process -- Revision 3." Also, some considerations for Standards Process -- Revision 3". In addition, some considerations
protocol design are given in RFC 1958, "Architectural Principles of for protocol design are given in RFC 1958, "Architectural Principles
the Internet." of the Internet".
2 General Guidelines 2 General Guidelines
It is important that multiple readers and implementors of a standard It is important that multiple readers and implementers of a standard
have the same understanding of a document. To this end, information have the same understanding of a document. To this end, information
should be orderly and detailed. The following are general guidelines should be orderly and detailed. The following are general guidelines
intended to help in the production of such a document. The IESG may 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 require that all or some of the following sections appear in a
standards track document. standards track document.
2.1 Discussion of Security 2.1 Discussion of Security
If the Internet is to achieve its full potential in commercial, If the Internet is to achieve its full potential in commercial,
governmental, and personal affairs, it must assure users that their governmental, and personal affairs, it must assure users that their
information transfers are free from tampering or compromise. Well- information transfers are free from tampering or compromise. Well-
written security sections in standards-track documents can help written security sections in standards-track documents can help
promote the confidence level required. For an implementor will find promote the confidence level required. Above all, new protocols and
it easier to provide the security measures specified. While users practices must not worsen overall Internet security.
will understand the security measures, and so have a higher level of
trust in the Internet. Above all, new protocols and practices must
not worsen overall Internet security.
A significant threat to the Internet are those individuals who are
motivated and capable of exploiting circumstances, events, or
vulnerabilities of the system to cause harm. Also, 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 A significant threat to the Internet comes from those individuals who
subject to attack. They are responsible for determining what attacks are motivated and capable of exploiting circumstances, events, or
are possible, and for detailing the nature of the attacks in the vulnerabilities of the system to cause harm. In addition, deliberate
document. Otherwise, they must convincingly argue that attack is not or inadvertent user behavior may expose the system to attack or
realistic in a specific environment, and restrict the use of the exploitation. The harm could range from disrupting or denying
protocol to that environment. 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).
This discussion of the threat model and other assumptions should Standards authors must accept that the protocol they specify will be
appear early in the standard. Doing so will establish a basis for subject to attack. They are responsible for determining what attacks
the further discussion of security throughout the document. 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 After the document has exhaustively identified the security risks the
protocol is exposed to, the authors must formulate and detail a protocol is exposed to, the authors must formulate and detail a
defense against those attacks. They must discuss the applicable defense against those attacks. They must discuss the applicable
countermeasures employed, or the risk the user is accepting by using countermeasures employed, or the risk the user is accepting by using
the protocol. The countermeasures may be provided by a protocol the protocol. The countermeasures may be provided by a protocol
mechanism or by reliance on external mechanisms. Authors should be mechanism or by reliance on external mechanisms. Authors should be
knowledgeable of existing security mechanisms, and reuse them if knowledgeable of existing security mechanisms, and reuse them if
practical. When a cryptographic algorithm is used, the protocol practical. When a cryptographic algorithm is used, the protocol
should be written to permit its substitution with another algorithm should be written to permit its substitution with another algorithm
in the future. Finally, the authors should discuss implementation in the future. Finally, the authors should discuss implementation
hints or guidelines, e.g., how to deal with untrustworthy data or hints or guidelines, e.g., how to deal with untrustworthy data or
peer systems. peer systems.
Additionally, the effects the security measures have on the Security measures will have an impact within the environment that
protocol's use and performance should be discussed. Security they are used. Perhaps users will now be constrained on what they
measures will have an impact on the environment they are used in. can do in the Internet, or will experience degradation in the speed
Perhaps users will now be locked out of portions of the Internet of service. The effects the security measures have on the protocol's
previously open to them, or users will experience a degradation in use and performance should be discussed.
the speed of service. The user may decided to accept a greater risk
in exchange for improved access or service. But the user must be
able to make an informed decision. They need to understand the risks
they are facing and the costs of reducing their risk.
The discussion of security can be concentrated in the Security The discussion of security can be concentrated in the Security
Considerations section of the document, or throughout the document Considerations section of the document, or throughout the document
where it is relevant to particular parts of the specification. An where it is relevant to particular parts of the specification. An
advantage of the second approach is that it ensures security is an advantage of the second approach is that it ensures security is an
integral part of the protocol's development, rather than something integral part of the protocol's development, rather than something
that is a follow-on or secondary effort. If security is discussed that is a follow-on or secondary effort. If security is discussed
throughout the document, the Security Considerations section must throughout the document, the Security Considerations section must
summarized and make reference to the appropriate specification summarize and refer to the appropriate specification sections. This
sections. This will insure that the protocol's security measures are will insure that the protocol's security measures are emphasized to
emphasized to implementor and user both. implementer and user both.
Within the Security Considerations section a discussion of the path Within the Security Considerations section, a discussion of the path
not taken may be appropriate. There may be several security not taken may be appropriate. There may be several security
mechanisms that were not selected for a variety of reasons: cost or mechanisms that were not selected for a variety of reasons: cost or
difficulty of implementation; ineffectiveness for a given network difficulty of implementation, or ineffectiveness for a given network
environment; or export control. By listing the mechanisms they did environment. By listing the mechanisms they did not use and the
not use and the reasons, editors can demonstrate that the protocol's reasons, editors can demonstrate that the protocol's WG gave security
WG gave security the necessary thought. Also, this gives the the necessary thought. In addition, this gives the protocol's users
protocol's users the information they need to consider whether one of the information they need to consider whether one of the non-selected
the non-selected mechanisms would be better suited to their mechanisms would be better suited to their particular requirements.
particular requirements.
A document giving further guidance on security topics is in A document giving further guidance on security topics is in
development. Authors should obtain a copy of the completed RFC to development. Authors should obtain a copy of the completed RFC to
help them prepare the security portion of the standard. help them prepare the security portion of the standard.
Finally, it is no longer acceptable that Security Considerations Finally, it is no longer acceptable that Security Considerations
sections consist solely of statements to the effect that security was sections consist solely of statements to the effect that security was
not considered in preparing the standard. not considered in preparing the standard.
Some examples of Security Considerations sections are found in Some examples of Security Considerations sections are found in STD
STD 33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939. 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 2.2 Protocol Description
Standards track documents must include a description of the protocol. Standards track documents must include a description of the protocol.
This description must address the protocol's purpose, intended This description must address the protocol's purpose, intended
functions, services it provides, and, the arena, circumstances, or functions, services it provides, and, the arena, circumstances, or
any special considerations of the protocol's use. any special considerations of the protocol's use.
The authors of a protocol specification will have a great deal of The authors of a protocol specification will have a great deal of
knowledge as to the reason for the protocol. However, the reader is knowledge as to the reason for the protocol. However, the reader is
more likely to have general networking knowledge and experience, more likely to have general networking knowledge and experience,
rather than expertise in a particular protocol. An explanation of rather than expertise in a particular protocol. An explanation of
it's purpose and use will give the reader a reference point for it's purpose and use will give the reader a reference point for
understanding the protocol, and where it fits in the Internet. The understanding the protocol, and where it fits in the Internet. The
Draft Standard RFC 2178 was recommended to the STDGUIDE working guide STD 54/RFC 2328 was recommended to the STDGUIDE working group as
as providing a good example of this in it's "Protocol Overview" providing a good example of this in its "Protocol Overview" section.
section.
The protocol's general description must also provide information on The protocol's general description must also provide information on
the relationship between the different parties to the protocol. the relationship between the different parties to the protocol. This
This can be done by showing typical packet sequences. can be done by showing typical packet sequences.
This also applies to the algorithms used by a protocol. A detailed This also applies to the algorithms used by a protocol. A detailed
description of the algorithms or citation of readily available description of the algorithms or citation of readily available
references that give such a description is necessary. references that give such a description is necessary.
2.3 Target Audience 2.3 Target Audience
RFCs have been written with many different purposes, ranging from the RFCs have been written with many different purposes, ranging from the
technical to the administrative. Those written as standards should technical to the administrative. Those written as standards should
clearly identify the intended audience, for example, designers, clearly identify the intended audience, for example, designers,
implementors, testers, help desk personnel, educators, end users, or implementers, testers, help desk personnel, educators, end users, or
others. If there are multiple audiences being addressed in the others. If there are multiple audiences being addressed in the
document, what sections are for each audience needs to be identified. document, the section for each audience needs to be identified. The
The goal is to help the reader discover and focus on what they have 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, turned to the document for, and avoid what they may find confusing,
diverting, or extraneous. diverting, or extraneous.
2.4 Level of Detail 2.4 Level of Detail
The author should consider what level of descriptive detail best The author should consider what level of descriptive detail best
conveys the protocol's intent. Concise text has several advantages. conveys the protocol's intent. Concise text has several advantages.
It makes the document easier to read. Such text reduces the chance It makes the document easier to read. Such text reduces the chance
for conflict between different portions of the specification. The for conflict between different portions of the specification. The
reader can readily identify the required protocol mechanisms in the reader can readily identify the required protocol mechanisms in the
standard. Also, it makes it easier to identify the requirements for standard. In addition, it makes it easier to identify the
protocol implementation. A disadvantage of concise descriptions is requirements for protocol implementation. A disadvantage of concise
that a reader may not fully comprehend the reasoning behind the descriptions is that a reader may not fully comprehend the reasoning
protocol, and thus make assumptions that will lead to implementation behind the protocol, and thus make assumptions that will lead to
errors. implementation errors.
Longer descriptions may be necessary to explain purpose, background, Longer descriptions may be necessary to explain purpose, background,
rationale, implementation experience, or to provide tutorial rationale, implementation experience, or to provide tutorial
information. This helps the reader understand the protocol. Yet information. This helps the reader understand the protocol. Yet,
several dangers exist with lengthy text. Finding the protocol several dangers exist with lengthy text. Finding the protocol
requirements in the text is difficult or confusing. The same requirements in the text is difficult or confusing. The same
mechanism may have multiple descriptions, which leads to mechanism may have multiple descriptions, which leads to
misinterpretation or conflict. Finally, it is more difficult to misinterpretation or conflict. Finally, it is more difficult to
comprehend, a consideration as English is not the native language of comprehend, a consideration as English is not the native language of
the many worldwide readers of IETF standards. the many worldwide readers of IETF standards.
One approach is to divide the standard into sections: one describing One approach is to divide the standard into sections: one describing
the protocol concisely, while another section consists of explanatory the protocol concisely, while another section consists of explanatory
text. The STD 3/RFC 1122/RFC 1123 and Draft Standard RFC 2178 text. The STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 provides
provides examples of this method. examples of this method.
2.5 Change Logs 2.5 Change Logs
As a document moves along the standards track, from Proposed to Draft 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 or Draft to Full, or cycles in level, it will undergo changes due to
better understanding of the protocol or implementation experience. better understanding of the protocol or implementation experience. To
To help it in tracking the progress being made, the IESG requires help implementers track the changes being made a log showing what has
each document to have a log showing what has changed from the changed from the previous version of the specification is required
pervious version of the specification. (see Appendix).
2.6 Protocol Versions 2.6 Protocol Versions
Often the standard is specifying a new version of an existing Often the standard is specifying a new version of an existing
protocol. In such a case, the authors should detail the differences protocol. In such a case, the authors should detail the differences
between the previous version and the new version. This should between the previous version and the new version. This should
include the rationale for the changes, for example, implementation include the rationale for the changes, for example, implementation
experience, changes in technology, responding to user demand, etc. experience, changes in technology, responding to user demand, etc.
2.7 Decision History 2.7 Decision History
In standards development, reaching consensus requires making In standards development, reaching consensus requires making
difficult choices. These choices are made through working group difficult choices. These choices are made through working group
discussions or from implementation experience. By including the discussions or from implementation experience. By including the
basis for a contentious decision, the author can prevent future basis for a contentious decision, the author can prevent future
revisiting of these disagreements when the original parties have revisiting of these disagreements when the original parties have
moved on. Also, the knowledge of the "why" is as useful to an moved on. In addition, the knowledge of the "why" is as useful to an
implementor as the description of "how." For example, the implementer as the description of "how". For example, the
alternative not taken may have been simpler to implement, so alternative not taken may have been simpler to implement, so
including the reasons behind the choice may prevent future including the reasons behind the choice may prevent future
implementors from taking nonstandard shortcuts. implementers from taking nonstandard shortcuts.
2.8 Response to Out of Specification Behavior 2.8 Response to Out of Specification Behavior
Detail descriptions of the actions taken in case of behavior that is 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 deviant from or exceeds the specification is useful. This is an area
where implementors often differ in opinion as to the appropriate where implementers often differ in opinion as to the appropriate
response. By specifying a common response, the standard author can response. By specifying a common response, the standard author can
reduce the risk that different implementations will come in to reduce the risk that different implementations will come in to
conflict. conflict.
The standard should describe responses to behavior explicitly The standard should describe responses to behavior explicitly
forbidden or out of the boundaries defined by the specification. Two forbidden or out of the boundaries defined by the specification. Two
possible approaches to such cases are discarding, or invoking possible approaches to such cases are discarding, or invoking error-
error-handling mechanisms. If discarding is chosen, detailing the handling mechanisms. If discarding is chosen, detailing the
disposition may be necessary. For instance, treat dropped frames as disposition may be necessary. For instance, treat dropped frames as
if they were never received, or reset an existing connection or if they were never received, or reset an existing connection or
adjacency state. adjacency state.
The specification should describe actions taken when critical The specification should describe actions taken when a critical
resource or performance scaling limits are exceeded. This is resource or a performance-scaling limit is exceeded. This is
necessary for cases where a risk of network degradation or necessary for cases where a risk of network degradation or
operational failure exists. In such cases, a consistent behavior operational failure exists. In such cases, a consistent behavior
between implementations is necessary. between implementations is necessary.
2.9 The Liberal/Conservative Rule 2.9 The Liberal/Conservative Rule
A rule, first stated in STD 5/RFC 791, recognized as having benefits A rule, first stated in STD 5/RFC 791, recognized as having benefits
in implementation robustness and interoperability is: 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 "Be liberal in what you accept, and
to deal with every conceivable error received. Caution is urged in conservative in what you send".
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 Or establish restrictions on what a protocol transmits, but be able
authors specify send and receive behavior separately. The to deal with every conceivable error received. Caution is urged in
description of reception will require the most detailing. For applying this approach in standards track protocols. It has in the
implementations will be expected to accept any packet from the past lead to conflicts between vendors when interoperability fails.
network without failure or malfunction. Therefore, the actions taken The sender accuses the receiver of failing to be liberal enough, and
to achieve that result, need to be laid out in the protocol the receiver accuses the sender of not being conservative enough.
specification. Standard authors should concern themselves on Therefore, the author is obligated to provide extensive detail on
achieving a level of cooperation that limits network disruption, not send and receive behavior.
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 To avoid any confusion between the two, recommend that standard
the packets. Two approaches are available, either using as much of authors specify send and receive behavior separately. The
the packet's content as possible, or invoking error procedures. The description of reception will require the most detailing. For
author should specify a dividing line on when to take which approach. 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 A case for consideration is that of a routing protocol, where
acceptance of flawed information can cause network failure. For acceptance of flawed information can cause network failure. For
protocols such as this, the specification should identify packets protocols such as this, the specification should identify packets
that could have differing interpretations and mandate that they be that could have different interpretations and mandate that they be
either rejected completely or the nature of the attempt to recover rejected completely or the nature of the attempt to recover some
some information from them. For example, routing updates that information from them. For example, routing updates that contain
contain more data than the tuple count shows. The protocol authors more data than the tuple count shows. The protocol authors should
should consider whether some trailing data can be accepted as consider whether some trailing data can be accepted as additional
additional routes, or to reject the entire packet as suspect because routes, or to reject the entire packet as suspect because it is non-
it is non-conformant. conformant.
2.10 Handling of Protocol Options 2.10 Handling of Protocol Options
Specifications with many optional features increase the complexity of Specifications with many optional features increase the complexity of
the implementation and the chance of non-interoperable the implementation and the chance of non-interoperable
implementations. The danger is that different implementations may implementations. The danger is that different implementations may
specify some combination of options that are unable to interoperate specify some combination of options that are unable to interoperate
with each other. with each other.
As the document moves along the standard track, implementation As the document moves along the standard track, implementation
experience shall determine the need for each option. Implementation experience shall determine the need for each option. Implementation
shall show whether the option should be a mandatory part of the 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 protocol or remain an option. If an option is not implemented as the
document advances, it must be removed from the protocol before it document advances, it must be removed from the protocol before it
reaches draft standard status. reaches draft standard status.
Therefore, options shall only be present in a protocol to address a Therefore, options shall only be present in a protocol to address a
real requirement. For example, options can support future real requirement. For example, options can support future
extensibility of the protocol, a particular market, e.g., the extensibility of the protocol, a particular market, e.g., the
financial industry, or a specific network environment, e.g., a financial industry, or a specific network environment, e.g., a
network constrained by limited bandwidth. They shall not be included network constrained by limited bandwidth. They shall not be included
as a means to "buy-off" a minority opinion. Omission of the optional as a means to "buy-off" a minority opinion. Omission of the optional
item shall have no interoperability consequences for the item shall have no interoperability consequences for the
implementation that does so. implementation that does so.
One possible approach is to document protocol options in a separate One possible approach is to document protocol options in a separate
specification. Doing so would make it clear that the options are not specification. This keeps the main protocol specification clean and
integral to the implementation of the protocol, and would keep the makes it clear that the options are not required to implement the
main protocol specification clean. Regardless of whether they appear protocol. Regardless of whether they appear within the specification
within the specification or in a separate document, the text shall or in a separate document, the text shall discuss the full
discuss the full implications of either using the option or not, and implications of either using the option or not, and the case for
the case for choosing either course. As part of this, the author choosing either course. As part of this, the author needs to
needs to consider and describe how the options are intended to be consider and describe how the options are used alongside other
used alongside other protocols. The text must also specify the protocols. The text must also specify the default conditions of all
default conditions of all options. For security checking options the options. For security checking options the default condition is on
default condition is on or enabled. or enabled.
There may be occasions when mutually exclusive options appear within There are occasions when mutually exclusive options appear within the
a protocol. That is, the implementation of an optional feature protocol. That is, the implementation of an optional feature
precludes the implementation of the other optional feature. For precludes the implementation of the other optional feature. For
clarity, the author needs to state when to implement one or the 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 other, what the effect of choosing one over the other is, and what
problems the implementor or user may face. The choice of one or the problems the implementer or user may face. The choice of one or the
other options shall have no interoperability consequences between other options shall have no interoperability consequences between
multiple implementations. multiple implementations.
2.11 Indicating Requirement Levels 2.11 Indicating Requirement Levels
The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate
Requirement Level," defines several words that are necessary for Requirement Level", defines several words that are necessary for
writing a standards track document. Editors of standards track writing a standards track document. Editors of standards track
documents must not deviate from the definitions provided as they are documents must not deviate from the definitions provided as they are
intended to identify interoperability requirements or limit intended to identify interoperability requirements or limit
potentially harmful behavior. The capitalization of these words is potentially harmful behavior. The capitalization of these words is
the accepted norm, and can help in identifying an unintentional or the accepted norm, and can help in identifying an unintentional or
unreasonable requirement. These words have been used in several RFCs unreasonable requirement. These words have been used in several RFCs
the first instances being STD 3/RFC 1122/RFC 1123. the first instances being STD 3/RFC 1122/RFC 1123.
2.12 Notational Conventions 2.12 Notational Conventions
Formal syntax notations can be used to define complicated protocol Formal syntax notations can be used to define complicated protocol
concepts or data types, and to specify values of these data types. concepts or data types, and to specify values of these data types.
This permits the protocol to be written without concern on how the This permits the protocol to be written without concern on how the
implementation is constructed, or how the data type is represented implementation is constructed, or how the data type is represented
during transfer. The specification is simplified because it can be during transfer. The specification is simplified because it can be
presented as "axioms" that will be proven by implementation. presented as "axioms" that will be proven by implementation.
The formal specification of the syntax used should be referenced in The formal specification of the syntax used should be referenced in
the text of the standard. Any extensions, subsets, alterations, or the text of the standard. Any extensions, subsets, alterations, or
exceptions to that formal syntax should be defined within the exceptions to that formal syntax should be defined within the
standard. standard.
The STD 11/RFC 822 provides an example of this. In RFC 822 (Section 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 2 and Appendix D) the Backus-Naur Form (BNF) meta-language was
extended to make its representation smaller and easier to understand. extended to make its representation smaller and easier to understand.
Another example is STD 16/RFC 1155 (Section 3.2) where a subset of Another example is STD 16/RFC 1155 (Section 3.2) where a subset of
the Abstract Syntax Notation One (ASN.1) is defined. the Abstract Syntax Notation One (ASN.1) is defined.
The author of a standards track protocol needs to consider several The author of a standards track protocol needs to consider several
things before they use a formal syntax notation. Is the formal things before they use a formal syntax notation. Is the formal
specification language being used parseable by an existing machine? specification language being used parseable by an existing machine?
If no parser exists, is there enough information provided in the If no parser exists, is there enough information provided in the
specification to permit the building of a parser? If not, it is specification to permit the building of a parser? If not, it is
likely the reader will not have enough information to decide what the likely the reader will not have enough information to decide what the
notation means. Also, the author should remember machine parseable notation means. In addition, the author should remember machine
syntax is often unreadable by humans, and can make the specification parseable syntax is often unreadable by humans, and can make the
excessive in length. Therefore, syntax notations cannot take the specification excessive in length. Therefore, syntax notations
place of a clearly written protocol description. cannot take the place of a clearly written protocol description.
2.13 IANA Considerations 2.13 IANA Considerations
The common use of the Internet standard track protocols by the The common use of the Internet standard track protocols by the
Internet community requires that unique values be assigned to Internet community requires that unique values be assigned to
parameter fields. An IETF WG does not have the authority to assign parameter fields. An IETF WG does not have the authority to assign
these values for the protocol it is working on. The Internet these values for the protocol it developed. The Internet Assigned
Assigned Numbers Authority (IANA) is the central coordinator for the Numbers Authority (IANA) is the central authority for the assignment
assignment of unique parameter values for Internet protocols. The of unique parameter values for Internet protocols. The authors of a
authors of a developing protocol that use a link, socket, port, developing protocol need to coordinate with the IANA the rules and
protocol, etc., need to coordinate with the IANA the rules and procedures to manage the number space. This coordination needs to be
procedures to be used to register constants and tags. This completed prior to submitting the Internet Draft to the standards
coordination needs to be completed prior to submitting the internet track.
draft to the standards track. For further information on parameter
assignment and current assignments, authors can reference STD 2/RFC A document is in preparation that discusses issues related to
1700, "Assigned Numbers." The BCP /RFC , "Guidelines for Writing an identifier assignment policy and guidelines on specific text to task
IANA Considerations Section in RFCs," gives further guidance on IANA with its administration. Standard authors should obtain a copy
determining indentifier assignment policy and providing IANA with of it when it is finalized as an RFC.
instructions to administer that policy.
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 2.14 Network Management Considerations
When relevant, each standard needs to discuss how to manage the When relevant, each standard needs to discuss how to manage the
protocol being specified. This management process should be protocol being specified. This management process should be
compatible with the current IETF Standard management protocol. Also compatible with the current IETF Standard management protocol. In
a MIB must be defined within the standard or in a companion document. addition, a MIB must be defined within the standard or in a companion
The MIB must be compatible with current Structure of Management document. The MIB must be compatible with current Structure of
Information (SMI) and parseable using a tool such as SMICng. Where Management Information (SMI) and parseable using a tool such as
management or a MIB is not necessary this section of the standard SMICng. Where management or a MIB is not necessary this section of
should explain the reason it is not relevant to the protocol. the standard should explain the reason it is not relevant to the
protocol.
2.15 Scalability Considerations 2.15 Scalability Considerations
The standard should establish the limitations on the scale of use, The standard should establish the limitations on the scale of use,
e.g., tens of millions of sessions, gigabits per second, etc., and e.g., tens of millions of sessions, gigabits per second, etc., and
establish limits on the resources used, e.g, round trip time, establish limits on the resources used, e.g., round trip time,
computing resources, etc. This is important because it establishes computing resources, etc. This is important because it establishes
the ability of the network to accommodate the number of users and the 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 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 such a section. If this is not applicable to the protocol, an
explanation of why not should be included. explanation of why not should be included.
2.16 Network Stability 2.16 Network Stability
A standard should discuss the relationship between network topology A standard should discuss the relationship between network topology
and convergence behavior. As part of this, any topology which would and convergence behavior. As part of this, any topology that would
be troublesome for the protocol should be identified. Additionally, be troublesome for the protocol should be identified. Additionally,
the specification should address any possible destablizing events, the specification should address any possible destabilizing events,
and how the protocol resists or recovers from them. The purpose is and means by which the protocol resists or recovers from them. The
to insure that the network will stabilize, in a timely fashion, after purpose is to insure that the network will stabilize, in a timely
a change, and that a combination of errors or events will not plunge fashion, after a change, and that a combination of errors or events
the network into chaos. The STD 34/RFC 1058, as an example, has will not plunge the network into chaos. The STD 34/RFC 1058, as an
sections which discuss how that protocol handles the affects of example, has sections which discuss how that protocol handles the
changing topology. affects of changing topology.
The obvious case this would apply to is a routing protocol. However, The obvious case this would apply to is a routing protocol. However,
an application protocol could also have dynamic behavior that would an application protocol could also have dynamic behavior that would
affect the network. For example, a messaging protocol could suddenly affect the network. For example, a messaging protocol could suddenly
dump a large number of messages onto the network. Therefore, editors dump a large number of messages onto the network. Therefore, editors
of an application protocol will have to consider possible impacts to of an application protocol will have to consider possible impacts to
network stability and convergence behavior. network stability and convergence behavior.
2.17 Glossary 2.17 Internationalization
Every standards track RFC should have a glossary, as words can have At one time the Internet had a geographic boundary and was English
many meanings. By defining any new words introduced, the author can only. The Internet now extends internationally. Therefore, data is
avoid confusing or misleading the implementer. The definition should interchanged in a variety of languages and character sets. In order
appear on the word's first appearance within the text of the protocol to meet the requirements of an international Internet, a standard
specification, and in a separate glossary section. must conform to the policies stated in BCP 18/RFC 2277, "IETF Policy
on Character Sets and Languages".
It is likely that definition of the protocol will rely on many words 2.18 Glossary
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.
If the author uses the word as commonly defined, she does not have to Every standards track RFC should have a glossary, as words can have
include the definition in the glossary. As a minimum, FYI 18/RFC many meanings. By defining any new words introduced, the author can
1983 should be referenced as a source. 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.
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 3 Specific Guidelines
The following are guidelines on how to present specific technical The following are guidelines on how to present specific technical
information in standards. information in standards.
3.1 Packet Diagrams 3.1 Packet Diagrams
Most link, network, and transport layer protocols have packet Most link, network, and transport layer protocols have packet
descriptions. Packet diagrams included in the standard are very descriptions. Packet diagrams included in the standard are very
helpful to the reader. The preferred form for packet diagrams is a helpful to the reader. The preferred form for packet diagrams is a
sequence of long words in network byte order, with each word sequence of long words in network byte order, with each word
horizontal on the page and bit numbering at the top: horizontal on the page and bit numbering at the top:
0 1 2 3 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 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 | |Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In cases where a packet is strongly byte-aligned rather than In cases where a packet is strongly byte-aligned rather than word-
word-aligned (e.g., when byte-boundary variable-length fields are aligned (e.g., when byte-boundary variable-length fields are used),
used), display packet diagrams in a byte-wide format. The author can display packet diagrams in a byte-wide format. The author can use
use different height boxes for short and long words, and broken boxes different height boxes for short and long words, and broken boxes for
for variable-length fields: variable-length fields:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
3.2 Summary Tables 3.2 Summary Tables
The specifications of some protocols are particularly lengthy, The specifications of some protocols are particularly lengthy,
sometimes covering a hundred pages or more. In such cases the sometimes covering a hundred pages or more. In such cases, the
inclusion of a summary table can reduce the risk of conformance inclusion of a summary table can reduce the risk of conformance
failure by an implementation through oversight. A summary table failure by an implementation through oversight. A summary table
itemizes what in a protocol is mandatory, optional, or prohibited. itemizes what in a protocol is mandatory, optional, or prohibited.
Summary tables do not guarantee conformance, but serve to assist an Summary tables do not guarantee conformance, but serve to assist an
implementor in checking that they have addressed all protocol implementer in checking that they have addressed all protocol
features. features.
The summary table will consist of, as a minimum, four (4) columns: The summary table will consist of, as a minimum, four (4) columns:
Protocol Feature, Section Reference, Status, and Protocol Feature, Section Reference, Status, and
References/Footnotes. The author may add columns if they further References/Footnotes. The author may add columns if they further
explain or clarify the protocol. explain or clarify the protocol.
In the Protocol Feature column describe the feature, for example, a In the Protocol Feature column, list the protocol's characteristics,
command word. We recommend grouping series of related transactions for example, a command word. We recommend grouping series of related
under descriptive headers, for example, RECEPTION. transactions under descriptive headers, for example, RECEPTION.
Section reference directs the implementor to the section, paragraph, Section reference directs the implementer to the section, paragraph,
or page that describes the protocol feature in detail. or page that describes the protocol feature in detail.
Status indicates whether the feature is mandatory, optional, or Status indicates whether the feature is mandatory, optional, or
prohibited. The author can either use a separate column for each prohibited. The author can use either a separate column for each
possibility, or a single column with appropriate codes. These codes possibility, or a single column with appropriate codes. These codes
need to be defined at the start of the summary table to avoid need to be defined at the start of the summary table to avoid
confusion. Possible status codes: confusion. Possible status codes:
M - must or mandatory M - must or mandatory
MN - must not MN - must not
O - optional O - optional
S - should S - should
SN - should not SN - should not
X - prohibited X - prohibited
In the References/Footnotes column authors can point to other RFCs In the References/Footnotes column authors can point to other RFCs
that are necessary to consider in implementing this protocol feature, that are necessary to consider in implementing this protocol feature,
or any footnotes necessary to explain the implementation further. or any footnotes necessary to explain the implementation further.
The STD 3/RFC 1122/RFC 1123 provides examples of summary tables. The STD 3/RFC 1122/RFC 1123 provides examples of summary tables.
3.3 State Machine Descriptions 3.3 State Machine Descriptions
A convenient method of presenting a protocol's behavior is as a A convenient method of presenting a protocol's behavior is as a
state-machine model. That is, a protocol can be described by a state-machine model. That is, a protocol can be described by a
series of states resulting from a command, operation, or transaction. series of states resulting from a command, operation, or transaction.
State-machine models define the variables and constants that State-machine models define the variables and constants that
establish a state, the events that cause state transitions, and the establish a state, the events that cause state transitions and the
actions that result from those transitions. Through these models, an actions that result from those transitions. Through these models, an
understanding of the protocol's dynamic operation as sequence of understanding of the protocol's dynamic operation as sequence of
state transitions that occur for any given event is possible. State state transitions that occur for any given event is possible. State
transitions can be detailed by diagrams, tables, or time lines. transitions can be detailed by diagrams, tables, or time lines.
Note that state-machine models are never to take the place of Note that state-machine models are never to take the place of
detailed text description of the specification. They are adjuncts to detailed text description of the specification. They are adjuncts to
the text. The protocol specification shall always take precedence in the text. The protocol specification shall always take precedence in
the case of a conflict. the case of a conflict.
When using a state transition diagram, show each possible protocol When using a state transition diagram, show each possible protocol
state as a box connected by state transition arcs. The author should state as a box connected by state transition arcs. The author should
label each arc with the event that causes the transition, and, in label each arc with the event that causes the transition, and, in
parentheses, any actions taken during the transition. The STD 5/RFC parentheses, any actions taken during the transition. The STD 5/RFC
1112 provides an example of such a diagram. As ASCII text is the 1112 provides an example of such a diagram. As ASCII text is the
preferred storage format for RFCs, only simple diagrams are possible. preferred storage format for RFCs, only simple diagrams are possible.
Tables can summarize more complex or extensive state transitions. Tables can summarize more complex or extensive state transitions.
In a state transition table, read events vertically and states In a state transition table, the different events are listed
horizontally. The form, action/new state, represents state vertically and the different states are listed horizontally. The
transitions and actions. Commas separate multiple actions, and form, action/new state, represents state transitions and actions.
succeeding lines are used as required. The authors should present Commas separate multiple actions, and succeeding lines are used as
multiple actions in the order they must be executed, if relevant. required. The authors should present multiple actions in the order
Letters that follow the state indicate an explanatory footnote. The they must be executed, if relevant. Letters that follow the state
dash ('-') indicates an illegal transition. The STD 51/RFC 1661 indicate an explanatory footnote. The dash ('-') indicates an
provides an example of such a state transition table. The initial illegal transition. The STD 51/RFC 1661 provides an example of such
columns and rows of that table follow as an example: a state transition table. The initial columns and rows of that table
follow as an example:
| State | State
| 0 1 2 3 4 5 | 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping Events| Initial Starting Closed Stopped Closing Stopping
------+----------------------------------------------------------- ------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - - Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1 Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4 Close| 0 tlf/0 2 2 4 4
| |
TO+ | - - - - str/4 str/5 TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3 TO- | - - - - tlf/2 tlf/3
The STD 18/RFC 904 also presents state transitions in table format. 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 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 state and a represents the action. The method in RFC 1661 is
preferred as new-state logically follows action. Also, RFC 904's preferred as new state logically follows action. In addition, RFC
Appendix C models transitions as the Cartesian product of two state 904's Appendix C models transitions as the Cartesian product of two
machines. This is a more complex representation that may be state machines. This is a more complex representation that may be
difficult to comprehend for those readers that are unfamiliar with difficult to comprehend for those readers that are unfamiliar with
the format. We recommend that authors present tables as defined in the format. We recommend that authors present tables as defined in
the previous paragraph. the previous paragraph.
A final method of representing state changes is by a time line. The 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 two sides of the time line represent the machines involved in the
exchange. The author lists the states the machines enter as time exchange. The author lists the states the machines enter as time
progresses (downward) along the outside of time line. Within the progresses (downward) along the outside of time line. Within the
time line, show the actions that cause the state transitions. An time line, show the actions that cause the state transitions. An
example: example:
client server client server
| | | |
| | LISTEN | | LISTEN
SYN_SENT |----------------------- | SYN_SENT |----------------------- |
| \ syn j | | \ syn j |
| ----------------->| SYN_RCVD | ----------------->| SYN_RCVD
| | | |
| ------------------| | ------------------|
| syn k, ack j+1 / | | syn k, ack j+1 / |
ESTABLISHED |<---------------------- | ESTABLISHED |<---------------------- |
| | | |
3.4 Character Sets
At one time the Internet had a geographic boundary and was English
only. Since the Internet now extends internationally, application
protocols must assume that the contents of any text string may be in
a language other than English. Therefore, new or updated protocols
which transmit text must use ISO 10646 as the default Coded Character
Set, and RFC 2279, "UTF-8, a transformation format of Unicode and
ISO 10646" as the default Character Encoding Scheme. An exception is
the use of US-ASCII for a protocol's controlling commands and
replies. Protocols that have a backwards compatibility requirement
should use the default of the existing protocol. This is in keeping
with the recommendations of RFC 2130, "The Report of the IAB
Character Set Workshop held 29 February - 1 March 1996."
4 Document Checklist 4 Document Checklist
The following is a checklist based on these guidelines that can be The following is a checklist based on the above guidelines that can
applied to a document: be applied to a document:
o Does it identify the security risks? Are countermeasures for each o Does it identify the security risks? Are countermeasures for each
potential attack provided? Are the effects of the security potential attack provided? Are the effects of the security
measures on the operating environment detailed? measures on the operating environment detailed?
o Does it explain the purpose of the protocol or procedure? Are the o Does it explain the purpose of the protocol or procedure? Are the
intended functions and services addressed? Does it describe how it intended functions and services addressed? Does it describe how it
relates to existing protocols? relates to existing protocols?
o Does it consider scaling and stability issues? o Does it consider scaling and stability issues?
o Have procedures for assigning numbers been coordinated with IANA? o Have procedures for assigning numbers been coordinated with IANA?
o Does it discuss how to manage the protocol being specified? Is a o Does it discuss how to manage the protocol being specified? Is a
MIB defined? MIB defined?
o Is a target audience defined? o Is a target audience defined?
o Does it reference or explain the algorithms used in the protocol? o Does it reference or explain the algorithms used in the protocol?
o Does it give packet diagrams in recommended form, if applicable? o Does it give packet diagrams in recommended form, if applicable?
o Is there a change log? o Is there a change log?
o Does it describe differences from previous versions, if applicable? o Does it describe differences from previous versions, if
o Does it separate explanatory portions of the document from applicable?
o Does it separate explanatory portions of the document from
requirements? requirements?
o Does it give examples of protocol operation? o Does it give examples of protocol operation?
o Does it specify behavior in the face of incorrect operation by o Does it specify behavior in the face of incorrect operation by
other implementations? other implementations?
o Does it delineate which packets should be accepted for processing o Does it delineate which packets should be accepted for processing
and which should be ignored? and which should be ignored?
o If multiple descriptions of a requirement are given, does it o If multiple descriptions of a requirement are given, does it
identify one as binding? identify one as binding?
o How many optional features does it specify? Does it separate them o How many optional features does it specify? Does it separate them
into option classes? into option classes?
o Have all combinations of options or option classes been examined o Have all combinations of options or option classes been examined
for incompatibility? for incompatibility?
o Does it explain the rationale and use of options? o Does it explain the rationale and use of options?
o Have all mandatory and optional requirements be identified and o Have all mandatory and optional requirements be identified and
documented by the accepted key words that define Internet documented by the accepted key words that define Internet
requirement levels? requirement levels?
o Does it use the recommended Internet meanings for any terms use to o Does it conform to the current internationalization policies of
specify the protocol? the IETF?
o Are new or altered definitions for terms given in a glossary? o Are the recommended meanings for common Internet terms used?
o If not, are new or altered definitions for terms given in a
glossary?
5 Security Considerations 5 Security Considerations
This document does not define a protocol or procedure that could be This document does not define a protocol or procedure that could be
subject to an attack. It establishes guidelines for the information subject to an attack. It establishes guidelines for the information
that should be included in RFCs that are to be submitted to the that should be included in RFCs that are to be submitted to the
standards track. In the area of security, IETF standards authors are standards track. In the area of security, IETF standards authors are
called on to define clearly the threats faced by the protocol and the called on to define clearly the threats faced by the protocol and the
way the protocol does or does not provide security assurances to the way the protocol does or does not provide security assurances to the
user. user.
6 References 6 References
RFC 791 "Internet Protocol (IP)," J. Postel, September 1981. [RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791
September 1981.
RFC 904 "Exterior Gateway Protocol formal specification," D. Mills, [RFC 904] Mills, D., "Exterior Gateway Protocol formal
April 1984 specification", RFC 904, April 1984.
RFC 1058 "Routing Information Protocol," C. Hedrick, June 1988 [RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, June 1988.
RFC 1112 "Host extensions for IP multicasting," S. Deering, [RFC 1112] Deering, S., "Host extensions for IP multicasting",
August 1989 STD 5, RFC 1112, August 1989.
RFC 1122 "Requirements for Internet Hosts -- Communication Layers," [RFC 1122] Braden, R., "Requirements for Internet Hosts --
R. Braden, October 1989 Communication Layers", STD 3, RFC 1122, October 1989.
RFC 1123 "Requirements for Internet hosts -- Application and [RFC 1123] Braden, R., "Requirements for Internet hosts --
Support," R. Braden, October 1989 Application and Support", STD 3, RFC 1123, October 1989.
RFC 1311 "Introduction to the STD Notes," J. Postel, March 1992 [RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
RFC 1350 "The TFTP Protocol (Revision 2)," K. Sollins, July 1992 [RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
RFC 1661 "The Point-to-Point Protocol (PPP)," W. Simpson, July 1994 [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
RFC 1662 "PPP in HLDC-like Framing," W. Simpson, July 1994 [RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662,
July 1994.
RFC 1700 "Assigned Numbers," J. Reynolds, J. Postel, October 1994 [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. (http://www.iana.org)
RFC 1939 "Post Office Protocol - Version 3," J. Meyers, M. Rose, [RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version
May 1996 3", STD 53, RFC 1939, May 1996.
RFC 1958 "Architectural Principles of the Internet," B. Carpenter, [RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
June 1996 RFC 1958, June 1996.
RFC 1983 "Internet Users' Glossary," G. Malkin, August 1996 [RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
August 1996.
RFC 2026 "The Internet Standards Process -- Revision 3," S. Bradner, [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3",
October 1996 RFC 2026, October 1996.
RFC 2119 "Key words for use in RFCs to Indicate Requirement Level," [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
S. Bradner, March 1997 Requirement Level", BCP 14, RFC 2119, March 1997.
RFC 2130 "The Report of the IAB Character Set Workshop held 29 [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
February - 1 March 1996," C. Weider, C. Preston,
K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin,
P. Svanberg, April 1997
RFC 2178 "OSPF Version 2," J. Moy, July 1997
RFC 2279 "UTF-8, a transformation format of ISO 10646," F. Yergeau, [RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
January 1998 RFC 2223, October 1997.
RFC "Guidelines for Writing an IANA Considerations Section in [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
RFCs," Language", RFC 2277, January 1998.
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
7 Acknowledgments 7 Acknowledgments
Peter Desnoyers and Art Mellor began the work on this document. The Peter Desnoyers and Art Mellor began the work on this document.
area directors that oversaw the STDGUIDE WG's efforts were Others that contributed were:
Scott Bradner, Mike O'Dell, and John Curran. Others that contributed
to this document were:
Bernard Aboba Bernard Aboba
Harald T. Alvestrand Harald T. Alvestrand
Fred Baker Fred Baker
Scott Bradner
Brian Carpenter Brian Carpenter
Robert Elz Robert Elz
Dirk Fieldhouse Dirk Fieldhouse
Dale Francisco Dale Francisco
Gary Malkin Gary Malkin
Neal McBurnett Neal McBurnett
Thomas Narten
Craig Partridge Craig Partridge
Vern Paxson
Mike O'Dell
Henning Schulzrinne Henning Schulzrinne
Kurt Starsinic Kurt Starsinic
James Watt James Watt
8 Editor's Address 8 Editor's Address
Gregor D. Scott Gregor D. Scott
Director, Defense Information Systems Agency Director, Defense Information Systems Agency
ATTN: JIEO-JEBBC ATTN: JIEO-JEBBC
Ft. Monmouth, NJ 07703-5613 Ft. Monmouth, NJ 07703-5613
USA USA
Phone: (732) 427-6856 Phone: (732) 427-6856
Fax: (732) 532-0853 Fax: (732) 532-0853
EMail: scottg@ftm.disa.mil EMail: scottg@ftm.disa.mil
This Internet Draft expires on 15 September 1998. 9 Appendix
CHANGES FROM DRAFT -06
The following changes were made following IESG review:
References to RFC 1543 were changed to RFC 2223 that obsoleted it.
In section 2.1, "export control" was dropped as a valid reason for
not selecting a security mechanism. In addition, ambiguous or
conflicting sentences were removed.
In section 2.1 reference made to RFC 2315 as an additional source of
information.
Section 2.5 was changed to highlight the Change Log's purpose as
assistance to implementers.
The IANA Considerations section (2.13) was rewritten to highlight
that the IANA guidelines document is work in progress but should be
used when it becomes available.
Section 3.4 Character Sets was deleted and replaced by section 2.17
Internationalization.
Spelling and grammar corrections were made.
CHANGES FROM DRAFT -05
A sentence pointing to a pending document that further addresses IANA
considerations was added to section 2.13. The current draft of that
document is draft-iesg-iana-considerations-02.txt. A clause stating
that the IANA established the assignment policies was removed since it
appeared to conflict with the intent of the referenced ID.
Placeholders for the BCP and RFC number have been added to the text
and reference section.
A new section (2.5) requiring change logs as documents progress along
the standards track was added.
References to RFC 2044 were changed to RFC 2279 that obsoleted it.
Spelling and grammar corrections were made.
CHANGES FROM DRAFT -04
A paragraph pointing to a pending document that further addresses
security was updated.
10 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 117 change blocks. 
645 lines changed or deleted 606 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/