Subject: Re: WG Last Call: draft-ietf-opes-end-comm-05

From: Alex Rousskov <[email-masked]>
Date: Mon, 3 Nov 2003 16:53:25 -0700 (MST)

On Wed, 22 Oct 2003, Markus Hofmann wrote:

> We are starting WG last call on the "OPES entities and end points
> communication" draft (see attached). The last call period closes on
> Wednesday, November 5 at 5pm EST. Please post any comments, etc. to
> the mailing list, and please point out whether you feel your comment
> is editorial or a show-stopper.

My comments are below. Original text is quoted with ">". Discussion
and comments is surrounded by square [brackets]. Suggested text
replacements are indented and not quoted/surrounded.

Editorial/showstopper comments are prefixed with "E/S" tags followed
by the issue number for ease of reference. Note that I am not always
100% sure what is the difference between the two categories; there are
too many dependencies and uncertainties in some cases.

> Network Working Group                             A. Barbir

[S1: wrong working group?]

>  3.  Requirements for OPES Tracing  . . . . . . . . . . . . . . . .  5

[E1: given section titles for section 3.1-4, the above reads as if
 "OPES Tracing" is an OPES Entity. Also, the whole draft scope is OPES
 so we do not have to repeat it all the time. Suggested replacement:]

   3. Tracing Requirements   . . . . . . . . . . . . . . . .  5

>  4.  Requirements for OPES System Bypass (Non-blocking feature) . .  8

[E2: same as E1, plus it is not only the system that is being bypassed
 (in fact, I would argue that the system cannot be bypassed at all).
 Suggested replacement:]

   4.  Bypass Requirements . . . . . . . . . . . . . . . .  8

>  3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . .  5
>  4.1 What can be bypassed in an OPES Flow?  . . . . . . . . . . . .  8

[E3: The whole draft scope is OPES Flow. Please say it once
 in draft scope statement and drop "OPES Flow" from the rest of the
 text. Otherwise, the reader expects to see a "What is traceable
 outside of the OPES Flow?" Suggested replacements:]

    3.1 Traceable entities . . . . . . . . . . . . . .  5
    4.1 Bypassable entities . . . . . . . . . . . . . . 8

>  This work specifies the requirements for providing tracing
>  functionality for the OPES architecture [8].

[E4: simplify; something along these lines:]

   This work specifies OPES tracing functionality.

>  Tracing functionality enables a data provider or a data consumer
>  application to detect inappropriate actions that are performed by
>  OPES entities.

[S2: Tracing does not enable end points to *detect* inappropriate
actions]

>  The work also develops requirements that can be used to fulfill IAB
>  Notification and Bypass (Non-Blocking) requirements [2].

[E5: simplify and do not mention IAB as an excuse since you did not
 mention it when talking about tracing functionality requirements:]

   This work also specifies OPES bypass functionality.

>  The architecture document requires [8] that tracing 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 are also dependent on the choice of the application level
>  protocol.

>  For these reasons, this work documents requirements for application
>  protocols that need to support OPES traces and non-blocking
>  mechanism. The architecture does not prevent implementers of
>  developing out-of-band protocols and techniques to address these
>  limitation.

[E6: Merge the above two paragraphs]

>  this work documents requirements for application protocols that
>  need to support OPES traces and non-blocking mechanism.

[S28b: Where are the requirements for application protocols? I
 can only see requirements for OPES entities.]

>  The architecture does not prevent implementers of developing

[E8a: "... from developing" ?]

>  In this document the key words that are used to signify
>  requirements are based on RFC 2119 [3].

[S3: Quote the recommended text from RFC 2119]

[E7: Specify whether case is important for RFC 2119 keywords
     identification. See OCP Core for example if needed]

>  Definition: An OPES System is a set of all OPES entities [8]
>  authorized by either the data provider or the data consumer
>  application to process a given application message.

[E8b: Note that [8] does not define OPES processor as an OPES
 entity. [8] defines a "data dispatcher" as an OPES entity. Consider
 redefining entity explicitly and removing reference to [8] from the
 above.]

>  the CDN uses to adapt and deliver the message comprise an OPES

[E9: "and deliver the image" ?]

>  System. In a more complex example, an OPES System would contain CDN
>  entries

[E10: "would contain CDN entities" ?]

>  In an OPES System tracing is defined as the inclusion of necessary
>  information within a message in an OPES Flow that identify the
>  collection of transformations or adaptations that have been
>  performed on it before its delivery to an end point (for example,
>  the data consumer application).

[S4: The above definition is probably incorrect and is very awkward.
 It is incorrect because "inclusion of information" is not the only
 tracing activity. As we define below, exclusion or merging of trace
 entries is also a tracing activity. Also, it is not clear whether the
 "tracing" is the "inclusion" itself or the "process of inclusion" or,
 perhaps a "result of inclusion"?]

> an end point (for example, the data
>  consumer application).

[E11: Throughout the document: define "end point" once and avoid
 repeating "(for example, the data ... application)" every time
 the text says "end point". This just makes definitions and
 requirements longer.]

>  An OPES trace represents a snap shot of the
>  tracing information that have been added to a given application
>  message.

[S4b: Depending on the S4-related definition, this may need to be
  revised. Overall, it is still not clear what an OPES trace is!]

>  A trace represents the collections of transformations on an
>  application message in the order that were performed.

[S5: A collection of transformations or a collection of OPES
  entity IDs?]

[S6: The order the transformations were performed or the
  order of which entities got traversed? If two callout services are
  working on the same message in a pipeline mode, which one will be
  listed first? The one that got called first? The one that received
  the call first? The one that finished first?]

>  A traceable entity can appear multiple times in a trace (every time
>  it acts on a message).

[E12: insert "for example, " before "every time it acts". We allow
 for trace entries to be merged or to be missing.]

>  A data consumer application can use OPES trace to infer the actions
>  that have been performed by the OPES System. Actions are the set of
>  OPES services that were performed by OPES entities in an OPES
>  System.

[S7: A trace does not document actions, only service invocations]

>  o  Providers may be hesitant to reveal information about their
>     internal network infrastructure.

[E13: simplify:}

   o  Providers may hesitate to ...

>  o  Within a service provider network, OPES processors may be
>     configured to use non-routable, private IP addresses.

[E14: Why is this relevant here? We do not require IP addresses to
 be included in a trace, do we? We do not even encourage that, right?]

>  o  A data consumer applications would prefer to have a single point
>     of contact regarding the trace information.

[E15: "A data consumer application" not "applications" ]

>  In an OPES System some OPES services are message-agnostic and operate
>  on message content or parts of a message. Such services do not
>  manipulate message headers. Other services can manipulate message
>  headers.

[E16: What is the reason for including the above text. In other
words, "so what?". The text below does not seem to be related.]

> OPES providers require some freedom in the way they deliver
>  tracing information to an end point.

[E17: Not clear what "ways" you are referring to. In-band versus
 outband?]

>  Tracing information provides a data consumer application (or a data
>  provider application) with information about OPES entities that
>  adapted the data.

[E18: simplify:]

    A trace provides endpoint application with information about OPES
    entities that adapted the data.

>  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

[E19: missing quote after "end].

[S8a: IMO, a trace enables an endpoint to detect presence of an OPES
System. Detection of OPES processors is a SHOULD-dependent feature
not a MUST-dependent guarantee.]

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

[S8b: This sentence is a case in point for S8a above]

>  Since the administrators of various OPES Systems can have various
>  ways of looking into tracing, they require the choice of freedom in
>  what to put in trace records

[E20: can you rephrase "ways of looking into tracing" to clarify the
intent here?]

[E21: simplify: replace "choice of freedom" with "freedom"]

> and how to format them.

[S9: We do not provide formatting freedom for trace entries to
  "administrators", do we?]

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

[E22a: How is the above relevant to this section? Same for S9 text].

>  At the implementation level, for a given trace, an OPES entity
>  involved in handling the corresponding application message is
>  traceable or traced if information about it appears in that trace.

[S10: Please answer the Section Title question explicitly. What is
  traceable? Give a list of entities if that is the best way to
  answer that question. The above text is OK but it does not answer
  the question on trace-independent level. What can be traced?]

>  OPES entities have different levels of traceability requirements.
>  Specifically,

[S11: missing (misplaced?) an OPES System requirement:]

   o An OPES System MUST add its entry to the trace.

>  o  An OPES processor MUST add its entry to the trace.

[S12: I believe this should be a SHOULD, given the OPES System
MUST-level requirement above (S11), the fact that processor is not
clearly defined, the fact that there could be dozens of processors,
and that we (should) allow processor entries to be merged/deleted]

>  o  An OPES service MAY add its entry to the trace.

[E22b: How is the above relevant to this section?].

>  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).

[E22c: How is the above relevant to this section?].

>  It is the responsibility of the operator to resolve the problems.

[E23: add "to decode trace details and " before "to resolve"]

>  o  An OPES System MUST trace itself.

[S11b: See S11. Either all existing "MUST add its entry" MUSTs above
are misplaced and should go to its own section OR this MUST should not
be here and should be grouped with others.]

[E24: keep format similar to other MUSTs:]

   o An OPES System MUST add its entry to the trace.

>  o  An  OPES System MUST include information about its privacy policy.
>  o  An OPES System MUST identify the party responsible for setting and
>     enforcing that policy.

[E25: group in one:]

   o An OPES System MUST include information about its privacy policy,
     including identity of the party responsible for setting and
     enforcing the policy.

>  o  An OPES System MUST include information that identifies, to the
>     technical contact, the OPES  processors involved in processing the
>     message.

[S13: If processor tracing is a SHOULD, the above cannot be a MUST.
  See S12]

[E26: identifies all OPES processors involved? some OPES processors
  involved? How is this requirement related to "An OPES processor MUST
  add its entry to the trace."? Are they equivalent?]

>  This specification does not define the meaning of the terms privacy
>  policy, policy enforcement, or technical contact and	contains no
>  requirements regarding encoding, language, format, or any other
>  aspects of that information.

[E27: Paragraph ends here]

> Furthermore, an example of System
>  identification would be something like http://www.examplecompany.com/
>  opes/?client=example.com.

[E28: delete "furthermore" and be more specific:]

  For example, a URI used for an OPES System trace entry may look like
  "http://www.examplecompany.com/opes/?client=example.com" where the
  identified web page is dynamically generated and contains the
  all OPES System information required above.

>  o  OPES processor MUST add its unique identification to the trace.
>     Here, uniqueness scope is the OPES System containing the
>     processor.

[S12b: How is this related/different from a MUST referenced by S12
above? We should not have two overlapping (nearly identical) MUSTs.
See S12 regarding MUST versus SHOULD.]

[S14: "MUST add" for each invocation? once for all invocations?

>  o  OPES processor MUST be able to trace it's own invocation and
>     service(s) execution.

[S15: How does "trace it's own invocation" different from the previous
MUST? See S12b.]

[S16: What is a service execution? Is it different from service
invocation as this MUST seem to imply?]

[S17: Is "be able" a key here? Can it be removed without changing
 the requirement meaning? If not, what do you mean by "be able"?
 Can a processor be configured not to add these entries and be
 compliant in such a configuration?]

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

[E29: What exactly should be done under the control of the OPES System
provider? What does it mean to do something "under the control of the
OPES System provider"? Isn't everything on the provider side done
under provider's control?]

>  In addressing IAB consideration (3.3), one need to specify what
>  constitute non-OPES content.

[E30: "what constitutes" not "what constitute" ]

>  In this work the definition of "non-OPES" content is provider
>  dependent. However, in some cases, the availability of "non-OPES"
> ...

[E31: Replace "However, in some cases," with "For example, "  and edit
accordingly because what your case is just an example of a provider
dependency. If you disagree that it is an example/subcase, please
rephrase so that the difference between the two is clear.]

>  The above examples illustrates that the availability of non-OPES

[E32: There is only one example above, right?]

>  In an OPES System a bypass request is defined as the act of avoiding

[S18: A request to avoid is not an act of avoiding]

>  the invocation of a service(s) that is identified by a URI within a
>  message in an OPES Flow before its delivery to an end point (for
>  example, the data consumer application). The availability of non-OPES
>  content is a precondition to whether a bypass instruction is honored
>  or not in an OPES System.

[S19: Does bypass semantics mean "give OPES version if non-OPES is
 not available" or "give an error if non-OPES is not available"? This
 is very important to document clearly because it affects bypass
 design/rules a lot.]

>  In the general case, a bypass 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.

[S20: But we define bypass for OPES processors, not just services. Is
processor "an OPES entity that performs a service"? Most requirements
seem to apply that it is not possible to bypass a processor itself. Is
it?]

>  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 that are relevant to an OPES processor).

[S21: Does not wildcard identify all possible services and not only
services that are relevant (known?) to an OPES processor? If yes,
please delete the "i.e." part. If no, please define "relevant".]

>  In an OPES Flow, a bypass request is processed in a local manner by

[E33: remove "local manner"]

>  each involved OPES processor. This means that an OPES processor
>  examines the bypass instruction and if non-OPES content is available,
>  the processor then  bypasses services that are local to itself.

[E34: What does "local to itself" mean?]

>  This
>  may include the act of bypassing itself completely depending on what
>  is specified in the URI.

[S22: But processor is not a service so "may include" does not seem
 to apply to it because the above you say "bypasses services".]

[S23: We need to define what "bypassing self completely" means. I
 am not sure how anything can bypass itself completely.]

>  At the OPES system level, a bypass instruction is honored when at
>  least one OPES processor bypasses the services that are specified
>  by the URI that is specified in the instruction (provided that the
>  non-OPES content is available).

[S24: Does it mean that honoring a bypass of "*" it is sufficient
  to bypass one our of 100 services? If yes, I disagree that it is
  a good definition. If no, the above should be reworded.]

[S25: So, what can be bypassed? What does it mean to bypass X?
  Please also see S10 for a related concern. We are not answering
  our own questions.]

4.2 Bypass requirements for OPES System

>  In an OPES System bypass requests are generally client centric and go

[E35: what does "client centric" mean in this context? Originated by
  data consumer?]

>  Bypass can be performed out of band or in-band. This work requires
>  that the Bypass feature be performed in-band

[E36: The above two sentences contradict each other. If we require
  that bypass is in-band, it cannot be performed out-of-band by a
  compliant OPES implementation. Please rephrase.]

>  o  An OPES system MUST support a Bypass feature. This means that the
>     OPES System bypasses an entity whose URI is identified by an OPES
>     end (usually data consumer application).

[S26: When more than one URI is specified, does OPES System
need to bypass every entity, most entities, or just one entity? "*"
URI is a test case here.]

>  why they ignored the bypass instruction. It is important to note that
>  in some cases the tracing facility itself may be broken and the whole
>  OPES System (or part) may need to be bypassed through the issue of a
>  bypass instruction.

[E37: How is it possible to bypass the whole OPES System if only the
  OPES System is bypass-aware?]

>  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

[E38: It is not the mix that requires, it is the existence of
"services that operate on content"]

>  In some cases, the first OPES processor that will get the bypass
>  request may not be the first OPES processor that will know whether
>  a non-OPES version of the content is available or not.

[E39: what does that imply? That is, why mention it?]

>  Bypass requirements for OPES processors are (the availability of a
>  non-OPES content is a precondition):
...
>  Provided that non-OPES content is available,

[S27: What are the requirements if no non-OPES content is available?]

4.4 Bypass requirements for callout servers

>  This should be done under the control of the OPES System provider.

[E29b: Please see E29 for this comment]

>  This work specifies high level requirements for tracing and bypass.
>  Protocol binding specifications MUST consider and follow all MUSTs in
>  this draft.

[S28: There are no MUSTs for Protocol binding specifications in the
draft as far as I can see. We have MUSTs for OPES entities only.]

> Protocol binding specifications MUST be compliant to this
>  draft.

[S29: You cannot require that something is compliant. You can
 only define what it means to be compliant. See OCP Core for
 an example of a Compliance Considerations section.]

[S30: Do you intentionally exclude SHOULDs from compliance
  requirements? As of now, an implementation may violate every SHOULD
  and call itself compliant. We should discuss whether that's a
  good thing.]

>  document is a requirement document for tracing and Bypass feature.

[E40: "features"; also "Bypass" capitalization seems inconsistent
 with the rest of the draft]

>  There are risks for the OPES System by non-OPES entities, whereby,
>  these entities can insert bypass instructions into the OPES Flow. The
>  threat can come from compromised non-OPES entities. The threat might
>  affect the overall integrity and effectiveness of an OPES System. For
>  example, a non-OPES proxy can add bypass instruction to bypass
>  legitimate OPES entities. The attack might result in overwhelming the
>  original content provider servers, since the attack essentially
>  bypass any load balancing techniques. In addition, such an attack is
>  also equivalent to a DoS attack, whereby, a legitimate data consumer
>  application may not be able to access some content from a content
>  provider or its OPES version.

>  Since an OPES Flow may include non-OPES entities, it is susceptible
>  to man-in-the-middle attacks, whereby an intruder may inject bypass
>  instructions into the data path. These attacks may affect content
>  availability or disturb load balancing techniques in the network.

[E41: Is the second paragraph already covered in the first paragraph?]

>  The above threats can also arise by compromised OPES entities. An
>  intruder can compromise an OPES entities and then use
>  man-in-the-middle techniques to disturb content availability to a
>  data consumer application or overload a content provider server
>  (essentially, some form of a DoS attack).

>  Attackers can use the bypass instruction to affect the overall
>  integrity of the OPES System. The ability to introduce bypass
>  instructions into a data flow may effect the accounting of the OPES

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

[E42: Can a Scenarios document be normative? In what way?]

> Informative References

>  [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", RFC 2119, March  1997.

[E43a: This should be a normative reference]

>  [6]  Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft
>       http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt,
>       July 2003.

[E44a: Please update]

>  [8]  A. Barbir et al., "An Architecture for Open Pluggable Edge
>       Services (OPES)", Internet-Draft http://www.ietf.org/
>       internet-drafts/draft-ietf-opes-architecture-04, December  2002.

[E43b: This should be a normative reference]

>  [9]  A. Barbir et al., "OPES Treatment of IAB Considerations",
>       Internet-Draft http://www.ietf.org/internet-drafts/
>       draft-ietf-opes-iab-02.txt, September  2003.

[E44b: Please update]

[S31: Did I miss a place in the spec were we allow for manipulation
of trace entries such as merging or deleting callout service entries?
I remember we used to say that, but I do not see that text now.]

Thank you,

Alex.