[要約] RFC 4084は、インターネット接続を説明するための用語集であり、インターネット接続の特性や要素を明確に定義することを目的としています。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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や他のプロバイダーは、「インターネット」または「インターネットアクセス」として識別されるさまざまな製品を提供しています。これらの製品はさまざまな種類の機能を提供し、その結果、特定のユーザーや使用に適しているものもあります。たとえば、Webへのアクセスのみを提供するサービス（このコンテキストでは、HTTPおよびHTTPSプロトコルを介してアクセス可能なインターネットの部分）は、ブラウジングや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]で定義されているように、このドキュメントでは、この用語が必要な、または必要な、または資本化される必要があります。
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コミュニティのメンバーの一部の信念にもかかわらず、提案された用語は軽jor的ではないことを意図しています。このドキュメントの特定のサービスまたはモデルの言及は、それの承認を意味するものではなく、市場に存在する、または存在する可能性のあるものの認識のみを意味します。したがって、このドキュメントで説明されている最良の現在のプラクティスは、提供されるべきサービスの種類ではなく、ユーザーに提供されるべき用語と情報に関するものです。
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への接続、つまり、「Webブラウザー」（Firefox、Internet Explorer、Mozilla、Netscape、Lynx、Operaなど）、特に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.) Filtering Web proxies are common with this type of service, and the provider SHOULD indicate whether or not one is present.
このサービスは、サーバーやほとんどのピアツーピア機能をサポートせずにインターネットへのアクセスを提供します。顧客に割り当てられたIPアドレスは動的であり、非公開のアドレススペースから特徴的に割り当てられています。サーバーとピアツーピア関数は、一般に、プライベートアドレスの使用によって必要とされるネットワークアドレス変換（NAT）システムによってサポートされていません。（[2]で与えられたNATのタイプのより正確な分類は、このドキュメントに多少直交しますが、セクション4で説明されているように、追加の用語として提供される場合があります。）フィルタリングWebプロキシは、このタイプのサービスと、およびプロバイダーは、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.
このタイプのサービスでは、Webプロキシのフィルタリングは珍しく、プロバイダーは存在するかどうかを示す必要があります。
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.
o 非公開の住所とNAT。
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.
さらに他の人は、別のネットワークの場所から接続するときにポータブルマシンを再構成する必要性を排除するという理論で、自分のサーバーに電子メールトラフィックを迂回させる（Reroute）。繰り返しますが、特に重大なセキュリティとプライバシーへの影響を与える可能性があるため、そのような迂回を開示する必要があります。
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サポートのみ、IPv4とIPv6の両方のサポート、またはIPv6サポートのみが含まれていますか？
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、半径、またはHTTP傍受が含まれる場合があります。
o VPNs and Tunnels.
o VPNとトンネル。
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またはHTTP、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.
このドキュメントは、Vernon Schryver、Paul Vixie、およびNathaniel Bornsteinとのメールでの会話に触発されました。そのような定義を長年にわたって作成するという提案がありましたが、その会話は著者に、IETFが実際にそれを運ぶことができるかどうかを確認するためにストローマンをテーブルに置く時だと著者に納得させました。ハラルド・アルベスランド、ブライアン・カーペンター、ジョージ・マイケルソン、バーノン・シュリーバーなど、最初のドラフトについていくつかの提案をしたため、2番目のドラフトと、ステファン・ボルツマイヤー、ブライアン・カーペンター、トニー・フィンチ、スーザン・ハリス、デビッド・ケッセン、ペッカ・サヴォラ、ヴァーノノンSchryverは、その後のバージョンに組み込まれた非常に有用な提案を行いました。スーザン・ハリスはまた、最後から2番目のバージョンに非常に慎重な読書を与えました。これは、RFCエディターによる編集上の提案と同様に、非常に高く評価されています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[2] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[3] Gellens、R。およびJ. Klensin、「Message Submission」、RFC 2476、1998年12月。
Author's Address
著者の連絡先
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。