RFC 3426 (rfc3426) - Page 2 of 23
General Architectural and Policy Considerations
Alternative Format: Original Text Document
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