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.