ietf-openproxy
[Top] [All Lists]

Feedback on draft-ietf-opes-end-comm-03

2003-10-05 21:06:32

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>

<Prev in Thread] Current Thread [Next in Thread>