RE: Updated Charter Proposal

Markus,
besides the excessive use of the "In particular" in the charter, I am ok
with it.

abbie

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Markus Hofmann
> Sent: Thursday, August 05, 2004 11:34 AM
> To: OPES Group
> Subject: Updated Charter Proposal
> 
> 
> 
> Folks,
> 
> attached a slightly updated version of the charter proposal, 
> reflecting feedback from our WG meeting this week.
> 
> For any change requests, please propose a specific new wording.
> 
> This version will otherwise be forwarded to IESG for consideration.
> 
> -Markus
> 
> ===================================
> 
> Open Pluggable Edge Services (opes)
> -----------------------------------
> 
> Chair(s):
> Markus Hofmann <[email protected]>
> Tony Hansen <[email protected]>
> 
> Applications Area Director(s):
> Ted Hardie <[email protected]>
> Scott Hollenbeck <[email protected]>
> 
> Applications Area Advisor:
> Ted Hardie <[email protected]>
> 
> Technical Advisor(s):
> Allison Mankin <[email protected]>
> Hilarie Orman <[email protected]>
> 
> Mailing Lists:
> General Discussion: [email protected]
> To Subscribe: [email protected]
> 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 improve the 
> user experience. Web proxies, for example, are commonly deployed to 
> provide services such as Web caching, virus scanning, and request 
> filtering. Lack of standardized mechanisms to trace and to control 
> such intermediaries causes problems with respect to failure 
> detection, 
> data integrity, privacy, and security.
> 
> The OPES Working Group has previously developed an architectural 
> framework to authorize, invoke, and trace such application-level 
> services for HTTP. The framework follows a one-party consent model, 
> which requires that each service be authorized explicitly by at least 
> one of the application-layer endpoints. It further requires that OPES 
> services are reversible by mutual agreement of the 
> application endpoints.
> 
> In particular, the WG has developed a protocol suite for invocation 
> and tracking of OPES services inside the net. The protocol suite 
> includes a generic, application-agnostic protocol core (OCP 
> Core) that 
> is supplemented by profiles specific to the application-layer 
> protocol 
> used between the endpoints. So far, the WG has specified an OCP 
> profile for HTTP, which supports OPES services that operate on HTTP 
> messages.
> 
> In a next step, the WG will specify one or more OCP profiles 
> that will 
> support OPES services operating on SMTP. In particular, the 
> profile to 
> be specified will enable an SMTP server (the OPES processor) to 
> encapsulate and forward SMTP data and metadata to a callout 
> server for 
> additional processing. Several kinds of agents participate in SMTP 
> exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP 
> profile will address the needs of at least the MTA and/or MDA. More 
> profiles may be needed to address other agent-specific needs, such as 
> for LMTP and/or SUBMIT. The security and privacy concerns of 
> SMTP must 
> be carefully analyzed as part of the definition of the profile.
> 
> In addition, the WG will define a rules language to control selection 
> and invocation of services by an OPES processor. This includes a 
> mechanism allowing an OPES processor to perform a runtime check of 
> service parameters, leveraging existing interface description 
> standards like WSDL, if possible, or OPES-specific description 
> otherwise. Defining language(s) for implementing OPES services is out 
> of the WG scope. The rules language will be based on previous work of 
> the WG on a rules language named "P". The WG will have a design goal 
> that the language 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. It 
> will be out of scope for this WG to develop the policy framework and 
> specify multiple-endpoint policy distribution.
> 
> The group's new work items can be listed as:
> 
> - Develop a document about "Scenarios and Use Cases for
>    OPES Services operating on SMTP".
> - Define profile(s) for OCP core that handle SMTP messages
>    or parts thereof.
> - Define a rules language to control the selection and
>    invocation of HTTP-based or SMTP-based OPES services.
> 
> Each deliverable must follow the previously developed OPES 
> architecture. As each deliverable is developed, it must address the 
> IAB considerations specified in RFC 3238.
> 
> Goals and Milestones:
> 
> Done    Submit OPES scenarios document and architecture
>          document to IESG for Informational.
> Done    Submit document on protocol (callout and tracing)
>          requirements to IESG for Informational.
> Done    Submit document on endpoint authorization and
>          enforcement requirements to IESG for Informational.
> Done    Submit document on threat/risk model for OPES
>          services to IESG for Informational.
> Done    Initial protocol document for OPES services
>          including their authorization, invocation,
>          tracking, and enforcement of authorization.
> Done    Initial document on rules specification method.
> Done    Submit protocol document for OPES services
>          including their authorization, invocation,
>          tracking, and enforcement of authorization to IESG
>          for Proposed Standard.
> SEP04   Revised document on OPES rules language.
> OCT04   Submit use cases document for OPES services
>          operating on SMTP to IESG for Informational.
> DEC04   Initial document on OCP/SMTP profile for MTAs,
>          including mechanisms for tracing and bypass.
> FEB05   Submit document on OCP/SMTP profile for MTAs,
>          including mechanisms for tracing and bypass, to
>          IESG for Proposed Standard.
> APR05   Submit document(s) on OCP/SMTP profile(s) for those
>          other SMTP agents the WG has decided to work on, if
>          any, to IESG as Proposed Standard(s).
> MAY05   Submit document(s) on OPES rules language to
>          IESG for Proposed Standard.
> MAY05   Consider additional OPES work and present new
>          charter to IESG, or conclude working group.
> 
> 
>