draft-ietf-opes-iab-01.txt		draft-ietf-opes-iab-02.txt
	Open Pluggable Edge Services A. Barbir		Open Pluggable Edge Services A. Barbir
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: February 25, 2004 A. Rousskov		Expires: March 23, 2004 A. Rousskov
	The Measurement Factory		The Measurement Factory
	August 27, 2003		September 23, 2003
	OPES Treatment of IAB Considerations		OPES Treatment of IAB Considerations
	draft-ietf-opes-iab-01		draft-ietf-opes-iab-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 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 February 25, 2004.		This Internet-Draft will expire on March 23, 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 16		skipping to change at page 2, line 16
	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 . . . . . . . . . . . . . . . 10
	5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12		5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12
	5.5 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 12		6. Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 13
	6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14		7. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14
	7. Consideration (4.2) Reference validity . . . . . . . . . . . . 15		8. Consideration (4.2) Reference validity . . . . . . . . . . . . 15
	8. Consideration (4.3) Addressing extensions . . . . . . . . . . 16		9. Consideration (4.3) Addressing extensions . . . . . . . . . . 16
	9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17		10. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 18		11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19		12. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		13. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21		A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Normative References . . . . . . . . . . . . . . . . . . . . . 23		Normative References . . . . . . . . . . . . . . . . . . . . . 23
	Informative References . . . . . . . . . . . . . . . . . . . . 24		Informative References . . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . 25		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
	skipping to change at page 9, line 28		skipping to change at page 9, line 28
	different organizations and have different optimization priorities		different organizations and have different optimization priorities
	may be impossible.		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".
			Nevertheless, OPES architecture allows for an efficient and
			meaningful notification protocol to be implemented in certain OPES
			environments. For specific examples, see the "Optional Notification"
			section in [I-D.ietf-opes-end-comm].
	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 intermediary operated by the client ISP. Both original (as sent		OPES intermediary operated by the client ISP. Both original (as sent
	by an end user) and adapted (as received by the origin web server)		by 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.		"OPES-Via" HTTP extension header.
	GET /pub/WWW/ HTTP/1.1		GET /pub/WWW/ HTTP/1.1
	skipping to change at page 12, line 29		skipping to change at page 13, line 5
	protocols may not have explicit responses (e.g., event logging		protocols may not have explicit responses (e.g., event logging
	service).		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.5 Consideration (3.3) Non-blocking		6. 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) [I-D.ietf-opes-end-comm]. If an application message includes		draft) [I-D.ietf-opes-end-comm]. If an application message includes
	bypass instructions and an OPES intermediary is not configured to		bypass instructions and an OPES intermediary is not configured to
	ignore them, the matching OPES intermediary will not process the		ignore them, the matching OPES intermediary will not process the
	skipping to change at page 14, line 5		skipping to change at page 14, line 5
	Bypass support has limitations similar to the two		Bypass support has limitations similar to the two
	notification-related considerations above. (XXX: but it is possible		notification-related considerations above. (XXX: but it is possible
	to instruct all OPES intermediaries to bypass an application message		to instruct all OPES intermediaries to bypass an application message
	without knowing all OPES intermediaries IDs).		without knowing all OPES intermediaries IDs).
	(XXX: Ideally, this section need to be polished further -- if there		(XXX: Ideally, this section need to be polished further -- if there
	is no non-OPES version of the content, most IAB considerations		is no non-OPES version of the content, most IAB considerations
	probably do not apply because there is really no adaptation, only		probably do not apply because there is really no adaptation, only
	creation of content; and we should not restrict content creation.)		creation of content; and we should not restrict content creation.)
	6. Consideration (4.1) URI resolution		7. 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
	do not include URI resolution (XXX check). In some environments, it		do not include URI resolution (XXX check). In some environments, it
	is technically possible to adapt URIs (and other kinds of identifiers		is technically possible to adapt URIs (and other kinds of identifiers
	or addresses) using documented OPES mechanisms.		or addresses) using documented OPES mechanisms.
	7. Consideration (4.2) Reference validity		8. Consideration (4.2) Reference validity
	"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) [I-D.ietf-opes-end-comm].		validity (XXX quote tracing draft) [I-D.ietf-opes-end-comm].
	8. 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 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. Such actions		work within IETF on potential extension requirements. Such actions
	would be outside of the current OPES framework.		would be outside of the current OPES framework.
	9. Consideration (5.1) Privacy		10. 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
	intermediaries, including their privacy policies.		intermediaries, including their privacy policies.
	skipping to change at page 18, line 5		skipping to change at page 18, line 5
	context (by IAB or OPES working group). OPES tracing mechanisms allow		context (by IAB or OPES working group). OPES tracing mechanisms allow
	end users and content providers to identify OPES intermediaries. It		end users and content providers to identify OPES intermediaries. It
	is believed that once an intermediary is identified, it would be		is believed that once an intermediary is identified, it would be
	possible to locate relevant information about that intermediary,		possible to locate relevant information about that intermediary,
	including information relevant to requesters perception of privacy		including information relevant to requesters perception of privacy
	policy or reference validity. (XXX: should we move this paragraph		policy or reference validity. (XXX: should we move this paragraph
	into a separate section and expand it? one the other hand, it is		into a separate section and expand it? one the other hand, it is
	probably the job of the architecture draft to define these things so		probably the job of the architecture draft to define these things so
	that we can refer to them from here.)		that we can refer to them from here.)
	10. Security Considerations		11. Security Considerations
	XXX.		XXX.
	11. Compliance		12. 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.
	12. To-do		13. 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, OPES systems, and privacy policies?		internal OPES intermediaries, OPES systems, and privacy policies?
	Should this document be limited to a compilation of references		Should this document be limited to a compilation of references
	from other OPES drafts, or should we introduce/discuss new		from other OPES drafts, or should we introduce/discuss new
	concepts here?		concepts here?
	Appendix A. Change Log		Appendix A. Change Log
	Internal WG revision control ID: $Id: iab-cons.xml,v 1.19 2003/08/28		Internal WG revision control ID: $Id: iab-cons.xml,v 1.20 2003/09/24
	03:48:32 rousskov Exp $		05:20:21 rousskov Exp $
			2003/09/23
			* Added a reference to Optional Notification section of the
			ietf-opes-end-comm draft.
			* Fixed "Consideration (3.3) Non-blocking" section position.
	head-sid15		head-sid15
	* Added a figure showing a chain of internal OPES intermediaries		* Added a figure showing a chain of internal OPES intermediaries
	behind a public IP address. Needs more work. More cases?		behind a public IP address. Needs more work. More cases?
	head-sid14		head-sid14
	* Rewrote the Introduction to the IP addressing consideration.		* Rewrote the Introduction to the IP addressing consideration.
	Do NOT explain how IAB considerations, if interpreted literary,		Do NOT explain how IAB considerations, if interpreted literary,
	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-00 (work in		communications", draft-ietf-opes-end-comm-02 (work in
	progress), June 2003.		progress), September 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/