Re: OPES Boiler Plate

Alex,

> 	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.

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

> [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?]

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 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.

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

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.

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 OPES architecture and common terminology are described in "An 
Architecture for Open Pluggable Edge Services (OPES)" 
[I-D.draft-ietf-opes-architecture].

"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.

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

"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.

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.

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

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.

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 protected]). P language 
is meant for configuring application proxies (OPES processors).