RFC4950 日本語訳
4950 ICMP Extensions for Multiprotocol Label Switching. R. Bonica, D.Gan, D. Tappan, C. Pignataro. August 2007. (Format: TXT=15091 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Bonica
Request for Comments: 4950 Juniper Networks
Category: Standards Track D. Gan
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
August 2007
Bonicaがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4950年の杜松はカテゴリをネットワークでつなぎます: 標準化過程D.ガンD.タッパンコンサルタントC.PignataroシスコシステムズInc.2007年8月
ICMP Extensions for Multiprotocol Label Switching
Multiprotocolラベルの切り換えのためのICMP拡張子
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed.
このメモは選択された複合ICMPメッセージに追加できる拡大物を定義します。 この拡大は、Label Switching RoutersがMPLS情報をICMPメッセージに追加することを許可して、既に広く配備されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . . 3
4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. MPLS Label Stack Object . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コンベンションは本書では.3 3を使用しました。 トレースルート. . . . . . . . . . . . . . . . . . . 3 4へのアプリケーション。 注意書き. . . . . . . . . . . . . . . . . . . . . . . . . . 3 5。 MPLSはスタック物. . . . . . . . . . . . . . . . . . . . 4 6をラベルします。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 6
Bonica, et al. Standards Track [Page 1] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[1ページ]。
1. Introduction
1. 序論
IP routers use the Internet Control Message Protocol, ICMPv4 [RFC0792] and ICMPv6 [RFC4443], to convey control information to source hosts. Network operators use this information to diagnose routing problems.
IPルータは、制御情報を送信元ホストに伝えるのに、インターネット・コントロール・メッセージ・プロトコル、ICMPv4[RFC0792]、およびICMPv6[RFC4443]を使用します。 ネットワーク・オペレータは、ルーティング問題を診断するのにこの情報を使用します。
When a router receives an undeliverable IP datagram, it can send an ICMP message to the host that originated the datagram. The ICMP message indicates why the datagram could not be delivered. It also contains the IP header and leading payload octets of the "original datagram" to which the ICMP message is a response.
ルータが「非-提出物」IPデータグラムを受けるとき、それはデータグラムを溯源したホストにICMPメッセージを送ることができます。 ICMPメッセージは、なぜデータグラムを届けることができなかったかを示します。 また、それはICMPメッセージが応答である「オリジナルのデータグラム」のIPヘッダーと主なペイロード八重奏を含んでいます。
MPLS Label Switching Routers (LSR) also use ICMP to convey control information to source hosts. Section 2.3 of [RFC3032] describes the interaction between MPLS and ICMP, and Sections 2.4 and 3 of [RFC3032] provide applications of that interaction.
また、MPLS Label Switching Routers(LSR)は、制御情報を送信元ホストに伝えるのにICMPを使用します。 [RFC3032]のセクション2.3はMPLSとICMPとの相互作用について説明します、そして、[RFC3032]のセクション2.4と3はその相互作用の利用を提供します。
When an LSR receives an undeliverable MPLS-encapsulated datagram, it removes the entire MPLS label stack, exposing the previously encapsulated IP datagram. The LSR then submits the IP datagram to an error processing module. Error processing can include ICMP message generation.
LSRがundeliverable MPLSによって要約されたデータグラムを受けるとき、全体のMPLSラベルスタックを取り除きます、以前に要約のIPデータグラムを露出して。 そして、LSRはエラー処理モジュールにIPデータグラムを提出します。 エラー処理はICMPメッセージ世代を含むことができます。
The ICMP message indicates why the original datagram could not be delivered. It also contains the IP header and leading octets of the original datagram.
ICMPメッセージは、なぜオリジナルのデータグラムを届けることができなかったかを示します。 また、それはオリジナルのデータグラムのIPヘッダーと主な八重奏を含んでいます。
The ICMP message, however, contains no information regarding the MPLS label stack that encapsulated the original datagram when it arrived at the LSR. This omission is significant because the LSR would have forwarded the original datagram based upon information contained by the MPLS label stack.
しかしながら、ICMPメッセージはLSRに到着したときオリジナルのデータグラムを要約したMPLSラベルスタックの情報を全く含んでいません。 LSRはMPLSラベルスタックによって含まれた情報に基づくオリジナルのデータグラムを進めたでしょう、したがって、この省略が重要です。
This memo defines an ICMP extension object that permits an LSR to append MPLS information to ICMP messages. Selected ICMP messages SHOULD include the MPLS label stack, as it arrived at the router that is sending the ICMP message. The ICMP message MUST also include the IP header and leading payload octets of the original datagram.
このメモはLSRがMPLS情報をICMPメッセージに追加するのを可能にするICMP拡大物を定義します。 選択されたICMPメッセージSHOULDはMPLSラベルスタックを含んでいます、ICMPメッセージを送るルータに到着したので。 また、ICMPメッセージはオリジナルのデータグラムのIPヘッダーと主なペイロード八重奏を含まなければなりません。
The ICMP extensions defined in this document must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
ICMP Extension Structure HeaderとICMP Object Headerは本書では定義されたICMP拡張子に先行しなければなりません。 両方が[RFC4884]で定義されます。
The ICMP extension defined in this document is equally applicable to ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. Throughout this document, unless otherwise specified, the acronym ICMP refers to multi-part ICMP messages, encompassing both ICMPv4 and ICMPv6.
本書では定義されたICMP拡張子は等しくICMPv4[RFC0792]とICMPv6[RFC4443]に適切です。 このドキュメント中では、ICMPv4とICMPv6の両方を取り囲んで、別の方法で指定されない場合、頭文字語ICMPは複合ICMPメッセージを示します。
Bonica, et al. Standards Track [Page 2] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[2ページ]。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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 RFC2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Application to TRACEROUTE
3. トレースルートへのアプリケーション
The ICMP extension defined in this memo supports enhancements to TRACEROUTE. Enhanced TRACEROUTE applications, like older implementations, indicate which nodes the original datagram visited en route to its destination. They differ from older implementations in that they also reflect the original datagram's MPLS encapsulation status as it arrived at each node.
このメモで定義されたICMP拡張子はTRACEROUTEに増進を支持します。 より古い実現のように、高められたTRACEROUTEアプリケーションは、オリジナルのデータグラムが目的地への途中でどのノードを訪問したかを示します。 彼らは各ノードに到着したのでオリジナルのデータグラムのMPLSカプセル化状態を反映するという点においても、より古い実現と異なっています。
Figure 1 contains sample output from an enhanced TRACEROUTE implementation.
図1は高められたTRACEROUTE実現からのサンプル出力を含んでいます。
> traceroute 192.0.2.1
>トレースルート192.0.2.1
traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 40 byte packets
192.0へのトレースルート、.2、.1、(192.0に、.1、)30が飛び越す.2は最大限にして、40バイトはパケットです。
1 192.0.2.13 (192.0.2.13) 0.661 ms 0.618 ms 0.579 ms
1 192.0 .2、.13、(192.0.2.13)0.661ms0.618ms0.579ms
2 192.0.2.9 (192.0.2.9) 0.861 ms 0.718 ms 0.679 ms
2 192.0 .2、.9、(192.0.2.9)0.861ms0.718ms0.679ms
MPLS Label=100048 Exp=0 TTL=1 S=1
MPLSラベル=100048Exp=0 TTL=1秒間=1
3 192.0.2.5 (192.0.2.5) 0.822 ms 0.731 ms 0.708 ms
3 192.0 .2、.5、(192.0.2.5)0.822ms0.731ms0.708ms
MPLS Label=100016 Exp=0 TTL=1 S=1
MPLSラベル=100016Exp=0 TTL=1秒間=1
4 192.0.2.1 (192.0.2.1) 0.961 ms 8.676 ms 0.875 ms
4 192.0 .2、.1、(192.0.2.1)0.961ms8.676ms0.875ms
Figure 1: Enhanced TRACEROUTE Sample Output
図1: 高められたトレースルートサンプル出力
4. Disclaimer
4. 注意書き
This memo does not define the general relationship between ICMP and MPLS. Section 2.3 of [RFC3032] defines this relationship.
このメモはICMPとMPLSとの一般的な関係を定義しません。 [RFC3032]のセクション2.3はこの関係を定義します。
The current memo does not define encapsulation-specific TTL (Time to Live) manipulation procedures. It defers to Section 5.4 of RFC 3034 [RFC3034] and Section 10 of [RFC3035] in this matter.
現在のメモはカプセル化特有のTTL(Liveへの時間)操作手順を定義しません。 それはこの件に関してRFC3034[RFC3034]のセクション5.4と[RFC3035]のセクション10に従います。
Bonica, et al. Standards Track [Page 3] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[3ページ]。
When encapsulation-specific TTL manipulation procedures defeat the basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE implementations.
また、カプセル化特有のTTL操作手順が基本的なTRACEROUTEメカニズムを破ると、彼らは高められたTRACEROUTE実現を破るでしょう。
5. MPLS Label Stack Object
5. MPLSラベルスタック物
The MPLS Label Stack Object can be appended to the ICMP Time Exceeded and Destination Unreachable messages. A single instance of the MPLS Label Stack Object represents the entire MPLS label stack, formatted exactly as it was when it arrived at the LSR that sends the ICMP message.
ICMP Time ExceededとDestination UnreachableメッセージにMPLS Label Stack Objectを追加できます。 MPLS Label Stack Objectのただ一つの例はちょうどそれがICMPメッセージを送るLSRに到着した時であるときにフォーマットされた全体のMPLSラベルスタックを表します。
Figure 2 depicts the MPLS Label Stack Object. It must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
図2はMPLS Label Stack Objectについて表現します。 ICMP Extension Structure HeaderとICMP Object Headerはそれに先行しなければなりません。 両方が[RFC4884]で定義されます。
In the object payload, octets 0-3 depict the first member of the MPLS label stack. Each remaining member of the MPLS label stack is represented by another 4 octets that share the same format.
物のペイロードでは、八重奏0-3は第1代MPLSラベルスタックのメンバーについて表現します。 MPLSラベルスタックのそれぞれの残っているメンバーは同じ形式を共有する別の4つの八重奏で代理をされます。
Class-Num = 1, MPLS Label Stack Class
C-Type = 1, Incoming MPLS Label Stack
Length = 4 + 4 * (number of MPLS LSEs)
クラスヌムは1、MPLSラベルスタッククラスC-タイプ=1、4+4入って来るMPLSラベルスタックの長さ=*と等しいです。(MPLS LSEsの数)
0 1 2 3
+-------------+-------------+-------------+-------------+
| Label |EXP |S| TTL |
+-------------+-------------+-------------+-------------+
| |
| // Remaining MPLS Label Stack Entries // |
| |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | ラベル|EXP|S| TTL| +-------------+-------------+-------------+-------------+ | | | //残っているMPLSラベルスタックエントリー//| | | +-------------+-------------+-------------+-------------+
Figure 2: MPLS Label Stack Object
図2: MPLSラベルスタック物
Label: 20 bits
以下をラベルしてください。 20ビット
Exp: Experimental Use, 3 bits
Exp: 実験的なUse、3ビット
S: Bottom of Stack, 1 bit
S: Stack、噛み付かれた1の下部
TTL: Time to Live, 8 bits
TTL: Liveへの時間、8ビット
Bonica, et al. Standards Track [Page 4] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[4ページ]。
6. Security Considerations
6. セキュリティ問題
This memo does not specify the conditions that trigger the generation of ICMP Messages for Labeled IP Packets. It does not define the interaction between MPLS and ICMP. However, this document defines an extension that allows an MPLS router to append MPLS information to multi-part ICMP messages, and therefore can provide the user of the TRACEROUTE application with additional information. Consequently, a network operator may wish to provide this information selectively based on some policy; for example, only include the MPLS extensions in ICMP messages destined to addresses within the network management blocks with administrative control over the router. An implementation could determine whether to include the MPLS Label Stack extensions based upon the destination address of the ICMP message, or based on a global configuration option in the router. Alternatively, an implementation may determine whether to include these MPLS extensions when TTL expires based on the number of label stack entries (depth of the label stack) of the incoming packet. Finally, an operator can make use of the TTL treatment on MPLS Pipe Model LSPs defined in [RFC3443] for a TTL-transparent mode of operation that would prevent ICMP Time Exceeded altogether when tunneled over the MPLS LSP.
このメモはICMP Messagesの世代の引き金となる状態をLabeled IP Packetsに指定しません。 それはMPLSとICMPとの相互作用を定義しません。 しかしながら、このドキュメントは、MPLSルータがMPLS情報を追加できる拡大を複合ICMPメッセージと定義して、したがって、TRACEROUTEアプリケーションのユーザに追加情報を提供できます。 その結果、ネットワーク・オペレータは選択的に何らかの方針に基づくこの情報を提供したがっているかもしれません。 例えば、ルータの上のネットワークマネージメントブロックの中の運営管理コントロールがあるアドレスに運命づけられたICMPメッセージで単にMPLS拡張子を含めてください。 実現は、ICMPメッセージの送付先アドレスに基づいているか、またはルータでグローバルな設定オプションに基づくMPLS Label Stack拡張子を含んでいるかどうか決定するかもしれません。 あるいはまた、実現は、TTLが入って来るパケットのラベルスタックエントリー(ラベルスタックの深さ)の数に基づいて期限が切れるとき、これらのMPLS拡張子を含んでいるかどうか決定するかもしれません。 最終的に、オペレータはMPLS LSPの上でトンネルを堀られると全体でICMP Time Exceededを防ぐ操作のTTL-透過モードのために[RFC3443]で定義されたMPLS Pipe Model LSPsでTTL処理を利用できます。
7. IANA Considerations
7. IANA問題
IANA has assigned the following object Class-num in the ICMP Extension Object registry:
IANAはICMP Extension Object登録で以下の物のClass-numを割り当てました:
Class-Num Description
1 MPLS Label Stack Class
クラスヌムの記述1MPLSラベルスタックのクラス
IANA has established a registry for the corresponding class sub-type (C-Type) space, as follows:
IANAは以下の通り対応するクラスサブタイプ(C-タイプ)スペースに登録を確立しました:
MPLS Label Stack Class Sub-types:
MPLSはスタッククラスサブタイプにレッテルを貼ります:
C-Type Description
0 Reserved
1 Incoming MPLS Label Stack
0x02-0xF6 Available for assignment
0xF7-0xFF Reserved for private use
私用のための課題0xF7-0xFF Reservedのための0×02 0xF6 AvailableのC-タイプ記述0Reserved1Incoming MPLS Label Stack
C-Type values are assignable on a first-come-first-serve (FCFS) basis [RFC2434].
C-タイプ値は最初に最初に役立ちに来ている(FCFS)ベース[RFC2434]で「割り当て-可能」です。
Bonica, et al. Standards Track [Page 5] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[5ページ]。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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月)。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] コンタ、A.、デアリング、S.、およびM.グプタ、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
2007年4月の[RFC4884]BonicaとR.とガンとD.とタッパン、D.とC.Pignataro、「複合メッセージを支持する拡張ICMP」RFC4884。
8.2. Informative References
8.2. 有益な参照
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[RFC3034] コンタ、A.、Doolan、P.、およびA.Malis、「フレームリレーにおけるラベルの切り換えの使用は仕様をネットワークでつなぎます」、RFC3034、2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
and ATM VC Switching", RFC 3035, January 2001.
[RFC3035] デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、G.、Rekhter、Y.、およびP.Doolan、「自由民主党と気圧VCの切り換えを使用するMPLS」、RFC3035(2001年1月)。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, January 2003.
[RFC3443]AgarwalとP.とB.Akyol、「生きるマルチプロトコルラベルスイッチング(MPLS)ネットワークで処理される時間(TTL)」、RFC3443、2003年1月。
Bonica, et al. Standards Track [Page 6] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[6ページ]。
Authors' Addresses
作者のアドレス
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
ロナルドP.Bonica杜松は米国でDriveハーンドン、2251の法人のParkヴァージニア 20171をネットワークでつなぎます。
EMail: rbonica@juniper.net
メール: rbonica@juniper.net
Der-Hwa Gan Consultant
Der-Hwaガンのコンサルタント
EMail: derhwagan@yahoo.com
メール: derhwagan@yahoo.com
Daniel C. Tappan Consultant
ダニエルC.タッパンコンサルタント
EMail: Dan.Tappan@gmail.com
メール: Dan.Tappan@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 US
カルロスPignataroシスコシステムズInc.7025キットクリーク道路リサーチトライアングル公園、NC27709米国
EMail: cpignata@cisco.com
メール: cpignata@cisco.com
Bonica, et al. Standards Track [Page 7] RFC 4950 ICMP MPLS August 2007
Bonica、他 規格はICMP MPLS2007年8月にRFC4950を追跡します[7ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bonica, et al. Standards Track [Page 8]
Bonica、他 標準化過程[8ページ]
一覧
スポンサーリンク
