draft-ietf-cdi-scenarios-01.txt		rfc3570.txt
	Network Working Group P. Rzewski		Network Working Group P. Rzewski
	Internet-Draft Inktomi		Request for Comments: 3570 Media Publisher, Inc.
	Expires: October 24, 2002 M. Day		Category: Informational M. Day
	Cisco		Cisco
	D. Gilletti		D. Gilletti
	CacheFlow
	April 24, 2002
	Content Internetworking (CDI) Scenarios		Content Internetworking (CDI) Scenarios
	draft-ietf-cdi-scenarios-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This memo provides information for the Internet community. It does
	all provisions of Section 10 of RFC2026.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 24, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	In describing content internetworking as a technology targeted for		In describing content internetworking as a technology targeted for
	use in production networks, it's useful to provide examples of the		use in production networks, it is useful to provide examples of the
	sequence of events that may occur when two content networks decide		sequence of events that may occur when two content networks decide to
	to interconnect. The scenarios presented here seek to provide some		interconnect. The scenarios presented here seek to provide some
	concrete examples of what content internetworking is, and also to		concrete examples of what content internetworking is, and also to
	provide a basis for evaluating content internetworking proposals.		provide a basis for evaluating content internetworking proposals.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................2
	1.1 Terminology....................................................3		1.1. Terminology..............................................3
	2. Special Cases of Content Networks..............................3		2. Special Cases of Content Networks..............................3
	2.1 Publishing Content Network.....................................4		2.1. Publishing Content Network...............................3
	2.2 Brokering Content Network......................................4		2.2. Brokering Content Network................................3
	2.3 Local Request-Routing Content Network..........................4		2.3. Local Request-Routing Content Network....................4
	3. Content Internetworking Arrangements...........................5		3. Content Internetworking Arrangements...........................5
	4. Content Internetworking Scenarios..............................6		4. Content Internetworking Scenarios..............................5
	4.1 General Content Internetworking................................6		4.1. General Content Internetworking..........................6
	4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING		4.2. BCN providing ACCOUNTING INTERNETWORKING and
	INTERNETWORKING................................................9		REQUEST-ROUTING INTERNETWORKING..........................9
	4.3 BCN providing ACCOUNTING INTERNETWORKING......................11		4.3. BCN providing ACCOUNTING INTERNETWORKING................11
	4.4 PCN ENLISTS multiple CNs......................................12		4.4. PCN ENLISTS multiple CNs................................12
	4.5 Multiple CNs ENLIST LCN.......................................13		4.5. Multiple CNs ENLIST LCN.................................13
	5. Security Considerations.......................................15		5. Security Considerations.......................................15
	6. Acknowledgements..............................................15		5.1. Threats to Content Internetworking......................15
	References....................................................15		5.1.1. Threats to the CLIENT.............................15
	Authors' Addresses............................................16		5.1.2. Threats to the PUBLISHER..........................17
	Full Copyright Statement......................................16		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. Introduction
	In [1], the concept of a "content network" is introduced and		In [1], the concept of a "content network" is introduced and
	described. In addition to describing some general types of content		described. In addition to describing some general types of content
	networks, it also describes motivations for allowing content		networks, it also describes motivations for allowing content networks
	networks to interconnect (defined as "content internetworking").		to interconnect (defined as "content internetworking").
	In describing content internetworking as a technology targeted for		In describing content internetworking as a technology targeted for
	use in production networks, it's useful to provide examples of the		use in production networks, it's useful to provide examples of the
	sequence of events that may occur when two content networks decide		sequence of events that may occur when two content networks decide to
	to interconnect. Naturally, different types of content networks may		interconnect. Naturally, different types of content networks may be
	be created due to different business motivations, and so many		created due to different business motivations, and so many
	combinations are likely.		combinations are likely.
	This document first provides detailed examples of special cases of		This document first provides detailed examples of special cases of
	content networks that are specifically designed to participate in		content networks that are specifically designed to participate in
	content internetworking (Section 2). We then discuss the steps that		content internetworking (Section 2). We then discuss the steps that
	would be taken in order to "bring up" or "tear down" a content		would be taken in order to "bring up" or "tear down" a content
	internetworking arrangement (Section 3). Next we provide some		internetworking arrangement (Section 3). Next we provide some
	detailed examples of how content networks (such as those from		detailed examples of how content networks (such as those from Section
	Section 2) could interconnect (Section 4). Finally, we describe any		2) could interconnect (Section 4). Finally, we describe any security
	security considerations that arise specifically from the examples		considerations that arise specifically from the examples presented
	presented here (Section 5).		here (Section 5).
	The scenarios presented here answer two distinct needs:		The scenarios presented here answer two distinct needs:
	1. To provide some concrete examples of what content		1. To provide some concrete examples of what content internetworking
	internetworking is, and		is, and
	2. To provide a basis for evaluating content internetworking		2. To provide a basis for evaluating content internetworking
	proposals.		proposals.
	For details on the architectural framework used in the development		A number of content internetworking systems have been implemented,
	of actual content internetworking protocols and interfaces, refer to		but there are few published descriptions. One such description is
	[2]. For specific examples of systems where content internetworking		[2].
	has been implemented, refer to [5].
	1.1 Terminology		1.1. Terminology
	Terms in ALL CAPS are defined in [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.
	2. Special Cases of Content Networks		2. Special Cases of Content Networks
	A CN is defined in [2] as having REQUEST-ROUTING, DISTRIBUTION, and		A CN may have REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING
	ACCOUNTING interfaces. However, some participating networks may		interfaces. However, some participating networks may gravitate
	gravitate toward particular subsets of the CONTENT INTERNETWORKING		toward particular subsets of the CONTENT INTERNETWORKING interfaces.
	interfaces. Others may be seen differently in terms of how they		Others may be seen differently in terms of how they relate to their
	relate to their CLIENT bases. This section describes these refined		CLIENT bases. This section describes these refined cases of the
	cases of the general CN case so they may be available for easier		general CN case so they may be available for easier reference in the
	reference in the further development of CONTENT INTERNETWORKING		further development of CONTENT INTERNETWORKING scenarios. The
	scenarios. The special cases described are the Publishing Content		special cases described are the Publishing Content Network, the
	Network, the Brokering Content Network, and the Local Request-		Brokering Content Network, and the Local Request-Routing Content
	Routing Content Network.		Network.
	2.1 Publishing Content Network		2.1. Publishing Content Network
	A Publishing Content Network (PCN), maintained by a PUBLISHER,		A Publishing Content Network (PCN), maintained by a PUBLISHER,
	contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or		contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or more
	more CNs. A PCN may contain SURROGATES for the benefit of serving		CNs. A PCN may contain SURROGATES for the benefit of serving some
	some CONTENT REQUESTS locally, but does not intend to allow its		CONTENT REQUESTS locally, but does not intend to allow its SURROGATES
	SURROGATES to serve CONTENT on behalf of other PUBLISHERS.		to serve CONTENT on behalf of other PUBLISHERS.
	Several implications follow from knowing that a particular CN is a		Several implications follow from knowing that a particular CN is a
	PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING		PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING
	SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the		SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the
	PUBLISHER to determine the distribution of CONTENT REQUESTS among		PUBLISHER to determine the distribution of CONTENT REQUESTS among
	ENLISTED CNs. Second, it implies that the PCN need only participate		ENLISTED CNs. Second, it implies that the PCN need only participate
	in a subset of CONTENT INTERNETWORKING. For example, a PCN's		in a subset of CONTENT INTERNETWORKING. For example, a PCN's
	DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive		DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive
	DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a		DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a
	PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send		PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send
	AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING		AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING
	SYSTEM need only be able to receive ACCOUNTING data, it need not		SYSTEM need only be able to receive ACCOUNTING data, it need not send
	send it.		it.
	2.2 Brokering Content Network		2.2. Brokering Content Network
	A Brokering Content Network (BCN) is a network that does not operate		A Brokering Content Network (BCN) is a network that does not operate
	its own SURROGATES. Instead, a BCN operates only CIGs as a service		its own SURROGATES. Instead, a BCN operates only CIGs as a service
	on behalf other CNs. A BCN may therefore be regarded as a		on behalf other CNs. A BCN may therefore be regarded as a
	"clearinghouse" for CONTENT INTERNETWORKING information.		"clearinghouse" for CONTENT INTERNETWORKING information.
	For example, a BCN may choose to participate in DISTRIBUTION		For example, a BCN may choose to participate in DISTRIBUTION
	INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to		INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to
	aggregate ADVERTISEMENTS from one set of CNs into a single update		aggregate ADVERTISEMENTS from one set of CNs into a single update
	stream for the benefit of other CNs. To name a single specific		stream for the benefit of other CNs. To name a single specific
	example, a BCN could aggregate CONTENT SIGNALS from CNs that		example, a BCN could aggregate CONTENT SIGNALS from CNs that
	represent PUBLISHERS into a single update stream for the benefit of		represent PUBLISHERS into a single update stream for the benefit of
	CNs that contain SURROGATES. A BCN may also choose to participate in		CNs that contain SURROGATES. A BCN may also choose to participate in
	ACCOUNTING INTERNETWORKING in order to aggregate utilization data		ACCOUNTING INTERNETWORKING in order to aggregate utilization data
	from several CNs into combined reports for CNs that represent		from several CNs into combined reports for CNs that represent
	PUBLISHERS.		PUBLISHERS.
	This definition of a BCN implies that a BCN's CIGs would implement		This definition of a BCN implies that a BCN's CIGs would implement
	the sending and/or receiving of any combination of ADVERTISEMENTS		the sending and/or receiving of any combination of ADVERTISEMENTS and
	and ACCOUNTING data as is necessary to provide desired services to		ACCOUNTING data as is necessary to provide desired services to other
	other CONTENT NETWORKS. For example, if a BCN is only interested in		CONTENT NETWORKS. For example, if a BCN is only interested in
	aggregating ACCOUNTING data on behalf of other CNs, it would only		aggregating ACCOUNTING data on behalf of other CNs, it would only
	need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.		need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.
	2.3 Local Request-Routing Content Network		2.3. Local Request-Routing Content Network
	Another type of CN is the Local Request-Routing CONTENT NETWORK		Another type of CN is the Local Request-Routing CONTENT NETWORK
	(LCN). An LCN is defined as a type of network where CLIENTS' CONTENT		(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		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		proxy [1]). In this context, "local" is taken to mean that both the
	CLIENT and SERVER are within the same administrative domain, and		CLIENT and SERVER are within the same administrative domain, and
	there is an administrative motivation for forcing the local mapping.		there is an administrative motivation for forcing the local mapping.
	This type of arrangement is common in enterprises where all CONTENT		This type of arrangement is common in enterprises where all CONTENT
	REQUESTS must be directed through a local SERVER for access control		REQUESTS must be directed through a local SERVER for access control
	purposes.		purposes.
	As implied by the name, the LCN creates an exception to the rule		As implied by the name, the LCN creates an exception to the rule that
	that there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a		there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a
	particular item of CONTENT. By directing CONTENT REQUESTS through		particular item of CONTENT. By directing CONTENT REQUESTS through
	the local SERVER, CONTENT RESPONSES may be given to CLIENTS without		the local SERVER, CONTENT RESPONSES may be given to CLIENTS without
	first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing		first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing
	this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with		this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an
	an LCN in order to perform DISTRIBUTION into the LCN and receive		LCN in order to perform DISTRIBUTION into the LCN and receive
	ACCOUNTING data from it. Note that once SERVERS participate in		ACCOUNTING data from it. Note that once SERVERS participate in
	DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they		DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they
	effectively take on the role of SURROGATES. However, an LCN would		effectively take on the role of SURROGATES. However, an LCN would
	not intend to allow its SURROGATES to be accessed by non-local		not intend to allow its SURROGATES to be accessed by non-local
	CLIENTS.		CLIENTS.
	This set of assumptions implies multiple things about the LCN's		This set of assumptions implies multiple things about the LCN's
	CONTENT INTERNETWORKING relationships. First, it is implied that the		CONTENT INTERNETWORKING relationships. First, it is implied that the
	LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send		LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send
	DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is		DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is
	implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be		implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be
	able to send ACCOUNTING data, it need not receive it. Finally, due		able to send ACCOUNTING data, it need not receive it. Finally, due
	to the locally defined REQUEST-ROUTING, the LCN would not		to the locally defined REQUEST-ROUTING, the LCN would not participate
	participate in REQUEST-ROUTING INTERNETWORKING.		in REQUEST-ROUTING INTERNETWORKING.
	3. Content Internetworking Arrangements		3. Content Internetworking Arrangements
	When the controlling interests of two CNs decide to interconnect		When the controlling interests of two CNs decide to interconnect
	their respective networks (such as for business reasons), it is		their respective networks (such as for business reasons), it is
	expected that multiple steps would need to occur.		expected that multiple steps would need to occur.
	The first step would be the creation of a NEGOTIATED RELATIONSHIP.		The first step would be the creation of a NEGOTIATED RELATIONSHIP.
	This relationship would most likely take the form of a legal		This relationship would most likely take the form of a legal document
	document that describes the services to be provided, cost of		that describes the services to be provided, cost of services, SLAs,
	services, SLAs, and other stipulations. For example, if an		and other stipulations. For example, if an ORIGINATING CN wished to
	ORIGINATING CN wished to leverage another CN's reach into a		leverage another CN's reach into a particular country, this would be
	particular country, this would be laid out in the NEGOTIATED		laid out in the NEGOTIATED RELATIONSHIP.
	RELATIONSHIP.
	The next step would be to configure CONTENT INTERNETWORKING		The next step would be to configure CONTENT INTERNETWORKING protocols
	protocols on the CIGs of the respective CNs in order to technically		on the CIGs of the respective CNs in order to technically support the
	support the terms of the NEGOTIATED RELATIONSHIP. To follow our		terms of the NEGOTIATED RELATIONSHIP. To follow our previous
	previous example, this could include the configuration of the		example, this could include the configuration of the ENLISTED CN's
	ENLISTED CN's CIGs in a particular country to send DISTRIBUTION		CIGs in a particular country to send DISTRIBUTION ADVERTISEMENTS to
	ADVERTISEMENTS to the CIGs of the ORIGINATING CN. In order to		the CIGs of the ORIGINATING CN. In order to configure these
	configure these protocols, technical details (such as CIG		protocols, technical details (such as CIG addresses/hostnames and
	addresses/hostnames and authentication information) would be		authentication information) would be exchanged by administrators of
	exchanged by administrators of the respective CNs.		the respective CNs.
	Note also that some terms of the NEGOTIATED RELATIONSHIP would be		Note also that some terms of the NEGOTIATED RELATIONSHIP would be
	upheld through means outside the scope of CDI protocols. These could		upheld through means outside the scope of CDI protocols. These could
	include non-technical terms (such as financial settlement) or other		include non-technical terms (such as financial settlement) or other
	technical terms (such as SLAs).		technical terms (such as SLAs).
	In the event that the controlling interests of two CNs no longer		In the event that the controlling interests of two CNs no longer wish
	wish to have their networks interconnected, it is expected that		to have their networks interconnected, it is expected that these
	these tasks would be undone. That is, the protocol configurations		tasks would be undone. That is, the protocol configurations would be
	would be changed to cease the movement of ADVERTISEMENTS and/or		changed to cease the movement of ADVERTISEMENTS and/or ACCOUNTING
	ACCOUNTING data between the networks, and the NEGOTIATED		data between the networks, and the NEGOTIATED RELATIONSHIP would be
	RELATIONSHIP would be legally terminated.		legally terminated.
	4. Content Internetworking Scenarios		4. Content Internetworking Scenarios
	This section provides several scenarios that may arise in CONTENT		This section provides several scenarios that may arise in CONTENT
	INTERNETWORKING implementations.		INTERNETWORKING implementations.
	Note that we obviously cannot examine every single permutation.		Note that we obviously cannot examine every single permutation.
	Specifically, it should be noted that:		Specifically, it should be noted that:
	o Any one of the interconnected CNs may have other CONTENT		o Any one of the interconnected CNs may have other CONTENT
	INTERNETWORKING arrangements that may or may not be transitive to		INTERNETWORKING arrangements that may or may not be transitive to
	the relationships being described in the diagram.		the relationships being described in the diagram.
	o The graphical figures do not illustrate the CONTENT REQUEST		o The graphical figures do not illustrate the CONTENT REQUEST paths.
	paths. It is assumed that the direction of CONTENT REQUESTS		It is assumed that a REQUEST-ROUTING SYSTEM eventually returns to
	follow the methodology given in [2] and that the end result is		the CLIENT the IP address of the SURROGATE deemed appropriate to
	that a REQUEST-ROUTING SYSTEM eventually returns to the CLIENT		honor the CLIENT's CONTENT REQUEST.
	the IP address of the SURROGATE deemed appropriate to honor the
	CLIENT's CONTENT REQUEST.
	The scenarios described include a general case, two cases in which		The scenarios described include a general case, two cases in which
	BCNs provide limited interfaces, a case in which a PCN enlists the		BCNs provide limited interfaces, a case in which a PCN enlists the
	services of multiple CNs, and a case in which multiple CNs enlist		services of multiple CNs, and a case in which multiple CNs enlist the
	the services of an LCN.		services of an LCN.
	4.1 General Content Internetworking		4.1. General Content Internetworking
	This scenario considers the general case where two or more existing		This scenario considers the general case where two or more existing
	CNs wish to establish a CONTENT INTERNETWORKING relationship in		CNs wish to establish a CONTENT INTERNETWORKING relationship in order
	order to provide increased scale and reach for their existing		to provide increased scale and reach for their existing customers.
	customers. It assumes that all of these CNs already provide REQUEST-		It assumes that all of these CNs already provide REQUEST-ROUTING,
	ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will		DISTRIBUTION, and ACCOUNTING services and that they will continue to
	continue to provide these services to existing customers as well as		provide these services to existing customers as well as offering them
	offering them to other CNs.		to other CNs.
	In this scenario, these CIs would interconnect with others via a CIG		In this scenario, these CNs would interconnect with others via a CIG
	that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a		that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a
	DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING		DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING
	INTERNETWORKING SYSTEM. The net result of this interconnection would		INTERNETWORKING SYSTEM. The net result of this interconnection would
	be that a larger set of SURROGATES will now be available to the		be that a larger set of SURROGATES will now be available to the
	CLIENTS.		CLIENTS.
	FIGURE 1 shows three CNs which have interconnected to provide		Figure 1 shows three CNs which have interconnected to provide greater
	greater scale and reach to their existing customers. They are all		scale and reach to their existing customers. They are all
	participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING		participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING
	INTERNETWORKING, and ACCOUNTING INTERNETWORKING.		INTERNETWORKING, and ACCOUNTING INTERNETWORKING.
	As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:		As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:
	1. CONTENT that has been INJECTED into any one of these ORIGINATING		1. CONTENT that has been INJECTED into any one of these ORIGINATING
	CNs may be distributed into any other ENLISTED CN.		CNs may be distributed into any other ENLISTED CN.
	2. Commands affecting the DISTRIBUTION of CONTENT may be issued		2. Commands affecting the DISTRIBUTION of CONTENT may be issued
	within the ORIGINATING CN, or may also be issued within the		within the ORIGINATING CN, or may also be issued within the
	ENLISTED CN. The latter case allows local decisions to be made		ENLISTED CN. The latter case allows local decisions to be made
	about DISTRIBUTION within the ENLISTED CN, but such commands		about DISTRIBUTION within the ENLISTED CN, but such commands would
	would not control DISTRIBUTION within the ORIGINATING CN.		not control DISTRIBUTION within the ORIGINATING CN.
	3. ACCOUNTING information regarding CLIENT access and/or		3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION
	DISTRIBUTION actions will be made available to the ORIGINATING		actions will be made available to the ORIGINATING CN by the
	CN by the ENLISTED CN.		ENLISTED CN.
	4. The ORIGINATING CN would provide this ACCOUNTING information to		4. The ORIGINATING CN would provide this ACCOUNTING information to
	the PUBLISHER based on existing Service Level Agreements (SLAs).		the PUBLISHER based on existing Service Level Agreements (SLAs).
	5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within		5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within
	any of the ENLISTED CNs.		any of the ENLISTED CNs.
	The decision of where to direct an individual CONTENT REQUEST may be		The decision of where to direct an individual CONTENT REQUEST may be
	dependent upon the DISTRIBUTION and REQUEST-ROUTING policies		dependent upon the DISTRIBUTION and REQUEST-ROUTING policies
	associated with the CONTENT being requested as well as the specific		associated with the CONTENT being requested as well as the specific
	algorithms and methods used for directing these requests. For		algorithms and methods used for directing these requests. For
	example, a REQUEST-ROUTING policy for a piece of CONTENT may		example, a REQUEST-ROUTING policy for a piece of CONTENT may indicate
	indicate multiple versions exist based on the spoken language of a		multiple versions exist based on the spoken language of a CLIENT.
	CLIENT. Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN		Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN would likely
	would likely direct a CONTENT REQUEST to a SURROGATE known to be		direct a CONTENT REQUEST to a SURROGATE known to be holding a version
	holding a version of CONTENT of a language that matches that of a		of CONTENT of a language that matches that of a CLIENT.
	CLIENT.
	FIGURE 1 - General CONTENT INTERNETWORKING		Figure 1 - General CONTENT INTERNETWORKING
	+--------------+ +--------------+		+--------------+ +--------------+
	| CN A | | CN B |		| CN A | | CN B |
	|..............| +---------+ +---------+ |..............+		|..............| +---------+ +---------+ |..............+
	| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |		| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
	|..............| | CONTENT | | CONTENT | |..............|		|..............| | CONTENT | | CONTENT | |..............|
	| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |		| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
	|..............| | GATEWAY | | GATEWAY | |..............|		|..............| | GATEWAY | | GATEWAY | |..............|
	| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |		| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
	+--------------+ +---------+ +---------+ +--------------+		+--------------+ +---------+ +---------+ +--------------+
	| ^ \^ \^ \^ ^/ ^/ ^/ | ^		| ^ \^ \ \ ^/ ^/ ^/ | ^
	v | \\ \\ \\ // // // v |		v | \\ \\ \\ // // // v |
	+--------------+ \\ \\ \\ // // // +--------------+		+--------------+ \\ \\ \\ // // // +--------------+
	| SURROGATES | \\ v\ v\ /v /v // | SURROGATES |		| SURROGATES | \\ v\ v\ /v /v // | SURROGATES |
	+--------------+ \\+---------+// +--------------+		+--------------+ \\+---------+// +--------------+
	^ | v| |v ^ |		^ | v| |v ^ |
	| | | CONTENT | | |		| | | CONTENT | | |
	| | |INTWRKING| | |		| | |INTWRKING| | |
	| | | GATEWAY | | |		| | | GATEWAY | | |
	| | | | | |		| | | | | |
	| | +---------+ | |		| | +---------+ | |
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	\ \ | SURROGATES | / /		\ \ | SURROGATES | / /
	\ \ +--------------+ / /		\ \ +--------------+ / /
	\ \ | ^ / /		\ \ | ^ / /
	\ \ | | / /		\ \ | | / /
	\ \ v | / /		\ \ v | / /
	\ \ +---------+ / /		\ \ +---------+ / /
	\ \-->| CLIENTS |---/ /		\ \-->| CLIENTS |---/ /
	\----| |<---/		\----| |<---/
	+---------+		+---------+
	4.2 BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING		4.2. BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
	INTERNETWORKING		INTERNETWORKING
	This scenario describes the case where a single entity (BCN A)		This scenario describes the case where a single entity (BCN A)
	performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING		performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
	INTERNETWORKING functions, but has no inherent DISTRIBUTION or		INTERNETWORKING functions, but has no inherent DISTRIBUTION or
	DELIVERY capabilities. A potential configuration which illustrates		DELIVERY capabilities. A potential configuration which illustrates
	this concept is given in FIGURE 2.		this concept is given in Figure 2.
	In the scenario shown in FIGURE 2, BCN A is responsible for		In the scenario shown in Figure 2, BCN A is responsible for
	collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN		collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN
	A and CN B) to provide a clearinghouse/settlement function, as well		A and CN B) to provide a clearinghouse/settlement function, as well
	as providing a REQUEST-ROUTING service for CN A and CN B.		as providing a REQUEST-ROUTING service for CN A and CN B.
	In this scenario, CONTENT is injected into either CN A or CN B and		In this scenario, CONTENT is injected into either CN A or CN B and
	its DISTRIBUTION between these CNs is controlled via the		its DISTRIBUTION between these CNs is controlled via the DISTRIBUTION
	DISTRIBUTION INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-		INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-ROUTING SYSTEM
	ROUTING SYSTEM provided by BCN A is informed of the ability to serve		provided by BCN A is informed of the ability to serve a piece of
	a piece of CONTENT from a particular CONTENT NETWORK by the REQUEST-		CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING
	ROUTING SYSTEMS within the interconnected CIGs.		SYSTEMS within the interconnected CIGs.
	BCN A collects statistics and usage information via the ACCOUNTING		BCN A collects statistics and usage information via the ACCOUNTING
	INTERNETWORKING SYSTEM and disseminates that information to CN A and		INTERNETWORKING SYSTEM and disseminates that information to CN A and
	CN B as appropriate.		CN B as appropriate.
	As illustrated in FIGURE 2, there are separate REQUEST-ROUTING		As illustrated in Figure 2, there are separate REQUEST-ROUTING
	SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM		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		provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a
	given piece of CONTENT this is not a problem. However, each		given piece of CONTENT this is not a problem. However, each
	individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING		individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING
	SYSTEM for some portion of its PUBLISHER customers. In this case		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		care must be taken to ensure that the there is one and only one
	AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given		AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given
	CONTENT object.		CONTENT object.
	FIGURE 2 - BCN providing ACCOUNTING INTERNETWORKING and		Figure 2 - BCN providing ACCOUNTING INTERNETWORKING and
	REQUEST-ROUTING INTERNETWORKING		REQUEST-ROUTING INTERNETWORKING
	+--------------+		+--------------+
	| BCN A |		| BCN A |
	|..............| +-----------+		|..............| +-----------+
	| REQ-ROUTING |<===>| |		| REQ-ROUTING |<===>| |
	|..............| | CONTENT |		|..............| | CONTENT |
	| ACCOUNTING |<===>| INTWRKING |		| ACCOUNTING |<===>| INTWRKING |
	+--------------+ | GATEWAY |		+--------------+ | GATEWAY |
	| |		| |
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	+--------------+ +--------------+		+--------------+ +--------------+
	^ \ ^ /		^ \ ^ /
	\ \ / /		\ \ / /
	\ \ / /		\ \ / /
	\ \ / /		\ \ / /
	\ \ +---------+ / /		\ \ +---------+ / /
	\ \---->| CLIENTS |-----/ /		\ \---->| CLIENTS |-----/ /
	\------| |<-----/		\------| |<-----/
	+---------+		+---------+
	4.3 BCN providing ACCOUNTING INTERNETWORKING		4.3. BCN providing ACCOUNTING INTERNETWORKING
	This scenario describes the case where a single entity (BCN A)		This scenario describes the case where a single entity (BCN A)
	performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/		performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/
	settlement function only. In this scenario, BCN A would enter into		settlement function only. In this scenario, BCN A would enter into
	NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their		NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their
	own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING		own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING
	as shown in FIGURE 3.		as shown in FIGURE 3.
	FIGURE 3 - BCN providing ACCOUNTING INTERNETWORKING		Figure 3 - BCN providing ACCOUNTING INTERNETWORKING
	+--------------+		+--------------+
	| BCN A |		| BCN A |
	|..............| +-----------+		|..............| +-----------+
	| ACCOUNTING |<===>| |		| ACCOUNTING |<===>| |
	+--------------+ | CONTENT |		+--------------+ | CONTENT |
	| INTWRKING |		| INTWRKING |
	| GATEWAY |		| GATEWAY |
	| |		| |
	+-----------+		+-----------+
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	+--------------+ +--------------+		+--------------+ +--------------+
	^ \ ^ /		^ \ ^ /
	\ \ / /		\ \ / /
	\ \ / /		\ \ / /
	\ \ / /		\ \ / /
	\ \ +---------+ / /		\ \ +---------+ / /
	\ \---->| CLIENTS |-----/ /		\ \---->| CLIENTS |-----/ /
	\------| |<-----/		\------| |<-----/
	+---------+		+---------+
	4.4 PCN ENLISTS multiple CNs		4.4. PCN ENLISTS multiple CNs
	In the previously enumerated scenarios, PUBLISHERS have not been		In the previously enumerated scenarios, PUBLISHERS have not been
	discussed. Much of the time, it is assumed that the PUBLISHERS will		discussed. Much of the time, it is assumed that the PUBLISHERS will
	allow CNs to act on their behalf. For example, a PUBLISHER may		allow CNs to act on their behalf. For example, a PUBLISHER may
	designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING		designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING
	SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a		SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a
	particular CN to aggregate all its ACCOUNTING data, even though that		particular CN to aggregate all its ACCOUNTING data, even though that
	data may originate at SURROGATES in multiple distant CNs. Finally, a		data may originate at SURROGATES in multiple distant CNs. Finally, a
	PUBLISHER may INJECT content only into a single CN and rely on that		PUBLISHER may INJECT content only into a single CN and rely on that
	CN to ENLIST other CNs to obtain scale and reach.		CN to ENLIST other CNs to obtain scale and reach.
	However, a PUBLISHER may wish to maintain more control and take on		However, a PUBLISHER may wish to maintain more control and take on
	the task of ENLISTING CNs itself, therefore acting as a PCN (Section		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		2.1). This scenario, shown in Figure 4, describes the case where a
	PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with		PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with
	multiple CNs. In this scenario, the PCN would operate its own CIG		multiple CNs. In this scenario, the PCN would operate its own CIG
	and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING		and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING
	INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships		INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships
	with two or more CNs.		with two or more CNs.
	FIGURE 4 - PCN ENLISTS multiple CNs		Figure 4 - PCN ENLISTS multiple CNs
	+--------------+		+--------------+
	| PCN |		| PCN |
	|..............| +-----------+		|..............| +-----------+
	| REQ-ROUTING |<=>| |<---\		| REQ-ROUTING |<=>| |<---\
	|..............| | CONTENT |----\\		|..............| | CONTENT |----\\
	| DISTRIBUTION |<=>| INTWRKING | \\		| DISTRIBUTION |<=>| INTWRKING | \\
	|..............| | GATEWAY |--\ \\		|..............| | GATEWAY |--\ \\
	| ACCOUNTING |<=>| |<-\\ \\		| ACCOUNTING |<=>| |<-\\ \\
	+--------------+ +-----------+ \\ \\		+--------------+ +-----------+ \\ \\
	skipping to change at page 13, line 40		skipping to change at page 13, line 40
	+--------------+ +--------------+		+--------------+ +--------------+
	^ \ ^ /		^ \ ^ /
	\ \ / /		\ \ / /
	\ \ / /		\ \ / /
	\ \ / /		\ \ / /
	\ \ +---------+ / /		\ \ +---------+ / /
	\ \---->| CLIENTS |-----/ /		\ \---->| CLIENTS |-----/ /
	\------| |<-----/		\------| |<-----/
	+---------+		+---------+
	4.5 Multiple CNs ENLIST LCN		4.5. Multiple CNs ENLIST LCN
	A type of CN described in Section 2.3 is the LCN. In this scenario,		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)		we imagine a tightly administered CN (such as within an enterprise)
	has determined that all CONTENT REQUESTS from CLIENTS must be		has determined that all CONTENT REQUESTS from CLIENTS must be
	serviced locally. Likely due to a large CLIENT base in the LCN,		serviced locally. Likely due to a large CLIENT base in the LCN,
	multiple CNs determine they would like to engage in DISTRIBUTION		multiple CNs determine they would like to engage in DISTRIBUTION
	INTERNETWORKING with the LCN in order to extend control over CONTENT		INTERNETWORKING with the LCN in order to extend control over CONTENT
	objects held in the LCN's SURROGATES. Similarly, the CNs would like		objects held in the LCN's SURROGATES. Similarly, the CNs would like
	to engage in ACCOUNTING INTERNETWORKING with the LCN in order to		to engage in ACCOUNTING INTERNETWORKING with the LCN in order to
	receive ACCOUTING data regarding the usage of the content in the		receive ACCOUNTING data regarding the usage of the content in the
	local SURROGATES. This scenario is shown in FIGURE 5.		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.
	FIGURE 5 - Multiple CNs ENLIST LCN		Figure 5 - Multiple CNs ENLIST LCN
	+--------------+ +--------------+		+--------------+ +--------------+
	| CN A | | CN B |		| CN A | | CN B |
	|..............| +---------+ +---------+ |..............+		+..............| +---------+ +---------+ |..............+
	| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |		| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
	|..............| | CONTENT | | CONTENT | |..............|		|..............| | CONTENT | | CONTENT | |..............|
	| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |		| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
	|..............| | GATEWAY | | GATEWAY | |..............|		|..............| | GATEWAY | | GATEWAY | |..............|
	| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |		| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
	+--------------+ +---------+ +---------+ +--------------+		+--------------+ +---------+ +---------+ +--------------+
	| ^ \^ \^ ^/ ^/ | ^		| ^ \^ \^ ^/ ^/ | ^
	v | \\ \\ // // v |		v | \\ \\ // // v |
	+--------------+ \\ \\ // // +--------------+		+--------------+ \\ \\ // // +--------------+
	| SURROGATES | v\ v\ /v /v | SURROGATES |		| SURROGATES | v\ v\ /v /v | SURROGATES |
	skipping to change at page 15, line 7		skipping to change at page 15, line 7
	| ^		| ^
	| |		| |
	v |		v |
	+---------+		+---------+
	| CLIENTS |		| CLIENTS |
	| |		| |
	+---------+		+---------+
	5. Security Considerations		5. Security Considerations
	This section contains security considerations that arise		Security concerns with respect to Content Internetworking can be
	specifically from the examples presented here. For a more general		generally categorized into trust within the system and protection of
	discussion of security in the CDI protocols, see [2].		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.
	Due to the likely reliance on ACCOUNTING data as the basis of		5.1. Threats to Content Internetworking
	payment for services, the likelihood of fraud may be a concern of
	parties that participate in CONTENT INTERNETWORKING. Indeed, it's		The following sections document key threats to CLIENTs, PUBLISHERs,
	easy to imagine fabricating log entries or increasing throughput		and CNs. The threats are classified according to the party that they
	numbers to increase revenue. While this is a difficult problem to		most directly harm, but, of course, a threat to any party is
	solve, there are some approaches to be explored. A useful tool would		ultimately a threat to all. (For example, having a credit card
	be a "fraud detection" analysis tool that is capable of modeling		number stolen may most directly affect a CLIENT; however, the
	human usage patterns and detecting anomalies. It may be logical for		resulting dissatisfaction and publicity will almost certainly cause
	such a tool to be run by a BCN that is acting as an "impartial third		some harm to the PUBLISHER and CN, even if the harm is only to those
	party", ENLISTED only to ensure fairness among participants.		organizations' reputations.)
	Additionally, a BCN may be ENLISTED to perform random audits of
	ACCOUNTING data.		5.1.1. Threats to the CLIENT
			5.1.1.1. Defeat of CLIENT's Security Settings
			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.)
			5.1.1.2. Delivery of Bad Accounting Information
			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.
			5.1.1.3. Delivery of Bad CONTENT
			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.
			5.1.1.4. Denial of Service
			A CN that does not forward the CLIENT appropriately may deny the
			CLIENT access to CONTENT.
			5.1.1.5. Exposure of Private Information
			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.
			5.1.1.6. Substitution of Security Parameters
			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
			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.
			5.1.2. Threats to the PUBLISHER
			5.1.2.1. Delivery of Bad Accounting Information
			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).
			5.1.2.2. Denial of Service
			A CN that does not distribute CONTENT appropriately may deny CLIENTs
			access to CONTENT.
			5.1.2.3. Substitution of Security Parameters
			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
			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.1. Bad Accounting Information
			If a CN is unable to collect or receive accurate accounting
			information, it may be unable to collect compensation for its
			services from PUBLISHERs.
			5.1.3.2. Denial of Service
			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.
			5.1.3.3. Transitive Threats
			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.
	6. Acknowledgements		6. Acknowledgements
	The authors acknowledge the contributions and comments of Fred		The authors acknowledge the contributions and comments of Fred
	Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John		Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John
	Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT),		Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT),
	Christian Hoertnagl (IBM), Christian Langkamp (Oxford University),		Christian Hoertnagl (IBM), Christian Langkamp (Oxford University),
	and Don Estberg (Activate).		and Don Estberg (Activate).
	References		7. References
	[1] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for
	Content Internetworking (CDI)", draft-ietf-cdi-model-01.txt
	(work in progress), February 2002,
	<URL:http://www.ietf.org/internet-drafts/draft-ietf-cdi-model-
	01.txt>.
	[2] Green, M., Cain, B., Tomlinson, G., Thomas, S., and P. Rzewski,
	"Content Internetworking Architectural Overview", draft-ietf-
	cdi-architecture-00.txt (work in progress), February 2002,
	<URL:http://www.ietf.org/internet-drafts/draft-ietf-cdi-
	architecture-00.txt>.
	[3] Gilletti, D., Nair, R., Scharber, J., and J. Guha, "CDN-I
	Internetworking Authentication, Authorization, and Accounting
	Requirements", draft-ietf-cdi-aaa-reqs-00.txt (work in
	progress), February 2002,
	<URL:http://www.ietf.org/internet-drafts/draft-ietf-cdi-aaa-
	reqs-00.txt>.
	[4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to		[1] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
	Accounting Management", RFC 2975, October 2000,		Content Internetworking (CDI)", RFC 3466, February 2003.
	<URL:ftp://ftp.isi.edu/in-notes/rfc2975.txt>.
	[5] Douglis, F., Chaudhri, I. and P. Rzewski, "Known Mechanisms for		[2] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal, S.,
	Content Internetworking", draft-douglis-cdi-known-mech-00.txt,		Spatscheck, O. and W. Sturm, "CDN Brokering", Proceedings of the
	November 2001,		6th International Workshop on Web Caching and Content
	<URL:http://www.ietf.org/internet-drafts/draft-douglis-cdi-		Distribution, Boston, MA, June 2001.
	known-mech-00.txt>.
	Authors' Addresses		8. Authors' Addresses
	Mark S. Day		Mark S. Day
	Cisco Systems		Cisco Systems
	135 Beaver Street		1414 Massachusetts Avenue
	Waltham, MA 02452		Boxborough, MA 01719
	US		US
	Phone: +1 781 663 8310		Phone: +1 978 936 1089
	EMail: markday@cisco.com		EMail: mday@alum.mit.edu
	Don Gilletti		Don Gilletti
	CacheFlow, Inc.		21 22nd Ave.
	441 Moffett Park Drive		San Mateo, CA 94403
	Sunnyvale, CA 94089 USA
	US		US
	Phone: +1 408 543 0437		Phone +1 408 569 6813
	EMail: don@cacheflow.com		EMail: dgilletti@yahoo.com
	Phil Rzewski		Phil Rzewski
	Inktomi		30 Jennifer Place
	4100 East Third Avenue		San Francisco, CA 94107
	MS FC2-4
	Foster City, CA 94404
	US		US
	Phone +1 650 653 2487		Phone: +1 650 303 3790
	Email: philr@inktomi.com		EMail: philrz@yahoo.com
	Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph are
	are included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	Funding for the RFC editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 73 change blocks.
	228 lines changed or deleted		317 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/