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