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.