RFC 3269 (rfc3269) - Page 3 of 12

Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents

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