draft-ietf-stdguide-ops-01.txt   draft-ietf-stdguide-ops-02.txt 
Network Working Group G. Scott Network Working Group G. Scott, Editor
INTERNET DRAFT Defense Information Systems Agency INTERNET DRAFT Defense Information Systems Agency
November 1996
Guide for Internet Standards Writers Guide for Internet Standards Writers
<draft-ietf-stdguide-ops-01.txt> <draft-ietf-stdguide-ops-02.txt>
Status of this Document Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is not appropriate to use Internet time. It is not appropriate to use Internet Drafts as reference
Drafts as reference material or to cite them other than as a material or to cite them other than as a "working draft" or "work in
"working draft" or "work in progress." progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Shadow Directories on ds.internic.net (US East Coast), Directories on ds.internic.net (US East Coast), nic.nordu.net
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
munnari.oz.au (Pacific Rim). Rim).
Distribution of this document is unlimited. Distribution of this document is unlimited.
This Internet Draft expires 23 May 1997. This Internet Draft expires on 17 September 1997.
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, those characteristics that make standards coherent, unambiguous, and
and easy to interpret. Also, it singles out usage believed to have easy to interpret. Also, it singles out usage believed to have led
led to unclear specifications, resulting in non-interoperable 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 1543, "Instructions to RFC Authors."
This version of the document is a draft. It is intended to This version of the document is a draft. It is intended to generate
generate further discussion and addition by the STDGUIDE working further discussion and addition by the STDGUIDE working group.
group. Please send comments to stdguide@midnight.com. Please send comments to stdguide@midnight.com.
CHANGES FROM THE PREVIOUS DRAFT
The order of section 2 was changed to emphasize security
considerations.
Section 2.1 was extensively revised to cover additional points
regarding security.
A section (2.3) was added discussing the need for each IETF Standard
to have a description of the target audience.
The protocol option section (2.9) was expanded to cover default
settings, separate option documents, permitting options in support of
future extensibility, and the impact of implementation experience on
proposed options.
The subsection on Implementation Experience was deleted. The affect
of implementation experience on the standard is now discussed as part
of subsections 2.6 and 2.9. This was done to keep related
information together.
Text in sections 2.2, 2.10, 4, and 5 were revised for clarity.
Section 2.12 was revised to require the standard to specify the rules
and procedures by which IANA will register constants and tags.
A section (2.13) was added to require standards to address management
issues.
A section (2.14) was added to require standards to address
scalability issues.
A section (2.15) was added to require standards to address network
stability.
A section (3.4) was added to discus how to support multilingual
character sets.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduction
2 General Guidelines . . . . . . . . . . . . . . . . . . . . . . 2 General Guidelines
2.1 Protocol Description . . . . . . . 2.1 Discussion of Security
2.2 Discussion of Security . . . . . . 2.2 Protocol Description
2.3 Level of Detail. . . . . . . .
2.4 Protocol Versions. . . . . . .
2.5 Decision History . . . . . . .
2.6 Response to Behavior Out of Scope. . . . . .
2.7 The Liberal/Conservative Rule. . . . . . . .
2.8 Handling of Protocol Options . . . . . . . . 2.3 Target Audience
2.9 Indicating Requirement Levels. . . . . . . . | 2.4 Level of Detail
2.10 Notational Conventions . . . . . . | 2.5 Protocol Versions
2.11 Implementation Experience. . . . . . . . . . 2.6 Decision History
2.12 Glossaries . . . . . . . . . . | 2.7 Response to Behavior Out of Scope
2.8 The Liberal/Conservative Rule
2.9 Handling of Protocol Options
2.10 Indicating Requirement Levels
2.11 Notational Conventions
2.12 IANA Considerations
2.13 Network Management Considerations
2.14 Scalability Considerations
2.15 Network Stability
2.16 Glossaries
3 Specific Guidelines. . . . . . . . . . . . . . . . . . . . . . 3 Specific Guidelines
3.1 Packet Diagrams. . . . . . . . 3.1 Packet Diagrams
3.2 Summary Tables . . . . . . . . 3.2 Summary Tables
3.3 State Machine Descriptions . . . . . . . . . 3.3 State Machine Descriptions
3.4 Character Sets
4 Document Checklist . . . . . . . . . . . . . . . . . . . . . . 4 Document Checklist
5 Security Considerations. . . . . . . . . . . . . . . . . . . . | 5 Security Considerations
6 Working Group Chair's Address . . . . . . . . . . . . . . . . 6 References
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgments
CHANGES FROM PREVIOUS DRAFT. . . . . . . . . . . . . . . . . . . . | 8 Editor's Address
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 protocol specification 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 1543, "Instructions to RFC
Authors," or its update. Note that some guidelines may not apply | Authors," or its update. Note that some guidelines may not apply in
in certain situations. certain situations. The process for standardizing protocols and
procedures is given in BCP 9/RFC 2026, "The Internet Standards
Process -- Revision 3."
The goal is to increase the possibility that multiple The goal is to increase the possibility that multiple implementations
implementations of a protocol will interoperate. Writing of a protocol will interoperate. Writing specifications to these
specifications to these guidelines will not guarantee guidelines will not guarantee interoperability. However, a
interoperability. However, a recognized barrier to the creation of recognized barrier to the creation of interoperable protocol
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 Implementors will have a better chance to conform to the protocol
specification. Protocol testers can use the specification to specification. Protocol testers can use the specification to derive
derive unambiguous testable statements. Purchasers and users of unambiguous testable statements. Purchasers and users of the
the protocol will have a better understanding of its capabilities. protocol will have a better understanding of its capabilities.
2 General Guidelines 2 General Guidelines
It is important that multiple readers and implementors of a It is important that multiple readers and implementors of a standard
standard have the same understanding of a document. To this end, have the same understanding of a document. To this end, information
information should be orderly and detailed. The following are should be orderly and detailed. The following are general guidelines
general guidelines intended to help in the production of such a intended to help in the production of such a document. The IESG may
document. require that all or some of the following sections appear in a
standards track document.
2.1 Protocol Description 2.1 Discussion of Security
Standards track documents must include a description of the purpose | If the Internet is to achieve its full potential in commercial,
or context of the protocol's use. The author of a protocol governmental, and personal affairs, it must assure users that their
specification will have a great deal of knowledge as to the purpose information transfers are free from tampering or compromise. Well-
of the protocol. However, the reader is more likely to have written security sections in standards-track documents can help
general networking knowledge and experience, rather than expertise promote the confidence level required. For an implementor will find
in a particular protocol. An explanation of the purpose will | it easier to provide with the security measures specified. While
give the reader a reference point for understanding the protocol | users will understand the security measures, and so have a higher
and where it fits in the Internet. The Draft Standard RFC 1583 was | level of trust in the Internet. Above all, new protocols and
recommended to the STDGUIDE working guide as providing a good | practices must not worsen overall Internet security.
example of this in it "Protocol Overview" section. |
The protocol's general description should also provide information | A significant threat to the Internet are those individuals who are
on the relationship between the different parties to the protocol. | motivated and capable of exploiting circumstances, events, or
This can be done by showing typical packet sequences. | vulnerabilities to cause harm by denying service, and/or destroying,
disclosing, or modifying information. Standards authors must accept
that the protocol they specify will be subject to attack. They are
responsible for determining what attacks are possible, and for
detailing the nature of the attacks in the document. Otherwise, they
must convincingly argue that attack is not realistic in a specific
environment, and restrict the use of the protocol to that
environment.
This also applies to the algorithms used by a protocol. A detailed After the document has exhaustively identified the security risks the
description of the algorithms or citation of readily available protocol is exposed to, the authors must formulate and detail a
references that give such a description is necessary. defense against those attacks. They must discuss the applicable
countermeasures employed, or the risk the user is accepting by using
the protocol. The countermeasures may be provided by a protocol
mechanism or by reliance on external mechanisms. Authors should be
knowledgeable of exiting security mechanisms, and reuse them if
practical. When cryptographic algorithms are use, the protocol
should be written to permit its substitution with another algorithm
in the future. Finally, the authors should discuss implementation
hints or guidelines, e.g., how to deal with untrustworthy data or
peer systems.
2.2 Discussion of Security Additionally, the effects the security measures have on the
protocol's use and performance should be discussed. Security
measures will have an impact on the environment they are used in.
Perhaps users will now be locked out of portions of the Internet
previously open to them, or users will experience a degradation in
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.
If the Internet is to achieve its full potential in commercial, The discussion of security can be concentrated in the Security
governmental, and personal affairs, it must assure users that Considerations section of the document, or throughout the document
deliveries of their information transfers are free from tampering where it is relevant to particular parts of the specification. If
or compromise. Well-written security sections in standard protocol the second approach is taken, the Security Considerations section
documents can do much to achieve that condition. Implementors will must summarized and make reference to the appropriate specification
find it easier to comply and do security. Users can understand the sections. This will insure that the protocol's security measures are
security measures in place, and so have faith in the Internet. emphasized to implementor and user both.
The security section should address several topics. Every | Currently, a RFC is being considered that would give guidance on how
standards track document must discuss the security risks inherent | to do a security analysis. It will provide a listing of classes of
in the protocol being specified. After the document's author has | attacks, and methods of analysis that are useful in developing
set out the security risks the protocol is open to, he then must | countermeasures to them. Standards authors should obtain a current
discuss the remedies offered. Additionally, the effects the | copy of this RFC to assist them in their preparation of the security
security measures have on the protocol's use and performance. If portion of the standard.
possible, the discussion should address how much insurance the
implementation of the security measures achieves.
When no security measures are offered, the author must provide a | Finally, it is no longer acceptable that Security Considerations
detailed explanation why. This discussion could present the | sections consist solely of statements to the effect that security was
reasons why the security issues are unresolvable at this time. not considered in preparing the standard.
Alternatively, the author could present a case why security is
unneeded when using the protocol.
These security sections should be complete and separate. If | Some examples of Security Considerations sections are found in
security measures are part of the general protocol text, they will STD 33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939.
be difficult to find. If the security measures are not clear they
may not be implemented, nor will a user be assured that they exist.
Finally, it is no longer acceptable that security sections consist 2.2 Protocol Description
solely of statements similar to: "Security issues are not
discussed in this RFC."
2.3 Level of Detail
The author should consider what level of descriptive detail best | Standards track documents must include a description of the protocol.
conveys the protocol's intent. Concise text has several This description should address the protocol's purpose, intended
advantages. It makes the document easier to read. Such text functions, and services it provides. Also addressed should be the
reduces the chance for conflict between different portions of the arena, circumstances, or any special considerations of its use.
specification. The reader can readily identify the required
protocol mechanisms in the standard. Also, it makes it easier to
identify the requirements for protocol implementation. A
disadvantage of concise descriptions is that a reader may not fully
comprehend the reasoning behind the protocol, and thus make
assumptions that will lead to implementation errors.
Longer descriptions may be necessary to explain purpose, | The authors of a protocol specification will have a great deal of
background, rationale, implementation experience, or to provide | knowledge as to the reason for the protocol. However, the reader is
tutorial information. This helps the reader understand the | more likely to have general networking knowledge and experience,
protocol. Yet several dangers exist with lengthy text. Finding rather than expertise in a particular protocol. An explanation of
the protocol requirements in the text is difficult or confusing. it's purpose and use will give the reader a reference point for
The same mechanism may have multiple descriptions, which leads to | understanding the protocol, and where it fits in the Internet. The
misinterpretations or conflict. Lengthy text is a challenge to the Draft Standard RFC 1583 was recommended to the STDGUIDE working guide
attention span of some readers. Finally, it is more difficult to as providing a good example of this in it's "Protocol Overview"
comprehend, a consideration as English is not the native language section.
of the many worldwide readers of IETF standards.
One approach is to divide the standard into sections: one The protocol's general description should also provide information on
describing the protocol concisely, while another section consists the relationship between the different parties to the protocol.
of explanatory text. The STD 3/RFC 1122/RFC 1123 and Draft | This can be done by showing typical packet sequences.
Standard RFC 1583 provides examples of this method. |
2.4 Protocol Versions This also applies to the algorithms used by a protocol. A detailed
description of the algorithms or citation of readily available
references that give such a description is necessary.
2.3 Target Audience
RFCs have been written with many different purposes, ranging from the
technical to the administrative. Those written as standards should
clearly identify the intended audience, for example, designers,
implementors, testers, help desk personnel, educators, end users, or
others. If there are multiple audiences being addressed in the
document, what sections are for each audience needs to be identified.
The goal is to help the reader discover and focus on what they have
turned to the document for, and avoid what they may find confusing,
diverting, or extraneous.
2.4 Level of Detail
The author should consider what level of descriptive detail best
conveys the protocol's intent. Concise text has several advantages.
It makes the document easier to read. Such text reduces the chance
for conflict between different portions of the specification. The
reader can readily identify the required protocol mechanisms in the
standard. Also, it makes it easier to identify the requirements for
protocol implementation. A disadvantage of concise descriptions is
that a reader may not fully comprehend the reasoning behind the
protocol, and thus make assumptions that will lead to implementation
errors.
Longer descriptions may be necessary to explain purpose, background,
rationale, implementation experience, or to provide tutorial
information. This helps the reader understand the protocol. Yet
several dangers exist with lengthy text. Finding the protocol
requirements in the text is difficult or confusing. The same
mechanism may have multiple descriptions, which leads to
misinterpretations or conflict. Finally, it is more difficult to
comprehend, a consideration as English is not the native language of
the many worldwide readers of IETF standards.
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 Draft Standard RFC 1583
provides examples of this method.
2.5 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 protocol. In such a case, the authors should detail the differences
differences between the previous version and the new version. This between the previous version and the new version. This should
should include the rationale for the changes, for example, include the rationale for the changes, for example, implementation
implementation experience, changes in technology, responding to experience, changes in technology, responding to user demand, etc.
user demand, etc.
2.5 Decision History 2.6 Decision History
In standards development, reaching consensus requires making In standards development, reaching consensus requires making
difficult choices. By including a discussion history and | difficult choices. These choices are made through working group
rationales for a decision, the author can prevent future revisiting | discussions or from implementation experience. By including the
of these disagreements later, when the original parties have moved basis for a contentious decision, the author can prevent future
on. Also, the knowledge of the "why" is as useful to an | revisiting of these disagreements later, when the original parties
implementor as the description of "how." For example, the | have moved on. Also, the knowledge of the "why" is as useful to an
implementor 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 logic behind the choice may prevent future including the reasons behind the choice may prevent future
implementors from taking nonstandard shortcuts. implementors from taking nonstandard shortcuts.
2.6 Response to Out of Specification Behavior 2.7 Response to Out of Specification Behavior
The STDGUIDE working group recommends that detail description of | The STDGUIDE working group recommends that detail description of the
the actions taken in case of behavior that is deviant from or actions taken in case of behavior that is deviant from or exceeds the
exceeds the specification be included. This is an area where specification be included. This is an area where implementors often
implementors often differ in opinion as to the appropriate differ in opinion as to the appropriate response. By specifying a
response. By specifying a common response, the standard author can common response, the standard author can reduce the risk that
reduce the risk that different inplementations will come in to | 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. forbidden or out of the boundaries defined by the specification. Two
Two possible approaches to such cases are discarding, or invoking possible approaches to such cases are discarding, or invoking
error-handling mechanisms. If discarding is chosen, detailing the error-handling mechanisms. If discarding is chosen, detailing the
disposition may be necessary. For instance, treat dropped frames disposition may be necessary. For instance, treat dropped frames as
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 critical
resource or performance scaling limits are exceeded. This is not resource or performance scaling limits are exceeded. This is not
necessary for every case. It is necessary for cases where a risk necessary for every case. It is necessary for cases where a risk of
of network degradation or operational failure exists. In such network degradation or operational failure exists. In such cases, a
cases, a consistent behavior between implementations is necessary. consistent behavior between implementations is necessary.
2.7 The Liberal/Conservative Rule 2.8 The Liberal/Conservative Rule
A rule, first stated in RFC 791, recognized as having benefits in A rule, first stated in RFC 791, recognized as having benefits in
implementation robustness and interoperability is: implementation robustness and interoperability is:
"Be liberal in what you accept, and "Be liberal in what you accept, and
conservative in what you send." conservative in what you send."
Or establish restrictions on what a protocol transmits, but be able | Or establish restrictions on what a protocol transmits, but be able
to deal with every conceivable error received. Caution is urged | to deal with every conceivable error received. Caution is urged in
in applying this approach in standards track protocols. It has in | applying this approach in standards track protocols. It has in the
the past lead to conflicts between vendors when interoperability | past lead to conflicts between vendors when interoperability fails.
fails. The sender accuses the receiver of failing to be liberal | The sender accuses the receiver of failing to be liberal enough, and
enough, and the receiver accuses the sender of not being | the receiver accuses the sender of not being conservative enough.
conservative enough. Therefore, the author is obligated to provide | Therefore, the author is obligated to provide extensive detail on
extensive detail on send and receive behavior. | send and receive behavior.
To avoid any confusion between the two, recommend that standard To avoid any confusion between the two, recommend that standard
authors specify send and receive behavior separately. The authors specify send and receive behavior separately. The
description of reception will require the most detailing. For | description of reception will require the most detailing. For
implementations will be expected to accept any packet from the implementations will be expected to accept any packet from the
network without failure or malfunction. Therefore, the actions network without failure or malfunction. Therefore, the actions taken
taken to achieve that result, need to be laid out in the protocol to achieve that result, need to be laid out in the protocol
specification. Standard authors should consider not just how to specification. Standard authors should consider not just how to
survive on the network, but achieve the highest level of survive on the network, but achieve the highest level of cooperation
cooperation possible to limit the amount of network disruption. possible to limit the amount of network disruption. The appearance
The appearance of undefined information or conditions must not of undefined information or conditions must not cause a network or
cause a network or host failure. This requires specification on host failure. This requires specification on how to attempt
how to attempt acceptance of most of the packets. Two approaches acceptance of most of the packets. Two approaches are available,
are available, either using as much of the packet's content as either using as much of the packet's content as possible, or invoking
possible, or invoking error procedures. The author should specify | error procedures. The author should specify a dividing line on when
a dividing line on when to take which approach. 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 differing interpretations and mandate that they be
either rejected completely or the nature of the attempt to recover | either rejected completely or the nature of the attempt to recover
some information from them. For example, routing updates that | some information from them. For example, routing updates that
contain more data than the tuple count shows. The protocol authors | contain more data than the tuple count shows. The protocol authors
should consider whether some trailing data can be accepted as | should consider whether some trailing data can be accepted as
additional routes, or to reject the entire packet as suspect | additional routes, or to reject the entire packet as suspect because
because it is non-conformant. | it is non-conformant.
2.8 Handling of Protocol Options 2.9 Handling of Protocol Options
Standards with many optional features increase the chance of Specifications with many optional features increase the complexity of
non-interoperable implementations. The danger is that different the implementation and the chance of non-interoperable
protocol implementations may specify some optional combinations implementations. The danger is that different implementations may
that are unable to interoperate with each other. Ideally, specify some combination of options that are unable to interoperate
implementation experience purges options from the protocol while with each other.
the document moves along the standard track.
Therefore, options should only be present in a protocol to | As the document moves along the standard track, implementation
support a particular market, e.g., the financial industry, or | experience should purge options from the protocol.. Implementation
network environment, e.g., a network constrained by limited | will show whether the option is needed or not, whether it should be a
bandwidth. The protocol specification must explain the full | mandatory part of the protocol or remain an option. If an option is
implications of either using the option or not, and the case for not implemented as the document advances, it must be removed from the
choosing either course. As part of this, the author needs to | protocol before it reaches draft standard status.
consider and describe how the options are intended to be used |
alongside other protocols. However, omission of the optional item |
should have no interoperability consequences for the implementation
that does so.
Certain cases will require the specifying of mutually exclusive Therefore, options should only be present in a protocol to address a
options within a protocol. That is, the implementation of an real requirement. For example, to support future extensibility of
optional feature precludes the implementation of the other optional the protocol, a particular market, e.g., the financial industry, or a
feature. For clarity, the author needs to state when to implement | specific network environment, e.g., a network constrained by limited
one or the other, what the effect of choosing one over the other bandwidth. They should not be included as a means to "buy-off" a
is, and what problems the implementor or user may face. The choice minority opinion. Omission of the optional item should have no
of one or the other options should have no interoperability interoperability consequences for the implementation that does so.
consequences between multiple implementations.
2.9 Indicating Requirement Levels | One possible approach is to document protocol options in a separate
document. Doing so would make it clear that the options are not
integral to the implementation of the protocol, and would keep the
main protocol specification clean. Regardless of whether they appear
within the specification or in a separate document, the text should
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 intended to be
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.
The Internet-Draft draft-bradner-key-words-03.txt, "Key words for | There may be occasions when mutually exclusive options appear within
use in RFCs to Indicate Requirement Levels," defines several words | a protocol. That is, the implementation of an optional feature
that can be used in many standards track documents to signify the | precludes the implementation of the other optional feature. For
mandatory protocol features from the optional features of the | clarity, the author needs to state when to implement one or the
specification. The definitions provided are as they should be | other, what the effect of choosing one over the other is, and what
interpreted in implementing IETF standards. Note that the force of | problems the implementor or user may face. The choice of one or the
these words is modified by the requirement level of the document in | other options should have no interoperability consequences between
which they are used. | multiple implementations.
Some authors of existing IETF standards have chosen to capitalize | 2.10 Indicating Requirement Levels
these words to clarify or stress their intent, but this is not |
required. What is necessary, is that these words are used |
consistently throughout the document. That is, every mandatory or |
optional protocol requirement shall be identified by the authors |
and documented by these words. If a requirement is not identified |
in this manner, it will not be considered an equal part of the |
protocol and be likely passed over by the implementor. |
2.10 Notational Conventions The Internet-Draft draft-bradner-key-words-03.txt, "Key words for use
in RFCs to Indicate Requirement Levels," defines several words that
are necessary for writing a standards track document. These words
separate the mandatory protocol features of the specification from
the optional features. The definitions provided are as they should
be interpreted in implementing IETF standards. Note that in IETF
Standards the intent of these words is binding on implementors and
other users of the document.
Some authors of existing IETF standards have chosen to capitalize
these words to clarify or stress their intent, but this is not
required. What is necessary, is that these words are used
consistently throughout the document. That is, every mandatory or
optional protocol requirement shall be identified by the authors and
documented by these words. If a requirement is not identified in
this manner, it will not be considered an equal part of the protocol
and be likely passed over by the implementor.
2.11 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 the formal syntax should be defined. exceptions to the formal syntax should be defined.
The STD 11/RFC 822 provides an example of this. In RFC 822 The STD 11/RFC 822 provides an example of this. In RFC 822 (Section
(Section 2 and Appendix D) the Backus-Naur Form (BNF) meta-language 2 and Appendix D) the Backus-Naur Form (BNF) meta-language was
was extended to make its representation smaller and easier to extended to make its representation smaller and easier to understand.
understand. Note, that the Internet-Draft | Note, that the Internet-Draft draft-ietf-drums-abnf-01.txt,
draft-ietf-drums-abnf-01.txt, "Augmented BNF for Syntax | "Augmented BNF for Syntax Specifications: ABNF," captures RFC 822's
Specifications: ABNF," captures | definition so that it can be used as a reference. Another example is
RFC 822's definition so that it can be used as a reference. | STD 16/RFC 1155 (Section 3.2) where a subset of the Abstract Syntax
Another example is STD 16/RFC 1155 (Section 3.2) where a subset of 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 | likely the reader will not have enough information to decide what the
the notation means. Also, the author should remember machine | notation means. Also, the author should remember machine parseable
parseable syntax is often unreadable by humans, and can make the | syntax is often unreadable by humans, and can make the specification
specification excessive in length. Therefore, syntax notations | excessive in length. Therefore, syntax notations cannot take the
cannot in place of a clearly written protocol description. | place of a clearly written protocol description.
2.11 Implementation Experience 2.12 IANA Considerations
For a protocol to be designated a standard, it must go through the The common use of the Internet standard track protocols by the
rigors of actual implementation. This implementation experience Internet community requires that the unique values be assigned to the
should be captured in the final document. For example, lessons parameter fields. The Internet Assigned Numbers Authority (IANA) is
learned from bake-offs between multiple vendors. the central coordinator for the assignment of unique parameter values
for Internet protocols. The authors of a developing protocol that
use a link, socket, port, protocol, etc., need to specify the rules
and procedures by which IANA will register constants and tags. The
author should ask IANA to review the rules and procedures for clarity
and feasibility prior to submitting the internet draft to the
standards track. For further information on parameter assignment and
current assignments, authors can reference STD 2/RFC 1700, "Assigned
Numbers."
2.12 Glossary | 2.13 Network Management Considerations
Every standards track RFC should have a glossary, as words can have | When relevant, each standard needs to discuss how to manage the
many meanings. By defining any new words introduced, the author | protocol being specified. This management process should be
can avoid confusing or misleading the implementer. The definition | compatible with the current IETF Standard management protocol. Also
should appear on the word's first appearance within the text of the | a MIB must be defined within the standard or in a companion document.
protocol specification, and in a separate glossary section. | The MIB must be compatible with current 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.
It is likely that definition of the protocol will rely on many | 2.14 Scalability Considerations
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 | The standard should establish the limitations on the scale of use,
to include the definition in the glossary. As a minimum, FYI | e.g., tens of millions of sessions, gigabits per second, etc., and
18/RFC 1983 should be referenced as a source. | 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 and
explanation of why not should be included.
2.13 Protocol Parameter Assignment | 2.15 Network Stability
The common use of the Internet standard track protocols by the | A standard should discuss the relationship between network topology
Internet community requires that the unique values be assigned to | and convergence behavior. As part of this, any topology which would
the parameter fields. The Internet Assigned Numbers Authority | be troublesome for the protocol should be identified. Additionally,
(IANA) is the central coordinator for the assignment of unique | the specification should address any possible destablizing events,
parameter values for Internet protocols. The authors of a | and how the protocol resists or recovers from them. The purpose is
developing protocol that use a link, socket, port, protocol, etc., | to insure that the network will stabilize, in a timely fashion, after
need to contact the IANA to receive a number assignment. For | a change, and that a combination of errors or events will not plunge
further information on parameter assignment and current | the network into chaos. The STD 34/RFC 1058, as an example, has
assignments, authors should reference STD 2/RFC 1700, "Assigned | sections which discuss how that protocol handles the affects of
Numbers." | changing topology.
2.16 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 implementer. 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. The STDGUIDE working group recommends that packet | descriptions. The STDGUIDE working group recommends that packet
diagrams be included in the standard, as they are very helpful to diagrams be included in the standard, as they are very helpful to the
the reader. The preferred form for packet diagrams is a sequence reader. The preferred form for packet diagrams is a sequence of long
of long words in network byte order, with each word horizontal on words in network byte order, with each word horizontal on the page
the page and bit numbering at the top: 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-aligned (e.g., when byte-boundary variable-length fields are word-aligned (e.g., when byte-boundary variable-length fields are
used), display packet diagrams in a byte-wide format. The author | used), display packet diagrams in a byte-wide format. The author can
can use different height boxes for short and long words, and broken | use different height boxes for short and long words, and broken boxes
boxes for variable-length fields: for variable-length fields:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length N | | Length N |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | |
+ Address + + Address +
... ...
+ (N bytes) + + (N bytes) +
| | | |
skipping to change at page 9, line 33 skipping to change at page 14, line 33
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 implementor 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 describe the feature, for example, a
command word. We recommend grouping series of related | command word. We recommend grouping series of related transactions
transactions under descriptive headers, for example, RECEPTION. under descriptive headers, for example, RECEPTION.
Section reference directs the implementor to the section, Section reference directs the implementor to the section, paragraph,
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 either use a separate column for each
possibility, or a single column with appropriate codes. These possibility, or a single column with appropriate codes. These codes
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 M - must
M - mandatory M - mandatory
MN - must not MN - must not
O - optional O - optional
S - should S - should
X - prohibited
SN - should not SN - should not
X - prohibited
In the References/Footnotes column authors can point to other | In the References/Footnotes column authors can point to other RFCs
RFCs that are necessary to consider in implementing this protocol that are necessary to consider in implementing this protocol feature,
feature, or any footnotes necessary to explain the implementation or any footnotes necessary to explain the implementation further.
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 series of states resulting from a command, operation, or transaction.
transaction. State-machine models define the variables and State-machine models define the variables and constants that
constants that establish a state, the events that cause state establish a state, the events that cause state transitions, and the
transitions, and the actions that result from those transitions. actions that result from those transitions. Through these models, an
Through these models, an understanding of the protocol's dynamic | understanding of the protocol's dynamic operation as sequence of
operation as sequence of state transitions that occur for any | state transitions that occur for any given event is possible.
given event is possible. State transitions can be detailed by | State transitions can be detailed by diagrams, tables, or time lines.
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 | detailed text description of the specification. They are adjuncts to
to the text. The protocol specification shall always take | the text. The protocol specification shall always take precedence in
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 | state as a box connected by state transition arcs. The author should
should label each arc with the event that causes the transition, | label each arc with the event that causes the transition, and, in
and, in parentheses, any actions taken during the transition. The parentheses, any actions taken during the transition. The STD 5/RFC
STD 5/RFC 1112 provides an example of such a diagram. As ASCII 1112 provides an example of such a diagram. As ASCII text is the
text is the preferred storage format for RFCs, only simple diagrams preferred storage format for RFCs, only simple diagrams are possible.
are possible. Tables can summarize more complex or extensive state Tables can summarize more complex or extensive state transitions.
transitions.
In a state transition table, read events vertically and states In a state transition table, read events vertically and states
horizontally. The form, action/new state, represents state | horizontally. The form, action/new state, represents state
transitions and actions. Commas separate multiple actions, and | transitions and actions. Commas separate multiple actions, and
succeeding lines are used as required. The authors should present | succeeding lines are used as required. The authors should present
multiple actions in the order they must be executed, if relevant. multiple actions in the order they must be executed, if relevant.
Letters that follow the state indicate an explanatory footnote. Letters that follow the state indicate an explanatory footnote. The
The dash ('-') indicates an illegal transition. The STD 51/RFC dash ('-') indicates an illegal transition. The STD 51/RFC 1661
1661 provides an example of such a state transition table. The provides an example of such a state transition table. The initial
initial columns and rows of that table are below as an example: columns and rows of that table are below 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
| |
skipping to change at page 11, line 4 skipping to change at page 16, line 19
| 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, this RFC's | preferred as new-state logically follows action. Also, this RFC's
Appendix C models transitions as the Cartesian product of two state Appendix C models transitions as the Cartesian product of two state
machines. This is a more complex representation that may be 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. The working group recommends that authors present | the format. The working group recommends that authors present
tables as defined in the previous paragraph. tables as defined in the previous paragraph.
A final method of representing state changes is by a timeline. The A final method of representing state changes is by a timeline. The
two sides of the timeline represent the machines involved in the two sides of the timeline 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 timeline. Within the progresses (downward) along the outside of timeline. Within the
timeline, show the actions that cause the state transitions. An timeline, 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 |<---------------------- |
| | | |
skipping to change at page 11, line 34 skipping to change at page 17, line 5
| | 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 2044, "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 the Character Set Workshop Report, draft-weider-
iab-char-wrkshop-00.txt.
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 these guidelines that can be
applied to a document: applied to a document:
o Does it explain the purpose of the protocol? o Does it identify the security risks? Are countermeasures for each
o Does it reference or explain the algorithms used in the potential attack provided? Are the effects of the security
protocol? 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 Are procedures for assigning numbers provided as guidance for 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 Does it give packet diagrams in recommended form, if applicable?
o Does it use the recommended Internet meanings for any terms use | o Does it describe differences from previous versions, if applicable?
to specify the protocol? |
o Are new or altered definitions for terms given in a glossary? |
o Does it separate explanatory portions of the document from o Does it separate explanatory portions of the document from
requirements? requirements?
o Does it describe differences from previous versions, if
applicable?
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 o Does it delineate which packets should be accepted for processing
processing and which should be ignored? and which should be ignored?
o Does it consider performance and scaling issues?
o How many optional features does it specify? If more than [X],
does it separate them into option classes?
o Have all combinations of options or option classes been examined
for incompatibility?
o Does it explain the rational and use of options?
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 Have all mandatory and optional requirements be identified and | o How many optional features does it specify? Does it separate them
documented by the accepted key words that define Internet | into option classes?
requirement levels? | o Have all combinations of options or option classes been examined
for incompatibility?
5. Security Considerations | o Does it explain the rationale and use of options?
o Have all mandatory and optional requirements be identified and
This document does not define any security service or mechanism. It| documented by the accepted key words that define Internet
does call on IETF standards authors to define clearly the way the | requirement levels?
protocol they are specifying does or does not provide security | o Does it use the recommended Internet meanings for any terms use to
assurances to the user. | specify the protocol?
o Are new or altered definitions for terms given in a glossary?
6 Working Group Chair's Address
Gregor D. Scott 5. Security Considerations
Director, Defense Information Systems Agency
ATTN: JIEO-JEBBD
Ft. Monmouth, NJ 07703-5613
USA
Phone: (908) 427-6856 | This document does not define a protocol or procedure that could be
Fax: (908) 532-0853 | subject to an attack. It establishes guidelines for the information
EMail: scottg@ftm.disa.mil that should be included in RFCs that are to be submitted to the
standards track. In the area of security, IETF standards authors are
called on to define clearly the the threats faced by the protocol and
the way the protocol does or does not provide security assurances to the
user.
7 References 6 References
RFC 791 "Internet Protocol (IP)," J. Postel, September 1981. RFC 791 "Internet Protocol (IP)," J. Postel, September 1981.
RFC 904 "Exterior Gateway Protocol formal specification," D. RFC 904 "Exterior Gateway Protocol formal specification," D.
RFC 1112 "Host extensions for IP multicasting," S. Deering, RFC 1112 "Host extensions for IP multicasting," S. Deering,
August 1989 August 1989
RFC 1122 "Requirements for Internet Hosts -- Communication Layers," RFC 1122 "Requirements for Internet Hosts -- Communication Layers,"
October 1989 October 1989
RFC 1123 "Requirements for Internet hosts -- Application and RFC 1123 "Requirements for Internet hosts -- Application and
Support," October 1989 Support," October 1989
RFC 1311 "Introduction to the STD Notes" RFC 1311 "Introduction to the STD Notes"
RFC 1583 "OSPF Version 2"
RFC 1700 "Assigned Numbers," J. Reynolds, J. Postel, October 1994
RFC 1583 "OSPF Version 2" | RFC 1983 "Internet Users' Glossary"
RFC 1602 "The Internet Standards Process - Revision 2"
RFC 1700 "Assigned Numbers," J. Reynolds, J. Postel, October 1994 |
RFC 1983 "Internet Users' Glossary" |
draft-ietf-drums-abnf-01.txt, "Augmented BNF for Syntax |
Specifications: ABNF," D. Crocker |
draft-bradner-key-words-03.txt, "Key words for use in RFCs to |
Indicate Requirement Levels," S. Bradner |
CHANGES FROM PREVIOUS DRAFT
Changes are marked by "|" along the right margin. Many of the changes
are editorial in nature. Some were rewriting sentences for clarity.
Others are noted as follows:
1. A reference to RFC 1543 was added to the Abstract and Introduction
so that authors would know that this was not a stand alone document.
That they had to comply to RFC 1543 as well.
2. In section 2.1, text recommending a "Protocol Overview" and a
description of how the parties to the protocol relate was added.
Reference to Draft Standard RFC 1583 was added.
3. In section 2.2, text was added calling for discussion of all the
security risks a protocol faces, rather than just the security problems
the protocol solves.
4. In section 2.7, cautionary text regarding the use of the
liberal/conservative rule was added.
5. In section 2.8, text calling on authors to consider how protocol RFC 1939 "Post Office Protocol - Version 3," J. Meyers, M. Rose,
options are used with other protocols was added. RFC 2026 "The Internet Standards Process -- Revision 3," S.
Bradner, October 1996
6. A new section, "2.9 Indicating Requirement Levels," was added to RFC 2044 "UTF-8, a transformation format of Unicode and ISO 10646,"
discuss the use of key words to identify protocol mandatory and option F. Yergeau, October 1996
features.
7. In section 2.10, a reference to DRUMS work in defining ABNF, and draft-ietf-drums-abnf-01.txt, "Augmented BNF for Syntax
cautionary text on using formal syntax notation was added. Specifications: ABNF," D. Crocker
8. A new section, "2.12 Glossary," was added calling on standards draft-bradner-key-words-03.txt, "Key words for use in RFCs to
track protocol authors to include a glossary of new or revised terms. Indicate Requirement Levels," S. Bradner
9. A new section, "2.13 Protocol Parameter Assignment," calls on draft-weider-iab-char-wrkshop-00.txt, "Character Set Workshop
authors to get such assignments from IANA. Report," C. Weider
10. In section 3.3, a statement that text takes precedence over state 7 Acknowledgments
machine models was added.
11. The previous draft's section 4, "Glossary," was deleted. In its 8 Editor's Address
place, a reference to draft-bradner-key-words-03.txt is made in the new
section 2.9.
12. New items were added to section 4, "Document Checklist," to reflect Gregor D. Scott
changes above. Director, Defense Information Systems Agency
ATTN: JIEO-JEBBD
Ft. Monmouth, NJ 07703-5613
USA
13. A new section 5, "Security Considerations," was added. Phone: (908) 427-6856
Fax: (908) 532-0853
EMail: scottg@ftm.disa.mil
 End of changes. 111 change blocks. 
425 lines changed or deleted 544 lines changed or added

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