この文書はRFC 5237の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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
           プロトコルフィールドのIANA割当ガイドライン

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.
   この文書はIPv4ヘッダに新しいプロトコルフィールド値を割り当てるた
   めのIANAガイドラインを改訂します。これはRFC2780の専門家レビュー
   の選択肢を取り除く様に指定された規則を変更します。この変更はIPv4
   の次ヘッダフィールド値の割当に影響するでしょう。

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.
   この文書はIPv4ヘッダ[RFC0791]に新しいプロトコルフィールド値を割
   り当てるためのIANAガイドライン[RFC2780]を改訂します。また、IP
   v6次ヘッダ値の割当のIANAガイドラインが[RFC2460]がIPv4ガイ
   ドラインを参照するので、変更はIPv6にも適用されます。

   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同意、または、標準化手順に従って、IAN
      AはIPv4プロトコル名前空間から値を割り当てます。専門家レビュー
      の過程は非公開情報がかかわる特別な場合に使用されるだけであるべき
      です。これらの場合でも、専門家は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.
   IETFが新しいプロトコルの開発をし続けるとき、標準化手順規則の必
   要性は明白です。この空間の実験的な割当を許す必要があるのも、同じく
   明白です; 例えばRFC 4727[RFC4727]を見てください。標準化手順以外や
   IETF外での使用でこの空間から値を割り当てる場合に同様な問題があ
   ります。 しかしながら、フィールドサイズは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.
   しかしながら、私たちは、現在、この空間の割当に秘密保持契約の選択が
   適切でないと信じています。 会社が固有のプロトコルを開発していて、
   新しい研究領域や将来の製品を明らかにしたがっていなかったとき、伝統
   的に、IANAの非公開協定が使用されました。 もうそのような固有の
   プロトコルに資源を使用するのが妥当であると私たちが信じていないほど
   プロトコル空間は制限されます。 したがって、私たちは、レビューでき
   る公開の仕様があるときだけ、IESG同意か標準化手順を使用すること
   で配布するだけであるべきでと信じています。

   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.
   その結果、この文書は、IPv4プロトコルとIPv6次ヘッダフィール
   ドについて、専門家レビューの選択肢を削除する様に、RFC2780規則を改
   訂します。この文書は秘密保持契約がある他のパラメタの割当については、
   それらのパラメタは異なった方針を必要とするでしょから、何の言及もし
   ません。

2.  IANA Considerations
2.  IANAの考察

   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.
      IANAは、IESG同意か標準化手順に従って、IPv4プロトコル
      名前空間から値を割り当てます。

   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章のIPv6次ヘッダフィールドの規則を暗
   黙に変更します。この規則は同じRFCの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
付録A.     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同意、または、標準化手順に従って、IAN
      AはIPv4プロトコル名前空間から値を割り当てます。専門家レビュー
      の過程は非公開情報がかかわる特別な場合に使用されるだけであるべき
      です。これらの場合でも、専門家はIESGによって任命されるべきです。

   to:

      IANA allocates values from the IPv4 Protocol name space following
      an IESG Approval or Standards Action process.
      IANAは、IESG同意か標準化手順に従って、IPv4プロトコル
      名前空間から値を割り当てます。

   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章のIPv4規則の参照は、この参照はここで改訂
   された規則、すなわち専門家レビューの選択がない規則、を示していると
   理解されるべきです。

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).
   著作権(C)IETF信託(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.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とIETF信託とインターネット技術標準化タスクフォースは、明確にも暗
   黙にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的へ
   の利用に適当である事の保障を含め、全ての保証を拒否します。

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.
   この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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の写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、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に情報を伝えてください。

Japanese translation by Ishida So