Hi,
Below are the change log entries followed by the corresponding
text that is meant address all IESG DISCUSS items we know about. The
notification example has been adjusted based on Markus feedback, to
clarify the meaning of a "host". One-party consent text used "content
privacy" terminology suggested by Hilarie to clarify the intent.
Please review soon and I will publish the polished version to
be resubmitted for IESG review. If you need more context, the entire
updated draft is available at
http://www.measurement-factory.com/tmp/opes/
Thank you,
Alex.
=====>* Replaced "Cable Company ISP" Notification example with two new
examples to address IESG uncertainty about the meaning of the
old convoluted example.
The OPES
architecture allows for an efficient and meaningful notification
protocol to be implemented in certain OPES environments. For
example, an OPES callout server attached to a gateway or firewall may
scan outgoing traffic for signs of worm or virus activity and notify
a local Intrusion Detection System (IDS) of potentially compromised
hosts (e.g., servers or client PCs) inside the network. Such
notifications may use OPES tracing information to pinpoint the
infected host (which could be another OPES entity). In this example,
notifications are essentially sent back to the content producer (the
local network) and use OPES tracing to supply details.
Another environment where efficient and meaningful notification using
OPES tracing is possible are Content Delivery Networks (CDNs). A CDN
node may use multiple content adaptation services to customize
generic content supplied by the content producer (a web site). For
example, the node may insert advertisements for client-local events
or services. The node itself may not understand specifics of the ad
insertion algorithm implemented in OPES callout servers. However, it
may use OPES trace to notify content producer about the number of
certain advertisements inserted (i.e., the number of "impressions"
delivered to the customer) or even the number of ad "clicks" the
customer made (e.g., if the node hosts content linked from the ads).
OPES services doing ad insertion may lack details (e.g., a customer
ID/address or a web server authentication token) to contact the
content producer directly in this case.
=====>* Polished text addressing "One-party consent" concern to better
show why the concern is addressed. It is not clear whether the
changes will address IESG review comment that "the WG does not
seem to get it" [because?] the text does not "name situations
where one-party consent does make sense". It is currently not
clear how naming such situations can address IAB concern, and
why naming such situations is in this document scope.
3. Consideration (2.1) 'One-party consent'
"An OPES framework standardized in the IETF must require that the use
of any OPES service be explicitly authorized by one of the
application-layer end-hosts (that is, either the content provider or
the client)."[RFC3238]
OPES architecture requires that "OPES processors MUST be consented to
by either the data consumer or data provider application"
[I-D.ietf-opes-architecture]. While this requirement directly
satisfies IAB concern, no requirement alone can prevent consent-less
introduction of OPES processors. In other words, OPES framework
requires one-party consent but cannot guarantee it in the presence of
incompliant OPES entities.
In [I-D.ietf-opes-end-comm], the OPES architecture enables concerned
parties to detect unwanted OPES processors by examining OPES traces.
While the use of traces in OPES is mandatory, a tracing mechanism on
its own cannot detect processors that are in violation of OPES
specifications. Examples include OPES processors operating in
stealth mode. However, the OPES architecture allows the use of
content signature to verify the authenticity of performed
adaptations. Content signatures is a strong but expensive mechanism
that can detect any modifications of signed content provided that the
content provider is willing to sign the data and that the client is
willing to either check the signature or relay received content to
the content provider for signature verification.
OPES entities may copy or otherwise access content without modifying
it. Such access cannot be detected using content signatures. Thus,
"passive" OPES entities can operate on signed content without the
data consumer or provider consent. If content privacy is a concern,
then content encryption can be used. A passive processor is no
different from any intermediary operating outside of OPES framework.
No OPES mechanism (existing or foreseeable) can prevent non-modifying
access to content.
In summary, the one-party consent is satisfied by including the
corresponding requirement in the IAB architecture document. That
requirement alone cannot stop incompliant OPES entities to perform
consent-less adaptations, but OPES framework allows for various means
of detecting and/or preventing such adaptations. These means
typically introduce overheads and require some level of
producer-consumer cooperation.
=====>* Polished text discussing URI resolution consideration to talk
more specifically about the resolution of URIs rather than
(more general) adaptation of URIs and added examples. This
change is meant to address IESG concern that URI resolution is
not addressed or the corresponding description is confusing.
7. Consideration (4.1) 'URI resolution'
"OPES documentation must be clear in describing these services as
being applied to the result of URI resolution, not as URI resolution
itself."[RFC3238]
"OPES Scenarios and Use Cases" specification
[I-D.ietf-opes-scenarios] documents content adaptations that are in
scope of the OPES framework. Scenarios include content adaptation of
requests and responses. These documented adaptations do not include
URI resolution. In some environments, it is technically possible to
use documented OPES mechanisms to resolve URIs (and other kinds of
identifiers or addresses). The OPES framework cannot effectively
prevent any specific kind of adaptation.
For example, a CDN node may substitute domain names in URLs with
CDN-chosen IP addresses, essentially performing a URI resolution on
behalf of the content producer (i.e., the web site owner). An OPES
callout service running on a user PC may rewrite all HTML-embedded
advertisement URLs to point to a user-specified local image,
essentially performing a URI redirection on behalf of the content
consumer (i.e., the end user). Such URI manipulations are outside of
the OPES framework scope, but cannot be effectively eliminated from
the real world.
=====>* Clarified in the Introduction that the purpose of this document
is to address nine formal IAB considerations, and that we hope
that addressing formal consideration is sufficient to address
any informal ones that are scattered through the IAB
Considerations document. This is meant to address IESG concern
that some [informal] words from the IAB Consideration document
do not explicitly appear in this document.
The primary goal of this document is to show that all formal IAB
recommendations are addressed by OPES, to the extent that those
considerations can be addressed by an IETF working group. The
limitations of OPES working group to address certain aspects of IAB
considerations are also explicitly documented.
IAB considerations document [RFC3238] contains many informal
recommendations. For example, while the IAB informally requires OPES
architecture to "protect end-to-end data integrity by supporting
end-host detection and response to inappropriate behavior by OPES
intermediaries", the IAB has chosen to formalize these requirements
via a set of more specific recommendations, such as Notification
considerations addressed in Section 5.3 and Section 5.4 below. OPES
framework addresses informal IAB recommendations by addressing
corresponding formal considerations.
=====>* Be more specific about where security of OPES mechanisms is
discussed. Added an example of where security of OPES tracing
mechanisms is discussed. This document is about addressing
specific IAB considerations and is not a map/index to OPES
mechanisms or their security. However, polished text and
example may provide the reader with more direct clues on where
to find security-related information that goes beyond the scope
of this document.
12. Security Considerations
This document does not define any mechanisms that may be subject to
security considerations. This document scope is to address specific
IAB considerations. Security of OPES mechanisms are discussed in
Security Considerations sections of the corresponding OPES framework
documents.
For example, OPES tracing mechanisms assist content providers and
consumers in protecting content integrity and confidentiality by
requiring OPES intermediaries to disclose their presence. Security of
the tracing mechanism is discussed in the Security Considerations
section of [I-D.ietf-opes-end-comm].
The End.