Network Working Group G. Scott, Editor
Request for Comments: 2360 Defense Information Systems Agency
BCP: 22 June 1998
Category: Best Current Practice
Network Working Group G. Scott, Editor
Request for Comments: 2360 Defense Information Systems Agency
BCP: 22 June 1998
Category: Best Current Practice
Guide for Internet Standards Writers
互联网标准编写者指南
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors".
本文件为互联网标准编写者指南。它定义了使标准连贯、明确且易于解释的特征。此外，它还特别指出了被认为导致规范不明确的用法，从而导致过去不可互操作的解释。这些指南将与RFC 2223“RFC作者须知”一起使用。
Table of Contents
目录
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2
2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3
2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4
2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6
2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6
2.8 Response to Out of Specification Behavior . . . . . . . . . 6
2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7
2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8
2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9
2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9
2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10
2.14 Network Management Considerations . . . . . . . . . . . . 10
2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10
2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11
2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2
2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3
2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4
2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6
2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6
2.8 Response to Out of Specification Behavior . . . . . . . . . 6
2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7
2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8
2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9
2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9
2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10
2.14 Network Management Considerations . . . . . . . . . . . . 10
2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10
2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11
2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11
2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12
3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12
3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13
3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13
4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15
5 Security Considerations . . . . . . . . . . . . . . . . . 16
6 References . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18
8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18
9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19
10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20
2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12
3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12
3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13
3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13
4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15
5 Security Considerations . . . . . . . . . . . . . . . . . 16
6 References . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18
8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18
9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19
10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20
1 Introduction
1导言
This document is a guide for Internet standard writers. It offers guidelines on how to write a standards-track document with clarity, precision, and completeness. These guidelines are based on both prior successful and unsuccessful IETF specification experiences. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors", or its update. Note that some guidelines may not apply in certain situations.
本文件为互联网标准编写者指南。它提供了关于如何清晰、准确和完整地编写标准跟踪文档的指南。这些指南基于先前成功和不成功的IETF规范经验。这些指南将与RFC 2223“RFC作者须知”或其更新一起使用。请注意，某些指南可能不适用于某些情况。
The goal is to increase the possibility that multiple implementations of a protocol will interoperate. Writing specifications to these guidelines will not guarantee interoperability. However, a recognized barrier to the creation of interoperable protocol implementations is unclear specifications.
其目标是增加协议的多个实现进行互操作的可能性。按照这些准则编写规范并不能保证互操作性。然而，创建可互操作协议实现的公认障碍是规范不明确。
Many will benefit from having well-written protocol specifications. Implementers will have a better chance to conform to the protocol specification. Protocol testers can use the specification to derive unambiguous testable statements. Purchasers and users of the protocol will have a better understanding of its capabilities.
许多人将受益于编写良好的协议规范。实现者将有更好的机会遵守协议规范。协议测试人员可以使用规范来派生明确的可测试语句。协议的购买者和用户将更好地了解其功能。
For further information on the process for standardizing protocols and procedures please refer to BCP 9/RFC 2026, "The Internet Standards Process -- Revision 3". In addition, some considerations for protocol design are given in RFC 1958, "Architectural Principles of the Internet".
有关协议和程序标准化过程的更多信息，请参考BCP 9/RFC 2026，“互联网标准过程——第3版”。此外，RFC1958“互联网的体系结构原则”中给出了协议设计的一些考虑因素。
2 General Guidelines
2一般准则
It is important that multiple readers and implementers of a standard have the same understanding of a document. To this end, information should be orderly and detailed. The following are general guidelines intended to help in the production of such a document. The IESG may require that all or some of the following sections appear in a
一个标准的多个读者和实施者对一个文档有相同的理解是很重要的。为此，信息应有序、详细。以下是旨在帮助编制此类文件的一般指南。IESG可能要求以下所有或部分章节出现在
standards track document.
标准跟踪文件。
If the Internet is to achieve its full potential in commercial, governmental, and personal affairs, it must assure users that their information transfers are free from tampering or compromise. Well-written security sections in standards-track documents can help promote the confidence level required. Above all, new protocols and practices must not worsen overall Internet security.
如果互联网要在商业、政府和个人事务中充分发挥其潜力，就必须确保用户的信息传输不受篡改或泄露。标准跟踪文档中写得好的安全部分可以帮助提高所需的可信度。最重要的是，新的协议和实践决不能恶化总体互联网安全。
A significant threat to the Internet comes from those individuals who are motivated and capable of exploiting circumstances, events, or vulnerabilities of the system to cause harm. In addition, deliberate or inadvertent user behavior may expose the system to attack or exploitation. The harm could range from disrupting or denying network service, to damaging user systems. Additionally, information disclosure could provide the means to attack another system, or reveal patterns of behavior that could be used to harm an individual, organization, or network. This is a particular concern with standards that define a portion of the Management Information Base (MIB).
对互联网的重大威胁来自那些有动机并能够利用环境、事件或系统漏洞造成伤害的个人。此外，有意或无意的用户行为可能会使系统受到攻击或利用。危害可能从中断或拒绝网络服务到破坏用户系统。此外，信息披露可以提供攻击另一个系统的手段，或揭示可用于伤害个人、组织或网络的行为模式。这是定义管理信息库（MIB）一部分的标准特别关注的问题。
Standards authors must accept that the protocol they specify will be subject to attack. They are responsible for determining what attacks are possible, and for detailing the nature of the attacks in the document. Otherwise, they must convincingly argue that attack is not realistic in a specific environment, and restrict the use of the protocol to that environment.
标准作者必须接受他们指定的协议将受到攻击。他们负责确定可能发生的攻击，并在文档中详细说明攻击的性质。否则，他们必须有说服力地论证攻击在特定环境中是不现实的，并将协议的使用限制在该环境中。
After the document has exhaustively identified the security risks the protocol is exposed to, the authors must formulate and detail a defense against those attacks. They must discuss the applicable countermeasures employed, or the risk the user is accepting by using the protocol. The countermeasures may be provided by a protocol mechanism or by reliance on external mechanisms. Authors should be knowledgeable of existing security mechanisms, and reuse them if practical. When a cryptographic algorithm is used, the protocol should be written to permit its substitution with another algorithm in the future. Finally, the authors should discuss implementation hints or guidelines, e.g., how to deal with untrustworthy data or peer systems.
在文档彻底确定了协议所面临的安全风险之后，作者必须制定并详细说明针对这些攻击的防御措施。他们必须讨论采用的适用对策，或用户通过使用协议接受的风险。反措施可通过协议机制或依靠外部机制提供。作者应该了解现有的安全机制，并在可行的情况下重用它们。当使用加密算法时，应该编写协议以允许将来用另一种算法替换它。最后，作者应该讨论实现提示或指南，例如，如何处理不可信数据或对等系统。
Security measures will have an impact within the environment that they are used. Perhaps users will now be constrained on what they can do in the Internet, or will experience degradation in the speed of service. The effects the security measures have on the protocol's use and performance should be discussed.
安全措施将在其使用的环境中产生影响。也许用户现在将被限制在他们可以在互联网上做什么，或者将体验到服务速度的下降。应该讨论安全措施对协议使用和性能的影响。
The discussion of security can be concentrated in the Security Considerations section of the document, or throughout the document where it is relevant to particular parts of the specification. An advantage of the second approach is that it ensures security is an integral part of the protocol's development, rather than something that is a follow-on or secondary effort. If security is discussed throughout the document, the Security Considerations section must summarize and refer to the appropriate specification sections. This will insure that the protocol's security measures are emphasized to implementer and user both.
关于安全性的讨论可以集中在文档的安全注意事项部分，也可以贯穿整个文档，其中与规范的特定部分相关。第二种方法的优点是，它确保安全性是协议开发的一个组成部分，而不是后续工作或次要工作。如果在整个文档中讨论了安全性，则安全注意事项部分必须总结并参考相应的规范部分。这将确保协议的安全措施对实现者和用户都很重要。
Within the Security Considerations section, a discussion of the path not taken may be appropriate. There may be several security mechanisms that were not selected for a variety of reasons: cost or difficulty of implementation, or ineffectiveness for a given network environment. By listing the mechanisms they did not use and the reasons, editors can demonstrate that the protocol's WG gave security the necessary thought. In addition, this gives the protocol's users the information they need to consider whether one of the non-selected mechanisms would be better suited to their particular requirements.
在“安全注意事项”部分中，讨论未采取的路径可能是合适的。由于各种原因，可能有几种安全机制未被选择：实施成本或难度，或者对于给定的网络环境无效。通过列出他们没有使用的机制和原因，编辑可以证明协议的工作组对安全性进行了必要的考虑。此外，这为协议的用户提供了他们需要考虑的信息，即一个非选择的机制是否更适合于他们的特定需求。
A document giving further guidance on security topics is in development. Authors should obtain a copy of the completed RFC to help them prepare the security portion of the standard.
正在编写一份关于安全问题的进一步指导文件。作者应获得完整RFC的副本，以帮助他们准备标准的安全部分。
Finally, it is no longer acceptable that Security Considerations sections consist solely of statements to the effect that security was not considered in preparing the standard.
最后，不再接受安全注意事项部分仅包含声明，大意是在编制标准时未考虑安全。
Some examples of Security Considerations sections are found in STD 33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939. RFC 2316, "Report of the IAB Security Architecture Workshop", provides additional information in this topic area.
STD 33/RFC 1350、STD 51/RFC 1662和STD 53/RFC 1939中提供了一些安全注意事项章节的示例。RFC 2316，“IAB安全架构研讨会报告”提供了该主题领域的其他信息。
Standards track documents must include a description of the protocol. This description must address the protocol's purpose, intended functions, services it provides, and, the arena, circumstances, or any special considerations of the protocol's use.
标准跟踪文件必须包括协议说明。本说明必须说明协议的目的、预期功能、提供的服务，以及协议使用的场所、环境或任何特殊考虑因素。
The authors of a protocol specification will have a great deal of knowledge as to the reason for the protocol. However, the reader is more likely to have general networking knowledge and experience, rather than expertise in a particular protocol. An explanation of it's purpose and use will give the reader a reference point for
协议规范的作者将对协议的原因有大量的了解。然而，读者更有可能拥有一般的网络知识和经验，而不是特定协议方面的专业知识。对其用途和用途的解释将为读者提供参考
understanding the protocol, and where it fits in the Internet. The STD 54/RFC 2328 was recommended to the STDGUIDE working group as providing a good example of this in its "Protocol Overview" section.
了解协议，以及它在Internet中的位置。STD 54/RFC 2328被推荐给STD指南工作组，作为其“协议概述”部分的一个很好的例子。
The protocol's general description must also provide information on the relationship between the different parties to the protocol. This can be done by showing typical packet sequences.
议定书的一般说明还必须提供关于议定书不同缔约方之间关系的信息。这可以通过显示典型的数据包序列来实现。
This also applies to the algorithms used by a protocol. A detailed description of the algorithms or citation of readily available references that give such a description is necessary.
这也适用于协议使用的算法。有必要对算法进行详细描述，或引用现成的参考文献进行描述。
RFCs have been written with many different purposes, ranging from the technical to the administrative. Those written as standards should clearly identify the intended audience, for example, designers, implementers, testers, help desk personnel, educators, end users, or others. If there are multiple audiences being addressed in the document, the section for each audience needs to be identified. The goal is to help the reader discover and focus on what they have turned to the document for, and avoid what they may find confusing, diverting, or extraneous.
RFC有许多不同的用途，从技术到管理。作为标准编写的标准应该清楚地确定目标受众，例如，设计师、实施者、测试者、帮助台人员、教育者、最终用户或其他人。如果文档中有多个受众，则需要确定每个受众的部分。目的是帮助读者发现并专注于他们转向文档的目的，避免他们可能发现的混淆、转移注意力或无关的内容。
The author should consider what level of descriptive detail best conveys the protocol's intent. Concise text has several advantages. It makes the document easier to read. Such text reduces the chance for conflict between different portions of the specification. The reader can readily identify the required protocol mechanisms in the standard. In addition, it makes it easier to identify the requirements for protocol implementation. A disadvantage of concise descriptions is that a reader may not fully comprehend the reasoning behind the protocol, and thus make assumptions that will lead to implementation errors.
作者应该考虑什么程度的描述细节最好地传达协议的意图。简洁的文本有几个优点。它使文档更容易阅读。这样的文本减少了规范不同部分之间发生冲突的机会。读者可以容易地识别标准中所需的协议机制。此外，它还可以更容易地确定协议实现的需求。简洁描述的一个缺点是，读者可能无法完全理解协议背后的推理，从而做出会导致实现错误的假设。
Longer descriptions may be necessary to explain purpose, background, rationale, implementation experience, or to provide tutorial information. This helps the reader understand the protocol. Yet, several dangers exist with lengthy text. Finding the protocol requirements in the text is difficult or confusing. The same mechanism may have multiple descriptions, which leads to misinterpretation or conflict. Finally, it is more difficult to comprehend, a consideration as English is not the native language of the many worldwide readers of IETF standards.
可能需要更长的描述来解释目的、背景、基本原理、实施经验或提供教程信息。这有助于读者理解协议。然而，冗长的文本存在着一些危险。在文本中查找协议要求是困难的或令人困惑的。同一机制可能有多个描述，这会导致误解或冲突。最后，它更难理解，因为英语不是IETF标准的许多全球读者的母语。
One approach is to divide the standard into sections: one describing the protocol concisely, while another section consists of explanatory text. The STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 provides examples of this method.
一种方法是将标准分成几个部分：一部分简要描述协议，另一部分由解释性文本组成。STD 3/RFC 1122/RFC 1123和STD 54/RFC 2328提供了该方法的示例。
As a document moves along the standards track, from Proposed to Draft or Draft to Full, or cycles in level, it will undergo changes due to better understanding of the protocol or implementation experience. To help implementers track the changes being made a log showing what has changed from the previous version of the specification is required (see Appendix).
当一份文件沿着标准的轨道前进，从提议到起草或起草到完整，或在级别上循环时，由于对协议或实施经验的更好理解，它将经历变化。为了帮助实施者跟踪所做的更改，需要一个日志，显示与规范先前版本相比所做的更改（见附录）。
Often the standard is specifying a new version of an existing protocol. In such a case, the authors should detail the differences between the previous version and the new version. This should include the rationale for the changes, for example, implementation experience, changes in technology, responding to user demand, etc.
该标准通常指定现有协议的新版本。在这种情况下，作者应详细说明前一版本和新版本之间的差异。这应包括变更的理由，例如实施经验、技术变更、响应用户需求等。
In standards development, reaching consensus requires making difficult choices. These choices are made through working group discussions or from implementation experience. By including the basis for a contentious decision, the author can prevent future revisiting of these disagreements when the original parties have moved on. In addition, the knowledge of the "why" is as useful to an implementer as the description of "how". For example, the alternative not taken may have been simpler to implement, so including the reasons behind the choice may prevent future implementers from taking nonstandard shortcuts.
在标准开发中，达成共识需要做出艰难的选择。这些选择是通过工作组讨论或根据实施经验做出的。通过将争议性决定的依据包括在内，作者可以防止在最初各方继续前进时，这些分歧再次出现。此外，“为什么”的知识对于实现者来说与“如何”的描述一样有用。例如，未采用的替代方案可能更易于实现，因此包括选择背后的原因可能会阻止未来的实现者采用非标准的快捷方式。
A detail description of the actions taken in case of behavior that is deviant from or exceeds the specification is useful. This is an area where implementers often differ in opinion as to the appropriate response. By specifying a common response, the standard author can reduce the risk that different implementations will come in to conflict.
对于偏离或超过规范的行为，详细描述所采取的措施是有用的。这是一个实施者经常对适当的响应有不同意见的领域。通过指定公共响应，标准作者可以降低不同实现发生冲突的风险。
The standard should describe responses to behavior explicitly forbidden or out of the boundaries defined by the specification. Two possible approaches to such cases are discarding, or invoking error-handling mechanisms. If discarding is chosen, detailing the
该标准应描述对明确禁止的行为或超出规范规定边界的行为的响应。处理此类情况的两种可能方法是丢弃或调用错误处理机制。如果选择了丢弃，则详细说明
disposition may be necessary. For instance, treat dropped frames as if they were never received, or reset an existing connection or adjacency state.
处置可能是必要的。例如，将丢弃的帧视为从未收到，或重置现有连接或邻接状态。
The specification should describe actions taken when a critical resource or a performance-scaling limit is exceeded. This is necessary for cases where a risk of network degradation or operational failure exists. In such cases, a consistent behavior between implementations is necessary.
规范应描述在超过关键资源或性能扩展限制时采取的措施。这对于存在网络退化或操作故障风险的情况是必要的。在这种情况下，实现之间的一致行为是必要的。
A rule, first stated in STD 5/RFC 791, recognized as having benefits in implementation robustness and interoperability is:
STD 5/RFC 791中首先规定的一条规则，被认为在实现健壮性和互操作性方面具有优势，即：
"Be liberal in what you accept, and conservative in what you send".
“接受的东西要自由，发送的东西要保守”。
Or establish restrictions on what a protocol transmits, but be able to deal with every conceivable error received. Caution is urged in applying this approach in standards track protocols. It has in the past lead to conflicts between vendors when interoperability fails. The sender accuses the receiver of failing to be liberal enough, and the receiver accuses the sender of not being conservative enough. Therefore, the author is obligated to provide extensive detail on send and receive behavior.
或者对协议传输的内容设置限制，但能够处理收到的每一个可能的错误。在标准跟踪协议中应用此方法时应谨慎。在过去，当互操作性失败时，它会导致供应商之间的冲突。发送者指责接收者不够自由，接收者指责发送者不够保守。因此，作者有义务提供有关发送和接收行为的详细信息。
To avoid any confusion between the two, recommend that standard authors specify send and receive behavior separately. The description of reception will require the most detailing. For implementations are expected to continue operating regardless of error received. Therefore, the actions taken to achieve that result, need to be laid out in the protocol specification. Standard authors should concern themselves on achieving a level of cooperation that limits network disruption, not just how to survive on the network. The appearance of undefined information or conditions must not cause a network or host failure. This requires specification on how to attempt acceptance of most of the packets. Two approaches are available, either using as much of the packet's content as possible, or invoking error procedures. The author should specify a dividing line on when to take which approach.
为了避免两者之间的混淆，建议标准作者分别指定发送和接收行为。接待的描述需要最详细的说明。无论收到何种错误，预期实现都将继续运行。因此，需要在协议规范中列出为实现该结果而采取的行动。标准作者应该关注的是如何实现限制网络中断的合作水平，而不仅仅是如何在网络上生存。出现未定义的信息或情况不得导致网络或主机故障。这需要说明如何尝试接受大多数数据包。有两种方法可用，要么使用尽可能多的数据包内容，要么调用错误过程。作者应该在何时采取哪种方法上指定一条分界线。
A case for consideration is that of a routing protocol, where acceptance of flawed information can cause network failure. For protocols such as this, the specification should identify packets that could have different interpretations and mandate that they be rejected completely or the nature of the attempt to recover some information from them. For example, routing updates that contain
需要考虑的一种情况是路由协议，其中接受有缺陷的信息可能导致网络故障。对于这样的协议，规范应该识别可能有不同解释的数据包，并要求完全拒绝这些数据包，或者确定试图从这些数据包中恢复某些信息的性质。例如，路由更新包含
more data than the tuple count shows. The protocol authors should consider whether some trailing data can be accepted as additional routes, or to reject the entire packet as suspect because it is non-conformant.
比元组计数显示的数据更多。协议作者应该考虑一些尾随数据是否可以被接受为附加路由，或者拒绝整个分组作为可疑的，因为它是不符合的。
Specifications with many optional features increase the complexity of the implementation and the chance of non-interoperable implementations. The danger is that different implementations may specify some combination of options that are unable to interoperate with each other.
具有许多可选特性的规范增加了实现的复杂性和不可互操作实现的可能性。危险在于，不同的实现可能会指定一些无法互操作的选项组合。
As the document moves along the standard track, implementation experience shall determine the need for each option. Implementation shall show whether the option should be a mandatory part of the protocol or remain an option. If an option is not implemented as the document advances, it must be removed from the protocol before it reaches draft standard status.
当文件沿着标准轨道移动时，实施经验应确定每个选项的需要。实施应表明该选项是协议的强制性部分还是仍然是选项。如果某个选项在文档推进时未实施，则必须在其达到标准草案状态之前将其从协议中删除。
Therefore, options shall only be present in a protocol to address a real requirement. For example, options can support future extensibility of the protocol, a particular market, e.g., the financial industry, or a specific network environment, e.g., a network constrained by limited bandwidth. They shall not be included as a means to "buy-off" a minority opinion. Omission of the optional item shall have no interoperability consequences for the implementation that does so.
因此，方案中应仅包含解决实际需求的选项。例如，选项可以支持协议、特定市场（例如金融业）或特定网络环境（例如受有限带宽约束的网络）的未来扩展性。不得将其作为“收买”少数意见的手段。省略可选项不会对这样做的实现产生互操作性后果。
One possible approach is to document protocol options in a separate specification. This keeps the main protocol specification clean and makes it clear that the options are not required to implement the protocol. Regardless of whether they appear within the specification or in a separate document, the text shall discuss the full implications of either using the option or not, and the case for choosing either course. As part of this, the author needs to consider and describe how the options are used alongside other protocols. The text must also specify the default conditions of all options. For security checking options the default condition is on or enabled.
一种可能的方法是在单独的规范中记录协议选项。这将保持主协议规范的整洁，并明确表示实现协议不需要这些选项。无论它们是否出现在规范中或单独的文件中，文本应讨论使用选项或不使用选项的全部含义，以及选择任一课程的情况。作为其中的一部分，作者需要考虑和描述如何与其他协议一起使用选项。文本还必须指定所有选项的默认条件。对于安全检查选项，默认条件为打开或启用。
There are occasions when mutually exclusive options appear within the protocol. That is, the implementation of an optional feature precludes the implementation of the other optional feature. For clarity, the author needs to state when to implement one or the other, what the effect of choosing one over the other is, and what
有时协议中会出现互斥选项。也就是说，可选特性的实现排除了其他可选特性的实现。为了清楚起见，作者需要说明何时实施其中一个，选择其中一个的效果是什么，以及什么
problems the implementer or user may face. The choice of one or the other options shall have no interoperability consequences between multiple implementations.
实现者或用户可能面临的问题。选择一个或其他选项不会在多个实现之间产生互操作性后果。
The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate Requirement Level", defines several words that are necessary for writing a standards track document. Editors of standards track documents must not deviate from the definitions provided as they are intended to identify interoperability requirements or limit potentially harmful behavior. The capitalization of these words is the accepted norm, and can help in identifying an unintentional or unreasonable requirement. These words have been used in several RFCs the first instances being STD 3/RFC 1122/RFC 1123.
BCP 14/RFC 2119“RFC中用于表示需求水平的关键词”定义了编写标准跟踪文件所需的几个词。标准跟踪文档的编辑不得偏离提供的定义，因为它们旨在确定互操作性要求或限制潜在的有害行为。这些词的大写是公认的标准，有助于确定无意或不合理的要求。这些词已在多个RFC中使用，第一个实例是STD 3/RFC 1122/RFC 1123。
Formal syntax notations can be used to define complicated protocol concepts or data types, and to specify values of these data types. This permits the protocol to be written without concern on how the implementation is constructed, or how the data type is represented during transfer. The specification is simplified because it can be presented as "axioms" that will be proven by implementation.
形式语法符号可用于定义复杂的协议概念或数据类型，并指定这些数据类型的值。这允许编写协议，而不必考虑如何构造实现，或在传输过程中如何表示数据类型。规范被简化了，因为它可以被表示为“公理”，并将通过实现得到验证。
The formal specification of the syntax used should be referenced in the text of the standard. Any extensions, subsets, alterations, or exceptions to that formal syntax should be defined within the standard.
标准文本中应参考所用语法的正式规范。该形式语法的任何扩展、子集、更改或例外都应在标准中定义。
The STD 11/RFC 822 provides an example of this. In RFC 822 (Section 2 and Appendix D) the Backus-Naur Form (BNF) meta-language was extended to make its representation smaller and easier to understand. Another example is STD 16/RFC 1155 (Section 3.2) where a subset of the Abstract Syntax Notation One (ASN.1) is defined.
STD 11/RFC 822提供了一个示例。在RFC 822（第2节和附录D）中，对巴科斯-诺尔形式（BNF）元语言进行了扩展，使其表示更小，更易于理解。另一个例子是STD 16/RFC 1155（第3.2节），其中定义了抽象语法符号1（ASN.1）的子集。
The author of a standards track protocol needs to consider several things before they use a formal syntax notation. Is the formal specification language being used parseable by an existing machine? If no parser exists, is there enough information provided in the specification to permit the building of a parser? If not, it is likely the reader will not have enough information to decide what the notation means. In addition, the author should remember machine parseable syntax is often unreadable by humans, and can make the specification excessive in length. Therefore, syntax notations cannot take the place of a clearly written protocol description.
标准跟踪协议的作者在使用正式语法符号之前需要考虑几件事。现有机器是否可以解析使用的正式规范语言？如果不存在解析器，规范中是否提供了足够的信息来构建解析器？如果没有，读者可能没有足够的信息来决定符号的含义。此外，作者应该记住，机器可解析语法通常是人类无法理解的，并且可能会使规范长度过长。因此，语法符号不能代替清晰的协议描述。
The common use of the Internet standard track protocols by the Internet community requires that unique values be assigned to parameter fields. An IETF WG does not have the authority to assign these values for the protocol it developed. The Internet Assigned Numbers Authority (IANA) is the central authority for the assignment of unique parameter values for Internet protocols. The authors of a developing protocol need to coordinate with the IANA the rules and procedures to manage the number space. This coordination needs to be completed prior to submitting the Internet Draft to the standards track.
互联网社区普遍使用互联网标准轨道协议，要求为参数字段指定唯一值。IETF工作组无权为其开发的协议分配这些值。互联网分配号码管理局（IANA）是为互联网协议分配唯一参数值的中心机构。开发协议的作者需要与IANA协调管理数字空间的规则和程序。这种协调需要在将互联网草案提交至标准轨道之前完成。
A document is in preparation that discusses issues related to identifier assignment policy and guidelines on specific text to task IANA with its administration. Standard authors should obtain a copy of it when it is finalized as an RFC.
正在编写一份文件，讨论与标识符分配政策有关的问题，以及向IANA及其管理部门提交特定文本的指南。标准作者应在最终确定为RFC时获得一份副本。
For further information on parameter assignment and current assignments, authors can reference STD 2, RFC 1700, "Assigned Numbers" (http://www.iana.org).
有关参数分配和当前分配的更多信息，作者可参考标准2，RFC 1700，“分配的编号”(http://www.iana.org).
When relevant, each standard needs to discuss how to manage the protocol being specified. This management process should be compatible with the current IETF Standard management protocol. In addition, a MIB must be defined within the standard or in a companion document. The MIB must be compatible with current Structure of Management Information (SMI) and parseable using a tool such as SMICng. Where management or a MIB is not necessary this section of the standard should explain the reason it is not relevant to the protocol.
相关时，每个标准都需要讨论如何管理指定的协议。该管理过程应与当前的IETF标准管理协议兼容。此外，MIB必须在标准或配套文件中定义。MIB必须与当前的管理信息结构（SMI）兼容，并且可以使用SMICng等工具进行解析。如果不需要管理或MIB，本节标准应解释其与协议无关的原因。
The standard should establish the limitations on the scale of use, e.g., tens of millions of sessions, gigabits per second, etc., and establish limits on the resources used, e.g., round trip time, computing resources, etc. This is important because it establishes the ability of the network to accommodate the number of users and the complexity of their relations. The STD 53/RFC 1939 has an example of such a section. If this is not applicable to the protocol, an explanation of why not should be included.
该标准应规定使用范围的限制，例如数千万次会话、每秒千兆位等，并规定所用资源的限制，例如往返时间、计算资源、，这一点很重要，因为它建立了网络适应用户数量及其关系复杂性的能力。STD 53/RFC 1939中有此类章节的示例。如果这不适用于协议，则应包括对为什么不适用的解释。
A standard should discuss the relationship between network topology and convergence behavior. As part of this, any topology that would be troublesome for the protocol should be identified. Additionally, the specification should address any possible destabilizing events, and means by which the protocol resists or recovers from them. The purpose is to insure that the network will stabilize, in a timely fashion, after a change, and that a combination of errors or events will not plunge the network into chaos. The STD 34/RFC 1058, as an example, has sections which discuss how that protocol handles the affects of changing topology.
标准应讨论网络拓扑与收敛行为之间的关系。作为这项工作的一部分，应该确定对协议造成麻烦的任何拓扑。此外，规范应解决任何可能的不稳定事件，以及协议抵抗或恢复这些事件的方法。其目的是确保网络在发生变化后及时稳定，并且错误或事件的组合不会使网络陷入混乱。以STD 34/RFC 1058为例，其章节讨论了该协议如何处理拓扑变化的影响。
The obvious case this would apply to is a routing protocol. However, an application protocol could also have dynamic behavior that would affect the network. For example, a messaging protocol could suddenly dump a large number of messages onto the network. Therefore, editors of an application protocol will have to consider possible impacts to network stability and convergence behavior.
这种情况明显适用于路由协议。但是，应用程序协议也可能具有影响网络的动态行为。例如，消息传递协议可能会突然将大量消息转储到网络上。因此，应用协议的编辑必须考虑到对网络稳定性和收敛行为的可能影响。
At one time the Internet had a geographic boundary and was English only. The Internet now extends internationally. Therefore, data is interchanged in a variety of languages and character sets. In order to meet the requirements of an international Internet, a standard must conform to the policies stated in BCP 18/RFC 2277, "IETF Policy on Character Sets and Languages".
曾经，互联网有一个地理边界，只使用英语。互联网现在扩展到了国际范围。因此，数据以各种语言和字符集进行交换。为了满足国际互联网的要求，标准必须符合BCP 18/RFC 2277“IETF字符集和语言政策”中规定的政策。
Every standards track RFC should have a glossary, as words can have many meanings. By defining any new words introduced, the author can avoid confusing or misleading the implementers. The definition should appear on the word's first appearance within the text of the protocol specification, and in a separate glossary section.
每个标准跟踪RFC都应该有一个术语表，因为单词可以有许多含义。通过定义引入的任何新词，作者可以避免混淆或误导实现者。定义应出现在协议规范文本中的单词第一次出现时，并在单独的术语表部分中。
It is likely that definition of the protocol will rely on many words frequently used in IETF documents. All authors must be knowledgeable of the common accepted definitions of these frequently used words. FYI 18/RFC 1983, "Internet Users' Glossary", provides definitions that are specific to the Internet. Any deviation from these definitions by authors is strongly discouraged. If circumstances require deviation, an author should state that he is altering the commonly accepted definition, and provide rationale as to the necessity of doing so. The altered definition must be included in the Glossary section.
协议的定义很可能依赖于IETF文档中经常使用的许多词。所有作者都必须了解这些常用词的公认定义。FYI 18/RFC 1983，“互联网用户词汇表”提供了特定于互联网的定义。强烈反对作者偏离这些定义。如果情况需要改变，提交人应说明他正在改变普遍接受的定义，并就这样做的必要性提供理由。修改后的定义必须包含在术语表部分。
If the author uses the word as commonly defined, she does not have to include the definition in the glossary. As a minimum, FYI 18/RFC 1983 should be referenced as a source.
如果作者使用通常定义的词，她不必在词汇表中包含该定义。至少应参考FYI 18/RFC 1983作为来源。
3 Specific Guidelines
3具体准则
The following are guidelines on how to present specific technical information in standards.
以下是关于如何在标准中呈现特定技术信息的指南。
Most link, network, and transport layer protocols have packet descriptions. Packet diagrams included in the standard are very helpful to the reader. The preferred form for packet diagrams is a sequence of long words in network byte order, with each word horizontal on the page and bit numbering at the top:
大多数链路、网络和传输层协议都有数据包描述。标准中包含的数据包图对读者非常有帮助。分组图的首选形式是按网络字节顺序排列的长单词序列，每个单词在页面上水平排列，位编号在顶部：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In cases where a packet is strongly byte-aligned rather than word-aligned (e.g., when byte-boundary variable-length fields are used), display packet diagrams in a byte-wide format. The author can use different height boxes for short and long words, and broken boxes for variable-length fields:
如果数据包是强字节对齐而不是字对齐（例如，当使用字节边界可变长度字段时），则以字节宽度格式显示数据包图。作者可以使用不同高度的框来表示短单词和长单词，使用断框来表示可变长度字段：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
The specifications of some protocols are particularly lengthy, sometimes covering a hundred pages or more. In such cases, the inclusion of a summary table can reduce the risk of conformance failure by an implementation through oversight. A summary table itemizes what in a protocol is mandatory, optional, or prohibited. Summary tables do not guarantee conformance, but serve to assist an implementer in checking that they have addressed all protocol features.
有些协议的规范特别冗长，有时长达100页或更多。在这种情况下，包含汇总表可以通过监督实施来降低合规失败的风险。汇总表列出协议中强制、可选或禁止的内容。摘要表不能保证一致性，但可以帮助实现者检查它们是否已经解决了所有协议特性。
The summary table will consist of, as a minimum, four (4) columns: Protocol Feature, Section Reference, Status, and References/Footnotes. The author may add columns if they further explain or clarify the protocol.
汇总表至少由四（4）列组成：协议特征、章节参考、状态和参考/脚注。如果进一步解释或澄清协议，作者可以添加专栏。
In the Protocol Feature column, list the protocol's characteristics, for example, a command word. We recommend grouping series of related transactions under descriptive headers, for example, RECEPTION.
在“协议功能”列中，列出协议的特征，例如命令字。我们建议将一系列相关交易分组在描述性标题下，例如，接收。
Section reference directs the implementer to the section, paragraph, or page that describes the protocol feature in detail.
章节参考将引导实施者进入详细描述协议功能的章节、段落或页面。
Status indicates whether the feature is mandatory, optional, or prohibited. The author can use either a separate column for each possibility, or a single column with appropriate codes. These codes need to be defined at the start of the summary table to avoid confusion. Possible status codes:
状态指示功能是强制、可选还是禁止。作者可以为每个可能性使用单独的列，也可以使用带有适当代码的单列。这些代码需要在汇总表的开头定义，以避免混淆。可能的状态代码：
M - must or mandatory MN - must not O - optional S - should SN - should not X - prohibited
M-必须或强制性MN-不得O-可选S-应SN-不应X-禁止
In the References/Footnotes column authors can point to other RFCs that are necessary to consider in implementing this protocol feature, or any footnotes necessary to explain the implementation further.
在参考文献/脚注栏中，作者可以指向在实现该协议特征时需要考虑的其他RFC，或者指向进一步解释实现的任何脚注。
The STD 3/RFC 1122/RFC 1123 provides examples of summary tables.
STD 3/RFC 1122/RFC 1123提供了汇总表的示例。
A convenient method of presenting a protocol's behavior is as a state-machine model. That is, a protocol can be described by a series of states resulting from a command, operation, or transaction. State-machine models define the variables and constants that
表示协议行为的一种方便方法是作为状态机模型。也就是说，协议可以由命令、操作或事务产生的一系列状态来描述。状态机模型定义了
establish a state, the events that cause state transitions and the actions that result from those transitions. Through these models, an understanding of the protocol's dynamic operation as sequence of state transitions that occur for any given event is possible. State transitions can be detailed by diagrams, tables, or time lines.
建立状态、导致状态转换的事件以及由这些转换导致的操作。通过这些模型，可以将协议的动态操作理解为任何给定事件发生的状态转换序列。状态转换可以通过图表、表格或时间线进行详细说明。
Note that state-machine models are never to take the place of detailed text description of the specification. They are adjuncts to the text. The protocol specification shall always take precedence in the case of a conflict.
请注意，状态机模型永远不能代替规范的详细文本描述。它们是正文的附属品。在发生冲突的情况下，应始终以协议规范为准。
When using a state transition diagram, show each possible protocol state as a box connected by state transition arcs. The author should label each arc with the event that causes the transition, and, in parentheses, any actions taken during the transition. The STD 5/RFC 1112 provides an example of such a diagram. As ASCII text is the preferred storage format for RFCs, only simple diagrams are possible. Tables can summarize more complex or extensive state transitions.
使用状态转换图时，将每个可能的协议状态显示为一个由状态转换弧连接的框。作者应在每个弧上标记导致转换的事件，并在括号中标记转换期间采取的任何操作。STD 5/RFC 1112提供了此类图表的示例。由于ASCII文本是RFC的首选存储格式，因此只能使用简单的图表。表可以总结更复杂或更广泛的状态转换。
In a state transition table, the different events are listed vertically and the different states are listed horizontally. The form, action/new state, represents state transitions and actions. Commas separate multiple actions, and succeeding lines are used as required. The authors should present multiple actions in the order they must be executed, if relevant. Letters that follow the state indicate an explanatory footnote. The dash ('-') indicates an illegal transition. The STD 51/RFC 1661 provides an example of such a state transition table. The initial columns and rows of that table follow as an example:
在状态转换表中，垂直列出不同的事件，水平列出不同的状态。表单action/newstate表示状态转换和操作。逗号分隔多个操作，并根据需要使用后续行。如果相关，作者应按照必须执行的顺序呈现多个操作。状态后面的字母表示解释性脚注。破折号（'-'）表示非法转换。STD 51/RFC 1661提供了这种状态转换表的示例。该表的初始列和行如下所示：
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
The STD 18/RFC 904 also presents state transitions in table format. However, it lists transitions in the form n/a, where n is the next state and a represents the action. The method in RFC 1661 is preferred as new state logically follows action. In addition, RFC 904's Appendix C models transitions as the Cartesian product of two state machines. This is a more complex representation that may be
STD 18/RFC 904还以表格形式呈现状态转换。但是，它以n/a的形式列出了转换，其中n是下一个状态，a表示动作。RFC1661中的方法是首选的，因为新状态逻辑上遵循动作。此外，RFC 904的附录C将转换建模为两个状态机的笛卡尔乘积。这是一个更复杂的表示，可能是
difficult to comprehend for those readers that are unfamiliar with the format. We recommend that authors present tables as defined in the previous paragraph.
对于那些不熟悉格式的读者来说很难理解。我们建议作者提供上一段中定义的表格。
A final method of representing state changes is by a time line. The two sides of the time line represent the machines involved in the exchange. The author lists the states the machines enter as time progresses (downward) along the outside of time line. Within the time line, show the actions that cause the state transitions. An example:
表示状态变化的最后一种方法是使用时间线。时间线的两侧代表交换中涉及的机器。作者列出了机器随着时间的推移（向下）在时间线之外进入的状态。在时间线内，显示导致状态转换的操作。例如：
client server
客户端服务器
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
4 Document Checklist
4文件清单
The following is a checklist based on the above guidelines that can be applied to a document:
以下是基于上述指南的清单，可应用于文件：
o Does it identify the security risks? Are countermeasures for each potential attack provided? Are the effects of the security measures on the operating environment detailed? o Does it explain the purpose of the protocol or procedure? Are the intended functions and services addressed? Does it describe how it relates to existing protocols? o Does it consider scaling and stability issues? o Have procedures for assigning numbers been coordinated with IANA? o Does it discuss how to manage the protocol being specified? Is a MIB defined? o Is a target audience defined? o Does it reference or explain the algorithms used in the protocol? o Does it give packet diagrams in recommended form, if applicable? o Is there a change log? o Does it describe differences from previous versions, if applicable? o Does it separate explanatory portions of the document from requirements? o Does it give examples of protocol operation?
o 它是否识别了安全风险？是否为每个潜在攻击提供了应对措施？是否详细说明了安全措施对操作环境的影响？o它是否解释了协议或程序的目的？是否说明了预期的功能和服务？它是否描述了它与现有协议的关系？O是否考虑缩放和稳定性问题？o分配编号的程序是否与IANA协调？o是否讨论了如何管理指定的协议？是否定义了MIB？o是否定义了目标受众？o是否参考或解释协议中使用的算法？o是否以推荐的形式给出数据包图（如适用）？o是否有更改日志？o是否描述了与以前版本的差异（如适用）？o是否将文件的解释部分与要求分开？o是否给出了协议操作的示例？
o Does it specify behavior in the face of incorrect operation by other implementations? o Does it delineate which packets should be accepted for processing and which should be ignored? o If multiple descriptions of a requirement are given, does it identify one as binding? o How many optional features does it specify? Does it separate them into option classes? o Have all combinations of options or option classes been examined for incompatibility? o Does it explain the rationale and use of options? o Have all mandatory and optional requirements be identified and documented by the accepted key words that define Internet requirement levels? o Does it conform to the current internationalization policies of the IETF? o Are the recommended meanings for common Internet terms used? o If not, are new or altered definitions for terms given in a glossary?
o 它是否指定了面对其他实现的错误操作时的行为？o它是否描述了哪些数据包应该被接受处理，哪些应该被忽略？o如果给出了一个需求的多个描述，它是否将其中一个定义为绑定？o它指定了多少可选功能？它是否将它们划分为选项类？o是否已检查所有选项组合或选项类别的不兼容性？o它是否解释了选项的原理和使用？o是否所有强制性和可选要求都已通过定义互联网要求级别的公认关键词进行识别和记录？o是否符合IETF当前的国际化政策？o是否使用了通用互联网术语的推荐含义？o如果没有，术语表中是否给出了新的或修改过的术语定义？
5 Security Considerations
5安全考虑
This document does not define a protocol or procedure that could be subject to an attack. It establishes guidelines for the information that should be included in RFCs that are to be submitted to the standards track. In the area of security, IETF standards authors are called on to define clearly the threats faced by the protocol and the way the protocol does or does not provide security assurances to the user.
本文档未定义可能受到攻击的协议或过程。它为提交至标准跟踪的RFC中应包含的信息制定了指南。在安全领域，IETF标准的作者被要求明确定义协议面临的威胁以及协议是否向用户提供安全保证的方式。
6 References
6参考文献
[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791 September 1981.
[RFC 791]Postel，J.，“互联网协议（IP）”，STD 5，RFC 791 1981年9月。
[RFC 904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC 904]Mills，D.，“外部网关协议正式规范”，RFC 904，1984年4月。
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, June 1988.
[RFC 1058]Hedrick，C.，“路由信息协议”，STD 34，RFC 1058，1988年6月。
[RFC 1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC 1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[RFC 1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1122]Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[RFC 1123] Braden, R., "Requirements for Internet hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1123]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992.
[RFC 1311]Postel，J.，“标准说明简介”，RFC 13111992年3月。
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC 1350]Sollins，K.，“TFTP协议（修订版2）”，STD 33，RFC 1350，1992年7月。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1661]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661，1994年7月。
[RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662, July 1994.
[RFC 1662]辛普森，W，“HLDC类框架中的PPP”，STD 51，RFC 1662，1994年7月。
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. (http://www.iana.org)
[RFC 1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。(http://www.iana.org)
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC 1939]Meyers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958]Carpenter，B.，“互联网的建筑原理”，RFC 19581996年6月。
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[RFC 1983]Malkin，G.“互联网用户词汇表”，仅供参考，RFC 1983，1996年8月。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
[RFC 2026]Bradner，S.，“互联网标准过程——第3版”，RFC 2026，1996年10月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC 2328]莫伊，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC 2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and Language", RFC 2277, January 1998.
[RFC 2277]Alvestrand，H.，“IETF字符集和语言政策”，RFC 2277，1998年1月。
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC 2316]Bellovin，S.，“IAB安全架构研讨会报告”，RFC 2316，1998年4月。
7 Acknowledgments
7致谢
Peter Desnoyers and Art Mellor began the work on this document. Others that contributed were:
彼得·德斯诺耶斯（Peter Desnoyers）和阿尔特·梅勒（Art Mellor）开始了这份文件的编写工作。其他作出贡献的有：
Bernard Aboba Harald T. Alvestrand Fred Baker Scott Bradner Brian Carpenter Robert Elz Dirk Fieldhouse Dale Francisco Gary Malkin Neal McBurnett Thomas Narten Craig Partridge Vern Paxson Mike O'Dell Henning Schulzrinne Kurt Starsinic James Watt
Bernard Aboba Harald T.Alvestrand Fred Baker Scott Bradner Brian Carpenter Robert Elz Dirk Fieldhouse Dale Francisco Gary Malkin Neal McBurnett Thomas Narten Craig Partridge Vern Paxson Mike O'Dell Henning Schulzrinne Kurt Starsinic James Watt
8 Editor's Address
8编辑地址
Gregor D. Scott Director, Defense Information Systems Agency ATTN: JIEO-JEBBC Ft. Monmouth, NJ 07703-5613 USA
Gregor D.Scott国防信息系统局局长收件人：美国新泽西州蒙茅斯堡JIEO-JEBBC 07703-5613
Phone: (732) 427-6856 Fax: (732) 532-0853 EMail: scottg@ftm.disa.mil
电话：（732）427-6856传真：（732）532-0853电子邮件：scottg@ftm.disa.mil
9 Appendix
附录9
CHANGES FROM DRAFT -06
草案-06的更改
The following changes were made following IESG review:
在IESG审查后进行了以下更改：
References to RFC 1543 were changed to RFC 2223 that obsoleted it.
对RFC 1543的引用已更改为RFC 2223，该版本已废弃。
In section 2.1, "export control" was dropped as a valid reason for not selecting a security mechanism. In addition, ambiguous or conflicting sentences were removed.
在第2.1节中，“出口管制”作为不选择安全机制的有效理由被删除。此外，删除了模棱两可或相互冲突的句子。
In section 2.1 reference made to RFC 2315 as an additional source of information.
在第2.1节中，参考RFC 2315作为附加信息来源。
Section 2.5 was changed to highlight the Change Log's purpose as assistance to implementers.
对第2.5节进行了更改，以强调更改日志作为帮助实施者的目的。
The IANA Considerations section (2.13) was rewritten to highlight that the IANA guidelines document is work in progress but should be used when it becomes available.
重新编写了IANA注意事项部分（2.13），以强调IANA指南文件正在进行中，但应在可用时使用。
Section 3.4 Character Sets was deleted and replaced by section 2.17 Internationalization.
删除第3.4节字符集，代之以第2.17节国际化。
Spelling and grammar corrections were made.
对拼写和语法进行了更正。
CHANGES FROM DRAFT -05
草案-05的更改
A sentence pointing to a pending document that further addresses IANA considerations was added to section 2.13. The current draft of that document is draft-iesg-iana-considerations-02.txt. A clause stating that the IANA established the assignment policies was removed since it appeared to conflict with the intent of the referenced ID. Placeholders for the BCP and RFC number have been added to the text and reference section.
第2.13节中增加了一句话，指出了进一步解决IANA考虑事项的未决文件。该文件的当前草稿是draft-iesg-iana-CONTESSIONS-02.txt。声明IANA制定分配政策的条款已被删除，因为该条款似乎与参考ID的意图相冲突。已将BCP和RFC编号的占位符添加到文本和参考部分。
A new section (2.5) requiring change logs as documents progress along the standards track was added.
增加了一个新的章节（2.5），该章节要求在文件沿着标准轨道进展时记录变更日志。
References to RFC 2044 were changed to RFC 2279 that obsoleted it.
对RFC 2044的引用被更改为RFC 2279，从而使其作废。
Spelling and grammar corrections were made.
对拼写和语法进行了更正。
CHANGES FROM DRAFT -04
草案-04的更改
A paragraph pointing to a pending document that further addresses security was updated.
更新了一个段落，该段落指向一个进一步解决安全问题的未决文件。
10 Full Copyright Statement
10完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。