General Architectural and Policy Considerations
RFC 3426

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                   S. Floyd, Editor
Request for Comments: 3426                   Internet Architecture Board
Category: Informational                                    November 2002

            General Architectural and Policy Considerations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document suggests general architectural and policy questions
   that the IETF community has to address when working on new standards
   and protocols.  We note that this document contains questions to be
   addressed, as opposed to guidelines or architectural principles to be
   followed.

1.  Introduction

   This document suggests general architectural and policy questions to
   be addressed in our work in the IETF.  This document contains
   questions to be addressed, as opposed to guidelines or architectural
   principles to be followed.  These questions are somewhat similar to
   the "Security Considerations" currently required in IETF documents
   [RFC2316].

   This document is motivated in part by concerns about a growing lack
   of coherence in the overall Internet architecture.  We have moved
   from a world of a single, coherent architecture designed by a small
   group of people, to a world of complex, intricate architecture to
   address a wide-spread and heterogeneous environment.  Because
   individual pieces of the architecture are often designed by
   sub-communities, with each sub-community having its own set of
   interests, it is necessary to pay increasing attention to how each
   piece fits into the larger picture, and to consider how each piece is
   chosen.  For example, it is unavoidable that each of us is inclined
   to solve a problem at the layer of the protocol stack and using the
   tools that we understand the best;  that does not necessarily mean
   that this is the most appropriate layer or set of tools for solving
   this problem in the long-term.

Floyd                        Informational                      [Page 1]
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 [RFC1958] 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 [RFC1958] 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                      [Page 2]