RFC4558 日本語訳

Network Working Group                                             Z. Ali
Request for Comments: 4558                                     R. Rahman
Category: Standards Track                                     D. Prairie
                                                           Cisco Systems
                                                        D. Papadimitriou
                                                                 Alcatel
                                                               June 2006

コメントを求めるワーキンググループZ.アリ要求をネットワークでつないでください: 4558年のR.ラーマンカテゴリ: 標準化過程D.大草原シスコシステムズD.Papadimitriouアルカテル2006年6月

       Node-ID Based Resource Reservation Protocol (RSVP) Hello:
                       A Clarification Statement

Node IDが資源予約プロトコル(RSVP)を基礎づけた、こんにちは: 明確化声明

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 Internet Society (2006).

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

Abstract

要約

   Use of Node-ID based Resource Reservation Protocol (RSVP) Hello
   messages is implied in a number of cases, e.g., when data and control
   planes are separated, when TE links are unnumbered.  Furthermore,
   when link level failure detection is performed by some means other
   than exchanging RSVP Hello messages, use of a Node-ID based Hello
   session is optimal for detecting signaling adjacency failure for
   Resource reSerVation Protocol-Traffic Engineering (RSVP-TE).
   Nonetheless, this implied behavior is unclear, and this document
   formalizes use of the Node-ID based RSVP Hello session in some
   scenarios.  The procedure described in this document applies to both
   Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   capable nodes.

こんにちは、メッセージはそうです。Node-IDの使用がResource予約プロトコル(RSVP)を基礎づけた、例えば、データと制御飛行機が切り離されるときの多くの場合では、暗示しています。(その時、TEリンクは無数です)。 RSVP Helloメッセージを交換するのを除いて、リンク・レベル失敗検出がどうでも実行されるとき、その上、Resource reSerVationプロトコル交通Engineering(RSVP-TE)のためにシグナリング隣接番組失敗を検出するのに、ベースのNode-ID Helloセッションの使用は最適です。 それにもかかわらず、この暗示している振舞いは不明瞭です、そして、このドキュメントはいくつかのシナリオにおけるベースのNode-ID RSVP Helloセッションの使用を正式にします。 本書では説明された手順はMulti-プロトコルLabel Switching(MPLS)とGeneralized MPLS(GMPLS)のできるノードの両方に適用されます。

Ali, et al.                 Standards Track                     [Page 1]

RFC 4558                Node-ID Based RSVP Hello               June 2006

アリ、他 標準化過程[1ページ]RFC4558Node IDはこんにちは、2006年6月にRSVPを基礎づけました。

1.  Introduction

1. 序論

   The RSVP Hello message exchange was introduced in [RFC3209].  The
   usage of RSVP Hello has been extended in [RFC3473] to support RSVP
   Graceful Restart (GR) procedures.

[RFC3209]でRSVP Hello交換処理を導入しました。 RSVP Graceful Restart(GR)手順を支持するために[RFC3473]でRSVP Helloの使用法を広げてあります。

   More specifically, [RFC3473] specifies the use of the RSVP Hello
   messages for GR procedures for Generalized MPLS (GMPLS).  GMPLS
   introduces the notion of control plane and data plane separation.  In
   other words, in GMPLS networks, the control plane information is
   carried over a control network whose end-points are IP capable and
   that may be physically or logically disjoint from the data bearer
   links it controls.  One of the consequences of separation of data
   bearer links from control channels is that RSVP Hello messages are
   not terminated on data bearer links' interfaces even if (some of)
   those are numbered.  Instead, RSVP Hello messages are terminated at
   the control channel (IP-capable) end-points.  The latter MAY be
   identified by the value assigned to the node hosting these control
   channels, i.e., Node-ID.  Consequently, the use of RSVP Hello
   messages for GR applications introduces a need for clarifying the
   behavior and usage of Node-ID based Hello sessions.

より明確に、[RFC3473]はRSVP HelloメッセージのGR手順の使用をGeneralized MPLS(GMPLS)に指定します。 GMPLSは制御飛行機とデータ修正面分離の概念を紹介します。 言い換えれば、GMPLSネットワークでは、コントロール飛行機情報は物理的にであるエンドポイントができるIPであり、それが制御するデータ運搬人リンクから論理的にばらばらになるかもしれない規制ネットワークの上まで運ばれます。 制御チャンネルからのデータ運搬人リンクの分離の結果の1つがRSVP Helloメッセージがデータ運搬人リンクのインタフェースで終えられないということである、(いくつか、)、それらは番号付です。 代わりに、RSVP Helloメッセージは制御チャンネルで終えられた(IPできる)エンドポイントです。 後者はこれらの制御チャンネル、すなわち、Node-IDを接待するノードに割り当てられた値によって特定されるかもしれません。 その結果、RSVP HelloメッセージのGRアプリケーションの使用は基づくNode-ID Helloセッションの振舞いと用法をはっきりさせる必要性を導入します。

   Even in the case of packet switching capable interfaces, when link
   failure detection is performed by some means other than RSVP Hello
   messages (e.g., [BFD]), the use of Node-ID based Hello sessions is
   also optimal for detection of signaling adjacency failures for
   GMPLS-RSVP-TE and RSVP-TE when there is more than one link between a
   pair of nodes.  Similarly, when all TE links between neighbor nodes
   are unnumbered, it is implied that the nodes will exchange Node-ID
   based Hello messages for detection of signaling adjacency failures.
   This document also clarifies the use of Node-ID based Hello message
   exchanges when all or a sub-set of TE links are unnumbered.

また、RSVP Helloメッセージ(例えば、[BFD])を除いて、リンク失敗検出がどうでも実行されるときのパケット交換のできるインタフェースの場合ではさえ、1組のノードの間に1個以上のリンクがあるとき、シグナリング隣接番組失敗の検出に、基づくNode-ID Helloセッションの使用もGMPLS-RSVP-TEとRSVP-TEのために最適です。 隣人ノードの間のすべてのTEリンクが無数であるときに、同様に、ノードがシグナリング隣接番組失敗の検出への基づくNode-ID Helloメッセージを交換するのが含意されます。 また、TEリンクのすべてか部分集合が無数であるときに、このドキュメントは基づくNode-ID Hello交換処理の使用をはっきりさせます。

2.  Terminology

2. 用語

   Node-ID: TE Router ID as advertised in the Router Address TLV for
   OSPF [OSPF-TE] and Traffic Engineering Router ID TLV for ISIS
   [ISIS-TE].  For IPv6, the Node-ID refers to the Router_IPv6_Address
   for OSPFv3 [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS
   [IS-ISv6-TE].

Node ID: OSPFのためのRouter Address TLV[OSPF-TE]とイシスのためのTraffic Engineering Router ID TLV[イシス-TE]の広告に掲載されているTE Router ID。 IPv6、Node-IDが_RouterのOSPFv3[OSPFv3-TE]のためのIPv6_AddressとIPv6 TE Router_IDを参照する、-、[-、ISv6-TE、]

   Node-ID based Hello Session: A Hello session in which local and
   remote Node-IDs are used in the source and destination fields of the
   Hello packet, respectively.

Node IDはHello Sessionを基礎づけました: それぞれ地方の、そして、リモートなNode-IDがHelloパケットのソースとあて先フィールドで使用されるHelloセッション。

   Interface bounded Hello Session: A Hello session in which local and
   remote addresses of the interface in question are used in the source
   and destination fields of the Hello packet, respectively.

境界があるHello Sessionを連結してください: それぞれ問題のインタフェースの地方の、そして、リモートなアドレスがHelloパケットのソースとあて先フィールドで使用されるHelloセッション。

Ali, et al.                 Standards Track                     [Page 2]

RFC 4558                Node-ID Based RSVP Hello               June 2006

アリ、他 標準化過程[2ページ]RFC4558Node IDはこんにちは、2006年6月にRSVPを基礎づけました。

2.1.  Conventions Used in This Document

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

   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 RFC 2119 [RFC2119].

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

3.  Node-ID Based RSVP Hello Messages

3. Node IDがRSVPを基礎づけた、こんにちは、メッセージ

   A Node-ID based Hello session is established through the exchange of
   RSVP Hello messages such that local and remote Node-IDs are
   respectively used in the source and destination fields of Hello
   packets.  Here, for IPv4, Node-ID refers to the TE router-id as
   defined in the Router Address TLV for OSPF [OSPF-TE] and the Traffic
   Engineering router ID TLV for ISIS [ISIS-TE].  For IPv6, the Node-ID
   refers to the Router_IPv6_Address for OSPFv3 [OSPFv3-TE] and the IPv6
   TE Router_ID for IS-IS [IS-ISv6-TE].  This section formalizes a
   procedure for establishing Node-ID based Hello sessions.

ベースのNode-ID HelloセッションがRSVP Helloメッセージの交換を通して確立されるので、地方の、そして、リモートなNode-IDはHelloパケットのソースとあて先フィールドでそれぞれ使用されます。 ここと、IPv4に関して、Node-IDはイシス[イシス-TE]についてOSPF[OSPF-TE]とTraffic EngineeringルータID TLVのためにRouter Address TLVで定義されるTEルータイドを呼びます。 IPv6、Node-IDが_RouterのOSPFv3[OSPFv3-TE]のためのIPv6_AddressとIPv6 TE Router_IDを参照する、-、[-、ISv6-TE、] このセクションは基づくNode-ID Helloセッションを確立するための手順を正式にします。

   If a node wishes to establish a Node-ID based RSVP Hello session with
   its neighbor, it sends a Hello message with its Node-ID in the source
   IP address field of the Hello packet.  Furthermore, the node also
   puts the neighbor's Node-ID in the destination address field of the
   IP packet.

ノードが隣人とのベースのNode-ID RSVP Helloセッションを確立したいなら、Node-IDがHelloパケットのソースIPアドレス・フィールドにある状態で、それはHelloメッセージを送ります。 その上、また、ノードはIPパケットの目的地アドレス・フィールドに隣人のNode-IDを置きます。

   When a node receives a Hello packet where the destination IP address
   is its local Node-ID as advertised in the IGP-TE topology, the node
   MUST use its Node-ID in replying to the Hello message.  In other
   words, nodes MUST ensure that the Node-IDs used in RSVP Hello
   messages are those derived/contained in the IGP-TE topology.
   Furthermore, a node can only run one Node-ID based RSVP Hello session
   per IGP instance (i.e., per Node-ID pair) with its neighbor.

ノードがIGP-TEトポロジーの広告に掲載されているように送付先IPアドレスが地方のNode-IDであるところでHelloパケットを受けるとき、ノードはHelloメッセージに答える際にNode-IDを使用しなければなりません。 言い換えれば、ノードは、RSVP Helloメッセージで使用されるNode-IDがIGP-TEトポロジーに引き出されるか、または保管されていたものであることを確実にしなければなりません。 その上、ノードは隣人と共に1つの1IGPあたりのRSVP Helloセッションのときに基づいたNode-ID例(すなわち、Node-ID組あたりの)しか走らせることができません。

   Even in the case of packet switching capable interfaces, when link
   failure detection is performed by some means other than exchanging
   RSVP Hello messages, use of Node-ID based Hello sessions is also
   optimal in detecting signaling adjacency failures for GMPLS-RSVP-TE
   and RSVP-TE when there is more than one link between a pair of nodes.
   Similarly, if all interfaces between a pair of nodes are unnumbered,
   the optimal way to use RSVP to detect signaling adjacency failure is
   to run Node-ID based Hello sessions.  Furthermore, in the case of an
   optical network with single or multiple numbered or unnumbered
   control channels, use of Node-ID based Hello messages for detecting
   signaling adjacency failure is also optimal.  Therefore, when link
   failure detection is performed by some means other than exchanging
   RSVP Hello messages, or if all interfaces between a pair of nodes are
   unnumbered, or in a GMPLS network with data and control plane
   separation, a node MUST run Node-ID based Hello sessions for
   detection of signaling adjacency failure for RSVP-TE.  Nonetheless,

また、RSVP Helloメッセージを交換するのを除いて、リンク失敗検出がどうでも実行されるときのパケット交換のできるインタフェースの場合ではさえ、基づくNode-ID Helloセッションの使用も1組のノードの間に1個以上のリンクがあるときGMPLS-RSVP-TEとRSVP-TEのためにシグナリング隣接番組失敗を検出するのにおいて最適です。 同様に、シグナリング隣接番組失敗を検出するのにRSVPを使用する最善の方法は1組のノードの間のすべてのインタフェースが無数であるなら、基づくNode-ID Helloセッションを走らせることです。 その上、単一であるか複数の番号付の、または、無数の制御チャンネルがある光学ネットワークの場合では、Node-IDの使用は検出へのメッセージがまた、最適であることを隣接番組失敗に示すHelloを基礎づけました。 したがって、リンク失敗検出がいついくつかによって実行されるかがRSVP Helloを交換するのを除いて、メッセージかそれとも1組のノードの間のすべてのインタフェースが無数であるかどうかを意味するか、またはデータとコントロール飛行機分離があるGMPLSネットワークでは、ノードはRSVP-TEのためにシグナリング隣接番組失敗の検出のための基づくNode-ID Helloセッションを述べなければなりません。 それにもかかわらず

Ali, et al.                 Standards Track                     [Page 3]

RFC 4558                Node-ID Based RSVP Hello               June 2006

アリ、他 標準化過程[3ページ]RFC4558Node IDはこんにちは、2006年6月にRSVPを基礎づけました。

   if it is desirable to distinguish between signaling adjacency and
   link failures, Node-ID based Hello sessions can co-exist with the
   exchange of interface bound Hellos messages.  Similarly, if a pair of
   nodes share numbered and unnumbered TE links, Node-ID and interface
   based Hello sessions can co-exist.

それが望ましいなら、シグナリング隣接番組を見分けて、失敗、ベースのHelloセッションが共存できるNode-IDをリンクするために、インタフェースの交換はハローズメッセージを縛りました。 同様に、1組のノードが番号付の、そして、無数のTEリンク、Node-ID、およびインタフェースを共有するなら、ベースのHelloセッションは共存できます。

4.  Backward Compatibility Note

4. 後方の互換性注意

   The procedure presented in this document is backward compatible with
   both [RFC3209] and [RFC3473].

本書では提示された手順は[RFC3209]と[RFC3473]の両方と互換性があった状態で後方です。

   Per [RFC3209], the Hello mechanism is intended for use between
   immediate neighbors, and Hello messages are by default sent between
   direct RSVP neighbors.  This document does not modify this behavior,
   as it uses as "local node_id" the IPv4/IPv6 source address of the
   sending node and as "remote node_id" the IPv4/IPv6 destination
   address of the neighbor node.  TTL/Hop Limit setting and processing
   are also left unchanged.

[RFC3209]に従ってすぐ隣の人の間の使用のためにHelloメカニズムを意図します、そして、デフォルトでダイレクトRSVP隣人の間にHelloメッセージを送ります。 このドキュメントはこの振舞いを変更しません、IPv4/IPv6ソースが記述する送付ノードの「ローカルのノード_イド」として「遠隔ノード_イド」として隣人ノードのIPv4/IPv6送付先アドレスを使用するとき。 また、TTL/ホップLimit設定と処理は変わりがないままにされます。

   Moreover, this document does not modify the use of Hello Processing
   for State Recovery as defined in Section 9.3 of [RFC3473] (including
   definition and processing of the RESTART_CAP object).

そのうえ、このドキュメントは[RFC3473]のセクション9.3で定義されるように(RESTART_CAP物の定義と処理を含んでいて)Hello Processingの州Recoveryの使用を変更しません。

5.  Security Considerations

5. セキュリティ問題

   As this document does not modify or extend the RSVP Hello messages
   exchange between immediate RSVP neighbors, it does not introduce new
   security considerations.

このドキュメントが即座のRSVP隣人の間のRSVP Helloメッセージ交換を変更もしませんし、広げてもいないのに従って、それは新しいセキュリティ問題を紹介しません。

   The security considerations pertaining to the original [RFC3209]
   remain relevant.  RSVP message security is described in [RFC2747] and
   provides Hello message integrity and authentication of the Node-ID
   ownership.

オリジナル[RFC3209]に関係するセキュリティ問題は関連していたままで残っています。 RSVPメッセージセキュリティは、[RFC2747]で説明されて、Node-ID所有権のHelloメッセージの保全と認証を提供します。

6.  Acknowledgements

6. 承認

   We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi
   Ayyangar, and Carol Iturralde for their useful comments and
   suggestions.

彼らの役に立つコメントと提案についてアンカZamfir、ジャン・ルイル・ルー、Arthi Ayyangar、およびキャロル・イトゥラルデに感謝申し上げます。

Ali, et al.                 Standards Track                     [Page 4]

RFC 4558                Node-ID Based RSVP Hello               June 2006

アリ、他 標準化過程[4ページ]RFC4558Node IDはこんにちは、2006年6月にRSVPを基礎づけました。

7.  Reference

7. 参照

7.1.  Normative References

7.1. 引用規格

   [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月。

   [RFC2747]    Baker, F., Lindell, B., and M. Talwar, "RSVP
                Cryptographic Authentication", RFC 2747, January 2000.

[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。

   [RFC3209]    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.

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

   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.

[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。

7.2.  Informative References

7.2. 有益な参照

   [OSPF-TE]    Katz, D., Kompella, K., and D. Yeung, "Traffic
                Engineering (TE) Extensions to OSPF Version 2", RFC
                3630, September 2003.

[OSPF-Te] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」

   [ISIS-TE]    Smit, H. and T. Li, "Intermediate System to Intermediate
                System (IS-IS) Extensions for Traffic Engineering (TE)",
                RFC 3784, June 2004.

[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)

   [BFD]        Katz, D. and D. Ward, "Bidirectional Forwarding
                Detection", Work in Progress.

[BFD] 「双方向の推進検出」というキャッツ、D.、およびD.区は進行中で働いています。

   [IS-ISv6-TE] Harrison, J., et al. "IPv6 Traffic Engineering in IS-
                IS", Work in Progress, November 2005.

[-、ISv6-TE、]、ハリソン、J.、他 「IPv6交通工学、中にある、」、11月2005、進行中で、働いてください。

   [OSPFv3-TE]  Ishiguro, K., et al. "Traffic Engineering Extensions to
                OSPF version 3", Work in Progress, April 2006.

[OSPFv3-TE] イシグロ、K.、他 Work、Engineering ExtensionsをOSPFにバージョン3インチ取引してください。「Progress、2006インチ年4月に。

Ali, et al.                 Standards Track                     [Page 5]

RFC 4558                Node-ID Based RSVP Hello               June 2006

アリ、他 標準化過程[5ページ]RFC4558Node IDはこんにちは、2006年6月にRSVPを基礎づけました。

Authors' Addresses

作者のアドレス

   Zafar Ali
   Cisco Systems Inc.
   100 South Main St. #200
   Ann Arbor, MI 48104, USA

アナーバー、Zafarのアリシスコシステムズ株式会社100の南Main聖#200MI 48104、米国

   Phone: (734) 276-2459
   EMail: zali@cisco.com

以下に電話をしてください。 (734) 276-2459 メールしてください: zali@cisco.com

   Reshad Rahman
   Cisco Systems Inc.
   2000 Innovation Dr.,
   Kanata, Ontario, K2K 3E8, Canada

Kanata、オンタリオK2K3E8、Reshadラーマンシスコシステムズ株式会社2000Innovation博士(カナダ)

   Phone: (613) 254-3519
   EMail: rrahman@cisco.com

以下に電話をしてください。 (613) 254-3519 メールしてください: rrahman@cisco.com

   Danny Prairie
   Cisco Systems Inc.
   2000 Innovation Dr.,
   Kanata, Ontario, K2K 3E8, Canada

Kanata、オンタリオK2K3E8、ダニー大草原シスコシステムズ株式会社2000Innovation博士(カナダ)

   Phone: (613) 254-3544
   EMail: dprairie@cisco.com

以下に電話をしてください。 (613) 254-3544 メールしてください: dprairie@cisco.com

   Dimitri Papadimitriou
   Alcatel
   Fr. Wellesplein 1,
   B-2018 Antwerpen, Belgium

ディミトリPapadimitriouアルカテルフラン。 Wellesplein1、B-2018アントウェルペン(ベルギー)

   Phone: +32 3 240-8491
   EMail: dimitri.papadimitriou@alcatel.be

以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be

Ali, et al.                 Standards Track                     [Page 6]

RFC 4558                Node-ID Based RSVP Hello               June 2006

アリ、他 標準化過程[6ページ]RFC4558Node IDはこんにちは、2006年6月にRSVPを基礎づけました。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

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

   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 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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Ali, et al.                 Standards Track                     [Page 7]

アリ、他 標準化過程[7ページ]