RFC5237 日本語訳

Network Working Group                                           J. Arkko
Request for Comments: 5237                                      Ericsson
BCP: 37                                                       S. Bradner
Updates: 2780                                         Harvard University
Category: Best Current Practice                            February 2008

Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5237エリクソンBCP: 37秒間ブラドナーアップデート: 2780年のハーバード大学カテゴリ: 最も良い現在の練習2008年2月

           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.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

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でExpert Reviewオプションを取り除くことによって指定された規則を変更します。 また、変化はIPv6でのNext Header分野値の配分に影響するでしょう。

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]を改訂します。 また、変化はIPv6に適切になるでしょう、IPv6 Next Headerが[RFC2460]配分を評価するのでIANAガイドラインがIPv4ガイドラインを示すとき。

   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:

以前、RFC2780はIESG Approval、Standards動作、またはExpert Reviewプロセス[RFC2780][RFC2434]を通してそのような配分を起こらせました。 Expert Reviewプロセスは秘密保持契約がかかわった場合だけに使用されるために指定されました:

      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.

Expert Review、IESG ApprovalまたはStandards Actionプロセスに続いて、IANAはスペースというIPv4プロトコル名から値を割り当てます。 Expert Reviewプロセスは非公開情報がかかわるそれらの特別な場合に使用されるだけであるべきです。 これらの場合では、専門家は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

IETFが新しいプロトコルを開発し続けるとき、Standards Action規則の必要性は明白です。 このスペースで実験的な配分を許す必要があるのは、等しく明白です。 例に関してRFC4727[RFC4727]を見てください。 Trackか非IETFが使用する他の非規格のためにこのスペースから値を割り当てる感覚を作るとき、同様に、ケースがあります。 しかしながら、分野のサイズは256の値です、そして、このドキュメントが書かれたとき、これらの55%は使用中でした。 その結果、健全度チェックが、それを確実にするのに必要です。

Arkko & Bradner          Best Current Practice                  [Page 1]

RFC 5237               Protocol Field IANA Rules           February 2008

Arkkoとブラドナーの最も良い現在の習慣[1ページ]RFC5237は2008年2月に分野IANA規則について議定書の中で述べます。

   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.

不必要に配分をしません。 RFC2780は、非規格のTrackケースのためのこれらの健全度チェックの世話をするためにIESG Approval規則を指定します。 審判の判定は安定したプロトコル仕様の存在を考慮に入れることができます、それを使用したがっている選挙民、同じ目的のためのコピーされた配分を避ける必要性、プロトコル番号配分がたとえば、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 ApprovalかStandards Actionプロセスを使用することで配分をするだけであるべきであると信じています。

   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.

その結果、このドキュメントは、Expert ReviewのためにIPv4プロトコルとIPv6 Next Header分野にオプションを移すことによって、RFC2780規則を改訂します。 このドキュメントは秘密保持契約がある他のパラメタの配分のときに立場を全く取りません、それらのパラメタが異なった方針を必要とするとき。

2.  IANA Considerations

2. IANA問題

   This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with
   the following:

このドキュメントはRFC2780セクション4.3規則[RFC2780]を以下に置き換えます:

      IANA allocates values from the IPv4 Protocol name space following
      an IESG Approval or Standards Action process.

IESG ApprovalかStandards Actionプロセスに続いて、IANAはスペースという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.

また、このドキュメントはRFC2780のセクション5.3で規則への内在している変更をIPv6 Next Header分野に行います。 その規則は同じRFCのセクション4.3の規則を示します。 これから先、この参照がここで改訂された規則を示すのが理解されるべきです、すなわち、Expert Reviewオプションなしで。

3.  Security Considerations

3. セキュリティ問題

   This specification does not change the security properties of the
   affected protocols.

この仕様は影響を受けるプロトコルのセキュリティ資産を変えません。

Arkko & Bradner          Best Current Practice                  [Page 2]

RFC 5237               Protocol Field IANA Rules           February 2008

Arkkoとブラドナーの最も良い現在の習慣[2ページ]RFC5237は2008年2月に分野IANA規則について議定書の中で述べます。

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.

オリジナルのRFC2780規則の問題はIETF-IANAチームの議論で発見されました。 また、チームは秘密保持契約で遭遇する実用的な困難に関する基礎的な情報を提供しました。 作者はトーマスNarten、ビル・フェナー、および特にミシェルCottonに感謝したがっています。

5.  References

5. 参照

5.1.  Normative References

5.1. 引用規格

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月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.

[RFC2780] ブラドナー、S.、および「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、BCP37、RFC2780(2000年3月)対パクソン

5.2.  Informative References

5.2. 有益な参照

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

[RFC4727]フェナー、B.、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC4727、2006年11月。

Arkko & Bradner          Best Current Practice                  [Page 3]

RFC 5237               Protocol Field IANA Rules           February 2008

Arkkoとブラドナーの最も良い現在の習慣[3ページ]RFC5237は2008年2月に分野IANA規則について議定書の中で述べます。

Appendix A.  Changes from RFC 2780

RFC2780からの付録A.変化

   Section 4.3 from RFC 2780 has been changed from:

以下からRFC2780からのセクション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.

Expert Review、IESG ApprovalまたはStandards Actionプロセスに続いて、IANAはスペースというIPv4プロトコル名から値を割り当てます。 Expert Reviewプロセスは非公開情報がかかわるそれらの特別な場合に使用されるだけであるべきです。 これらの場合では、専門家はIESGによって任命されるはずです。

   to:

to:

      IANA allocates values from the IPv4 Protocol name space following
      an IESG Approval or Standards Action process.

IESG ApprovalかStandards Actionプロセスに続いて、IANAはスペースという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.

さらに、IPv4規則のRFC2780セクション5.3参照がここで改訂された規則を示すのが理解されるべきです、すなわち、Expert Reviewオプションなしで。

Authors' Addresses

作者のアドレス

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

ヤリArkkoエリクソンJorvas02420フィンランド

   EMail: jari.arkko@piuha.net

メール: jari.arkko@piuha.net

   Scott Bradner
   Harvard University
   Cambridge, MA  02138
   US

スコット・ブラドナーハーバード大学MA02138ケンブリッジ(米国)

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu

以下に電話をしてください。 +1 3864年の617 495メール: sob@harvard.edu

Arkko & Bradner          Best Current Practice                  [Page 4]

RFC 5237               Protocol Field IANA Rules           February 2008

Arkkoとブラドナーの最も良い現在の習慣[4ページ]RFC5237は2008年2月に分野IANA規則について議定書の中で述べます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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に情報を扱ってください。

Arkko & Bradner          Best Current Practice                  [Page 5]

Arkkoとブラドナーの最も良い現在の習慣[5ページ]