Network Working Group E. Lear
Request for Comments: 4744 Cisco Systems
Category: Standards Track K. Crozier
December 2006
Using the NETCONF Protocol over
the Blocks Extensible Exchange Protocol (BEEP)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP).
この文書では、ブロック拡張可能交換プロトコル（BEEP）を超えるネットワーク構成プロトコル（NETCONF）のためのアプリケーションプロトコルのマッピングを指定します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Why BEEP? ..................................................2
2. BEEP Transport Mapping ..........................................2
2.1. NETCONF Session Establishment ..............................2
2.2. Starting a Channel for NETCONF .............................4
2.3. NETCONF Session Usage ......................................5
2.4. NETCONF Session Teardown ...................................5
2.5. BEEP Profile for NETCONF ...................................6
3. Security Considerations .........................................6
4. IANA Considerations .............................................7
5. Acknowledgments .................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
The NETCONF protocol [1] defines a simple mechanism through which a network device can be managed. NETCONF is designed to be usable over a variety of application protocols. This document specifies an application protocol mapping for NETCONF over the Blocks Extensible Exchange Protocol (BEEP) [7].
NETCONFプロトコル[1]は、ネットワークデバイスを管理することができるような単純なメカニズムを定義します。 NETCONFは、アプリケーションプロトコルの種々にわたって使用できるように設計されています。この文書は、ブロック拡張交換プロトコル（BEEP）上NETCONFのためのアプリケーションプロトコルのマッピングを指定する[7]。
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 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
Use of BEEP is natural as an application protocol for transport of XML. As a peer-to-peer protocol, BEEP provides an easy way to implement NETCONF, no matter which side of the connection was the initiator. This "bidirectionality" allows for either manager or agent to initiate a connection. This is particularly important to support large numbers of intermittently connected devices, as well as those devices that must reverse the management connection in the face of firewalls and network address translators (NATs).
BEEPを使用すると、XMLの輸送のためのアプリケーションプロトコルとして自然です。ピア・ツー・ピア・プロトコルとして、BEEPはNETCONFを実装する簡単な方法は、接続の側面は、イニシエータたどんなにを提供します。この「双方向性」とは、接続を開始するためにマネージャとエージェントのどちらが可能になります。これは、大きな断続的接続されたデバイスの数、ならびにファイアウォールおよびネットワークアドレス変換（NAT）の面内の管理接続を逆にする必要があり、それらのデバイスをサポートすることが特に重要です。
BEEP makes use of the Simple Authentication and Security Layer (SASL) [3]. The SASL profile used by BEEP allows for a simple and direct mapping to the existing security model for command line interface (CLI), while Transport Layer Security (TLS) [4] provides a strong, well-tested encryption mechanism with either server or server and client-side authentication.
BEEPは、簡易認証セキュリティー層（SASL）を使用しています[3]。トランスポート層セキュリティ（TLS）が[4]、サーバーまたはサーバーのいずれかとの強い、十分にテストされた暗号化メカニズムを提供しながら、BEEPが使用するSASLプロファイルは、コマンドラインインタフェース（CLI）のための既存のセキュリティモデルにシンプルかつ直接マッピングすることができますそして、クライアント側の認証。
All NETCONF over BEEP implementations MUST implement the profile and functional mapping between NETCONF and BEEP as described below.
以下に説明するようにBEEP実装上のすべてのNETCONFは、NETCONFとBEEP間プロファイルおよび機能のマッピングを実装しなければなりません。
For purposes of this document, a manager is a NETCONF client, and an agent is a NETCONF server. Use of client/server language in BEEP is avoided because of the common notion that in networking clients connect to servers.
このドキュメントの目的のために、マネージャはNETCONFクライアントであり、そしてエージェントはNETCONFサーバです。 BEEPで、クライアント/サーバー言語の使用は、ネットワークの中で、クライアントがサーバに接続することを共通概念で回避されます。
Managers may be either BEEP listeners or initiators. Similarly, agents may be either listeners or initiators. To establish a connection, the initiator connects to the listener on TCP port 831. Thus, the initial exchange takes place without regard to whether a manager or the agent is the initiator. After the transport connection is established, as greetings are exchanged, they SHOULD each announce their support for TLS and optionally SASL. Once BEEP greeting messages are exchanged, if TLS is to be used and available by both parties, the listener STARTs a channel with the TLS profile.
管理者は、BEEPリスナーまたはイニシエータのいずれであってもよいです。同様に、薬剤は、リスナーまたは開始剤のいずれであってもよいです。接続を確立するには、イニシエータは、このようにTCPポート831上のリスナーに接続し、初期の交換はマネージャまたはエージェントは、イニシエータであるかどうかに関係なく行われます。トランスポート接続が確立された後挨拶が交換されているように、彼らはそれぞれのTLSおよびオプションSASLのための彼らのサポートを発表すべきです。 BEEPのグリーティングメッセージが交換されるとTLSを使用し、両当事者によって利用できることがあれば、リスナーはTLSプロファイルを持つチャネルを開始します。
Once TLS has been started, a new BEEP greeting message is sent by both initiator and listener, as required by the BEEP RFC.
TLSが開始された後BEEPのRFCで要求されるよう、新しいBEEPあいさつメッセージは、イニシエータとリスナーの両方で送信されます。
After all BEEP greeting messages are exchanged in order for roles to be clear, the agent MUST advertise the NETCONF profile. The manager MUST NOT advertise the NETCONF profile. If the agent side of the communication (either initiator or listener) receives a BEEP <greeting> element that contains the NETCONF profile, it MUST close the connection. Similarly, if neither side issues a NETCONF profile it is equally an error, and the listener MUST close the connection.
すべてのBEEPのグリーティングメッセージは役割が明確になるようにするために交換された後、エージェントはNETCONFプロフィールを宣伝しなければなりません。マネージャは、NETCONFプロフィールを宣伝してはなりません。通信（イニシエータまたはリスナーのいずれか）のエージェント側はNETCONFのプロファイルを含むBEEP <挨拶>要素を受信した場合、それは接続を閉じなければなりません。どちらの側がNETCONFプロファイルを発行した場合も同様に、それは均等エラーであり、リスナーは接続を閉じなければなりません。
At this point, if SASL is desired, the initiator starts a BEEP channel to perform a SASL exchange to authenticate itself. Upon completion of authentication the channel is closed. That is, the channel is exclusively used to authenticate.
この時点で、SASLが所望される場合、開始剤は、それ自体を認証するSASL交換を実行するBEEPチャンネルを開始します。認証が完了すると、チャネルが閉じられます。これは、チャネルが独占的に認証するために使用されています。
Examples of both TLS and SASL profiles can be found in [7].
両方のTLSとSASLプロファイルの例は、[7]に見出すことができます。
It is anticipated that the SASL PLAIN mechanism will be heavily used in conjunction with TLS [5]. In such cases, in accordance with RFC 2595 the PLAIN mechanism MUST NOT be advertised in the first BEEP <greeting>, but only in the one following a successful TLS negotiation. This applies only if TLS and SASL PLAIN mechanisms are both to be used. To avoid risk of eavesdropping, the SASL PLAIN mechanism MUST NOT be used over unencrypted channels. More specifics about the use of SASL and TLS are mentioned in Security Considerations below.
SASL PLAIN機構が重くTLSと併せて使用されることが予想される[5]。このような場合には、RFC 2595に従ってPLAINメカニズムは<挨拶>最初のBEEPで広告が、唯一の成功TLSネゴシエーション以下の1にあってはなりません。これは、TLSとSASL PLAINメカニズムが両方使用されるようにしている場合にのみ適用されます。盗聴の危険性を回避するために、SASL PLAINメカニズムは暗号化されていないチャネル上で使用してはいけません。 SASLとTLSの使用についての詳細詳細は以下のセキュリティの考慮事項に記載されています。
Once authentication has occurred, there is no need to distinguish between initiator and listener. We now distinguish between manager and agent, and it is assumed that each knows its role in the conversation.
認証が発生した後は、イニシエータとリスナーを区別する必要はありません。私たちは今、マネージャとエージェントを区別し、それぞれが会話の中でその役割を知っていることが想定されます。
The manager now establishes a new channel and specifies the single NETCONF profile. For example:
マネージャーは今、新たなチャネルを確立し、単一NETCONFプロファイルを指定します。例えば：
(M = Manager; A = Agent)
（M =マネージャー; A =エージェント）
M: MSG 0 1 . 10 48 118 M: Content-type: application/beep+xml M: M: <start number="1"> M: <profile uri="http://iana.org/beep/netconf" /> M: </start> M: END A: RPY 0 1 . 38 87 A: Content-Type: application/beep+xml A: A: <profile uri="http://iana.org/beep/netconf" /> A: END
M：MSG 0 1。 10 48 118 M：コンテンツタイプ：アプリケーション/ビープ+ XMLのM：M：<開始番号= "1"> M <プロファイルURI = "http://iana.org/beep/netconf" /> M < ENDのA：RPY 0 1 /> Mを起動します。 38 87 A：コンテンツタイプ：アプリケーション/ビープ音+ xmlのA：A：<プロファイルのuri = "http://iana.org/beep/netconf" /> A：END
At this point, we are ready to proceed on BEEP channel 1 with NETCONF operations.
この時点で、我々は、NETCONF操作でBEEPチャンネル1に進む準備ができました。
NETCONF messages are transmitted with a Content-type header set to "text/xml".
NETCONFメッセージは、「テキスト/ XML」に設定Content-Typeヘッダで送信されます。
Next the manager and the agent exchange NETCONF <hello> elements on the new channel so that each side learns the other's capabilities. This occurs through a MSG. Each side will then respond positively. The following example is adapted from [1] Section 8.1:
それぞれの側には、相手の能力を学習し、マネージャとエージェントの交換NETCONF新しいチャネル上の<こんにちは>要素の次のようにします。これはMSGを介して行われます。各側はその後、積極的に対応します。以下の例は、[1]のセクション8.1から適合されています。
A: MSG 1 0 . 0 457
A: Content-type: application/beep+xml
A:
A: <?xml version='1.0' encoding="UTF-8"?>
A: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
A: <capabilities>
A: <capability>
A: urn:ietf:params:netconf:base:1.0
A: </capability>
A: <capability>
A: urn:ietf:params:netconf:capability:startup:1.0
A: </capability>
A: <capability>
A: http://example.net/router/2.3/core#myfeature
A: </capability>
A: </capabilities>
A: <session-id>4</session-id> A: </hello> A: END
<セッションID> 4 </セッションID> A </こんにちは> A：END
M: RPY 1 0 . 0 0 M: END
M：RPY 1 0。 0 0 M：END
Future NETCONF capabilities may require additional BEEP channels. When such capabilities are defined, a BEEP mapping must be defined as well.
将来のNETCONFの機能が追加BEEPチャンネルを必要とするかもしれません。そのような能力が定義されている場合は、BEEPマッピングも同様に定義する必要があります。
At this point, the NETCONF session is established, and capabilities have been exchanged.
この時点で、NETCONFセッションが確立され、機能が交換されました。
Nearly all NETCONF operations are executed through the <rpc> element. To issue a remote procedure call (RPC), the manager transmits on the operational channel a BEEP MSG containing the RPC and its arguments. In accordance with the BEEP standard, RPC requests may be split across multiple BEEP frames.
ほぼすべてのNETCONFの操作は、<RPC>要素を介して実行されています。リモートプロシージャコール（RPC）を発行するために、管理者は、動作チャンネルにRPCとその引数を含むBEEPのMSGを送信します。 BEEP規格に従って、RPC要求は、複数のBEEPフレームに分割されてもよいです。
Once received and processed, the agent responds with BEEP RPY messages on the same channel with the response to the RPC. In accordance with the BEEP standard, responses may be split across multiple BEEP frames.
一度受信および処理、エージェントがRPCへの応答と同じチャネル上のBEEP RPYメッセージで応答します。 BEEP規格に従って、応答は、複数のBEEPフレームに分割されてもよいです。
Upon receipt of <close-session> from the manager, once the agent has completed all RPCs, it will close BEEP channel 0. When an agent needs to initiate a close, it will do so by closing BEEP channel 0. Although not required to do so, the agent should allow for a reasonable period for a manager to release an existing lock prior to initiating a close. Once the agent has closed channel 0, all locks are released, and each side follows teardown procedures as specified in [8]. Having received a BEEP close or having sent <close-session>, a manager MUST NOT send further requests. If there are additional activities due to expanded capabilities, they MUST cease in an orderly manner and should be properly described in the capability mapping.
エージェントがすべてのRPCを完了すると、エージェントがクローズを開始する必要がある場合、マネージャから<クローズセッション>を受信すると、それはする必要はありませんが、BEEPチャンネル0を閉じることで、それはそうだろう、BEEPチャネル0を閉じますそう、エージェントは前の近くを開始する既存のロックを解除するために管理者のための合理的な期間を可能にする必要があります。エージェントはチャネル0を閉じた後、すべてのロックが解除され、[8]で指定されるようにそれぞれの側は、ティアダウン手順に従います。クローズまたは送信したBEEP <クローズセッションを>受け取ったマネージャーがさらに要求を送ってはいけません。拡張機能のために追加的な活動がある場合、それらは整然と停止する必要があり、適切に機能マッピングに記述する必要があります。
Profile Identification: http://iana.org/beep/netconf
プロフィール同定：http://iana.org/beep/netconf
Messages exchanged during Channel Creation: not applicable
チャンネルの作成時に交換されるメッセージ：適用されません
Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply"
「RPC-返信」、「こんにちは」、「RPC」：メッセージは1対1の交換を開始します
Messages in positive replies: "rpc-reply"
正の返信でメッセージ：「RPC-返信」
Messages in negative replies: "rpc-reply"
負の返信でメッセージ：「RPC-返信」
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message syntax: [1]
メッセージ構文：[1]
Message semantics: [1]
メッセージの意味：[1]
Contact Information: See the "Author's Address" section of this memo.
お問い合わせ先：このメモの「著者のアドレス」を参照してください。
Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic so-called "person-in-the-middle" attacks. Configuration information often times contains passwords, user names, service descriptions, and topological information, all of which are sensitive. A NETCONF application protocol, therefore, must minimally support options for both confidentiality and authentication.
構成情報は機密その性質です。はっきりとせずに整合性チェックでは、その送信は、古典的な、いわゆる「人-in-the-middle」攻撃にオープンデバイスを残します。構成情報は、多くの場合、時間が敏感であるすべてのそれらのパスワード、ユーザー名、サービス記述、およびトポロジ情報が含まれています。 NETCONFのアプリケーションプロトコルは、そのため、機密性と認証の両方のサポートオプションを最小限にしなければなりません。
The BEEP mapping described in this document addresses both confidentiality and authentication in a flexible manner through the use of TLS and SASL profiles. Confidentiality is provided via the TLS profile and is used as discussed above. In addition, the server certificate shall serve as the server's authentication to the client. The client MUST be prepared to recognize and validate a server certificate and SHOULD by default reject invalid certificates.
本書では説明BEEPマッピングは、TLSとSASLプロファイルの使用を介して柔軟に機密性と認証の両方に対処します。機密性は、TLSのプロファイルを介して提供され、上述したように使用されます。また、サーバ証明書は、クライアントに対するサーバの認証を務めるものとします。クライアントは、サーバー証明書を認識し、検証するために準備しなければなりませんし、デフォルトでは無効な証明書を拒否すべきです。
In order to validate a certificate, the client must be able to access a trust anchor. While such validation methods are beyond the scope of this document, they will depend on the type of device and circumstance. Both the implementor and the administrator are cautioned to be aware of any circular dependencies that various methods may introduce. For instance, Online Certificate Status Protocol (OCSP) servers may not be available in a network cold-start scenario and would be ill-advised for core routers to depend on to receive configuration at boot.
証明書を検証するために、クライアントは、トラストアンカーにアクセスできる必要があります。そのような検証方法は、このドキュメントの範囲を超えているが、それらはデバイスや環境の種類によって異なります。実装者と管理者の両方は、種々の方法で導入することができる任意の円形の依存関係を認識することが警告されています。例えば、オンライン証明書状態プロトコル（OCSP）サーバーは、ネットワークコールドスタートシナリオでは使用できない可能性があり、ブート時に設定を受信するために依存するコアルータのために無分別になります。
For client-side authentication, there are several options. The client MAY provide a certificate during the initiation phase of TLS, in which case the subject of that certificate shall be considered principle for authentication purposes. Once again, server implementors should be aware of any interdependencies that could be created through protocols used to validate trust anchors.
クライアント側の認証では、いくつかのオプションがあります。クライアントは、その証明書のサブジェクトは、認証のための原則を考慮しなければならない。その場合にはTLSの開始段階、中に証明書を提供することができます。もう一度、サーバーの実装者は、トラストアンカーを検証するために使用されるプロトコルを介して作成される可能性のある相互依存性を認識する必要があります。
TLS endpoints may be authorized based on subject name or certificate authority (CA), depending on circumstances. For instance, it would be unwise for a core Internet router to allow a netconf agent connection simply based on a valid certificate signed by a common CA, but not unreasonable to allow a connection from an agent with a particular distinguished name. On the other hand, it might be desirable for enterprises to trust certificates signed by CAs of their network operations team.
TLSエンドポイントは、状況に応じて、サブジェクト名または認証局（CA）に基づいて許可されてもよいです。例えば、それは単に、特定の識別名を持つエージェントからの接続を許可するための有効な一般的なCAによって署名された証明書が、不合理ではないに基づいて、NETCONFエージェントの接続を許可するコアインターネットルータのための賢明だろう。企業が自社のネットワーク運用チームのCAによって署名された証明書を信頼する一方で、それは望ましいかもしれません。
In the case where the client has not authenticated through TLS, the server SHOULD advertise one or more SASL profiles, from which the client will choose. In the singular case where TLS is established, the minimum profile MAY be PLAIN. Otherwise, implementations MUST support the DIGEST-MD5 profile as described in [6], and they MAY support other profiles such as the One-Time Password (OTP) mechanism [10].
クライアントがTLSによって認証されていない場合、サーバは、クライアントが選択されます、そこから一つ以上のSASLプロファイルを、宣伝すべきです。 TLSが確立された特異場合には、最小プロファイルはPLAINであるかもしれ。そうでない場合は、[6]に記載のように実装は、DIGEST-MD5プロファイルをサポートしなければならない、と彼らは、ワンタイムパスワード（OTP）機構[10]などの他のプロファイルをサポートするかもしれません。
Different environments may well allow different rights prior to and then after authentication. An authorization model is not specified in this document. When an operation is not properly authorized, then a simple rpc-error containing "permission denied" is sufficient. Note that authorization information may be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection.
異なる環境はよく前にして、認証後に異なる権利せることができます。認可モデルは、この文書で指定されていません。操作が適切に承認されていない場合は、単純なRPC-エラー含む十分なものである「許可が拒否されました」。接続のセキュリティを確保するためのすべてのより多くの理由である、設定情報の形式で交換することができること、認可情報に注意してください。
IANA assigned TCP port (831) for NETCONF over BEEP.
IANAは、BEEPの上にNETCONFのためのTCPポート（831）を割り当てます。
This work is the product of the NETCONF IETF working group, and many people have contributed to the NETCONF discussion. Most notably, Rob Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and Margaret Wasserman all contributed in some fashion to this work, which was originally to be found in the NETCONF base protocol specification. Thanks also to Weijing Chen, Keith Allen, Juergen Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very constructive participation. The authors would also like to thank Elwyn Davies for his constructive review.
この作品は、NETCONF IETFワーキンググループの製品であり、そして多くの人々は、NETCONFの議論に貢献してきました。最も顕著なのは、ロブENS、フィル・シェーファー、アンディBierman、ウェスHardiger、テッド・ゴダード、およびマーガレットワッサーマンは、すべてもともとNETCONFベースのプロトコル仕様で発見されるこの作品に何らかの形で貢献しました。彼らは非常に建設的な参加もWeijingチェン、キース・アレン、ユルゲンSchoenwaelder、マーシャルローズ、そしてイーモンO'Tuathailに感謝します。著者らはまた、彼の建設的なレビューのためにエルウィン・デイヴィスに感謝したいと思います。
[1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[1]エンス、R.、エド。、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[3]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[4]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[5] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[5]ニューマン、C.、 "IMAP、POP3、およびACAPとTLSの使用"、RFC 2595を、1999年6月。
[6] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[6]、RFC 2831、2000年5月 "SASLメカニズムとしてダイジェスト認証を使用する" リーチ、P.とC.ニューマン、。
[7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[7]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[8] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[8]ローズ、M.、RFC 3081、 "TCP上にBEEPコアのマッピング" を、2001年3月。
[9] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium, First Edition, http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[9] Sperberg-マックィーン、C.、パオリ、J.、MALER、E.、およびT.ブレイ、 "拡張マークアップ言語（XML）1.0（第二版）"、ワールドワイドウェブコンソーシアム、初版は、http：/ /www.w3.org/TR/2000/REC-xml-20001006、2000年10月。
[10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998.
[10]ニューマン、C.、 "ワンタイムパスワードのSASLメカニズム"、RFC 2444、1998年10月。
Authors' Addresses
著者のアドレス
Eliot Lear Cisco Systems Glatt-com CH-8301 Glattzentrum, Zurich CH
エリオット・リアシスコシステムズスムーズコムCH-8301 Glattzentrum、チューリッヒCH
EMail: lear@cisco.com
メールアドレス：lear@cisco.com
Ken Crozier
ケン・クロージャー
EMail: ken.crozier@gmail.com
メールアドレス：ken.crozier@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。