Network Working Group S. Floyd, Editor
Request for Comments: 3426 Internet Architecture Board
Category: Informational November 2002
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.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件提出了IETF社区在制定新标准和协议时必须解决的一般架构和政策问题。我们注意到，本文件包含需要解决的问题，而不是需要遵循的指导方针或体系结构原则。
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].
本文件提出了IETF工作中需要解决的总体架构和政策问题。本文档包含需要解决的问题，而不是需要遵循的指南或体系结构原则。这些问题与IETF文件[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.
本文件的部分动机是担心整个互联网架构越来越缺乏一致性。我们已经从一个由一小群人设计的单一、连贯的体系结构世界，转变为一个复杂、复杂的体系结构世界，以应对广泛和异构的环境。因为建筑的每一个部分通常是由子社区设计的，每个子社区都有自己的兴趣集，所以需要更加关注每个作品如何适合更大的图片，并考虑每个作品是如何被选择的。例如，不可避免的是，我们每个人都倾向于在协议栈层解决问题，并使用我们最了解的工具；这并不一定意味着这是解决这一长期问题的最合适的工具层或工具集。
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.
我们的假设是，本文件将被用作IETF成员在组建新工作组、在工作组中工作以及评估其他工作组输出时要解决的问题的建议（但不是清单！）。本文档不是关于如何设计协议和体系结构的入门，也没有提供任何答案。
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."
RFC 1958[RFC1958]概述了互联网的一些体系结构原则，如“过去发现的有用的指南，可能对设计新协议或评估此类设计有用的指南”。一个示例指南是“一般认为端到端功能最好通过端到端协议实现。”类似地，[RFC1958]中的一个示例设计问题是“异构性是不可避免的，必须由设计支持。”
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."
相比之下，其他问题则更加开放，例如关于健壮性的问题：“协议的健壮性如何，不仅针对节点故障，而且针对受损或故障组件、不完善或有缺陷的实现等？”作为一个社区，我们仍在学习我们能够构建到协议中的健壮性程度，以及确保这种健壮性的可用工具。因此，按照“确保您的协议对X、Y和Z具有健壮性”的思路，目前还没有明确的体系结构指南
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.
在本节中，我们列出了在设计协议时要问的一些问题。每一个问题都将在本文的其余部分进行更深入的讨论。我们并不是建议所有的协议设计工作都需要明确回答所有这些问题；有些问题与一份文件的相关性比与另一份文件的相关性更大。我们也不是说这是一个完整的体系结构关注点列表。
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?
* 整体解决方案中有哪些部分必须由其他IETF工作组或其他标准机构提供？
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?
* 协议的健壮性有多强，不仅针对节点故障，还针对受损或故障的组件、不完善或有缺陷的实现等？
* 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)?
* 协议是否保护竞争各方的利益（例如，不仅是最终用户，还包括ISP、路由器供应商、软件供应商或其他各方）？
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?
* 当协议要求文本格式的元素时，是否已对全球可理解性和表示本地文本内容的能力的可能冲突要求进行适当权衡？
DEPLOYMENT QUESTIONS:
部署问题：
* Is the protocol deployable?
* 协议是否可以部署？
Each of these questions is discussed in more depth in the rest of this paper.
本文的其余部分将对这些问题进行更深入的讨论。
Question: Why are you proposing this solution, instead of proposing something else, or instead of using existing protocols and procedures?
问：您为什么提出这个解决方案，而不是提出其他解决方案，或者使用现有的协议和过程？
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.
开发集成和差异化服务的大部分工作是理解要解决的问题，并就解决方案的体系结构框架和特定服务的性质达成一致。因此，在开发集成服务时，受控负载[RFC2211]和保证[RFC2212]服务的规范都要求分别证明对该特定服务的需求为低损耗和有界延迟。
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.
后来，当关于“差异化服务架构”的RFC 2475提出了一种不同于先前定义的集成服务架构的可扩展、服务差异化架构时，该文件还必须明确证明这种新架构的要求，并将提出的架构与其他可能的方法进行比较[RFC2475]。类似地，当提出区分服务的保证转发[RFC2597]和加速转发[RFC3246]每跳行为时，每个服务都需要证明在互联网上需要该服务。
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?
各层之间的相互作用是什么（如果有的话）？
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.
1984年关于“系统设计中的端到端参数”的经典论文[SRC84]开始讨论在模块之间放置函数的位置，建议“与在低水平上提供功能的成本相比，在系统的低水平上放置的功能可能是多余的或没有什么价值。本文讨论的示例包括位错误恢复、使用加密的安全性、重复消息抑制、系统崩溃恢复和传递确认。支持这些功能的低级机制只是作为性能增强的理由。“端到端原则是在选择一个函数的适当层时考虑的关键体系结构准则之一。
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].
端点拥塞管理中拥塞管理器的目标是允许具有相同源地址和目标地址的多个并发流共享拥塞控制状态[RFC3124]。在协议栈的不同层次上，已经有过多路复用流的提议；建议包括在HTTP（WebMux）和TCP（TCP控制块）层以及TCP（拥塞管理器）层下方添加多路复用。
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.
然而，1989年关于“分层复用被认为是有害的”的文章指出，“跨中上层复用功能的大量重复是有害的，应该避免”[T89]。因此，为多路复用流提供机制的关键问题之一是确定协议栈的哪一层或几层最适合提供此功能。每个研究人员的自然倾向通常是在他们最了解的层添加功能；这并不一定会产生最合适的总体架构。
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.
在HTTP[RFC3205]之上分层应用程序已经引起了相当大的兴趣。引用的理由包括与广泛部署的浏览器的兼容性、重用客户端和服务器库的能力、使用现有安全机制的能力以及穿越防火墙的能力。正如RFC 3205所讨论的，“最近对在HTTP上分层新协议的兴趣提出了许多问题，这些问题是何时使用合适，以及在合适的上下文中使用HTTP的正确方式。”因此，RFC 3205不仅解决了在HTTP上分层应用程序的好处，但也评估了与引入专用协议的成本相比，在HTTP之上分层应用程序的额外复杂性和开销。
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].
“关于分层和互联网架构的参考文献”的网页指向了讨论互联网架构中一般分层问题的其他论文[分层]。
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?
如果没有，就未来发展的限制而言，该解决方案的长期成本是多少（如果有）？制定长期解决方案的要求是什么？
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.
为了解决NAT中间盒改变端点外部地址的问题，对于发起进程试图确定NAT另一端已知的地址（和端口）的机制提出了各种建议。这将允许发起进程能够在协议交换中使用地址数据，或播发它将从中接收连接的外部地址。
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.
[RFC3424]中的IAB概述了为什么这些提案最多可以被视为针对特定问题的短期解决方案，以及在标准化这些提案之前需要仔细评估的特定问题。这些问题包括确定要修复的有限范围问题，描述短期解决方案的退出策略，以及描述短期解决方案遗留下来的长期问题。
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.
对于与其他标准机构以及其他IETF工作组的协议进行交互的复杂协议，可能需要记住总体情况，同时，在特定工作组中划分待标准化问题的特定部分。
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?
问题：整体解决方案中有哪些部分必须由其他IETF工作组或其他标准机构提供？
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.
用于管理连接的多媒体会话的会话发起协议（SIP）[RFC2543]是复杂协议的一个示例，该协议已在其他工作组中被分解为多个部分进行标准化。SIP还涉及与其他标准化机构的互动。
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.
SIP工作组正在对基本SIP框架进行标准化。该工作组专注于设置、管理和拆除多媒体会话的核心功能。如果扩展与这些核心功能相关，则会考虑扩展。
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.
设置多媒体会话的任务还需要描述所需的多媒体会话。这是由会话描述协议（SDP）提供的。SDP是由多方多媒体会话控制（MMUSIC）工作组提供的构建块。SIP工作组内未对其进行标准化。
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.
其他工作组则参与标准化SIP扩展，这些扩展不属于核心功能特性或应用程序。SIPing工作组正在分析应用于不同任务的SIP需求，SIMPLE工作组正在研究SIP在即时消息和状态中的应用。IPTEL工作组正在定义一种以各种方式与SIP交互的呼叫处理语言（CPL）。这些工作组偶尔会将需求反馈给主要的SIP工作组。
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].
最后，外部标准化小组一直非常积极地向SIP工作组提供需求。来自PacketCable Consortium、3GPP和3GPP2的分布式呼叫信令（DCS）组都将SIP用于各种电话相关应用，这些组的成员都参与了SIP需求的起草。此外，这些标准化机构正在考虑SIP的扩展。IETF正在开发程序，以解决SIP的拟议扩展，包括初步、私有或专有扩展类别，并提供SIP命名空间的安全管理[MBMWOR02]。
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?
问题：提议的新协议的架构优势与架构成本（如果有的话）相比如何？是否仔细考虑了建筑成本？
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.
RFC 3135 [RFC3135]考虑在网络中间放置性能增强代理（PEPS）以解决链路相关劣化的相对成本和益处。就PEP而言，潜在成本包括禁用IP层安全机制的端到端使用；引入不在终端系统控制下的新的可能故障点；增加了故障诊断和处理的难度；以及不对称路由或移动主机可能带来的复杂性。RFC 3135仔细考虑了这些可能的成本、可以引入的缓解措施，以及性能增强代理对用户的好处可能超过成本的情况。
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.
互联网中的中间商提出的一个问题涉及到数据的端到端完整性。最近关于特许开放可插拔边缘服务（OPES）工作组的问题说明了这一点。开放可插拔边缘服务是在网络中作为应用程序级中介部署的服务，例如，在源服务器和客户端之间的web代理缓存中。这些中介机构将在内容提供商或最终用户明确同意的情况下转换或过滤内容。
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].
在特许OPES工作组的过程中出现的架构问题之一涉及数据的端到端完整性。例如，有人提出，“运营支出将降低互联网上通信的完整性和对完整性的感知，并将显著增加在内容通过网络时可能对其采取的措施的不确定性”，因此运营支出的风险大于收益[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.
作为此次辩论的一个结果，IAB编写了一份关于“IAB运营商的架构和政策考虑”的文件，同时考虑了运营商的潜在架构优势和成本[RFC3238]。本文件并未建议具体的解决方案或规定具体的功能要求，而是包含了一些问题的建议，如IETF中标准化的OPES解决方案需要解决的数据完整性问题。
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.)?
协议是否考虑了当前或未来互联网的实际情况（例如，数据包丢失和数据包损坏、数据包重新排序、非对称路由等）？
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.
健壮性一直被认为是互联网体系结构的首要目标之一[Clark88]。[Clark88]中讨论的健壮性问题主要指即使在存在故障路由器的情况下，数据包交付的健壮性；今天，健壮性问题已经扩展到包括在出现大量故障、错误代码和恶意操作时的健壮性能目标。
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.
正如[ASSW02]所指出的，协议的设计需要有一定的防御性，以最大限度地增强对不一致性和错误的鲁棒性。[ASSW02]讨论了几种增强协议健壮性的方法，如尽可能验证信息；设计概念简单的接口，因此不容易出错；保护资源免受攻击或过度使用；以及识别和暴露错误，以便修复它们。
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.
验证信息的技术范围从验证TCP中的确认是否确认实际发送的数据，到为路由器提供验证路由消息中信息的机制。
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).
保护资源免受攻击的技术包括通过设计不为单个SYN数据包分配资源的协议来防止“SYN洪水”攻击，以及对资源进行分区（例如，防止一个流或聚合使用所有链路带宽）。
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.
互联网是基于端到端拥塞控制的，历史上，互联网使用丢包作为路由器向端节点指示拥塞的唯一方法。ECN[RFC3168]是IP体系结构的最新添加，允许路由器在IP数据包头中设置一个位，以通知终端节点拥塞，而不是丢弃数据包。
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.
ECN的第一个实验性规范[RFC3168]广泛讨论了恶意或损坏的路由器“擦除”IP报头中ECN字段的信息的危险，从而防止拥塞指示到达终端节点。为了增加健壮性，标准跟踪规范[RFC3168]在IP报头的ECN字段中指定了一个额外的代码点，用于ECN“nonce”。ECN nonce的开发是由TCP中特定健壮性问题的早期研究[SCWA99]推动的。RFC 3168解释说，添加代码点“主要是希望允许数据发送方的机制验证网元没有擦除CE代码点，并且数据接收方按照传输协议的要求正确地向发送方报告接收到带有CE代码点集的数据包。”传输协议中需要ECN nonce的支持机制，以确保基于ECN的拥塞指示交付的健壮性。
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].
相比之下，ECN的一个更困难、更不明确的健壮性问题涉及基于TCP SYN数据包中TCP报头的ECN标志的中间盒对网络中的数据包的区别处理[RFC3360]。该问题涉及“ECN设置”SYN数据包，即在TCP报头中设置ECN标志的SYN数据包，以协商两个TCP终端主机之间ECN的使用。网络中存在丢弃“ECN设置”SYN数据包的防火墙、发送TCP重置消息的防火墙以及在TCP头中设置零ECN标志的防火墙。ECN的设计者没有预料到这一点，RFC 3168增加了可选机制，以允许TCP在存在丢弃“ECN设置”SYN数据包的防火墙的情况下稳健运行。然而，ECN对于所有可能出现的中间盒将TCP报头中的ECN标志归零的情况仍然不是很健壮。到目前为止，传输协议已经独立于中间盒用于控制这些协议的使用的机制进行了标准化，并且还不清楚在网络中存在未经授权的传输头修改的情况下，传输协议需要多大程度的健壮性。[RFC3360]中详细讨论了这些问题和类似问题。
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?
问题：如果每个人都在使用新协议，性能是否仍然稳定？是否需要考虑广泛部署的其他潜在影响？
[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
[RFC2914]讨论了在高拥塞时，如果流不使用端到端拥塞控制，则拥塞崩溃的可能性。例如，如果提出了新的传输协议
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].
如果不使用端到端拥塞控制，则很容易证明，只要网络中的所有竞争流都使用端到端拥塞控制，使用新传输协议的单个流的性能就会相当好。为了全面评估新的传输协议，有必要查看多个流竞争时的性能，所有流都使用新的传输协议。如果所有竞争流在高拥塞时使用更激进的传输协议，结果可能是高稳态数据包丢弃率和总体吞吐量降低，繁忙链路承载的数据包只会在下游丢弃。这可以被视为公地悲剧的一种形式，如果一个人只做一件事（例如，在公共牧场多放几只羊）就会产生效果，而每个人都做一件事则会产生反效果[H68]。
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)?
问题：该协议是否保护竞争各方的利益（例如，不仅是最终用户，还包括ISP、路由器供应商、软件供应商或其他各方）？
[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.)
[CWSB02]讨论了相互竞争的利益之间的竞争在互联网发展中所起的作用，并认为互联网协议的作用是设计竞争环境，而不是选择结果。IETF长期以来的立场是，它只能设计协议，通常会开发两种相互竞争的方法，让市场在它们之间做出决定[A02]。（也有人建议“市场”完全由市场自行决定并不总是做出最佳决策，而努力确定并采用技术上最佳的解决方案有时是有帮助的。因此，虽然不应忽视市场的作用，但市场的决策也不应被视为神圣的或绝对正确的。）
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.
[CWSB02]中引用的支持竞争利益的模块化示例是，决定使用IP报头中的代码点来选择QoS，而不是将QoS绑定到端口号等其他属性。这将与QoS相关的结构和经济问题与协议和端口号的技术问题分开，并为各种结构和定价解决方案的出现提供了空间。
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
多年来，人们已经意识到一些问题，这些问题给IETF协议增加了不必要的复杂性，增加了这些协议的其他实现的障碍。显然如此
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:
12. 为选择而设计与避免不必要的复杂性：
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?
协议是否为选择而设计，以允许不同的玩家在适当的情况下表达他们的偏好？在另一个极端，协议是否提供了如此多的选择，以至于威胁到互操作性或引入其他重大问题？
[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."
[CWSB02]建议“互联网的基本设计目标是将计算机连接在一起，由于计算机用于不可预测和不断发展的目的，确保用户不受限制，他们可以做什么，只不过是保持互联网的核心设计宗旨。在这种情况下，用户授权是一个基本组成部分，应尽可能嵌入所有机制。”
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.
例如，“邮件系统的设计允许用户选择其SMTP服务器和POP服务器”[CWSB02]。更多关于选择的开放性问题涉及到机制的设计，这些机制允许用户在提供商级别选择路径，或允许用户选择第三方中介，如web缓存，或开放可插拔边缘服务（OPE）提供商。[CWSB02]还指出，选择问题本身反映了相互竞争的利益。例如，ISP通常希望锁定客户，而客户希望保留其在供应商之间进行更改的能力。
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.
同时，我们注意到，过度选择可能导致“厨房-水槽”协议效率低下、难以理解、谈判过多或选项之间存在意料之外的交互。例如，[P99]指出，过度选择可能导致难以确保协议的两个独立、一致的实现之间的互操作性。
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.
[MBMWOR02]中还讨论了过多选项的危险，其中给出了应对SIP（会话启动协议）修改和扩展建议“持续泛滥”的指南。特别是，SIP工作组关注的是，提议的扩展具有普遍用途，不能以牺牲简单性或健壮性为代价提供效率。[MBMWOR02]表明，IETF中开发的其他高度可扩展协议也可能受益于扩展的更多协调。
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?
对于给互联网架构带来新复杂性的协议，该协议是否增加了健壮性并保持了可进化性？它是否也会给系统带来不必要的新脆弱性？
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.
关于互联网基础设施的可进化性或不可进化性，有大量文献和正在进行的讨论；“关于互联网基础设施可进化性的论文”的网页上有一些相关文献[可进化性]的指针。问题包括DNS的可进化性和过载；互联网发展到包含多播、QoS或IPv6的困难；路由难以满足不断变化和扩展的互联网的需求；防火墙和其他中间盒在限制可进化性方面的作用。
[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.
[CWSB02]指出，在所有可进化性问题中，“保持网络对新应用程序的开放和透明是最重要的目标。”一开始，基础设施的相对透明度足以确保可进化性，“透明”网络只是将数据包从一端节点路由到另一端节点。然而，随着时间的推移，这种透明度变得越来越模糊，如[RFC3234]中所述，其中讨论了中间盒与现有协议交互的方式，并增加了故障诊断的难度。[CWSB02]实事求是地提出了以下指导原则：“将发生透明性故障-设计发生的情况”，其中透明性故障的示例包括防火墙、应用程序过滤、连接重定向、缓存、到DNS的乱码等。因此，保持可进化性还需要在基础设施本身缺乏透明度的情况下允许进化的机制。
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
保持可进化性的方法之一是让新机制和协议的设计者尽可能清楚地了解关于网络其余部分的假设。刚出现的
mechanisms that make unwarranted assumptions about the network can end up placing unreasonable constraints on the future evolution of the network.
对网络做出不必要假设的机制最终可能会对网络的未来发展施加不合理的约束。
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.
在过去几年中，出现了一种强烈的趋势，即使用新功能使某些设计过载，从而导致操作复杂性。可扩展协议可以看作是提供可进化性的工具之一。然而，如果协议和系统超出其合理的设计参数，则可能会引入可扩展性、可靠性或安全性问题。被视为有效扩展或危险过载或两者兼有的协议示例包括DNS[K02、RFC3403]、MPLS[A02a]和BGP[B02]。在某些情况下，重载或扩展协议可以通过避免创建新协议来降低总体复杂性和部署成本；在其他情况下，新协议可能是更简单的解决方案。
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].
我们有许多可重用的技术，包括专门为重用而设计的组件技术。示例包括SASL、BEEP和APEX。TCP和UDP也可以被视为可重用的传输协议，由一系列应用程序使用。另一方面，重复使用不应该像HTTP[RFC3205]那样将协议变成特洛伊木马。
[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.
[WD02]介绍了互联网作为一个复杂系统的发展历史，特别关注复杂性、鲁棒性和脆弱性之间的权衡。[WD02]描述了无连接、分层的数据报基础设施和通用逻辑寻址方案的简单性所带来的健壮性，并作为案例研究，描述了TCP和BGP日益增加的复杂性。本文描述了最初稳健设计的复杂性/稳健螺旋，以及脆弱性的出现，然后是为更稳健而进行的修改，这些修改本身引入了新的脆弱性。[WD02]推测“互联网现在才开始经历这种复杂性/健壮性螺旋的加速，如果不加以关注，完全可以预期在不太遥远的将来会遇到神秘、不可调和和影响深远的健壮性问题。”引用[WD02]，[BFM02]重点讨论复杂性增加运营商IP网络资本和运营支出的方式，并将复杂性视为阻碍有效扩展的主要机制。
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?
当协议要求文本格式的元素时，是否已对全球可理解性和表示本地文本内容的能力的可能冲突要求进行适当权衡？
RFC 1958 [RFC1958] included a simple statement of the need for a common language:
RFC 1958[RFC1958]包括一个简单的通用语言需求声明：
"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."
公共（即广泛可见）名称应采用独立于大小写的ASCII。具体而言，这指的是DNS名称和以文本格式传输的协议元素
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.
IETF研究了字符集的一般问题[RFC 2130]，并提出了使用标准化方法的具体建议[RFC 2277]。文本的某些用途完全隐藏在协议元素中，只需要机器读取，而其他用途则完全用于人类消费，这一事实使情况更加复杂。许多用途介于这两个极端之间，这会导致冲突的实现需求。
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.
对于DNS的具体案例，国际化域名工作组正在考虑这些问题。正如该工作组章程所述，“这项工作的一个基本要求是不干扰域名系统的当前使用和运行，DNS继续允许任何地方的任何系统解析任何域名。”这导致对向后兼容现有仅ASCII DNS的一些非常强烈的要求。然而，由于DNS已经被当作一种目录服务来使用，域名也将以本地字符集的形式呈现给用户。
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.
本文件并不试图解决这些复杂和困难的问题，只是将其作为我们工作中需要解决的问题加以阐述。协议元素中以文本格式编码的名称是通用可解码的（即以无内在歧义的全球标准格式编码）这一要求似乎不会改变。但是，在某些情况下，这种格式可能不再是大小写无关的ASCII。
Question: Is the protocol deployable?
问题：该协议是否可部署？
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].
有人认为，未能理解当前环境中的可部署性考虑因素是IETF的主要弱点之一。作为部署困难的示例，RFC 2990[RFC2990]讨论了服务质量（QoS）体系结构的部署困难，MBONE部署工作组的各种文件解决了IP多播的部署问题，IPv6工作组讨论了大量与IPv6部署相关的问题。[CN02]讨论了集成服务的部署如何受到各种因素的限制，如未能考虑管理边界。关于互联网体系结构演变中的困难的其他论文可从[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.
可能使部署复杂化的问题包括协议是否与现有标准兼容，以及协议是否与已安装的基础兼容。例如，如果传输协议在存在丢弃的、重新排序的、重复的、延迟的和重新路由的数据包的情况下正确且合理地稳健地执行，则传输协议更有可能被部署，因为所有这些都可能发生在当前互联网中。
This document suggests general architectural and policy questions to be addressed when working on new protocols and standards in the IETF.
本文件提出了在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.
本文件中的案例研究通常是简要说明过去工作组如何处理文件中提出的问题。然而，我们通常避开了更多争议性问题的案例研究，在这些问题上IETF社区尚未达成共识。因此，我们回避了添加IKE（Internet密钥交换）案例研究的建议，将其作为协议过度协商的可能示例，或添加网络管理协议的案例研究，以说明将事情留给市场决定的可能成本。我们鼓励其他人提供这些问题或任何其他问题的案例研究，以阐明本文件中的一些问题；任何这样的案例研究都可以包括对双方架构推理的仔细介绍。
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.
我们欢迎对本文件的反馈意见，以供今后修订。反馈可以发送给编辑Sally Floydfloyd@icir.org.
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.
本文件自由借用了其他IETF RFC的文本，并借鉴了[ASSW02]、[CWSB02]、[M01]和其他地方的思想。本文件来源于IAB的讨论，并借鉴了IAB全体会议和ietf一般性讨论邮件列表中提出的建议。关于SIP的案例研究由James Kempf提供，关于DNS压力的早期案例研究由Karen Sollins提供，Keith Moore提供的建议包含在文件中的许多地方。关于国际化和重载的讨论是基于Brian Carpenter和Rob Austein的早期文档。我们还受益于与Noel Chiappa、Karen Sollins、John Wroclawski和其他人的讨论，以及IESG成员的有益反馈。我们特别感谢Senthilkumar Ayyasamy、John Loughney、Keith Moore、Eric Rosen和Dean Willis等人对本文件各个阶段的反馈。
[A02] Harald Alvestrand, "Re: How many standards or protocols...", email to the ietf discussion mailing list, Message-id: <598204031.1018942481@localhost>, April 16, 2002.
[A02]Harald Alvestrand，“回复：有多少标准或协议…”，发送电子邮件至ietf讨论邮件列表，邮件id：<598204031。1018942481@localhost>，2002年4月16日。
[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".
[A02a]Loa Andersson，“MPLS在当前IP网络中的作用”，《MPLS世界新闻》，2002年9月16日。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.
[ASSW02]T.Anderson，S.Shenker，I.Stoica和D.Wetheral，“健壮互联网协议的设计指南”，HotNets-I，2002年10月。
[BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some Internet Architectural Guidelines and Philosophy", Work in Progress.
[BFM02]Randy Bush、Tim Griffin和David Meyer，“一些互联网架构指南和哲学”，正在进行中。
[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.
[B02]Hamid Ould Brahim、Bryan Gleeson、Peter Ashwood Smith、Eric C.Rosen、Yakov Rekhter、Fang Luyuan、Jeremy De Clercq、Riad Hartani和Tissa Senevirathne，“使用BGP作为基于网络的VPN的自动发现机制”，工作正在进行中。
[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".
[CDT01]提议的OPES工作组工作提出的政策问题，通过电子邮件发送至IESG，来自民主与技术中心，2001年8月3日。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.
[Clark88]David D.Clark，DARPA互联网协议的设计理念，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".
[CN02]Brian Carpenter，Kathleen Nichols，“互联网中的差异化服务”，技术报告，2002年2月，URL“http://www.research.ibm.com/resources/ 论文搜索.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".
[CWSB02]Clark，D.，Wroslawski，J.，Sollins，K.，和Braden，R.，“网络空间中的争斗：定义明天的互联网”，SIGCOM2002。URL“http://www.acm.org/sigcomm/sigcomm2002/papers/ html”。
[Evolvability] Floyd, S., "Papers on the Evolvability of the Internet Infrastructure". Web Page, URL "http://www.icir.org/floyd/evolution.html".
[Evolvability]Floyd，S.，“互联网基础设施的可进化性论文”。网页，网址“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".
[H68]Garrett Hardin，“公地悲剧”，《科学》第162卷，1968年，第1243-1248页。URL“http://dieoff.org/page95.htm".
[K02] John C. Klensin, "Role of the Domain Name System", Work in Progress.
[K02]John C.Klensin，“域名系统的作用”，正在进行中。
[Layering] Floyd, S., "References on Layering and the Internet Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html".
[Layering]Floyd，S.，“关于分层和互联网架构的参考”，网页，网址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".
[多路复用]S.Floyd，“多路复用、TCP和UDP：指向讨论的指针”，网页，URL“http://www.icir.org/floyd/tcp_mux.html".
[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.
[MBMWOR02]Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.和B.Rosen，“会话启动协议（SIP）的更改过程”，BCP 67，RFC 3427，2002年11月。
[M01] Tim Moors, A Critical Review of End-to-end Arguments in System Design, 2001. URL "http://uluru.poly.edu/~tmoors/".
[M01]Tim Moors，《系统设计中端到端论点的评论》，2001年。URL“http://uluru.poly.edu/~t门/”。
[P99] Radia Perlman, "Protocol Design Folklore", in Interconnections Second Edition: Bridges, Routers, Switches, and Internetworking Protocols, Addison-Wesley, 1999.
[P99]Radia Perlman，“协议设计民俗”，互联第二版：网桥、路由器、交换机和互联网协议，Addison-Wesley，1999年。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负载服务质量规范”，RFC2211，1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC2316]Bellovin，S.，“IAB安全架构研讨会报告”，RFC 2316，1998年4月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, B. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 25434, March 1999.
[RFC2543]Handley，M.，Schulzrinne，H.，Schooler，B.和J.Rosenberg，“SIP：会话启动协议”，RFC 25434，1999年3月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]Huston，G.，“IP QoS架构的下一步”，RFC 29902000年11月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]Balakrishnan，H.和S.Seshan，“拥堵管理者”，RFC31242001年6月。
[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.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[RFC3168] Ramakrishnan, K. K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[RFC3205]Moore，K.，“关于HTTP作为基板的使用”，BCP 56，RFC 3205，2002年2月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]Huston，G.“互联网中域间路由的评论”，RFC3221，2001年12月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB体系结构和政策考虑”，RFC 3238，2002年1月。
[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.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.R.，Benson，K.，Le Boudec，J.Y.，Courtney，W.，Davari，S.，Firoiu，V.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]Floyd，S.，“不适当的TCP重置被认为是有害的”，BCP 60，RFC 3360，2002年8月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403]Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年10月。
[RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
[RFC3424]Daigle，L.，“IAB对单边自定址（UNSAF）的考虑”，RFC 34242002年11月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review, October 1999.
[SCWA99]Stefan Savage，Neal Cardwell，David Wetheral，Tom Anderson，“使用行为不当接收器的TCP拥塞控制”，ACM计算机通信评论，1999年10月。
[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.
[SRC84]J.Saltzer，D.Reed和D.D.Clark，“系统设计中的端到端参数”，计算机系统上的ACM交易，第2版，第4页。277-88. 1984
[T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful", Protocols for High-Speed Networks, 1989.
[T89]D.Tennenhouse，“分层复用被认为是有害的”，高速网络协议，1989年。
[WD02] Walter Willinger and John Doyle, "Robustness and the Internet: Design and Evolution", draft, March 2002, URL "http://netlab.caltech.edu/internet/".
[WD02]沃尔特·威林格和约翰·道尔，“健壮性与互联网：设计与进化”，草稿，2002年3月，网址“http://netlab.caltech.edu/internet/".
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.
本文件未提出任何新协议，因此不涉及该意义上的任何安全考虑。然而，在本文件中，讨论了隐私和完整性问题以及这些问题产生的体系结构要求。
There are no IANA considerations regarding this document.
关于本文件，没有IANA考虑事项。
Authors' Addresses
作者地址
Internet Architecture Board EMail: iab@iab.org
互联网架构委员会电子邮件：iab@iab.org
IAB Membership at time this document was completed:
本文件完成时的IAB成员资格：
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
哈拉尔·阿尔维斯特兰德（Harald Alvestrand）经营的是阿特金森（Atkinson）、罗布·奥斯汀（Rob Austein）、弗雷德·贝克（Fred Baker）、莱斯利·戴格尔（Leslie Daigle）、史蒂夫·迪林（Steve Deering）、萨莉·弗洛伊德（Sally Floyd）、泰德·哈迪（Ted Hardie）、杰夫
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。