RFC 3269 (rfc3269) - Page 3 of 12
Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents
Alternative Format: Original Text Document
RFC 3269 RMT Author Guidelines April 2002
combinations of building blocks A and B works, the combination of
building blocks B and C works, however the combination of building
blocks A, B, and C does not work.
In order to avoid misusage of and incompatibilities between building
blocks, any external dependency must be highlighted in the building
block specification. Furthermore, the specification must contain a
precise applicability statement for the building block. Conversely,
any protocol instantiation specification must state how any building
block being used in it meets the protocol instantiation's
applicability requirements. These guidelines are not intended to
replace the common practice of Internet specification writing, but to
augment them in a manner that better fits the RMT framework.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
2. The Guidelines
This document provides guidelines for authors of the two main kinds
of RMT documents; building block documents and protocol instantiation
documents. The guidelines for each are as follows.
2.1. Building Block Document Guidelines
All RMT Building block documents MUST contain sections that cover the
following.
2.1.1. Rationale
Individual building blocks SHOULD be reusable within multiple
protocols and MUST provide functionality not present within other
building blocks. If a building block is currently used in a single
protocol instantiation, then it MUST specify some functionality that
is likely to be reused in another (future) protocol instantiation.
The rationale section of a building block document must clearly
define why the particular level of granularity for the functional
decomposition resulted in that building block being chosen. If the
granularity is too small it is highly likely that the building blocks
will be trivial, and therefore require excessive additional effort to
realize a working protocol. Conversely, if the level of granularity
is too large, building blocks will only be usable within a single
protocol instantiation. The rationale section MUST show that the
level of granularity is appropriate so that neither problem occurs.
Kermode & Vicisano Informational