Apologies in advance for duplication of comments that have already been
discussed here and for the delay in getting them to the list.
I'm quoting lots of the draft but I've tried to snip out the parts where I
have no comments. My apologies if I'm not around to respond to comments
until Friday.
1. Introduction
When realizing a data stream service between a provider and a
^^^^^^^^^
We've had comments on the use of this word before; I guess I still don't
like it. Would replacing with "supplying" cause a problem?
consumer, the need may arise to provision the use of other
application entities, in addition to the provider and consumer. For
example, some party may wish to customize a data stream as a service
to a consumer. The customization step might be based on the
customer's geographical locality (e.g., language) or resource
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
availability (e.g., display capabilities).
Geographical locality and the example of use of language don't really gel
for me. Language translation would seem to be a customer's "personal
special needs" rather than something related to their geographic locality.
In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
at a network location
the consumer host. For certain services performed on end-user behalf
^^^^^^^^^^^^^^^^^
Are the provider and consumer hosts not leaf node network locations?
Maybe:
"at a network location between the provider and consumer host rather than
at one of these endpoints"
this may be the only option of service deployment. In this case, one
or more additional application entities may participate in the data
stream service. There are many possible provisioning scenarios which
make a data stream service attractive. In [1] a description of
several scenarios is provided.
[snip remainder of introduction]
2.1 OPES Entities
An OPES entity is an application that operates on a data flow between
a data provider application and a data consumer application. OPES
entities can be one of the following:
^^^^^^^^^^^^^
o an OPES service application, which analyzes and possibly
transforms messages exchanged between the data provider
application and the data consumer application; or,
^^^^
o a data dispatcher, which invokes an OPES service application based
on OPES ruleset and application-specific knowledge.
I'm not sure I see the reason why the dispatcher and the service
application need to be bundled together to form a superset "entity" term.
In the network, OPES entities reside inside OPES processors. The
cooperative behavior of OPES entities introduces additional
functionality for each data flow provided that it matches the OPES
rules.
In the current work, the data provider and data consumer applications
are not considered as OPES entities. The OPES architecture is
largely independent of the protocol that is used by the OPES entities
to exchange data. However, this document selects HTTP [4] as the
example protocol to be used for realizing a data flow. In this
regard, the logical implementation stack of an OPES entity is
summarized in Figure 1.
This last paragraph can be read to say that OPES protocols run over HTTP
and I don't think that's what is really meant. In the case of HTTP it may
be beneficial to point out that the OPES process would typically be
implemented in a proxy or surrogate (apologies if it causes problems in
using RFC 3040).
Also, in Figure 2 you make the use of a callout server a special case,
however the above paragraph is written in a way that implies there's a
network protocol going on between the dispatcher and the service
application (and if there's a network protocol going on between the
dispatcher and service application, why is there a need to mention a
callout server as a special case?).
Maybe:
"The OPES architecture is largely independent of the underlying protocol on
which OPES processors operate. However, this document selects HTTP [4] as
the example for the underlying protocol in OPES flows."
Barbir , et al. Expires December 18, 2002 [Page 4]
Internet-Draft OPES Architecture June 2002
---------------------------------------------------------------------
+-------------+
|OPES service |
| Application |
| |
+-------------+
| Data |
| Dispatcher |
| |
+-------------+
| |
| HTTP |
| |
+-------------+
| TCP/IP |
+-------------+
| ... |
+-------------+
Figure 1: OPES Logical Implementation
---------------------------------------------------------------------
Figure 1 depicts a "minimal" stack for OPES. However, other
protocols may be present, depending on the functions that are
performed by the application.
I think we've already had comments suggesting that the use of a "network
stack" diagram doesn't really work here. I personally feel that this
diagram is unnecessary - Figure 2 appears to convey the necessary
information in a better manner.
2.1.1 Data Dispatcher
Data dispatchers include a ruleset that can be compiled from several
sources and must resolve into an unambiguous result. The compiled
^^^^^^^^
ruleset enables an OPES processor to determine which service
applications to invoke for which data flow. Accordingly, the data
dispatcher constitutes an enhanced policy enforcement point, where
policy rules are evaluated, service-specific data handlers and state
information is maintained, as depicted in Figure 2.
Is it necessary to define that rulesets be compiled? (Sure this one's been
mentioned already too.) Perhaps you mean "combined"?
Barbir , et al. Expires December 18, 2002 [Page 5]
Internet-Draft OPES Architecture June 2002
---------------------------------------------------------------------
+----------+
| callout |
| server |
+----------+
||
||
||
||
+--------------------------+
| +----------+ || |
| | OPES | || |
| | service | || |
| | appl | || |
| +----------+ || |
| +----------------------+ |
OPES flow <---->| | data dispatcher and | |<----> OPES flow
| | policy enforcement | |
| +----------------------+ |
| OPES |
| processor |
+--------------------------+
Figure 2: Data Dispatchers
---------------------------------------------------------------------
The architecture allows more than one policy enforcement point to be
present on an OPES flow.
This diagram again gets me wondering about why there's a definition of an
OPES Entity in 2.1.
2.2 OPES Flows
An OPES flow is a cooperative undertaking between a data provider
application, a data consumer application, zero or more OPES service
applications, and zero or more data dispatchers.
E.g. in the trivial case an HTTP flow would be identical to an OPES flow
for the purposes of this document.
(The trivial case being zero "OPES entities" [I note you don't use the
definition in the one place where it would appear to be used ...])
In order to understand the trust relationships between OPES entities,
each is labeled as residing in an administrative domain. Entities
associated with a given OPES flow may reside in one or more
administrative domains.
For example, Figure 2 depicts a data flow (also known as an "OPES
^^^^^^^^
flow"), that spans two administrative domains.
Figure 3, surely?
Barbir , et al. Expires December 18, 2002 [Page 6]
Internet-Draft OPES Architecture June 2002
---------------------------------------------------------------------
consumer administrative domain provider administrative domain
+------------------------------+ +------------------------------+
| | | |
| data OPES | | OPES data |
| consumer processor | | processor provider |
| | | |
| +----------+ +--------+ | | +--------+ +----------+ |
| | data | | OPES | | | | OPES | | data | |
| | consumer | |service | | | |service | | provider | |
| | appl | | appl | | | | appl | | appl | |
| +----------+ +--------+ | | +--------+ +----------+ |
| | | | | | | | | | | |
| | HTTP | | HTTP | | | | HTTP | | HTTP | |
| | | | | | | | | | | |
| +----------+ +--------+ | | +--------+ +----------+ |
| | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | |
| +----------+ +--------+ | | +--------+ +----------+ |
| || || || | | || || || |
| ============= ================= ============= |
| | | |
+------------------------------+ +------------------------------+
| <----------------- OPES flow -----------------> |
Figure 3: An OPES flow
---------------------------------------------------------------------
Figure 3 depicts two data dispatchers that are present in the OPES
flow. However, the architecture allows for zero or more data
dispatchers to be present in any flow.
Since "consumer" and "provider" are each the same number of characters, and
since the rest of the diagram is identical, perhaps some kind of vertical
division between the two domains would make it a little more obvious as to
why half a page is being used for the diagram?
2.3 OPES Rules
OPES policy regarding services and the data provided to them is
determined by a ruleset consisting of OPES rules. The rules consist
of a set of conditions and related actions. The ruleset is the
superset of all OPES rules on the processor. The OPES ruleset
determines which service applications will operate on a data stream.
The communication of data stream elements to an application is
performed by data dispatchers. In this model, all data filters are
^^
typo
invoked for all data.
^^^^
Substite "flows" for data in the above?
In order to ensure predictable behavior the OPES architecture
^^
missing comma
Barbir , et al. Expires December 18, 2002 [Page 7]
Internet-Draft OPES Architecture June 2002
requires the use of a standardized schema for the purpose of defining
and interpreting the ruleset. The OPES architecture does not require
a mechanism for configuring a ruleset into a data dispatcher. This
is treated as a local matter for each implementation (e.g., through
the use of a text editor, secure upload protocol, and so on). Future
revisions of the architecture may introduce such a requirement.
2.4 Callout Servers
The evaluation of OPES ruleset determines which service applications
will operate on a data stream. How the ruleset is evaluated is not
the subject of the architecture, except to note that it must result
in the same unambiguous result in all implementations.
In some cases it may be useful for the OPES processor to distribute
the responsibility of service evaluation by communicating with one or
more callout servers (cf., [7]). The situation is illustrated in
^^
I don't think you mean "c.f." here, there's no comparison: "see"
Figure 4, which shows a data dispatcher communicating with multiple
callout servers as it processes an OPES flow.
Barbir , et al. Expires December 18, 2002 [Page 8]
Internet-Draft OPES Architecture June 2002
---------------------------------------------------------------------
data callout callout callout
dispatcher server server server
+----------+ +---------+ +---------+ +---------+
| | | | | | | |
| OCP | | OCP | | OCP | ... | OCP |
| | | | | | | |
+----------+ +---------+ +---------+ +---------+
| Lower | | Lower | | Lower | | Lower |
| Layer | | Layer | | Layer | | Layer |
|Protocols | |Protocols| |Protocols| |Protocols|
| . | | . | | . | | . |
| . | | . | | . | | . |
+----------+ +---------+ +---------+ +---------+
|| || || ||
||================ || ... ||
|| || ||
||============================== ||
|| ||
================================================
Figure 4: An OPES flow with Callout servers
I've commented on this diagram in earlier email. My preference would be to
remove it completely; Figure 5 does a far better job of showing what's
going on. (Figure 4 is only useful to suggest that there can be multiple
callout servers, and Figure 5 could surely be amended to suggest this with
the standard "deck" approach?)
[snip]
---------------------------------------------------------------------
+--------------------------+
| +----------+ |
| | OPES | |
| | service | | +----------------+
| | appl | | | Callout Server |
| +----------+ | | |
| || | | +--------+ |
| +----------------------+ | | | OPES | |
| | data dispatcher | | | | Service| |
| +----------------------+ | | | App2 | |
| | HTTP | OCP | | | +--------+ |
| +------------| |==========| OCP | |
| | |---------+ | | +--------+ |
| | TCP/IP | | +----------------+
=========| |=============== OPES Data Flow ====
| +------------+ |
+--------------------------+
Figure 5: Interaction of OPES Entities
The way that the HTTP and OCP boxes interface worries me here, since surely
the data has to pass through the dispatcher before it can be vectored
through OCP?
---------------------------------------------------------------------
2.5 Tracing Facility
The OPES architecture requires that each data dispatcher to provide
tracing facilities that allow the appropriate verification of its
operation. The OPES architecture requires that tracing be feasible
on the OPES flow per OPES processor using in-band annotation. One
of those annotations could be a URL with more detailed information on
^^^
URL? Or URI?
Note that neither the URI nor specifically a URL would actually give you
more information in their own rights.
the transformation that occurred to the data on the OPES flow.
Providing the ability for in-band annotation MAY require header
extensions on the application protocol that is used (e.g., HTTP).
However, the presence of an OPES processor in the data request/
response flow SHALL NOT interfere with the operations of non-OPES
aware clients and servers. OPES processors, content server and
content consumer MAY use OPES extensions to the base protocol (HTTP),
but support of these extensions SHALL NOT be required.
Doesn't this last part actually suggest that the OPES processors don't have
to understand the very extensions that you're saying may be required for
tracing/signalling? Am I missing something?
Use of RFC 2119-like words with no reference to 2119 in the document. Is
this intentional?
OPES processors must obey tracing, reporting and notification
requirements set by the center of authority in the trust domain to
Barbir , et al. Expires December 18, 2002 [Page 10]
Internet-Draft OPES Architecture June 2002
which OPES processor belongs. As part of these requirements OPES
processor may be instructed to reject or ignore such requirements
that originate from other trust domains.
Barbir , et al. Expires December 18, 2002 [Page 11]
Internet-Draft OPES Architecture June 2002
3. Security and Privacy Considerations
Each data flow must be secured in accordance with several policies.
The primary stakeholders are the data consumer and the data provider.
The secondary stakeholders are the entities to which they may have
delegated their trust. The other stakeholders are the owners of the
callout servers. Any of these parties may be participants in the
OPES architecture.
^^^^^^^^^^^^^^^^^
Is it possible for a party to be a participant in an architecture? It
doesn't read right to me. "OPES data transaction" or something like that
would appear to convey a better sense of what I think you're trying to say
here.
[Big snip]
3.2 Callout protocol
The determination of whether or not OPES processors will use the
measures that are described in the previous section during their
communication with callout servers depends on the details of how the
primary parties delegated trust to the OPES processors and the trust
relationship between the OPES processors and the callout server. If
the OPES processors are in a single administrative domain with strong
confidentiality guarantees, then encryption may be optional. In
other cases, encryption and strong authentication would be at least
strongly recommended.
In the case of a "closed" network I'm still not convinced that this group
should be suggesting it's OK to go without encryption; I wonder what folks
from the security area might say and whether this comment would get past
the IESG?
If the delegation mechanism names the trusted parties and their
privileges in some way that permits authentication, then the OPES
processors will be responsible for enforcing the policy and for using
authentication as part of that enforcement.
The callout servers must be aware of the policy governing the
communication path. They must not, for example, communicate
confidential information to auxiliary servers outside the trust
domain.
This is a requirement for the callout protocol which I don't see mentioned
in the requirements document for that protocol.
A separate security association must be used for each channel
established between an OPES processor and a callout server. The
channels must be separate for different primary parties.
3.3 Privacy
Some data from data consumers is considered "private" or "sensitive",
and OPES processors must both advise the primary parties of the their
privacy policy and respect the policies of the primary parties. The
privacy information must be conveyed on a per-flow basis.
The callout servers must also participate in handling of private
data, and they must be prepared to announce their own capabilities
and to enforce the policy required by the primary parties.
3.4 Establishing trust
The OPES processor will have configuration policy specifying what
privileges the callout servers have and how they are to be
identified. This is especially critical for third-party (fourth-
party, etc.) callout servers. OPES uses standard protocols for
^^^^^^^^^^^^^^^^^^
authenticating and otherwise security communication with callout
servers.
Do you mean "OPES will not define its own protocols for authentication and
securing communication with callout servers, rather it will use those
already available" ?
Barbir , et al. Expires December 18, 2002 [Page 13]
Internet-Draft OPES Architecture June 2002
An OPES processor will have a trusted method for receiving
configuration information such as rules for the data dispatcher,
trusted callout servers, primary parties that opt-in or opt-out of
individual services, etc.
3.5 End-to-end Integrity
Digital signature techniques can be used to mark data changes in such
a way that a third-party can verify that the changes are or are not
consistent with the originating party's policy. This requires an
inline manner of specifying policy and its binding to data, a trace
of changes and the party making the changes, and strong identities
and authentication methods.
Strong end-to-end integrity can fulfill some of the functions
required by "tracing".
This section seems important but has simply been tacked on the end, as if
to say "it can be done but we're not gonna think about it"
Barbir , et al. Expires December 18, 2002 [Page 14]
Internet-Draft OPES Architecture June 2002
4. Summary
Although the architecture supports a wide range of cooperative
transformation services, it has few requirements for
interoperability.
The necessary and sufficient elements are specified in the following
documents:
o the OPES ruleset schema [6] which defines the syntax and semantics
of the rules interpreted by a data dispatcher; and,
o the OPES callout protocol (OCP) [7] which defines the protocol
between a data dispatcher and a callout server.
[7] is a requirements document, not the definition of a protocol.