Network Working Group T. Narten
Request for Comments: 2434 IBM
BCP: 26 H. Alvestrand
Category: Best Current Practice Maxware
October 1998
Network Working Group T. Narten
Request for Comments: 2434 IBM
BCP: 26 H. Alvestrand
Category: Best Current Practice Maxware
October 1998
Guidelines for Writing an IANA Considerations Section in RFCs
在RFCs中编写IANA注意事项部分的指南
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
摘要
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
许多协议使用由常量和其他已知值组成的标识符。即使在定义了协议并开始部署之后，也可能需要分配新的值（例如，对于DHCP中的新选项类型，或者对于IPSec的新加密或身份验证算法）。为了确保这些数量在不同的实现中具有一致的值和解释，它们的分配必须由中央当局管理。对于IETF协议，该角色由互联网分配号码管理局（IANA）提供。
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.
为了让IANA谨慎地管理给定的名称空间，它需要一些准则来描述可以分配新值的条件。如果预计IANA将在名称空间的管理中发挥作用，则必须向IANA提供描述该作用的清晰简洁的说明。本文件讨论了在制定为名称空间赋值的政策时应考虑的问题，并为文件作者提供了关于特定文本的指南，这些文本必须包含在对IANA提出要求的文件中。
Table of Contents
目录
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Issues To Consider....................................... 3
3. Registration maintenance................................. 6
4. What To Put In Documents................................. 7
5. Applicability to Past and Future RFCs.................... 8
6. Security Considerations.................................. 8
7. Acknowledgments.......................................... 9
8. References............................................... 9
9. Authors' Addresses....................................... 10
10. Full Copyright Statement................................. 11
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Issues To Consider....................................... 3
3. Registration maintenance................................. 6
4. What To Put In Documents................................. 7
5. Applicability to Past and Future RFCs.................... 8
6. Security Considerations.................................. 8
7. Acknowledgments.......................................... 9
8. References............................................... 9
9. Authors' Addresses....................................... 10
10. Full Copyright Statement................................. 11
Many protocols make use of fields that contain constants and other well-known values (e.g., the Protocol field in the IP header [IP] or MIME types in mail messages [MIME-REG]). Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., a new option type in DHCP [DHCP] or a new encryption or authentication algorithm for IPSec [IPSEC]). To insure that such fields have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
许多协议使用包含常量和其他已知值的字段（例如，IP头[IP]中的协议字段或邮件消息[MIME-REG]中的MIME类型）。即使在定义了协议并开始部署之后，也可能需要分配新的值（例如，DHCP[DHCP]中的新选项类型或IPSec[IPSec]的新加密或身份验证算法）。为了确保这些字段在不同的实现中具有一致的值和解释，它们的分配必须由中央机构管理。对于IETF协议，该角色由互联网分配号码管理局（IANA）提供。
In this document, we call the set of possible values for such a field a "name space"; its actual content may be a name, a number or another kind of value. The assignment of a specific value to a name space is called an assigned number (or assigned value). Each assignment of a number in a name space is called a registration.
在本文档中，我们将此类字段的一组可能值称为“名称空间”；其实际内容可能是名称、数字或其他类型的值。将特定值分配给名称空间称为已分配的编号（或已分配的值）。名称空间中数字的每次分配称为注册。
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values should be assigned. This document provides guidelines to authors on what sort of text should be added to their documents, and reviews issues that should be considered in formulating an appropriate policy for assigning numbers to name spaces.
为了让IANA谨慎地管理给定的名称空间，它需要一些准则来描述应在哪些条件下分配新值。本文档为作者提供了关于应向其文档中添加何种文本的指南，并回顾了在制定为名称空间分配数字的适当策略时应考虑的问题。
Not all name spaces require centralized administration. In some cases, it is possible to delegate a name space in such a way that further assignments can be made independently and with no further (central) coordination. In the Domain Name System, for example, the IANA only deals with assignments at the higher-levels, while subdomains are administered by the organization to which the space has been delegated. As another example, Object Identifiers (OIDs) as defined by the ITU are also delegated [ASSIGNED]. When a name space
并非所有名称空间都需要集中管理。在某些情况下，可以以这样的方式委派名称空间，即可以独立地进行进一步的分配，而无需进一步（中心）协调。例如，在域名系统中，IANA只处理更高级别的分配，而子域则由空间被授予的组织管理。作为另一个示例，ITU定义的对象标识符（OID）也被委派[分配]。当一个名字空间
can be delegated, the IANA only deals with assignments at the top level.
IANA只能处理最高级别的任务。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, "the specification" as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process.
本文件使用术语“必须”、“应该”和“可能”及其否定词，如RFC 2119[关键词]中所述。在这种情况下，RFC 2119使用的“规范”指的是提交给IETF标准过程的协议处理。
The primary issue to consider in managing a name space is its size. If the space is small and limited in size, assignments must be made carefully to insure that the space doesn't become exhausted. If the space is essentially unlimited, on the other hand, it may be perfectly reasonable to hand out new values to anyone that wants one. Even when the space is essentially unlimited, however, it is usually desirable to have a minimal review to prevent the hoarding of or unnecessary wasting of a space. For example, if the space consists of text strings, it may be desirable to prevent organizations from obtaining large sets of strings that correspond to the "best" names (e.g., existing company names).
在管理名称空间时要考虑的主要问题是它的大小。如果空间较小且尺寸有限，则必须仔细分配，以确保空间不会耗尽。另一方面，如果空间基本上是无限的，那么向任何想要新价值观的人分发新价值观可能是完全合理的。然而，即使空间基本上是无限的，通常也需要进行最低限度的审查，以防止空间被囤积或不必要的浪费。例如，如果空格由文本字符串组成，则可能需要防止组织获取与“最佳”名称（例如，现有公司名称）相对应的大型字符串集。
A second consideration is whether it makes sense to delegate the name space in some manner. This route should be pursued when appropriate, as it lessens the burden on the IANA for dealing with assignments.
第二个考虑因素是以某种方式委托名称空间是否有意义。在适当的情况下，应采用这条路线，因为它减轻了IANA处理任务的负担。
In some cases, the name space is essentially unlimited, and assigned numbers can safely be given out to anyone. When no subjective review is needed, the IANA can make assignments directly, provided that the IANA is given specific instructions on what types of requests it should grant, and what information must be provided before a request for an assigned number will be considered. Note that the IANA will not define an assignment policy; it should be given a set of guidelines that allow it to make allocation decisions with little subjectivity.
在某些情况下，名称空间基本上是无限的，分配的号码可以安全地发给任何人。当不需要主观审查时，IANA可以直接进行分配，前提是IANA得到了关于其应批准的请求类型的具体指示，以及在考虑分配号码请求之前必须提供的信息。请注意，IANA不会定义派遣政策；应该给它一套指导方针，允许它在几乎没有主观性的情况下做出分配决定。
In most cases, some review of prospective allocations is appropriate, and the question becomes who should perform the review and how rigorous the review needs to be. In many cases, one might think that an IETF Working Group (WG) familiar with the name space at hand should be consulted. In practice, however, WGs eventually disband, so they cannot be considered a permanent evaluator. It is also possible for name spaces to be created through individual submission documents, for which no WG is ever formed.
在大多数情况下，对预期分配进行一些审查是适当的，问题是谁应该进行审查以及审查需要有多严格。在许多情况下，人们可能会认为应该咨询熟悉手头名称空间的IETF工作组（WG）。然而，在实践中，工作组最终解散，因此不能将其视为永久评估人。也可以通过单独的提交文档创建名称空间，但从未为其创建工作组。
One way to insure community review of prospective assignments is to have the requester submit a document for publication as an RFC. Such an action insures that the IESG and relevant WGs review the
确保社区对预期任务进行审查的一种方法是让请求者提交一份文件，作为RFC发布。此类行动确保IESG和相关工作组审查
assignment. This is the preferred way of insuring review, and is particularly important if any potential interoperability issues can arise. For example, many assignments are not just assignments, but also involve an element of protocol specification. A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built.
分配这是确保审查的首选方式，如果可能出现任何潜在的互操作性问题，这一点尤为重要。例如，许多分配不仅仅是分配，还涉及协议规范的一个元素。新选项可能会定义需要解析和处理的字段，这些字段（如果指定得不好）可能不完全适合其他选项的体系结构或构建它们的基本协议。
In some cases, however, the burden of publishing an RFC in order to get an assignment is excessive. However, it is generally still useful (and sometimes necessary) to discuss proposed additions on a mailing list dedicated to the purpose (e.g., the ietf-types@iana.org for media types) or on a more general mailing list (e.g., that of a current or former IETF WG). Such a mailing list provides a way for new registrations to be publicly reviewed prior to getting assigned, or to give advice for persons who want help in understanding what a proper registration should contain.
然而，在某些情况下，为了获得分配而发布RFC的负担过重。然而，在专门用于此目的的邮件列表（如ietf）上讨论提议的新增内容通常仍然有用（有时是必要的）-types@iana.org对于媒体类型）或更通用的邮件列表（例如，当前或以前的IETF工作组的邮件列表）。这样的邮件列表提供了一种方式，让新注册在被分配之前进行公开审查，或者为那些想要帮助理解正确注册应该包含哪些内容的人提供建议。
While discussion on a mailing list can provide valuable technical expertise, opinions may vary and discussions may continue for some time without resolution. In addition, the IANA cannot participate in all of these mailing lists and cannot determine if or when such discussions reach consensus. Therefore, the IANA cannot allow general mailing lists to fill the role of providing definitive recommendations regarding a registration question. Instead, the IANA will use a designated subject matter expert. The IANA will rely on a "designated expert" to advise it in assignment matters. That is, the IANA forwards the requests it receives to a specific point-of-contact (one or a small number of individuals) and acts upon the returned recommendation from the designated expert. The designated expert can initiate and coordinate as wide a review of an assignment request as may be necessary to evaluate it properly.
虽然邮件列表上的讨论可以提供宝贵的技术专业知识，但意见可能会有所不同，讨论可能会持续一段时间而没有结果。此外，IANA无法参与所有这些邮件列表，也无法确定这些讨论是否或何时达成共识。因此，IANA不能允许普通邮件列表填补就注册问题提供明确建议的角色。相反，IANA将使用指定的主题专家。IANA将依靠“指定专家”就任务事宜向其提供建议。也就是说，IANA将收到的请求转发给特定的联络点（一个或少数个人），并根据指定专家返回的建议采取行动。指定专家可以启动和协调对任务请求的广泛审查，以便对其进行适当评估。
Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary.
指定专家由IESG相关区域主任任命。它们通常在创建新编号空间的文件作为RFC发布时命名，但由于最初任命的专家可能随后无法获得，相关区域主管将在必要时任命替代者。
Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF-PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG.
指定专家做出的任何决定都可以使用[IETF-process]第6.5节所述的正常IETF上诉程序进行上诉。由于指定的专家是由IESG任命的，IESG可能会罢免他们。
The following are example policies, some of which are in use today:
以下是一些目前正在使用的示例策略：
Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability.
私人使用-仅供私人或本地使用，类型和用途由本地站点定义。未尝试阻止多个站点以不同（且不兼容）的方式使用相同的值。IANA无需审查此类分配，而且这些分配通常对互操作性没有帮助。
Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. "X-foo:" header lines in email messages.
示例：DHCP[DHCP]中特定于站点的选项仅在单个站点中有效。“X-foo:”电子邮件中的标题行。
Hierarchical allocation - Delegated managers can assign values provided they have been given control over that part of the name space. IANA controls the higher levels of the namespace according to one of the other policies.
分层分配-委托经理可以分配值，前提是他们已获得对名称空间该部分的控制权。IANA根据其他策略之一控制命名空间的更高级别。
Examples: DNS names, Object Identifiers
示例：DNS名称、对象标识符
First Come First Served - Anyone can obtain an assigned number, so long as they provide a point of contact and a brief description of what the value would be used for. For numbers, the exact value is generally assigned by the IANA; with names, specific names are usually requested.
先到先得-任何人都可以获得一个指定的号码，只要他们提供一个联系点，并简要说明该值的用途。对于数字，准确值通常由IANA指定；对于名称，通常需要特定的名称。
Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP and UDP port numbers.
例如：vnd。（供应商指定）MIME类型[MIME-REG]、TCP和UDP端口号。
Expert Review - approval by a Designated Expert is required.
专家审查-需要指定专家的批准。
Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
所需规范-值及其含义必须记录在RFC或其他永久性且随时可用的参考文件中，足够详细，以便独立实现之间的互操作性成为可能。
Examples: SCSP [SCSP]
示例：SCSP[SCSP]
IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis).
IESG批准-新任务必须经IESG批准，但不要求将请求记录在RFC中（尽管IESG有权根据具体情况申请文件或其他支持材料）。
IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
IETF共识-通过IETF共识流程分配新值。具体而言，新任务通过IESG批准的RFC完成。通常情况下，IESG将寻求适当人员（例如，相关工作组，如果存在）对预期任务的投入。
Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address Family Identifiers [BGP4-EXT].
示例：SMTP扩展[SMTP-EXT]，BGP后续地址系列标识符[BGP4-EXT]。
Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG.
标准行动-仅为IESG批准的标准跟踪RFC分配值。
Examples: MIME top level types [MIME-REG]
示例：MIME顶级类型[MIME-REG]
It should be noted that it often makes sense to partition a name space into several categories, with assignments out of each category handled differently. For example, the DHCP option space [DHCP] is split into two parts. Option numbers in the range of 1-127 are globally unique and assigned according to the Specification Required policy described above, while options number 128-254 are "site specific", i.e., Local Use. Dividing the name space up makes it possible to allow some assignments to be made with minimal review, while simultaneously reserving some part of the space for future use.
应该注意的是，将名称空间划分为几个类别通常是有意义的，每个类别的分配处理方式不同。例如，DHCP选项空间[DHCP]分为两部分。1-127范围内的选项编号是全局唯一的，并根据上述规范要求的政策进行分配，而选项编号128-254是“特定于现场的”，即本地使用。将名称空间分割开来，可以在进行一些分配时只需最少的审阅，同时保留部分空间供将来使用。
Registrations are a request for an assigned number, including the related information needed to evaluate and document the request. Even after a number has been assigned, some types of registrations contain additional information that may need to be updated over time. For example, mime types, character sets, language tags, etc. typically include more information than just the registered value itself. Example information can include point of contact information, security issues, pointers to updates, literature references, etc. In such cases, the document must clearly state who is responsible for maintaining and updating a registration. It is appropriate to:
注册是对指定号码的请求，包括评估和记录请求所需的相关信息。即使在分配了号码之后，某些类型的注册也包含可能需要随时间更新的附加信息。例如，mime类型、字符集、语言标记等通常包含比注册值本身更多的信息。示例信息可以包括联系人信息、安全问题、更新指针、文献参考等。在这种情况下，文档必须明确说明谁负责维护和更新注册。适当的做法是：
- Let the author update the registration, subject to the same constraints and review as with new registrations.
- 让作者更新注册，受与新注册相同的约束和审查。
- Allow some mechanism to attach comments to the registration, for cases where others have significant objections to claims in a registration, but the author does not agree to change the registration.
- 如果其他人对登记中的主张有重大异议，但提交人不同意更改登记，则允许某些机制对登记附加评论。
- Designate the IESG or another authority as having the right to reassign ownership of a registration. This is mainly to get around the problem when some registration owner cannot be reached in order to make necessary updates.
- 指定IESG或其他机构有权重新分配注册所有权。这主要是为了解决无法联系到某些注册所有者以进行必要更新时的问题。
The previous sections presented some issues that should be considered in formulating a policy for assigning well-known numbers and other protocol constants. It is the Working Group and/or document author's job to formulate an appropriate policy and specify it in the appropriate document. In some cases, having an "IANA Considerations" section may be appropriate. Specifically, documents that create an name space (or modify the definition of an existing space) and that expect the IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST document the process through which future assignments are made. Such a section MUST state clearly:
前几节介绍了在制定分配已知数字和其他协议常数的政策时应考虑的一些问题。工作组和/或文件作者的工作是制定适当的政策，并在适当的文件中加以规定。在某些情况下，设置“IANA注意事项”部分可能是合适的。具体而言，创建名称空间（或修改现有空间的定义）以及希望IANA在维护该空间中发挥作用（例如，作为注册值的存储库）的文档必须记录未来分配的过程。该节必须明确说明：
- whether or not an application for an assigned number needs to be reviewed. If review is necessary, the review mechanism MUST be specified. When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself; instead, the name should be relayed to the appropriate IESG Area Director at the time the document is sent to the IESG for approval.
- 是否需要审查分配号码的申请。如果需要审查，则必须指定审查机制。使用指定专家时，文件不得在文件中指定指定专家；相反，在将文件发送给IESG审批时，应将该名称转发给相应的IESG区域主管。
- If the request should also be reviewed on a specific public mailing list (such as the ietf-types@iana.org for media types), that mailing address should be specified. Note, however, that use of a Designated Expert MUST also be specified.
- 是否还应在特定的公共邮件列表（如ietf）上审查请求-types@iana.org对于媒体类型），应指定该邮寄地址。但是，请注意，还必须指定指定专家。
- if the IANA is expected to make assignments without requiring an outside review, sufficient guidance MUST be provided so that the requests can be evaluated with minimal subjectivity.
- 如果IANA希望在不需要外部审查的情况下完成任务，则必须提供足够的指导，以便能够以最小的主观性评估请求。
Authors SHOULD attempt to provide guidelines that allow the IANA to assign new values directly without requiring review by a Designated Expert. This can be done easily in many cases by designating a range of values for direct assignment by the IANA while simultaneously reserving a sufficient portion of the name space for future use by requiring that assignments from that space be made only after a more stringent review.
作者应尝试提供指南，允许IANA直接分配新值，而无需指定专家审查。在许多情况下，通过指定IANA直接分配的一系列值，同时保留足够部分的名称空间供将来使用，可以很容易地做到这一点，方法是要求仅在更严格的审查之后才从该空间进行分配。
Finally, it is quite acceptable to pick one of the example policies cited above and refer to it by name. For example, a document could say something like:
最后，选择上面引用的示例策略之一并按名称引用是完全可以接受的。例如，文档可能会说：
Following the policies outlined in [IANA-CONSIDERATIONS], numbers in the range 0-63 are allocated as First Come First Served, numbers between 64-240 are allocated through an IETF Consensus action and values in the range 241-255 are reserved for Private Use.
按照[IANA-注意事项]中概述的政策，0-63范围内的数字按先到先得的方式分配，64-240之间的数字通过IETF一致行动分配，241-255范围内的值保留供私人使用。
For examples of documents that provide good and detailed guidance to the IANA on the issue of assigning numbers, consult [MIME-REG, MIME-LANG].
有关向IANA提供关于分配号码问题的良好详细指导的文件示例，请参考[MIME-REG，MIME-LANG]。
For all existing RFCs that either explicitly or implicitly rely on the IANA to evaluate assignments without specifying a precise evaluation policy, the IANA will continue to decide what policy is appropriate. The default policy has been first come, first served. Changes to existing policies can always be initiated through the normal IETF consensus process.
对于所有显式或隐式依赖IANA评估任务而不指定精确评估策略的现有RFC，IANA将继续决定什么策略是合适的。默认策略为先到先得。对现有政策的更改始终可以通过正常的IETF协商一致过程启动。
All future RFCs that either explicitly or implicitly rely on the IANA to register or otherwise manage assignments MUST provide guidelines for managing the name space.
所有明示或暗示依赖IANA注册或以其他方式管理分配的未来RFC必须提供管理名称空间的指南。
Information that creates or updates a registration needs to be authenticated.
创建或更新注册的信息需要经过身份验证。
Information concerning possible security vulnerabilities of a protocol may change over time. Likewise, security vulnerabilities related to how an assigned number is used (e.g., if it identifies a protocol) may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing registrations, so that users are not mislead as to the true security issues surrounding the use of a registered number.
有关协议可能存在的安全漏洞的信息可能会随时间而变化。同样，与分配号码的使用方式相关的安全漏洞（例如，如果它标识了协议）也可能会发生变化。当发现新的漏洞时，可能需要将有关此类漏洞的信息附加到现有的注册中，这样用户就不会对使用注册号码的真正安全问题产生误导。
An analysis of security issues is required for all parameters (data types, operation codes, keywords, etc.) used in IETF protocols or registered by the IANA. All descriptions of security issues must be as accurate as possible regardless of level of registration. In particular, a statement that there are "no security issues associated with this type" must not given when it would be more accurate to state that "the security issues associated with this type have not been assessed".
需要对IETF协议中使用或IANA注册的所有参数（数据类型、操作代码、关键字等）进行安全问题分析。无论注册级别如何，安全问题的所有描述都必须尽可能准确。特别是，当更准确地说“与此类型相关的安全问题尚未评估”时，不得给出“不存在与此类型相关的安全问题”的声明。
Jon Postel and Joyce K. Reynolds provided a detailed explanation on what the IANA needs in order to manage assignments efficiently, and patiently provided comments on multiple versions of this document. Brian Carpenter provided helpful comments on earlier versions of the document. One paragraph in the Security Considerations section was borrowed from [MIME-REG].
Jon Postel和Joyce K.Reynolds详细解释了IANA需要什么才能有效地管理任务，并耐心地对本文档的多个版本发表了评论。Brian Carpenter对文档的早期版本提供了有用的评论。安全注意事项部分的一段是从[MIME-REG]借用的。
[ASSIGNED] Reynolds, J., and J. Postel, "Assigned
Numbers", STD 2, RFC 1700, October 1994. See
also: http://www.iana.org/numbers.html
[ASSIGNED] Reynolds, J., and J. Postel, "Assigned
Numbers", STD 2, RFC 1700, October 1994. See
also: http://www.iana.org/numbers.html
[BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
[BGP4-EXT]贝茨。T.，Chandra，R.，Katz，D.和Y.Rekhter，“BGP-4的多协议扩展”，RFC 2283，1998年2月。
[DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[DHCP-OPTIONS]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA注意事项]Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[IETF-PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[IETF-PROCESS]Bradner，S.，“互联网标准流程——第3版”，BCP 9，RFC 2026，1996年10月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[IPSEC]Atkinson，R.，“互联网协议的安全架构”，RFC 18251995年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[MIME-LANG]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC2184，1997年8月。
[MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[MIME-REG]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，RFC 20481996年11月。
[SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[SCSP]Luciani，J.，Armitage，G.和J.Halpern，“服务器缓存同步协议（SCSP）”，RFC 2334，1998年4月。
[SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[SMTP-EXT]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“SMTP服务扩展”，RFC 18691995年11月。
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195
Thomas Narten IBM Corporation 3039 Cornwallis Ave.邮政信箱12195-北卡罗来纳州三角研究公园BRQA/502 27709-2195
Phone: 919-254-7798 EMail: narten@raleigh.ibm.com
电话：919-254-7798电子邮件：narten@raleigh.ibm.com
Harald Tveit Alvestrand Maxware Pirsenteret N-7005 Trondheim Norway
挪威特隆赫姆哈拉尔德·特维特·阿尔韦斯特兰德马克斯韦尔皮森塔雷特N-7005
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。