draft-ietf-opes-iab-00.txt		draft-ietf-opes-iab-01.txt
	Open Pluggable Edge Services A. Barbir		Open Pluggable Edge Services A. Barbir
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: December 11, 2003 A. Rousskov		Expires: February 25, 2004 A. Rousskov
	The Measurement Factory		The Measurement Factory
	June 12, 2003		August 27, 2003
	OPES Treatment of IAB Considerations		OPES Treatment of IAB Considerations
	draft-ietf-opes-iab-00		draft-ietf-opes-iab-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 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 32		skipping to change at page 1, line 32
	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 December 11, 2003.		This Internet-Draft will expire on February 25, 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
	IETF Internet Architecture Board (IAB) expressed nine		IETF Internet Architecture Board (IAB) expressed nine
	architecture-level considerations when Open Pluggable Edge Services		architecture-level considerations when Open Pluggable Edge Services
	(OPES) working group was being chartered at the IETF. The working		(OPES) working group was being chartered at the IETF. The working
	skipping to change at page 2, line 12		skipping to change at page 2, line 12
	addressed by the group. This document describes how OPES addresses		addressed by the group. This document describes how OPES addresses
	those considerations.		those considerations.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Consideration (2.1) One-party consent . . . . . . . . . . . . 5		3. Consideration (2.1) One-party consent . . . . . . . . . . . . 5
	4. Consideration (2.2) IP-layer communications . . . . . . . . . 6		4. Consideration (2.2) IP-layer communications . . . . . . . . . 6
	5. Notification Considerations . . . . . . . . . . . . . . . . . 8		5. Notification Considerations . . . . . . . . . . . . . . . . . 8
	5.1 Consideration (3.1) Notification . . . . . . . . . . . . . . . 9		5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8
	5.2 Consideration (3.2) Notification . . . . . . . . . . . . . . . 10		5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9
	5.3 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 11		5.3 Consideration (3.1) Notification . . . . . . . . . . . . . . . 10
	6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 12		5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12
	7. Consideration (4.2) Reference validity . . . . . . . . . . . . 13		5.5 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 12
	8. Consideration (4.3) Addressing extensions . . . . . . . . . . 14		6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14
	9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 15		7. Consideration (4.2) Reference validity . . . . . . . . . . . . 15
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Consideration (4.3) Addressing extensions . . . . . . . . . . 16
	11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17
	12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19		11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Normative References . . . . . . . . . . . . . . . . . . . . . 20		12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Informative References . . . . . . . . . . . . . . . . . . . . 21		A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21		Normative References . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . 22		Informative References . . . . . . . . . . . . . . . . . . . . 24
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . . 25
	1. Introduction		1. Introduction
	The Open Pluggable Edge Services (OPES) architecture		The Open Pluggable Edge Services (OPES) architecture
	[I-D.ietf-opes-architecture], enables cooperative application		[I-D.ietf-opes-architecture], enables cooperative application
	services (OPES services) between a data provider, a data consumer,		services (OPES services) between a data provider, a data consumer,
	and zero or more OPES processors. The application services under		and zero or more OPES processors. The application services under
	consideration analyze and possibly transform application-level		consideration analyze and possibly transform application-level
	messages exchanged between the data provider and the data consumer.		messages exchanged between the data provider and the data consumer.
	Following controversy related to chartering OPES, IAB made		In the process of chartering OPES, the IAB made recommendations on
	recommendations on issues that OPES solutions should be required to		issues that OPES solutions should be required to address. These
	address. These recommendations were formulated in the form of		recommendations were formulated in the form of specific IAB
	specific IAB considerations [RFC3238]. IAB emphasized that its		considerations [RFC3238]. IAB emphasized that its considerations did
	considerations did not recommend specific solutions and did not		not recommend specific solutions and did not mandate specific
	mandate specific functional requirements. Addressing an IAB		functional requirements. Addressing an IAB consideration may involve
	consideration may involve showing appropriate protocol mechanisms or		showing appropriate protocol mechanisms or demonstrating that the
	demonstrating that the issue does not apply.		issue does not apply. Addressing a consideration does not necessarily
			mean supporting technology implied by the consideration wording.
	The primary goal of this document is to show that all IAB		The primary goal of this document is to show that all IAB
	considerations are addressed by OPES, to the extent those		considerations are addressed by OPES, to the extent those
	considerations can be addressed by an IETF working group. We also		considerations can be addressed by an IETF working group. Limitations
	explicitly document limitations of our abilities to address certain		of OPES working group ability to address certain aspects of IAB
	aspects of IAB considerations.		considerations are explicitly documented.
	There are nine IAB considerations [RFC3238] that OPES has to address.		There are nine IAB considerations [RFC3238] that OPES has to address.
	In the core of this document are the corresponding nine		In the core of this document are the corresponding nine
	"Consideration" sections. For each IAB consideration, its section		"Consideration" sections. For each IAB consideration, its section
	contains general discussion as well as references to specific OPES		contains general discussion as well as references to specific OPES
	mechanisms relevant to the consideration.		mechanisms relevant to the consideration.
	2. Terminology		2. Terminology
	This document does not introduce any new terminology but uses		This document does not introduce any new terminology but uses
	skipping to change at page 5, line 14		skipping to change at page 5, line 14
	3. Consideration (2.1) One-party consent		3. Consideration (2.1) One-party consent
	"An OPES framework standardized in the IETF must require that the use		"An OPES framework standardized in the IETF must require that the use
	of any OPES service be explicitly authorized by one of the		of any OPES service be explicitly authorized by one of the
	application-layer end-hosts (that is, either the content provider or		application-layer end-hosts (that is, either the content provider or
	the client)."[RFC3238]		the client)."[RFC3238]
	OPES architecture requires that "OPES processors MUST be consented to		OPES architecture requires that "OPES processors MUST be consented to
	by either the data consumer or data provider application"		by either the data consumer or data provider application"
	[I-D.ietf-opes-architecture]. The requirement alone cannot prevent		[I-D.ietf-opes-architecture]. This requirement alone cannot prevent
	consent-less introduction of OPES processors, of course. OPES		consent-less introduction of OPES processors. In
	enables concerned parties to detect unwanted OPES processors by		[I-D.ietf-opes-end-comm], the OPES architecture enables concerned
	examining OPES traces and by checking content signatures.		parties to detect unwanted OPES processors by examining OPES traces.
			The use of traces in OPES is mandatory.
	Tracing is a weak but cheap mechanism that is unable to detect		Tracing mechanism on its own is unable to detect processors that are
	processors incompliant with OPES specifications on tracing and		in violation of OPES specifications. Examples include OPES processors
	operating in stealth mode. Content signatures is a strong but		operating in stealth mode. However, the OPES architecture allows the
	expensive mechanism that can detect any modifications of signed		use of content signature to verify the authenticity of performed
	content provided the content provider is willing to sign the data and		adaptations. Content signatures is a strong but expensive mechanism
	the client is willing to either check the signature or relay received		that can detect any modifications of signed content provided the
	content to content provider for signature verification.		content provider is willing to sign the data and the client is
			willing to either check the signature or relay received content to
			content provider for signature verification.
	OPES adaptations include copying and other forms of non-modifying		OPES adaptations may include copying and other forms of non-modifying
	access to content. These kinds of adaptations cannot be detected by		access to content. These kinds of adaptations cannot be detected by
	the above mentioned mechanisms. Thus, "passive" unwanted OPES		the above mentioned mechanisms. Thus, "passive" OPES processors can
	processors cannot be detected. If presence of such processors is a		operate without consent. If presence of such processors is a concern,
	concern, content encryption can be used. See privacy consideration		content encryption can be used. A passive processor is no different
	for more details.		from a proxy or intermediary operating outside of OPES framework. No
			OPES mechanism can prevent non-modifying access to content.
	4. Consideration (2.2) IP-layer communications		4. Consideration (2.2) IP-layer communications
	"For an OPES framework standardized in the IETF, the OPES		"For an OPES framework standardized in the IETF, the OPES
	intermediary must be explicitly addressed at the IP layer by the end		intermediary must be explicitly addressed at the IP layer by the end
	user."[RFC3238]		user."[RFC3238]
	OPES architecture requires that "OPES processors MUST be addressable		OPES architecture requires that "OPES processors MUST be addressable
	at the IP layer by the end user (data consumer application)"		at the IP layer by the end user (data consumer application)"
	[I-D.ietf-opes-architecture]. Two caveats are related to this		[I-D.ietf-opes-architecture]. IAB and the architecture draft mention
	requirement. First, addressing the first OPES processor in a chain of		an important exception: addressing the first OPES processor in a
	processors is sufficient. That is, a chain of OPES processors is		chain of processors is sufficient. That is, a chain of OPES
	viewed as a single OPES processor at the address of the first chain		processors is viewed as a single OPES "system" at the address of the
	element. (XXX: should we move these caveats into a separate section?		first chain element.
	they seem to affect many considerations; one the other hand, it is
	probably the job of the architecture draft to define these things so
	that we can refer to them from here.)
	The second caveat is more controversial. Only a very limited subset		The notion of a chain is not strictly defined by IAB. For the purpose
	of OPES intermediaries are subject to the above requirements. The		of addressing this consideration, we consider a group of OPES
	situation is examined below, by considering content provider and end		processors working on a given application transaction. Such a group
	user sides of the architecture.		would necessarily form a single processing chain, with a single
			"exit" OPES processor (the processor that adapted the given message
			last). OPES architecture essentially requires that last OPES
			processor to be explicitly addressable at the IP layer by the end
			user. Note that chain formation, including its exit point may depend
			on an application message and other dynamic factors such as time of
			day or system load.
	OPES processors that operate under content provider consent may not		Furthermore, if OPES processing is an internal processing step at
	be subject to the above consideration and requirement (XXX the		data consumer or provider side, then the last OPES processor may
	architecture draft does not reflect this). It is irrational to expect		reside in a private address space of the side's network and may not
	a content provider to provide access to internal hosts participating		be explicitly addressable. In such situations, the processing side
	in content generation, whether OPES processors are involved or not.		must designate an addressable point on the same processing chain.
	Moreover, providing such access would serve little practical purpose		That designated point may not be, strictly speaking, an OPES
	because internal OPES processors are not likely to be able to answer		processor, but it will suffice as such as far as IAB considerations
	any end user queries, being completely our of content generation		are concerned -- the other side will be able to address it explicitly
	context. For example, an OPES processor adding customer-specific		at the IP layer and it will represent the OPES processing chain to
	information to XML pages may not understand or be aware of any final		the outside world.
	HTML content that the end user receives and may not be able to map
	end user request to any internal user identification.
	OPES processors that operate under end user consent may not be		Designating an addressable processing point avoids the conflict
	subject to the above consideration and requirement (XXX the		between narrow interpretation of IAB consideration and real system
	architecture draft does not reflect this). It is irrational to expect		designs: It is irrational to expect a content provider to provide
	a client-side ISP to provide access to internal hosts participating		access to internal hosts participating in content generation, whether
	in content processing, whether OPES processors are involved or not.		OPES processors are involved or not. Moreover, providing such access
	Moreover providing such access would serve little practical purpose		would serve little practical purpose because internal OPES processors
	because internal OPES processors are not likely to be able to answer		are not likely to be able to answer any end user queries, being
	any end user queries, being completely our of content processing		completely out of content generation context. For example, an OPES
	context. For example, an OPES processor making a client-authorized		processor adding customer-specific information to XML pages may not
	XML content translation may not understand or be aware of any final		understand or be aware of any final HTML content that the end user
	HTML content that the end user receives and may not be able to map		receives and may not be able to map end user request to any internal
	end user request to any internal user identification.		user identification. Since OPES requires the end of the message
			processing chain to be addressable, the conflict does not exist --
			OPES places no requirements on the internal architecture of data
			producer systems while requiring the entire OPES-related content
			production "system" to be addressable at the IP layer.
	IAB consideration 2.2 apparently was not meant to apply to "internal"		Public/Private Domain | Private Domain
	OPES intermediaries. It may be better interpreted as "If the first		|
	intermediary on end user's message processing path is an OPES		+--------------+ | +------+
	intermediary, that intermediary must be explicitly addressed at the		| Data | *-------* +----------+ | | OPES |
	IP layer by the end user". In other words, the end user is assured		| Consumer |<-->/ Network \<-->| Public IP| | +------+
	that the first intermediary that touches her request is explicitly		| Application | \(Public) / | Address |<-->| .
	addressed if it is an OPES intermediary.		+--------------+ *-------* | OPES | | .
			+----------+ | .
			| +------+
			| | OPES |
			| +------+
			|
			Figure 1
	(XXX: should we add a picture showing internal and external OPES		(XXX: should we add a picture showing internal and external OPES
	intermediaries?)		intermediaries? more pictures showing other OPES layouts? Move to
			architecture draft?)
	5. Notification Considerations		5. Notification Considerations
	This section discusses how OPES framework addresses IAB Notification		This section discusses how OPES framework addresses IAB Notification
	concerns 3.1 and 3.2. OPES framework concentrates on tracing rather		considerations 3.1 and 3.2.
	than notification. The tracing specification [XXX] defines "OPES
	trace" as "application message information about OPES entities that		5.1 Notification versus trace
	adapted that message" and "OPES tracing" as "the process of
	including, manipulating, and interpreting an OPES trace" (XXX: keep		Before specific considerations are discussed, the relationship
	these in sync). Thus, OPES trace follows the application message it		between IAB notifications and OPES tracing has to be explained. OPES
	traces. It notifies the recipient of the message of what has happened		framework concentrates on tracing rather than notification. The
	to that message. Traces are implemented as extensions of application		tracing specification [I-D.ietf-opes-end-comm] defines "OPES trace"
	protocols being adapted and traced.		as "application message information about OPES entities that adapted
			that message" and "OPES tracing" as "the process of including,
			manipulating, and interpreting an OPES trace" (XXX: keep these in
			sync). Thus, OPES trace follows the application message it traces.
			The trace is for the recipient of the application message. Traces are
			implemented as extensions of application protocols being adapted and
			traced.
	As opposed to an OPES trace, provider notification (as implied by		As opposed to an OPES trace, provider notification (as implied by
	IAB) notifies the sender of the message of what had happened to the		IAB) notifies the sender of the application message rather than the
	message after the message left the sender. Thus, notifications		recipient. Thus, notifications propagate in the opposite direction of
	propagate in the opposite direction of traces. Supporting		traces. Supporting notifications directly would require a new
	notifications directly would require a new protocol. Figure XXX		protocol. Figure XXX illustrates the differences between a trace and
	illustrates the differences between a trace and notification from a		notification from a single application message point of view.
	single application message point of view.
	sender --[message A]---> OPES --[message A' + trace]--> recipient		sender --[message A]---> OPES --[message A' + trace]--> recipient
	^ V		^ V
	| |		| |
	+-<-- [notification] ---+		+-<-- [notification] ---+
	Figure 1		Figure 2
	Since notifications cannot be piggy-backed to application messages,		Since notifications cannot be piggy-backed to application messages,
	they create new messages and may at least double the number of		they create new messages and may at least double the number of
	messages the sender has to process (more if several intermediaries on		messages the sender has to process (more if several intermediaries on
	the message path emit notifications). Moreover, a notification		the message path emit notifications). Moreover, associating
	message may refer to some sender state that has to be kept around		notifications with application messages may require duplicating
	until notification is received, increasing performance overhead of		application message information in notifications and/or maintaining a
	notifications. These concerns call for optional notification, with a		sender state until notification is received, increasing performance
	special protocol to enable notifications when needed.		overhead of notifications. These concerns call for optional
			notification, with a special protocol to enable notifications when
			needed.
	The level of available details in notifications versus provider		The level of available details in notifications versus provider
	interest in supporting notification is another concern. Experience		interest in supporting notification is another concern. Experience
	shows that content providers often require very detailed information		shows that content providers often require very detailed information
	about user actions to be interested in notifications at all. For		about user actions to be interested in notifications at all. For
	example, Hit Metering protocol [XXX] has been designed to supply		example, Hit Metering protocol [XXX] has been designed to supply
	content providers with proxy cache hit counts, in an effort to reduce		content providers with proxy cache hit counts, in an effort to reduce
	cache busting behavior which was caused by content providers desire		cache busting behavior which was caused by content providers desire
	to get accurate site "access counts". However, the Hit Metering		to get accurate site "access counts". However, the Hit Metering
	protocol is currently not widely deployed because the protocol does		protocol is currently not widely deployed because the protocol does
	not supply content providers with information such as client IP		not supply content providers with information such as client IP
	addresses, browser versions, or cookies.		addresses, browser versions, or cookies.
	The Hit Metering experience is relevant because Hit Metering protocol		Hit Metering experience is relevant because Hit Metering protocol was
	was designed to do for HTTP caching intermediaries what OPES		designed to do for HTTP caching intermediaries what OPES
	notifications are meant to do for OPES intermediaries. Performance		notifications are meant to do for OPES intermediaries. Performance
	requirements call for state reduction via aggregation of		requirements call for state reduction via aggregation of
	notifications while provider preferences call for state preservation		notifications while provider preferences call for state preservation
	or duplication. Achieving the right balance when two sides belong to		or duplication. Achieving the right balance when two sides belong to
	different organizations and have different optimization priorities is		different organizations and have different optimization priorities
	probably impossible in general.		may be impossible.
	Thus, instead of explicitly supporting notifications on a protocol		Thus, instead of explicitly supporting notifications on a protocol
	level, OPES concentrates on tracing facilities and supports		level, OPES concentrates on tracing facilities and supports
	notifications indirectly, using those tracing facilities. In other		notifications indirectly, using those tracing facilities. In other
	words, the IAB choice of "Notification" label is interpreted as		words, the IAB choice of "Notification" label is interpreted as
	"Notification assistance" (i.e. making notifications meaningful) and		"Notification assistance" (i.e. making notifications meaningful) and
	is not interpreted as a "Notification protocol".		is not interpreted as a "Notification protocol".
	5.1 Consideration (3.1) Notification		5.2 An example of an OPES trace for HTTP
			The example below illustrates adaptations done to HTTP request at an
			OPES intermediary operated by the client ISP. Both original (as sent
			by an end user) and adapted (as received by the origin web server)
			requests are shown. The primary adaptation is the modification of
			HTTP "Accept" header. The secondary adaptation is the addition of an
			"OPES-Via" HTTP extension header.
			GET /pub/WWW/ HTTP/1.1
			Host: www.w3.org
			Accept: text/plain
			Figure 3
			... may be adapted by an ISP OPES system to become:
			GET /pub/WWW/ HTTP/1.1
			Host: www.w3.org
			Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
			OPES-Via: http://www.isp-example.com/opes/?client-hash=1234567
			Figure 4
			The example below illustrates adaptations done to HTTP response at an
			OPES intermediary operated by a Content Distribution Network (CDN).
			Both original (as sent by the origin web server) and adapted (as
			received by the end user) responses are shown. The primary adaptation
			is the conversion from HTML markup to plain text. The secondary
			adaptation is the addition of an "OPES-Via" HTTP extension header.
			HTTP/1.1 200 OK
			Content-Length: 12345
			Content-Encoding: text/html
			<html><head><h1>Available Documenta...
			Figure 5
			... may be adapted by a CDN OPES system to become:
			HTTP/1.1 200 OK
			Content-Length: 2345
			Content-Encoding: text/plain
			OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t
			AVAILABLE DOCUMENTA...
			Figure 6
			In the above examples, "OPES-Via" header values contain URLs that may
			point to OPES-specific documents such as description of the OPES
			operator and its privacy policy. Those documents may be
			parameterized to allow for customizations specific to the transaction
			being traced (e.g., client or even transaction identifier may be used
			to provide more information about performed adaptations). Traced OPES
			URLs may be later used to request OPES bypass. (XXX: OPES specs will
			need to define OPES-Via format and semantics)
			5.3 Consideration (3.1) Notification
	"The overall OPES framework needs to assist content providers in		"The overall OPES framework needs to assist content providers in
	detecting and responding to client-centric actions by OPES		detecting and responding to client-centric actions by OPES
	intermediaries that are deemed inappropriate by the content		intermediaries that are deemed inappropriate by the content
	provider."[RFC3238]		provider."[RFC3238]
	OPES tracing mechanisms assist content providers in detecting		OPES tracing mechanisms assist content providers in detecting
	client-centric actions by OPES intermediaries. Specifically, a		client-centric actions by OPES intermediaries. Specifically, a
	compliant OPES intermediary or system notifies a content provider of		compliant OPES intermediary or system notifies a content provider of
	its presence by including its tracing information in the application		its presence by including its tracing information in the application
	protocol requests. An OPES intermediary MUST leave its trace (XXX		protocol requests. An OPES system MUST leave its trace (XXX quote
	quote tracing draft). Detection assistance has its limitations. Some		tracing draft) [I-D.ietf-opes-end-comm]. Detection assistance has
	OPES intermediaries may work exclusively on responses and may not		its limitations. Some OPES intermediaries may work exclusively on
	have a chance to trace the request. Moreover, some application		responses and may not have a chance to trace the request. Moreover,
	protocols may not have explicit requests (e.g., a content push		some application protocols may not have explicit requests (e.g., a
	service).		content push service).
	OPES tracing mechanisms assist content providers in responding to		OPES tracing mechanisms assist content providers in responding to
	client-centric actions by OPES intermediaries. Specifically, OPES		client-centric actions by OPES intermediaries. Specifically, OPES
	traces MUST include identification of OPES systems and SHOULD include		traces MUST include identification of OPES systems and SHOULD include
	a list of adaptation actions performed on provider's content. This		a list of adaptation actions performed on provider's content. This
	tracing information may be included in the application request.		tracing information may be included in the application request.
	Usually, however, this information will be included in the		Usually, however, this information will be included in the
	application response, an adapted version of which does not reach the		application response, an adapted version of which does not reach the
	content provider. If OPES end points cooperate, then notification can		content provider. If OPES end points cooperate, then notification can
	be assisted with traces. Content providers that suspect or experience		be assisted with traces. Content providers that suspect or experience
	skipping to change at page 10, line 32		skipping to change at page 12, line 5
	policy using appropriate OPES bypass mechanisms and/or end-to-end		policy using appropriate OPES bypass mechanisms and/or end-to-end
	encryption mechanisms.		encryption mechanisms.
	OPES detection and response assistance is limited to application		OPES detection and response assistance is limited to application
	protocols with support for tracing extensions. For example, HTTP		protocols with support for tracing extensions. For example, HTTP
	[RFC2616] has such support while DNS over UDP does not.		[RFC2616] has such support while DNS over UDP does not.
	(XXX: should we prohibit adaptation of application protocols that do		(XXX: should we prohibit adaptation of application protocols that do
	not allow for tracing?)		not allow for tracing?)
	5.2 Consideration (3.2) Notification		5.4 Consideration (3.2) Notification
	"The overall OPES framework should assist end users in detecting the		"The overall OPES framework should assist end users in detecting the
	behavior of OPES intermediaries, potentially allowing them to		behavior of OPES intermediaries, potentially allowing them to
	identify imperfect or compromised intermediaries."[RFC3238]		identify imperfect or compromised intermediaries."[RFC3238]
	OPES tracing mechanisms assist end users in detecting OPES		OPES tracing mechanisms assist end users in detecting OPES
	intermediaries. Specifically, a compliant OPES intermediary or system		intermediaries. Specifically, a compliant OPES intermediary or system
	notifies an end user of its presence by including its tracing		notifies an end user of its presence by including its tracing
	information in the application protocol messages sent to the client.		information in the application protocol messages sent to the client.
	An OPES intermediary MUST leave its trace (XXX quote tracing draft).		An OPES intermediary MUST leave its trace (XXX quote tracing draft)
	Detection assistance has its limitations. Some OPES intermediaries		[I-D.ietf-opes-end-comm]. Detection assistance has its limitations.
	may work exclusively on requests and may not have a chance to trace		Some OPES intermediaries may work exclusively on requests and may not
	the response. Moreover, some application protocols may not have		have a chance to trace the response. Moreover, some application
	explicit responses (e.g., event logging service).		protocols may not have explicit responses (e.g., event logging
			service).
	OPES detection assistance is limited to application protocols with		OPES detection assistance is limited to application protocols with
	support for tracing extensions. For example, HTTP [RFC2616] has such		support for tracing extensions. For example, HTTP [RFC2616] has such
	support while DNS over UDP does not.		support while DNS over UDP does not.
	(XXX: should we prohibit adaptation of application protocols that do		(XXX: should we prohibit adaptation of application protocols that do
	not allow for tracing?)		not allow for tracing?)
	5.3 Consideration (3.3) Non-blocking		5.5 Consideration (3.3) Non-blocking
	"If there exists a "non-OPES" version of content available from the		"If there exists a "non-OPES" version of content available from the
	content provider, the OPES architecture must not prevent users from		content provider, the OPES architecture must not prevent users from
	retrieving this "non-OPES" version from the content		retrieving this "non-OPES" version from the content
	provider."[RFC3238]		provider."[RFC3238]
	OPES intermediaries MUST support a bypass feature (XXX quote bypass		OPES intermediaries MUST support a bypass feature (XXX quote bypass
	draft). If an application message includes bypass instructions, the		draft) [I-D.ietf-opes-end-comm]. If an application message includes
	matching OPES intermediary will not process the message. Bypass may		bypass instructions and an OPES intermediary is not configured to
	generate content errors since some OPES services may be essential.		ignore them, the matching OPES intermediary will not process the
	(Should there be a way to bypass non-essential services only?)		message. An intermediary may be configured to ignore bypass
			instructions only if no non-OPES version of content is available.
			Bypass may generate content errors since some OPES services may be
			essential but may not be configured as such.
	Bypass support has limitations similar to the two		Bypass support has limitations similar to the two
	notification-related considerations above.		notification-related considerations above. (XXX: but it is possible
			to instruct all OPES intermediaries to bypass an application message
			without knowing all OPES intermediaries IDs).
			(XXX: Ideally, this section need to be polished further -- if there
			is no non-OPES version of the content, most IAB considerations
			probably do not apply because there is really no adaptation, only
			creation of content; and we should not restrict content creation.)
	6. Consideration (4.1) URI resolution		6. Consideration (4.1) URI resolution
	"OPES documentation must be clear in describing these services as		"OPES documentation must be clear in describing these services as
	being applied to the result of URI resolution, not as URI resolution		being applied to the result of URI resolution, not as URI resolution
	itself."[RFC3238]		itself."[RFC3238]
	"OPES Scenarios and Use Cases" specification		"OPES Scenarios and Use Cases" specification
	[I-D.ietf-opes-scenarios] documents content adaptations that are in		[I-D.ietf-opes-scenarios] documents content adaptations that are in
	scope of the OPES framework (XXX provide a quote). These adaptations		scope of the OPES framework (XXX provide a quote). These adaptations
	skipping to change at page 13, line 16		skipping to change at page 15, line 16
	"All proposed services must define their impact on inter- and		"All proposed services must define their impact on inter- and
	intra-document reference validity."[RFC3238]		intra-document reference validity."[RFC3238]
	OPES working group does not propose adaptation services. However,		OPES working group does not propose adaptation services. However,
	OPES tracing requirements include identification of OPES		OPES tracing requirements include identification of OPES
	intermediaries and services (for details, see "Notification"		intermediaries and services (for details, see "Notification"
	consideration sections in this document). It is required that		consideration sections in this document). It is required that
	provided identification can be used to locate information about the		provided identification can be used to locate information about the
	OPES intermediaries, including the description of impact on reference		OPES intermediaries, including the description of impact on reference
	validity (XXX quote tracing draft).		validity (XXX quote tracing draft) [I-D.ietf-opes-end-comm].
	8. Consideration (4.3) Addressing extensions		8. Consideration (4.3) Addressing extensions
	"Any services that cannot be achieved while respecting the above two		"Any services that cannot be achieved while respecting the above two
	considerations may be reviewed as potential requirements for Internet		considerations may be reviewed as potential requirements for Internet
	application addressing architecture extensions, but must not be		application addressing architecture extensions, but must not be
	undertaken as ad hoc fixes."[RFC3238]		undertaken as ad hoc fixes."[RFC3238]
	OPES framework does not contain ad hoc services. This and other OPES		OPES framework does not contain ad hoc fixes. This and other OPES
	documents should be sufficient to inform service creators of IAB		documents should be sufficient to inform service creators of IAB
	considerations. If a service does URI resolution or silently affects		considerations. If a service does URI resolution or silently affects
	document reference validity, the authors are requested to review		document reference validity, the authors are requested to review
	service impact on Internet application addressing architecture and		service impact on Internet application addressing architecture and
	work within IETF on potential extension requirements.		work within IETF on potential extension requirements. Such actions
			would be outside of the current OPES framework.
	9. Consideration (5.1) Privacy		9. Consideration (5.1) Privacy
	"The overall OPES framework must provide for mechanisms for end users		"The overall OPES framework must provide for mechanisms for end users
	to determine the privacy policies of OPES intermediaries."[RFC3238]		to determine the privacy policies of OPES intermediaries."[RFC3238]
	OPES tracing mechanisms allow end users to identify OPES		OPES tracing mechanisms allow end users to identify OPES
	intermediaries (for details, see "Notification" consideration		intermediaries (for details, see "Notification" consideration
	sections in this document). It is required that provided		sections in this document). It is required that provided
	identification can be used to locate information about the OPES		identification can be used to locate information about the OPES
	skipping to change at page 18, line 14		skipping to change at page 20, line 14
	12. To-do		12. To-do
	security section: Does this document have any original security		security section: Does this document have any original security
	matters worth documenting?		matters worth documenting?
	normative IDs: To be normative, OPES Internet-Drafts must be replaced		normative IDs: To be normative, OPES Internet-Drafts must be replaced
	with corresponding RFCs when the latter are published.		with corresponding RFCs when the latter are published.
	architecture draft: Should architecture draft talk about external/		architecture draft: Should architecture draft talk about external/
	internal OPES intermediaries and about privacy policies? Should		internal OPES intermediaries, OPES systems, and privacy policies?
	this document be limited to a compilation of references from other		Should this document be limited to a compilation of references
	OPES drafts, or should we introduce/discuss new concepts here?		from other OPES drafts, or should we introduce/discuss new
			concepts here?
	Appendix A. Change Log		Appendix A. Change Log
	Internal WG revision control ID: $Id: iab-cons.xml,v 1.13 2003/06/12		Internal WG revision control ID: $Id: iab-cons.xml,v 1.19 2003/08/28
	15:38:48 rousskov Exp $		03:48:32 rousskov Exp $
			head-sid15
			* Added a figure showing a chain of internal OPES intermediaries
			behind a public IP address. Needs more work. More cases?
			head-sid14
			* Rewrote the Introduction to the IP addressing consideration.
			Do NOT explain how IAB considerations, if interpreted literary,
			do not satisfy important real-world constraints. Instead, use
			the "chain of OPES intermediaries" exception introduced by IAB
			itself to show that OPES architecture addresses IAB concerns as
			long as the "chain" is defined/formed for a given application
			message rather than being a statically configured application
			routing table of sorts. IAB had to add the "chain" exception to
			cover one of the most obvious real-world usage scenario. We use
			the very same exception to cover all usage scenarios we care
			about.
			* Polished text explaining the differences between tracing and
			notification mechanisms.
			* Added examples of OPES/HTTP traces.
			* Be careful not to imply that all OPES intermediaries must obey
			bypass instructions. Bypass should be ignored when no non-OPES
			version of the content exists. Ideally, this may need to be
			polished further -- if there is no non-OPES version of the
			content, most IAB considerations probably do not apply because
			there is really no adaptation, only creation of content (and we
			should not restrict content creation).
			* Added references to OPES "Communications" draft
			[I-D.ietf-opes-end-comm].
	head-sid9		head-sid9
	* Polished to meet new xml2rfc sctrict requirements.		* Polished to meet new xml2rfc strict requirements.
	head-sid8		head-sid8
	* Added unpolished meat for all nine considerations.		* Added unpolished meat for all nine considerations.
	* Added Abbie Barbir as an author.		* Added Abbie Barbir as an author.
	head-sid7		head-sid7
	* Initial revision		* Initial revision
	Normative References		Normative References
			[I-D.ietf-opes-end-comm]
			Barbir, A., "OPES processor and end points
			communications", draft-ietf-opes-end-comm-00 (work in
			progress), June 2003.
	[I-D.ietf-opes-architecture]		[I-D.ietf-opes-architecture]
	Barbir, A., "An Architecture for Open Pluggable Edge		Barbir, A., "An Architecture for Open Pluggable Edge
	Services (OPES)", draft-ietf-opes-architecture-04 (work in		Services (OPES)", draft-ietf-opes-architecture-04 (work in
	progress), December 2002.		progress), December 2002.
	[I-D.ietf-opes-scenarios]		[I-D.ietf-opes-scenarios]
	Barbir, A., "OPES Use Cases and Deployment Scenarios",		Barbir, A., "OPES Use Cases and Deployment Scenarios",
	draft-ietf-opes-scenarios-01 (work in progress), August		draft-ietf-opes-scenarios-01 (work in progress), August
	2002.		2002.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/