RFC 3426 (rfc3426) - Page 2 of 23

General Architectural and Policy Considerations

RFC 3426        Architectural and Policy Considerations    November 2002


   Our assumption is that this document will be used as suggestions (but
   not a checklist!) of issues to be addressed by IETF members in
   chartering new working groups, in working in working groups, and in
   evaluating the output from other working groups.  This document is
   not a primer on how to design protocols and architectures, and does
   not provide answers to anything.

2.  Relationship to "Architectural Principles of the Internet"

   RFC 1958 [RFC 1958] outlines some architectural principles of the
   Internet, as "guidelines that have been found useful in the past, and
   that may be useful to those designing new protocols or evaluating
   such designs." An example guideline is that "it is also generally
   felt that end-to-end functions can best be realized by end-to-end
   protocols." Similarly, an example design issue from [RFC 1958] is that
   "heterogeneity is inevitable and must be supported by design."

   In contrast, this document serves a slightly different purpose, by
   suggesting additional architectural questions to be addressed.  Thus,
   one question suggested in this document is the following: "Is this
   proposal the best long-term solution to the problem?  If not, what
   are the long-term costs of this solution, in terms of restrictions on
   future development, if any?" This question could be translated to a
   roughly equivalent architectural guideline, as follows: "Identify
   whether the proposed protocol is a long-term solution or a short-term
   solution, and identify the long-term costs and the exit strategy for
   any short-term solutions."

   In contrast, other questions are more open-ended, such as the
   question about robustness: "How robust is the protocol, not just to
   the failure of nodes, but also to compromised or malfunctioning
   components, imperfect or defective implementations, etc?" As a
   community, we are still learning about the degree of robustness that
   we are able to build into our protocols, as well as the tools that
   are available to ensure this robustness.  Thus, there are not yet
   clear architectural guidelines along the lines of "Ensure that your
   protocol is robust against X, Y, and Z."

3.  Questions

   In this section we list some questions to ask in designing protocols.
   Each question is discussed more depth in the rest of this paper.  We
   aren't suggesting that all protocol design efforts should be required
   to explicitly answer all of these questions; some questions will be
   more relevant to one document than to another.  We also aren't
   suggesting that this is a complete list of architectural concerns.





Floyd                        Informational