この文書はRFC 5237の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group J. Arkko
Request for Comments: 5237 Ericsson
BCP: 37 S. Bradner
Updates: 2780 Harvard University
Category: Best Current Practice February 2008
IANA Allocation Guidelines for the Protocol Field
プロトコルフィールドのＩＡＮＡ割当ガイドライン
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.
この文書はインターネット共同体にインターネットの現時点での最良の方法
を示し、改良のための議論と提案を求めます。この文書の配布は無制限です。
Abstract
概要
This document revises the IANA guidelines for allocating new Protocol
field values in IPv4 header. It modifies the rules specified in RFC
2780 by removing the Expert Review option. The change will also
affect the allocation of Next Header field values in IPv6.
この文書はＩＰｖ４ヘッダに新しいプロトコルフィールド値を割り当てるた
めのＩＡＮＡガイドラインを改訂します。これはRFC2780の専門家レビュー
の選択肢を取り除く様に指定された規則を変更します。この変更はＩＰｖ４
の次ヘッダフィールド値の割当に影響するでしょう。
1. Introduction
1. はじめに
This document revises the IANA guidelines [RFC2780] for allocating
new Protocol field values in IPv4 header [RFC0791]. The change will
also be applicable for IPv6, as the IANA guidelines for IPv6 Next
Header values [RFC2460] allocation refer to the IPv4 guidelines.
この文書はＩＰｖ４ヘッダ[RFC0791]に新しいプロトコルフィールド値を割
り当てるためのＩＡＮＡガイドライン[RFC2780]を改訂します。また、ＩＰ
ｖ６次ヘッダ値の割当のＩＡＮＡガイドラインが[RFC2460]がＩＰｖ４ガイ
ドラインを参照するので、変更はＩＰｖ６にも適用されます。
Previously, RFC 2780 allowed such allocations to happen through IESG
Approval, Standards action, or Expert Review processes
[RFC2780][RFC2434]. The Expert Review process was specified to be
used only in the case where a non-disclosure agreement was involved:
以前、RFC 2780は、IESG同意を通じて行われる配布か、標準化手順か、専門
家レビュー手順[RFC2780][RFC2434]で割当を許しました。専門家レビュー
手順は秘密保持契約がかかわった場合に使用されるために指定されました:
IANA allocates values from the IPv4 Protocol name space following
an Expert Review, IESG Approval or Standards Action process. The
Expert Review process should only be used in those special cases
where non-disclosure information is involved. In these cases the
expert(s) should be designated by the IESG.
専門化レビュー、ＩＥＳＧ同意、または、標準化手順に従って、ＩＡＮ
ＡはＩＰｖ４プロトコル名前空間から値を割り当てます。専門家レビュー
の過程は非公開情報がかかわる特別な場合に使用されるだけであるべき
です。これらの場合でも、専門家はIESGによって任命されるべきです。
The need for the Standards Action rule is obvious as the IETF keeps
developing new protocols. It is equally obvious that there is a need
to allow experimental allocations in this space; see RFC 4727
[RFC4727] for an example. Similarly, there are cases when it makes
sense to allocate values out of this space for other non-Standards
Track or non-IETF uses. However, the size of the field is 256
values, and 55% of these were in use at the time this document was
written. As a result, a sanity check is needed to ensure that
allocations are not made needlessly. RFC 2780 specifies the IESG
Approval rule to take care of these sanity checks for the non-
Standards Track cases. The judgment call can take into account the
existence of a stable protocol specification, constituency that wants
to use it, need to avoid duplicated allocations for the same purpose,
whether protocol number allocation is the right solution for this
problem as opposed to, say, a TCP port, and so on.
ＩＥＴＦが新しいプロトコルの開発をし続けるとき、標準化手順規則の必
要性は明白です。この空間の実験的な割当を許す必要があるのも、同じく
明白です; 例えばRFC 4727[RFC4727]を見てください。標準化手順以外や
ＩＥＴＦ外での使用でこの空間から値を割り当てる場合に同様な問題があ
ります。 しかしながら、フィールドサイズは256個の値で、この文書が書
かれた時点で、これらの55%は使用中でした。この結果、不必要な割当を
しないのを保証するために、健全度チェックが必要です。RFC 2780は、標
準化手順以外の場合にこれらの健全度チェックの世話をするためにIESG同
意規則を指定します。審判の判定は、安定したプロトコル仕様の存在、そ
れを使用したがっている人、同じ目的で重複割当を避ける必要性、プロト
コル番号割当がこの問題のための正しい解決策であるかどうか、例えば
TCPポートではダメかどうか、を考慮に入れることができます、
However, we now believe that the non-disclosure agreement option is
not appropriate for allocations in this space. Traditionally, non-
disclosure agreements have been used by the IANA when a company was
developing a proprietary protocol and did not want to disclose new
areas of research or future products. The protocol space is limited
enough that we no longer believe that it is reasonable to use the
resource for such proprietary protocols. Thus, we believe that
allocations should only be made using the IESG Approval or Standards
Action processes when there are public specifications that can be
reviewed.
しかしながら、私たちは、現在、この空間の割当に秘密保持契約の選択が
適切でないと信じています。 会社が固有のプロトコルを開発していて、
新しい研究領域や将来の製品を明らかにしたがっていなかったとき、伝統
的に、ＩＡＮＡの非公開協定が使用されました。 もうそのような固有の
プロトコルに資源を使用するのが妥当であると私たちが信じていないほど
プロトコル空間は制限されます。 したがって、私たちは、レビューでき
る公開の仕様があるときだけ、ＩＥＳＧ同意か標準化手順を使用すること
で配布するだけであるべきでと信じています。
As a result, this document revises the RFC 2780 rules by removing the
option for Expert Review for the IPv4 Protocol and IPv6 Next Header
fields. This document takes no position on the allocation of other
parameters with non-disclosure agreements, as those parameters may
require different policies.
その結果、この文書は、ＩＰｖ４プロトコルとＩＰｖ６次ヘッダフィール
ドについて、専門家レビューの選択肢を削除する様に、RFC2780規則を改
訂します。この文書は秘密保持契約がある他のパラメタの割当については、
それらのパラメタは異なった方針を必要とするでしょから、何の言及もし
ません。
2. IANA Considerations
2. ＩＡＮＡの考察
This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with
the following:
この文書はRFC 2780の4.3章の規則[RFC2780]を以下に取り替えます:
IANA allocates values from the IPv4 Protocol name space following
an IESG Approval or Standards Action process.
ＩＡＮＡは、ＩＥＳＧ同意か標準化手順に従って、ＩＰｖ４プロトコル
名前空間から値を割り当てます。
This document also makes an implicit change to the rule for the IPv6
Next Header field in Section 5.3 of RFC 2780. That rule refers to
the rule in Section 4.3 of the same RFC. From now on, this reference
should be understood to refer to the rule revised here, i.e., without
the Expert Review option.
また、この文書はRFC 2780の5.3章のＩＰｖ６次ヘッダフィールドの規則を暗
黙に変更します。この規則は同じＲＦＣの4.3章の規則を参照します。現時点
から、この参照はここで改訂された規則、すなわち専門家レビューの選択が
ない規則、を示していると理解されるべきです。
3. Security Considerations
3. セキュリティ問題
This specification does not change the security properties of the
affected protocols.
この仕様は影響を受けるプロトコルのセキュリティ特性を変えません。
4. Acknowledgments
4. 謝辞
Issues with the original RFC 2780 rules were uncovered in discussions
of the IETF-IANA team. The team also provided background information
on the practical difficulties encountered with non-disclosure
agreements. The authors would like to thank Thomas Narten, Bill
Fenner, and Michelle Cotton in particular.
元々のRFC 2780規則の問題はIETF-IANAチームの議論で発見されました。また、
チームは秘密保持契約で遭遇する実用的な困難に関する基礎的な情報を提供
しました。作者はThomas Narten, Bill Fenner, and Michelle Cottonに感謝
します。
5. References
5. 参考文献
5.1. Normative References
5.1. 参照する参考文献
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
5.2. Informative References
5.2. 有益な参考文献
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
Appendix A. Changes from RFC 2780
付録Ａ． RFC 2780からの変更
Section 4.3 from RFC 2780 has been changed from:
RFC 2780の4.3章は以下の通り変わりました：
IANA allocates values from the IPv4 Protocol name space following
an Expert Review, IESG Approval or Standards Action process. The
Expert Review process should only be used in those special cases
where non-disclosure information is involved. In these cases the
expert(s) should be designated by the IESG.
専門化レビュー、ＩＥＳＧ同意、または、標準化手順に従って、ＩＡＮ
ＡはＩＰｖ４プロトコル名前空間から値を割り当てます。専門家レビュー
の過程は非公開情報がかかわる特別な場合に使用されるだけであるべき
です。これらの場合でも、専門家はIESGによって任命されるべきです。
to:
IANA allocates values from the IPv4 Protocol name space following
an IESG Approval or Standards Action process.
ＩＡＮＡは、ＩＥＳＧ同意か標準化手順に従って、ＩＰｖ４プロトコル
名前空間から値を割り当てます。
In addition, RFC 2780 Section 5.3 reference to IPv4 rules should be
understood to refer to the rule revised here, i.e., without the
Expert Review option.
さらに、RFC 2780の5.3章のＩＰｖ４規則の参照は、この参照はここで改訂
された規則、すなわち専門家レビューの選択がない規則、を示していると
理解されるべきです。
Authors' Addresses
著者のアドレス
Jari Arkko
Ericsson
Jorvas 02420
Finland
EMail: jari.arkko@piuha.net
Scott Bradner
Harvard University
Cambridge, MA 02138
US
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Full Copyright Statement
完全著作権表示
Copyright (C) The IETF Trust (2008).
著作権（Ｃ）ＩＥＴＦ信託（２００８）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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, THE IETF TRUST 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 procedures with respect to rights in RFC documents can be
found in BCP 78 and 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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。