Re: WG Action: RECHARTER: Open Pluggable Edge Services (opes)

I hoped they would remove the exclusive restriction to the outdated 
client-server model.  When is IAB going to be told we are no more on 
ARPANET, but on the ARPANET Internet?
jfc

PS. for obvious reasons, I would suggest currently proposed TCP/IP 
windowing restrictions be included in OCP and other protections are 
considered. OPES _are_ about dataflow content stuffing. There must be an 
absolute certitude that an added content is not from hacking.



At 22:30 22/04/04, Markus Hofmann wrote:


>Folks,
>
>just in case you're wondering... This is about removing the rules language 
>work item from our current charter, according to discussions we had before 
>on the mailing list.
>
>We'll now focus on addressing the IESG feedback on the tracing draft, 
>re-submit this draft, and then go into discussing possible re-charter 
>(with the discussions including the rules language).
>
>Of course, we'll also respond to IESG feedback to our other docuemnts as 
>it becomes available.
>
>Thanks,
>   Markus
>
>The IESG wrote:
>>The charter of the Open Pluggable Edge Services (opes) working group in 
>>the Application Area of the IETF has been updated. For additional 
>>information, please contact the Area Directors or the working group Chairs.
>>Open Pluggable Edge Services (opes)
>>------------------------------------
>>Current Status: Acrive Working Group
>>Chair(s):
>>Marshall T. Rose <[email protected]>
>>Markus Hofmann <[email protected]>
>>Applications Area Director(s):
>>Ted Hardie <[email protected]>
>>Scott Hollenbeck <[email protected]>
>>Applications Area Advisor:
>>Scott Hollenbeck <[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 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:
>>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.
>>Oct 03  Consider additional OPES work such as extension to traffic beyond 
>>HTTP and RTSP and     present new charter to IESG, or conclude working group.
>
>
>