doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc3426.txt b/doc/rfc/rfc3426.txt
new file mode 100644
index 0000000..a3c57bd
--- /dev/null
+++ b/doc/rfc/rfc3426.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+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]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   DESIGN QUESTIONS:
+
+   Justifying the Solution:
+
+   * Why are you proposing this solution, instead of proposing something
+   else, or instead of using existing protocols and procedures?
+
+   Interactions between Layers:
+
+   * Why are you proposing a solution at this layer of the protocol
+   stack, rather than at another layer?  Are there solutions at other
+   layers of the protocol stack as well?
+
+   * Is this an appropriate layer in terms of correctness of function,
+   data integrity, performance, ease of deployment, the diagnosability
+   of failures, and other concerns?
+
+   * What are the interactions between layers, if any?
+
+   Long-term vs. Short-term Solutions:
+
+   * 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?  What are the
+   requirements for the development of longer-term solutions?
+
+   The Whole Picture vs. Building Blocks:
+
+   * Have you considered the larger context, while appropriately
+   restricting your own design efforts to one part of the whole?
+
+   * Are there parts of the overall solution that will have to be
+   provided by other IETF Working Groups or by other standards bodies?
+
+   EVALUATION QUESTIONS:
+
+   Weighing Benefits against Costs:
+
+   * How do the architectural benefits of a proposed new protocol
+   compare against the architectural costs, if any?  Have the
+   architectural costs been carefully considered?
+
+   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?
+
+
+
+Floyd                        Informational                      [Page 3]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   * Does the protocol take into account the realistic conditions of the
+   current or future Internet (e.g., packet drops and packet corruption;
+   packet reordering; asymmetric routing; etc.)?
+
+   Tragedy of the Commons:
+
+   * Is performance still robust if everyone is using this protocol?
+   Are there other potential impacts of widespread deployment that need
+   to be considered?
+
+   Protecting Competing Interests:
+
+   * Does the protocol protect the interests of competing parties (e.g.,
+   not only end-users, but also ISPs, router vendors, software vendors,
+   or other parties)?
+
+   Designing for Choice vs. Avoiding Unnecessary Complexity:
+
+   * Is the protocol designed for choice, to allow different players to
+   express their preferences where appropriate?  At the other extreme,
+   does the protocol provide so many choices that it threatens
+   interoperability or introduces other significant problems?
+
+   Preserving Evolvability?
+
+   * Does the protocol protect the interests of the future, by
+   preserving the evolvability of the Internet?  Does the protocol
+   enable future developments?
+
+   * If an old protocol is overloaded with new functionality, or reused
+   for new purposes, have the possible complexities introduced been
+   taken carefully into account?
+
+   * For a protocol that introduces new complexity to the Internet
+   architecture, how does the protocol add robustness and preserve
+   evolvability, and how does it also introduce new fragilities to the
+   system?
+
+   Internationalization:
+
+   * Where protocols require elements in text format, have the possibly
+   conflicting requirements of global comprehensibility and the ability
+   to represent local text content been properly weighed against each
+   other?
+
+
+
+
+
+
+
+Floyd                        Informational                      [Page 4]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   DEPLOYMENT QUESTIONS:
+
+   * Is the protocol deployable?
+
+   Each of these questions is discussed in more depth in the rest of
+   this paper.
+
+4.  Justifying the Solution
+
+   Question: Why are you proposing this solution, instead of proposing
+   something else, or instead of using existing protocols and
+   procedures?
+
+4.1.  Case study: Integrated and Differentiated Services
+
+   A good part of the work of developing integrated and differentiated
+   services has been to understand the problem to be solved, and to come
+   to agreement on the architectural framework of the solution, and on
+   the nature of specific services.  Thus, when integrated services were
+   being developed, the specification of the Controlled Load [RFC2211]
+   and Guaranteed [RFC2212] services each required justification of the
+   need for that particular service, of low loss and bounded delay
+   respectively.
+
+   Later, when RFC 2475 on "An Architecture for Differentiated Services"
+   proposed a scalable, service differentiation architecture that
+   differs from the previously-defined architecture for integrated
+   services, the document also had to clearly justify the requirements
+   for this new architecture, and compare the proposed architecture to
+   other possible approaches [RFC2475].  Similarly, when the Assured
+   Forwarding [RFC2597] and Expedited Forwarding [RFC3246] Per-Hop
+   Behaviors of differentiated services were proposed, each service
+   required a justification of the need for that service in the
+   Internet.
+
+5. Interactions between Layers
+
+   Questions: Why are you proposing a solution at this layer of the
+   protocol stack, rather than at another layer?  Are there solutions at
+   other layers of the protocol stack as well?
+
+   Is this an appropriate layer in terms of correctness of function,
+   data integrity, performance, ease of deployment, the diagnosability
+   of failures, and other concerns?
+
+   What are the interactions between layers, if any?
+
+
+
+
+
+Floyd                        Informational                      [Page 5]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+5.1.  Discussion: The End-to-End Argument
+
+   The classic 1984 paper on "End-To-End Arguments In System Design"
+   [SRC84] begins a discussion of where to place functions among modules
+   by suggesting that "functions placed at low levels of a system may be
+   redundant or of little value when compared with the cost of providing
+   them at that low level.  Examples discussed in the paper include bit
+   error recovery, security using encryption, duplicate message
+   suppression, recovery from system crashes, and delivery
+   acknowledgement.  Low level mechanisms to support these functions are
+   justified only as performance enhancements."  The end-to-end
+   principle is one of the key architectural guidelines to consider in
+   choosing the appropriate layer for a function.
+
+5.2.  Case study: Endpoint Congestion Management
+
+   The goal of the Congestion Manager in Endpoint Congestion Management
+   is to allow multiple concurrent flows with the same source and
+   destination address to share congestion control state [RFC3124].
+   There has been a history of proposals for multiplexing flows at
+   different levels of the protocol stack; proposals have included
+   adding multiplexing at the HTTP (WebMux) and TCP (TCP Control Blocks)
+   layers, as well as below TCP (the Congestion Manager) [Multiplexing].
+
+   However, the 1989 article on "Layered Multiplexing Considered
+   Harmful" suggests that "the extensive duplication of multiplexing
+   functionality across the middle and upper layers is harmful and
+   should be avoided" [T89].  Thus, one of the key issues in providing
+   mechanisms for multiplexing flows is to determine which layer or
+   layers of the protocol stack are most appropriate for providing this
+   functionality.  The natural tendency of each researcher is generally
+   to add functionality at the layer that they know the best; this does
+   not necessarily result in the most appropriate overall architecture.
+
+5.3.  Case study: Layering Applications on Top of HTTP
+
+   There has been considerable interest in layering applications on top
+   of HTTP [RFC3205].  Reasons cited include compatibility with widely-
+   deployed browsers, the ability to reuse client and server libraries,
+   the ability to use existing security mechanisms, and the ability to
+   traverse firewalls.  As RFC 3205 discusses, "the recent interest in
+   layering new protocols over HTTP has raised a number of questions
+   when such use is appropriate, and the proper way to use HTTP in
+   contexts where it is appropriate." Thus, RFC 3205 addresses not only
+   the benefits of layering applications on top of HTTP, but also
+   evaluates the additional complexity and overhead of layering an
+   application on top of HTTP, compared to the costs of introducing a
+   special-purpose protocol.
+
+
+
+Floyd                        Informational                      [Page 6]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   The web page on "References on Layering and the Internet
+   Architecture" has pointers to additional papers discussing general
+   layering issues in the Internet architecture [Layering].
+
+6.  Long-term vs. Short-term Solutions
+
+   Questions: 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?  What are the
+   requirements for the development of longer-term solutions?
+
+6.1.  Case study: Traversing NATs
+
+   In order to address problems with NAT middleboxes altering the
+   external address of endpoints, various proposals have been made for
+   mechanisms where an originating process attempts to determine the
+   address (and port) by which it is known on the other side of a NAT.
+   This would allow an originating process to be able to use address
+   data in the protocol exchange, or to advertise an external address
+   from which it will receive connections.
+
+   The IAB in [RFC3424] has outlined reasons why these proposals can be
+   considered, at best, short-term fixes to specific problems, and the
+   specific issues to be carefully evaluated before standardizing such
+   proposals.  These issues include the identification of the
+   limited-scope problem to be fixed, the description of an exit
+   strategy for the short-term solution, and the description of the
+   longer-term problems left unsolved by the short-term solution.
+
+7.  Looking at the whole picture vs. making a building block
+
+   For a complex protocol which interacts with protocols from other
+   standards bodies as well as from other IETF working groups, it can be
+   necessary to keep in mind the overall picture while, at the same
+   time, breaking out specific parts of the problem to be standardized
+   in particular working groups.
+
+   Question: Have you considered the larger context, while restricting
+   your own design efforts to one part of the whole?
+
+   Question: Are there parts of the overall solution that will have to
+   be provided by other IETF Working Groups or by other standards
+   bodies?
+
+
+
+
+
+
+Floyd                        Informational                      [Page 7]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+7.1.  Case Study: The Session Initiation Protocol (SIP)
+
+   The Session Initiation Protocol (SIP) [RFC2543], for managing
+   connected, multimedia sessions,  is an example of a complex protocol
+   that has been broken into pieces for standardization in other working
+   groups.  SIP has also involved interaction with other standardization
+   bodies.
+
+   The basic SIP framework is being standardized by the SIP working
+   group.  This working group has focused on the core functional
+   features of setting up, managing, and tearing down multimedia
+   sessions.  Extensions are considered if they relate to these core
+   features.
+
+   The task of setting up a multimedia session also requires a
+   description of the desired multimedia session.  This is provided by
+   the Session Description Protocol (SDP).  SDP is a building block that
+   is supplied by the Multiparty Multimedia Session Control (MMUSIC)
+   working group.  It is not standardized within the SIP working group.
+
+   Other working groups are involved in standardizing extensions to SIP
+   that fall outside of core functional features or applications.  The
+   SIPPING working group is analyzing the requirements for SIP applied
+   to different tasks, and the SIMPLE working group is examining the
+   application of SIP to instant messaging and presence.  The IPTEL
+   working group is defining a call processing language (CPL) that
+   interacts with SIP in various ways.  These working groups
+   occasionally feed requirements back into the main SIP working group.
+
+   Finally, outside standardization groups have been very active in
+   providing the SIP working group with requirements.  The Distributed
+   Call Signaling (DCS) group from the PacketCable Consortium, 3GPP, and
+   3GPP2 are all using SIP for various telephony-related applications,
+   and members of these groups have been involved in drafting
+   requirements for SIP.  In addition, there are extensions of SIP which
+   are under consideration in these standardization bodies.  Procedures
+   are under development in the IETF to address proposed extensions to
+   SIP, including a category of preliminary, private, or proprietary
+   extensions, and to provide for the safe management of the SIP
+   namespace [MBMWOR02].
+
+8.  Weighing architectural benefits against architectural costs
+
+   Questions: How do the architectural benefits of a proposed new
+   protocol compare against the architectural costs, if any?  Have the
+   architectural costs been carefully considered?
+
+
+
+
+
+Floyd                        Informational                      [Page 8]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+8.1.  Case Study: Performance-enhancing proxies (PEPs)
+
+   RFC 3135 [RFC3135] considers the relative costs and benefits of
+   placing performance-enhancing proxies (PEPs) in the middle of a
+   network to address link-related degradations.  In the case of PEPs,
+   the potential costs include disabling the end-to-end use of IP layer
+   security mechanisms; introducing a new possible point of failure that
+   is not under the control of the end systems; adding increased
+   difficulty in diagnosing and dealing with failures; and introducing
+   possible complications with asymmetric routing or mobile hosts.  RFC
+   3135 carefully considers these possible costs, the mitigations that
+   can be introduced, and the cases when the benefits of
+   performance-enhancing proxies to the user are likely to outweigh the
+   costs.
+
+8.2.  Case Study: Open Pluggable Edge Services (OPES)
+
+   One of the issues raised by middleboxes in the Internet involves the
+   end-to-end integrity of data.  This is illustrated in the recent
+   question of chartering the Open Pluggable Edge Services (OPES)
+   Working Group.  Open Pluggable Edge Services are services that would
+   be deployed as application-level intermediaries in the network, for
+   example, at a web proxy cache between the origin server and the
+   client.  These intermediaries would transform or filter content, with
+   the explicit consent of either the content provider or the end user.
+
+   One of the architectural issues that arose in the process of
+   chartering the OPES Working Group concerned the end-to-end integrity
+   of data.  As an example, it was suggested that "OPES would reduce
+   both the integrity, and the perception of integrity, of
+   communications over the Internet, and would significantly increase
+   uncertainly about what might have been done to content as it moved
+   through the network", and that therefore the risks of OPES outweighed
+   the benefits [CDT01].
+
+   As one consequence of this debate, the IAB wrote a document on "IAB
+   Architectural and Policy Considerations for OPES", considering both
+   the potential architectural benefits and costs of OPES [RFC3238].
+   This document did not recommend specific solutions or mandate
+   specific functional requirements, but instead included
+   recommendations of issues such as concerns about data integrity that
+   OPES solutions standardized in the IETF should be required to
+   address.
+
+
+
+
+
+
+
+
+Floyd                        Informational                      [Page 9]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+9.  General Robustness Questions
+
+   Questions: How robust is the protocol, not just to the failure of
+   nodes, but also to compromised or malfunctioning components,
+   imperfect or defective implementations, etc?
+
+   Does the protocol take into account the realistic conditions of the
+   current or future Internet (e.g., packet drops and packet corruption,
+   packet reordering, asymmetric routing, etc.)?
+
+9.1.  Discussion: Designing for Robustness
+
+   Robustness has long been cited as one of the overriding goals of the
+   Internet architecture [Clark88].  The robustness issues discussed in
+   [Clark88] largely referred to the robustness of packet delivery even
+   in the presence of failed routers;  today robustness concerns have
+   widened to include a goal of robust performance in the presence of a
+   wide range of failures, buggy code, and malicious actions.
+
+   As [ASSW02] argues, protocols need to be designed somewhat
+   defensively, to maximize robustness against inconsistencies and
+   errors.  [ASSW02] discusses several approaches for increasing
+   robustness in protocols, such as verifying information whenever
+   possible; designing interfaces that are conceptually simple and
+   therefore less conducive to error; protecting resources against
+   attack or overuse; and identifying and exposing errors so that they
+   can be repaired.
+
+   Techniques for verifying information range from verifying that
+   acknowledgements in TCP acknowledge data that was actually sent, to
+   providing mechanisms for routers to verify information in routing
+   messages.
+
+   Techniques for protecting resources against attack range from
+   preventing "SYN flood" attacks by designing protocols that don't
+   allocate resources for a single SYN packet, to partitioning resources
+   (e.g., preventing one flow or aggregate from using all of the link
+   bandwidth).
+
+9.2.  Case Study: Explicit Congestion Notification (ECN)
+
+   The Internet is based on end-to-end congestion control, and
+   historically the Internet has used packet drops as the only method
+   for routers to indicate congestion to the end nodes.  ECN [RFC3168]
+   is a recent addition to the IP architecture to allow routers to set a
+   bit in the IP packet header to inform end-nodes of congestion,
+   instead of dropping the packet.
+
+
+
+
+Floyd                        Informational                     [Page 10]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   The first, Experimental specification of ECN [RFC3168] contained an
+   extensive discussion of the dangers of a rogue or broken router
+   "erasing" information from the ECN field in the IP header, thus
+   preventing indications of congestion from reaching the end-nodes.  To
+   add robustness, the standards-track specification [RFC3168] specified
+   an additional codepoint in the IP header's ECN field, to use for an
+   ECN "nonce".  The development of the ECN nonce was motivated by
+   earlier research on specific robustness issues in TCP [SCWA99].  RFC
+   3168 explains that the addition of the codepoint "is motivated
+   primarily by the desire to allow mechanisms for the data sender to
+   verify that network elements are not erasing the CE codepoint, and
+   that data receivers are properly reporting to the sender the receipt
+   of packets with the CE codepoint set, as required by the transport
+   protocol." Supporting mechanisms for the ECN nonce are needed in the
+   transport protocol to ensure robustness of delivery of the ECN-based
+   congestion indication.
+
+   In contrast, a more difficult and less clear-cut robustness issue for
+   ECN concerns the differential treatment of packets in the network by
+   middleboxes, based on the TCP header's ECN flags in a TCP SYN packet
+   [RFC3360].  The issue concerns "ECN-setup" SYN packets, that is, SYN
+   packets with ECN flags set in the TCP header to negotiate the use of
+   ECN between the two TCP end-hosts.  There exist firewalls in the
+   network that drop "ECN-setup" SYN packets, others that send TCP Reset
+   messages, and yet others that zero ECN flags in TCP headers.  None of
+   this was anticipated by the designers of ECN, and RFC 3168 added
+   optional mechanisms to permit the robust operation of TCP in the
+   presence of firewalls that drop "ECN-setup" SYN packets.  However,
+   ECN is still not robust to all possible scenarios of middleboxes
+   zeroing ECN flags in the TCP header.  Up until now, transport
+   protocols have been standardized independently from the mechanisms
+   used by middleboxes to control the use of these protocols, and it is
+   still not clear what degree of robustness is required from transport
+   protocols in the presence of the unauthorized modification of
+   transport headers in the network.  These and similar issues are
+   discussed in more detail in [RFC3360].
+
+10.  Avoiding Tragedy of the Commons
+
+   Question: Is performance still robust if everyone is using the new
+   protocol?  Are there other potential impacts of widespread deployment
+   that need to be considered?
+
+10.1.  Case Study: End-to-end Congestion Control
+
+   [RFC2914] discusses the potential for congestion collapse if flows
+   are not using end-to-end congestion control in a time of high
+   congestion.  For example, if a new transport protocol was proposed
+
+
+
+Floyd                        Informational                     [Page 11]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   that did not use end-to-end congestion control, it might be easy to
+   show that an individual flow using the new transport protocol would
+   perform quite well as long as all of the competing flows in the
+   network were using end-to-end congestion control.  To fully evaluate
+   the new transport protocol, it is necessary to look at performance
+   when many flows are competing, all using the new transport protocol.
+   If all of the competing flows were using the more aggressive
+   transport protocol in a time of high congestion, the result could be
+   high steady-state packet drop rates and reduced overall throughput,
+   with busy links carrying packets that will only be dropped
+   downstream.  This can be viewed as a form of tragedy of the commons,
+   when a practice that is productive if done by only one person (e.g.,
+   adding a few more sheep to the common grazing pasture) is instead
+   counter-productive when done by everyone [H68].
+
+11.  Balancing Competing Interests
+
+   Question: Does the protocol protect the interests of competing
+   parties (e.g., not only end-users, but also ISPs, router vendors,
+   software vendors, or other parties)?
+
+11.1.  Discussion: balancing competing interests
+
+   [CWSB02] discusses the role that competition between competing
+   interests plays in the evolution of the Internet, and takes the
+   position that the role of Internet protocols is to design the playing
+   field in this competition, rather than to pick the outcome.  The IETF
+   has long taken the position that it can only design the protocols,
+   and that often two competing approaches will be developed, with the
+   marketplace left to decide between them [A02].  (It has also been
+   suggested that "the marketplace" left entirely to itself does not
+   always make the best decisions, and that working to identify and
+   adopt the technically best solution is sometimes helpful.  Thus,
+   while the role of the marketplace should not be ignored, the
+   decisions of the marketplace should also not be held as sacred or
+   infallible.)
+
+   An example cited in [CWSB02] of modularization in support of
+   competing interests is the decision to use codepoints in the IP
+   header to select QoS, rather than binding QoS to other properties
+   such as port numbers.  This separates the structural and economic
+   issues related to QoS from technical issues of protocols and port
+   numbers, and allows space for a wide range of structural and pricing
+   solutions to emerge.
+
+   There have been perceived problems over the years of individuals
+   adding unnecessary complexity to IETF protocols, increasing the
+   barrier to other implementations of those protocols.  Clearly such
+
+
+
+Floyd                        Informational                     [Page 12]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   action would not be protecting the interests of open competition.
+   Underspecified protocols can also serve as an unnecessary barrier to
+   open competition.
+
+12.  Designing for Choice vs. Avoiding Unnecessary Complexity:
+
+   Is the protocol designed for choice, to allow different players to
+   express their preferences where appropriate?  At the other extreme,
+   does the protocol provide so many choices that it threatens
+   interoperability or introduces other significant problems?
+
+12.1.  Discussion: the importance of choice
+
+   [CWSB02] suggests that "the fundamental design goal of the Internet
+   is to hook computers together, and since computers are used for
+   unpredictable and evolving purposes, making sure that the users are
+   not constrained in what they can do is doing nothing more than
+   preserving the core design tenet of the Internet.  In this context,
+   user empowerment is a basic building block, and should be embedded
+   into all mechanism whenever possible."
+
+   As an example of choice, "the design of the mail system allows the
+   user to select his SMTP server and his POP server" [CWSB02].  More
+   open-ended questions about choice concern the design of mechanisms
+   that would enable the user to choose the path at the level of
+   providers, or to allow users to choose third-party intermediaries
+   such as web caches, or providers for Open Pluggable Edge Services
+   (OPES).  [CWSB02] also notes that the issue of choice itself reflects
+   competing interests.  For example, ISPs would generally like to lock
+   in customers, while customers would like to preserve their ability to
+   change among providers.
+
+   At the same time, we note that excessive choice can lead to "kitchen
+   sink" protocols that are inefficient and hard to understand, have too
+   much negotiation, or have unanticipated interactions between options.
+   For example, [P99] notes that excessive choice can lead to difficulty
+   in ensuring interoperability between two independent, conformant
+   implementations of the protocol.
+
+   The dangers of excessive options are also discussed in [MBMWOR02],
+   which gives guidelines for responding to the "continuous flood" of
+   suggestions for modifications and extensions to SIP (Session
+   Initiation Protocol).  In particular, the SIP Working Group is
+   concerned that proposed extensions have general use, and do not
+   provide efficiency at the expense of simplicity or robustness.
+   [MBMWOR02] suggests that other highly extensible protocols developed
+   in the IETF might also benefit from more coordination of extensions.
+
+
+
+
+Floyd                        Informational                     [Page 13]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+13.  Preserving evolvability?
+
+   Does the protocol protect the interests of the future, by preserving
+   the evolvability of the Internet?  Does the protocol enable future
+   developments?
+
+   If an old protocol is overloaded with new functionality, or reused
+   for new purposes, have the possible complexities introduced been
+   taken into account?
+
+   For a protocol that introduces new complexity to the Internet
+   architecture, does the protocol add robustness and preserve
+   evolvability?  Does it also introduce unwanted new fragilities to the
+   system?
+
+13.1.  Discussion: evolvability
+
+   There is an extensive literature and an ongoing discussion about the
+   evolvability, or lack of evolvability, of the Internet
+   infrastructure; the web page on "Papers on the Evolvability of the
+   Internet Infrastructure" has pointers to some of this literature
+   [Evolvability].  Issues range from the evolvability and overloading
+   of the DNS; the difficulties of the Internet in evolving to
+   incorporate multicast, QoS, or IPv6; the difficulties of routing in
+   meeting the demands of a changing and expanding Internet; and the
+   role of firewalls and other middleboxes in limiting evolvability.
+
+   [CWSB02] suggests that among all of the issues of evolvability,
+   "keeping the net open and transparent for new applications is the
+   most important goal."  In the beginning, the relative transparency of
+   the infrastructure was sufficient to ensure evolvability, where a
+   "transparent" network simply routes packets from one end-node to
+   another.  However, this transparency has become more murky over time,
+   as cataloged in [RFC3234], which discusses the ways that middleboxes
+   interact with existing protocols and increase the difficulties in
+   diagnosing failures.  [CWSB02] realistically suggests the following
+   guideline: "Failures of transparency will occur - design what happens
+   then," where examples of failures of transparency include firewalls,
+   application filtering, connection redirection, caches, kludges to
+   DNS, and the like.  Thus, maintaining evolvability also requires
+   mechanisms for allowing evolution in the face of a lack of
+   transparency of the infrastructure itself.
+
+   One of the ways for maintaining evolvability is for designers of new
+   mechanisms and protocols to be as clear as possible about the
+   assumptions that are being made about the rest of the network.  New
+
+
+
+
+
+Floyd                        Informational                     [Page 14]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   mechanisms that make unwarranted assumptions about the network can
+   end up placing unreasonable constraints on the future evolution of
+   the network.
+
+13.2.  Discussion: overloading
+
+   There has been a strong tendency in the last few years to overload
+   some designs with new functionality, with resulting operational
+   complexities.  Extensible protocols could be seen as one of the tools
+   for providing evolvability.  However, if protocols and systems are
+   stretched beyond their reasonable design parameters, then scaling,
+   reliability, or security issues could be introduced.  Examples of
+   protocols that have been seen as either productively extended, or as
+   dangerously overloaded, or both, include DNS [K02,RFC3403], MPLS
+   [A02a], and BGP [B02].  In some cases, overloading or extending a
+   protocol may reduce total complexity and deployment costs by avoiding
+   the creation of a new protocol; in other cases a new protocol might
+   be the simpler solution.
+
+   We have a number of reusable technologies, including component
+   technologies specifically designed for re-use.  Examples include
+   SASL, BEEP and APEX.  TCP and UDP can also be viewed as reusable
+   transport protocols, used by a range of applications.  On the other
+   hand, re-use should not go so far as to turn a protocol into a Trojan
+   Horse, as has happened with HTTP [RFC3205].
+
+13.3.  Discussion: complexity, robustness, and fragility
+
+   [WD02] gives a historical account of the evolution of the Internet as
+   a complex system, with particular attention to the tradeoffs between
+   complexity, robustness, and fragility.  [WD02] describes the
+   robustness that follows from the simplicity of a connectionless,
+   layered, datagram infrastructure and a universal logical addressing
+   scheme, and, as case studies, describes the increasing complexity of
+   TCP and of BGP.  The paper describes a complexity/robustness spiral
+   of an initially robust design and the appearance of fragilities,
+   followed by modifications for more robustness that themselves
+   introduce new fragilities.  [WD02] conjectures that "the Internet is
+   only now beginning to experience an acceleration of this
+   complexity/robustness spiral and, if left unattended, can be fully
+   expected to experience arcane, irreconcilable, and far-reaching
+   robustness problems in the not-too-distant future."  Citing [WD02],
+   [BFM02] focuses on the ways that complexity increases capital and
+   operational expenditures in carrier IP network, and views complexity
+   as the primary mechanism that impedes efficient scaling.
+
+
+
+
+
+
+Floyd                        Informational                     [Page 15]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+14.  Internationalization
+
+   Where protocols require elements in text format, have the possibly
+   conflicting requirements of global comprehensibility and the ability
+   to represent local text content been properly weighed against each
+   other?
+
+14.1.  Discussion: internationalization
+
+   RFC 1958 [RFC1958] included a simple statement of the need for a
+   common language:
+
+   "Public (i.e. widely visible) names should be in case-independent
+   ASCII.  Specifically, this refers to DNS names, and to protocol
+   elements that are transmitted in text format."
+
+   The IETF has studied character set issues in general [RFC 2130] and
+   made specific recommendations for the use of a standardized approach
+   [RFC 2277].  The situation is complicated by the fact that some uses
+   of text are hidden entirely in protocol elements and need only be
+   read by machines, while other uses are intended entirely for human
+   consumption.  Many uses lie between these two extremes, which leads
+   to conflicting implementation requirements.
+
+   For the specific case of DNS, the Internationalized Domain Name
+   working group is considering these issues.  As stated in the charter
+   of that working group, "A fundamental requirement in this work is to
+   not disturb the current use and operation of the domain name system,
+   and for the DNS to continue to allow any system anywhere to resolve
+   any domain name."  This leads to some very strong requirements for
+   backwards compatibility with the existing ASCII-only DNS.  Yet since
+   the DNS has come to be used as if it was a directory service, domain
+   names are also expected to be presented to users in local character
+   sets.
+
+   This document does not attempt to resolve these complex and difficult
+   issues, but simply states this as an issue to be addressed in our
+   work.  The requirement that names encoded in a text format within
+   protocol elements be universally decodable (i.e. encoded in a
+   globally standard format with no intrinsic ambiguity) does not seem
+   likely to change.  However, at some point, it is possible that this
+   format will no longer be case-independent ASCII.
+
+
+
+
+
+
+
+
+
+Floyd                        Informational                     [Page 16]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+15.  Deployability
+
+   Question: Is the protocol deployable?
+
+15.1.  Discussion: deployability
+
+   It has been suggested that the failure to understand deployability
+   considerations in the current environment is one of the major
+   weakness of the IETF.  As examples of deployment difficulties, RFC
+   2990 [RFC2990] discusses deployment difficulties with Quality of
+   Service (QoS) architectures, various documents of the MBONE
+   Deployment Working Group address deployment problems with IP
+   Multicast, and the IPv6 Working Group discusses a wealth of issues
+   related to the deployment of IPv6.  [CN02] discusses how the
+   deployment of Integrated Services has been limited by factors such as
+   the failure to take into account administrative boundaries.
+   Additional papers on difficulties in the evolution of the Internet
+   architecture are available from [Evolvability].
+
+   Issues that can complicate deployment include whether the protocol is
+   compatible with pre-existing standards, and whether the protocol is
+   compatible with the installed base.  For example, a transport
+   protocol is more likely to be deployable if it performs correctly and
+   reasonably robustly in the presence of dropped, reordered,
+   duplicated, delayed, and rerouted packets, as all of this can occur
+   in the current Internet.
+
+16.  Conclusions
+
+   This document suggests general architectural and policy questions to
+   be addressed when working on new protocols and standards in the IETF.
+
+   The case studies in this document have generally been short
+   illustrations of how the questions proposed in the document have been
+   addressed in working groups in the past.  However, we have generally
+   steered away from case studies of more controversial issues, where
+   there is not yet a consensus in the IETF community.  Thus, we
+   side-stepped suggestions for adding a case study for IKE (Internet
+   Key Exchange) as an possible example of a protocol with too much
+   negotiation, or of adding a case study of network management
+   protocols as illustrating the possible costs of leaving things to the
+   marketplace to decide.  We would encourage others to contribute case
+   studies of these or any other issues that may shed light on some of
+   the questions in this document;  any such case studies could include
+   a careful presentation of the architectural reasoning on both sides.
+
+
+
+
+
+
+Floyd                        Informational                     [Page 17]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   we would conjecture that there is a lot to be learned, in terms of
+   the range of answers to the questions posed in this document, by
+   studying the successes, failures, and other struggles of the past.
+
+   We would welcome feedback on this document for future revisions.
+   Feedback could be send to the editor, Sally Floyd, at floyd@icir.org.
+
+17.  Acknowledgements
+
+   This document has borrowed text freely from other IETF RFCs, and has
+   drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere.  This
+   document has developed from discussions in the IAB, and has drawn
+   from suggestions made at IAB Plenary sessions and on the ietf general
+   discussion mailing list.  The case study on SIP was contributed by
+   James Kempf, an early case study on Stresses on DNS was contributed
+   by Karen Sollins, and Keith Moore contributed suggestions that were
+   incorporated in a number of places in the document.  The discussions
+   on Internationalization and on Overloading were based on an earlier
+   document by Brian Carpenter and Rob Austein.  We have also benefited
+   from discussions with Noel Chiappa, Karen Sollins, John Wroclawski,
+   and others, and from helpful feedback from members of the IESG.  We
+   specifically thank Senthilkumar Ayyasamy, John Loughney, Keith Moore,
+   Eric Rosen, and Dean Willis and others for feedback on various stages
+   of this document.
+
+18.  Normative References
+
+19.  Informative References
+
+   [A02]          Harald Alvestrand, "Re: How many standards or
+                  protocols...", email to the ietf discussion mailing
+                  list, Message-id:  <598204031.1018942481@localhost>,
+                  April 16, 2002.
+
+   [A02a]         Loa Andersson, "The Role of MPLS in Current IP
+                  Network", MPLS World News, September 16, 2002.  URL
+                  "http://www.mplsworld.com/archi_drafts/focus/analy-
+                  andersson.htm".
+
+   [ASSW02]       T. Anderson, S. Shenker, I. Stoica, and D. Wetherall,
+                  "Design Guidelines for Robust Internet Protocols",
+                  HotNets-I, October 2002.
+
+   [BFM02]        Randy Bush, Tim Griffin, and David Meyer, "Some
+                  Internet Architectural Guidelines and Philosophy",
+                  Work in Progress.
+
+
+
+
+
+Floyd                        Informational                     [Page 18]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   [B02]          Hamid Ould-Brahim, Bryan Gleeson, Peter Ashwood-Smith,
+                  Eric C. Rosen, Yakov Rekhter, Luyuan Fang, Jeremy De
+                  Clercq, Riad Hartani, and Tissa Senevirathne, "Using
+                  BGP as an Auto-Discovery Mechanism for Network-based
+                  VPNs", Work in Progress.
+
+   [CDT01]        Policy Concerns Raised by Proposed OPES Working Group
+                  Efforts, email to the IESG, from the Center for
+                  Democracy & Technology, August 3, 2001.  URL
+                  "http://www.imc.org/ietf-openproxy/mail-
+                  archive/msg00828.html".
+
+   [Clark88]      David D. Clark, The Design Philosophy of the DARPA
+                  Internet Protocols, SIGCOMM 1988.
+
+   [CN02]         Brian Carpenter, Kathleen Nichols, "Differentiated
+                  Services in the Internet", Technical Report, February
+                  2002, URL "http://www.research.ibm.com/resources/
+                  paper_search.shtml".
+
+   [CWSB02]       Clark, D., Wroslawski, J., Sollins, K., and Braden,
+                  R., "Tussle in Cyberspace: Defining Tomorrow's
+                  Internet", SIGCOMM 2002.  URL
+                  "http://www.acm.org/sigcomm/sigcomm2002/papers/
+                  tussle.html".
+
+   [Evolvability] Floyd, S., "Papers on the Evolvability of the Internet
+                  Infrastructure".  Web Page, URL
+                  "http://www.icir.org/floyd/evolution.html".
+
+   [H68]          Garrett Hardin, "The Tragedy of the Commons", Science,
+                  V. 162, 1968, pp. 1243-1248.  URL
+                  "http://dieoff.org/page95.htm".
+
+   [K02]          John C. Klensin, "Role of the Domain Name System",
+                  Work in Progress.
+
+   [Layering]     Floyd, S., "References on Layering and the Internet
+                  Architecture", Web Page, URL
+                  "http://www.icir.org/floyd/layers.html".
+
+   [Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the
+                  Discussion", Web Page, URL
+                  "http://www.icir.org/floyd/tcp_mux.html".
+
+
+
+
+
+
+
+Floyd                        Informational                     [Page 19]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   [MBMWOR02]     Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.
+                  and B. Rosen, "Change Process for the Session
+                  Initiation Protocol (SIP)", BCP 67, RFC 3427, November
+                  2002.
+
+   [M01]          Tim Moors, A Critical Review of End-to-end Arguments
+                  in System Design, 2001.  URL
+                  "http://uluru.poly.edu/~tmoors/".
+
+   [P99]          Radia Perlman, "Protocol Design Folklore", in
+                  Interconnections Second Edition: Bridges, Routers,
+                  Switches, and Internetworking Protocols, Addison-
+                  Wesley, 1999.
+
+   [RFC1958]      Carpenter, B.,  "Architectural Principles of the
+                  Internet", RFC 1958, June 1996.
+
+   [RFC2211]      Wroclawski, J., "Specification of the Controlled Load
+                  Quality of Service", RFC 2211, September 1997.
+
+   [RFC2212]      Shenker, S., Partridge, C., and R. Guerin,
+                  "Specification of Guaranteed Quality of Service", RFC
+                  2212, September 1997.
+
+   [RFC2316]      Bellovin, S., "Report of the IAB Security Architecture
+                  Workshop", RFC 2316, April 1998.
+
+   [RFC2475]      Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+                  Z.  and W. Weiss, "An Architecture for Differentiated
+                  Services", RFC 2475, December 1998.
+
+   [RFC2543]      Handley, M., Schulzrinne, H., Schooler, B. and J.
+                  Rosenberg, "SIP: Session Initiation Protocol", RFC
+                  25434, March 1999.
+
+   [RFC2597]      Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
+                  "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [RFC2990]      Huston, G., "Next Steps for the IP QoS Architecture",
+                  RFC 2990, November 2000.
+
+   [RFC3124]      Balakrishnan, H. and S. Seshan, "The Congestion
+                  Manager", RFC 3124, June 2001.
+
+   [RFC3135]      Border, J., Kojo, M., Griner, J., Montenegro, G. and
+                  Z.  Shelby, "Performance Enhancing Proxies Intended to
+                  Mitigate Link-Related Degradations", RFC 3135, June
+                  2001.
+
+
+
+Floyd                        Informational                     [Page 20]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+   [RFC3168]      Ramakrishnan, K. K., Floyd, S. and D. Black, "The
+                  Addition of Explicit Congestion Notification (ECN) to
+                  IP", RFC 3168, September 2001.
+
+   [RFC3205]      Moore, K., "On the use of HTTP as a Substrate", BCP
+                  56, RFC 3205, February 2002.
+
+   [RFC3221]      Huston, G., "Commentary on Inter-Domain Routing in the
+                  Internet", RFC 3221, December 2001.
+
+   [RFC3234]      Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+                  Issues", RFC 3234, February 2002.
+
+   [RFC3238]      Floyd, S. and L. Daigle, "IAB Architectural and Policy
+                  Considerations for Open Pluggable Edge Services", RFC
+                  3238, January 2002.
+
+   [RFC3246]      Davie, B., Charny, A., Bennet, J. C. R., Benson, K.,
+                  Le Boudec, J. Y., Courtney, W., Davari, S., Firoiu, V.
+                  and D. Stiliadis, "An Expedited Forwarding PHB (Per-
+                  Hop Behavior)", RFC 3246, March 2002.
+
+   [RFC3360]      Floyd, S., "Inappropriate TCP Resets Considered
+                  Harmful", BCP 60, RFC 3360, August 2002.
+
+   [RFC3403]      Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Three: The Domain Name System (DNS)
+                  Database", RFC 3403, October 2002.
+
+   [RFC3424]      Daigle, L., "IAB Considerations for UNilateral Self-
+                  Address Fixing (UNSAF)", RFC 3424, November 2002.
+
+   [SCWA99]       Stefan Savage, Neal Cardwell, David Wetherall, Tom
+                  Anderson, "TCP Congestion Control with a Misbehaving
+                  Receiver", ACM Computer Communications Review, October
+                  1999.
+
+   [SRC84]        J. Saltzer, D. Reed, and D. D. Clark, "End-To-End
+                  Arguments In System Design", ACM Transactions on
+                  Computer Systems, V.2, N.4, p.  277-88. 1984.
+
+   [T89]          D. Tennenhouse, "Layered Multiplexing Considered
+                  Harmful", Protocols for High-Speed Networks, 1989.
+
+   [WD02]         Walter Willinger and John Doyle, "Robustness and the
+                  Internet: Design and Evolution", draft, March 2002,
+                  URL "http://netlab.caltech.edu/internet/".
+
+
+
+
+Floyd                        Informational                     [Page 21]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+20.  Security Considerations
+
+   This document does not propose any new protocols, and therefore does
+   not involve any security considerations in that sense.  However,
+   throughout this document there are discussions of the privacy and
+   integrity issues and the architectural requirements created by those
+   issues.
+
+21.  IANA Considerations
+
+   There are no IANA considerations regarding this document.
+
+Authors' Addresses
+
+   Internet Architecture Board
+   EMail:  iab@iab.org
+
+   IAB Membership at time this document was completed:
+
+   Harald Alvestrand
+   Ran Atkinson
+   Rob Austein
+   Fred Baker
+   Leslie Daigle
+   Steve Deering
+   Sally Floyd
+   Ted Hardie
+   Geoff Huston
+   Charlie Kaufman
+   James Kempf
+   Eric Rescorla
+   Mike St. Johns
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Floyd                        Informational                     [Page 22]
+
+RFC 3426        Architectural and Policy Considerations    November 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Floyd                        Informational                     [Page 23]
+