Subject: OCP and IAB considerations

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 15:49:27 -0600 (MDT)

The next OCP release should have an IAB Considerations section. That
section is supposed to describe what IAB Considerations are relevant
to OCP and how OCP addresses those that are relevant. I propose the
following wording (inspired by Abbie Barbir's private contribution)
and am seeking early feedback.

   9. IAB Considerations

   OPES callout protocol is an internal and optional OPES feature.  No
   Internet Architecture Board (IAB) considerations [RFC3238] are
   relevant to OCP.

   For example, IAB consideration (5.1) Privacy says: "The overall OPES
   framework must provide for mechanisms for end users to determine the
   privacy policies of OPES intermediaries." The only OPES intermediary
   known to OCP is an OPES processor, an OCP client. While OCP does deal
   with privacy issues (see Section XXX Security Considerations), OCP
   itself has no effect on privacy policies of OPES processors. OCP is
   not designed for communication with end users. While OPES processors
   are expected to reflect OCP privacy-specific concerns (e.g.,
   encryption of OCP communications) in their privacy policies, OCP
   itself is not relevant to this IAB Privacy consideration.

Does anybody disagree with the conclusion that no IAB considerations
apply directly to OCP? Should we provide more examples of
considerations that do NOT apply?

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 20 May 2003 18:33:12 -0400

>    Internet Architecture Board (IAB) considerations [RFC3238] are

Just stating that the IAB consideration are not relevant to OCP might 
not be appropriate. Past experience has shown that it's helpful and 
worthwhile to explicitly address each of the IAB considerations, and 
explain how OCP addresses each specific consideration, or why it's not 
applicable to OCP. In the latter case, it would be helpful to indicate 
which piece in OPES takes care of the specific consideration and add a 
reference. For example, it might not be obvious why tracing/bypass 
doesn't impact OCP at all - a short explanation and reference might help.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 17:14:11 -0600 (MDT)

On Tue, 20 May 2003, Markus Hofmann wrote:

> >    For example, ...
> Just stating that the IAB consideration are not relevant to OCP
> might not be appropriate. Past experience has shown that it's
> helpful and worthwhile to explicitly address each of the IAB
> considerations, and explain how OCP addresses each specific
> consideration, or why it's not applicable to OCP. In the latter
> case, it would be helpful to indicate which piece in OPES takes care
> of the specific consideration and add a reference. For example, it
> might not be obvious why tracing/bypass doesn't impact OCP at all -
> a short explanation and reference might help.

The proposed wording gives an example for one IAB consideration (5.1
Privacy).  You are arguing that there needs to be one statement for
each IAB consideration (9 of them). This approach will result in lots
of repeated text in every OPES document that has an "IAB
Considerations" section.

Perhaps we should have a single document dedicated to IAB
considerations then? That document will have one entry per
consideration, with pointers to other relevant documents such as
architecture, OCP, tracing, and bypass drafts? This way we can remove
all "IAB Considerations" sections from specific drafts that
(technically) have nothing to do with IAB. We will have all
IAB-related information in one place, without repetitions.

To summarize, there are three options:

	1. "lean and mean":
	   Each draft has its own IAB Considerations section
	   addressing only relevant considerations (if any)

	2. "can never be too careful":
	   Each draft has its own IAB Considerations section
	   addressing all 9 considerations (explaining
	   irrelevance where needed and pointing to relevant
	   drafts)

	3. "all under one roof":
	   One dedicated "Addressing IAB Considerations" draft
	   addressing all 9 considerations (pointing to relevant
	   drafts as needed). Other drafts simply refer to
	   this dedicated draft from their Introductions.

To me #1 and #3 are more attractive than #2. Which one would you
prefer?

Thanks,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 20 May 2003 16:27:28 -0600

Giving an example of an IAB concern that is not relevant to OCP does
not mean that there are no concerns relevant to OCP.

It had always been my expectation that OCP would carry information
about privacy requirements for data shared between the OPES processor
and the callout server, and that the level of confidentiality would
match the requirements.  And, to me, that further implied that OCP
must have mechanisms fine-grained enough to keep data separated
and protected at the appropriate level.

OCP MUST be able to protect any information about the user, the user's
preferences, history of user selections, times of connection,
etc.   It would be better to avoid having to carry this information at
all, if possible.  Only the minimum information about the mechanical
protection should be carried.  It had seemed to me that we would
avoid having the OPES processor give the userid to the callout server,
for example, if we could simply give some minimal information about
the OPES services needed on the data.

I think that if we try to duck the issue altogether we will force people
into greater information disclosure and greater privacy risks than if
we address the problem straightforwardly as a protocol requirement.

Hilarie

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 20 May 2003 17:14:42 -0600

I think it's also wise to note the word "consideration" ... the IAB
did not mean to have their words turned into absolute minimal
requirements - they meant that they wanted to WG to *consider* them.
It's the documentation of the consideration that is important, not just
the conclusions.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 17:20:36 -0600 (MDT)

I agree with what you are saying, but I do not understand how is that
relevant to any specific IAB consideration. Please clarify the
relevance. IAB does not seem to care about the things you describe
below, not in their considerations anyway...

Saying that IAB considerations are not relevant does not mean that we
are not going to address privacy concerns (that are not expressed in
those considerations).

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 20 May 2003 20:08:54 -0400

> 	   this dedicated draft from their Introductions.

I somewhat like option 3, with a reference to the "all under one roof" 
document in each of the other OPES docments. I'm sceptical about 
option 1...

I'll check with our ADs whether there would be a preferred option.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 20 May 2003 20:12:44 -0400

> It's the documentation of the consideration that is important, not just

Absolutely, couldn't agree more, thanks for emphasizing this.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 21:46:39 -0600 (MDT)

On Tue, 20 May 2003, The Purple Streak, Hilarie Orman wrote:

> It's the documentation of the consideration that is important, not
> just the conclusions.

Sure, but documenting why certain consideration is not relevant to a
particular draft is not important. Some other draft documents why that
consideration is relevant (to that draft) and how it is addressed (by
that draft).  That is all I am saying -- do not re-document what is
documented elsewhere (pick option #1 or option #3, not option #2).

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 20 May 2003 21:54:48 -0600 (MDT)

> document in each of the other OPES docments. I'm sceptical about

OK. Let's focus on option #3 then. If nothing else, it will save IAB a
lot of time if they decide to check how we are addressing their
concerns.

> I'll check with our ADs whether there would be a preferred option.

Good idea, please do! I assume it is not possible or appropriate to
check with IAB folks directly? I can put a stub draft together if you
get no objections to #3 from ADs. There will be no "IAB
Considerations" section in the OCP draft until the issue is resolved
one way or the other.

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 21 May 2003 18:32:11 -0400

> Considerations" section in the OCP draft until the issue is resolved

Until we hear back, I'd suggest to start moving forward with the "all 
under one roof" draft. All other drafts should have a section on "IAB 
Considerations", which just refers to the single document.

Would be great if you could start with a stub draft and post it to the 
list. Once Abbie is back online, I'd hope he can also help getting 
this draft together.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 21 May 2003 23:26:40 -0600 (MDT)

On Wed, 21 May 2003, Markus Hofmann wrote:

> Would be great if you could start with a stub draft and post it to
> the list.

Done. Please see "OPES Treatment of IAB Considerations" at
	http://www.measurement-factory.com/tmp/opes/

Better title ideas are very welcome :-). I will start incorporating
existing notes relevant to IAB considerations soon.

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 27 May 2003 11:34:14 +0200

While in the process of trying to sell a budget for developping OCP, I meet 
requests coming from different WGs I would like to note for the records.

1. support of sub-schemes. Let say I want to access http://abc.com in 
French. I would like to use the RFC 3066 code for French (fre) and type 
http-fre://abc.com and have a translating OPES taking over.

2. Longhorn (Windows 2005) will abandon the notion of user files and 
replace them by blobs in a BillSQL database (partly as Dick Pick was also 
doing). This seems of interest to OCP. I maybe wrong but this may introduce 
an interesting security feature. OCP can transport Longhorn crypted blobs 
to Longhorn receiver. We have an end-to-end user security without any 
interface CPU load.

3. in domotics/immotics we may have peered systems actings as OPES where 
OCP may become the basic long distance protocol. Let say I have two places: 
home and a chalet in the Alps. I can set-up an OPES in each place filtering 
the home traffic. When the OPES see that a required information is known or 
decided by the systems in the oher place they introduce it. The problems 
which prevent that for years are both an easy to manage dispatcher at the 
right layer and a secure protocol.

4. in my DNS line of thinking, the support of the PNS (private naming 
space) together with the DNS could be the same way. The basic idea of the 
PNS working group is to use 1 letter TLDs as the network side of 1 letter 
schemes local disks. C:> means your C local disk, http://xxx.c means in 
your  ".c" private space. All the DNS (protocol) calls could be trough an 
OPES redirecting them depending on the alias I gave to ".c" or to "xxx.c" 
(some kind of dynamic DNAME).

jfc

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 27 May 2003 09:30:15 -0600 (MDT)

On Tue, 27 May 2003, jfcm wrote:

> While in the process of trying to sell a budget for developping OCP,
> I meet requests coming from different WGs I would like to note for
> the records.
>
> 1. support of sub-schemes. Let say I want to access http://abc.com
> in French. I would like to use the RFC 3066 code for French (fre)
> and type http-fre://abc.com and have a translating OPES taking over.

This kind of adaptation is supported by OCP but is probably out of
OPES scope due to the following IAB 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.

That is, OPES protocols and mechanisms may work well for what you want
to do, but supporting this use case directly will not be possible in
OPES working group.

You will also have to have the OPES processor very close to, if not
embedded into, the browser because the infrastructure may not support
propagation of http-fre: URLs/requests. This is also, IMO, an inferior
design because you are overloading the meaning of the schema ("http")
into access protocol plus an OPES service. Perhaps a cleaner and more
robust solution would be to put adaptation specifics into HTTP headers
or use
	http://abc.com?opes-trans=fre
or even
	http://fre.opes-service.com/?url=abc.com
or something along those lines?

> replace them by blobs in a BillSQL database (partly as Dick Pick was
> also doing). This seems of interest to OCP. I maybe wrong but this
> may introduce an interesting security feature. OCP can transport
> Longhorn crypted blobs to Longhorn receiver. We have an end-to-end
> user security without any interface CPU load.

Possible with OCP but out of OPES scope (there seems to be no proxying
or adaptation involved). I am also not sure OCP is the best protocol
for the task because OCP is designed for adaptation, not just
forwarding. That is, it is optimized for the case where you want to
get an adapted response back from the callout server.

> 4. in my DNS line of thinking, the support of the PNS (private
> naming space) together with the DNS could be the same way. The basic
> idea of the PNS working group is to use 1 letter TLDs as the network
> side of 1 letter schemes local disks. C:> means your C local disk,
> http://xxx.c means in your ".c" private space. All the DNS
> (protocol) calls could be trough an OPES redirecting them depending
> on the alias I gave to ".c" or to "xxx.c"  (some kind of dynamic
> DNAME).

I guess this is similar to #1 as far as OCP support and OPES scope are
concerned.

HTH,

Alex.

---

From: Yimin Chen <[email-masked]>
Date: Wed, 28 May 2003 18:20:25 -0700 (PDT)

Hi,

I am reading section 4.7 regarding ISTag in ICAP
response. In the section, it mentioned that the change
of ISTag should invalidate all entities generated by a
particular service. Could someone clarify for me
whether this "entities" referring to objects in "ICAP
CACHE" (cache to store ICAP responses), or objects in
"HTTP CACHE" (in the case that the ICAP client is a
HTTP proxy. 

Thanks!
Yimin 

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com