draft-ietf-opes-iab-03.txt		draft-ietf-opes-iab-04.txt
	Open Pluggable Edge Services A. Barbir		Open Pluggable Edge Services A. Barbir
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: April 26, 2004 A. Rousskov		Expires: June 1, 2004 A. Rousskov
	The Measurement Factory		The Measurement Factory
	October 27, 2003		December 2, 2003
	OPES Treatment of IAB Considerations		OPES Treatment of IAB Considerations
	draft-ietf-opes-iab-03		draft-ietf-opes-iab-04
	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 April 26, 2004.		This Internet-Draft will expire on June 1, 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 for the Open Pluggable Edge		architecture-level considerations for the Open Pluggable Edge
	Services (OPES) framework. This document describes how OPES		Services (OPES) framework. This document describes how OPES
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	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 Notification versus trace . . . . . . . . . . . . . . . . . . 8		5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8
	5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9		5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9
	5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 10		5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 11
	5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12		5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12
	6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13		6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13
	7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14		7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14
	8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15		8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15
	9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16		9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16
	10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17		10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17
	11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18		11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 19		12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20		13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21		A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	skipping to change at page 9, line 27		skipping to change at page 9, line 27
	Thus, instead of explicitly supporting notifications at the protocol		Thus, instead of explicitly supporting notifications at the protocol
	level, OPES concentrates on tracing facilities. In essence, OPES		level, OPES concentrates on tracing facilities. In essence, OPES
	supports notifications indirectly, using tracing facilities. In other		supports notifications indirectly, using 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".
	The above concerns call for making notification optional. The OPES		The above concerns call for making notification optional. The OPES
	architecture allows for an efficient and meaningful notification		architecture allows for an efficient and meaningful notification
	protocol to be implemented in certain OPES environments. For		protocol to be implemented in certain OPES environments. For
	specific examples, see the "Optional Notification" section in		example, a Cable Company Internet Service Provider (Cable ISP) may
	[I-D.ietf-opes-end-comm].		provide a user-configurable porn filtering service to its subscribers
			while having an agreement with the parent Cable Company to send
			notifications to the content provider when clients (content
			consumers) use the same filter to block Company's advertisement
			images. If the Cable Company deems such subscriber actions
			inappropriate, the company may contact individual subscribers and
			enforce their ISP usage policy according to the terms of the service
			agreement. In this example, ISP cooperation is expected, the volume
			of notifications would be relatively low, and notifications can be
			handled in an automated manner.
	5.2 An example of an OPES trace for HTTP		5.2 An example of an OPES trace for HTTP
	The example below illustrates adaptations done to HTTP request at an		The example below illustrates adaptations done to HTTP request at an
	OPES processor operated by the client ISP. Both original (as sent by		OPES processor operated by the client ISP. Both original (as sent by
	an end user) and adapted (as received by the origin web server)		an end user) and adapted (as received by the origin web server)
	requests are shown. The primary adaptation is the modification of		requests are shown. The primary adaptation is the modification of
	HTTP "Accept" header. The secondary adaptation is the addition of an		HTTP "Accept" header. The secondary adaptation is the addition of an
	"OPES-Via" HTTP extension header [I-D.ietf-opes-http] (XXX: but it is		OPES-System HTTP extension header [I-D.ietf-opes-http].
	not OPES-Via, it is OPES-System for now; OPES-Via is probably better
	for a few reasons though).
	GET /pub/WWW/ HTTP/1.1		GET /pub/WWW/ HTTP/1.1
	Host: www.w3.org		Host: www.w3.org
	Accept: text/plain		Accept: text/plain
	Figure 3		Figure 3
	... may be adapted by an ISP OPES system to become:		... may be adapted by an ISP OPES system to become:
	GET /pub/WWW/ HTTP/1.1		GET /pub/WWW/ HTTP/1.1
	Host: www.w3.org		Host: www.w3.org
	Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8		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		OPES-System: http://www.isp-example.com/opes/?client-hash=1234567
	Figure 4		Figure 4
	The example below illustrates adaptations done to HTTP response at an		The example below illustrates adaptations done to HTTP response at an
	OPES intermediary operated by a Content Distribution Network (CDN).		OPES intermediary operated by a Content Distribution Network (CDN).
	Both original (as sent by the origin web server) and adapted (as		Both original (as sent by the origin web server) and adapted (as
	received by the end user) responses are shown. The primary adaptation		received by the end user) responses are shown. The primary adaptation
	is the conversion from HTML markup to plain text. The secondary		is the conversion from HTML markup to plain text. The secondary
	adaptation is the addition of an "OPES-Via" HTTP extension header.		adaptation is the addition of an OPES-System HTTP extension header.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Length: 12345		Content-Length: 12345
	Content-Encoding: text/html		Content-Encoding: text/html
	<html><head><h1>Available Documenta...		<html><head><h1>Available Documenta...
	Figure 5		Figure 5
	... may be adapted by a CDN OPES system to become:		... may be adapted by a CDN OPES system to become:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Length: 2345		Content-Length: 2345
	Content-Encoding: text/plain		Content-Encoding: text/plain
	OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t		OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t
	AVAILABLE DOCUMENTA...		AVAILABLE DOCUMENTA...
	Figure 6		Figure 6
	In the above examples, "OPES-Via" header values contain URLs that may		In the above examples, OPES-System header values contain URIs that
	point to OPES-specific documents such as description of the OPES		may point to OPES-specific documents such as description of the OPES
	operator and its privacy policy. Those documents may be		operator and its privacy policy. Those documents may be
	parameterized to allow for customizations specific to the transaction		parameterized to allow for customizations specific to the transaction
	being traced (e.g., client or even transaction identifier may be used		being traced (e.g., client or even transaction identifier may be used
	to provide more information about performed adaptations). Traced OPES		to provide more information about performed adaptations). An OPES-Via
	URLs may be later used to request OPES bypass		header may be used to provide a more detailed trace of specific OPES
			entities within an OPES System that adapted the message. Traced OPES
			URIs may be later used to request OPES bypass
	[I-D.ietf-opes-end-comm].		[I-D.ietf-opes-end-comm].
	5.3 Consideration (3.1) 'Notification'		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
	skipping to change at page 15, 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]
	The OPES framework does not propose adaptation services. However,		The OPES framework 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 [I-D.ietf-opes-end-comm] (XXX: check tracing draft for this		validity [I-D.ietf-opes-end-comm].
	requirement).
	9. Consideration (4.3) 'Addressing extensions'		9. 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 fixes. This document in		OPES framework does not contain ad hoc fixes. This document in
	combination with and other OPES documents should be sufficient to		combination with and other OPES documents should be sufficient to
	skipping to change at page 21, line 7		skipping to change at page 21, line 7
	13. Compliance		13. Compliance
	This document may be perceived as a proof of OPES compliance with IAB		This document may be perceived as a proof of OPES compliance with IAB
	implied recommendations. However, this document does not introduce		implied recommendations. However, this document does not introduce
	any compliance subjects. Compliance of OPES implementations is		any compliance subjects. Compliance of OPES implementations is
	defined in other OPES documents discussed above.		defined in other OPES documents discussed above.
	Appendix A. Change Log		Appendix A. Change Log
	Internal WG revision control ID: $Id: iab-cons.xml,v 1.26 2003/10/27		RFC Editor Note: This section is to be removed during the final
	11:40:33 rousskov Exp $		publication of the document.
			Internal WG revision control ID: $Id: iab-cons.xml,v 1.32 2003/12/03
			06:46:04 rousskov Exp $
			2003/11/18
			* Added an example where an efficient and meaningful notification
			protocol can be implemented in OPES.
			* Assume Communications draft will contain wording about
			documenting impact on reference validity.
			* Use OPES-System HTTP header for examples and mention OPES-Via.
			We still need to get HTTP Adaptations draft in sync with this
			change, but the text now assumes that has been done.
	2003/10/24		2003/10/24
	* Addressed hop-by-hop encryption concerns mentioned in the IAB		* Addressed hop-by-hop encryption concerns mentioned in the IAB
	draft.		draft.
	* Polished IP addressing figure.		* Polished IP addressing figure.
	* Removed resolved XXXs.		* Removed resolved XXXs.
	skipping to change at page 23, line 9		skipping to change at page 23, line 9
	* 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]		[I-D.ietf-opes-end-comm]
	Barbir, A., "OPES processor and end points		Barbir, A., "OPES processor and end points
	communications", draft-ietf-opes-end-comm-04 (work in		communications", draft-ietf-opes-end-comm-05 (work in
	progress), October 2003.		progress), October 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
	skipping to change at page 24, line 19		skipping to change at page 24, line 19
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
	Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/		[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/
	1.1", RFC 2817, May 2000.		1.1", RFC 2817, May 2000.
	[I-D.ietf-opes-http]		[I-D.ietf-opes-http]
	Rousskov, A. and M. Stecher, "HTTP adaptation with OPES",		Rousskov, A. and M. Stecher, "HTTP adaptation with OPES",
	draft-ietf-opes-http-00 (work in progress), August 2003.		draft-ietf-opes-http-01 (work in progress), October 2003.
	[I-D.ietf-opes-ocp-core]		[I-D.ietf-opes-ocp-core]
	Rousskov, A., "OPES Callout Protocol Core",		Rousskov, A., "OPES Callout Protocol Core",
	draft-ietf-opes-ocp-core-01 (work in progress), August		draft-ietf-opes-ocp-core-03 (work in progress), November
	2003.		2003.
	Authors' Addresses		Authors' Addresses
	Abbie Barbir		Abbie Barbir
	Nortel Networks		Nortel Networks
	3500 Carling Avenue		3500 Carling Avenue
	Nepean, Ontario		Nepean, Ontario
	CA		CA
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/