Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04?

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 Apr 2004 20:37:04 -0600 (MDT)

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.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 09 Apr 2004 11:53:39 -0400

Alex Rousskov wrote:

> be resubmitted for IESG review. 

Looks good to me. At the end of the day, please go ahead ab request 
publication of the updated draft. I'll then notify ted that this draft 
has been modified to address the IESG comments.

>    content producer directly in this case.

Just for clarification - this example implies that an OPES processor 
could use trace information to determine where to send notifications 
to. The destination of such notifications could be either the content 
producer or another (upstream) OPES processor. In the former case, 
there would be an OPES trace entry for the content producer?

Thanks,
   Makrus

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 12 Apr 2004 10:16:08 -0600 (MDT)

On Fri, 9 Apr 2004, Markus Hofmann wrote:

> publication of the updated draft. I'll then notify ted that this
> draft has been modified to address the IESG comments.

I submitted the iab-05 draft for publication today.

> to.

More like what to include in those notifications, I think. I inserted
a few adjectives and explicitly defined a few "it" and "that" to
clarify:

   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, a callout service may insert advertisements for client-local
   events.  The CDN node itself may not understand specifics of the ad
   insertion algorithm implemented at callout servers.  However, the
   node may use information in the OPES trace (e.g., coming from the
   callout service) to notify the content producer. Such notifications
   may be 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).  Callout 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. Thus,
   OPES trace produced by an OPES service becomes essential in enabling
   meaningful notifications that the CDN node sends to the content
   producer.

I hope the above polished text conveys the same meaning better. If it
is not good enough, please suggest specific changes or we can delete
the entire example.

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 12 Apr 2004 13:55:36 -0400

Alex,

> I submitted the iab-05 draft for publication today.

Thanks!

> I hope the above polished text conveys the same meaning better. If
> it is not good enough, please suggest specific changes or we can
> delete the entire example.

Fine with me.

Thanks,
   Markus