-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Monday, October 06, 2003 12:06 AM
To: OPES WG
Subject: Feedback on draft-ietf-opes-end-comm-03
Abbie,
Here are my comments about version 03 of the
Communications draft you submitted for publication this
weekend. Your original text is ">" quoted. My comments are in
square [brackets]. Suggested replacement text is not.
Thank you,
Alex.
OPES processor and end points communications
draft-ietf-opes-end-comm-03
[Since the draft also contains requirements for callout
services and OPES systems, it would be more appropriate to title it]
OPES entities and end points communication
[No change in filename is required.]
This work specify the requirements for providing tracing
functionality
for the OPES architecture [8].
... specifies ... (?)
Tracing functionality
enables a data provider application to detect inappropriate actions
that are performed by OPES entities.
... enables a data provider or consumer application to ...
[Also, tracing cannot be used to detect actions, it can only
be used to detect intermediaries]
The architecture document requires [8] that tracing be supported
... is supported (?)
in-band. This design goal limits the type of application protocols
that OPES can support. The details of what a trace record
can convey
is also dependent on the choice of the application level protocol
... are also dependent (?)
For these reasons, this work documents requirements for application
protocols that need to support OPES traces and non-blocking.
[Non-blocking is not a noun, right? If you insist on using
that expression as a noun, I would suggest to always append
"feature" or "mechanism" to make the sentences appear more
grammatically correct. Note that IAB RFC never uses
non-blocking as a noun. In fact, IAB never uses "blocking"
in any sentence! The non-word is only used as a label. This,
and other reasons I have already mentioned, make me feel
that we should not be using this non-word for anything other
than referring to IAB consideration by label. If you
disagree, let's at least make the sentences grammatically
correct. If non-blocking is indeed a perfectly valid noun,
please ignore my grammar-related comments (with apologies).]
However,
the architecture does not prevent implementers of developing
out-of-band protocols and techniques to address these limitation.
Definition: An OPES System is a set of all OPES entities
authorized by
either the data provider or the data consumer application
to process a
given application message.
The nature of the authorization agreement determines if authority
delegation is transitive (meaning an authorized entities is
... an authorized entity is
The above definition implies that there can be no more than
one OPES
system processing a single message at a given time.
... no more than two OPES systems (?)
[Client-side and server-side OPES systems can process the
same message at the same time]
... processing the same message at a given time.
or
... processing the given message at a given time.
For example, consider a Content Delivery Network (CDN)
delivering an
image on behalf of a busy web site. OPES processors and
services that
the CDN uses to adapt and deliver the message comprise an
OPES system.
In a more complex example, an OPES System would contain CDN
[Please capitalize System in "OPES System" consistently
throughout the text]
In an OPES System tracing is performed on per message basis. Trace
format is dependent on the application protocol that is
being adapted
by OPES. A Data consumer application can use OPES trace to infer the
A data ...
actions that have been performed by the OPES system.
Actions are the
set of authorized OPES services that were performed by OPES
entities
in an OPES System.
... set of OPES services that ...
[The trace is no guarantee or even an indication of authorization ]
Providing tracing information, MUST take into account the following
considerations:
[Missing compliance subject/noun]
o Providers may be hesitant to reveal information about their
internal network infrastructure.
o Within a service provider network, OPES processors may be
configured to use non-routable, private IP addresses.
o A Data consumer applications would prefer to have a single point
of contact regarding the trace information.
[It is not clear to a reader what tracing properties these
considerations affect. In other words, how to take them into
account? Looks like some context is missing here]
3.1 What is traceable in an OPES Flow?
This section focuses on identifying traceable entities in an OPES
Flow.
Tracing information provides a data consumer application (or a data
provider application) with useful information without tracing the
... with information ...
exact OPES Processor or callout servers that adapted the data.
[But often exact OPES Processor or callout servers are
traced! Missing "for example" or "may" somewhere above?]
For
example, some OPES services are message-agnostic and operate on
message content or parts of a message. Such services cannot
manipulate
message headers. Hence, a data consumer application would be
interested in knowing that a translation service on the message
content was performed.
[The first ("for example") and the second ("hence") sentences
seem unrelated to me. Why "hence"?]
It does not need to know the exact entity that
has performed the service.
[Unless it wants to bypass that exact entity?]
[Overall, it is not clear what all the text above from
"without tracing" to "has performed the service" is trying to
accomplish]
There are two distinct uses of OPES traces. First, a trace
enables an
"end (content provider or consumer) to detect the presence of OPES
processors within an OPES System. Such "end" should be able
to see a
trace entry, but does not need to be able to interpret it beyond
identification of the OPES System.
Second, the OPES System administrator is expected to be able to
interpret the contents of an OPES trace. The trace can be
provided by
an end (data consumer or provider) as an opaque string.
... can be relayed to the administrator by an end (data consumer or
provider) without interpretation, as opaque data (e.g., a TCP
packet or an HTTP message snapshot).
Since the administrators of various OPES Systems can have
various ways
of looking into tracing, they MAY require the choice of freedom in
what to put in trace records and how to format them.
... they require freedom in ...
[this should not be a compliance requirement because we are
not in business of certifying administrators; so no MAY]
Trace records
should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque
data to the
extent possible.
[Are these shoulds SHOULDs? Rephrase or capitalize them.]
[Also, the second should is out of scope in this section The
first one may be out of scope as well unless "extensibility"
means adding info on new entities that can be traced"].
At the implementation level, for a given trace, an OPES entity
For a given trace, ...
involved in handling the corresponding application message is
traceable or traced if information about it appears in that trace.
OPES entities have different levels of traceability requirements.
Specifically,
[Is OPES system an OPES entity? Please define OPES entity
somewhere. You can say, for example, that OPES entity is
OPES processor or callout server, and that we also treat OPES
system as OPES entity where that does not lead to conflicts
(e.g., we do not do that when we define an OPES System).]
o An OPES system MUST add its entry to the trace.
o An OPES processor SHOULD add its entry to the trace.
o An OPES service May add its entry to the trace.
... MAY ...
[Why are the above three rules here? Don't they belong to
corresponding "Requirements for XXX" sections?]
o An OPES entity MAY manage trace information from
entities that are
under its control. For example, an OPES processor may add or
remove callout service entries in order to manage the size of a
trace.
[Since OPES System is not something that can "add entries" on
its own, how about adding something like:
o An OPES entity MAY delegate addition of its trace entry to
another OPES entity. For example, an OPES System can have
a dedicated OPES processor for adding System entries; an
OPES processor can use a callout service to manage all
OPES trace manipulations (since such manipulations are
OPES adaptations).
]
[We also must address the ordering here. Are trace entries ordered?]
[We also must specify whether a trace is a set or collection:
if an OPES processor is involved twice on the message path,
should it trace itself twice?]
From an OPES context, a good tracing approach is similar to
a trouble
In an OPES context, ... (?)
3.2 Requirements for Information Related to Traceable Entities
3.2 Information required in a trace
The following MUST requirements apply for information as related to
entities that are traceable in an OPES flow:
[Delete the above sentence. It is too awkward and complex]
o Identification of the OPES System privacy policy at the time it
dealt with the message.
OPES System MUST include information about its privacy policy.
[Note that we would need to say how that information can be
included without making the trace too large. For example, we
can say that it is sufficient to provide a URL to the OPES
System web page that has links to privacy and other policies.]
o Identification of the party responsible for setting and enforcing
that policy.
[Same note as above]
o Information pointing to a technical contact.
[Same note as above]
o Information that identifies, to the technical contact, the OPES
processors involved in processing the message.
OPES processors MUST include their identification.
[Now, if you look at the above, this section is really a
"Requirements for OPES Systems" section, with the exception
of the last MUST that belong to the "Requirements for OPES
processors" below! I would rename/move/rephrase accordingly.]
3.3 Requirements for OPES processors
The requirements for OPES processors that are applicable to tracing
are:
Tracing requirements for OPES processors are:
o Each OPES processor MUST be uniquely identified in an
OPES System.
[Remove the above. Since processor tracing is a SHOULD, there
is no reason to have a MUST concerning processor IDs]
o Each OPES processor MUST support tracing, policy can be used to
turn tracing on and to determine its granularity.
[Remove the above. It makes not practical sense. If a
particular policy says "turn tracing off", and a particular
processor implementation is based exclusively on that policy,
that implementation should not be forced to "support"
tracing. Processor tracing is a SHOULD.]
o If tracing is turned on, then the OPES processor MUST add its
identification to the trace.
OPES processor SHOULD add its unique identification to the
trace. Here, uniqueness scope is the OPES System containing
the processor.
[Another trouble to address: What if a client-side OPES
System and a server-side OPES System share a processor? For
example, a server is translating from British English to
American based on client IP address and a client (a Briton
temporary in the US) is translating back to British English,
using the same well-known OPES processor (but under a
different contract, of course). We should make sure that OPES
processor includes two unique IDs in this scenario so it
would be clear that two translations were made and so that
one can be bypassed if buggy. I am not sure the above rules
address this kind of sharing.]
o OPES processor SHOULD be able to trace it's own invocation and
service(s) execution since it understands the application
protocol.
[How is that different from the above rule? Do you mean to
add a rule that requires processor to trace its services?]
To fulfill this:
[Fulfill what?]
* An OPES processor MAY have a fixed configuration that
enable it
to respond to tracing inquires. For example, entity X performs
service Y and so on.
[It is unclear to me what this rule is trying to accomplish.
Of course, processor can have fixed configurations. Why are
we suddenly talking about "tracing inquires"??]
* An OPES processor MAY package tracing information related to
the entities that it control based on the policy of a given
OPES System. For example, the trace may state that service W
was performed. The OPES processor knows that service W is
composed of services X, Y and Z in a given order
[Isn't that already covered in "An OPES entity MAY manage
trace information" rule?]
o An OPES processor SHOULD add to the trace identification of every
callout service that processed the application message.
[What if the service identified itself already?]
o An OPES processor MAY delegate trace management to a callout
service within the same OPES System.
[That should be covered by "An OPES entity MAY manage trace
information" rule in the revised version above]
3.4 Requirements for callout servers
In an OPES system, it is the task of an OPES processor to add trace
records to application messages. However, in some cases, callout
servers May add trace information to application messages.
This should
be done under the control of the OPES System provider.
[Isn't everything in an OPES System done under the control of
the OPES System provider?]
3.5 Protocol Binding
[Should this section follow the Non-blocking section and be
not so tracing-specific? Bindings are equally needed for
tracing and bypass features...]
The task of adding tracing information is application protocol
specific.
The task of encoding tracing information is ...
Separate documents will address HTTP and other protocols.
This work documents what tracing information is required and some
common tracing elements.
[Remove the above sentence because it is both quite imprecise
and unnecessary here?]
4. Non-Blocking
[I find it strange that the layout of this section is not the
same as the layout of the Tracing section. We seem to be
talking about very similar things in both sections, but the
Tracing section is much better organized.]
In [9] recommendation addresses the issue of non-blocking
in an OPES
System. The recommendation is restated below for ease of reference.
(3.3) Non-blocking: If there exists a non-OPES version of content
available from the content provider, the OPES architecture must
not prevent users from retrieving this non-OPES version from the
content provider.
The IAB recommendation implies that it is up to the content
provider
to make non-OPES versions of a given content available.
[IAB consideration is not (should not be) the motivation or
reason to support bypass. Let's leave addressing of IAB
considerations to the IAB Treatment draft. We can simply
state that bypass is necessary to prevent [malfunctioning]
intermediaries from blocking the way to non-OPES content.]
The actual
meaning of non-OPES version of the content depended on the
agreement
between the OPES provider and the content provider. The
agreement can
allow OPES to perform some services (such as logging services) and
prevent it from performing other services (such as data to audio
transformation).
[Two things seem to be mixed here: It is not clear whether
the above paragraph explains that data provider can prohibit
certain services OR whether the above paragraph asserts that
definition of "non-OPES" is provider-dependent and may
include content adapted by OPES.]
Whether an OPES System honor a non-blocking request from a data
consumer application (user) can also be a function of deployment.
Consider the case where Company A has as contract with an OPES
provider to perform virus checking on all e-mail attachments. An
employee X of Company A can issue a non-blocking request
for the virus
scanning service. However, the request could be ignored by the OPES
provider since it contradicts its agreement with Company A.
[Can we say that the above example is an example of "no
non-OPES content available" (and, hence, the above OPES
System does not violate any OPES rules)? Or are you implying
that the OPES System above is violating OPES rules by
ignoring user bypass request?]
As
a second example, a user may issue a non-blocking request for adult
content, this request may be declined by the OPES provider simply
because it contradicts its internal policy or its agreement
with the
end subscriber.
[Same concerns as above: what are we trying to illustrate here?]
Like tracing, Non-blocking operates on per application
message bases.
Non-Blocking is an end-end operation as opposed to a hop-by-hop
operation. Non-blocking requests are generally client
centric and go
in the opposite direction of tracing requests. Non-blocking can be
performed out of band or in-band. This work requires
non-blocking to
be performed in-band as an extension to an application specific
protocol.
Non-OPES entities should be able to safely ignore the
extensions. The
work does not prevent OPES Systems from developing their own out of
band protocols.
Non-blocking format is dependent on the application
protocol that is
being adapted by OPES. For a given application protocol, in an OPES
System there can be services that operate on application message
headers and those that just operate on content. This mix of service
requires that an OPES processor that is calling the service(s) to
handle the non-blocking request. In some cases, the first OPES
processor that will get the non-blocking request may not be
the first
OPES processor that will know whether a non-OPES version of the
content is available or not.
In an OPES System, the OPES provider is expected to
configure at least
one OPES processor to process a non-blocking header based
on content
availability and related policies. In this case the OPES
processor is
expected to determine the set of services that will be bypassed (or
those services that will be performed) or whether the
request should
be forwarded directly to the data provider application
(origin content
provider).
[All of the above is a non-normative (informative) text
(i.e., it contains no requirements or definitions), right? If
something above is normative, please use appropriate keywords
(MUST/SHOULD/MAY).]
Although, IAB recommendation (3.3) has intended for non-blocking
approach to be used as a vehicle to bypass faulty OPES
intermediaries.
IAB recommendation (3.3) uses non-blocking requests as a
vehicle to bypass faulty OPES intermediaries.
However, this work recognizes that the same technique
can be used to enable a data consumer application to select
the set of
services that it would like to be bypassed for a given application
message.
[I do not see a clear difference between the above two
sentences. If you are implying that our bypass feature is
designed to select a subset of useful services, than I
disagree. Bypass feature is designed specifically to bypass
faulty/malfunctioning/corrupted services. While it can be
used for other purposes, any such use would be out of scope here]
For this reason, a non-blocking request is viewed as a
bypass instruction that contains a URI that identifies an
OPES entity
or a group of OPES entities that perform a service (or
services) to be
bypassed.
... identifies an OPES entity or a group of OPES entities to
be bypassed.
An instruction may contain more than one such URI. A
special wildcard identifier can be used to represent all
possible URIs
(i.e., all possible OPES services).
This version of the work
requires that all non-blocking instructions to use the wildcard
approach.
["version of the work"?? If we require that all instructions
use wildcards, then why are we documenting URIs? Any URI use
would be a violation of this spec!]
For example, an application level protocol (such as HTTP) can be
extended to include the following OPES non-blocking related header:
OPES-Bypass: *
For example, HTTP can be extended to ...
The following requirements apply for non-blocking feature:
o An OPES System MUST support the non-blocking feature for requests
of non-OPES content for a given application message.
[What does it mean to "support" a non-blocking feature? Does
it mean to bypass? Does it mean to bypass unless no non-OPES
content exists? Something else?]
o An OPES System MUST treat the non-blocking feature as an
end-to-end operation.
[Do the above two requirements apply to OPES entities or just
the System as a whole?]
* This means that there MUST be at least one OPES
processor in an
OPES System that knows how to interpret and process the
non-blocking feature.
[If this is implied (i.e., there is no way around it), why
another MUST? Also, what is the compliance subject of this MUST?]
* The recipient MUST forward the bypass instructions to the next
application hop provided that the next hop speaks application
protocol with OPES bypass support.
[Again, if this is an explanation of the above MUST, then
this text should not be normative]
End users may not be able to know if their non-blocking request was
honored or not by the OPES System. In this case, it would be
beneficial if tracing can provide additional information regarding
whether a non-blocking request was honored or not. For this reason,
the following requirement also apply to the tracing facility:
o An OPES System SHOULD assist the data consumer application in
determining if a non-blocking request was performed by
the system.
Assistance is viewed as the addition of information about services
that were skipped and those that could not be bypassed.
[But what if it is the OPES tracing facility that is broken
and needs to be bypassed? In other words, should not bypass
apply to tracing adaptations as well? We could recommend that
non-bypassed entities include information why/that they
ignored the bypass instruction, but we should not recommend
that bypassed entities were traced.]
5. IANA considerations
This work does not require any IANA consideration since any actions
will be addressed in [6].
[ but [6] only addresses HTTP-specific IANA considerations.
How about:]
This specification contains no IANA considerations.
Application bindings MAY contain application-specific IANA
considerations.
6. Security Considerations
The security considerations for OPES are documented in [7]. This
document is a requirement document for tracing and
non-blocking and as
such does not develop any new protocols that require security
considerations.
[I strongly disagree. We certainly specify a high-level
tracing and bypass protocol here. There are security
considerations to document. For example, an OPES
intermediary can add so many trace entries that another OPES
intermediary will be overwhelmed (DoS attack or worse).
Another example is fake trace entries. What bad things can
be done by faking a trace? Finally, can bypass be used for
DoS attacks because bypassed path is not optimized (e.g.,
bypassing CDN may overwhelm the server). Etc. etc.]
Normative References
[1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-scenarios-01.txt, August 2002.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft
http://www.ietf.org/internet-drafts/
draft-ietf-opes-ocp-core-01.txt, August 2003.
[6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
September 2003.
[7] A. Barbir et al., "Security Threats and Risks for Open
Pluggable
Edge Services", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-threats-02.txt, February 2003.
[9] A. Barbir et al., "OPES Treatment of IAB Considerations",
Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-iab-01.txt, February 2004.
[In what way are the above reference normative? They seem to
contain no normative text at all (e.g., [9]) or contain no
normative text cited in this Tracing document.]
Informative References
[10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC
3198, November 2001.
[11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", W3C Recommendation 16 http://
www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002.
[I could not find any references from the draft text to the above two]
<eof>