RFC3967 日本語訳
3967 Clarifying when Standards Track Documents may Refer Normativelyto Documents at a Lower Level. R. Bush, T. Narten. December 2004. (Format: TXT=12251 bytes) (Updated by RFC4897) (Also BCP0097) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Bush
Request for Comments: 3967 IIJ
BCP: 97 T. Narten
Category: Best Current Practice IBM Corporation
December 2004
コメントを求めるワーキンググループR.ブッシュの要求をネットワークでつないでください: 3967IIJ BCP: 97T.Nartenカテゴリ: 最も良い現在の練習IBM社の2004年12月
Clarifying when Standards Track Documents may Refer
Normatively to Documents at a Lower Level
Standards Track Documentsがそうするときのはっきりさせる、Lower LevelのDocumentsへのRefer Normatively
Status of this Memo
この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).
Copyright(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特有のモードを説明するのに情報のRFCsを使用するとき、この規則への例外が時々必要です。 このドキュメントは、こういう事情ですから実行した手順をはっきりさせて、アップデートします。
1. Introduction
1. 序論
The Internet Standards Process [RFC2026] Section 4.2.4 specifies the following:
インターネットStandards Process[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つは、規格が知覚ですが、作成するのを実際により熟した状態で避けることになっています。
Bush & Narten Best Current Practice [Page 1] RFC 3967 Document Down-Ref Clarifications December 2004
明確化2004年12月の下がっている審判のブッシュとNartenの最も良い現在の習慣[1ページ]RFC3967ドキュメント
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ドキュメントと同様であると考えられたことに注意されるべきです。 例えば、Experimental RFCの引用規格は[RFC2026]あたり1つの不適当な参照であると考えられました。
1.1. Normative References
1.1. 引用規格
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 Standardの文脈では、すべての依存する断片が規格を構成することの上に不一致が全くないくらい記録保管所のフォームで明確に指定されていて利用可能であることは、重要です。 これはいつも他のドキュメントのためのそうであるというわけではありません。
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では、それは作成者には彼らが規格で完全に言いなりになるために実装して、その規格の他の実装で共同利用できる必要があることに関する明確な理解がなければならないという基本仮定です。 参照をつけられたドキュメントに関しては、implementerが必要とする主要な情報を含んでいるどんなドキュメントも規範的でしょう。 例えば、人が、仕様を完全に履行するために別のドキュメントで定義されたパケット・フォーマットを理解する必要があるなら、その形式の参照は規範的でしょう。 同様に、必要なアルゴリズムについて言及されるなら、参照は規範的でしょう。
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つは完全にプロトコルを実装することができるというわけではありません。 したがって、参照は規範的でしょう。
Bush & Narten Best Current Practice [Page 2] RFC 3967 Document Down-Ref Clarifications December 2004
明確化2004年12月の下がっている審判のブッシュとNartenの最も良い現在の習慣[2ページ]RFC3967ドキュメント
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つであることで。
2. The Need for Downward References
2. 下方向参照の必要性
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ドキュメントが下側の成熟レベルでドキュメントの引用規格をする必要があるかもしれない多くの事情がありますが、そのような参照は.4セクション4.2[RFC2026]と衝突します。 例えば:
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は情報のRFCsを使用することで固有のプロトコルを記録します。
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ドキュメントは実験的であるか情報の仕様のために最も良い現在の実務について説明したがっているかもしれません。
Bush & Narten Best Current Practice [Page 3] RFC 3967 Document Down-Ref Clarifications December 2004
明確化2004年12月の下がっている審判のブッシュとNartenの最も良い現在の習慣[3ページ]RFC3967ドキュメント
3. The Procedure to Be Used
3. 使用されるべき手順
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.
より低い円熟のドキュメントの引用規格を必要とするStandards TrackかBCPドキュメントに関しては、正常なIETF Last Call手順を発行するでしょう、明らかにLast Call自身に記録された下方向参照の必要性をもって。 下方向参照の適切さのどんな共同体コメントも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.
特定のドキュメントの特定の下に参照が共同体(例えば、数個のLast Callsでは、言及された)によっていったん受け入れられると、Areaディレクターはそれの下に参照のLast Callでのその後の通知を放棄するかもしれません。 同じドキュメント(そして、バージョン)が参照をつけることにされるのであって、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.
適切なステップが参照が作っていることにされるのであるドキュメントを適切なカテゴリに動かすことであるならこの手順を用いるべきではありません。 それは正常なプロセスの安易な解決法として意図しません。 むしろ、必要なカテゴリに特定のドキュメントを入れるのが問題が多くて、ありそうもない特定のケースに対処するために、今までに、手順が起こることを意図します。
4. Security Considerations
4. セキュリティ問題
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規格の品質に対するダウングレード攻撃であると考えられるか、または厳しさで、よりひどく規格のセキュリティ局面について調査するかもしれません。
5. Acknowledgments
5. 承認
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の中の議論の結果です。
Bush & Narten Best Current Practice [Page 4] RFC 3967 Document Down-Ref Clarifications December 2004
明確化2004年12月の下がっている審判のブッシュとNartenの最も良い現在の習慣[4ページ]RFC3967ドキュメント
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
6.2. Informative References
6.2. 有益な参照
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
Practices", BCP 1, RFC 1818, August 1995.
[RFC1818] ポステルとJ.と李、T.とY.Rekhter、「最も良い現在の実務」、BCP1、RFC1818、1995年8月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
7. Authors' Addresses
7. 作者のアドレス
Randy Bush IIJ 5147 Crystal Springs Bainbridge Island, WA 98110 US
ランディブッシュIIJ5147水晶スプリングベーンブリッジ島、ワシントン98110米国
Phone: +1 206 780 0431 EMail: randy@psg.com URI: http://psg.com/~randy/
以下に電話をしてください。 +1 0431年の206 780メール: randy@psg.com ユリ: http://psg.com/~randy/
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 US
トーマスNarten IBM社のP.O. Box12195リサーチトライアングル公園、NC27709-2195米国
Phone: +1 919 254 7798 EMail: narten@us.ibm.com
以下に電話をしてください。 +1 7798年の919 254メール: narten@us.ibm.com
Bush & Narten Best Current Practice [Page 5] RFC 3967 Document Down-Ref Clarifications December 2004
明確化2004年12月の下がっている審判のブッシュとNartenの最も良い現在の習慣[5ページ]RFC3967ドキュメント
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78と、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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Bush & Narten Best Current Practice [Page 6]
ブッシュとNartenの最も良い現在の習慣[6ページ]
一覧
スポンサーリンク
