Network Working Group J. Klensin
Request for Comments: 4084 May 2005
BCP: 104
Category: Best Current Practice
Terminology for Describing Internet Connectivity
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered.
インターネットが発展してきたとおり、配置の多くの種類は、「インターネット接続」として宣伝して販売されています。これらは、彼らが提供する機能で大幅に異なる場合がありますので、オプションの範囲、および任意の標準的な用語の欠如、これらのサービスを区別するための努力はかなりの消費者の混乱を引き起こしました。この文書では、潜在的プロバイダー、消費者、および、提供されるサービスの種類と特徴を明確にする規制当局に役立つかもしれない用語と定義のリストを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem and the Requirement . . . . . . . . . . . . 2
1.2. Adoption and a Non-pejorative Terminology . . . . . . . 2
2. General Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. Filtering or Security Issues and Terminology . . . . . . . . . 5
4. Additional Terminology . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 9
Different ISPs and other providers offer a wide variety of products that are identified as "Internet" or "Internet access". These products offer different types of functionality and, as a result, some may be appropriate for certain users and uses and not others. For example, a service that offers only access to the Web (in this context, the portion of the Internet that is accessible via the HTTP and HTTPS protocols) may be appropriate for someone who is exclusively interested in browsing and in Web-based email services. It will not be appropriate for someone who needs to download files or use email more frequently. And it is likely to be even less appropriate for someone who needs to operate servers for other users, who needs virtual private network (VPN) capabilities or other secured access to a remote office, or who needs to synchronize mail for offline use.
異なるISPや他のプロバイダは、「インターネット」または「インターネット接続」として識別されている多種多様な製品を提供します。これらの製品は、結果として、いくつかは、特定のユーザーや用途ではなく他人のために適切な場合があり、機能の異なる種類を提供します。たとえば、（この文脈では、HTTPおよびHTTPSプロトコルを介してアクセス可能なインターネットの部分）は、Webへのアクセスのみを提供するサービスは、ブラウジング中やWebベースの電子メールサービスで独占的に興味を持っている誰かのために適切かもしれません。これは、ファイルをダウンロードしたり、より頻繁に電子メールを使用する必要がある誰かのために適切ではありません。そして、仮想プライベートネットワーク（VPN）機能やオフラインで使用するためにメールを同期させる必要がある、またはリモートオフィスへの他の安全なアクセスを必要とする他のユーザーのためのサーバを運用する必要がある誰かのためにもあまり適切である可能性が高いです。
Recent and rapidly evolving changes to the Internet's email environment have led to additional restrictions on sending and retrieving email. These restrictions, most of them developed as part of well intentioned attempts to prevent or fight unsolicited mail, may be imposed independently of the service types described below and are discussed separately in Section 3.
最近、急速にインターネットの電子メール環境に変更を進化は、電子メールの送信および取得の追加制限につながっています。これらの制限は、それらのほとんどは迷惑メールを防ぐか、戦うための善意の試みの一環として開発され、後述するサービスの種類とは無関係に課されるかもしれ及び第3節で別々に議論されています。
This document describes only the functions provided or permitted by the service provider. It does not and cannot specify the functions that pass through and are supported by various user-provided equipment.
このドキュメントでは、サービスプロバイダが提供または許可のみの機能について説明します。それがないと通過し、様々なユーザが提供する機器でサポートされている関数を指定することができません。
The terms SHOULD, MUST, or MAY are capitalized in this document, as defined in [1].
[1]で定義されるように用語は、ないと、MAYは、この文書に計上されるべきです。
The definitions proposed here are of little value if service providers and vendors are not willing to adopt them. The terms proposed are intended not to be pejorative, despite the belief of some members of the IETF community that some of these connectivity models are simply "broken" or "not really an Internet service". The mention of a particular service or model in this document does not imply any endorsement of it, only recognition of something that exists or might exist in the marketplace. Thus, the Best Current Practice described in this document is about terminology and information that should be supplied to the user and not about the types of service that should be offered.
サービスプロバイダーやベンダーはそれらを採用して喜んでない場合は、ここで提案した定義は、ほとんど価値があります。提案された条件は、これらの接続モデルのいくつかは、単に「壊れた」または「本当にインターネットサービス」あるIETFコミュニティの一部のメンバーの信念にもかかわらず、軽蔑的ではないことが意図されています。この文書に記載されている特定のサービスやモデルの言及は、存在するか、市場に存在するかもしれない何かの唯一の認識をそれのいずれかの保証を意味するものではありません。したがって、この文書で説明する最も良い現在の練習は、用語と提供すべきサービスの種類について、ユーザーとではないに供給すべき情報についてです。
This section lists the primary IP service terms. It is hoped that service providers will adopt these terms, to better define the services to potential users or customers. The terms refer to the intent of the provider (ISP), as expressed in either technical measures or terms and conditions of service. It may be possible to work around particular implementations of these characteristic connectivity types, but that freedom is generally not the intent of the provider and is unlikely to be supported if the workarounds stop working.
このセクションでは、プライマリIPサービス用語を示しています。サービス・プロバイダは、より良い潜在的なユーザーや顧客にサービスを定義するには、これらの用語を採用することが期待されています。この用語は技術的手段又は用語及びサービスの条件のいずれかで表されるように、プロバイダ（ISP）の意図を指します。これらの特徴的な接続の種類の特定の実装を回避することは可能かもしれないが、その自由は、一般的に、プロバイダの意図するところではないと回避策は動作を停止した場合にサポートされにくいです。
The service terms are listed in order of ascending capability, to reach "full Internet connectivity".
サービスの用語は、「完全なインターネット接続」に到達するために、上昇性能の順にリストされています。
o Web connectivity.
OのWeb接続を提供します。
This service provides connectivity to the Web, i.e., to services supported through a "Web browser" (such as Firefox, Internet Explorer, Mozilla, Netscape, Lynx, or Opera), particularly those services using the HTTP or HTTPS protocols. Other services are generally not supported. In particular, there may be no access to POP3 or IMAP4 email, encrypted tunnels or other VPN mechanisms.
このサービスは、Webへの、すなわち、（例えばFirefoxやInternet ExplorerやMozillaの、ネットスケープ、オオヤマネコ、またはオペラなど）、「Webブラウザ」を通じてサポートサービス、HTTPまたはHTTPSプロトコルを使用して、特に、これらのサービスへの接続を提供します。その他のサービスは、一般的にサポートされていません。具体的には、POP3またはIMAP4電子メール、暗号化されたトンネルまたは他のVPN機構へのアクセスがなくてもよいです。
The addresses used may be private and/or not globally reachable. They are generally dynamic (see the discussion of dynamic addresses in Section 3 for further discussion of this terminology and its implications) and relatively short-lived (hours or days rather than months or years). These addresses are often announced as "dynamic" to those who keep lists of dial-up or dynamic addresses. The provider may impose a filtering Web proxy on the connections; that proxy may change and redirect URLs to other sites than the one originally specified by the user or embedded link.
使用されるアドレスは、プライベートおよび/または世界的に到達できないかもしれません。彼らは一般的に（数時間または数日間ではなく、数ヶ月または数年）、ダイナミック（この用語とその意味のさらなる議論については第3章でダイナミックアドレスの説明を参照）と比較的短命です。これらのアドレスは、多くの場合、ダイヤルアップまたはダイナミックアドレスのリストを守る者に「ダイナミック」として発表されています。プロバイダは接続のフィルタリング、Webプロキシを課すことができます。そのプロキシは、もともとユーザーまたは埋め込まれたリンクで指定されたもの以外のサイトへのURLを変更し、リダイレクトすることがあります。
o Client connectivity only, without a public address.
パブリックアドレスを持たない唯一oクライアントの接続、。
This service provides access to the Internet without support for servers or most peer-to-peer functions. The IP address assigned to the customer is dynamic and is characteristically assigned from non-public address space. Servers and peer-to-peer functions are generally not supported by the network address translation (NAT) systems that are required by the use of private addresses. (The more precise categorization of types of NATs given in [2] are somewhat orthogonal to this document, but they may be provided as additional terms, as described in Section 4.)
このサービスは、サーバや、ほとんどのピア・ツー・ピアの機能をサポートすることなく、インターネットへのアクセスを提供します。顧客に割り当てられたIPアドレスは動的であり、特徴的に非パブリックアドレス空間から割り当てられます。サーバーとピア・ツー・ピアの機能は、一般的にプライベートアドレスを使用することによって、必要とされるネットワークアドレス変換（NAT）システムによってサポートされていません。 （に与えられたのNATのタイプのより正確な分類は、[2]この文書に幾分直交しているが、セクション4で説明したように、それらは、追加条件として提供されてもよいです）
Filtering Web proxies are common with this type of service, and the provider SHOULD indicate whether or not one is present.
フィルタリングウェブプロキシはこのタイプのサービスで共通しており、プロバイダは1つが存在するか否かを示す必要があります。
o Client only, public address.
oクライアントのみ、パブリックアドレス。
This service provides access to the Internet without support for servers or most peer-to-peer functions. The IP address assigned to the customer is in the public address space. It is usually nominally dynamic or otherwise subject to change, but it may not change for months at a time. Most VPN and similar connections will work with this service. The provider may prohibit the use of server functions by either legal (contractual) restrictions or by filtering incoming connection attempts.
このサービスは、サーバや、ほとんどのピア・ツー・ピアの機能をサポートすることなく、インターネットへのアクセスを提供します。顧客に割り当てられたIPアドレスは、パブリックアドレス空間です。これは通常、名目上、動的または変更する場合がそうでない場合は対象となりますが、それは一度に数ヶ月のために変更することはできません。ほとんどのVPNと同様の接続は、このサービスで動作します。プロバイダは、いずれかの法的（契約）の制限により、または着信接続の試みをフィルタリングすることにより、サーバ機能の使用を禁止することができます。
Filtering Web proxies are uncommon with this type of service, and the provider SHOULD indicate if one is present.
フィルタリングウェブプロキシはこのタイプのサービスとまれであり、1が存在する場合、プロバイダは示すべきです。
o Firewalled Internet Connectivity.
ファイアウォールインターネット接続、O。
This service provides access to the Internet and supports most servers and most peer-to-peer functions, with one or (usually) more static public addresses. It is similar to "Full Internet Connectivity", below, and all of the qualifications and restrictions described there apply. However, this service places a provider-managed "firewall" between the customer and the public Internet, typically at customer request and at extra cost compared to non-firewalled services. Typically by contractual arrangements with the customer, this may result in blocking of some services.
このサービスは、1つまたは（通常は）より静的パブリックアドレスで、インターネットへのアクセスを提供し、ほとんどのサーバとほとんどピア・ツー・ピア機能をサポートしています。それは以下、「フルインターネット接続」に類似しており、資格と制限のすべてが適用されます説明しました。しかし、このサービスは、通常、顧客の要求に応じて非ファイアウォールサービスに比べて、余分なコストで、顧客と公共のインターネット間のプロバイダーが管理する「ファイアウォール」を配置します。通常、顧客との契約によって、これは一部のサービスのブロッキングをもたらすことができます。
Other services may be intercepted by proxies, content-filtering arrangements, or application gateways. The provider SHOULD specify which services are blocked and which are intercepted or altered in other ways.
その他のサービスは、プロキシ、コンテンツフィルタリングの手配、またはアプリケーション・ゲートウェイによって傍受されることがあります。プロバイダは、サービスがブロックされているが傍受又は他の方法で改変されている特定すべきです。
In most areas, this service arrangement is offered as an add-on, extra-cost, option with what would otherwise be Full Internet Connectivity. It is distinguished from the models above by the fact that any filtering or blocking services are ultimately performed at customer request, rather than being imposed as service restrictions.
ほとんどの地域では、このサービスの配置は、それ以外の場合は完全なインターネット接続であるものとアドオン、余分なコスト、オプションとして提供されます。これは、任意のフィルタリングまたはブロッキングサービスは、最終的には、むしろサービスの制限として課されるより、顧客の要請で行われているという事実によって、上記のモデルと区別されます。
o Full Internet Connectivity.
完全なインターネット接続、O。
This service provides the user full Internet connectivity, with one or more static public addresses. Dynamic addresses that are long-lived enough to make operating servers practical without highly dynamic DNS entries are possible, provided that they are not characterized as "dynamic" to third parties.
このサービスは、1つの以上の静的パブリックアドレスで、ユーザーの完全なインターネット接続を提供します。長寿命の十分な高度に動的DNSエントリなしで動作サーバを実用的になっているダイナミックアドレスは可能であり、それらは第三者に「ダイナミック」として特徴付けられていないことを条件とします。
Filtering Web proxies, interception proxies, NAT, and other provider-imposed restrictions on inbound or outbound ports and traffic are incompatible with this type of service. Servers on a connected customer LAN are typically considered normal. The only compatible restrictions are bandwidth limitations and prohibitions against network abuse or illegal activities.
フィルタリングWebプロキシ、傍受プロキシ、NAT、およびインバウンドまたはアウトバウンドポートやトラフィック上の他のプロバイダに課した制限は、このタイプのサービスと互換性がありません。接続されている顧客LAN上のサーバーは、通常は正常と考えています。唯一の互換性の制限は、帯域幅制限とネットワークの乱用や違法行為に対して禁止されています。
As mentioned in the Introduction, the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services. Such objectionable traffic may include unsolicited mail of various types (including "spam"), worms, viruses, and their impact, and in some cases, specific content.
はじめに述べたように、不快なネットワークトラフィックを制御または制限するための努力は、行動やインターネットサービスの機能の追加制限につながっています。このような不快なトラフィックは未承諾（「スパム」を含む）様々な種類のメール、ワーム、ウイルス、およびその影響、およびいくつかのケースでは、特定のコンテンツを含むことができます。
In general, significant restrictions are most likely to be encountered with Web connectivity and non-public-address services, but some current recommendations would apply restrictions at all levels. Some of these mail restrictions may prevent sending outgoing mail (except through servers operated by the ISP for that purpose), may prevent use of return addresses of the user's choice, and may even prevent access to mail repositories (other than those supplied by the provider) by remote-access protocols such as POP3 or IMAP4. Because users may have legitimate reasons to access remote file services, remote mail submission servers (or, at least, to use their preferred email addresses from multiple locations), and to access remote mail repositories (again, a near-requirement if a single address is to be used), it is important that providers disclose the services they are making available and the filters and conditions they are imposing.
一般的には、重要な制限は、Web接続と非公共アドレスのサービスと遭遇する可能性が最も高いですが、いくつかの現在の推奨事項はすべてのレベルで制限を適用します。これらのメールの制限のいくつかは、（除く、その目的のためにISPが運営するサーバーを介して）送信メールを送信できない場合があり、ユーザの好みのリターンアドレスの使用を防ぐことができ、さらには、プロバイダによって提供されたもの以外のメールリポジトリへのアクセスを（妨げる可能性）このようなPOP3またはIMAP4などのリモート・アクセス・プロトコルによって。ユーザーがリモートメール服従サーバ（または、少なくとも、複数の場所から好みの電子メールアドレスを使用する）、そして再び（リモートメールリポジトリにアクセスするには、ほぼ要求であれば、単一のアドレス、リモート・ファイル・サービスにアクセスするための正当な理由を持っている可能性があるためプロバイダは、彼らが利用できるようにしたサービスと、堂々としているフィルターと条件を開示することが重要である、）を使用することです。
Several key issues in email filtering are of particular importance.
電子メールフィルタリングのいくつかの重要な問題は、特に重要です。
o Dynamic Addresses.
Oダイナミックアドレス。
A number of systems, including several "blacklist" systems, are based on the assumption that most undesired email originates from systems with dynamic addresses, especially dialup and home broadband systems. Consequently, they attempt to prevent the addresses from being used to send mail, or perform some other services, except through provider systems designated for that purpose.
いくつかの「ブラックリスト」システムを含むシステムの数は、最も望ましくない電子メールが動的アドレスを持つシステム、特にダイヤルアップおよび家庭用ブロードバンド・システムに由来するという仮定に基づいています。その結果、彼らはその目的のために指定されたプロバイダシステムを通じて以外、メールを送信するために使用されてからアドレスを防ぐ、またはいくつかの他のサービスを実行しようとします。
Different techniques are used to identify systems with dynamic addresses, including provider advertising of such addresses to blacklist operators, heuristics that utilize certain address ranges, and inspection of reverse-mapping domain names to see if they contain telltale strings such as "dsl" or "dial". In some cases, the absence of a reverse-mapping DNS address is taken as an indication that the address is "dynamic". (Prohibition on connections based on the absence of a reverse-mapping DNS record was a technique developed for FTP servers many years ago; it was found to have fairly high rates of failure, both prohibiting legitimate connection attempts and failing to prevent illegitimate ones). Service providers SHOULD describe what they are doing in this area for both incoming and outgoing message traffic, and users should be aware that, if an address is advertised as "dynamic", it may be impossible to use it to send mail to an arbitrary system even if Full Internet Connectivity is otherwise provided.
異なる技術が、彼らは、そのような「DSL」か」などの証拠となる文字列が含まれているかどうかを確認するために、プロバイダ事業者をブラックリストにそのようなアドレスの宣伝、特定のアドレス範囲を使用するヒューリスティック、および逆マッピングドメイン名の検査を含む動的アドレスを持つシステムを識別するために使用されています」ダイヤルしてください。いくつかのケースでは、逆マッピングDNSアドレスが存在しない場合は、アドレスが「ダイナミック」であることの指標としました。 （逆マッピングDNSレコードの有無に基づいて接続の禁止は何年も前にFTPサーバー用に開発された技術だった。それが正当な接続試行を禁止し、違法なものを防ぐために失敗の両方、失敗のかなり高い率を有することが判明しました）。サービスプロバイダは、彼らが着信と発信の両方のメッセージトラフィックのために、このエリアに何をしているか説明する必要があり、ユーザーはアドレスが「ダイナミック」として宣伝されている場合、任意のシステムにメールを送信するためにそれを使用することは不可能であり得ることを認識すべきです完全なインターネット接続を別の方法で提供されている場合でも。
o Non-public addresses and NATs.
非パブリックアドレスとNATのO。
The NAT systems that are used to map between private and public address spaces may support connections to distant mail systems for outbound and inbound mail, but terms of service often prohibit the use of systems not supplied by the connectivity provider and prohibit the operation of "servers" (typically not precisely defined) on the client connection.
NATのアウトバウンドとインバウンドメールの遠方のメールシステムへの接続をサポートすることができるプライベートとパブリックアドレス空間の間でマッピングするために使用されているシステムが、サービスの観点からは、多くの場合、接続プロバイダーによって提供されていないシステムの使用を禁止し、「サーバの操作を禁止します「クライアント接続で（通常は正確に定義されていません）。
o Outbound port filtering from the provider.
プロバイダからフィルタリングOアウトバウンドポート。
Another common technique involves blocking connections to servers outside the provider's control by blocking TCP "ports" that are commonly used for messaging functions. Different providers have different theories about this. Some prohibit their customers from accessing external SMTP servers for message submission, but they permit the use of the mail submission protocol ([3]) with sender authentication. Others try to block all outgoing messaging-related protocols, including remote mail retrieval protocols; however, this is less common with public-address services than those that are dependent on private addresses and NATs. If this type of filtering is present, especially with "Client only, public address" and "Full Internet Connectivity" services, the provider MUST indicate that fact (see also Section 4).
他の一般的な技術は、一般的に、メッセージング機能に使用されているTCP「ポート」をブロックすることにより、プロバイダの制御の外部のサーバへの接続をブロックが含まれます。異なるプロバイダは、このことについて異なる理論を持っています。いくつかは、メッセージ送信のために外部のSMTPサーバにアクセスする顧客を禁止しますが、それらは、送信者認証とメール送信プロトコル（[3]）の使用を許可します。その他には、リモートメールの取得プロトコルを含むすべての送信メッセージに関連するプロトコルをブロックするようにしてみてください。しかし、これはプライベートアドレスとNATのに依存しているものよりも、パブリック・アドレスサービスであまり一般的です。この種のフィルタリングは、特に「クライアントのみ、パブリックアドレス」と「フルインターネット接続」サービスで、存在する場合は、その事実を示してしなければならないプロバイダが（セクション4を参照します）。
Still others may divert (reroute) outbound email traffic to their own servers, on the theory that this eliminates the need for reconfiguring portable machines as they connect from a different network location. Again, such diversion MUST be disclosed, especially since it can have significant security and privacy implications.
まだ他には、これは彼らが別のネットワークの場所から接続するなどのポータブル機器を再構成する必要がなくなるという理論に、独自のサーバーに（リルート）アウトバウンドのメールトラフィックをそらすことがあります。また、このような転換は、それは重大なセキュリティとプライバシーの意味を持つことができ、特に以来、開示されなければなりません。
More generally, filters that block some or all mail being sent to (or submitted to) remote systems (other than via provider-supported servers), or that attempt to divert that traffic to their own servers, are, as discussed above, becoming common and SHOULD be disclosed.
より一般的には、上述したように、一部またはすべてに送信されたメール（またはに提出）リモート（プロバイダがサポートするサーバ経由以外の）システム、または独自のサーバーにそのトラフィックをそらすために、その試みを、ブロックフィルタは、ある、一般的になってきておよび開示すべき。
These additional terms, while not as basic to understanding a service offering as the ones identified above, are listed as additional information that a service provider might choose to provide to complement those general definitions. A potential customer might use those that are relevant to construct a list of specific questions to ask, for example.
これらの追加の用語は、上記で特定したものとしてサービス提供を理解するための基本として、付加情報として記載されていないが、サービスプロバイダは、これらの一般的な定義を補完するために提供することを選択するかもしれないという。潜在的な顧客は、たとえば、依頼する具体的な質問のリストを構築するために関連するものをを使用する場合があります。
o Version support.
Oバージョンのサポート。
Does the service include IPv4 support only, both IPv4 and IPv6 support, or IPv6 support only?
サービスは、IPv4とIPv6のサポート、またはIPv6のサポートのみ、両方、IPv4のみのサポートが含まれていますか？
o Authentication support.
O認証のサポート。
Which technical mechanism(s) are used by the service to establish and possibly authenticate connections? Examples might include unauthenticated DHCP, PPP, RADIUS, or HTTP interception.
これは技術的なメカニズム（複数可）を確立し、可能性の接続を認証するために、サービスによって使用されていますか？例としては、認証されていないDHCP、PPP、RADIUS、またはHTTPの傍受などがあります。
o VPNs and Tunnels.
VPNおよびトンネルO。
Is IPSec blocked or permitted? Are other tunneling techniques at the IP layer or below, such as L2TP, permitted? Is there any attempt to block applications-layer tunnel mechanisms such as SSH?
IPSecはブロックまたは許可されていますか？許可などL2TPなどの他のトンネリング技術IP層での以下、ありますか？ SSHなどのアプリケーション層のトンネルメカニズムをブロックする試みはありますか？
o Multicast support
Oマルチキャストサポート
Does the user machine have access to multicast packets and services?
ユーザマシンは、マルチキャストパケットやサービスへのアクセスを持っていますか？
o DNS support.
OのDNSのサポート。
Are users required to utilize DNS servers provided by the service provider, or are DNS queries permitted to reach arbitrary servers?
ユーザーは、サービスプロバイダが提供するDNSサーバーを利用するために必要とされる、またはDNSクエリは、任意のサーバーに到達することが許可されていますか？
o IP-related services.
O IP関連のサービスを提供しています。
Are ICMP messages to and from end user sites generally blocked or permitted? Are specific functions such as ping and traceroute blocked and, if so, at what point in the network?
エンドユーザサイトからのICMPメッセージは、一般的にブロックまたは許可されていますか？ pingやtracerouteのような特定の機能は、ネットワーク内のどの時点で、そうであれば、ブロックされたとされていますか？
o Roaming support.
Oサポートをローミング。
Does the service intentionally include support for IP roaming and, if so, how is this defined? For "broadband" connections, is some dialup arrangement provided for either backup or customer travel? If present, does that arrangement have full access to mailboxes, etc.
サービスは、意図的にIPローミングのサポートが含まれていますと、もしそうなら、これはどのように定義されていますか？ 「ブロードバンド」接続では、バックアップまたは顧客の旅行のいずれかのために提供されるいくつかのダイヤルアップ配置はありますか？存在する場合、その配置がなど、メールボックスへのフルアクセスを持っていません
o Applications services provided.
Oアプリケーションサービスを提供します。
Are email services and/or Web hosting provided as part of the service, and on what basis? An email services listing should identify whether POP3, IMAP4, or Web access are provided and in what combinations, and what types of authentication and privacy services are supported or required for each.
サービスの一部として提供されるメールサービスおよび/またはWebホスティングされており、どのような基準で？リストのメールサービスは、POP3、IMAP4、またはWebアクセスが提供されているかどうかを識別し、どのような組み合わせで、認証およびプライバシーサービスの種類ごとのサポートまたは要求されている必要があります。
o Use and Blocking of Outbound Applications Services.
Oを使用すると、アウトバウンドアプリケーションサービスのブロッキング。
Does the service block use of SMTP or mail submission to other than its own servers or intercept such submissions and route them to its servers? Do its servers restrict the user to use of its domain names on outbound email? (For email specifically, also see Section 3 above.) Is the FTP PASV command supported or blocked? Are blocks or intercepts imposed on other file sharing or file transfer mechanisms, on conferencing applications, or on private applications services?
サービスブロック独自のサーバーやインターセプトなどの提出以外のSMTPやメール提出の使用とそのサーバーへルーティングしていますか？そのサーバーは、アウトバウンド電子メールにそのドメイン名の使用にユーザーを制限しますか？ （電子メールの場合は具体的には、また、上記のセクション3を参照。）FTP PASVコマンドがサポートされたりブロックされていますか？ブロックまたは切片が会議アプリケーションに、他のファイル共有やファイル転送メカニズムに課せられた、またはプライベートなアプリケーションサービスにしていますか？
More generally, the provider should identify any actions of the service to block, restrict, or alter the destination of, the outbound use (i.e., the use of services not supplied by the provider or on the provider's network) of applications services.
より一般的には、プロバイダは、アプリケーションサービス（すなわち、サービスの使用は、プロバイダによって、またはプロバイダのネットワーク上で供給されていない）、ブロックを制限、またはアウトバウンド使用の宛先を変更するために、サービスのすべてのアクションを識別すべきです。
o Blocking of Inbound Applications Services.
インバウンドアプリケーションサービスのOブロッキング。
In addition to issues raised by dynamic or private address space (when present), does the service take any other measures that specifically restrict the connections that can be made to equipment operated by the customer? Specifically, are inbound SMTP, HTTP or HTTPS, FTP, or various peer-to-peer or other connections (possibly including applications not specifically recognized by the provider) prohibited and, if so, which ones?
動的またはプライベートアドレス空間（存在する場合）が提起した問題に加えて、サービスは、特に顧客が運営する機器にすることができる接続を制限し、他の対策を講じていますか？具体的には、インバウンドSMTP、HTTPまたはHTTPS、FTP、又はピア・ツー・ピアまたは他の接続（おそらく特異プロバイダによって認識されないアプリケーションを含む）は、種々のを禁止され、もしそうであれば、どれ？
o Application Content Filtering.
Oアプリケーションコンテンツフィルタリング。
The service should declare whether it provides filtering or protection against worms or denial of service attacks against its customers, virus and spam filtering for its mail services (if any), non-discretionary or "parental control" filtering of content, and so on.
それはワームやそのメールサービスのための顧客、ウイルスやスパムフィルタリングに対するサービス拒否攻撃（もしあれば）、非裁量やコンテンツの「ペアレンタルコントロール」フィルタリングなどに対するフィルタリングや保護を提供するかどうかのサービスを宣言しなければなりません。
o Wiretapping and interception.
盗聴や傍受O。
The service SHOULD indicate whether traffic passing through it is subject to lawful intercept, and whether the provider will make a proactive attempt to inform the user of such an intercept when such notice is legal. Analogous questions can be asked for traffic data that is stored for possible use by law enforcement.
サービスは、それを通過するトラフィックは、合法的傍受の対象となるかどうかを示す必要があり、プロバイダかどうか、そのような通知が合法であるとき、そのような切片をユーザに知らせるための積極的な試みを行います。類似の質問には、法執行機関による可能な使用のために記憶されるトラフィックデータを求めすることができます。
This document is about terminology, not protocols, so it does not raise any particular security issues. However, if the type of terminology that is proposed is widely adopted, it may become easier to identify security-related expectations of particular hosts, LANs, and types of connections.
この文書では、専門用語ではなく、プロトコルについてですので、いずれかの特定のセキュリティ問題を提起しません。提案されている用語の種類が広く採用されている場合は、それが特定のホスト、のLAN、および接続の種類のセキュリティ関連の期待を特定することが容易になることができます。
This document was inspired by an email conversation with Vernon Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been proposals to produce such definitions for many years, that conversation convinced the author that it was finally time to put a strawman on the table to see if the IETF could actually carry it forward. Harald Alvestrand, Brian Carpenter, George Michaelson, Vernon Schryver, and others made several suggestions on the initial draft that resulted in clarifications to the second one and Stephane Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens, Pekka Savola, and Vernon Schryver made very useful suggestions that were incorporated into subsequent versions. Susan Harris also gave the penultimate version an exceptionally careful reading, which is greatly appreciated, as are editorial suggestions by the RFC Editor.
この文書は、バーノンSchryver、ポール・ヴィクシー、およびナサニエルBornsteinとの電子メールの会話に触発されました。長年にわたり、このような定義を生成する提案がなされているが、その会話は、最終的にIETFが実際にそれを前方に運ぶことができるかどうかを確認するためにテーブルの上にstrawmanを置くための時間だった著者を確信させました。ハラルドAlvestrand、ブライアン・カーペンター、ジョージ・マイケルソン、バーノンSchryver、その他は二番目とステファンBortzmeyer、ブライアン・カーペンター、トニー・フィンチ、スーザン・ハリス、デビッドKessens、ペッカSavola、とバーノンに明確になった最初の草案にいくつかの提案を行いましたSchryverは、以降のバージョンに組み込まれた非常に有益な提案をしました。スーザンハリスはまた、最後から二番目のバージョンRFCエディタによって編集の提案がされているように大きく、高く評価され、非常に慎重に読書を与えました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[2] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[3] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
Author's Address
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
電話：+1 617 491 5735 Eメール：john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。