Browse Prior Art Database

IAB Architectural and Policy Considerations for Open Pluggable Edge Services (RFC3238)

IP.com Disclosure Number: IPCOM000006754D
Original Publication Date: 2002-Jan-01
Included in the Prior Art Database: 2002-Jan-30
Document File: 18 page(s) / 42K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Floyd: AUTHOR [+2]

Abstract

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 8% of the total text.

Network Working Group                  Internet Architecture Board (IAB)

Request for Comments: 3238                                      S. Floyd

Category: Informational                                        L. Daigle

                                                            January 2002

            IAB Architectural and Policy Considerations for

                      Open Pluggable Edge Services

Status of this Memo

   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document includes comments and recommendations by the IAB on

   some architectural and policy issues related to the chartering of

   Open Pluggable Edge Services (OPES) in the IETF.  OPES are services

   that would be deployed at application-level intermediaries in the

   network, for example, at a web proxy cache between the origin server

   and the client.  These intermediaries would transform or filter

   content, with the explicit consent of either the content provider or

   the end user.

1.  Introduction

   Open Pluggable Edge Services (OPES) are services that would be

   deployed in the network, for example, at a web proxy cache between

   the origin server and the client, that would transform or filter

   content.  Examples of proposed OPES services include assembling

   personalized web pages, adding user-specific regional information to

   web pages, virus scanning, content adaptation for clients with

   limited bandwidth, language translation, and the like [OPES].

   The question of chartering OPES in the IETF ([OPESBOF1], [OPESBOF2],

   [OPESBOF3]) and the related controversy in the IETF community

   ([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) have raised

   to the fore several architectural and policy issues about robustness

   and the end-to-end integrity of data (in terms of the disparities

   between what the "origin server" makes available and what the client

   receives).  In particular, questions have been raised about the

   possible requirements, for a protocol to be developed and

IAB                          Informational                      [Page 1]

RFC 3238              IAB Considerations for OPES           January 2002

   standardized in the IETF, for that protocol to protect the end-to-end

   privacy and integrity of data.  This document attempts to address

   some of the architectural and policy issues that have been unresolved

   in the chartering of OPES, and to come to some common recommendations

   from the IAB regarding these issues.

   The purpose of this document is not to recommend specific solutions

   for OPES, or even to mandate specific functional requirements.  This

   is also not a recommendation to the IESG about whether or not OPES

   should be chartered.  Instead, these are recommendations on issues

   that any OPES solutions standardized in the IETF should be required

   to address, similar to the "Security Considerations" currently

   required in IETF documents [RFC2316].  As an example, one way to

   address security issues is to show that appropriate security

   mechanisms have been provided in the protocol, and another way to

   address security issues is to demonstrate that no security issues...