RFC3936 日本語訳

Network Working Group                                        K. Kompella
Request for Comments: 3936                              Juniper Networks
Updates: 3209, 2205                                              J. Lang
BCP: 96                                                  Rincon Networks
Category: Best Current Practice                             October 2004

Kompellaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3936年の杜松はアップデートをネットワークでつなぎます: 3209、2205J.ラングBCP: 96 リンコンはカテゴリをネットワークでつなぎます: 最も良い現在の練習2004年10月

   Procedures for Modifying the Resource reSerVation Protocol (RSVP)

資源予約プロトコルを変更するための手順(RSVP)

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

要約

   This memo specifies procedures for modifying the Resource reSerVation
   Protocol (RSVP).  This memo also lays out new assignment guidelines
   for number spaces for RSVP messages, object classes, class-types, and
   sub-objects.

このメモはResource reSerVationプロトコル(RSVP)を変更するための手順を指定します。 また、このメモはRSVPメッセージ、オブジェクトのクラス、クラスタイプ、およびサブオブジェクトのために数の空間のための新しい課題ガイドラインを広げます。

1.  Introduction

1. 序論

   This memo specifies procedures for modifying the Resource reSerVation
   Protocol (RSVP) [RSVP], including (but not limited to) adding,
   updating, extending or obsoleting: messages, message formats and
   procedures, object classes and class types, object formats and
   procedures; header formats, error codes and subcodes and semantics,
   and procedures for sending, receiving, and addressing RSVP messages.

このメモはResource reSerVationプロトコル(RSVP)[RSVP]を変更するための手順を指定します、(他)付加を含んでいて、アップデートするか、広げているか、または以下を時代遅れにして メッセージ、メッセージ・フォーマット、手順、オブジェクトのクラス、クラスタイプ、オブジェクト形式、および手順。 発信して、受信して、RSVPにメッセージを扱うためのヘッダー形式、エラーコード、部分符号、意味論、および手順。

   IANA recognizes the following RSVP name spaces: Message Types, Class
   Names, Class Numbers, Class Types and Sub-objects, Virtual
   Destination Ports, and Error Codes and (Subcode) Values (all of these
   will collectively be referred to as RSVP entities in this document).
   This memo specifies ranges for each name space and assignment
   policies for each range.  New RSVP name spaces must be defined in a
   Standards Track RFC which include guidelines for IANA assignments
   within the new name spaces.

IANAは以下のRSVP名前空間を認識します: メッセージTypes、Class Names、Class民数記、Class Types、Sub-オブジェクト、Virtual Destination Ports、Error Codes、および(部分符号)値(これらのすべてがRSVP実体とまとめて本書では呼ばれるでしょう)。 このメモは各範囲としてそれぞれの名前スペースと課題方針に範囲を指定します。 Standards Track RFCで新しいRSVP名前空間を定義しなければなりません(空間という新しい名前の中にIANA課題のためのガイドラインを含んでいます)。

   The assignment policies used in this document are: Standards Action
   (as defined in [IANA]), Expert Review, and Organization/Vendor
   Private (more simply, "Vendor Private"); the last two are defined in
   this document.  The intent of these assignment policies is to ensure

本書では使用される課題方針は以下の通りです。 規格Action([IANA]で定義されるように)、Expert Review、およびOrganization/ベンダー兵士(単により多くの「ベンダー兵士」)。 最後の2は本書では定義されます。 課題方針が確実にすることになっているこれらの意図

Kompella & Lang          Best Current Practice                  [Page 1]

RFC 3936             Procedures for Modifying RSVP          October 2004

2004年10月にRSVPを変更するためのKompellaとラング最も良い現在の習慣[1ページ]RFC3936手順

   that extensions to RSVP receive adequate review before code-points
   are assigned, without being overly rigid.  Thus, if an extension is
   widely accepted and its ramifications are well understood, it may
   receive an assignment from the Standards Action space; however, if an
   extension is experimental in nature, it receives an assignment from
   the Expert Review space, and may, with maturity, move to Standards
   Track.  Assignments from the Vendor Private space are not reviewed,
   but there are mechanisms in place to ensure that these codepoints can
   co-exist in a network without harm.

コード・ポイントがひどく堅くなくて割り当てられる前にRSVPへの拡大は適切なレビューを受け取ります。 したがって、広く拡大を受け入れて、分岐をよく理解しているなら、Standards Actionスペースから課題を受け取るかもしれません。 しかしながら、拡大が現実に実験的であるなら、円熟で、それは、Expert Reviewスペースから課題を受け取って、Standards Trackに移行するかもしれません。 Vendor兵士のスペースからの課題は見直されませんが、これらのcodepointsがネットワークで害がなくて共存できるのを保証するために、メカニズムが適所にあります。

   A standards body other than the IETF that wishes to obtain an
   assignment for an RSVP entity must decide from which type of
   name/number space they desire their assignment be made from, and then
   submit the appropriate documentation.  For example, if the assignment
   is to be made from a number space designated as Standards Action, a
   Standards Track RFC MUST be submitted in support of the request for
   assignment.

A規格は、IETFを除いて、人工で彼らがどのタイプの名前/数のスペースを望むかからRSVP実体が、彼らの課題があると決めなければならないので課題を得るというその願望を具体化させて、次に、適切なドキュメンテーションを提出します。 例えば、課題がStandards Actionとして指定された数のスペースから作ることであるなら、課題を求める要求を支持してStandards Track RFCを提出しなければなりません。

   This memo updates the IANA Considerations section (section 7) of
   [RSVP-TE], replacing the assignment policies stated there.

そこに述べられた課題方針を置き換えて、このメモは[RSVP-TE]のIANA Considerations部(セクション7)をアップデートします。

   Conventions used in this document

本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[キーワード]で説明されるように本書では解釈されることであるべきです。

2.  Assignment Policies for RSVP Entities

2. RSVP実体のための課題方針

   For each of the RSVP name spaces identified by IANA, the space is
   divided into assignment ranges; the following terms are used in
   describing the procedures by which IANA assigns values: "Standards
   Action" (as defined in [IANA]), "Expert Review", and
   "Organization/Vendor Private", defined below.

空間というIANAによって特定されたそれぞれのRSVP名において、スペースは課題範囲に分割されます。 次の用語はIANAが値を割り当てる手順について説明する際に使用されます: 以下で定義された「専門のレビュー」的、そして、「組織/ベンダー個人的である」「規格Action。」([IANA]で定義されるように)

   "Expert Review" ranges refer to values that are to be reviewed by an
   Expert designated by the IESG.  The code points from these ranges are
   typically used for experimental extensions; such assignments MUST be
   requested by Experimental RFCs that document their use and
   processing, and the actual assignments made during the IANA actions
   for the document.  Values from "Expert Review" ranges MUST be
   registered with IANA.

「専門のReview」範囲はIESGによって指定されたExpertによって見直されることになっている値について言及します。 これらの範囲からのコード・ポイントは実験的な拡大に通常使用されます。 彼らの使用と処理を記録するExperimental RFCs、およびドキュメントのためのIANA動作の間にされた実際の課題でそのような課題を要求しなければなりません。 「専門のレビュー」範囲からの値をIANAに示さなければなりません。

   "Organization/Vendor Private" ranges refer to values that are
   enterprise-specific; these MUST NOT be registered with IANA.  For
   Vendor Private values, the first 4-octet word of the data field MUST
   be an enterprise code [ENT] as registered with the IANA SMI Network

「組織/ベンダー兵士」範囲は企業特有の値について言及します。 IANAにこれらを登録してはいけません。 Vendor兵士の値のために、データ・フィールドの最初の4八重奏の単語は登録されるとしてIANA SMI Networkとの企業コードでなければなりません[ENT]。

Kompella & Lang          Best Current Practice                  [Page 2]

RFC 3936             Procedures for Modifying RSVP          October 2004

2004年10月にRSVPを変更するためのKompellaとラング最も良い現在の習慣[2ページ]RFC3936手順

   Management Private Enterprise Codes, and the rest of the data
   thereafter is for the private use of the registered enterprise.  (For
   each RSVP entity that has a Vendor Private range, it must be
   specified where exactly the data field starts; see below for
   examples.)  In this way, different enterprises, vendors, or Standards
   Development Organizations (SDOs) can use the same code point without
   fear of collision.

その後、管理兵士のエンタープライズCodes、およびデータの残りはそうです。登録された企業の私用のために。 (Vendor兵士の範囲を持っているそれぞれのRSVP実体として、データ・フィールドがいったいどこで始まるか指定しなければなりません; 例に関して以下を見てください。) このように、異なった企業、ベンダー、またはStandards Development Organizations(SDOs)が衝突への恐怖なしで同じコード・ポイントを使用できます。

2.1.  Message Types

2.1. メッセージタイプ

   A Message Type is an 8-bit number that identifies the function of the
   RSVP message.  Values from 0 through 239 are to be assigned by
   Standards Action.  Values from 240 through 255 are to be assigned by
   Expert Review.

Message TypeはRSVPメッセージの機能を特定する8ビットの数です。 0〜239の値はStandards Actionによって割り当てられることです。 240〜255の値はExpert Reviewによって割り当てられることです。

2.2.  Class Names and Numbers

2.2. クラス名と数

   Each class of data objects in an RSVP message is identified by an all
   upper-case Class Name and an 8-bit Class Number (also known as
   Class-Num or C-Num).  Class Numbers are divided broadly into three
   ranges (0-127, 128-191, and 192-255) determined by the two high-order
   bits of the Class-Num object (the 'b' below represents a bit).

RSVPメッセージのそれぞれのクラスのデータ・オブジェクトはすべての大文字Class Nameと8ビットのClass Number(また、Class-ヌムかC-ヌムとして、知られている)によって特定されます。 クラス民数記はClass-ヌムオブジェクト(下が少し表す'b')の2高位のビットで決定する3つの範囲(128-191、および192-255の0-127)に広く分割されます。

   Note: the first 32-bit word of an Object whose Class-Num or Class-
   Type is from the Vendor Private range MUST be that vendor's SMI
   enterprise code in network octet order (these enterprise codes can be
   obtained from, and registered with, IANA).  An implementation
   encountering a Vendor Private object with an SMI enterprise code that
   it does not recognize MUST treat that object (and enclosing message)
   based on the Class-Num, as specified in [RSVP], section 3.10.

以下に注意してください。 Class-ヌムかClassタイプがVendor兵士の範囲から来ているObjectの最初の32ビットの単語はネットワーク八重奏命令でそのベンダーのSMI企業コードであるに違いありません(IANAはこれらの企業コードに入手できて、登録されました)。 それが認識しないSMI企業コードでVendor兵士のオブジェクトに遭遇する実装はClass-ヌムに基づくそのオブジェクト(メッセージを同封して)を扱わなければなりません、[RSVP]で指定されるように、セクション3.10。

      o  Class-Num = 0bbbbbbb

o クラスヌムは0bbbbbbbと等しいです。

         Class Numbers from 0 through 119 are to be assigned by
         Standards Action.  Class Numbers from 120 through 123 are to be
         assigned by Expert Review.  Class Numbers from 124 through 127
         are reserved for Vendor Private Use.

0〜119のクラス民数記はStandards Actionによって割り当てられることです。 120〜123のクラス民数記はExpert Reviewによって割り当てられることです。 124〜127のクラス民数記はVendor兵士のUseのために予約されます。

      o  Class-Num = 10bbbbbb

o クラスヌムは10bbbbbbと等しいです。

         Class Numbers from 128 through 183 are to be assigned by
         Standards Action.  Class Numbers from 184 through 187 are to be
         assigned by Expert Review.  Class Numbers from 188 through 191
         are reserved for Vendor Private Use.

128〜183のクラス民数記はStandards Actionによって割り当てられることです。 184〜187のクラス民数記はExpert Reviewによって割り当てられることです。 188〜191のクラス民数記はVendor兵士のUseのために予約されます。

Kompella & Lang          Best Current Practice                  [Page 3]

RFC 3936             Procedures for Modifying RSVP          October 2004

2004年10月にRSVPを変更するためのKompellaとラング最も良い現在の習慣[3ページ]RFC3936手順

      o  Class-Num = 11bbbbbb

o クラスヌムは11bbbbbbと等しいです。

         Class Numbers from 192 through 247 are to be assigned by
         Standards Action.  Class Numbers from 248 through 251 are to be
         assigned by Expert Review.  Class Numbers from 252 through 255
         are reserved for Vendor Private Use.

192〜247のクラス民数記はStandards Actionによって割り当てられることです。 248〜251のクラス民数記はExpert Reviewによって割り当てられることです。 252〜255のクラス民数記はVendor兵士のUseのために予約されます。

2.3.  Class Types

2.3. クラスタイプ

   Within each object class there is an 8-bit Class Type (also known as
   a C-Type).  Class Types are scoped to a Class Number.  In general,
   the appropriateness of allowing assignments of Class Types through
   Expert Review or Vendor Private depends on the semantics of the Class
   Number itself.  Thus, any new Class Number definition must specify an
   appropriate IANA Considerations policy for assigning additional Class
   Type values.

中では、そこのそれぞれのオブジェクトのクラスが8ビットのClass Type(また、C-タイプとして、知られている)です。 クラスTypesはClass Numberにおいて見られます。 一般に、Expert ReviewかVendor兵士にClass Typesの課題の通ることを許す適切さはClass Number自身の意味論によります。 したがって、どんな新しいClass Number定義も追加Class Type値を割り当てるための適切なIANA Considerations方針を指定しなければなりません。

   For Class Numbers that pre-date this document (specifically, 0, 1,
   3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the
   default assignment policy for new Class Types is Standards Action,
   unless a Standards Track or Best Current Practice RFC supercedes
   this.

このドキュメントより前に起こるClass民数記、(3-25 30-37 42-45 0、明確に1、64、65、新しいClass Typesのための128-131、161-165、192-196、および207、)デフォルト課題方針がStandards Actionである、Standards TrackかBest Current Practice RFC supercedes、これ。

2.3.1.  Sub-objects

2.3.1. サブオブジェクト

   Within an object, sub-objects may be defined, generally as a Type-
   Length-Value triple.  This memo defines the assignment policies for
   sub-objects of EXPLICIT_ROUTE and RECORD_ROUTE.  An RFC defining new
   sub-objects MUST state how IANA is to assign the sub-object Types.

オブジェクトの中では、サブオブジェクトは一般に、Type長さ価値が3倍になると定義されるかもしれません。 このメモはEXPLICIT_ROUTEとRECORD_ROUTEのサブオブジェクトのために課題方針を定義します。 新しいサブオブジェクトを定義するRFCはIANAがサブオブジェクトTypesを割り当てることになっている方法を述べなければなりません。

   The EXPLICIT_ROUTE object [RSVP-TE] carries a variable length sub-
   object that is identified by a 7-bit Type field.  Types 0 through 119
   are to be assigned by Standards Action.  Types 120 through 123 are to
   be assigned by Expert Review.  Types 124 through 127 are to be
   reserved for Vendor Private Use.

EXPLICIT_ROUTEオブジェクト[RSVP-TE]は7ビットのType分野によって特定される可変長サブオブジェクトを運びます。 タイプ0〜119はStandards Actionによって選任されることになっています。 タイプ120〜123はExpert Reviewによって選任されることになっています。 タイプ124〜127はVendor兵士のUseのために予約されることになっています。

   The RECORD_ROUTE object [RSVP-TE] carries a variable length sub-
   object that is identified by an 8-bit Type field.  Types 0 through
   191 are to be assigned by Standards Action.  Types 192 through 251
   are to be assigned by Expert Review.  Types 252 through 255 are to be
   reserved for Vendor Private Use.

RECORD_ROUTEオブジェクト[RSVP-TE]は8ビットのType分野によって特定される可変長サブオブジェクトを運びます。 タイプ0〜191はStandards Actionによって選任されることになっています。 タイプ192〜251はExpert Reviewによって選任されることになっています。 タイプ252〜255はVendor兵士のUseのために予約されることになっています。

   The first four octets of the sub-object contents of a Vendor Private
   sub-object of an EXPLICIT_ROUTE or RECORD_ROUTE object MUST be that
   vendor's SMI enterprise code in network octet order.

EXPLICIT_ROUTEかRECORD_ROUTEオブジェクトのVendor兵士のサブオブジェクトのサブオブジェクトコンテンツの最初の4つの八重奏がネットワーク八重奏命令でそのベンダーのSMI企業コードであるに違いありません。

Kompella & Lang          Best Current Practice                  [Page 4]

RFC 3936             Procedures for Modifying RSVP          October 2004

2004年10月にRSVPを変更するためのKompellaとラング最も良い現在の習慣[4ページ]RFC3936手順

2.4.  Virtual Destination Ports

2.4. 仮想の仕向港

   Virtual destination ports are described in [RSVP-IPSEC], which also
   specifies how IANA assignments are to be made.

仮想の仕向港は[RSVP-IPSEC]で説明されます。(また、それは、作られているIANA課題がことである方法を指定します)。

2.5.  Error Codes and Values

2.5. エラーコードと値

   An Error Code is an 8-bit quantity that appears in an ERROR_SPEC
   object to broadly define an error condition.  With each Error Code
   there may be a 16-bit Error Value that further specifies the cause of
   the error.  Error Value may be globally defined, in which case the
   sub-code component is assigned by IANA.

Error Codeはエラー条件を広く定義するERROR_SPECオブジェクトに現れる8ビットの量です。 各Error Codeと共に、さらに誤りの原因を指定する16ビットのError Valueがあるかもしれません。 誤りValueはグローバルに定義されるかもしれません、その場合、サブコードコンポーネントがIANAによって割り当てられます。

   Error Code values from 0 through 239 are to be assigned by Standards
   Action.  Values from 240 through 251 are to be assigned by Expert
   Review.  Values from 252 through 255 are reserved for Vendor Private
   Use.  If the Error Code is for Vendor Private Use, the first four
   octets following the Error Value MUST be the vendor's SMI enterprise
   code in network octet order.

0〜239の誤りCode値はStandards Actionによって割り当てられることです。 240〜251の値はExpert Reviewによって割り当てられることです。 252〜255の値はVendor兵士のUseのために予約されます。 Error CodeがVendor兵士のUseのためのものであるなら、Error Valueに続く最初の4つの八重奏がネットワーク八重奏命令でベンダーのSMI企業コードであるに違いありません。

   Globally defined Error Values are assigned by Standards Action.

グローバルに定義されたError ValuesはStandards Actionによって割り当てられます。

3.  Modifying RSVP Procedures

3. RSVP手順を変更します。

   RSVP entities have associated procedures describing when and how they
   are to be sent, received, processed, and responded to.  A change to a
   procedure that affects the processing of an RSVP entity that belongs
   to a range designated "Standards Action" MUST be documented in a
   Standards Track RFC.  A change to a procedure that affects the
   processing of an RSVP entity that belongs to a range designated
   "Expert Review" MUST be documented in an Experimental RFC.

RSVP実体は、関連手順がいつ、それらが送られることになっている方法を説明するか、そして、受け取られて、処理されて、応答されるのをさせます。 「規格動作」に指定された範囲に属すRSVP実体の処理に影響する手順への変化をStandards Track RFCに記録しなければなりません。 「専門のレビュー」に指定された範囲に属すRSVP実体の処理に影響する手順への変化をExperimental RFCに記録しなければなりません。

4.  Acknowledgements

4. 承認

   Many thanks to Scott Bradner, who encouraged this project, and made
   several helpful comments and suggestions.

スコット・ブラドナーをありがとうございます。(ブラドナーは、このプロジェクトを奨励して、いくつかの役に立つコメントと提案をしました)。

5.  Security Considerations

5. セキュリティ問題

   It is hoped that the procedures outlined in this memo will ensure
   that changes made to RSVP will be better reviewed and thus more
   architecturally sound, thereby enhancing the security both of the
   protocol and of networks deploying it.

このメモに概説された手順がRSVPにされた変更が好評であることを確実にして、その結果、より建築上、鳴ることが望まれています、その結果、プロトコルとそれを配布するネットワークのセキュリティを高めます。

6.  IANA Considerations

6. IANA問題

   See section 2.

セクション2を見てください。

Kompella & Lang          Best Current Practice                  [Page 5]

RFC 3936             Procedures for Modifying RSVP          October 2004

2004年10月にRSVPを変更するためのKompellaとラング最も良い現在の習慣[5ページ]RFC3936手順

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RSVP]       Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
                S. Jamin, "Resource ReSerVation Protocol (RSVP) --
                Version 1 Functional Specification", RFC 2205, September
                1997.

[RSVP]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。

   [RSVP-TE]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。

7.2.  Informative References

7.2. 有益な参照

   [ENT]        IANA PRIVATE ENTERPRISE NUMBERS,
                http://www.iana.org/assignments/enterprise-numbers

[ENT]IANA私企業番号、 http://www.iana.org/assignments/enterprise-numbers

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

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

   [RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
                Data Flows", RFC 2207, September 1997.

[RSVP-IPSEC] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。

8.  Authors' Addresses

8. 作者のアドレス

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089 USA

Kireeti Kompella杜松は1194N.マチルダ・Aveカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。

   EMail:  kireeti@juniper.net

メール: kireeti@juniper.net

   Jonathan P. Lang
   Rincon Networks

ジョナサンP.ラングリンコンネットワーク

   EMail:  jplang@ieee.org

メール: jplang@ieee.org

Kompella & Lang          Best Current Practice                  [Page 6]

RFC 3936             Procedures for Modifying RSVP          October 2004

2004年10月にRSVPを変更するためのKompellaとラング最も良い現在の習慣[6ページ]RFC3936手順

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

   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 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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

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

   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機能のための基金は現在、インターネット協会によって提供されます。

Kompella & Lang          Best Current Practice                  [Page 7]

KompellaとラングBest現在の習慣[7ページ]