Subject: RE: Feedback on draft-ietf-opes-end-comm-03

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 6 Oct 2003 08:56:21 -0400

ALex,

Thanks

we will incporporate , sometime today.

At this stage, I highly recommend that the IAB draft be polished and be
ready for WGLC.

ps: if u need help in the ocp/http drafts (please ask)

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> 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>
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 6 Oct 2003 07:06:31 -0600 (MDT)

> At this stage, I highly recommend that the IAB draft be polished and be

I believe the IAB draft is in a relatively good shape. I would rather
wait for Sally's feedback or October 17th before making any serious
changes to avoid changing the same thing more than once. I will be
concentrating on OCP-related drafts for now.

Alex.