RFC3237 日本語訳

Network Working Group                                          M. Tuexen
Request for Comments: 3237                                    Siemens AG
Category: Informational                                           Q. Xie
                                                                Motorola
                                                              R. Stewart
                                                                M. Shore
                                                                   Cisco
                                                                  L. Ong
                                                                   Ciena
                                                             J. Loughney
                                                             M. Stillman
                                                                   Nokia
                                                            January 2002

Tuexenがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3237年のジーメンス株式会社カテゴリ: 情報のQ.のJ.Loughney M.蒸留装置操作係ノキアシェモトローラR.スチュワートM.岸のコクチマスL.オングCiena2002年1月

                Requirements for Reliable Server Pooling

信頼できるサーバプーリングのための要件

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document defines a basic set of requirements for reliable server
   pooling.

このドキュメントは信頼できるサーバプーリングのための基本的なセットの要件を定義します。

   The goal of Reliable Server Pooling (RSerPool) is to develop an
   architecture and protocols for the management and operation of server
   pools supporting highly reliable applications, and for client access
   mechanisms to a server pool.

Reliable Server Pooling(RSerPool)の目標は高信頼性アプリケーションをサポートするサーバプールの管理と操作、およびサーバプールへのクライアントアクセス機構のためにアーキテクチャとプロトコルを開発することです。

1.  Introduction

1. 序論

1.1.  Overview

1.1. 概要

   The Internet is always on.  Many users expect services to be always
   available; many businesses depend upon connectivity 24 hours a day, 7
   days a week, 365 days a year.  In order to fulfill this level of
   performance, many proprietary solutions and operating system
   dependent solutions have been developed to provide highly reliable
   and highly available servers.

インターネットはいつもオンです。 多くのユーザが、サービスがいつも利用可能であると予想します。 多くのビジネスが1日24時間、1週間あたり7日間、1年365日接続性に依存します。 この技量、多くの独占溶液、およびオペレーティングシステムを実現させて、依存する解決策は、高信頼性の、そして、非常に利用可能なサーバを提供するために見いだされました。

Tuexen, et al.               Informational                      [Page 1]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[1ページ]のRFC3237要件

   This document defines requirements for an architecture and protocols
   enabling pooling of servers to support high reliability and
   availability for applications.

このドキュメントはサーバのプーリングが高信頼性をサポートするのを可能にするアーキテクチャとプロトコルのための要件とアプリケーションのための有用性を定義します。

   The range of applications that can benefit from reliable server
   pooling includes both mobile and real-time applications.  Reliable
   server pooling mechanisms will be designed to support functionality
   for flexible pooling such as registration and deregistration, and
   load balancing of traffic across the server pool.  Mechanisms will
   need to balance the needs of scalability, overhead traffic and
   response time to changes in pool status, as discussed below.

信頼できるサーバプーリングの利益を得ることができるアプリケーションの範囲はモバイルの、そして、リアルタイムの両方のアプリケーションを含んでいます。 信頼できるサーバプーリングメカニズムは、サーバプールの向こう側にフレキシブルなプーリングのための登録や反登録などの機能性、およびトラフィックのロードバランシングをサポートするように設計されるでしょう。 メカニズムは、スケーラビリティ、オーバーヘッド・トラヒック、および応答時間の必要性のプール状態の変化とバランスをとる必要があるでしょう、以下で議論するように。

1.2.  Terminology

1.2. 用語

   This document uses the following terms:

このドキュメントは次の用語を使用します:

      Operation scope:
         The part of the network visible to pool users by a specific
         instance of the reliable server pooling protocols.

操作範囲: プールユーザにとって、信頼できるサーバプーリングプロトコルの特定のインスタンスで目に見えるネットワークの部分。

      Pool (or server pool):
         A collection of servers providing the same application
         functionality.

プール(または、サーバプール): 同じアプリケーションの機能性を提供するサーバの収集。

      Pool handle (or pool name):
         A logical pointer to a pool.  Each server pool will be
         identifiable in the operation scope of the system by a unique
         pool handle or "name".

ハンドル(または、プール名)をプールしてください: プールへの論理的な指針。 それぞれのサーバプールはシステムの操作範囲でユニークなプールハンドルか「名前」で身元保証可能になるでしょう。

      Pool element:
         A server entity having registered to a pool.

要素をプールしてください: 有がプールに示したサーバ実体。

      Pool user:
         A server pool user.

ユーザをプールしてください: サーバプールユーザ。

      Pool element handle (or endpoint handle):
         A logical pointer to a particular pool element in a pool,
         consisting of the name of the pool and one or more destination
         transport addresses for the pool element.

要素ハンドル(または、終点ハンドル)をプールしてください: プールの名前から成るプールの中の特定のプール要素への論理的な指針と輸送がプール要素のために扱う1つ以上の目的地。

      Name space:
         A cohesive structure of pool names and relations that may be
         queried by an internal or external agent.

スペースを命名してください: 内部の、または、外部のエージェントによって質問されるかもしれないプール名と関係の粘着性がある構造。

      Name server:
         Entity which is responsible for managing and maintaining the
         name space within the RSerPool operation scope.

ネームサーバ: RSerPool操作範囲の中でスペースという名前を管理して、維持するのに原因となる実体。

Tuexen, et al.               Informational                      [Page 2]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[2ページ]のRFC3237要件

      RSerPool:
         The architecture and protocols for reliable server pooling.

RSerPool: 信頼できるサーバプーリングのためのアーキテクチャとプロトコル。

1.3.  Abbreviations

1.3. 略語

      PE:   Pool element

PE: プール要素

      PU:   Pool user

Pu: プールユーザ

      SCTP: Stream Control Transmission Protocol

SCTP: ストリーム制御伝動プロトコル

      TCP:  Transmission Control Protocol

TCP: 通信制御プロトコル

2.  Requirements

2. 要件

2.1.  Robustness

2.1. 丈夫さ

   The solution must allow itself to be implemented and deployed in such
   a way that there is no single point of failure in the system.

システムには失敗のどんな単一のポイントもないような方法で実装されて、ソリューションは配布しなければなりません。

2.2.  Failover Support

2.2. フェイルオーバーサポート

   The RSerPool architecture must be able to detect failure of pool
   elements and name servers supporting the pool, and support failover
   to available alternate resources.

RSerPoolアーキテクチャは、プール要素とネームサーバの失敗がプールを支えるのを検出して、利用可能な代替のリソースにフェイルオーバーをサポートすることができなければなりません。

2.3.  Communication Model

2.3. コミュニケーションモデル

   The general architecture should support flexibility of the
   communication model between pool users and pool elements, especially
   allowing for a peer-to-peer relationship to support some
   applications.

一般的なアーキテクチャはプールユーザとプール要素の間のコミュニケーションモデルの柔軟性をサポートするべきです、ピアツーピア関係がいくつかのアプリケーションをサポートするのを特に許容して。

2.4.  Processing Power

2.4. 処理能力

   It should be possible to use the protocol stack in small devices,
   like handheld wireless devices.  The solution must scale to devices
   with a differing range of processing power.

小さいデバイスでプロトコル・スタックを使用するのはハンドヘルドのワイヤレス機器のように可能であるべきです。 ソリューションは異なった範囲の処理能力でデバイスに比例しなければなりません。

2.5.  Transport Protocol

2.5. トランスポート・プロトコル

   The protocols used for the pool handling should not cause network
   congestion.  This means that it should not generate heavy traffic,
   even in case of failures, and has to use flow control and congestion
   avoidance algorithms which are interoperable with currently deployed
   techniques, especially the flow control of TCP [RFC793] and SCTP
   [RFC2960] and must be compliant with [RFC2914].

プール取り扱いに使用されるプロトコルはネットワークの混雑を引き起こすべきではありません。 これはそれが失敗の場合にさえ激しいトラフィックを生成するべきでなくて、現在配布しているテクニック、特にTCP[RFC793]とSCTP[RFC2960]のフロー制御でフロー制御と共同利用できる輻輳回避アルゴリズムを使用しなければならなくて、[RFC2914]と共に言いなりになるに違いないことを意味します。

Tuexen, et al.               Informational                      [Page 3]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[3ページ]のRFC3237要件

   The architecture should not rely on multicast capabilities of the
   underlying layer.  Nevertheless, it can make use of it if multicast
   capabilities are available.

アーキテクチャは下位層のマルチキャスト能力を当てにするべきではありません。 それにもかかわらず、マルチキャスト能力が利用可能であるなら、それはそれを利用できます。

   Network failures have to be handled and concealed from the
   application layer as much as possible by the transport protocol.
   This means that the underlying transport protocol must provide a
   strong network failure handling capability on top of an acknowledged
   error-free non-duplicated data delivery service.  The failure of a
   network element must be handled by the transport protocol in such a
   way that the timing requirements are still fulfilled.

トランスポート・プロトコルは応用層からネットワーク失敗をできるだけ扱って、隠さなければなりません。 これは、基本的なトランスポート・プロトコルが承認されたエラーのない非コピーされたデータデリバリ・サービスの上で強いネットワーク失敗取り扱い能力を提供しなければならないことを意味します。 トランスポート・プロトコルでタイミング要件がまだ実現しているような方法でネットワーク要素の失敗を扱わなければなりません。

2.6.  Support of RSerPool Unaware Clients

2.6. RSerPoolの気づかないクライアントのサポート

   The architecture should allow for ease of interaction between pools
   and non-RSerPool-aware clients.  However, it is assumed that only
   RSerPool-aware participants will receive maximum timing and
   notification benefits the architecture offers.

そして、アーキテクチャがプールの間の相互作用の容易さを考慮するべきである、非RSerPool意識する、クライアント。 しかしながら、RSerPool意識している関係者だけがアーキテクチャが提供する最大のタイミングと通知利益を受け取ると思われます。

2.7.  Registering and Deregistering

2.7. 登録とDeregistering

   Another important requirement is that servers should be able to
   register to (become PEs) and deregister from a server pool
   transparently without an interruption in service.  This means that
   after a PE has deregistered, it will continue to serve PUs which
   started their connection before the deregistration of the PE.  New
   connections will be directed towards an alternative PE.

別の重要な要件はサーバが登録できて(PEsになります)サーバプールから透過的に使用中の中断なしで、よりderegisterであるはずであるということです。 これは、PEが反登録した後にずっとPEの反登録の前で彼らの接続を始めたPUsに役立つことを意味します。 新しい接続は代替のPEに向けられるでしょう。

   Servers should be able to register in multiple server pools which may
   belong to different namespaces.

サーバは異なった名前空間に属すかもしれない複数のサーバプールに登録できるべきです。

2.8.  Naming

2.8. 命名

   Server pools are identified by pool handles.  These pool handles are
   only valid inside the operation scope.  Interoperability between
   different namespaces has to be provided by other mechanisms.

サーバプールはプールハンドルによって特定されます。 これらのプールハンドルは操作範囲の中で有効であるだけです。 他のメカニズムは異なった名前空間の間の相互運用性を提供しなければなりません。

2.9.  Name Resolution

2.9. 名前解決

   The name resolution should not result in a pool element which is not
   operational.  This might be important for fulfilling the timing
   requirements described below.

名前解決は操作上でないプール要素をもたらすべきではありません。 以下で説明されたタイミング要件を実現させるのに、これは重要であるかもしれません。

2.10.  Server Selection

2.10. サーバ選択

   The RSerPool mechanisms must be able to support different server
   selection mechanisms.  These are called server pool policies.

RSerPoolメカニズムは、異なったサーバ選択がメカニズムであるとサポートすることができなければなりません。これらはサーバプール方針と呼ばれます。

Tuexen, et al.               Informational                      [Page 4]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[4ページ]のRFC3237要件

   Examples of server pool policies are:

サーバプール方針に関する例は以下の通りです。

      -  Round Robin

- 連続

      -  Least used

- 最も最少に使用されます。

      -  Most used

- 最も使用にされる

   The set of supported policies must be extensible in the sense that
   new policies can be added as required.  Non-stochastic and stochastic
   policies can be supported.

サポートしている方針のセットは必要に応じて新しい政策を加えることができるという意味で広げることができるに違いありません。 非推計的で推計的な方針をサポートすることができます。

   There must be a way for the client to provide operational status
   feedback to the name server about the pool elements.

クライアントがプール要素に関して操作上の状態フィードバックをネームサーバに提供する方法があるに違いありません。

   The name server protocols must be extensible to allow more refined
   server selection mechanisms to be implemented as they are developed
   in the future.

それらが将来開発されるとき、より洗練されたサーバ選択メカニズムが実装されるのを許容するのにおいてネームサーバプロトコルは広げることができるに違いありません。

   For some applications it is important that a client repeatedly
   connects to the same server in a pool if it is possible, i.e., if
   that server is still alive.  This feature should be supported through
   the use of pool element handles.

いくつかのアプリケーションに、それが可能であるならクライアントが繰り返してプールの中の同じサーバに接続するのは、重要です、すなわち、そのサーバがまだ生きているなら。 この特徴はプール要素ハンドルの使用でサポートされるべきです。

2.11.  Timing Requirements and Scaling

2.11. 要件を調節して、比例します。

   Handling of name resolution must be fast to support real-time
   applications.  Moreover, the name space should reflect pool
   membership changes to the client application as rapidly as possible,
   i.e., not waiting until the client application next reconnects.

名前解決の取り扱いはリアルタイムのアプリケーションをサポートするのにおいて速いに違いありません。 そのうえ、すなわち、名前スペースは、次のクライアントアプリケーションが再接続されるまで待たないことで早急にクライアントアプリケーションへのプール会員資格変化を反映するべきです。

   The architecture should support control of timing parameters based on
   specific needs, e.g., of an application or implementation.

アーキテクチャは特定の必要性に基づくタイミングパラメタ、例えば、アプリケーションか実装のコントロールをサポートするべきです。

   In order to support more rapid and accurate response, the
   requirements on scalability of the mechanism are limited to server
   pools consisting of a suitably large but not Internet-wide number of
   elements, as necessary to support bounded delay in handling real-time
   name resolution.

より急速で正確な応答をサポートするために、メカニズムのスケーラビリティに関する要件はリアルタイムの名前解決を扱う境界がある遅れをサポートするために必要に応じて適当に大きい、しかし、インターネット全体でない数の要素から成るサーバプールに制限されます。

   Also, there is no requirement to support hierarchical organization of
   name servers for scalability.  Instead, it is envisioned that the set
   of name servers supporting a particular pool is organized as a flat
   space of equivalent servers.  Accordingly, the impact of relatively
   frequent updates to ensure accurate reflection of the status of pool
   elements is limited to the set of name servers supporting a specific
   pool.

また、スケーラビリティのためにネームサーバの階層的な組織をサポートするという要件が全くありません。 代わりに、それは思い描かれます。ネームサーバが特定のプールを支えるセットは同等なサーバの平坦なスペースとして組織化されます。 それに従って、プール要素の状態の正確な反映を確実にする比較的頻繁なアップデートの影響は特定のプールを支えるネームサーバのセットに制限されます。

Tuexen, et al.               Informational                      [Page 5]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[5ページ]のRFC3237要件

2.12.  Scalability

2.12. スケーラビリティ

   The RSerPool architecture should not require a limitation on the
   number of server pools or on the number of pool users, although the
   size of an individual pool may be limited by timing requirements as
   defined above.

RSerPoolアーキテクチャはサーバプールの数の上、または、プールユーザの数の上で制限を必要とするべきではありません、個々のプールのサイズが上で定義されるようにタイミング要件によって制限されるかもしれませんが。

2.13.  Security Requirements

2.13. セキュリティ要件

2.13.1.  General

2.13.1. 一般

   -  The scaling characteristics of the security architecture should be
      compatible with those given previously.

- セキュリティー体系のスケーリングの特性は以前に与えるそれらと互換性があるべきです。

   -  The security architecture should support hosts having a wide range
      of processing powers.

- セキュリティー体系はさまざまな処理能力を持っているホストをサポートするべきです。

2.13.2.  Name Space Services

2.13.2. 名前宇宙サービス

   -  It must not be possible for an attacker to falsely register as a
      pool element with the name server either by masquerading as
      another pool element or by registering in violation of local
      authorization policy.

- 攻撃者がプール要素として別のプール要素のふりをするか、またはローカルの承認方針を違反して登録することによって間違ってネームサーバに登録するのは、可能であるはずがありません。

   -  It must not be possible for an attacker to deregister a server
      which has successfully registered with the name server.

- 攻撃者にとって、そうしたサーバが首尾よくネームサーバとともに記名したのは、「反-レジスタ」に可能であるはずがありません。

   -  It must not be possible for an attacker to spoof the response to a
      query to the name server

- 攻撃者が質問への応答をネームサーバに偽造するのは、可能であるはずがありません。

   -  It must be possible to protect the privacy of queries to the name
      server and responses to those queries from the name server.

- ネームサーバからそれらの質問へのネームサーバと応答に質問のプライバシーを保護するのは可能であるに違いありません。

   -  Communication among name servers must be afforded the same
      protections as communication between clients and name servers.

- クライアントとネームサーバとのコミュニケーションと同じ保護をネームサーバの中のコミュニケーションに提供しなければなりません。

2.13.3.  Security State

2.13.3. セキュリティ状態

   The security context of an application is a subset of the overall
   context, and context or state sharing is explicitly out-of-scope for
   RSerPool.  Because RSerPool does introduce new security
   vulnerabilities to existing applications application designers
   employing RSerPool should be aware of problems inherent in failing
   over secured connections.  Security services necessarily retain some
   state and this state may have to be moved or re-established.
   Examples of this state include authentication or retained ciphertext

アプリケーションのセキュリティ文脈は総合的な文脈の部分集合です、そして、文脈か州の共有がRSerPoolのために範囲で明らかに出ています。 RSerPoolが新しいセキュリティの脆弱性を存在に紹介するので、RSerPoolを使うアプリケーションアプリケーション設計者は機密保護している接続の上で失敗することの固有である問題を意識しているべきです。 セキュリティー・サービスが必ず何らかの状態を保有して、この状態は、動かされなければならないか、または復職しなければならないかもしれません。 この状態に関する例は認証か保有された暗号文を含んでいます。

Tuexen, et al.               Informational                      [Page 6]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[6ページ]のRFC3237要件

   for ciphers operating in cipher block chaining (CBC) or cipher
   feedback (CFB) mode.  These problems must be addressed by the
   application or by future work on RSerPool.

暗号で作動する暗号には、推論(CBC)か暗号フィードバック(CFB)モードを妨げてください。 アプリケーションかRSerPoolへの今後の活動でこれらの問題を扱わなければなりません。

3.  Security Considerations

3. セキュリティ問題

   Security issues are discussed in section 2.13.

セクション2.13で安全保障問題について議論します。

4.  Acknowledgements

4. 承認

   The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot
   Lear, Christopher Ross, Werner Vogels and many others for their
   invaluable comments and suggestions.

作者は彼らの非常に貴重なコメントと提案についてバーナードAboba、マットHoldrege、エリオットリア、クリストファー・ロス、ヴェルナーVogels、および多くの他のものに感謝したがっています。

5.  References

5. 参照

   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

   [RFC959]  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
             STD 9, RFC 959, October 1985.

[RFC959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
             Location Protocol, Version 2", RFC 2608, June 1999.

[RFC2608]Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。

   [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
             L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp,
             "Framework Architecture for Signaling Transport", RFC 2719,
             October 1999.

[RFC2719] オングとL.とRytinaとI.とガルシアとM.とSchwarzbauerとH.とCoeneとL.とリンとH.とJuhaszとI.とHoldregeとM.と鋭く、「シグナリングのためのフレームワークアーキテクチャは輸送する」C.、RFC2719、1999年10月。

   [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
             2914, September 2000.

[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。

   [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
             L. and V. Paxson, "Stream Control Transmission Protocol",
             RFC 2960, November 2000.

[RFC2960]スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年11月。

Tuexen, et al.               Informational                      [Page 7]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[7ページ]のRFC3237要件

6.  Authors' Addresses

6. 作者のアドレス

   Michael Tuexen
   Siemens AG
   ICN WN CS SE 51
   D-81359 Munich
   Germany

マイケルTuexenジーメンス株式会社ICN WN Cs SE51D-81359ミュンヘンドイツ

   Phone:   +49 89 722 47210
   EMail: Michael.Tuexen@icn.siemens.de

以下に電話をしてください。 +49 89 722 47210 メール: Michael.Tuexen@icn.siemens.de

   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, #2309
   Arlington Heights, Il 60004
   USA

シェモトローラ1501W.シュアーのドライブ、2309アーリントンハイツ、#不-60004米国をQiaobingします。

   Phone: +1 847 632 3028
   EMail: qxie1@email.mot.com

以下に電話をしてください。 +1 3028年の847 632メール: qxie1@email.mot.com

   Randall Stewart
   Cisco Systems, Inc.
   24 Burning Bush Trail
   Crystal Lake, Il 60012
   USA

ランドルスチュワートシスコシステムズInc.24の燃えているブッシュ・Trail不-60012クリスタルレーク(米国)

   Phone: +1 815 477 2127
   EMail: rrs@cisco.com

以下に電話をしてください。 +1 2127年の815 477メール: rrs@cisco.com

   Melinda Shore
   Cisco Systems, Inc.
   809 Hayts Rd
   Ithaca, NY 14850
   USA

メリンダ岸のシスコシステムズInc.809Haytsニューヨーク14850第イタケー(米国)

   Phone: +1 607 272 7512
   EMail: mshore@cisco.com

以下に電話をしてください。 +1 7512年の607 272メール: mshore@cisco.com

Tuexen, et al.               Informational                      [Page 8]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[8ページ]のRFC3237要件

   Lyndon Ong
   Ciena
   10480 Ridgeview Court
   Cupertino, CA 95014
   USA

リンドンオングCiena10480Ridgeview法廷カリフォルニア95014カルパチーノ(米国)

   Phone: +1 408 366 3358
   EMail: lyong@ciena.com

以下に電話をしてください。 +1 3358年の408 366メール: lyong@ciena.com

   John Loughney
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group
   Finland

ジョンLoughneyノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド

   Phone: +358 50 483 6242
   EMail: john.loughney@nokia.com

以下に電話をしてください。 +358 50 483 6242はメールされます: john.loughney@nokia.com

   Maureen Stillman
   Nokia
   127 W. State Street
   Ithaca, NY 14850
   USA

モーリーン蒸留装置操作係ノキア127W.ステイト・ストリートニューヨーク14850イタケー(米国)

   Phone: +1 607 273 0724 62
   EMail: maureen.stillman@nokia.com

以下に電話をしてください。 +1 0724 62がメールする607 273: maureen.stillman@nokia.com

Tuexen, et al.               Informational                      [Page 9]

RFC 3237        Requirements for Reliable Server Pooling    January 2002

Tuexen、他 2002年1月に水たまりになる高信頼のサーバのための情報[9ページ]のRFC3237要件

7.  Full Copyright Statement

7. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

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

Tuexen, et al.               Informational                     [Page 10]

Tuexen、他 情報[10ページ]