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
