Network Working Group J. Kempf
Request for Comments: 3105 NTT DoCoMo USA Labs
Category: Experimental G. Montenegro
Sun Microsystems
October 2001
Finding an RSIP Server with SLP
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
IESG Note
IESG注意
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of the RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESGは、RSIP技術を記述したドキュメントのセットは、完全な実装のための重要なホストとゲートウェイの変更を意味するものではありことを指摘しています。また、ポート番号の浮きがある場合には、既存のアプリケーション（例えば、IPsecの）と透過的相互運用からRSIP対応ホストを防止する、いくつかの用途のために問題を引き起こす可能性があります。最後に、RSIPを使用することに伴う大幅な運用の複雑さがあるかもしれません。これらおよび他の合併症のいくつかは、したがってRFC 3102のセクション6で、だけでなく、RFC 3104の付録に概説されている、RSIPを使用してのコストとベネフィットを慎重アドレス不足を緩和する他の手段と比較して検討する必要があります。
Abstract
抽象
This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. Service Location Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP (Realm Specific IP) clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The service type template is the basis for an Internet Assigned Numbers Authority (IANA) standard definition of the advertisements offered by RSIP servers, an important step toward interoperability.
この文書では、彼らのサービスのためのRSIPサーバによって作られた広告を記述するSLPサービスタイプテンプレートが含まれています。サービス・ロケーション・プロトコル（SLP）は、特に、クライアントが特定のサービスを提供するサーバを見つけることができるように設計されたIETF標準トラックプロトコルです。 RSIP（レルム特定IP）クライアントがRSIPサーバを発見するためのメカニズムを必要とするので、SLPは、ソリューションのための自然な試合です。サービスタイプテンプレートはRSIPサーバによって提供される広告のIANA（Internet Assigned Numbers Authority）の標準的な定義、相互運用性に向けた重要なステップの基礎となっています。
Table of Contents
目次
1. Introduction ............................................... 2
2. Notation Conventions ....................................... 2
3. Terminology ................................................ 2
4. Using SLP for RSIP Service Discovery ....................... 3
5. Using Scopes for Server Provisioning ....................... 4
6. Load Balancing ............................................. 6
7. The RSIP Service Type Template ............................. 7
8. Security Considerations .................................... 9
9. Summary .................................................... 9
References ..................................................... 9
Authors' Addresses ............................................. 10
Full Copyright Statement ....................................... 11
Realm Specific IP (RSIP) [7] enables an RSIP client in one realm to borrow addresses and other resources from another realm. It does so by engaging in an RSIP protocol [1] exchange with an RSIP server. The RSIP protocol requires the RSIP server to have a permanent presence on both realms.
レルム特定IP（RSIP）[7]別の領域からアドレスやその他のリソースを借りるために、1つのレルムにRSIPクライアントを可能にします。それはRSIPプロトコルにRSIPサーバと[1]の交換を係合することによってそうします。 RSIPプロトコルは、両方のレルムで永続的な存在感を持つようにRSIPサーバが必要です。
There are a variety of traditional ways an RSIP client could go about locating the appropriate RSIP server. However, Service Location Protocol (SLP) [2][11] is an IETF standards track protocol specifically designed to facilitate location of services and their servers by clients. SLP provides a number of features that simplify locating RSIP servers. In this document, we describe how RSIP clients can use SLP to discover RSIP servers.
RSIPクライアントが適切なRSIPサーバを見つけるに取り掛かることができ、従来の様々な方法があります。しかし、サービスロケーションプロトコル（SLP）[2] [11]は、具体的にクライアントがサービスとそのサーバの位置を容易にするように設計されたIETF標準トラックプロトコルです。 SLPはRSIPサーバを見つける簡素化する多数の機能を提供します。この文書では、我々は、クライアントがRSIPサーバを検出するためにSLPを使用する方法について説明しRSIP。
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 [4].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[4]で説明されるように解釈されます。
We reproduce here some SLP terminology from [2] for readers unfamiliar with SLP.
私たちはここからいくつかのSLPの用語を再現[2] SLPになじみのない読者のために。
User Agent (UA)
ユーザーエージェント（UA）
A process working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents.
いくつかのサービスとの接続を確立するためにユーザーに代わって作業工程。 UAは、サービスエージェントやディレクトリエージェントからのサービス情報を取得します。
Service Agent (SA)
サービスエージェント（SA）
A process working on behalf of one or more services to advertise the services and their capabilities.
サービスとその機能を通知するために1つ以上のサービスのために働くのプロセス。
Directory Agent (DA)
ディレクトリエージェント（DA）
A process which collects service advertisements. There can only be one DA present per given host.
サービス通知を収集プロセス。唯一の特定のホストごとにDAが存在することができます。
Scope
範囲
A set of services, typically making up a logical administrative group.
サービスのセットは、一般的に論理的な管理グループを構成しています。
Service Advertisement
サービス広告
A URL, attributes, and a lifetime (indicating how long the advertisement is valid), providing service access information and capabilities description for a particular service.
URLは、属性、および寿命は、特定のサービスのためのサービスのアクセス情報や機能の説明を提供し、（広告が有効な期間を示します）。
SLP provides the framework in which RSIP clients and servers make contact. Here is a description of how an RSIP server and client find each other using SLP:
SLPはRSIPクライアントとサーバーが接触しているフレームワークを提供します。ここではRSIPサーバとクライアントがSLPを使用して互いを見つける方法の説明は次のとおりです。
1. The RSIP server implements a SLP SA while the RSIP client implements an SLP UA.
RSIPクライアントはSLP UAを実装しながら、1 RSIPサーバはSLP SAを実装しています。
2. The RSIP SA constructs a service advertisement consisting of a service URL, attributes and a lifetime. The URL has service type "service:rsip", and attributes defined according to the template in Section 7.
2. RSIP SAは、サービスURL、属性と寿命からなるサービスの広告を作成します。第7節では、テンプレートに従って定義、および属性：URLは、サービスタイプ「RSIPサービス」を持っています。
3. If an SLP DA is found, the SA contacts the DA and registers the advertisement. If no DA is found, the SA maintains the advertisement itself, answering multicast UA queries directly.
3. SLP DAはDA、SAの連絡先を見つけて、広告を登録している場合。何DAが見つからない場合、SAは直接マルチキャストUAの問い合わせに答える、広告自体を維持します。
4. When the RSIP client requires contact information for an RSIP server, the UA either contacts the DA using unicast or the SA using multicast. The UA includes a query based on the attributes to indicate the characteristics of the server it requires.
RSIPクライアントがRSIPサーバのコンタクト情報が必要な場合4. UAのいずれかの連絡先DAは、マルチキャストを使用して、ユニキャストまたはSAを使用しました。 UAは、それが必要とするサーバーの特性を示すために、属性に基づいてクエリを含んでいます。
5. Once the UA has the host name or address of the RSIP server as well as the port number, it can begin negotiation using the RSIP protocol.
5. UAは、ホスト名またはアドレスRSIPサーバのと同様に、ポート番号を持っていたら、それはRSIPプロトコルを使用して交渉を開始することができます。
This procedure is exactly the same for any client/server pair implementing SLP and is not specific to RSIP.
この手順は、SLPを実装する任意のクライアント/サーバのペアのためにまったく同じであるとRSIPに固有ではありません。
Many protocols use a variety of traditional methods for service discovery. These methods include static configuration, purpose-build protocols for discovery, special features in the protocol itself, DNS SRV RRs [5], or DHCP [6]. SLP provides a number of advantages over these traditional methods:
多くのプロトコルは、サービス発見のための伝統的な様々な方法を使用します。これらの方法は、静的構成、発見の目的ビルドプロトコル、プロトコル自体に特別な機能は、DNS SRVのRRを含む[5]、又はDHCP [6]。 SLPは、これら従来の方法よりも多くの利点を提供します。
1. Discovery of services using SLP is dynamic, whereas many of the traditional methods only allow static or weakly dynamic (i.e., difficult to update) discovery. Clients only discover services that are actually active with SLP. Furthermore, if subsequent to initial discovery a server goes down, the client can reissue an SLP query and obtain a new server. On the server side, no databases must be updated to provide dynamic discovery, the servers advertise themselves.
従来の方法の多くは静的な又は（即ち、困難更新する）弱動的検出を可能にする一方、SLPを使用してサービスの1発見は、動的です。クライアントは、唯一実際にSLPとのアクティブなサービスを発見します。初期の発見以降のサーバがダウンした場合さらに、クライアントは、SLPのクエリを再発行して、新しいサーバーを取得することができます。サーバー側では、何のデータベースは、サーバが自分自身を宣伝し、ダイナミックな発見を提供するために、更新されてはなりません。
2. SLP requires no third party configuration. Only the server offering the service and the client seeking it are required to know the details for the particular service type.
2. SLPには、サードパーティの設定は必要ありません。それを求めているサービスとクライアントを提供する唯一のサーバーは、特定のサービスタイプの詳細を知るために必要とされます。
3. SLP allows clients to specify the attributes describing the desired server. A client discovers servers that meet a set of specific requirements. This reduces the amount of network traffic involved in selecting a server when many possible choices are available.
3. SLPは、クライアントが目的のサーバーを記述する属性を指定することができます。クライアントは、特定の要件のセットを満たすサーバを検出します。これは、多くの可能な選択肢が用意されていたときに、サーバーの選択に関与するネットワークトラフィックの量を減らすことができます。
4. SLP contains a number of scaling mechanisms (DAs, scopes, multicast convergence algorithm), that facilitate deployment in large enterprise networks as well as in smaller networks.
前記SLPは、大規模な企業ネットワークならびに小規模なネットワークでの展開を容易にスケーリング機構（DAS、スコープ、マルチキャスト収束アルゴリズム）の数を含んでいます。
One particular design feature of SLP that is useful for RSIP is scopes. Scopes in SLP are a mechanism for provisioning access to particular service advertisements. An administrator assigns UAs and SAs to particular scopes to assure that UAs only find SAs in those scopes. Scopes are not an access control mechanism for the service itself, however. UAs from outside the scope can still access services in a particular scope (unless the service itself provides for access control), they just won't be able to find the services using SLP.
RSIPのために有用であるSLPの一つの特定の設計上の特徴は、スコープです。 SLPでのスコープは、特定のサービスの広告へのアクセスをプロビジョニングするためのメカニズムです。管理者は、UAがのみスコープにSAを見つけることを保証するために、特定のスコープにUAとSAを割り当てます。スコープは、しかし、サービス自体のアクセス制御機構ではありません。 （サービス自体がアクセス制御を提供する場合を除き）範囲外からのUAはまだ特定のスコープ内のサービスにアクセスすることができ、彼らはSLPを使用してサービスを見つけることができません。
Scopes are useful for RSIP service advertisement provisioning because they allow a system administrator to tie particular RSIP clients to specific RSIP servers. For example, consider the network architecture described in Section 4.2.1 of [7]. RSIP clients are
彼らは、システム管理者は、特定のRSIPサーバに特定のRSIPクライアントを結ぶことができので、スコープはRSIPサービス広告のプロビジョニングのために便利です。例えば、[7]のセクション4.2.1に記載のネットワークアーキテクチャを考えます。 RSIPクライアントがあります
recommended to find "the nearest" RSIP server, but exactly how that should be arranged is left unspecified. SLP provides a way for system administrators to precisely specify which realm an RSIP client resides in, by tying the realm to an SLP scope. The diagram from Section 14.1 is reproduced here, with SLP scopes included to illustrate how clients could be directed to the right RSIP servers.
「最も近い」RSIPサーバを見つけることをお勧めしますが、正確にどのようにそれを配置しなければならないことは、不特定のままにされます。 SLPは、システム管理者が正確SLPスコープにレルムを結ぶことにより、RSIPクライアントに常駐する領域を指定するための方法を提供します。 SLPスコープは、クライアントが右RSIPサーバに向けることができる方法説明するために含まれて、セクション14.1からの図は、ここに再現されます。
+-----------+
| |
| RSIP |
| server +---- 10.0.0.0/8
| B | SLP Scope: B
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ server | SLP Scope: A
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| server +---- 10.0.0.0/8
| C | SLP Scope: C
| |
+-----------+
Clients on the upper 10.0.0.0/8 network are configured to use SLP scope B, while clients on the lower 10.0.0.0/8 network are configured to use SLP scope C. RSIP servers B and C (as clients of server A) use SLP to locate RSIP server A, as do other RSIP clients on the 10.0.1.0/24 and 10.0.2.0/24 subnets. Within these two subnets, all clients have their scopes configured to be A.
下部10.0.0.0/8ネットワーク上のクライアントが（サーバAのクライアントのような）SLPスコープC. RSIPサーバBとCを使用するように構成されている間、上部10.0.0.0/8ネットワーク上のクライアントが使用し、SLPスコープBを使用するように構成されていますSLP 10.0.1.0/24と10.0.2.0/24サブネット上の他のRSIPクライアントがそうであるように、RSIPサーバAを検索します。これらの2つのサブネット内では、すべてのクライアントは、そのスコープはA.可能に構成されています
Note that specifying a particular SLP scope for RSIP clients does not restrict the SLP scope for other services advertised by SLP. SLP UAs can be configured for multiple scopes, so the scope configured for printing may be different from the scope configured for RSIP service.
RSIPクライアントのために特定のSLPスコープを指定すると、SLPによってアドバタイズ他のサービスのSLPスコープを制限するものではないことに注意してください。 SLP UAは複数のスコープのために構成することができるので、印刷のために構成されたスコープはRSIPサービスのために構成されたスコープでも異なっていてもよいです。
Since SLP scopes are configured through a DHCP option [8], along with the IP address, system administrators can easily switch a cluster of machines from one realm to another by simply changing the scope and
SLPスコープは、DHCPオプションを使用して構成されているので、[8]、IPアドレスと共に、システム管理者が容易に単に範囲を変更することによって別の領域からマシンのクラスタを切り替えることができます
IP address assignments on the DHCP server. For example, in the above architecture, suppose a system administrator wanted to remove RSIP server B so that clients on the upper 10.0.0.0/8 subnet were directly on subnet 10.0.1.0/24. These clients now communicate with RSIP server A. By simply changing the address assignments and scope configuration of these clients on the DHCP server, the realm can be effectively switched.
DHCPサーバー上のIPアドレスの割り当て。例えば、上記のアーキテクチャでは、上位10.0.0.0/8サブネット上のクライアントは、サブネット10.0.1.0/24に直接ましたように、システム管理者がRSIPサーバBを削除したいとします。これらのクライアントは、今レルムが効果的に切り替えることができ、単にDHCPサーバ上でこれらのクライアントのアドレス割り当てとスコープの構成を変更することによりRSIPサーバAと通信します。
While SLP itself contains no specific provision for load balancing, load balancing can easily be implemented using SLP. The only requirement is that the service type template specify an attribute indicating server load. In the case of RSIP, the service type template in Section 7 contains such an attribute. The attribute indicates the number of RSIP client sessions currently being supported by the server.
SLP自体は、負荷分散のための具体的な規定が含まれていませんが、負荷分散を簡単にSLPを使用して実装することができます。唯一の要件は、サービスタイプのテンプレートは、サーバーの負荷を示すの属性を指定することです。 RSIPの場合は、第7節でサービスタイプテンプレートは、そのような属性が含まれています。属性は、現在サーバーでサポートされているRSIPクライアントセッションの数を示します。
In order to perform load balancing, the RSIP server must update its service advertisement periodically as new connections are accepted. An RSIP client seeking to find the server having the lightest load performs the following series of SLP operations.
新しい接続が受け入れられるように、負荷分散を実行するためには、RSIPサーバは、定期的にそのサービスの広告を更新する必要があります。最も軽い負荷を有するサーバを見つけるために求めているRSIPクライアントは、SLPの次の一連の動作を実行します。
1. As in Section 4, the client issues an SLP service request and collects all the returned service URLs.
1.第4節では、クライアントはSLPサービス要求を発行し、すべての返されたサービスのURLを収集します。
2. For each service URL, the client performs an SLP attribute request for the attribute LOAD. The integer load figures are returned.
2.各サービスのURLの場合、クライアントは、属性LOADのためのSLP属性要求を行います。整数ロードの数値が返されます。
3. The client sorts through the returned load figures and selects the URL having the least number of connections. The client establishes its RSIP session with that server.
3.クライアントは、返された負荷の数字によってソートし、接続の最小数を持つURLを選択します。クライアントは、そのサーバとのRSIPセッションを確立します。
Because of network delays, this procedure does not guarantee that a client will always obtain a connection with the lightest loaded server, but it does provide a high probability that the selected server is more lightly loaded.
そのため、ネットワークの遅延のため、この手順は、クライアントが常に最軽量ロードされたサーバとの接続を取得することを保証するものではありませんが、選択したサーバーは、より軽くロードされていることを高い確率を提供しません。
A similar procedure is used in [9] to load balance access to TN3270E telnet servers.
同様の手順は、[9]のTN3270EのTelnetサーバへのバランスのアクセスをロードするために使用されます。
Name of submitters: James Kempf <james@docomolabs-usa.com> Gabriel Montenegro <gab@sun.com>
提出者の名前：ジェームズ・ケンプ<james@docomolabs-usa.com>ガブリエルモンテネグロ<gab@sun.com>
Language of service template: en
サービステンプレートの言語：EN
Security Considerations: RSIP clients can use Service Location Protocol to find RSIP servers having particular security characteristics. If secure access to such information is required, SLP security should be used.
セキュリティの考慮：RSIPクライアントは、特定のセキュリティ特性を有するRSIPサーバを見つけるために、サービスロケーションプロトコルを使用することができます。そのような情報への安全なアクセスが必要な場合は、SLPのセキュリティを使用する必要があります。
Template text:
----------------------template begins here -------------------------
template-type = rsip
template-version = 0.0
テンプレートバージョン= 0.0
template-description= The service:rsip type provides advertisements for clients seeing realm-specific IP (RSIP) servers. RSIP servers use the Realm Specific IP protocol to manage addresses and other resources from one realm on behalf of a client in another realm.
テンプレート説明=サービス：RSIPタイプは、レルム固有のIP（RSIP）のサーバを見て、クライアントの広告を提供します。 RSIPサーバは、他の分野でのクライアントに代わって1つの領域からアドレスや他のリソースを管理するために、レルム特定IPプロトコルを使用します。
template-url-syntax= ;No additional URL path information required. An example service ;URL for an RSIP server is: service:rsip://gateway.mydomain:4455
テンプレートのurl-構文=;必要な追加のURLパス情報。例えば、サービス、RSIPサーバのURLは次のとおりです。サービス：RSIP：//gateway.mydomain：4455
ipsec-support = BOOLEAN O #True if the server supports IPSEC as per [10]
IPSecの支持= BOOLEAN O #Trueサーバは、[10]の通りにIPsecをサポートしている場合
ike-support = BOOLEAN O #True if the server supports IKE as per [10]
IKE-支持= BOOLEAN O #Trueサーバは、[10]に従ってIKEをサポートしている場合
tunnel-type = STRING L M O IP-IP #The tunneling methods supported by the RSIP server. Clients #should include this attribute in a query so that they obtain a #server offering a tunneling method for which they have #support. Default is IP-IP. The values are currently #restricted to IP-IP, L2TP, GRE and NONE. A server can support #multiple tunnel types. IP-IP,L2TP,GRE,NONE
RSIPサーバによってサポートされるトンネルタイプ= STRING L M O IP-IP＃このトンネリング方法。彼らは#supportているためトンネリング方式を提供するの#serverを得るように、クライアントは、クエリでこの属性を含める#should。デフォルトでは、IP-IPです。値は、現在、IP-IP、L2TP、GREおよびNONEに#restrictedされています。サーバーは#multipleトンネルタイプをサポートすることができます。 IP-IP、L2TP、GRE、NONE
transport = STRING L M O TCP #Transport used by the RSIP protocol itself. TCP,UDP
RSIPプロトコル自体によって使用されるトランスポート= STRING L M O TCP #Transport。 TCP、UDP
load = INTEGER O
#If the server supports load balancing, this attribute should be
#set to an integer from 0 to 100. 0 is the lowest indication of
#load and 100 the highest. Clients can query for this attribute
#and obtain load information, from which they can make an
#intelligent decision about which server to use.
----------------------template ends here ---------------------------
Service type templates provide information that is used to interpret information obtained by clients through SLP. If the RSIP template is modified or if a false template is distributed, RSIP servers may not correctly register themselves, or RSIP clients may not be able to interpret service information.
サービスタイプのテンプレートは、SLPを通じてクライアントによって得られた情報を解釈するために使用される情報を提供しています。 RSIPテンプレートが変更されたり虚偽のテンプレートが配布されている場合、RSIPサーバは正しく自身を登録しないことがあり、またはRSIPクライアントがサービス情報を解釈することができない場合があります。
SLP provides an authentication mechanism for UAs to assure that service advertisements only come from trusted SAs [2]. If trust is an issue, particularly with respect to the information sought by the client about IPSEC and IKE support, then SLP authentication should be enabled in the network.
SLPは、サービス通知のみ信頼のSA [2]から来る保証するのUAの認証メカニズムを提供します。信頼は特にIPSECとIKEのサポートについてのクライアントが求める情報に関して、問題がある場合は、SLP認証がネットワークで有効にする必要があります。
This document describes how SLP can be used by RSIP clients to find RSIP servers. A service type template for an RSIP SLP service type is presented. In addition, a few techniques for provisioning access to service advertisements for particular gateway servers, and for load balancing using SLP were provided. The result should allow RSIP service provisioning that is considerably more dynamic and robust than when traditional service discovery mechanisms are used.
この文書では、SLPがRSIPサーバを見つけるために、RSIPクライアントで使用する方法について説明します。 RSIP SLPサービスタイプのサービスタイプのテンプレートが提示されます。また、特定のゲートウェイサーバー用、およびSLPを使用して、負荷分散のためのサービス通知へのアクセスをプロビジョニングするためのいくつかの技術が提供されました。結果はかなり伝統的なサービスディスカバリメカニズムが使用されている場合よりも、よりダイナミックかつ堅牢であるRSIPサービスプロビジョニングを可能にしなければなりません。
References
リファレンス
[1] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, April 2001.
[1]ボレッラ、M.、Grabelsky、D.、ロー、J.及びK.谷口、 "レルム特定IP：プロトコル仕様"、RFC 3103、2001年4月。
[2] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
[2]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービス・ロケーション・プロトコル、バージョン2"、RFC 2608、1999年7月。
[3] Guttman, E, Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
[3]ガットマン、E、パーキンス、C.及びJ.ケンプ、 "サービステンプレートおよびサービス：スキーム"、RFC 2609、1999年7月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[5] Gulbrandsenの、A.及びP.いるVixie、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2052、1996年10月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[6] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[7] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[7]ボレッラ、M.、ロー、J.、Grabelsky、D.およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[8] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, July 1999.
[8]パーキンス、C.およびE.グットマン、 "サービスロケーションプロトコルのためのDHCPオプション"、RFC 2610、1999年7月を。
[9] Naugle, J., Kasthurirangan, K. and G. Ledford, "TN3270E Service Location and Session Balancing", RFC 3049, January 2001.
[9] Naugle、J.、Kasthurirangan、K.およびG.レドフォード、 "TN3270Eサービスロケーションとセッションバランシング"、RFC 3049、2001年1月。
[10] Montenegro, G. and M. Borella, "RSIP Support for End-to-end IPSEC", RFC 3104, October 2001.
[10]モンテネグロ、G.およびM.ボレッラ、 "エンドツーエンドのIPSECのためのRSIPサポート"、RFC 3104、2001年10月。
[11] E. Guttman, "Service Location Protocol: Automatic Discovery of IP Network Services," IEEE Internet Computing, July/August 1999. Available at: http://computer.org/internet/ic1999/w4toc.htm
[11] E.ガットマン、「サービス・ロケーション・プロトコル：自動検出IPネットワークサービスの、」IEEEインターネットコンピューティング、7月/ 8月の利用可能な1999年：http://computer.org/internet/ic1999/w4toc.htm
Authors' Addresses
著者のアドレス
Questions about this document may be directed to:
このドキュメントに関するご質問は、対象とすることができます。
James Kempf NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110
ジェームズ・ケンプNTTドコモUSA研究所181メトロドライブ、スイート300サンノゼ、CA 95110
Phone: 408-451-4711 Email: james@docomolabs-usa.com
電話番号：408-451-4711 Eメール：james@docomolabs-usa.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエル・E.モンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メランFRANCE
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：gab@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。