Subject: Latest Charter Proposal

From: Markus Hofmann <[email-masked]>
Date: Thu, 15 Jul 2004 10:00:31 -0400

Folks,

below the latest charter proposal. I'd like to close on this soon and 
forward to our Area Directors for feedback.

Please take a careful look. If you've comments, please make *specific* 
suggestions on where the text should be changed and how it should be 
changed.

If there are no more comments by Friday, 7/16, 5pm (EST), I'll forward 
this version of the charter to Ted/IESG.

Thanks,
   Markus

=====================

Open Pluggable Edge Services (opes)
-----------------------------------

Chair(s):
Markus Hofmann <[email-masked]>

Applications Area Director(s):
Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>

Applications Area Advisor:
Ted Hardie <[email-masked]>

Technical Advisor(s):
Allison Mankin <[email-masked]>
Hilarie Orman <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
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. 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 messages. In particular, the 
profile to be specified will enable an OPES processor to encapsulate 
and forward SMTP messages (or parts thereof) 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. More profiles may 
be needed to address other agent-specific needs.

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 rule language named "P". The working group 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 scenarios and use case document for OPES
   services operating on SMTP messages.
- Define SMTP profile(s) to supplement OCP core.
- 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 messages to IESG for
         Informational.
DEC04   Initial document on OCP/SMTP profile for MTAs.
FEB05   Submit document on OCP/SMTP profile for MTAs 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.
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.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 23:23:09 -0600 (MDT)

Markus,

	I have only one important correction and two minor questions:

Correction: Please replace
	"operating on SMTP messages" with
	"adapting SMTP"
and
	"forward SMTP messages (or parts thereof)" with
	"forward SMTP data and metadata".
This change should capture everything we might need to adapt.

I think Martin gave us enough use cases to at least include SMTP
command adaptation in the charter, but I am not sure we will end up
adapting commands themselves and not SMTP state. Martin's examples
seem to indicate that we are talking about some processing state
adaptation.

Question1: Should "OCP/SMTP profile for X" in deadlines be replaced
with something like "SMTP adaptation for X with OPES"? Since those
drafts will include tracing/bypass profile as well as OCP profile, it
seems wrong to call them just "OCP/SMTP profile". We called HTTP draft
"HTTP adaptation with OPES" for that reason...

Question2: Should APR05 deadline have something like "to IESG as
Proposed Standard(s)"?

Thanks,

Alex.

On Thu, 15 Jul 2004, Markus Hofmann wrote:

> support OPES services operating on SMTP messages. ...
> additional processing. ...
> ...
> ...

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 16 Jul 2004 03:12:28 -0400

Alex,

> 	"operating on SMTP messages" with

I never liked the term "adaptation" too much for describing OPES 
services, since there are OPES services that do *not* adapt, i.e. 
don't change dataat all (logging being one example). Any specific 
reason why you prefer the term "adapting"?

> 	"forward SMTP data and metadata".

Sounds good, I'll change that.

> "HTTP adaptation with OPES" for that reason...

Same feeling about using the term "adaptation" as above. I would 
consider the current phrasing OK, but if there are strong feelings I'd 
be open to re-phrase.

> Question2: Should APR05 deadline have something like "to IESG as

Yup, will add that.

Thanks much!!

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 16 Jul 2004 16:54:51 -0600 (MDT)

> reason why you prefer the term "adapting"?

The reason for correction is not the word "adaptation" but that the
original wording limits us to operating on SMTP messages rather than
SMTP messages, commands, states, etc. Martin's examples illustrate why
operating on MIME messages alone is not sufficient.

> consider the current phrasing OK, but if there are strong feelings I'd

It's not the word adaptation that I am after. It is including tracing
and bypass. The current wording inlcudes only OCP, and not OPES
Communications stuff.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 16 Jul 2004 23:59:20 -0400

> operating on MIME messages alone is not sufficient.

"Adaptation" alone is not sufficient either. Your main concern seems 
to be the term "SMTP messages", since it leaves out SMTP commands etc. 
So I'll put "...support OPES services operating on SMTP..." and remove 
the "messages". This should include the commands etc.

> and bypass. The current wording inlcudes only OCP, and not OPES

So let's not use the term 'adaptation' then. I'll put in "Initial 
document on OCP/SMTP profile for MTAs, including mechanisms for 
tracing and bypass" for now.

-Markus