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

From: Alex Rousskov <[email-masked]>
Date: Thu, 25 Mar 2004 14:37:14 -0700 (MST)

According to IESG ID tracker, a revised version is needed for
draft-ietf-opes-iab-04. I do not think I have received any information
regarding this decision from the IESG. Could somebody (Chairs?) please
let me know:

	(a) is this the time to start revising the ID?
	(b) is there a list of problems that must be fixed?
	(c) once revised, does the ID go directly to IESG or
	    do we start the process from scratch?

As for (b), the ID Tracker gives access to "IN IESG DISCUSSION" items.
However, some of the IESG people raising questions in those items
later change their position from Discuss to No Objection. Can their
questions be ignored if, for example, it is not clear what they want
or addressing their (now removed?) objections may open new objections?
Will there be a concise/precise list of objections that must be
addressed? Or should we do our best to guess what needs to be changed
and resubmit?

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 25 Mar 2004 18:10:04 -0500

Alex,

it's on my to-do list, and I apologize for the delay in getting this 
started - too many things happened recently...

I'll try to send out a note to the list, which is overdue. But in 
general, yes, it's time to re-work the drafts based on IESG feedback. 
I also don't have much more than what's available in the ID tracker, 
though.

Thanks,
   Markus

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 25 Mar 2004 17:44:35 -0700

The main objection seemed to be the confusing example about
notifications, which seems to have little relevance to OPES protocol
issues.  The example calls for a note to be sent from a child ISP to a
parent company when a user reconfigures his preferences in such a way
as to subvert a policy of the parent company.  OPES is only indirectly
involved, if at all.  Is there a better example?

I'm not sure if the IESG comments about "one-party consent" are an
objection or not.  The architecture is clearly in compliance with
the IAB recommendation, and perhaps that could be stressed more.

The last paragraph of the one-party consent section is a little
confusing.  It calls copying an "adaptation" that cannot be detected.
I think that the issue is more simply described as content privacy.

Hilarie

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 30 Mar 2004 14:12:28 -0500

Folks,

as pointed out earlier, the IETF ID tracker shows that a revised
version of our IAB considerations document is needed. I don't have any
more information that what the IETF tracker at

   http://datatracker.ietf.org/

shows, so let's work from there.

[Ted - if you've any more information and/or advice on what exactly
we're expected to do, please let us know! Thanks.]

 From looking at the comments in the ID tracker, and as summarized by
Hilarie, it seems we need to address the following issues:

- We need to re-work the notification example given in Section 5.1,
   the comment we received is certainly valid and I'd suggest to use
   a different example. What about using an example in which the
   content provider receives notification that her content was rejected
   by an OPES virus scanning service? This would give the content
   provider the opportunity to verify its content, and if there's an
   error with the virus scanner, to inform the OPES service provider.
   This example also seems to be close to the one used in the original
   IAB document.

- Clarification is need on our Section 7 (URI adaption vs. URI
   resolution).

- Section 3 needs some clarification. I don't believe that there's a
   fundamental problem here, re-wording might do it.

- The security considerations section was considered "inadequate" by
   a reviewer and it was asked to add "pointers to sections that
   discuss [...] integrity and confidentiality". Can we do that?

Please also see Hilarie's comments (cited below).

Alex, Abbie - can you start working on an updated version that will 
address these issues and share it with the group? When do you think 
we'd be able to have such updated version?

Ted - please let us know if there's anything that would help us in 
making sure the updated version will pass IESG.

Thanks,
   Markus

The Purple Streak, Hilarie Orman wrote:

> notifications, which seems to have little relevance to OPES
> protocol issues.  The example calls for a note to be sent from a
> child ISP to a parent company when a user reconfigures his
> preferences in such a way as to subvert a policy of the parent
> company.  OPES is only indirectly involved, if at all.  Is there a
> better example?
> 
> confusing.  It calls copying an "adaptation" that cannot be
> detected. I think that the issue is more simply described as
> content privacy.
> 
> Hilarie
>

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Mar 2004 13:22:46 -0700 (MST)

Markus,

	I will start working on these issues and will post suggested
changes. I hope I can fix all of them except I am not quite sure about
the "inadequate security considerations section" comment. I can
address the latter by providing a list of Security Sections in the
other drafts, but doing so seems silly/redundant.

	The example you suggest may not be appropriate because
pro-actively notifying 3rd parties of viruses and such is becoming less
and less popular idea (there were some IETF drafts about that IIRC).

Thank you,

Alex.

P.S. I did not receive Hilarie's and another message for some reason.
     Found both in the list archive. Others may want to check that
     they did not miss any recent posts.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 30 Mar 2004 15:37:03 -0500

Alex,

> changes.

Excellent, thanks!!

 > I hope I can fix all of them except I am not quite sure about

My feeling is that this might be sufficient, since I believe the 
security considerations are already address elsewhere, we just need to 
point it out. If we can address the comment and thereby pass IESG 
review, we should do so.

> and less popular idea (there were some IETF drafts about that IIRC).

You're right, I remember previous comments along those lines. Any 
other suggestions, anyone?

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 31 Mar 2004 09:28:39 -0700 (MST)

On Tue, 30 Mar 2004, Markus Hofmann wrote:

>   a different example.

I suggest the following two examples as a replacement.

   The above concerns call for making notification optional. 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 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).
   Note that OPES services may not have enough information to contact
   the content producer directly in this case.

I have already updated the latest draft snapshot at
http://www.measurement-factory.com/tmp/opes/ with the above examples
(so that folks can review them in contex), but would be happy to
incorporate whatever example(s) the group decides on, of course.

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 31 Mar 2004 16:23:09 -0500

Alex,

both examples look good to me. Minor comment inline.

>    OPES entity). 

Although I believe to understand the intent of using the term "host" 
here, I'm wondering wether it might be easier to understand if we talk 
about a "server" in this example. I had to read the example twice to 
understand that the "host" you're talking about is a content source 
rather than the content consumer. But it might just be me :)

>    the content producer directly in this case.

The last sentecne could be explained a little more (e.g. what 
information might be missing etc.).

Thanks,
   Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 31 Mar 2004 15:10:14 -0700 (MST)

On Wed, 31 Mar 2004, Markus Hofmann wrote:

> >    an OPES callout server attached to a gateway or firewall may

Hmm... I meant the host inside a network. It could be a user PC, a web
server, or some other kind of a server/agent. In case of a user PC,
the PC is the content producer where content is whatever that infected
PC is sending outside of the network (malformed GET requests, port
probes, etc.). In case of a web server, the server is the content
producer where content is a web page with scripting bugs or other bad
things inside. In either case, the host is infected and is the content
producer.

Is that how you interpreted it? The "host" to "server" change would
eliminate an important case of an infected client PC. Any other
suggestions on how to polish the above?

> information might be missing etc.).

Will do.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 31 Mar 2004 22:24:53 -0500

> suggestions on how to polish the above?

Yup, that's the way I interpreted it. And, yes, the "host" to "server" 
change would eliminate the case of an infected client PC. However, 
since this is just an example for illustration, I felt that simplicity 
is more important than completness. But that's minor suggestion, I 
don't have a problem with the current phrasing.

-Markus