Subject: OPES Boiler Plate

From: Markus Hofmann <[email-masked]>
Date: Mon, 08 Dec 2003 23:05:07 -0500

Folks,

"external" reviewers pointed out that it's hard to follow how the 
various OPES documents play together.

As such, we intend to add an "OPES Boiler Plate" to each of our WG 
documents, which guides the reader through the various documents.

Bellow a strawman proposal for such boiler plate. If you have 
suggestions on how to improve it, please PROVIDE SPECIFIC TEXT rather 
then generic comments.

Thanks,
   Markus

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

Overview of OPES documents

The OPES Working Group has produced a series of documents that 
together provide a motivation and a description of the OPES 
architecture and the protocols being used therein.

The document on "OPES Use Cases and Deployment Scenarios" 
[I-D.draft-ietf-opes-scenarios] describes a set of services and 
applications that are considered in scope for OPES and have been used 
as a motivation and guidance in designing the OPES architecture. The 
list of services and applications presented in this document is not 
exhaustive, additional services and applications beyond the ones 
presented in the document are expected to be deployed based on the 
OPES architecture.

The OPES architecture itself is described in "An Architecture for Open 
Pluggable Edge Services (OPES)" [I-D.draft-ietf-opes-architecture]. 
The document also attempts to layout the core terminology used across 
the various OPES documents.

The architecture document is augmented by the document on "Policy, 
Authorization and Enforcement Requirements of OPES" 
[I-D.draft-ietf-opes-authorization], which should not be seen as a 
specification of concrete authorization and enforcement methods, but 
rather outlines requirements and assumptions on the policy framework 
underlying OPES.

The security threats and risks associated with OPES are investigated 
in "Security Threats and Risks for OPES" 
[I-D.draft-ietf-opes-threats]. The purpose of this document is to 
identify and discuss possible threats that arise from the nature of 
OPES, but it does not specify or recommend specific solutions.

When the OPES WG was chartered, the IETF Internet Architecture Board 
(IAB) expressed nine architecture-level considerations for the Open 
Pluggable Edge Services (OPES) framework to be addressed by the WG. 
Rather then spreading the explanations for these consideration across 
the various OPES documents, the WG decided to produce a single 
document that collectively addresses all nine of the IAB 
considerations in one place. The document is named "OPES Treatment of 
IAB Considerations" [I-D.draft-ietf-opes-iab].

At the core of the OPES architecture are the OPES processor and the 
callout server, two network elements that communicate with each other 
via an OPES Callout Protocol. The requirements for such protocol are 
discussed in "Requirements for OPES Callout Protocols" 
[I-D.draft-ietf-opes-protocol-reqs].

The document on "OPES Callout Protocol Core" 
[I-D.draft-ietf-opes-ocp-core-03] finally specifies an application 
agnostic protocol core to be used for the communication between OPES 
processor and callout server, with generic tracing and bypass 
mechanisms defined in "OPES entities and end points communication" 
[I-D.draft-ietf-opes-end-comm-05]. The core document itself does not 
provide a complete protocol specification, but rather defines a common 
protocol framework that has to be complemented by application specific 
profiles.

One of such profiles is specified in "HTTP adaptation with OPES" 
[I-D.draft-ietf-opes-http]. It specifies how application-agnostic 
mechanisms such as OPES tracing, OPES bypass, and OPES protocol core 
are to be used and augmented in order to support adaptation of HTTP 
messages. Additional profiles beyond HTTP are expected to be worked on 
in the future.

Finally, the document on "P: Message Processing Language" 
[I-D.draft-ietf-opes-rules-p-02] defines a simple language for 
specifying message processing instructions at application proxies. It 
can be used to instruct OPES intermediaries how to manipulate 
application messages. For example, it can be used to tell an OPES 
processor which HTTP messages have to be forwarded to a callout server 
(via the OPES callout protocol) for performing a certain OPES service.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 11 Dec 2003 16:23:23 -0700 (MST)

On Mon, 8 Dec 2003, Markus Hofmann wrote:

> suggestions on how to improve it, please PROVIDE SPECIFIC TEXT
> rather then generic comments.

Markus,

	I have one generic comment that I will provide, despite your
request, in order to motivate my specific suggestions below. The
proposed text is too long and too detailed. Boiler plate purpose
should be to position the reader in the right place within the OPES
document hierarchy, not to explain subtle features and shortcomings of
every document. Let's try to make it shorter.

	My SPECIFIC TEXT is inlined below.

> Overview of OPES documents

OPES document map

> architecture and the protocols being used therein.

This document belongs to a large set of OPES specifications produced
by the IETF OPES Working Group. Familiarity with the overall OPES
approach and typical scenarios is often essential when trying to
comprehend isolated OPES documents. This section provides an index of
OPES documents to assist the reader with finding "missing"
information.

> applications that are considered in scope for OPES and have been
> used as a motivation and guidance in designing the OPES
> architecture.

> The list of services and applications presented in this document is
> not exhaustive, additional services and applications beyond the ones

[Delete everything starting from "The list of services" ]

> The OPES architecture itself is described in "An Architecture for
> Open Pluggable Edge Services (OPES)"
> [I-D.draft-ietf-opes-architecture].  The document also attempts to
> layout the core terminology used across the various OPES documents.

The OPES architecture and common terminology are described in "An
Architecture for Open Pluggable Edge Services (OPES)"
[I-D.draft-ietf-opes-architecture].

> rather outlines requirements and assumptions on the policy framework

"Policy, Authorization and Enforcement Requirements of OPES"
[I-D.draft-ietf-opes-authorization] outlines requirements and
assumptions on the policy framework, without specifying concrete
authorization and enforcement methods.

> OPES, but it does not specify or recommend specific solutions.

"Security Threats and Risks for OPES"  [I-D.draft-ietf-opes-threats]
provides OPES risk analysis, without recommending specific solutions.

> Rather then spreading the explanations for these consideration
> across the various OPES documents, the WG decided to produce a
> single document that collectively addresses all nine of the IAB
> considerations in one place. The document is named "OPES Treatment
> of IAB Considerations" [I-D.draft-ietf-opes-iab].

"OPES Treatment of IAB Considerations" [I-D.draft-ietf-opes-iab]
addresses all architecture-level considerations expressed by the IETF
Internet Architecture Board (IAB) when the OPES WG was chartered.

> callout server, two network elements that communicate with each
> other via an OPES Callout Protocol. The requirements for such
> protocol are discussed in "Requirements for OPES Callout Protocols"

[Add "(OCP)" after "OPES Callout Protocol"]

[Is the requirements document important at this point in time?  Isn't
it more like an internal, temporary document to guide protocol
development process? Does the requirements document contain anything
that will help the reader of other documents? Can we drop the above
paragraph or at least leave it in OCP Core only?]

> provide a complete protocol specification, but rather defines a
> common protocol framework that has to be complemented by application
> specific profiles.

"OPES Callout Protocol Core" [I-D.draft-ietf-opes-ocp-core-03]
specifies a protocol core to be used for the communication between
OPES processor and callout server.

"OPES entities and end points communications"
[I-D.draft-ietf-opes-end-comm-05] specifies generic tracing and bypass
mechanisms for OPES.

> messages. Additional profiles beyond HTTP are expected to be worked
> on in the future.

The OCP Core and Communications documents are independent from the
application protocol being adapted by OPES entities. Their generic
mechanisms have to be complemented by application-specific profiles.
"HTTP adaptation with OPES" is such an application profile for HTTP.
It specifies how application-agnostic OPES mechanisms are to be used
and augmented in order to support adaptation of HTTP messages.

> specifying message processing instructions at application proxies.
> It can be used to instruct OPES intermediaries how to manipulate
> processor which HTTP messages have to be forwarded to a callout
> server (via the OPES callout protocol) for performing a certain OPES
> service.

Finally, "P: Message Processing Language"
[I-D.draft-ietf-opes-rules-p-02] defines a language for specifying
what OPES adaptations (e.g, translation) must be applied to what
application messages (e.g., e-mail from [email-masked]). P language
is meant for configuring application proxies (OPES processors).

HTH,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 15 Dec 2003 10:41:12 -0500

Alex,

> every document. Let's try to make it shorter.

Agreed - I like simpler and shorter :) I've taken your suggestions - 
see below for new boiler plate.

> paragraph or at least leave it in OCP Core only?]

Agreed, either way is fine by me. But since the protocol requirements 
draft is WG output, it might be helpful to include it here, just so 
that people know the context. IF there are no strong feelings, let's 
keep it in. If some one objects, I wouldntt mind taking it out.

> OPES processor and callout server.

I addedd "...specifies an application agnostic protocol core..."

I'd suggest to use the version of the boiler plate below. If no one 
objects, could the authors please add the boiler plate to the 
currently open documents (i.e. documents not yet submitted to IESG/in 
RFC Ed queue).

Thanks,
   Markus

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

OPES Document Map

OPES documents to assist the reader with finding "missing" information.

The document on "OPES Use Cases and Deployment Scenarios" 
[I-D.draft-ietf-opes-scenarios] describes a set of services and 
applications that are considered in scope for OPES and have been used 
as a motivation and guidance in designing the OPES architecture.

At the core of the OPES architecture are the OPES processor and the 
callout server, two network elements that communicate with each other 
via an OPES Callout Protocol (OCP). The requirements for such protocol 
are discussed in "Requirements for OPES Callout Protocols" 
[I-D.draft-ietf-opes-protocol-reqs].

"OPES Callout Protocol Core" [I-D.draft-ietf-opes-ocp-core-03] 
specifies an application agnostic protocol core to be used for the 
communication between OPES processor and callout server.