Subject: Request to publish :draft-ietf-opes-end-comm-03

From: "Abbie Barbir" <[email-masked]>
Date: Sat, 4 Oct 2003 10:14:17 -0400

Please publish the following 

draft-ietf-opes-end-comm-03

as a WG Draft.

Thanks
Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 5 Oct 2003 22:06:21 -0600 (MDT)

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

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