[要約] RFC 3570は、CDI(Content Internetworking)シナリオに関する情報を提供するものであり、異なるネットワーク間でのコンテンツの配信や管理に関するガイドラインを提供しています。その目的は、異なるネットワーク間でのコンテンツの効率的な配信と管理を実現するための手法を提供することです。

Network Working Group                                         P. Rzewski
Request for Comments: 3570                         Media Publisher, Inc.
Category: Informational                                           M. Day
                                                                   Cisco
                                                             D. Gilletti
                                                               July 2003
        

Content Internetworking (CDI) Scenarios

コンテンツインターネットワーク(CDI)シナリオ

Status of this 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 (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

Abstract

概要

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals.

コンテンツを生産ネットワークで使用することを目的とした技術としてインターネットワークを説明する際に、2つのコンテンツネットワークが相互接続を決定したときに発生する可能性のあるイベントのシーケンスの例を提供することが有用です。ここに示されているシナリオは、インターネットワーキングとは何かの具体的な例をいくつか提供しようとしています。また、コンテンツのインターネットワーキング提案を評価するための基礎を提供します。

Table of Contents

目次

   1.  Introduction...................................................2
       1.1.  Terminology..............................................3
   2.  Special Cases of Content Networks..............................3
       2.1.  Publishing Content Network...............................3
       2.2.  Brokering Content Network................................3
       2.3.  Local Request-Routing Content Network....................4
   3.  Content Internetworking Arrangements...........................5
   4.  Content Internetworking Scenarios..............................5
       4.1.  General Content Internetworking..........................6
       4.2.  BCN providing ACCOUNTING INTERNETWORKING and
             REQUEST-ROUTING INTERNETWORKING..........................9
       4.3.  BCN providing ACCOUNTING INTERNETWORKING................11
       4.4.  PCN ENLISTS multiple CNs................................12
       4.5.  Multiple CNs ENLIST LCN.................................13
   5.  Security Considerations.......................................15
       5.1.  Threats to Content Internetworking......................15
           5.1.1.  Threats to the CLIENT.............................15
              5.1.2.  Threats to the PUBLISHER..........................17
           5.1.3.  Threats to a CN...................................17
   6.  Acknowledgements..............................................18
   7.  References....................................................18
   8.  Authors' Addresses............................................19
   9.  Full Copyright Statement......................................20
        
1. Introduction
1. はじめに

In [1], the concept of a "content network" is introduced and described. In addition to describing some general types of content networks, it also describes motivations for allowing content networks to interconnect (defined as "content internetworking").

[1]では、「コンテンツネットワーク」の概念が導入され、説明されています。いくつかの一般的なタイプのコンテンツネットワークを説明することに加えて、コンテンツネットワークが相互接続できるようにする動機(「コンテンツインターネットワーク」として定義)についても説明しています。

In describing content internetworking as a technology targeted for use in production networks, it's useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. Naturally, different types of content networks may be created due to different business motivations, and so many combinations are likely.

コンテンツを生産ネットワークで使用することを目的とした技術としてインターネットワークを説明する際に、2つのコンテンツネットワークが相互接続を決定したときに発生する可能性のあるイベントのシーケンスの例を提供することは便利です。当然のことながら、ビジネスの動機が異なるため、さまざまな種類のコンテンツネットワークが作成される場合があり、多くの組み合わせが可能です。

This document first provides detailed examples of special cases of content networks that are specifically designed to participate in content internetworking (Section 2). We then discuss the steps that would be taken in order to "bring up" or "tear down" a content internetworking arrangement (Section 3). Next we provide some detailed examples of how content networks (such as those from Section 2) could interconnect (Section 4). Finally, we describe any security considerations that arise specifically from the examples presented here (Section 5).

このドキュメントは、最初に、コンテンツインターネットワークに参加するように特別に設計されたコンテンツネットワークの特別なケースの詳細な例を提供します(セクション2)。次に、コンテンツのインターネットワークの取り決めを「育て」、「解体」するために取られる手順について説明します(セクション3)。次に、コンテンツネットワーク(セクション2のものなど)が相互接続できる方法の詳細な例をいくつか提供します(セクション4)。最後に、ここに示す例(セクション5)から特に発生するセキュリティ上の考慮事項について説明します。

The scenarios presented here answer two distinct needs:

ここに示されているシナリオは、2つの異なるニーズに答えます。

1. To provide some concrete examples of what content internetworking is, and

1. インターネットワーキングとは何かの具体的な例を提供するため、そして

2. To provide a basis for evaluating content internetworking proposals.

2. コンテンツのインターネットワーキング提案を評価するための基礎を提供する。

A number of content internetworking systems have been implemented, but there are few published descriptions. One such description is [2].

多くのコンテンツインターネットワークシステムが実装されていますが、公開された説明はほとんどありません。そのような説明の1つは[2]です。

1.1. Terminology
1.1. 用語

Terms in ALL CAPS are defined in [1] except for the following terms defined below in this document: PCN, BCN, and LCN. Additionally, the term SLA is used as an abbreviation for Service Level Agreement.

すべてのキャップの用語は、このドキュメントで以下に定義されている次の用語を除き、[1]で定義されています:PCN、BCN、およびLCN。さらに、SLAという用語は、サービスレベル契約の略語として使用されます。

2. Special Cases of Content Networks
2. コンテンツネットワークの特別なケース

A CN may have REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING interfaces. However, some participating networks may gravitate toward particular subsets of the CONTENT INTERNETWORKING interfaces. Others may be seen differently in terms of how they relate to their CLIENT bases. This section describes these refined cases of the general CN case so they may be available for easier reference in the further development of CONTENT INTERNETWORKING scenarios. The special cases described are the Publishing Content Network, the Brokering Content Network, and the Local Request-Routing Content Network.

CNには、リクエストルーティング、配布、および会計インターフェイスがある場合があります。ただし、一部の参加ネットワークは、コンテンツインターネットワークインターフェイスの特定のサブセットに引き寄せられる場合があります。他の人は、クライアントベースとどのように関係するかという点で異なる方法で見られる場合があります。このセクションでは、一般的なCNケースのこれらの洗練されたケースについて説明するため、コンテンツインターネットワークシナリオのさらなる開発で簡単に参照できるようになります。説明されている特別なケースは、パブリッシングコンテンツネットワーク、ブローカーコンテンツネットワーク、およびローカルリクエストルーティングコンテンツネットワークです。

2.1. Publishing Content Network
2.1. コンテンツネットワークの公開

A Publishing Content Network (PCN), maintained by a PUBLISHER, contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or more CNs. A PCN may contain SURROGATES for the benefit of serving some CONTENT REQUESTS locally, but does not intend to allow its SURROGATES to serve CONTENT on behalf of other PUBLISHERS.

パブリッシャーが維持するパブリッシングコンテンツネットワーク(PCN)には、起源が含まれており、2つ以上のCNと交渉された関係があります。PCNには、いくつかのコンテンツリクエストをローカルで提供するために代理人が含まれている場合がありますが、代理人が他の出版社に代わってコンテンツを提供できるようにするつもりはありません。

Several implications follow from knowing that a particular CN is a PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the PUBLISHER to determine the distribution of CONTENT REQUESTS among ENLISTED CNs. Second, it implies that the PCN need only participate in a subset of CONTENT INTERNETWORKING. For example, a PCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING SYSTEM need only be able to receive ACCOUNTING data, it need not send it.

特定のCNがPCNであることを知ることから、いくつかの意味があります。まず、PCNには、出版社のコンテンツの権威あるリクエストルーティングシステムが含まれています。この取り決めにより、出版社は、入隊したCNS間のコンテンツ要求の分布を決定することができます。第二に、PCNはコンテンツインターネットワークのサブセットにのみ参加する必要があることを意味します。たとえば、PCNの流通インターネットワークシステムは、配布広告を受信できるだけで、送信する必要はありません。同様に、PCNのリクエストルーティングインターネットワークシステムには、領域広告を送信する理由はありません。最後に、PCNの会計インターネットワーキングシステムは、会計データを受信できる必要があるため、送信する必要はありません。

2.2. Brokering Content Network
2.2. ブローカーコンテンツネットワーク

A Brokering Content Network (BCN) is a network that does not operate its own SURROGATES. Instead, a BCN operates only CIGs as a service on behalf other CNs. A BCN may therefore be regarded as a "clearinghouse" for CONTENT INTERNETWORKING information.

ブローカーコンテンツネットワーク(BCN)は、独自のサロゲートを操作しないネットワークです。代わりに、BCNは他のCNSに代わってサービスとしてCIGSのみを運用しています。したがって、BCNは、コンテンツインターネットワーク情報の「クリアリングハウス」と見なされる場合があります。

For example, a BCN may choose to participate in DISTRIBUTION INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to aggregate ADVERTISEMENTS from one set of CNs into a single update stream for the benefit of other CNs. To name a single specific example, a BCN could aggregate CONTENT SIGNALS from CNs that represent PUBLISHERS into a single update stream for the benefit of CNs that contain SURROGATES. A BCN may also choose to participate in ACCOUNTING INTERNETWORKING in order to aggregate utilization data from several CNs into combined reports for CNs that represent PUBLISHERS.

たとえば、BCNは、他のCNSの利益のために、1つのCNSから1つのCNSから単一の更新ストリームに広告を集約するために、インターネットワーキングおよび/またはリクエストのインターネットワークに参加することを選択できます。単一の具体的な例を挙げると、BCNは、サロゲートを含むCNSの利益のために、パブリッシャーを表すCNSからのコンテンツ信号をCNSから集約することができます。BCNは、いくつかのCNSから出版社を代表するCNSの複合レポートに利用データを集約するために、会計インターネットワークに参加することも選択できます。

This definition of a BCN implies that a BCN's CIGs would implement the sending and/or receiving of any combination of ADVERTISEMENTS and ACCOUNTING data as is necessary to provide desired services to other CONTENT NETWORKS. For example, if a BCN is only interested in aggregating ACCOUNTING data on behalf of other CNs, it would only need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.

BCNのこの定義は、BCNのCIGSが、他のコンテンツネットワークに望ましいサービスを提供するために必要な広告と会計データの任意の組み合わせの送信および/または受信を実装することを意味します。たとえば、BCNが他のCNSに代わって会計データを集約することにのみ関心がある場合、CIGSに会計インターネットワークインターフェイスが必要です。

2.3. Local Request-Routing Content Network
2.3. ローカルリクエストルーティングコンテンツネットワーク

Another type of CN is the Local Request-Routing CONTENT NETWORK (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT REQUESTS are always handled by some local SERVER (such as a caching proxy [1]). In this context, "local" is taken to mean that both the CLIENT and SERVER are within the same administrative domain, and there is an administrative motivation for forcing the local mapping. This type of arrangement is common in enterprises where all CONTENT REQUESTS must be directed through a local SERVER for access control purposes.

別のタイプのCNは、ローカルリクエストルーティングコンテンツネットワーク(LCN)です。LCNは、クライアントのコンテンツ要求が常にローカルサーバー(キャッシュプロキシ[1]など)によって常に処理されるネットワークのタイプとして定義されます。これに関連して、「ローカル」は、クライアントとサーバーの両方が同じ管理領域内にあることを意味し、ローカルマッピングを強制するための管理上の動機があることを意味します。このタイプの配置は、すべてのコンテンツ要求をアクセス制御の目的でローカルサーバーを介して指示する必要がある企業で一般的です。

As implied by the name, the LCN creates an exception to the rule that there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a particular item of CONTENT. By directing CONTENT REQUESTS through the local SERVER, CONTENT RESPONSES may be given to CLIENTS without first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an LCN in order to perform DISTRIBUTION into the LCN and receive ACCOUNTING data from it. Note that once SERVERS participate in DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they effectively take on the role of SURROGATES. However, an LCN would not intend to allow its SURROGATES to be accessed by non-local CLIENTS.

名前で暗示されているように、LCNは、特定のコンテンツ項目に単一の権威ある要求ルーティングシステムがあるというルールの例外を作成します。ローカルサーバーを介してコンテンツリクエストを指示することにより、最初に権威あるリクエストルーティングシステムを参照することなく、クライアントにコンテンツの応答が与えられる場合があります。これが真実であることを知っていると、他のCNSは、LCNへの分布を実行し、そこから会計データを受信するためにLCNとの交渉された関係を求めている場合があります。サーバーがディストリビューションインターネットワークと会計インターネットワークに参加すると、彼らは効果的に代理人の役割を引き受けることに注意してください。ただし、LCNは、非ローカルクライアントがその代理人にアクセスできるようにするつもりはありません。

This set of assumptions implies multiple things about the LCN's CONTENT INTERNETWORKING relationships. First, it is implied that the LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be able to send ACCOUNTING data, it need not receive it. Finally, due to the locally defined REQUEST-ROUTING, the LCN would not participate in REQUEST-ROUTING INTERNETWORKING.

この一連の仮定は、LCNのコンテンツインターネットワーク関係に関する複数のことを意味します。第一に、LCNの配布インターネットワークシステムは、配布広告を送信するだけで、それらを受け取る必要がないことを暗示しています。第二に、LCNの会計インターネットワーキングシステムは、会計データを送信できるだけで、受信する必要はないことが暗示されています。最後に、ローカルに定義されたリクエストルーティングにより、LCNはリクエストルーティングインターネットワークに参加しませんでした。

3. Content Internetworking Arrangements
3. コンテンツインターネットワークアレンジメント

When the controlling interests of two CNs decide to interconnect their respective networks (such as for business reasons), it is expected that multiple steps would need to occur.

2つのCNSの制御関心がそれぞれのネットワーク(ビジネス上の理由など)を相互接続することを決定する場合、複数のステップが発生する必要があると予想されます。

The first step would be the creation of a NEGOTIATED RELATIONSHIP. This relationship would most likely take the form of a legal document that describes the services to be provided, cost of services, SLAs, and other stipulations. For example, if an ORIGINATING CN wished to leverage another CN's reach into a particular country, this would be laid out in the NEGOTIATED RELATIONSHIP.

最初のステップは、交渉された関係の創造です。この関係は、提供されるサービス、サービスのコスト、SLA、およびその他の規定を説明する法的文書の形をとる可能性が高いでしょう。たとえば、発生したCNが特定の国に別のCNのリーチを活用したい場合、これは交渉された関係でレイアウトされます。

The next step would be to configure CONTENT INTERNETWORKING protocols on the CIGs of the respective CNs in order to technically support the terms of the NEGOTIATED RELATIONSHIP. To follow our previous example, this could include the configuration of the ENLISTED CN's CIGs in a particular country to send DISTRIBUTION ADVERTISEMENTS to the CIGs of the ORIGINATING CN. In order to configure these protocols, technical details (such as CIG addresses/hostnames and authentication information) would be exchanged by administrators of the respective CNs.

次のステップは、交渉された関係の条件を技術的にサポートするために、それぞれのCNSのCIGSでコンテンツインターネットワークプロトコルを構成することです。以前の例に従うために、これには、特定の国で入隊したCNのCIGSの構成を含めることができ、発信されるCNのCIGに流通広告を送信できます。これらのプロトコルを構成するために、それぞれのCNSの管理者によって技術的な詳細(CIGアドレス/ホスト名や認証情報など)が交換されます。

Note also that some terms of the NEGOTIATED RELATIONSHIP would be upheld through means outside the scope of CDI protocols. These could include non-technical terms (such as financial settlement) or other technical terms (such as SLAs).

また、交渉された関係のいくつかの条件は、CDIプロトコルの範囲外の平均を通じて支持されることに注意してください。これらには、非技術的な用語(金融和解など)またはその他の技術用語(SLAなど)が含まれます。

In the event that the controlling interests of two CNs no longer wish to have their networks interconnected, it is expected that these tasks would be undone. That is, the protocol configurations would be changed to cease the movement of ADVERTISEMENTS and/or ACCOUNTING data between the networks, and the NEGOTIATED RELATIONSHIP would be legally terminated.

2つのCNSの制御された利益がネットワークを相互接続したくない場合、これらのタスクが取り消されると予想されます。つまり、プロトコル構成は、ネットワーク間の広告および/または会計データの動きを停止するために変更され、交渉された関係は法的に終了します。

4. Content Internetworking Scenarios
4. コンテンツインターネットワークシナリオ

This section provides several scenarios that may arise in CONTENT INTERNETWORKING implementations.

このセクションでは、コンテンツインターネットワークの実装で発生する可能性のあるいくつかのシナリオを提供します。

Note that we obviously cannot examine every single permutation. Specifically, it should be noted that:

明らかにすべての単一の順列を調べることができないことに注意してください。具体的には、次のことに注意する必要があります。

o Any one of the interconnected CNs may have other CONTENT INTERNETWORKING arrangements that may or may not be transitive to the relationships being described in the diagram.

o 相互接続されたCNSのいずれかが、図に記載されている関係に換算される場合としない場合がある他のコンテンツのインターネットワークアレンジメントを持っている場合があります。

o The graphical figures do not illustrate the CONTENT REQUEST paths. It is assumed that a REQUEST-ROUTING SYSTEM eventually returns to the CLIENT the IP address of the SURROGATE deemed appropriate to honor the CLIENT's CONTENT REQUEST.

o グラフィカルな図は、コンテンツ要求パスを示していません。リクエストルーティングシステムが最終的にクライアントに戻り、クライアントのコンテンツリクエストを尊重するために適切とみなされるサロゲートのIPアドレスを返すと想定されています。

The scenarios described include a general case, two cases in which BCNs provide limited interfaces, a case in which a PCN enlists the services of multiple CNs, and a case in which multiple CNs enlist the services of an LCN.

説明されているシナリオには、一般的なケース、BCNが限られたインターフェイスを提供する2つのケース、PCNが複数のCNのサービスを採用するケース、および複数のCNSがLCNのサービスを参加させるケースが含まれます。

4.1. General Content Internetworking
4.1. 一般的なコンテンツインターネットワーク

This scenario considers the general case where two or more existing CNs wish to establish a CONTENT INTERNETWORKING relationship in order to provide increased scale and reach for their existing customers. It assumes that all of these CNs already provide REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will continue to provide these services to existing customers as well as offering them to other CNs.

このシナリオでは、2つ以上の既存のCNSが、既存の顧客にスケールとリーチを増やすために、コンテンツのインターネットワーク関係を確立することを望んでいる一般的なケースを考慮しています。これらのすべてのCNSは、すでにリクエストルーティング、流通、会計サービスを提供しており、既存の顧客にこれらのサービスを提供し続け、他のCNに提供し続けると想定しています。

In this scenario, these CNs would interconnect with others via a CIG that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING INTERNETWORKING SYSTEM. The net result of this interconnection would be that a larger set of SURROGATES will now be available to the CLIENTS.

このシナリオでは、これらのCNSは、リクエストルーティングインターネットワーキングシステム、流通インターネットワークシステム、および会計インターネットワーキングシステムを提供するCIGを介して、他のCNと相互接続します。この相互接続の最終的な結果は、クライアントがより大きなサロゲートのセットを利用できるようになることです。

Figure 1 shows three CNs which have interconnected to provide greater scale and reach to their existing customers. They are all participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING INTERNETWORKING, and ACCOUNTING INTERNETWORKING.

図1は、既存の顧客により大きな規模とリーチを提供するために相互接続された3つのCNSを示しています。彼らはすべて、分布インターネットワーク、リクエストのインターネットワーク、および会計インターネットワークに参加しています。

As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:

交渉された関係の結果として、それは次のとも想定されています。

1. CONTENT that has been INJECTED into any one of these ORIGINATING CNs may be distributed into any other ENLISTED CN.

1. これらの発生CNSのいずれかに注入されたコンテンツは、他の入隊CNに分布する場合があります。

2. Commands affecting the DISTRIBUTION of CONTENT may be issued within the ORIGINATING CN, or may also be issued within the ENLISTED CN. The latter case allows local decisions to be made about DISTRIBUTION within the ENLISTED CN, but such commands would not control DISTRIBUTION within the ORIGINATING CN.

2. コンテンツの分布に影響を与えるコマンドは、発信されるCN内で発行される場合がある場合、または入隊したCN内で発行される場合があります。後者のケースでは、入隊したCN内の分布について現地の決定を下すことができますが、そのようなコマンドは、発生するCN内の分布を制御しません。

3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION actions will be made available to the ORIGINATING CN by the ENLISTED CN.

3. クライアントアクセスおよび/または流通アクションに関する会計情報は、入隊したCNによって発生するCNが利用できるようになります。

4. The ORIGINATING CN would provide this ACCOUNTING information to the PUBLISHER based on existing Service Level Agreements (SLAs).

4. 発信されるCNは、既存のサービスレベル契約(SLA)に基づいて、この会計情報を出版社に提供します。

5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within any of the ENLISTED CNs.

5. クライアントによるコンテンツリクエストは、入隊したCNSのいずれか内の代理人に指示される場合があります。

The decision of where to direct an individual CONTENT REQUEST may be dependent upon the DISTRIBUTION and REQUEST-ROUTING policies associated with the CONTENT being requested as well as the specific algorithms and methods used for directing these requests. For example, a REQUEST-ROUTING policy for a piece of CONTENT may indicate multiple versions exist based on the spoken language of a CLIENT. Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN would likely direct a CONTENT REQUEST to a SURROGATE known to be holding a version of CONTENT of a language that matches that of a CLIENT.

個々のコンテンツリクエストをどこに向けるかという決定は、要求されるコンテンツに関連付けられた配布およびリクエストルーティングポリシー、およびこれらのリクエストの指示に使用される特定のアルゴリズムと方法に依存する場合があります。たとえば、コンテンツのリクエストルーティングポリシーは、クライアントの音声言語に基づいて複数のバージョンが存在することを示している場合があります。したがって、入隊したCNのリクエストルーティングシステムは、クライアントのコンテンツのバージョンを保持していることが知られているサロゲートにコンテンツリクエストを指示する可能性があります。

Figure 1 - General CONTENT INTERNETWORKING

図1-一般的なコンテンツインターネットワーク

   +--------------+                               +--------------+
   |     CN A     |                               |     CN B     |
   |..............|   +---------+   +---------+   |..............+
   | REQ-ROUTING  |<=>|         |<=>|         |<=>| REQ-ROUTING  |
   |..............|   | CONTENT |   | CONTENT |   |..............|
   | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
   |..............|   | GATEWAY |   | GATEWAY |   |..............|
   |  ACCOUNTING  |<=>|         |<=>|         |<=>|  ACCOUNTING  |
   +--------------+   +---------+   +---------+   +--------------+
         | ^           \^ \ \       ^/ ^/ ^/           | ^
         v |            \\ \\ \\     // // //            v |
   +--------------+      \\ \\ \\   // // //      +--------------+
   |  SURROGATES  |       \\ v\ v\ /v /v //       |  SURROGATES  |
   +--------------+        \\+---------+//        +--------------+
          ^ |               v|         |v                ^ |
          | |                | CONTENT |                 | |
          | |                |INTWRKING|                 | |
          | |                | GATEWAY |                 | |
          | |                |         |                 | |
          | |                +---------+                 | |
          | |                  ^| ^| ^|                  | |
          | |                  || || ||                  | |
          | |                  |v |v |v                  | |
          | |              +--------------+              | |
          | |              |     CN C     |              | |
          | |              |..............|              | |
          | |              | REQ-ROUTING  |              | |
          | |              |..............|              | |
          \ \              | DISTRIBUTION |             / /
           \ \             |..............|            / /
            \ \            |  ACCOUNTING  |           / /
             \ \           |--------------|          / /
              \ \                | ^                / /
               \ \               v |               / /
                \ \        +--------------+       / /
                 \ \       |  SURROGATES  |      / /
                  \ \      +--------------+     / /
                   \ \           | ^           / /
                    \ \          | |          / /
                     \ \         v |         / /
                      \ \    +---------+    / /
                       \ \-->| CLIENTS |---/ /
                        \----|         |<---/
                             +---------+
        
4.2. BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING INTERNETWORKING
4.2. 会計インターネットワークとリクエストのインターネットワークを提供するBCN

This scenario describes the case where a single entity (BCN A) performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING INTERNETWORKING functions, but has no inherent DISTRIBUTION or DELIVERY capabilities. A potential configuration which illustrates this concept is given in Figure 2.

このシナリオでは、単一のエンティティ(BCN A)が会計インターネットワークとリクエストのインターネットワーク機能を実行するが、固有の配布または配信機能がない場合について説明します。この概念を示す潜在的な構成を図2に示します。

In the scenario shown in Figure 2, BCN A is responsible for collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN A and CN B) to provide a clearinghouse/settlement function, as well as providing a REQUEST-ROUTING service for CN A and CN B.

図2に示すシナリオでは、BCN Aは、複数のコンテンツネットワーク(CN AおよびCN B)から会計情報を収集して、CNA AおよびCN Bのリクエストルーティングサービスを提供するだけでなく、複数のコンテンツネットワーク(CN AおよびCN B)からの会計情報を収集する責任があります。。

In this scenario, CONTENT is injected into either CN A or CN B and its DISTRIBUTION between these CNs is controlled via the DISTRIBUTION INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-ROUTING SYSTEM provided by BCN A is informed of the ability to serve a piece of CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING SYSTEMS within the interconnected CIGs.

このシナリオでは、コンテンツがCN AまたはCN Bのいずれかに注入され、これらのCNS間のその分布は、CIGS内の分布インターネットワークシステムを介して制御されます。BCN Aが提供するリクエストルーティングシステムは、相互接続されたCIG内のリクエストルーティングシステムによって特定のコンテンツネットワークからコンテンツを提供する機能を通知されます。

BCN A collects statistics and usage information via the ACCOUNTING INTERNETWORKING SYSTEM and disseminates that information to CN A and CN B as appropriate.

BCN Aは、会計インターネットワーキングシステムを介して統計と使用情報を収集し、必要に応じてCN AおよびCN Bにその情報を広めます。

As illustrated in Figure 2, there are separate REQUEST-ROUTING SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a given piece of CONTENT this is not a problem. However, each individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING SYSTEM for some portion of its PUBLISHER customers. In this case care must be taken to ensure that the there is one and only one AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given CONTENT object.

図2に示すように、BCN Aが提供するリクエストルーティングシステムが特定のコンテンツの権威あるリクエストルーティングシステムである場合、これは問題ではありません。ただし、各CNは、出版社の顧客の一部に権威あるリクエストルーティングシステムを提供する場合があります。この場合、指定された各コンテンツオブジェクトに対して識別される権威ある要求ルーティングシステムが1つずつあることを確認するために、注意を払う必要があります。

Figure 2 - BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING INTERNETWORKING

図2-会計インターネットワークとリクエストのインターネットワークを提供するBCN

       +--------------+
       |    BCN A     |
       |..............|     +-----------+
       | REQ-ROUTING  |<===>|           |
       |..............|     |  CONTENT  |
       |  ACCOUNTING  |<===>| INTWRKING |
       +--------------+     |  GATEWAY  |
                            |           |
                            +-----------+
                             ^| ^| ^| ^|
   +--------------+         // //   \\ \\         +--------------+
   |     CN A     |        |v |v     |v |v        |     CN B     |
   |..............|   +---------+   +---------+   |..............|
   | REQ-ROUTING  |<=>|         |   |         |<=>| REQ-ROUTING  |
   |..............|   | CONTENT |   | CONTENT |   |..............|
   | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
   |..............|   | GATEWAY |   | GATEWAY |   |..............|
   |  ACCOUNTING  |<=>|         |   |         |<=>|  ACCOUNTING  |
   +--------------+   +---------+   +---------+   +--------------+
         | ^                                             | ^
         v |                                             v |
   +--------------+                               +--------------+
   |  SURROGATES  |                               |  SURROGATES  |
   +--------------+                               +--------------+
                ^ \                               ^ /
                 \ \                             / /
                  \ \                           / /
                   \ \                         / /
                    \ \      +---------+      / /
                     \ \---->| CLIENTS |-----/ /
                      \------|         |<-----/
                             +---------+
        
4.3. BCN providing ACCOUNTING INTERNETWORKING
4.3. 会計インターネットワークを提供するBCN

This scenario describes the case where a single entity (BCN A) performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/ settlement function only. In this scenario, BCN A would enter into NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING as shown in FIGURE 3.

このシナリオでは、単一のエンティティ(BCN A)が会計インターネットワークを実行して、クリアリングハウス/決済機能のみを提供する場合のみを説明しています。このシナリオでは、BCN Aは、図3に示すように、それぞれが独自の分布インターネットウォーキングとリクエストのインターネットワークを実行する複数のCNと交渉された関係を築きます。

Figure 3 - BCN providing ACCOUNTING INTERNETWORKING

図3-会計インターネットワークを提供するBCN

       +--------------+
       |    BCN A     |
       |..............|     +-----------+
       |  ACCOUNTING  |<===>|           |
       +--------------+     |  CONTENT  |
                            | INTWRKING |
                            |  GATEWAY  |
                            |           |
                            +-----------+
                                ^| ^|
   +--------------+            //   \\            +--------------+
   |     CN A     |           |v     |v           |     CN B     |
   |..............|   +---------+   +---------+   |..............|
   | REQ-ROUTING  |<=>|         |<=>|         |<=>| REQ-ROUTING  |
   |..............|   | CONTENT |   | CONTENT |   |..............|
   | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
   |..............|   | GATEWAY |   | GATEWAY |   |..............|
   |  ACCOUNTING  |<=>|         |   |         |<=>|  ACCOUNTING  |
   +--------------+   +---------+   +---------+   +--------------+
         | ^                                             | ^
         v |                                             v |
   +--------------+                               +--------------+
   |  SURROGATES  |                               |  SURROGATES  |
   +--------------+                               +--------------+
                ^ \                               ^ /
                 \ \                             / /
                  \ \                           / /
                   \ \                         / /
                    \ \      +---------+      / /
                     \ \---->| CLIENTS |-----/ /
                      \------|         |<-----/
                             +---------+
        
4.4. PCN ENLISTS multiple CNs
4.4. PCNは複数のCNを募集します

In the previously enumerated scenarios, PUBLISHERS have not been discussed. Much of the time, it is assumed that the PUBLISHERS will allow CNs to act on their behalf. For example, a PUBLISHER may designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a particular CN to aggregate all its ACCOUNTING data, even though that data may originate at SURROGATES in multiple distant CNs. Finally, a PUBLISHER may INJECT content only into a single CN and rely on that CN to ENLIST other CNs to obtain scale and reach.

以前に列挙したシナリオでは、出版社は議論されていません。多くの場合、出版社はCNSが彼らに代わって行動することを許可すると想定されています。たとえば、パブリッシャーは、特定のCNをそのコンテンツの権威あるリクエストルーティングシステムと指定する場合があります。同様に、パブリッシャーは、特定のCNに頼って、そのデータが複数の遠いCNSの代理で発生する可能性がある場合でも、すべての会計データを集約することができます。最後に、出版社はコンテンツを単一のCNにのみ注入し、そのCNに依存して他のCNを登録してスケールとリーチを取得することができます。

However, a PUBLISHER may wish to maintain more control and take on the task of ENLISTING CNs itself, therefore acting as a PCN (Section 2.1). This scenario, shown in Figure 4, describes the case where a PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with multiple CNs. In this scenario, the PCN would operate its own CIG and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships with two or more CNs.

ただし、出版社は、より多くのコントロールを維持し、CNS自体を募集するタスクを引き受けることを望んでいる場合があり、したがってPCNとして機能します(セクション2.1)。図4に示すこのシナリオは、PCNが複数のCNと交渉された関係に直接入りたい場合を説明しています。このシナリオでは、PCNは独自のCIGを操作し、インターネットワーク、会計、および2つ以上のCNとのリクエストインターネットワーキング関係を分配します。

Figure 4 - PCN ENLISTS multiple CNs

図4 -PCNは複数のCNSを募集しています

   +--------------+
   |     PCN      |
   |..............|   +-----------+
   | REQ-ROUTING  |<=>|           |<---\
   |..............|   |  CONTENT  |----\\
   | DISTRIBUTION |<=>| INTWRKING |     \\
   |..............|   |  GATEWAY  |--\   \\
   |  ACCOUNTING  |<=>|           |<-\\   \\
   +--------------+   +-----------+   \\   \\
                        ^| ^| ^|  ^|   \\   ||
   +--------------+     || || ||   \\   ||  ||    +--------------+
   |     CN A     |     |v |v |v    \v  |v  |v    |     CN B     |
   |..............|   +---------+   +---------+   |..............|
   | REQ-ROUTING  |<=>|         |   |         |<=>| REQ-ROUTING  |
   |..............|   | CONTENT |   | CONTENT |   |..............|
   | DISTRIBUTION |<=>|INTWRKING|   |INTWRKING|<=>| DISTRIBUTION |
   |..............|   | GATEWAY |   | GATEWAY |   |..............|
   |  ACCOUNTING  |<=>|         |   |         |<=>|  ACCOUNTING  |
   +--------------+   +---------+   +---------+   +--------------+
         | ^                                             | ^
         v |                                             v |
   +--------------+                               +--------------+
   |  SURROGATES  |                               |  SURROGATES  |
   +--------------+                               +--------------+
                ^ \                               ^ /
                 \ \                             / /
                  \ \                           / /
                   \ \                         / /
                    \ \      +---------+      / /
                     \ \---->| CLIENTS |-----/ /
                      \------|         |<-----/
                             +---------+
        
4.5. Multiple CNs ENLIST LCN
4.5. 複数のCNSがLCNを登録します

A type of CN described in Section 2.3 is the LCN. In this scenario, we imagine a tightly administered CN (such as within an enterprise) has determined that all CONTENT REQUESTS from CLIENTS must be serviced locally. Likely due to a large CLIENT base in the LCN, multiple CNs determine they would like to engage in DISTRIBUTION INTERNETWORKING with the LCN in order to extend control over CONTENT objects held in the LCN's SURROGATES. Similarly, the CNs would like to engage in ACCOUNTING INTERNETWORKING with the LCN in order to receive ACCOUNTING data regarding the usage of the content in the local SURROGATES. This scenario is shown in Figure 5. Although this diagram shows a DISTRIBUTION INTERNETWORKING connection between CN A and CN B, it should be recognized that this connection is optional and not a requirement in this scenario.

セクション2.3で説明されているCNのタイプはLCNです。このシナリオでは、緊密に管理されたCN(エンタープライズ内など)が、クライアントからのすべてのコンテンツリクエストをローカルで修理する必要があると判断したことを想像しています。おそらくLCNのクライアントベースが大きいため、複数のCNSは、LCNの代理に保持されているコンテンツオブジェクトを制御するために、LCNとの配布インターネットワークに従事したいと判断します。同様に、CNSは、ローカル代理のコンテンツの使用に関する会計データを受け取るために、LCNとの会計インターネットワークに従事したいと考えています。このシナリオを図5に示します。この図は、CN AとCN Bの間の分布インターネットワーク接続を示していますが、この接続はオプションであり、このシナリオの要件ではないことを認識する必要があります。

Figure 5 - Multiple CNs ENLIST LCN

図5-複数のCNSがLCNを登録します

   +--------------+                               +--------------+
   |     CN A     |                               |     CN B     |
   +..............|   +---------+   +---------+   |..............+
   | REQ-ROUTING  |<=>|         |<=>|         |<=>| REQ-ROUTING  |
   |..............|   | CONTENT |   | CONTENT |   |..............|
   | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
   |..............|   | GATEWAY |   | GATEWAY |   |..............|
   |  ACCOUNTING  |<=>|         |<=>|         |<=>|  ACCOUNTING  |
   +--------------+   +---------+   +---------+   +--------------+
         | ^              \^ \^       ^/ ^/              | ^
         v |               \\ \\     // //               v |
   +--------------+         \\ \\   // //         +--------------+
   |  SURROGATES  |          v\ v\ /v /v          |  SURROGATES  |
   +--------------+          +---------+          +--------------+
                             |         |
                             | CONTENT |
                             |INTWRKING|
                             | GATEWAY |
                             |         |
                             +---------+
                                ^| ^|
                                || ||
                                |v |v
                           +--------------+
                           |    LCN A     |
                           |..............|
                           | DISTRIBUTION |
                           |..............|
                           |  ACCOUNTING  |
                           |--------------|
                                 | ^
                                 v |
                           +--------------+
                           |  SURROGATES  |
                           +--------------+
                                 | ^
                                 | |
                                 v |
                             +---------+
                             | CLIENTS |
                             |         |
                             +---------+
        
5. Security Considerations
5. セキュリティに関する考慮事項

Security concerns with respect to Content Internetworking can be generally categorized into trust within the system and protection of the system from threats. The trust model utilized with Content Internetworking is predicated largely on transitive trust between the ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORING SYSTEM, and SURROGATES. Network elements within the Content Internetworking system are considered to be "insiders" and therefore trusted.

コンテンツに関するセキュリティの懸念は、一般に、システム内の信頼に分類され、脅威からシステムを保護することができます。コンテンツで使用される信頼モデルは、インターネットワーキングが主にオリジン、リクエストリクエストインターネットワーキングシステム、分布インターネットワークシステム、会計インターネットウォーリングシステム、およびサロゲート間の推移的な信頼に基づいています。コンテンツインターネットワークシステム内のネットワーク要素は、「インサイダー」と見なされるため、信頼されています。

5.1. Threats to Content Internetworking
5.1. コンテンツインターネットワークへの脅威

The following sections document key threats to CLIENTs, PUBLISHERs, and CNs. The threats are classified according to the party that they most directly harm, but, of course, a threat to any party is ultimately a threat to all. (For example, having a credit card number stolen may most directly affect a CLIENT; however, the resulting dissatisfaction and publicity will almost certainly cause some harm to the PUBLISHER and CN, even if the harm is only to those organizations' reputations.)

次のセクションでは、クライアント、出版社、およびCNSに対する重要な脅威を文書化しています。脅威は、彼らが最も直接的に害を及ぼすという当事者に従って分類されますが、もちろん、あらゆる当事者に対する脅威は最終的にはすべての人に対する脅威です。(たとえば、クレジットカード番号が盗まれた場合、クライアントに最も直接影響を与える可能性があります。しかし、結果として生じる不満と宣伝は、たとえ害がそれらの組織の評判にのみ害を及ぼしても、ほぼ確実に出版社とCNにある程度の害を引き起こします。)

5.1.1. Threats to the CLIENT
5.1.1. クライアントに対する脅威
5.1.1.1. Defeat of CLIENT's Security Settings
5.1.1.1. クライアントのセキュリティ設定の敗北

Because the SURROGATE's location may differ from that of the ORIGIN, the use of a SURROGATE may inadvertently or maliciously defeat any location-based security settings employed by the CLIENT. And since the SURROGATE's location is generally transparent to the CLIENT, the CLIENT may be unaware that its protections are no longer in force. For example, a CN may relocate CONTENT from a Internet Explorer user's "Internet Web Content Zone" to that user's "Local Intranet Web Content Zone". If the relocation is visible to the Internet Explorer browser but otherwise invisible to the user, the browser may be employing less stringent security protections than the user is expecting for that CONTENT. (Note that this threat differs, at least in degree, from the substitution of security parameters threat below, as Web Content Zones can control whether or not, for example, the browser executes unsigned active content.)

代理人の位置は起源の位置とは異なる可能性があるため、代理人の使用は、クライアントが採用しているロケーションベースのセキュリティ設定を不注意にまたは悪意に倒す可能性があります。また、代理の位置は一般にクライアントに対して透明であるため、クライアントはその保護がもはや有効ではないことを知らないかもしれません。たとえば、CNは、インターネットエクスプローラーユーザーの「インターネットWebコンテンツゾーン」からそのユーザーの「ローカルイントラネットWebコンテンツゾーン」にコンテンツを再配置する場合があります。リロケーションがインターネットエクスプローラーブラウザに表示されているが、それ以外の場合はユーザーには見えない場合、ブラウザはユーザーがそのコンテンツに期待しているよりも厳しいセキュリティ保護を採用している可能性があります。(この脅威は、少なくとも程度は、セキュリティパラメーターの脅威の代替とは異なります。たとえば、ブラウザが署名されていないアクティブコンテンツを実行するかどうかを制御できるためです。)

5.1.1.2. Delivery of Bad Accounting Information
5.1.1.2. 悪い会計情報の提供

In the case of CONTENT with value, CLIENTs may be inappropriately charged for viewing content that they did not successfully access. Conversely, some PUBLISHERs may reward CLIENTs for viewing certain CONTENT (e.g., programs that "pay" users to surf the Web). Should a CN fail to deliver appropriate accounting information, the CLIENT may not receive appropriate credit for viewing the required CONTENT.

価値のあるコンテンツの場合、クライアントは、アクセスに成功しなかったコンテンツを表示するために不適切に請求される場合があります。逆に、一部の出版社は、特定のコンテンツを表示するためにクライアントに報酬を与える場合があります(たとえば、ユーザーを「支払う」プログラムにWebをサーフィンします)。CNが適切な会計情報の提供に失敗した場合、クライアントは必要なコンテンツを表示するための適切なクレジットを受け取らない場合があります。

5.1.1.3. Delivery of Bad CONTENT
5.1.1.3. 悪いコンテンツの配信

A CN that does not deliver the appropriate CONTENT may provide the user misleading information (either maliciously or inadvertently). This threat can be manifested as a failure of either the DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or REQUEST-ROUTING SYSTEM (request routing to inappropriate SURROGATEs, even though they may have appropriate CONTENT), or both. A REQUEST-ROUTING SYSTEM may also fail by forwarding the CLIENT request when no forwarding is appropriate, or by failing to forward the CLIENT request when forwarding is appropriate.

適切なコンテンツを配信しないCNは、ユーザーに誤解を招く情報を提供する場合があります(悪意のあるまたは不注意に)。この脅威は、配布システム(適切な代理人に配信される不適切なコンテンツ)またはリクエストルーティングシステム(適切なコンテンツがある場合でも不適切な代理人へのリクエストルーティング)の障害として明らかにすることができます。また、リクエストルーティングシステムは、転送が適切でない場合、または転送が適切である場合にクライアントリクエストを転送できない場合にクライアント要求を転送することで失敗する場合があります。

5.1.1.4. Denial of Service
5.1.1.4. サービス拒否

A CN that does not forward the CLIENT appropriately may deny the CLIENT access to CONTENT.

クライアントを適切に転送しないCNは、クライアントがコンテンツへのアクセスを拒否する可能性があります。

5.1.1.5. Exposure of Private Information
5.1.1.5. 個人情報の暴露

CNs may inadvertently or maliciously expose private information (passwords, buying patterns, page views, credit card numbers) as it transmits from SURROGATEs to ORIGINs and/or PUBLISHERs.

CNSは、代理人から起源や出版社に送信される際に、不注意または悪意のある個人情報(パスワード、購入パターン、ページビュー、クレジットカード番号)を公開する場合があります。

5.1.1.6. Substitution of Security Parameters
5.1.1.6. セキュリティパラメーターの代替

If a SURROGATE does not duplicate completely the security facilities of the ORIGIN (e.g., encryption algorithms, key lengths, certificate authorities) CONTENT delivered through the SURROGATE may be less secure than the CLIENT expects.

代理人がオリジンのセキュリティ施設(例えば、暗号化アルゴリズム、キー長、証明書当局など)を完全に複製しない場合、代理を通じて配信されるコンテンツは、クライアントが予想するよりも安全性が低い場合があります。

5.1.1.7. Substitution of Security Policies
5.1.1.7. セキュリティポリシーの代替

If a SURROGATE does not employ the same security policies and procedures as the ORIGIN, the CLIENT's private information may be treated with less care than the CLIENT expects. For example, the operator of a SURROGATE may not have as rigorous protection for the CLIENT's password as does the operator of the ORIGIN server. This threat may also manifest itself if the legal jurisdiction of the SURROGATE differs from that of the ORIGIN, should, for example, legal differences between the jurisdictions require or permit different treatment of the CLIENT's private information.

代理人が起源と同じセキュリティポリシーと手順を使用しない場合、クライアントの個人情報は、クライアントが予想するよりも少ない注意を払って扱われる場合があります。たとえば、サロゲートのオペレーターは、Origin Serverのオペレーターほどクライアントのパスワードを厳密に保護していない場合があります。この脅威は、代理人の法的管轄権が起源の管轄区域と異なる場合、それ自体を明らかにする可能性があります。たとえば、管轄区域間の法的違いは、クライアントの個人情報の異なる扱いを必要とするか許可する必要があります。

5.1.2. Threats to the PUBLISHER
5.1.2. 出版社に対する脅威
5.1.2.1. Delivery of Bad Accounting Information
5.1.2.1. 悪い会計情報の提供

If a CN does not deliver accurate accounting information, the PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it may reward CLIENTs inappropriately. Inaccurate accounting information may also cause a PUBLISHER to pay for services (e.g., content distribution) that were not actually rendered. Invalid accounting information may also effect PUBLISHERs indirectly by, for example, undercounting the number of site visitors (and, thus, reducing the PUBLISHER's advertising revenue).

CNが正確な会計情報を提供しない場合、出版社はコンテンツにアクセスするためにクライアントを請求できない場合や、クライアントに不適切に報酬を与える可能性があります。不正確な会計情報は、出版社が実際にレンダリングされていないサービス(たとえば、コンテンツの分布)の支払いを引き起こす可能性があります。また、無効な会計情報は、たとえば、サイト訪問者の数(したがって、出版社の広告収益を減らす)の数を拡大することにより、出版社に間接的に影響を与える可能性があります。

5.1.2.2. Denial of Service
5.1.2.2. サービス拒否

A CN that does not distribute CONTENT appropriately may deny CLIENTs access to CONTENT.

コンテンツを適切に配布しないCNは、クライアントがコンテンツへのアクセスを拒否する場合があります。

5.1.2.3. Substitution of Security Parameters
5.1.2.3. セキュリティパラメーターの代替

If a SURROGATE does not duplicate completely the security services of the ORIGIN (e.g., encryption algorithms, key lengths, certificate authorities, client authentication) CONTENT stored on the SURROGATE may be less secure than the PUBLISHER prefers.

代理がオリジンのセキュリティサービス(例えば、暗号化アルゴリズム、キー長、証明書当局、クライアント認証)を完全に複製していない場合、サロゲートに保存されているコンテンツは、出版社が好むよりも安全性が低い場合があります。

5.1.2.4. Substitution of Security Policies
5.1.2.4. セキュリティポリシーの代替

If a SURROGATE does not employ the same security policies and procedures as the ORIGIN, the CONTENT may be treated with less care than the PUBLISHER expects. This threat may also manifest itself if the legal jurisdiction of the SURROGATE differs from that of the ORIGIN, should, for example, legal differences between the jurisdictions require or permit different treatment of the CONTENT.

代理人が起源と同じセキュリティポリシーと手順を使用しない場合、コンテンツは出版社が期待するよりも少ない注意で扱われる場合があります。この脅威は、代理の法的管轄権が起源の管轄区域と異なる場合、それ自体も現れる可能性があります。たとえば、管轄区域間の法的違いは、コンテンツの異なる扱いを必要とするか許可する必要があります。

5.1.3. Threats to a CN
5.1.3. CNに対する脅威
5.1.3.1. Bad Accounting Information
5.1.3.1. 悪い会計情報

If a CN is unable to collect or receive accurate accounting information, it may be unable to collect compensation for its services from PUBLISHERs.

CNが正確な会計情報を収集または受信できない場合、出版社からサービスに対する報酬を収集できない場合があります。

5.1.3.2. Denial of Service
5.1.3.2. サービス拒否

Misuse of a CN may make that CN's facilities unavailable, or available only at reduced functionality, to legitimate customers or the CN provider itself. Denial of service attacks can be targeted at a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING SYSTEM.

CNの誤用により、CNの施設は、正当な顧客またはCNプロバイダー自体に利用できないか、機能された機能でのみ利用可能になる可能性があります。サービス拒否攻撃は、CNの会計システム、流通システム、またはリクエストルーティングシステムを対象とすることができます。

5.1.3.3. Transitive Threats
5.1.3.3. 推移的な脅威

To the extent that a CN acts as either a CLIENT or a PUBLISHER (such as, for example, in transitive implementations) such a CN may be exposed to any or all of the threats described above for both roles.

CNがクライアントまたは出版社(たとえば、推移的な実装など)として機能する限り、そのようなCNは、両方の役割について上記の脅威の一部またはすべてにさらされる可能性があります。

6. Acknowledgements
6. 謝辞

The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT), Christian Hoertnagl (IBM), Christian Langkamp (Oxford University), and Don Estberg (Activate).

著者は、フレッド・ダグリス(AT&T)、ラージ・ナイア(シスコ)、ゲイリー・トムリンソン(キャシフロー)、ジョン・シェルバー(カシフロー)、ナリン・ミストリー(ノーテル)、スティーブ・ルドキン(BT)、クリスチャン・ホールンナグル(IBM)の貢献とコメントを認めています。クリスチャンラングカンプ(オックスフォード大学)、およびドンエストバーグ(アクティブ化)。

7. References
7. 参考文献

[1] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.

[1] Day、M.、Cain、B.、Tomlinson、G。and P. Rzewski、「コンテンツインターネットワーク(CDI)のモデル」、RFC 3466、2003年2月。

[2] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal, S., Spatscheck, O. and W. Sturm, "CDN Brokering", Proceedings of the 6th International Workshop on Web Caching and Content Distribution, Boston, MA, June 2001.

[2] Biliris、A.、Cranor、C.、Douglis、F.、Rabinovich、M.、Sibal、S.、Spatscheck、O.、W。Sturm、「CDN Brokering」、第6回国際ワークショップの議事録Webキャッシュとコンテンツの議事録分布、マサチューセッツ州ボストン、2001年6月。

8. Authors' Addresses
8. 著者のアドレス

Mark S. Day Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 US

マークS.デイシスコシステム1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719米国

   Phone: +1 978 936 1089
   EMail: mday@alum.mit.edu
        

Don Gilletti 21 22nd Ave. San Mateo, CA 94403 US

ドンギレッティ21 22nd Ave. San Mateo、CA 94403 US

Phone +1 408 569 6813 EMail: dgilletti@yahoo.com

電話1 408 569 6813メール:dgilletti@yahoo.com

Phil Rzewski 30 Jennifer Place San Francisco, CA 94107 US

Phil Rzewski 30ジェニファープレイスサンフランシスコ、カリフォルニア94107 US

   Phone: +1 650 303 3790
   EMail: philrz@yahoo.com
        
9. 完全な著作権声明

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

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

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 assignees.

上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。

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