Subject: Re: IAB considerations

From: Alex Rousskov <[email-masked]>
Date: Fri, 15 Aug 2003 17:14:48 -0600 (MDT)

On Thu, 24 Jul 2003, The Purple Streak, Hilarie Orman wrote:

> The current consideration draft confuses "privacy" and "undetected
> modification" and "encryption".
>
> "Privacy" is about trusting a party with data that they may use but
> not disclose.  The detection modification of data is its
> "integrity", and it can be ensured by cryptographic methods,
> including keyed hashes and public key methods, but in general, not
> encryption.  Encryption is used for "confidentiality", and it can be
> accomplished by cryptographic methods, but it is not a way to ensure
> integrity: encrypted data on the wire can be undetectably modified
> by third parties unless a cryptographic integrity mechanism is used
> in conjunction with the encryption.

While do not fully agree with your interpretation of privacy,
integrity, and encryption, I would be more than happy to discuss
specific draft flaws and address these concerns (of course). What
draft text should be fixed in this regard?

> The current draft characterizes processor identification at content
> provider sites as "irrational"

I disagree. The draft says (emphasis added) "It is irrational to
expect a content provider to provide _access_ to internal hosts
participating in content generation". This is different from providing
identification of those hosts!

The point is that in a typical environment an end user would have no
way to access internal hosts, even if they are well identified.
Furthermore, even if such access is provided as an exception to
corporate integrity policy, the accessed servers will not be able to
tell the end user much because they are not designed for or have
enough information to communicate with end users. Note that the above
quoted text belongs to the "IP-layer communication" section. We are
discussing addressability of the OPES intermediaries there, nothing
else.

The conclusion in the current draft is that the IAB consideration in
question can apply to a "a very limited subset of OPES intermediaries"
and, hence, is not directly satisfiable in real world.

My feeling is that IAB did not see the big picture (OPES systems) and
focused their attention on components (OPES processors), creating
irrelevant/misleading concerns. I am guessing that they simply did not
consider common arrangements where many OPES processors form a single
OPES system, representing a single content/data provider.

Note that if IAB had expressed their concerns in terms of OPES
systems, we would have no problems satisfying them! My suggestion is
that we do not treat IAB concerns literary but apply our better
understanding of the problem domain to satisfy "true" IAB intent.

If you are familiar with Lawrence Lessig's work, this approach is
similar to re-interpreting the Constitution authors' intent in the
light of current [digital] reality instead of treating Constitution
text literary and, hence, inapplicable. To our advantage, IAB members
are still alive as opposed to US Constitution authors; we can always
get a second opinion. Moreover, I think Markus intended to get such a
second opinion sometime soon, using the existing draft.

> It is also argues that end users cannot identify themselves usefully
> to a content provider's internal processors.  Although I don't
> disagree that this might be true in some implementations, it isn't
> clear that it is impossible in practice.

It is not that the users cannot identify themselves. They
[technically] can. It is that the internal OPES processors do not
poses enough state and global understanding to respond to user
requests. Most OPES processors do not have a notion of a "user"; they
work with much more simple and well-focused objects like XML trees,
access counters, or ad images.

> I think that overall the viewpoint should clearly distinguish
> between protocol feasibility and impact on content provider
> practices.

The text is trying to distinguish between micro-level feasibility
(OPES processor MUST be addressable) and architectural macro-level
feasibility (OPES processor is invisible behind an OPES system which
MUST be addressable).

We can approach the problem from a different angle:

	IAB already made an exception for chained OPES processors.
	An OPES system is nothing else but a chain of OPES processors
	or a very similar structure. Clearly, there should be
	no difference to the end user whether she deals with
	a chain or a "graph/tree" of OPES processors as long as the
	exit point is addressable/identified!

Would that angle help you accept the notion of OPES system? If not,
where do you see an important difference between a "chain of OPES
processors with an addressable exit point" and a "graph of OPES
processors with an addressable exit point"?

Thank you,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 15 Aug 2003 17:22:13 -0600

Sounds like a good way to ensure that the documents never come close
to RFC status ...

Hilarie

On Fri, 15 Aug 2003 at 17:14:48 -0600 (MDT) Alex Rousskov scribbled:

> My suggestion is

---

From: jfcm <[email-masked]>
Date: Sat, 16 Aug 2003 13:01:49 +0200

At 01:22 16/08/03, The Purple Streak, Hilarie Orman wrote:
>Sounds like a good way to ensure that the documents never come close to 
>RFC status ...

Understood and accepted.

This in turns sounds like the best explnation why my job is delayed for 15 
years due to what some call the IAB ineptitude to understand the real 
world. This is not a critic of the concerned people but of the very nature 
of the consensual system. Good for developement specification, not for 
innovative architecture.

Now question is: shall we stay with everyone, or shall we make them move 
ahaead?
jfc

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03

---

From: Marshall Rose <[email-masked]>
Date: Sat, 16 Aug 2003 07:13:25 -0700

[ speaking as co-chair... ]
    
guys - this is tiring, so let's go back to first principles.
    
the charter is quite clear in saying that the work product has to
address the IAB considerations. it is also quite clear in stating that
the work product can diverge from those considerations providing that it
clearly documents the rationale.

to topic of what the iab/framers know or didn't know isn't
relevant. what is relevant is that the document editors need to make
sure that there is concise explanations as to why a given document
diverges, so that the poor iesg can decide whether the trade-off is
acceptable. (by definition, only the iesg and iab know what "the big
picture" is.)
    
thanks,
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 16 Aug 2003 12:17:46 -0600 (MDT)

Marshall,

	I agree with your statement 100%. That is exactly what I was
trying to do when writing the "IAB treatment" draft: address what we
can, document what we cannot, and explain why.

	However, Hillarie asserts, in part, that if IAB says "OPES
processor MUST be addressible" then it must be addressible even it
makes no sense or is technically impossible. I disagree with such a
position. I assume that IAB will listen to reasonable arguments. This
difference in assumptions/approaches caused the discussion on this
thread.

	I am not sure how to proceed though. Clearly, we cannot say
both "OPES processor MUST be addressible" and "OPES processor MAY be
addressible". We have to pick wether our primary unit of concern is
OPES system as a whole or each OPES processor inside the system. I
think I used up all the arguments for the former. If Hillarie is not
convinced, we are stuck.

Alex.

---

From: jfcm <[email-masked]>
Date: Sat, 16 Aug 2003 21:56:25 +0200

At 20:17 16/08/03, Alex Rousskov wrote:
>If Hillarie is not convinced, we are stuck.

I do not think so. If we take back the thinking we have;

1. IAB says each processor MUST be addressable
2. we say each OPES processor belongs to a domain
3. the owner of the domain may not want each of its OPES processors to be 
disclosed.

1. It seems that we can say that each OPES processor in an OPES system MUST 
be addressable through its OPES domain sub-address, however povided his 
OPES domain address is tracable; a  domain owner MAY opacfied the 
sub-address of his processors.

2. in the security part it can be underlined that the OPES domain owners 
should be adviszed not to disclose the domain adress of their processors or 
to provide coded addresses suitable for trouble shouting but not for access.

jfc

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 16 Aug 2003 21:33:33 -0600 (MDT)

On Sat, 16 Aug 2003, jfcm wrote:

> 1. It seems that we can say that each OPES processor in an OPES
> system MUST be addressable through its OPES domain sub-address,
> however povided his OPES domain address is tracable; a domain owner
> MAY opacfied the sub-address of his processors.
>
> 2. in the security part it can be underlined that the OPES domain
> owners should be adviszed not to disclose the domain adress of their
> processors or to provide coded addresses suitable for trouble
> shouting but not for access.

First of all, you are mixing two distinct properties: IP-level
addressability by end user (IAB consideration 2.2) and OPES processor
identification in the trace for end user (IAB consideration 3.2). The
opaque IDs will not make internal OPES processors addressable at IP
level. Nothing short of OPES-specific VPNs will -- the whole point of
an internal host is that it is not IP-addressable from the outside!

If we concentrate on processor identification alone, then I agree with
your approach as long as "opacification" (making opaque) of OPES IDs
includes removing them completely. There is absolutely no reason for
us to tell content provider how to identify their internal systems. In
a simple case, for example, there will be a single path through the
OPES system and no individual processor identification will be
necessary.

Combining the two observations above, we can see that we should
concentrate on specifying OPES system IDs and may ignore all other IDs
until we have spare cycles to waste.

Alex.

---

From: jfcm <[email-masked]>
Date: Sun, 17 Aug 2003 06:54:08 +0200

At 05:33 17/08/03, Alex Rousskov wrote:
>identification in the trace for end user (IAB consideration 3.2).

I obvilusly know. We have an arbitrary logic demand and we have oractual 
needs. We have to start fomr the practical needs and see how/if they can 
match the arbitrary logic, to doucment a response.

>until we have spare cycles to waste.

Here I disagree. Identifying various OPES operators domain and reacting on 
that information is important. Because for example I do nottryst them or I 
do not make or I make business with them.

jfc

---

From: Marshall Rose <[email-masked]>
Date: Sun, 17 Aug 2003 10:48:38 -0700

> difference in assumptions/approaches caused the discussion on this
    
let's try this: edit the draft so that is complete and
self-consistent. to the extent it differs from what the IAB recommends,
make sure that the differences are explain and justified. then have a
friend take a pass through the document for clarity and conciseness.

we will then see if we have concensus around that document.
    
if so, we'll move forward, and wait to from the powers-that-be.
    
if not, we'll try a different approach.
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 18 Aug 2003 11:37:56 -0600 (MDT)

On Sun, 17 Aug 2003, jfcm wrote:

> Here I disagree. Identifying various OPES operators domain and
> reacting on that information is important. Because for example I do
> nottryst them or I do not make or I make business with them.

I dod not say it is not important. It is just a much smaller scale
problem, where no good general solution may exist. If this WG does not
define a solution for OPES processor identification (but defines OPES
system identification), then OPES will still "work" and satisfy IAB
concerns (in my rendition of them). The reverse is not true, IMO: OPES
processor identification alone will not satisfy IAB (or mine)
concerns.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 18 Aug 2003 16:34:39 -0400

Alex Rousskov wrote:

> [...] Moreover, I think Markus intended to get such a

Let's add some more details and, in particular, an example showing a 
specific trace flow and how it would be used to resolve problems. My 
feeling is that this would be helpful when asking of additional opinions.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 18 Aug 2003 15:19:50 -0600 (MDT)

> feeling is that this would be helpful when asking of additional

Agreed. In theory, three drafts will need to updated to provide an
example: OPES communications draft (Abbie), HTTP adaptation draft
(Martin Stecher or myself), and IAB treatment draft (Abbie or myself).
I will update IAB treatment draft soon. That should be enough to get
us started with the IAB review and other drafts can catch up if the
review is positive.

Thanks,

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Tue, 19 Aug 2003 09:02:51 -0700

> friend take a pass through the document for clarity and conciseness.

ok, so when are we going to have this submitted as an I-D?

/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 19 Aug 2003 10:20:56 -0600 (MDT)

> ok, so when are we going to have this submitted as an I-D?

I can commit to finish another update by the end of this week,
hopefully sooner. We will probably need at least three working days
for a WG-wide review and then a day or two to apply changes suggested
by that review, assuming the WG decides to proceed with the draft as a
WG draft.

Does August 30 sound like a reasonable self-imposed submission
deadline?

Thanks,

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Tue, 19 Aug 2003 09:59:53 -0700

> Does August 30 sound like a reasonable self-imposed submission

i can't quite parse this.

what you need to do is to submit an I-D you say "works" according to the
criteria i gave you.

at that point, the chairs decide what the timeline is for review, comments, and
whether their is concensus, based on what the feedback is on the mailing list.

in other words: submit the draft on friday morning, and we'll worry about the
rest later.

/mtr