IESG and IAB final discussions of the charter draft resulted
in the OPES WG being approved yesterday. The announcement and charter
posting on the web will follow, as will announcement of a process-oriented
co-chair for Markus. The WG slot in MN should show up on the next
published agenda.
Feel free to send questions to Ned and me (you guys merit
two shepherding ADs :)
Allison
Open Pluggable Edge Services (opes)
-----------------------------------
Charter
Last Modified: 21-Feb-02
Current Status: Proposed Working Group
Chair(s):
Markus Hofmann <hofmann(_at_)bell-labs(_dot_)com>
TBD
Applications Area Director(s):
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com>
Patrik Faltstrom <paf(_at_)cisco(_dot_)com>
Applications Area Advisor:
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com>
Technical Advisor(s):
Allison Mankin <mankin(_at_)isi(_dot_)edu>
Hilarie Orman <ho(_at_)alum(_dot_)mit(_dot_)edu>
Mailing Lists:
General Discussion:ietf-openproxy(_at_)imc(_dot_)org
To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org
Archive:
http://www.imc.org/ietf-openproxy/mail-archive/
Description of Working Group:
The Internet facilitates the development of networked services at the
application level that both offload origin servers and mediate the
user experience. Proxies are commonly deployed to provide such
services as web caching, request filtering and virus scanning. Lack
of standardized mechanisms to trace and to control such intermediaries
causes problems with respect to failure detection, data integrity,
privacy, and security.
The Open Pluggable Edge Services (OPES) working group is chartered
to define a framework and protocols to both authorize and invoke
distributed application services while maintaining the network's
robustness and end-to-end data integrity. These services may be
server-centric (i.e., an administrative domain that includes the
origin server) and they may be client-centric (i.e., an
administrative domain that includes the user agent).
Services provided in the OPES framework should be traceable by the
application endpoints of an OPES-involved transaction, thus helping
both service providers and end-users detect and respond to
inappropriate behavior by OPES components. In particular, services
provided in the OPES framework should be reversible by mutual
agreement of the application endpoints. Furthermore, the OPES
protocol must include authorization as one if its steps,
and this must be by at least one of the of the application-layer
endpoints (i.e. either the content provider or the content consumer).
In a first step, this working group will investigate and
propose to the Area Directors whether the architecture to be
developed must be compatible with the use of end-to-end integrity
and encryption. Based on this decision, it will examine the
requirements for both authorization and invocation of application
services inside the network. The group will create an architecture for
OPES services applied to application messages, and specify the protocol
for HTTP and RTP/RTSP. The working group will define one or more methods
for specification of policies, as well as the rules that enable
application endpoints to control execution of such services.
The working group will have a design goal that policies affecting
the control and authorization rules be compatible with existing
policy work within the IETF (e.g. IETF Policy Framework) and be
able to interface with systems automating distribution of policies to
multiple endpoints, but it will be out of scope for this work to
develop the policy framework and specify multiple-endpoint policy
distribution.
With the requirements, the working group will specify a protocol or suite
of protocols for invocation and tracking of OPES services inside the
net, including the authorization and enforcement elements for one
endpoint.
The working group will consider the ICAP protocol drafts as an
OPES precursor and will will support development of an
analysis that explains the limitations of ICAP, to accompany
informational publication of that protocol. The working group
will coordinate with other groups such as AVT and MMUSIC (in
regard to RTP/RTSP) and WEBI (in regard to HTTP).
The group's work items can be listed as:
- Develop scenarios and use case document.
- Draft high-level, overall example OPES architecture.
- Define requirements for service invocation and tracing (callout).
- Define policy specification method(s) and rules for controlling
execution of OPES services.
- Define callout and tracing protocol(s).
- Develop a vulnerability assessment and use this
to guide each type of security service to be included
in the protocols developed.
As each deliverable is developed, it must address the IAB
considerations specified in RFC 3238.
Deliverables:
- OPES scenarios and use case document.
- General OPES architecture/framework.
- Requirements for authorization and enforcement of OPES services.
- Requirements for invocation and tracking of OPES services.
- Vulnerability assessment document for OPES services.
- Mechanisms and protocols for service invocation and service tracking.
Goals and Milestones:
Apr 02 Submit OPES scenarios document and
architecture document to IESG for Informational.
Apr 02 Submit document on protocol (callout and tracing)
requirements to IESG for Informational.
Apr 02 Submit document on endpoint authorization
and enforcement requirements to IESG for
Informational.
Apr 02 Submit document on threat/risk model for OPES services
to IESG for Informational.
Jul 02 Initial protocol document for OPES services
including their authorization, invocation, tracking,
and enforcement of authorization
Sep 02 Submit protocol document for OPES services
including their authorization, invocation, tracking,
and enforcement of authorization to IESG for
Proposed Standard
Sep 02 Consider additional OPES work such as extension
to traffic beyond HTTP and RTSP and present new
charter to IESG, or conclude working group.