RE: Revised Charter for BOF Discussion and Concensus

The term surrogate has meaning beyond replica origin servers.  It is often
the case that surrogates are intermediary reverse caching proxies.  I think
the term intermediary needs to be further discussed and a term defined for
it.  In my mind, CDN surrogates are very likely to be reverse caching
proxies (i.e. shared distributed server accelerators) operating at the
delivery edge of the CDN.  I'm also aware of a number of OPES applications
that various content providers would like to have hosted on these types of
intermediaries as well.

Gary

-----Original Message-----
From: Micah Beck [mailto:mbeck(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Tuesday, March 06, 2001 9:26 PM
To: Hilarie Orman; ietf-openproxy(_at_)imc(_dot_)org; 
condry(_at_)intel(_dot_)com
Cc: paf(_at_)cisco(_dot_)com; ned(_dot_)freed(_at_)innosoft(_dot_)com
Subject: Re: Revised Charter for BOF Discussion and Concensus


If the charter does not rule out surrogates, then I'm satisfied.  I agree
that intermediaries are the primary case for OPES, and I speak up for
non-intermediaries to be considered only because there seems to me to be no
fundamental difference between the two cases.  If broadening the scope to
include non-intermediaries would complicate OPES or delay consensus, then I
agree with Marcus that it should be deferred.  It is my belief that
non-intermediaries are actually a simpler case and can be subsumed under the
more complex case of intermediaries, with perhaps minor adjustments.  I'm
willing to put in the effort to find out if that belief is true.

/micah

----- Original Message -----
From: "Hilarie Orman" <HORMAN(_at_)volera(_dot_)com>
To: <mbeck(_at_)cs(_dot_)utk(_dot_)edu>; <ietf-openproxy(_at_)imc(_dot_)org>; 
<condry(_at_)intel(_dot_)com>
Cc: <paf(_at_)cisco(_dot_)com>; <ned(_dot_)freed(_at_)innosoft(_dot_)com>
Sent: Tuesday, March 06, 2001 7:44 PM
Subject: Re: Revised Charter for BOF Discussion and Concensus

I don't think the charter rules out surrogates, but I see that the
wording is perhaps overly narrow.  I think we can take the
reasonable interpretation that our foremost priority is to address
the intermediary case, but we will be pleased to have the
design accommodate surrogates, too.  One might imagine
an eventual "OPES domain of interpretation for surrogates"
as a WG document.

Hilarie

"Micah Beck" <mbeck(_at_)cs(_dot_)utk(_dot_)edu> 03/06/01 02:21PM >>>

Michael,

My concern is that the rule framework being devised is being scoped too
narrowly, specifically to "services executed on application data by
participating transit intermediaries."   I am interested in using this

rule

language for services executed on non-caching replica servers that may not
be transit intermediaries (unless I'm not understanding the meaning of
transit intermediaries).  If the charter does not reflect the additional
goal of devising a rule language usable for both caches and replica

servers

that are not caches, then the specification coming out of this group may

not

be adequate to that purpose.  Which would mean that we would need to have
another, perhaps very similar, rule language for specifying "services
executed on application data by participating replica servers."

The fundamental difference between the rules for caches and the rules for
replica servers is the API of the proxylets/servelets invoked by those
rules.  Aside from this difference, I am quite sure that a single rule
language can suffice for both purposes, but not if the design criteria for
that language are drawn too narrowly.

/micah

----- Original Message -----
From: "Michael W. Condry" <condry(_at_)intel(_dot_)com>
To: <ietf-openproxy(_at_)imc(_dot_)org>
Cc: <paf(_at_)cisco(_dot_)com>; <ned(_dot_)freed(_at_)innosoft(_dot_)com>
Sent: Tuesday, March 06, 2001 3:51 PM
Subject: Revised Charter for BOF Discussion and Concensus

Mail discussions and our workshop suggested that the initial focus
of the working group should be organization of requirements for the
overall OPES architecture and delivery of specific solutions, such as
callout service protocols. With this in mind Hilarie and I have revised

the

charter to reflect this need, assuring we are working on an industry

consensus

plan and havedistinguished goals from MidCom, CDI, MidTax, etc.

Here is the revised charter:


Orthogonal Protocol Extension Services(opes)

Co-chairs:
    Michael Condry <condry(_at_)intel(_dot_)com>
    Hilarie Orman <HORMAN(_at_)novell(_dot_)com>

Mailing Lists:
    General Discussion: ietf-openproxy(_at_)imc(_dot_)org
    To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org
    Web: http://www.extproxy.org
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes

Description of Working Group:

The Orthogonal Protocol Extension Services architecture (OPES) enables
construction of services executed on application data by participating
transit intermediaries.  Caching is the most basic intermediary service,
one that requires a basic understanding of application semantics by the
cache server.  Because intermediaries divert data temporarily over a
pathway different from the transit pathway, one can think of the service
path as being orthogonal to the main transit path.  The purpose of this
working group is to define the protocols and API's for a broad set of
services that facilitate efficient delivery of complex content or

services

related to content.  The advantage of standardizing these protocols and
API's is that the services can be re-used across vendor products without
modifying the transit intermediaries or services.

The architecture supports services that are either co-located with the
transit intermediary or located on other servers (referred to as

auxiliary

servers in this charter).  The ICAP protocol is being developed for
carrying HTTP headers and data to cooperating servers; other protocols

for

carrying SMTP or other protocols to cooperating servers will be

supported

by the framework, as they exist or become available.  This working group
defines the supporting configuration data and protocols for configuring
services on the transit intermediaries; this configuration makes it
possible to administer collections of transit intermediaries and content
services as a coherent system.

There are four parts of a good service definition for transit-based
extensions to an application protocol.  The first part defines the

protocol

processing point or points in the intermediary that could detect an
application data event of interest to the auxiliary service.  The second
part defines the server, the access method for the server, and the
marshaled form for arguments added when delivering the application data

to

the auxiliary server.  The third defines the post processing of the data
returned by the auxiliary.  The fourth element of the definition is an
encoding of the above information combined with the service extension
itself, defined as some form of loadable code or access method for

invoking

the code.  The working group will define an information model and
realization of the model into repository and protocol elements.

These service definitions must be standardized in ways that are

compatible

with the policy framework of the Policy working group. The definitions
constitute configuration information that can come from repositories or
runtime protocols; for example, and ICAP server coming on-line can

notify

its clients of the services it offers, and it can update their status
("up", "changed", "suspended", "moved") while it is running.  A

namespace

for services and a means for registering names will be considered.

Some crucial data must be communicated from the intermediary to the
auxiliary server in standardized semantics.  Identification and
authentication information for the application connection may be

important

to the auxiliary processing, for example.  The working group will define

core set of information necessary for supporting generic application

needs.


Postprocessing the result from the auxiliary processor is done at the
option of the intermediary, but instructions from the auxiliary server

must

be communicated in a standardized manner.  Generic directives ("drop",
"hold", "assign attribute", are examples.  The working group will define
postprocessing directives and the rules for their interaction with the
configuration policy.

The security model for intermediary services involves defining the
administrator roles and privileges for the application client,

application

server, intermediary, and auxiliary server.  The working group will use

the

Policy Configuration Information Model to define the security attributes
and the enforceable policy.

The working group items for delivery are
1.      A "side transit" protocol (ICAP) for use with HTTP
2.      A policy-based configuration and definition model for orthogonal
service extensions
a.      To include representation of conditions leading to invocation of
extension services, common data items (identities, authentication state,
etc.), postprocessing directives, and the access method for the service

or

a representation of a loadable service (URL or encoded executable or
interpretable code, for example).
b.      A specific repository-based embodiment of the model
c.      A delivery protocol embodying the elements of the model as a
language; the protocol may be embedded in HTTP and/or ICAP.
d.      Recommended procedures for registering service names and
repositories for extensions
3.      A security model and security configuration policy definitions,
i.e. roles, privileges, and enforcement point responsibilities.

After these items have been delivered, the working group can examine the
progress in this area and, if appropriate, re-charter to with more
general work items in the OPES framework.

Existing Internet-Drafts
Basic Requirements:
         http://draft-tomlinson-epsfw-00.txt
Initial iCAP Callout Server:
         http://draft-elson-opes-icap-00.txt
A Rule Specification Language for Proxy Services:
         http://draft-beck-opes-psrl-00.txt
General Use Cases:
         http://draft-beck-opes-esfnep-01.txt


Goals and Milestones:

Feb 01: Requirements and roadmap documents for WG
Feb 01: First draft of HTTP orthogonal protocol; first draft of policy
information model
Mar 01: Meet at Minneapolis IETF
Mar 01: OPES architecture and requirements documents
Jun 01: Submission of security model and configuration policy to IETF
Jul 15: Draft of policy rules, enforcement semantics, standard data

items,

and post processing
Aug 01: Meet at London IETF
Aug 01: Final submission of HTTP orthogonal protocol.
Oct 01: Submission of repository specific and ICAP-based policy rule
deliver protocol
Dec 01: Salt Lake City IETF.
Dec 01: Review charter, if necessary, amend for additional orthogonal
protocol definitions, standard data items, postprocessing directives.






Michael W. Condry
Director, Network Edge Technology