draft-ietf-opes-end-comm-01.txt		draft-ietf-opes-end-comm-02.txt
	Network Working Group A. Barbir		Network Working Group A. Barbir
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: March 12, 2004 September 12, 2003		Expires: March 18, 2004 September 18, 2003
	OPES processor and end points communications		OPES processor and end points communications
	draft-ietf-opes-end-comm-01		draft-ietf-opes-end-comm-02
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 30		skipping to change at page 1, line 30
	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 March 12, 2004.		This Internet-Draft will expire on March 18, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	This memo documents tracing requirements for Open Pluggable Edge		This memo documents tracing requirements for Open Pluggable Edge
	Services (OPES).		Services (OPES).
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	4. Requirements for OPES processors . . . . . . . . . . . . . . 8		4. Requirements for OPES processors . . . . . . . . . . . . . . 8
	5. Requirements for callout servers . . . . . . . . . . . . . . 9		5. Requirements for callout servers . . . . . . . . . . . . . . 9
	6. Privacy considerations . . . . . . . . . . . . . . . . . . . 10		6. Privacy considerations . . . . . . . . . . . . . . . . . . . 10
	6.1 Tracing and Trust Domains . . . . . . . . . . . . . . . . . 10		6.1 Tracing and Trust Domains . . . . . . . . . . . . . . . . . 10
	7. How to Support Tracing . . . . . . . . . . . . . . . . . . . 11		7. How to Support Tracing . . . . . . . . . . . . . . . . . . . 11
	7.1 Tracing and OPES System Granularity . . . . . . . . . . . . 11		7.1 Tracing and OPES System Granularity . . . . . . . . . . . . 11
	7.2 Requirements for In-Band Tracing . . . . . . . . . . . . . . 12		7.2 Requirements for In-Band Tracing . . . . . . . . . . . . . . 12
	7.2.1 Tracing Information Granularity and Persistence levels		7.2.1 Tracing Information Granularity and Persistence levels
	Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12		Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 13		7.3 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 13
	7.4 Tracing scenarios and examples . . . . . . . . . . . . . . . 13		8. Tracing Examples . . . . . . . . . . . . . . . . . . . . . . 14
	8. Optional Notification . . . . . . . . . . . . . . . . . . . 14		8.1 Single OPES Processor: Detailed Trace . . . . . . . . . . . 14
	9. IANA considerations . . . . . . . . . . . . . . . . . . . . 16		8.2 Single OPES Processor: Partial Trace . . . . . . . . . . . . 15
	10. Security Considerations . . . . . . . . . . . . . . . . . . 17		8.3 Multiple OPES Processors: Full Trace . . . . . . . . . . . . 15
	Normative References . . . . . . . . . . . . . . . . . . . . 18		8.4 Multiple OPES Processors: Partial Trace . . . . . . . . . . 16
	Informative References . . . . . . . . . . . . . . . . . . . 19		9. Optional Notification . . . . . . . . . . . . . . . . . . . 18
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 19		10. IANA considerations . . . . . . . . . . . . . . . . . . . . 20
	A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		11. Security Considerations . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . 21		Normative References . . . . . . . . . . . . . . . . . . . . 22
			Informative References . . . . . . . . . . . . . . . . . . . 23
			Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
			A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . 25
	1. Introduction		1. Introduction
	The Open Pluggable Edge Services (OPES) architecture [8] enables		The Open Pluggable Edge Services (OPES) architecture [8] enables
	cooperative application services (OPES services) between a data		cooperative application services (OPES services) between a data
	provider, a data consumer, and zero or more OPES processors. The		provider, a data consumer, and zero or more OPES processors. The
	application services under consideration analyze and possibly		application services under consideration analyze and possibly
	transform application-level messages exchanged between the data		transform application-level messages exchanged between the data
	provider and the data consumer.		provider and the data consumer.
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	the execution of service applications local to the OPES processor.		the execution of service applications local to the OPES processor.
	Alternatively, the OPES processor can distribute the responsibility		Alternatively, the OPES processor can distribute the responsibility
	of service execution by communicating and collaborating with one or		of service execution by communicating and collaborating with one or
	more remote callout servers. As described in [8], an OPES processor		more remote callout servers. As described in [8], an OPES processor
	communicates with and invokes services on a callout server by using a		communicates with and invokes services on a callout server by using a
	callout protocol.		callout protocol.
	The work specify the requirements for providing tracing functionality		The work specify the requirements for providing tracing functionality
	for the OPES architecture [8]. This document specifies tracing		for the OPES architecture [8]. This document specifies tracing
	mechanisms that the OPES architecture could provide that enable data		mechanisms that the OPES architecture could provide that enable data
	provider application to detect inappropriate clinet centric actions		provider application to detect inappropriate client centric actions
	by OPES entities. The work focus on developing tracing requirements		by OPES entities. The work focus on developing tracing requirements
	that can be used to fulfil the notification and Non-Blocking		that can be used to fulfill the notification and Non-Blocking
	requirements [2].		requirements [2].
	In the OPES architecture document [8], there is a requirement of		In the OPES architecture document [8], there is a requirement of
	relaying tracing information in-band. This work investigates this		relaying tracing information in-band. This work investigates this
	possibility and discusses possible methods that could be used to		possibility and discusses possible methods that could be used to
	detect faulty OPES processors or callout servers by end points in an		detect faulty OPES processors or callout servers by end points in an
	OPES flow.		OPES flow.
	The document is organized as follows: Section 2 defines OPES Domain		The document is organized as follows: Section 2 defines OPES Domain
	and OPES System. Section 3 discusses entities that are traceable in		and OPES System. Section 3 discusses entities that are traceable in
	an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES		an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES
	systems and callout servers. Section 6 focus on Tracing and Trust		systems and callout servers. Section 6 focus on Tracing and Trust
	Domains. Section 7 discusses how to support tracing and provides uses		Domains. Section 7 discusses how to support tracing and provides uses
	cases. Section 8 examines Optional Notofication. Section 9 looks		cases. Section 8 provides some examples of traces. Section 9 examines
	into IANA considerations. Section 10 examines security		Optional Notification. Section 9 looks into IANA considerations.
	considerations.		Section 10 examines security considerations.
	2. OPES Domain and OPES System		2. OPES Domain and OPES System
	This sections clarifies the terms OPES system and OPES Domain [8].		This sections clarifies the terms OPES system and OPES Domain [8].
	These terms are needed in order to define what is traceable in an		These terms are needed in order to define what is traceable in an
	OPES Flow [8].		OPES Flow [8].
	An OPES domain describes the collection of OPES entities that a		An OPES domain describes the collection of OPES entities that a
	single provider operates. OPES domains can be based on trust or other		single provider operates. OPES domains can be based on trust or other
	operational boundaries. All elements of an "OPES Domain" MUST be in		operational boundaries. All entities of an "OPES Domain" MUST be in
	the same trust domain. This would be independent of any specific OPES		the same trust domain. This would be independent of any specific OPES
	flow.		Flow.
	An OPES system consists of a limited set of OPES entities, parts of a		An OPES system consists of a limited set of OPES entities, parts of a
	single or of multiple OPES operators domains, organized by (or on		single or of multiple OPES domains, organized by (or on behalf) of
	behalf) of either a data provider application or a data consumer		either a data provider application or a data consumer application to
	application to perform authorized services on a given application		perform authorized services on a given application message. Each OPES
	message. Each OPES entity in an OPES system MUST be directly		entity in an OPES system MUST be directly addressable at the IP level
	addressable on IP level by a data consumer application.		by a data consumer application.
	An OPES system can be formed in a recursive manner. An OPES system		An OPES system can be formed in a recursive manner. An OPES system
	can start with either a data provider application or a data consumer		can start with either a data provider application or a data consumer
	application (for a given message). The OPES system then includes any		application (for a given message). The OPES system then includes any
	OPES entity trusted by (accepting authority from) an entity that is		OPES entity trusted by (accepting authority from) an entity that is
	already in the OPES system. The trust and authority delegation is		already in the OPES system. The trust and authority delegation is
	viewed in the context of the given application message.		viewed in the context of the given application message.
	As implied by the above definition, some OPES entities in the system		As implied by the above definition, some OPES entities in the system
	may not participate in the processing of a given message.		MAY not participate in the processing of a given message.
	An OPES domain MUST not be an OPES sub-system. An OPES domain MUST		An OPES domain MUST not be an OPES sub-system. An OPES domain MUST
	require external resources to provide services. An OPES domain is a		require external resources to provide services. An OPES domain is a
	part of an OPES system belonging to a given operator. OPES domains		part of an OPES system belonging to a given operator. OPES domains
	have no incidence on the structure of an OPES system, but they may		have no incidence on the structure of an OPES system, but they may
	influence its organization for different reasons such as security,		influence its organization for different reasons such as security,
	payment, quality of service, delivery parameters among others.		payment, quality of service, delivery parameters among others.
	In Figure 1 an OPES Flow is shown that traverses across various OPES		In Figure 1 an OPES Flow is shown that traverses across various OPES
	Domains. A data consumer application MUST be able to recive tracing		Domains starting from a data provider application. A data consumer
	information on per message basis that enable it to determine the set		application MUST be able to receive tracing information on per
	of transformations that were perfomed on the data for a particular		message basis that enable it to determine the set of transformations
	OPES Flow. The formation of an OPES flow can be static or dynamic,		that were performed on the data for a particular OPES Flow. The
	meaning that the determination of which OPES Domains will participate		formation of an OPES Flow can be static or dynamic, meaning that the
	in a given OPES Flow (per message basis) can be a function of		determination of which OPES Domains will participate in a given OPES
	business arrangements.		Flow (per message basis) can be a function of business arrangements.
	+------------------------------------------+		+------------------------------------------+
	| Data Consumer Application |		| Data Consumer Application |
	+------------------------------------------+		+------------------------------------------+
	^		^
	|		|
	+-------------------------------------------+		+-------------------------------------------+
	| OPES System | O |		| OPES System | O |
	| | |		| | |
	| +-------------------------+ | P |		| +-------------------------+ | P |
	skipping to change at page 6, line 10		skipping to change at page 6, line 10
	| |		| |
	+-------------------------------------------+		+-------------------------------------------+
	Figure 1: OPES System		Figure 1: OPES System
	3. OPES Tracing		3. OPES Tracing
	Before discussing what is traceable in an OPES flow, it is beneficial		Before discussing what is traceable in an OPES flow, it is beneficial
	to define what tracing means. Tracing is defined as the inclusion of		to define what tracing means. Tracing is defined as the inclusion of
	necessary information within a message in an OPES flow that could be		necessary information within a message in an OPES flow that could be
	used to identify the set of transformations or adpatations that have		used to identify the set of transformations or adaptations that have
	been performed on its content in an OPES System before its delivery		been performed on its content in an OPES System before its delivery
	to an end point (the data consumer application).		to an end point (for example, the data consumer application).
	o OPES trace: application message information about OPES entities in		o OPES trace: application message information about OPES entities in
	an OPES System that adapted that message.		an OPES System that adapted that message.
	o OPES tracing: the process of including, manipulating, and		o OPES tracing: the process of including, manipulating, and
	interpreting an OPES trace in an OPES System.		interpreting an OPES trace in an OPES System.
	To emphasize, the above definition means that OPES tracing SHOULD be		To emphasize, the above definition means that OPES tracing SHOULD be
	performed on per message basis. Trace format is dependent on the		performed on per message basis. Trace format is dependent on the
	application protocol that is being adapted by OPES. Data consumer		application protocol that is being adapted by OPES. Data consumer
	skipping to change at page 6, line 39		skipping to change at page 6, line 39
	o Providers may be hesitant to reveal information about their		o Providers may be hesitant to reveal information about their
	internal network infrastructure.		internal network infrastructure.
	o Within a service provider network, OPES processors may be		o Within a service provider network, OPES processors may be
	configured to use non-routable, private IP addresses.		configured to use non-routable, private IP addresses.
	o A Data consumer applications would prefer to have a single point		o A Data consumer applications would prefer to have a single point
	of contact regarding the trace information.		of contact regarding the trace information.
	o TBD
	3.1 What is traceable in an OPES Flow?		3.1 What is traceable in an OPES Flow?
	This section focuses on identifying the traceable entities in an OPES		This section focuses on identifying the traceable entities in an OPES
	Flow. Tracing information MUST be able to provide a data consumer		Flow. Tracing information MUST be able to provide a data consumer
	application with useful information without tracing the exact OPES		application with useful information without tracing the exact OPES
	Processor or callout servers that adapted the data. It is up to the		Processor or callout servers that adapted the data. It is up to the
	OPES service provider to have maintained appropriate internal		OPES service provider to have maintained appropriate internal
	detailed traces to find the answer to the data consumer applications		detailed traces to find the answer to the data consumer applications
	inquiry.		inquiry.
	skipping to change at page 7, line 20		skipping to change at page 7, line 18
	o An OPES processor SHOULD add its entry to the trace.		o An OPES processor SHOULD add its entry to the trace.
	o An OPES service SHOULD add its entry to the trace.		o An OPES service SHOULD add its entry to the trace.
	o An OPES entity MAY manage trace information from entities that are		o An OPES entity MAY manage trace information from entities that are
	under its control. For example, an OPES processor may add or		under its control. For example, an OPES processor may add or
	remove callout service entries in order to manage the size of a		remove callout service entries in order to manage the size of a
	trace. Other considerations include:		trace. Other considerations include:
	* The OPES processor may have a fixed configuration that enable		* The OPES processor MAY have a fixed configuration that enable
	it to respond to tracing inquires.		it to respond to tracing inquires.
	* The OPES processor may insert a summary of the services that it		* The OPES processor MAY insert a summary of the services that it
	controls. The summary can be used to respond to tracing		controls. The summary can be used to respond to tracing
	inquiries.		inquiries.
	* The OPES processor may package tracing information related to		* The OPES processor MAY package tracing information related to
	the entities that it control based on the policy of a given		the entities that it control based on the policy of a given
	OPES System.		OPES System.
	From an OPES context, a good tracing approach is similar to a trouble		From an OPES context, a good tracing approach is similar to a trouble
	ticket ready for submission to a known address. The trace in itself		ticket ready for submission to a known address. The trace in itself
	is not necessarily a detailed description of what has happened. It is		is not necessarily a detailed description of what has happened. It is
	the resposibility of the operator to resolve the problems.		the responsibility of the operator to resolve the problems.
	3.2 Requirements for Information Related to Traceable Entities?		3.2 Requirements for Information Related to Traceable Entities?
	The requirements for information as related to entities that are		The requirements for information as related to entities that are
	terceable in an OPES flow are:		traceable in an OPES flow are:
	o The privacy policy at the time it dealt with the message		o The privacy policy at the time it dealt with the message
	o Identification of the party responsible for setting and enforcing		o Identification of the party responsible for setting and enforcing
	that policy		that policy
	o Information pointing to a technical contact		o Information pointing to a technical contact
	o Information that identifies, to the technical contact, the OPES		o Information that identifies, to the technical contact, the OPES
	processors involved in processing the messag		processors involved in processing the message.
	o TBD
	4. Requirements for OPES processors		4. Requirements for OPES processors
	In order to facilitate compliance, the concept of an "OPES system"		In order to facilitate compliance, the concept of an "OPES system"
	being traceable, requires that each OPES processor MUST support		being traceable, requires that each OPES processor MUST support
	tracing. Policy can be set that defines which domain has		tracing. Policy can be set that defines which domain has
	authorization to turn on tracing and its granularity. An OPES		authorization to turn on tracing and its granularity. An OPES
	provider can have its private policy for trace information, but it		provider can have its private policy for trace information, but it
	MUST support tracing mechanisms and it MUST reveal it's policy.		MUST support tracing mechanisms and it MUST reveal its policy.
	The requirements for OPES processors that are applicatble to tracing		The requirements for OPES processors that are applicable to tracing
	are:		are:
	o Each OPES processor MUST belong to a single OPES Domain.		o Each OPES processor MUST belong to a single OPES Domain.
	o Each OPES processor MUST have a Unique Identity in that Domain.		o Each OPES processor MUST have a Unique Identity in that Domain.
	o Each OPES processor MUST support tracing, policy can be used to		o Each OPES processor MUST support tracing, policy can be used to
	turn tracing on and.to determine granuality.		turn tracing on and to determine its granularity.
	o TBD
	5. Requirements for callout servers		5. Requirements for callout servers
	If it is the task of an OPES processor to add trace records to		In an OPES system, it is the task of an OPES processor to add trace
	application messages, then callout servers that uses the OCP protocol		records to application messages. In this case, the callout servers
	are not affected by tracing requirements. In order for an OCP		that uses the OCP protocol [5] are not affected by tracing
	protocol to be tracing neutral, the OPES server SHOULD be able to		requirements. In order for an OCP protocol to be tracing neutral, an
	meet the following requirements:		OPES processor in an OPES system MUST be able to meet the following
			requirements:
	o Callout services adapt payload regardless of the application		o Callout services adapt payload regardless of the application
	protocol in use and leave header adjustment to OPES processor.		protocol in use and leave header adjustment to OPES processor.
	o OPES processor SHOULD be able to trace it's own invocation and		o OPES processor SHOULD be able to trace it's own invocation and
	service(s) execution since they understand the application		service(s) execution since they understand the application
	protocol.		protocol.
	o Callout servers MAY be able to add their own OPES trace records		o Callout servers MAY be able to add their own OPES trace records
	to application level messages.		to application level messages.
	o TBD
	6. Privacy considerations		6. Privacy considerations
	6.1 Tracing and Trust Domains		6.1 Tracing and Trust Domains
	A trust domain may include several OPES systems and entities. Within		A trust domain may include several OPES systems and entities. Within
	a trust domain, there MUST be at least support for one trace entry		a trust domain, there MUST be at least support for one trace entry
	per system. Entities outside of that system may or may not see any		per OPES system. Entities outside of that system may or may not see
	traces, depending on domain policies or configuration. For example,		any traces, depending on domain policies or configuration. For
	if an OPES system is on the content provider "side", end-users are		example, if an OPES system is on the content provider "side",
	not guaranteed any traces. If an OPES system is working inside		end-users are not guaranteed any traces. If an OPES system is working
	end-user domain, the origin server is not guaranteed any traces		inside end-user domain, the origin server is not guaranteed any
	related to user requests.		traces related to user requests.
	7. How to Support Tracing		7. How to Support Tracing
	In order to support tracing, the following aspects must be addressed:		In order to support tracing, the following aspects must be addressed:
	o There MUST be a System Identifier that identify a domain that is		o There MUST be a System Identifier that identify a domain that is
	employing an OPES system.		employing an OPES system.
	o An OPES processor MUST be able to be uniquely identified (MUST		o An OPES processor MUST be able to be uniquely identified (MUST
	have an Identifier) within a system.		have an Identifier) within a system.
	o An OPES processor MUST add its identification to the trace.		o An OPES processor SHOULD add its identification to the trace.
	o An OPES processor SHOULD add to the trace identification of every		o An OPES processor SHOULD add to the trace identification of every
	callout service that received the application message.		callout service that received the application message.
	o An OPES processor MUST add to the trace identification of the		o If the policy in an OPES system requires an OPES processor to turn
	"system/entity" it belongs to. "System" ID MUST make it possible		tracing on, then the OPES processor MUST add to the trace
	to access "system" privacy policy.		identification of the "system or entity" it belongs to. "System"
			ID MUST make it possible to access "system" privacy policy.
	o An OPES processor MAY group the above information for sequential		o An OPES processor MAY group the above information for sequential
	trace entries having the same "system/entity" ID. In other words,		trace entries having the same "system/entity" ID. In other words,
	trace entries produced within the same "system/entity" MAY be		trace entries produced within the same "system or entity" MAY be
	merged/aggregated into a single less detailed trace entry.		merged or aggregated into a single less detailed trace entry.
	o An OPES processor MAY delegate trace management to a callout		o An OPES processor MAY delegate trace management to a callout
	service within the same "system/entity".		service within the same "system or entity".
	TBD
	7.1 Tracing and OPES System Granularity		7.1 Tracing and OPES System Granularity
	There are two distinct uses of traces. First, is to SHOULD enable the		There are two distinct uses of traces. First, a trace SHOULD enable
	"end (content producer or consumer) to detect OPES processor presence		the "end (content producer or consumer) to detect OPES processor
	within end's trust domain. Such "end" should be able to see a trace		presence within end's trust domain. Such "end" should be able to see
	entry, but does not need to be able to interpret it beyond		a trace entry, but does not need to be able to interpret it beyond
	identification of the trust domain(s).		identification of the trust domain(s).
	Second, the domain administrator SHOULD be able to take a trace entry		Second, the domain administrator SHOULD be able to take a trace entry
	(possibly supplied by an "end? as an opaque string) and interpret it.		(possibly supplied by an "end? as an opaque string) and interpret it.
	The administrator must be able to identify OPES processor(s) involved		The administrator must be able to identify OPES processor(s) involved
	and may be able to identify applied adaptation services along with		and may be able to identify applied adaptation services along with
	other message-specific information. That information SHOULD help to		other message-specific information. That information SHOULD help to
	explain what OPES agent(s) were involved and what they did. It may be		explain what OPES entities were involved and the actions that they
	impractical to provide all the required information in all cases.		performed. It may be impractical to provide all the required
	This document view a trace record as a hint, as opposed to an		information in all cases. This document view a trace record as a
	exhaustive audit.		hint, as opposed to an exhaustive audit.
	Since the administrators of various trust domains can have various		Since the administrators of various trust domains can have various
	ways of looking into tracing, they MAY require the choice of freedom		ways of looking into tracing, they MAY require the choice of freedom
	in what to put in trace records and how to format them. Trace records		in what to put in trace records and how to format them. Trace records
	should be easy to extend beyond basic OPES requirements. Trace		should be easy to extend beyond basic OPES requirements. Trace
	management algorithms should treat trace records as opaque data to		management algorithms should treat trace records as opaque data to
	the extent possible.		the extent possible.
	It is not expected that entities in one trust domain to be able to		It is not expected that entities in one trust domain to be able to
	get all OPES-related feedback from entities in other trust domains.		get all OPES-related feedback from entities in other trust domains.
	For example, if an end-user suspects that a served is corrupted by a		For example, if an end-user suspects that a service was corrupted by
	callout service, there is no guarantee that the use will be able to		a callout service, then, there is no guarantee that the user will be
	identify that service, contact its owner, or debug it _unless_ the		able to identify that service, contact its owner, or debug it, unless
	service is within my trust domain. This is no different from the		the service is within its trust domain. This is no different from the
	current situation where it is impossible, in general, to know the		current situation where it is impossible, in general, to know the
	contact person for an application on an origin server that generates		contact person for an application on an origin server that generates
	corrupted HTML; and even if the person is known, one should not		corrupted HTML; and even if the person is known, one should not
	expect that person to respond to end-user queries.		expect that person to respond to end-user queries.
	7.2 Requirements for In-Band Tracing		7.2 Requirements for In-Band Tracing
	The OPES architecture [8] states that traces must be in-band. The		The OPES architecture [8] states that traces must be in-band. The
	support of this design specification is dependent on the specifics of		support of this design goal is dependent on the specifics of the
	the message application level protocol that is being used in an OPES		message application level protocol that is being used in an OPES
	flow. In-band tracing limits the type of application protocols that		flow. In-band tracing limits the type of application protocols that
	OPES can support. The details of what a trace record can convey is		OPES can support. The details of what a trace record can convey is
	also dependent on the choice of the application level protocol.		also dependent on the choice of the application level protocol.
	For these reasons, the work will document requirements for		For these reasons, this work documents requirements for application
	application protocols that need to support OPES traces. However, the		protocols that need to support OPES traces. However, the architecture
	architecture does not prevent implementers of developing out-of-band		does not prevent implementers of developing out-of-band protocols and
	protocols and techniques to address the above limitation.		techniques to address the above limitation.
	7.2.1 Tracing Information Granularity and Persistence levels		7.2.1 Tracing Information Granularity and Persistence levels
	Requirements		Requirements
	In order to be able to trace entities that have acted on an		In order to be able to trace entities that have acted on an
	application message in an OPES flow, there may be requirements to		application message in an OPES flow, there may be requirements to
	keep information that is related to the following:		keep information that is related to the following:
	o Message-related informatio: All data that describes specific		o Message-related information: All data that describes specific
	actions performed on the message SHOULD be provided with that		actions performed on the message SHOULD be provided with that
	message, as there is no other way to find message level details		message, as there is no other way to find message level details at
	later.		a later stage.
	o Session related information: Session level data MUST be preserved		o Session related information: Session level data MUST be preserved
	for the duration of the session. OPES processor is responsible for		for the duration of the session. OPES processor is responsible for
	inserting notifications if session-level information changes.		inserting notifications if session-level information changes.
	o End-point related data: What profile is activated? Where to get		o End-point related data: What profile is activated? Where to get
	profile details? Where to set preferences?		profile details? Where to set preferences?
	o TBD
	7.3 Protocol Binding		7.3 Protocol Binding
	How tracing is added is application protocol-specific and will be		The task of adding tracing information is application protocol
	documented in separate drafts. This work documents what tracing		specific. Separate documents will address HTTP and other protocols.
	information is required and some common tracing elements.		This work documents what tracing information is required and some
			common tracing elements.
	7.4 Tracing scenarios and examples		8. Tracing Examples
	TBD		This section provides some examples of tracing that could be
			generated by an OPES System. The examples are based on HTTP [3] and
			use HTTP extension headers as given in [6]. In [6] trace entries are
			supplied using HTTP extension message headers. These headers are
			defined using #list constructs. A valid HTTP message may contain
			multiple entries of each header. In an OPES Systems, these headers
			MUST be used to represent the trace entries.
	8. Optional Notification		In [6], the following HTTP extensions are defined:
			OPES-System = "OPES-System" ":" #trace-entry
			OPES-Processor = "OPES-Processor" ":" #trace-entry
			OPES-Service = "OPES-Service" ":" #trace-entry
			trace-entry = opes-agent-id *( ";" parameter )
			opes-agent-id = absoluteURI
			8.1 Single OPES Processor: Detailed Trace
			This example consider the case of an OPES System consisting of a
			single OPES Processor that is capable of locally performing three
			OPES services. A data consumer application may receive the following
			HTTP response message header after OPES adaptations have been
			applied:
			HTTP/1.1 200 OK
			Date: Wed, 15 Nov 1995 06:25:24 GMT
			Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
			Content-type: application/octet-stream
			OPES-System: http://www.example-opes-systemA.com/
			opes?session=ac79a7901549f56
			OPES-Service: http:// www.example-opes-systemA.com /?sid=123
			OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=124
			OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=125
			In this example, the trace has identified the OPES System and all the
			OPES services that were performed on the data consumer application
			original request.
			8.2 Single OPES Processor: Partial Trace
			In this example, the OPES System consisting of a two OPES Processor.
			Each Processor is capable of locally performing many OPES services. A
			data consumer application may receive the following HTTP response
			message header after OPES adaptations have been applied:
			HTTP/1.1 200 OK
			Date: Wed, 15 Nov 1995 06:25:24 GMT
			Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
			Content-type: application/octet-stream
			OPES-System: http://www.example-opes-systemA.com/
			opes?session=ac79a7901549f56
			OPES-Service: http:// www.example-opes-systemA.com /?sid=123
			OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=124 ;
			Mode = Aggregate
			In this example, several OPES services may be performed on the
			request. However, the trace has one entry that fully identifies one
			service and the other services are identified through a common ID.
			The OPES system is expected to be able to detail the other services
			when queried by the data consumer application.
			8.3 Multiple OPES Processors: Full Trace
			In this example, the OPES System consisting of a two OPES Processors.
			Each processor is capable of locally performing two OPES services. A
			data consumer application may receive the following HTTP response
			message header after OPES adaptations have been applied:
			HTTP/1.1 200 OK
			Date: Wed, 15 Nov 1995 06:25:24 GMT
			Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
			Content-type: application/octet-stream
			OPES-System: http://www.example-opes-systemA.com/
			opes?session=ac79a7901549f56
			OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
			?sid=123
			OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
			?sid=124
			OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
			?sid=111
			OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
			?sid=112
			In this example, the trace has identified the OPES System and all the
			OPES services that were performed on the data consumer application
			original request.
			8.4 Multiple OPES Processors: Partial Trace
			In this example, the OPES System consisting of a two OPES Processors.
			Each processor is capable of locally performing several OPES
			services. A data consumer application may receive the following HTTP
			response message header after OPES adaptations have been applied:
			HTTP/1.1 200 OK
			Date: Wed, 15 Nov 1995 06:25:24 GMT
			Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
			Content-type: application/octet-stream
			OPES-System: http://www.example-opes-systemA.com/
			opes?session=ac79a7901549f56
			OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
			?sid=123
			OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
			?sid=124 ; Mode A
			OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
			?sid=111
			OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
			?sid=112 ; Mode B
			In this example, several OPES services may be performed on the
			request. However, the trace partially indicates the services that
			were performed. The OPES system is expected to be able to detail the
			other services when queried by the data consumer application.
			9. Optional Notification
	This section examines IAB [2] considerations (3.1) and (3.2)		This section examines IAB [2] considerations (3.1) and (3.2)
	regarding notification in an OPES architecture.		regarding notification in an OPES architecture.
	Notification propagates in opposite direction of tracing and cannot		Notification propagates in opposite direction of tracing and cannot
	be attached to application messages that it notifies about.		be attached to the application messages that it notifies about.
	Notification can be done out-band and may require the development of		Notification can be done out-band and may require the development of
	a new protocol. The direction of data flow for tracing and		a new protocol. The direction of data flow for tracing and
	notification are depicted in Figure 2.		notification are depicted in Figure 2.
	Notification		Notification
	+-----------------------------------------------		+-----------------------------------------------
	| |		| |
	| V		| V
	+---------------+ +-------+ +---------------+		+---------------+ +-------+ +---------------+
	| | | | | Data Provider |		| | | | | Data Provider |
	skipping to change at page 15, line 4		skipping to change at page 19, line 4
	allow Optional Notification. For example, an OPES System can adopt a		allow Optional Notification. For example, an OPES System can adopt a
	mechanism that uses a flag that would allow a data consumer and a		mechanism that uses a flag that would allow a data consumer and a
	data provider application to signal to each other that they are		data provider application to signal to each other that they are
	interested to receive an explicit notification if an OPES service is		interested to receive an explicit notification if an OPES service is
	applied to a specific message. The value of this optional flag/field		applied to a specific message. The value of this optional flag/field
	can be a URI that identifies notification method plus parameters. If		can be a URI that identifies notification method plus parameters. If
	a processor understands the method, it would be able to further		a processor understands the method, it would be able to further
	decode the field and send a notification. The specification of the		decode the field and send a notification. The specification of the
	field name and format for an application protocol can be stated in		field name and format for an application protocol can be stated in
	the associated binding document. The details of the notification		the associated binding document. The details of the notification
	protocol is beyond the scope of this Working Group.		protocol is beyond the scope of this document.
	For example, the following HTTP header:		For example, the following HTTP header:
	o OPES-Notify: URI *(pname=pvalue)		OPES-Notify: URI *(pname=pvalue)
	Or,		Or,
	o My-OPES-Notify: foo=bar q=0.5		My-OPES-Notify: foo=bar q=0.5
	can be used.		can be used.
	9. IANA considerations		10. IANA considerations
	TBD		This work does not require any IANA consideration since any actions
			will be addressed in [6].
	10. Security Considerations		11. Security Considerations
	TBD		The security considerations for OPES are documented in [7]. This
			document is a requirement document for tracing and as such does not
			develop any new protocols that require security considerations.
	Normative References		Normative References
	[1] McHenry, S., et. al, "OPES Scenarios and Use Cases",		[1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
	Internet-Draft TBD, May 2002.		Internet-Draft http://www.ietf.org/internet-drafts/
			draft-ietf-opes-scenarios-01.txt, Auguest 2002.
	[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy		[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
	Considerations for Open Pluggable Edge Services", RFC 3238,		Considerations for Open Pluggable Edge Services", RFC 3238,
	January 2002.		January 2002.
	[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,		[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
	Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --		Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", RFC 2616, June 1999.		HTTP/1.1", RFC 2616, June 1999.
	[4] OPES working group, "OPES Service Authorization and Enforcement		[4] A. Barbir et al., "Policy, Authorization and Enforcement
	Requirements", Internet-Draft TBD, May 2002.		Requirements of OPES", Internet-Draft http://www.ietf.org/
			internet-drafts/draft-ietf-opes-authorization-02.txt, February
			2003.
	[5] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,		[5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft
	May 2002.		http://www.ietf.org/internet-drafts/
			draft-ietf-opes-ocp-core-01.txt, August 2003.
	[6] A. Beck et al., "Requirements for OPES Callout Protocols",		[6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
	Internet-Draft http://www.ietf.org/internet-drafts/		September 2003.
	draft-ietf-opes-protocol-reqs-03.txt, December 2002.
	[7] A. Barbir et al., "Security Threats and Risks for Open Pluggable		[7] A. Barbir et al., "Security Threats and Risks for Open Pluggable
	Edge Services", Internet-Draft http://www.ietf.org/		Edge Services", Internet-Draft http://www.ietf.org/
	internet-drafts/draft-ietf-opes-threats-00.txt, October 2002.		internet-drafts/draft-ietf-opes-threats-02.txt, February 2003.
	[8] A. Barbir et al., "An Architecture for Open Pluggable Edge		[8] A. Barbir et al., "An Architecture for Open Pluggable Edge
	Services (OPES)", Internet-Draft http://www.ietf.org/		Services (OPES)", Internet-Draft http://www.ietf.org/
	internet-drafts/draft-ietf-opes-architecture-04, December 2002.		internet-drafts/draft-ietf-opes-architecture-04, December 2002.
	[9] A. Barbir et al., "OPES Treatment of IAB Considerations",		[9] A. Barbir et al., "OPES Treatment of IAB Considerations",
	Internet-Draft http://www.ietf.org/internet-drafts/		Internet-Draft http://www.ietf.org/internet-drafts/
	draft-ietf-opes-iab-01.txt, February 2004.		draft-ietf-opes-iab-01.txt, February 2004.
	Informative References		Informative References
	[10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,		[10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
	Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.		Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
	Waldbusser, "Terminology for Policy-Based Management", RFC		Waldbusser, "Terminology for Policy-Based Management", RFC
	3198, November 2001.		3198, November 2001.
	[11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0		[11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0
	(P3P1.0) Specification", W3C Recommendation 16 http://		(P3P1.0) Specification", W3C Recommendation 16 http://
	www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002.		www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002.
	[12] "Hit Metering", RFC .
	Author's Address		Author's Address
	Abbie Barbir		Abbie Barbir
	Nortel Networks		Nortel Networks
	3500 Carling Avenue		3500 Carling Avenue
	Nepean, Ontario K2H 8E9		Nepean, Ontario K2H 8E9
	Canada		Canada
	Phone: +1 613 763 5229		Phone: +1 613 763 5229
	EMail: abbieb@nortelnetworks.com		EMail: abbieb@nortelnetworks.com
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	TBD		Several people has contributed to this work. Many thanks to: Alex
			Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin
			Stecher, Marshall Rose and Reinaldo Penno.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/