draft-ietf-opes-architecture-00.txt		draft-ietf-opes-architecture-01.txt
	Network Working Group Abbie. Barbir		Network Working Group Abbie. Barbir
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: November 1, 2002 R. Chen		Expires: December 10, 2002 R. Chen
	AT&T Labs		AT&T Labs
	M. Hofmann		M. Hofmann
	Bell Labs/Lucent Technologies		Bell Labs/Lucent Technologies
	H. Orman		H. Orman
	The Purple Streak Development		The Purple Streak Development
	R. Penno		R. Penno
	Nortel Networks		Nortel Networks
	G. Tomlinson		G. Tomlinson
	Cacheflow		Cacheflow
	May 3, 2002		June 11, 2002
	An Architecture for Open Pluggable Edge Services (OPES)		An Architecture for Open Pluggable Edge Services (OPES)
	draft-ietf-opes-architecture-00		draft-ietf-opes-architecture-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 1, 2002.		This Internet-Draft will expire on December 10, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	This memo defines an architecture for a cooperative application		This memo defines an architecture for a cooperative application
	service in which a data provider, a data consumer, and zero or more		service in which a data provider, a data consumer, and zero or more
	application entities cooperatively realize a data stream service.		application entities cooperatively realize a data stream service.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 4		2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . 7		2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . 7
	2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 8		2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 8
	2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . 8		2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Security and Privacy Considerations . . . . . . . . . . . . . 10		3. Security and Privacy Considerations . . . . . . . . . . . . . 11
	3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 10		3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2 Primary data flow . . . . . . . . . . . . . . . . . . . . . . 11		3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . 12
	3.3 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . 11		3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . . 12
	3.5 Establishing trust . . . . . . . . . . . . . . . . . . . . . . 12		3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . 13
	3.6 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . 12		4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14		A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	When realizing a data stream service between a provider and a		When realizing a data stream service between a provider and a
	consumer, the need may arise to provision the use of other		consumer, the need may arise to provision the use of other
	application entities, in addition to the provider and consumer. For		application entities, in addition to the provider and consumer. For
	example, some party may wish to customize a data stream as a service		example, some party may wish to customize a data stream as a service
	to a consumer, e.g., a service might customize the data based on the		to a consumer, e.g., a service might customize the data based on the
	customer's geographical locality (e.g., language) or resource		customer's geographical locality (e.g., language) or resource
	availability (e.g., display capabilities).		availability (e.g., display capabilities).
	In some cases it may be impossible to offer the customization service		In some cases in may be beneficial to provide a customization service
	at either the provider or the consumer applications. In this case,		at network location instead of deploying it at either the provider or
	one or more additional application entities may participate in the		the consumer host. For certain services performed on end-user behalf
	data stream service. There are many possible provisioning scenarios		this may be the only option of service deployment. In this case, one
	which make a data stream service attractive. The reader is referred		or more additional application entities may participate in the data
	to [1] for a description of several scenarios.		stream service. There are many possible provisioning scenarios which
			make a data stream service attractive. The reader is referred to [1]
			for a description of several scenarios.
	The document presents the architectural components of Open Pluggable		The document presents the architectural components of Open Pluggable
	Edge Services (OPES) that are needed in order to perform a data		Edge Services (OPES) that are needed in order to perform a data
	stream service. The architecture addresses the IAB considerations		stream service. The architecture addresses the IAB considerations
	described in [2]. These considerations are covered in the various		described in [2]. These considerations are covered in the various
	parts of the document, specifically with respect to tracing (Section		parts of the document, specifically with respect to tracing (Section
	2.6) and security considerations (Section 3).		2.6) and security considerations (Section 3).
	The document is organized as follows: Section 2 introduces the OPES		The document is organized as follows: Section 2 introduces the OPES
	architecture. Section 3 discusses security considerations. Section		architecture. Section 3 discusses security considerations. Section
	skipping to change at page 4, line 29		skipping to change at page 4, line 29
	An OPES entity is an application that operates on a data flow between		An OPES entity is an application that operates on a data flow between
	a data provider application and a data consumer application. OPES		a data provider application and a data consumer application. OPES
	entities can be one of the following:		entities can be one of the following:
	o an OPES service application, which analyzes and possibly		o an OPES service application, which analyzes and possibly
	transforms messages exchanged between the data provider		transforms messages exchanged between the data provider
	application and the data consumer application; or,		application and the data consumer application; or,
	o a data dispatcher, which invokes an OPES service application based		o a data dispatcher, which invokes an OPES service application based
	on filtering rules and application-specific knowledge.		on OPES ruleset and application-specific knowledge.
	In the network, OPES entities reside inside OPES processors. The		In the network, OPES entities reside inside OPES processors. The
	cooperative behavior of OPES entities introduces additional		cooperative behavior of OPES entities introduces additional
	functionality for each data flow provided that it matches the OPES		functionality for each data flow provided that it matches the OPES
	rules.		rules.
	The OPES architecture is largely independent of the protocol that is		In the current work, the data provider and data consumer applications
	used by the OPES entities to exchange data. However, this document		are not considered as OPES entities. The OPES architecture is
	selects HTTP [4] as the example protocol to be used for realizing a		largely independent of the protocol that is used by the OPES entities
	data flow. In this regard, the "protocol" stack of an OPES entity is		to exchange data. However, this document selects HTTP [4] as the
			example protocol to be used for realizing a data flow. In this
			regard, the logical implementation stack of an OPES entity is
	summarized in Figure 1.		summarized in Figure 1.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	OPES entity		+-------------+
			|OPES service |
			| Application |
			| |
			+-------------+
			| Data |
			| Dispatcher |
			| |
	+-------------+		+-------------+
	| |		| |
	| HTTP |		| HTTP |
	| |		| |
	+-------------+		+-------------+
	| TCP/IP |		| TCP/IP |
	+-------------+		+-------------+
	| ... |		| ... |
	+-------------+		+-------------+
	Figure 1: An OPES protocol stack		Figure 1: OPES Logical Implementation
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 1 depicts a "minimal" stack for OPES. However, other		Figure 1 depicts a "minimal" stack for OPES. However, other
	protocols may be present, depending on the functions that are		protocols may be present, depending on the functions that are
	performed by the application.		performed by the application.
	2.2 OPES Flows		2.2 OPES Flows
	An OPES flow is a cooperative undertaking between a data provider		An OPES flow is a cooperative undertaking between a data provider
	application, a data consumer application, one or more OPES service		application, a data consumer application, zero or more OPES service
	applications, and one or more data dispatchers.		applications, and zero or more data dispatchers.
	In order to understand the trust relationships between OPES entities,		In order to understand the trust relationships between OPES entities,
	each is labeled as residing in an administrative domain. However,		each is labeled as residing in an administrative domain. Entities
	depending on provisioning decisions, the entities associated with a		associated with a given OPES flow may reside in one or more
	given OPES flow may reside in one or more administrative domains.		administrative domains.
	For example, Figure 2 depicts a data flow (also known as an "OPES		For example, Figure 2 depicts a data flow (also known as an "OPES
	flow"), that spans two administrative domains.		flow"), that spans two administrative domains.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	consumer administrative domain provider administrative domain		consumer administrative domain provider administrative domain
	+------------------------------+ +------------------------------+		+------------------------------+ +------------------------------+
	| | | |		| | | |
	| data OPES | | OPES data |		| data OPES | | OPES data |
	skipping to change at page 6, line 40		skipping to change at page 6, line 40
	Figure 2: An OPES flow		Figure 2: An OPES flow
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 2 depicts two data dispatchers that are present in the OPES		Figure 2 depicts two data dispatchers that are present in the OPES
	flow. However, the architecture allows for zero or more data		flow. However, the architecture allows for zero or more data
	dispatchers to be present in any flow.		dispatchers to be present in any flow.
	2.3 OPES Rules		2.3 OPES Rules
	The behavior of data dispatchers is governed by a set of filtering		OPES policy regarding services and the data provided to them is
	rules, consisting of a set of conditions and related actions. The		determined by a ruleset consisting of OPES rules. The rules consist
	ruleset is the superset of all OPES rules on the processor. Data		of a set of conditions and related actions. The ruleset is the
	dispatchers invoke OPES service applications that may perform		superset of all OPES rules on the processor. The OPES ruleset
	modifications on an OPES flow. In this model, all data filters are		determines which service applications will operate on a data stream.
			The communication of data stream elements to an application is
			performed by data dispatchers. In this model, all data filters are
	invoked for all data.		invoked for all data.
	In order to ensure predictable behavior the OPES architecture		In order to ensure predictable behavior the OPES architecture
	requires the use of a standardized schema for the purpose of defining		requires the use of a standardized schema for the purpose of defining
	and interpreting the ruleset. The OPES architecture does not require		and interpreting the ruleset. The OPES architecture does not require
	a mechanism for configuring a ruleset into a data dispatcher. This		a mechanism for configuring a ruleset into a data dispatcher. This
	is treated as a local matter for each implementation (e.g., through		is treated as a local matter for each implementation (e.g., through
	the use of a text editor, secure upload protocol, and so on). Future		the use of a text editor, secure upload protocol, and so on). Future
	revisions of the architecture may introduce such a requirement.		revisions of the architecture may introduce such a requirement.
	2.4 Callout Servers		2.4 Callout Servers
	The OPES ruleset is executed within a data dispatcher, which triggers		The evaluation of OPES ruleset determines which service applications
	the execution of local OPES service applications. How the ruleset is		will operate on a data stream. How the ruleset is evaluated is not
	executed is not the subject of the architecture. However, in some		the subject of the architecture, except to note that it must result
	cases it may be useful for the OPES processor to distribute the		in the same unambiguous result in all implementations.
	responsibility of service execution by communicating with one or more
	callout servers (cf., [7]). The situation is illustrated in Figure		In some cases it may be useful for the OPES processor to distribute
	3, which shows a data dispatcher communicating with multiple callout		the responsibility of service evaluation by communicating with one or
	servers as it processes an OPES flow.		more callout servers (cf., [7]). The situation is illustrated in
			Figure 3, which shows a data dispatcher communicating with multiple
			callout servers as it processes an OPES flow.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	+----------+ +---------+ +---------+ +---------+		data callout callout callout
	| data | | callout | | callout | | callout |		dispatcher server server server
	|dispatcher| | server | | server | | server |
	+----------+ +---------+ +---------+ +---------+		+----------+ +---------+ +---------+ +---------+
	| | | | | | | |		| | | | | | | |
	| OCP | | OCP | | OCP | ... | OCP |		| OCP | | OCP | | OCP | ... | OCP |
	| | | | | | | |		| | | | | | | |
	+----------+ +---------+ +---------+ +---------+		+----------+ +---------+ +---------+ +---------+
	| TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP |		| TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP |
	+----------+ +---------+ +---------+ +---------+		+----------+ +---------+ +---------+ +---------+
	|| || || ||		|| || || ||
	||================ || ... ||		||================ || ... ||
	|| || ||		|| || ||
	skipping to change at page 8, line 6		skipping to change at page 8, line 10
	In Figure 3, a data dispatcher invokes the services of a callout		In Figure 3, a data dispatcher invokes the services of a callout
	server by using the OPES callout protocol (OCP). The requirements		server by using the OPES callout protocol (OCP). The requirements
	for the OCP are given in [7]. The OCP is application-agnostic, being		for the OCP are given in [7]. The OCP is application-agnostic, being
	unaware of the semantics of the encapsulated application protocol		unaware of the semantics of the encapsulated application protocol
	(e.g., HTTP). However, the OCP must incorporate a service aware		(e.g., HTTP). However, the OCP must incorporate a service aware
	vectoring capability that parses the data flow according to the		vectoring capability that parses the data flow according to the
	ruleset and delivers the data to the OPES service application that		ruleset and delivers the data to the OPES service application that
	can be local or remote.		can be local or remote.
			In this model, OPES applications may be executed either on the same
			processor (or even in the same application environment) with the
			dispatcher or on a different OPES processor through OCP. The general
			interaction situation is depicted in Figure 4, which illustrates the
			positions and interaction of different components of OPES
			architecture.
			---------------------------------------------------------------------
			+--------------------------+
			| +----------+ |
			| | OPES | |
			| | service | | +----------------+
			| | appl | | | Callout Server |
			| +----------+ | | |
			| || | | +--------+ |
			| +----------------------+ | | | OPES | |
			| | data dispatcher | | | | Service| |
			| +----------------------+ | | | App2 | |
			| | HTTP | OCP | | | +--------+ |
			| +------------| |==========| OCP | |
			| | |---------+ | | +--------+ |
			| | TCP/IP | | +----------------+
			=========| |=============== OPES Data Flow ====
			| +------------+ |
			+--------------------------+
			Figure 4: Interaction of OPES Entities
			---------------------------------------------------------------------
	2.5 Policy Enforcement		2.5 Policy Enforcement
	Data dispatchers include a ruleset that can be compiled from several		Data dispatchers include a ruleset that can be compiled from several
	sources and must resolve into an unambiguous result. The compiled		sources and must resolve into an unambiguous result. The compiled
	ruleset enables an OPES processor to detremine which service		ruleset enables an OPES processor to determain which service
	applications to invoke for which data flow. Accordingly, the data		applications to invoke for which data flow. Accordingly, the data
	dispatcher consitutes an enhanced Policy Enforcement Point (PEP),		dispatcher constitutes an enhanced Policy Enforcement Point (PEP),
	where policy rules are executed, data vectoring and connection		where policy rules are evaluated, service-specific data handlers and
	management is performed, and service-specific data handlers and state		state information are maintained, as depicted in Figure 5.
	information are maintained, as depicted in Figure 4.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	+----------+		+----------+
	| callout |		| callout |
	| server |		| server |
	+----------+		+----------+
	||		||
	||		||
	||		||
	skipping to change at page 8, line 40		skipping to change at page 9, line 31
	| | service | || |		| | service | || |
	| | appl | || |		| | appl | || |
	| +----------+ || |		| +----------+ || |
	| +----------------------+ |		| +----------------------+ |
	OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow		OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow
	| +----------------------+ |		| +----------------------+ |
	| OPES |		| OPES |
	| processor |		| processor |
	+--------------------------+		+--------------------------+
	Figure 4: Data Dispatchers and Policy Enforcement Point		Figure 5: Data Dispatchers and Policy Enforcement Point
	---------------------------------------------------------------------		---------------------------------------------------------------------
	The architecture allows more than one PEP to be present on an OPES		The architecture allows more than one PEP to be present on an OPES
	flow.		flow.
	2.6 Tracing Facility		2.6 Tracing Facility
	The architecture makes no requirements as to how an OPES flow is		The architecture makes no requirements as to how an OPES flow is
	negotiated, provided that it is consistent with the security policy		negotiated, provided that it is consistent with the security policy
	(Section 3) of each administrative domain that hosts the OPES		(Section 3) of each administrative domain that hosts the OPES
	entities that are associated with the flow.		entities that are associated with the flow.
	The OPES architecture requires that each data dispatcher provides		The OPES architecture requires that each data dispatcher provides
	tracing facilities that allow the appropriate verification of its		tracing facilities that allow the appropriate verification of its
	operation. The OPES architecture requires that tracing be feasible		operation. The OPES architecture requires that tracing be feasible
	on the OPES flow per OPES processor using in-band annotation through		on the OPES flow per OPES processor using in-band annotation. One
	header extensions on the application protocol that is used (e.g.,		of those annotations could be a URL with more detailed information on
	HTTP). One of those annotations could be a URL with more detailed		the transformation that occurred to the data on the OPES flow.
	information on the transformation that occurred to the data on the
	OPES flow. Future revisions of the architecture may provide for a		Future revisions of the architecture may provide for a tracing
	tracing facility to be used for subsequent out-of-band analysis.		facility to be used for subsequent out-of-band analysis.
			Providing the ability for in-band annotation MAY require header
			extensions on the application protocol that is used (e.g., HTTP).
			However, the presence of an OPES processor in the data request/
			response flow SHALL NOT interfere with the operations of non-OPES
			aware clients and servers. OPES processors, content server and
			content consumer MAY use OPES extensions to the base protocol (HTTP),
			but support of these extensions SHALL NOT be required.
			OPES processors must obey tracing, reporting and notification
			requirements set by the center of authority in the trust domain to
			which OPES processor belongs. As part of these requirements OPES
			processor may be instructed to reject or ignore such requirements
			that originate from other trust domains.
	3. Security and Privacy Considerations		3. Security and Privacy Considerations
	Each data flow must be secured in accordance with several policies.		Each data flow must be secured in accordance with several policies.
	The primary stakeholders are the data consumer and the data provider.		The primary stakeholders are the data consumer and the data provider.
	The secondary stakeholders are the entities to which they may have		The secondary stakeholders are the entities to which they may have
	delegated their trust. The other stakeholders are the owners of the		delegated their trust. The other stakeholders are the owners of the
	callout servers. Any of these parties may be participants in the		callout servers. Any of these parties may be participants in the
	OPES architecture.		OPES architecture.
	skipping to change at page 10, line 34		skipping to change at page 11, line 34
	In order to delegate fine-grained trust, the parties must convey		In order to delegate fine-grained trust, the parties must convey
	policy information by implicit contract, by a setup protocol, by a		policy information by implicit contract, by a setup protocol, by a
	dynamic negotiation protocol, or in-line with application data		dynamic negotiation protocol, or in-line with application data
	headers.		headers.
	3.1 Trust Domains		3.1 Trust Domains
	The delegation of authority starts at either a data consumer or data		The delegation of authority starts at either a data consumer or data
	provider and moves to more distant entities in a "stepwise" fashion.		provider and moves to more distant entities in a "stepwise" fashion.
	Stepwise means A delegates to B and B delegates to C and so force.		Stepwise means A delegates to B and B delegates to C and so forth.
	The entities thus "colored" by the delegation are said to form a		The entities thus "colored" by the delegation are said to form a
	trust domain with respect to the original delegating party. Here,		trust domain with respect to the original delegating party. Here,
	"Colored" means that if the first step in the chain is the data		"Colored" means that if the first step in the chain is the data
	provider, then the stepwise delegation "colors" the chain with that		provider, then the stepwise delegation "colors" the chain with that
	data "provider" color. The only colors that are defined are data the		data "provider" color. The only colors that are defined are the data
	"provider" and the data "consumer". An OPES processor may be in		"provider" and the data "consumer". Delegation of authority
	several trust domains at any time. There is no restriction on		(coloring) propagates from the content producer start of authority or
	whether the OPES processors are authorized by data consumers and/or		from the content consumer start of authority, that may be different
	data providers. The original party has the option of forbidding or		from the end points in the data flow.
	limiting redelegation.
			An OPES processor may be in several trust domains at any time. There
			is no restriction on whether the OPES processors are authorized by
			data consumers and/or data providers. The original party has the
			option of forbidding or limiting redelegation.
	An OPES processor must have a representation of its trust domain		An OPES processor must have a representation of its trust domain
	memberships that it can report in whole or in part for tracing		memberships that it can report in whole or in part for tracing
	purposes. It must include the name of the party which delegated each		purposes. It must include the name of the party which delegated each
	privilege to it.		privilege to it.
	3.2 Primary data flow		3.2 Callout protocol
	The primary data flow occurs between the data provider and the data
	consumer. OPES must not interfere with the capability of these
	parties to use end-to-end authentication and confidentiality.
	If the primary parties want the assurance that their data does not
	appear in plaintext on network links, but they will permit use of
	plaintext on OPES processors and/or callout servers, then the OPES
	processors must use authentication and encryption between "hops".
	A separate security association must be used for each channel
	established between two OPES processors.
	3.3 Callout protocol
	The determination of whether or not OPES processors will use the		The determination of whether or not OPES processors will use the
	measures that are described in the previous section during their		measures that are described in the previous section during their
	communication with callout servers depends on the details of how the		communication with callout servers depends on the details of how the
	primary parties delegated trust to the OPES processors and the trust		primary parties delegated trust to the OPES processors and the trust
	relationship between the OPES processors and the callout server. If		relationship between the OPES processors and the callout server. If
	the OPES processors are in a single administrative domain with strong		the OPES processors are in a single administrative domain with strong
	confidentiality guarantees, then encryption may be optional. In		confidentiality guarantees, then encryption may be optional. In
	other cases, encryption and strong authentication would be at least		other cases, encryption and strong authentication would be at least
	strongly recommended.		strongly recommended.
	skipping to change at page 11, line 45		skipping to change at page 12, line 32
	The callout servers must be aware of the policy governing the		The callout servers must be aware of the policy governing the
	communication path. They must not, for example, communicate		communication path. They must not, for example, communicate
	confidential information to auxiliary servers outside the trust		confidential information to auxiliary servers outside the trust
	domain.		domain.
	A separate security association must be used for each channel		A separate security association must be used for each channel
	established between an OPES processor and a callout server. The		established between an OPES processor and a callout server. The
	channels must be separate for different primary parties.		channels must be separate for different primary parties.
	3.4 Privacy		3.3 Privacy
	Some data from data consumers is considered "private" or "sensitive",		Some data from data consumers is considered "private" or "sensitive",
	and OPES processors must both advise the primary parties of the their		and OPES processors must both advise the primary parties of the their
	privacy policy and respect the policies of the primary parties. The		privacy policy and respect the policies of the primary parties. The
	privacy information must be conveyed on a per-flow basis.		privacy information must be conveyed on a per-flow basis.
	The callout servers must also participate in handling of private		The callout servers must also participate in handling of private
	data, and they must be prepared to announce their own capabilities		data, and they must be prepared to announce their own capabilities
	and to enforce the policy required by the primary parties.		and to enforce the policy required by the primary parties.
	3.5 Establishing trust		3.4 Establishing trust
	The OPES processor will have configuration policy specifying what		The OPES processor will have configuration policy specifying what
	privileges the callout servers have and how they are to be		privileges the callout servers have and how they are to be
	identified. This is especially critical for third-party (fourth-		identified. This is especially critical for third-party (fourth-
	party, etc.) callout servers. OPES uses standard protocols for		party, etc.) callout servers. OPES uses standard protocols for
	authenticating and otherwise security communication with callout		authenticating and otherwise security communication with callout
	servers.		servers.
	An OPES processor will have a trusted method for receiving		An OPES processor will have a trusted method for receiving
	configuration information such as rules for the data dispatcher,		configuration information such as rules for the data dispatcher,
	trusted callout servers, primary parties that opt-in or opt-out of		trusted callout servers, primary parties that opt-in or opt-out of
	individual services, etc.		individual services, etc.
	3.6 End-to-end Integrity		3.5 End-to-end Integrity
	Digital signature techniques can be used to mark data changes in such		Digital signature techniques can be used to mark data changes in such
	a way that a third-party can verify that the changes are or are not		a way that a third-party can verify that the changes are or are not
	consistent with the originating party's policy. This requires an		consistent with the originating party's policy. This requires an
	inline manner of specifying policy and its binding to data, a trace		inline manner of specifying policy and its binding to data, a trace
	of changes and the party making the changes, and strong identities		of changes and the party making the changes, and strong identities
	and authentication methods.		and authentication methods.
	Strong end-to-end integrity can fulfill some of the functions		Strong end-to-end integrity can fulfill some of the functions
	required by "tracing".		required by "tracing".
	skipping to change at page 16, line 8		skipping to change at page 17, line 8
	EMail: rpenno@nortelnetworks.com		EMail: rpenno@nortelnetworks.com
	Gary Tomlinson		Gary Tomlinson
	Cacheflow		Cacheflow
	EMail: gary@tomlinsongroup.net		EMail: gary@tomlinsongroup.net
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors gratefully acknowledge the contributions of: Marshall T.		The authors gratefully acknowledge the contributions of: Marshall T.
	Rose. (more to come, soon...)		Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). 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 are		kind, provided that the above copyright notice and this paragraph are
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/