Network Working Group R. Bush
Request for Comments: 3967 IIJ
BCP: 97 T. Narten
Category: Best Current Practice IBM Corporation
December 2004
Network Working Group R. Bush
Request for Comments: 3967 IIJ
BCP: 97 T. Narten
Category: Best Current Practice IBM Corporation
December 2004
Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level
明确标准跟踪文件的时间，规范性地引用较低级别的文件
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances.
IETF程序通常要求，标准跟踪RFC不得对成熟度较低的其他标准跟踪文件或非标准跟踪规范（其他标准机构的规范除外）进行规范性引用。例如，标准跟踪文档可能没有对信息RFC的规范性引用。由于IETF使用信息性RFC来描述非IETF标准或此类标准的IETF特定使用模式，因此有时需要例外情况。本文件澄清并更新了这些情况下使用的程序。
The Internet Standards Process [RFC2026] Section 4.2.4 specifies the following:
互联网标准流程[RFC2026]第4.2.4节规定了以下内容：
Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies.
标准轨道规范通常不得依赖于成熟度较低的其他标准轨道规范或非标准轨道规范，而非其他标准机构的参考规范。
One intent is to avoid creating a perception that a standard is more mature than it actually is.
一个目的是避免造成标准比实际更成熟的感觉。
It should also be noted that Best Current Practice documents [RFC1818] have generally been considered similar to Standards Track documents in terms of what they can reference. For example, a normative reference to an Experimental RFC has been considered an improper reference per [RFC2026].
还应注意的是，当前最佳实践文件[RFC1818]通常被认为与标准跟踪文件在可参考方面类似。例如，根据[RFC2026]，对实验RFC的规范性引用被视为不当引用。
Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Broadly speaking, a normative reference specifies a document that must be read to fully understand or implement the subject matter in the new RFC, or whose contents are effectively part of the new RFC, as its omission would leave the new RFC incompletely specified. An informative reference is not normative; rather, it provides only additional background information.
在RFC中，对其他文件的引用分为两大类：“规范性”和“信息性”。广义而言，规范性参考文件规定了必须阅读的文件，以充分理解或实施新RFC中的主题，或其内容实际上是新RFC的一部分，因为其省略将导致新RFC未完全规定。资料性参考文献不规范；相反，它只提供额外的背景信息。
An exact and precise definition of what is (and is not) a normative reference has proven challenging in practice, as the details and implications can be subtle. Moreover, whether a reference needs to be normative can depend on the context in which a particular RFC is being published in the first place. For example, in the context of an IETF Standard, it is important that all dependent pieces be clearly specified and available in an archival form so that there is no disagreement over what constitutes a standard. This is not always the case for other documents.
实践证明，对什么是（或不是）规范性参考的准确定义具有挑战性，因为细节和含义可能很微妙。此外，参考文献是否需要规范性可能取决于特定RFC首先发布的环境。例如，在IETF标准的背景下，重要的是所有相关部分都应明确规定并以存档形式提供，以便在标准构成方面没有分歧。其他文件并非总是如此。
The rest of this section provides guidance on what might (and might not) be considered normative in the context of the IETF standards process.
本节其余部分提供了在IETF标准过程中哪些可以（也可能不可以）被视为规范性的指南。
In the IETF, it is a basic assumption that implementors must have a clear understanding of what they need to implement in order to be fully compliant with a standard and to be able to interoperate with other implementations of that standard. For documents that are referenced, any document that includes key information an implementer needs would be normative. For example, if one needs to understand a packet format defined in another document in order to fully implement a specification, the reference to that format would be normative. Likewise, if a reference to a required algorithm is made, the reference would be normative.
在IETF中，一个基本假设是，实施者必须清楚地了解他们需要实现什么，以便完全符合标准，并能够与该标准的其他实现进行互操作。对于引用的文件，任何包含实施者需要的关键信息的文件都是规范性的。例如，如果需要理解另一个文档中定义的数据包格式以完全实现规范，那么对该格式的引用将是规范性的。同样，如果引用了所需的算法，则引用将是规范性的。
Some specific examples:
一些具体例子：
- If a protocol relies on IPsec to provide security, one cannot fully implement the protocol unless the specification for IPsec is available; hence, the reference would be normative.
- 如果协议依赖IPsec提供安全性，则除非IPsec规范可用，否则无法完全实现该协议；因此，该引用是规范性的。
The referenced specification would likely include details about specific key management requirements, which transforms are required and which are optional, etc.
参考规范可能包括有关特定密钥管理需求的详细信息，哪些转换是必需的，哪些是可选的，等等。
- In MIB documents, an IMPORTS clause by definition is a normative reference.
- 在MIB文件中，根据定义，进口条款是一种规范性参考。
- When a reference to an example is made, such a reference need not be normative. For example, text such as "an algorithm such as the one specified in [RFCxxxx] would be acceptable" indicates an informative reference, since that cited algorithm is just one of several possible algorithms that could be used.
- 当引用示例时，这种引用不必是规范性的。例如，“可接受[RFCxxxx]中指定的算法”等文本表示参考信息，因为所引用的算法只是可使用的几种可能算法之一。
There are a number of circumstances in which an IETF document may need to make a normative reference to a document at a lower maturity level, but such a reference conflicts with Section 4.2.4 of [RFC2026]. For example:
在许多情况下，IETF文件可能需要对较低成熟度的文件进行规范性引用，但此类引用与[RFC2026]第4.2.4节冲突。例如：
o A standards track document may need to refer to a protocol or algorithm developed by an external body but modified, adapted, or profiled by an IETF informational RFC, for example, MD5 [RFC1321] and HMAC [RFC2104]. Note that this does not override the IETF's duty to see that the specification is indeed sufficiently clear to enable creation of interoperable implementations.
o 标准跟踪文档可能需要引用由外部机构开发的协议或算法，但由IETF信息RFC修改、改编或分析，例如MD5[RFC1321]和HMAC[RFC2104]。请注意，这并没有覆盖IETF的职责，即确保规范确实足够清晰，能够创建可互操作的实现。
o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs.
o 标准文件可能需要参考专有协议，IETF通常使用信息RFC记录专有协议。
o A migration or co-existence document may need to define a standards track mechanism for migration from, and/or co-existence with, an historic protocol, a proprietary protocol, or possibly a non-standards track protocol.
o 迁移或共存文档可能需要定义从历史协议、专有协议或可能的非标准跟踪协议迁移和/或与之共存的标准跟踪机制。
o There are exceptional procedural or legal reasons that force the target of the normative reference to be an informational or historical RFC or to be at a lower standards level than the referring document.
o 由于特殊的程序或法律原因，规范性参考文件的目标必须是信息性或历史性RFC，或低于参考文件的标准水平。
o A BCP document may want to describe best current practices for experimental or informational specifications.
o BCP文件可能希望描述实验性或信息性规范的最佳当前实践。
For Standards Track or BCP documents requiring normative reference to documents of lower maturity, the normal IETF Last Call procedure will be issued, with the need for the downward reference explicitly documented in the Last Call itself. Any community comments on the appropriateness of downward references will be considered by the IESG as part of its deliberations.
对于需要对较低成熟度文件进行规范性引用的标准跟踪或BCP文件，将发布标准IETF最后调用程序，并在最后调用中明确记录向下引用的需要。IESG将考虑社区对向下参考的适当性的任何意见，作为其审议的一部分。
Once a specific down reference to a particular document has been accepted by the community (e.g., has been mentioned in several Last Calls), an Area Director may waive subsequent notices in the Last Call of down references to it. This should only occur when the same document (and version) are being referenced and when the AD believes that the document's use is an accepted part of the community's understanding of the relevant technical area. For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well known among cryptographers.
一旦社区接受了对特定文件的特定撤销引用（例如，在最近几次撤销引用中已提及），区域总监可放弃在最后一次撤销引用中的后续通知。只有在引用同一文件（和版本）且广告认为该文件的使用是社区对相关技术领域理解的可接受部分时，才会发生这种情况。例如，MD5[RFC1321]和HMAC[RFC2104]的使用在密码学家中是众所周知的。
This procedure should not be used if the proper step is to move the document to which the reference is being made into the appropriate category. It is not intended as an easy way out of normal process. Rather, the procedure is intended for dealing with specific cases where putting particular documents into the required category is problematic and unlikely ever to happen.
如果正确的步骤是将参考文件移至适当的类别，则不应使用本程序。这不是一种脱离正常流程的简单方法。相反，该程序旨在处理将特定文件归入所需类别存在问题且不太可能发生的特定情况。
This document is not known to create any new vulnerabilities for the Internet. On the other hand, inappropriate or excessive use of the process might be considered a downgrade attack on the quality of IETF standards or, worse, on the rigorous review of security aspects of standards.
目前还不知道此文档是否会为Internet创建任何新的漏洞。另一方面，不适当或过度使用该过程可能被视为对IETF标准质量的降级攻击，或者更糟糕的是，对标准安全方面的严格审查。
This document is the result of discussion within the IESG, with particular contribution by Harald Alvestrand, Steve Bellovin, Scott Bradner, Ned Freed, Allison Mankin, Jeff Schiller, and Bert Wijnen.
本文件是IESG内部讨论的结果，由Harald Alvestrand、Steve Bellovin、Scott Bradner、Ned Freed、Allison Mankin、Jeff Schiller和Bert Wijnen特别贡献。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", BCP 1, RFC 1818, August 1995.
[RFC1818]Postel，J.，Li，T.，和Y.Rekhter，“当前最佳实践”，BCP 1，RFC 1818，1995年8月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
Randy Bush IIJ 5147 Crystal Springs Bainbridge Island, WA 98110 US
兰迪·布什IIJ 5147美国华盛顿州班布里奇岛水晶泉98110
Phone: +1 206 780 0431
EMail: randy@psg.com
URI: http://psg.com/~randy/
Phone: +1 206 780 0431
EMail: randy@psg.com
URI: http://psg.com/~randy/
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 US
美国北卡罗来纳州三角研究公园12195号邮政信箱托马斯·纳顿IBM公司，邮编：27709-2195
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。