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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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.
一つの目的は、標準的には、それが実際よりもより成熟であるという認識を作成しないようにすることです。
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].
また、最も良いCurrent Practiceドキュメント[RFC1818]は、一般的にそれらが参照できるかという点で標準化過程文書に似考慮されていることに留意すべきです。例えば、実験的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の仕様が利用可能でない限り、1は完全にプロトコルを実装することはできません。従って、参照は規範的であろう。
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]で指定さが許容されるようなアルゴリズム」などのテキストは、有益な参照を示します。
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.
この文書では、ハラルドAlvestrand、スティーブBellovin氏、スコット・ブラッドナー、ネッドフリード、アリソンマンキン、ジェフシラー、およびバートWijnenによって特定の貢献と、IESG内の議論の結果です。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、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]ポステル、J.、李、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メッセージダイジェストアルゴリズム"、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.、ベラー、M.、およびR.カネッティ、 "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/
電話：+1 206 780 0431 Eメール：randy@psg.com URI：http://psg.com/~randy/
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 US
トーマスNarten氏IBM社の私書箱12195リサーチトライアングルパーク、ノースカロライナ州27709から2195米箱
Phone: +1 919 254 7798 EMail: narten@us.ibm.com
電話：+1 919 254 7798 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。