[要約] RFC 3967は、標準トラックのドキュメントが低レベルのドキュメントを参照する場合の明確化に関するものです。その目的は、ドキュメント間の参照の階層を明確にし、標準化プロセスをより効果的にすることです。
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 は非 IETF 標準またはそのような標準の IETF 固有の使用モードを説明するために情報 RFC を使用するため、この規則の例外が必要になる場合があります。この文書は、このような状況で使用される手順を明確にし、更新します。
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.
その目的の 1 つは、標準が実際よりも成熟しているという認識を与えないようにすることです。
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].
また、Best Current Practice 文書 [RFC1818] は、一般に、参照できる内容という点で Standards Track 文書と同様であると考えられていることに注意してください。たとえば、実験的 RFC への規範的な参照は、[RFC2026] によれば不適切な参照とみなされています。
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 内では、他の文書への参照は、「規範的」と「情報的」という 2 つの一般的なカテゴリに分類されます。大まかに言うと、規範的参照は、新しい 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 ドキュメントでは、IMPORTS 句は定義上、規範的な参照です。
- 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] で指定されているようなアルゴリズムは許容されます」などのテキストは、引用されたアルゴリズムが使用可能ないくつかのアルゴリズムの 1 つにすぎないため、参考情報を示します。
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.
特定の文書への特定のダウンリファレンスがコミュニティによって受け入れられると（たとえば、数回のラストコールで言及された）、エリアディレクターは、ラストコールでその文書へのダウンリファレンスについてのその後の通知を放棄することができます。これは、同じドキュメント (およびバージョン) が参照されており、そのドキュメントの使用が関連する技術分野のコミュニティの理解の一部として受け入れられていると AD が判断した場合にのみ発生します。たとえば、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.
この文書がインターネットに新たな脆弱性をもたらすことは知られていません。一方、プロセスの不適切または過剰な使用は、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 Alvestrond、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、「Best Current Practices」、BCP 1、RFC 1818、1995 年 8 月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R.、「MD5 メッセージ ダイジェスト アルゴリズム」、RFC 1321、1992 年 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
Randy Bush IIJ 5147 Crystal Springs Bainbridge Island, WA 98110 US
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
トーマス・ナーテン IBM Corporation P.O.Box 12195 Research Triangle Park、NC 27709-2195 US
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 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (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 エディター機能の資金は現在、インターネット協会によって提供されています。