Subject: WG Last Call: draft-ietf-opes-architecture-00

From: Markus Hofmann <[email-masked]>
Date: Sat, 18 May 2002 22:01:20 -0400

Since there haven't been any comments on the published OPES 
Architecture draft so far, we're issuing a Working Group last call on 
this draft:

This is an OPES Working Group Last Call for comments on
draft-ietf-opes-architecture-00. This last call closes Sunday, June 2, 
2002. Please post any final comments you have on the draft to this 
list by that date. If there are no substantive technical issues raised 
by June 2, we will forward this document to the IESG for publication 
as Informational.

The draft is available at

http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-00.txt

---

From: Graham Klyne <[email-masked]>
Date: Mon, 20 May 2002 10:47:08 +0100

There's nothing like a last-call to raise a reviewer's priorities, right?-)

I approach this document on the assumption that (based on its title) it is 
to be a basis for designing and understanding OPES protocol elements.  I 
think it starts off quite well, but then descends into a morass of vague 
hand-waving whose design intent is hard to fathom.  Much of the later parts 
of the document seem to be a catalogue of requirements rather than the 
design elements that I would expect in an "architecture".  For example, I 
would expect an "architecture" document to enumerate the various components 
that must be specified to make up the OPES specification.

Also, I think that there are some serious problems with tracing facilities 
sketched in section 2.6.

And I think that, as a starting point for other aspects of OPES design, it 
would be appropriate to include a collected glossary in this document.

And so to detail:

Section 1
---------

The first paragraph mentions customization based on geographical 
locality.  Taking this as an example, I didn't notice anything later in the 
document about the source of information that an OPES processor might use 
as the basis for customization services.  I think some discussion might be 
appropriate;  e.g. is any such customization to be based on information 
provided by the party with respect of whom the customization is being 
performed?  Or conversely, If I connect via an ISP in a foreign country, 
might I expect to get information customized for that country?  I think 
such sources of information should at least be clearly identified in any 
trace information.

Section 2.0
-----------
Do OPES entiries include the provider and consumer?  It's not clear to 
me.  The second bullet here suggests "yes", but elsewhere suggests "no".

Section 2.1
-----------
The distinctive roles of OPES service application and data dispatchers 
aren't entirely clear.  I would expect what you describe as an "Opes 
service application" that sits on the provider-consumer flow to contain the 
architectural elements you describe under "data dispatcher".

Section 2.2
-----------
Where you say "one or more OPES service applications" and "one or more data 
dispatchers" I think you mean "zero or more".  Later you mention "zero or 
more..."

2nd para:  I found this description rather woolly.  Would any significant 
meaning be lost if the second sentence of this paragraph were to be deleted?

Section 2.3
-----------
It seems to me that the OPES rules are a cornerstone of the architecture, 
but very little is said about them.

Section 2.4
-----------
Maybe this is just a personal preference, but talking about "executing" a 
ruleset seems to be very implementation-choice-oriented;  would 
"evaluating" not be closer to what you mean here?

You also discuss using "the OPES callout protocol", which seems to say 
there is a single such protocol.  It is not clear to me why there needs to 
be a single such protocol, as different dispatcher/server combinations 
might use different protocols according to the needs of the 
application.  For example, I'd imagine a session-oriented protocol 
appropriate for an HTTP callout service, but for processing email flows a 
callout protocol based on email style messaging, or file sharing, might be 
more appropriate.

Maybe there are reasons for defining a single protocol here:  if so, I 
think they should be explained.

The final sentence of the final paragraph is impenetrable to me.  What's 
this "...service aware vectoring capability that parses the data flow 
according to the ruleset..."?

And a typo in the final para:  "detremine".

Section 2.6
-----------
I think this section is very weak.  It manages to impose questionable 
implementation decisions without providing any real guidance about how 
tracing is to be provided.

Specifically, it calls for "in-band annotation through header extensions on 
the application protocol".  I believe that this approach will mean that the 
tracing facility is effectively unusable at Internet scale, because it 
depends on protocol extensions that will be largely unimplemented by the 
end systems who need access to the diagnostic information.

I recently encountered a real problem that will illustrate my concern 
here:  my wife works from home as editorial manager for a 
website.  Recently, she was reviewing website content and was getting old 
data when all the other parties involved were getting new data.  This 
occurred with different browsers, after cache-flushing, etc., so was almost 
certainly not a local problem.  It most likely was a fault in an 
intermediate transparent cache.  Now, I think this is exactly the kind of 
problem that OPES tracing should be able to diagnose.  For this to be 
useful, I'd say it must be possible to access the traces without any 
extensions to the protocol whose flow is being serviced by OPES.

The sort of design I might suggest would be that an OPES intermediary 
maintains an audit of services that are applied, possibly for a limited 
time.  This audit should be accessible to affected clients using standard 
features of the protocol whose flow is being OPES-serviced.

Section 3
---------
I think this whole section needs more work -- I found this had a kind of 
motherhood-and-apple-pie flavour, without providing much in the way of real 
information about how the security issues are to be handled.  Or at least 
determining what OPES component is responsible for what aspects of the 
security issues raised.

Section 3.2
-----------
This touches on an area where I take issue with the IAB requirements on 
OPES (and have posted my comments elsewhere).

[[
    The primary data flow occurs between the data provider and the data
    consumer.  OPES must not interfere with the capability of these
    parties to use end-to-end authentication and confidentiality.
]]

Consider the case of an employee working for a corporation.  I is the 
employee or the corporation considered to be the "data provider" or "data 
consumer" here.  I particular, is OPES required to allow an employee to 
send encrypted data out of the organization without examination by an 
intermediary system?

In terms of OPES architecture (as I understand it), I think the employee is 
the end system here, and the corporate network may contain OPES 
intermediaries that prohibit the data flows that OPES is hereby prohibited 
from interfering with.  That is how content filtering systems with which I 
am familiar are deployed.  I think the requirements need to be refined.

#g
--

At 10:01 PM 5/18/02 -0400, Markus Hofmann wrote:

>Since there haven't been any comments on the published OPES Architecture 
>draft so far, we're issuing a Working Group last call on this draft:
>
>2002. Please post any final comments you have on the draft to this list by 
>that date. If there are no substantive technical issues raised by June 2, 
>we will forward this document to the IESG for publication as Informational.
>

-------------------
Graham Klyne
<[email-masked]>

---

From: Marshall Rose <[email-masked]>
Date: Mon, 20 May 2002 04:55:32 -0700

[ i've trimed the cc list, because those markus, ned, and allison should be on the mailing list... ]

> There's nothing like a last-call to raise a reviewer's priorities, right?-)

my interests in this is primarily process, but since i was on the
subteam that produced the document, i'd figure i'd answer what
questions that i could...

> that must be specified to make up the OPES specification.

i'm not sure i agree with your characterizations. the job of an
architectural document is to enumerate components and their
relationships. sometimes, as a part of that, the document has to
discuss mechanism. in general, i think that the existing document
adheres to those principles. however, it's only a draft (and one
that was written from scratch), so some tuning might be needed.

> would be appropriate to include a collected glossary in this document.

my position, in all working groups, has been that putting glossaries
in documents is the signature of poor writing. at best, they're
redundant, at worst, they're contradictory. if the document can't
define terms in context as they are used, then there is a more
fundamental problem in the document...

> Section 2.0

from an architectural perspective, i think the answer is no...hence
the "zero, or more" text appearing througout with respect to opes
service applications. of course, you can't have an opes flow without
the provider or consumer, and perhaps this is why it's
counter-intuitive?

> Section 2.1

i personally think the names are confusing as the diagrams later on
try to make clear that the "data dispatcher" is the fundamental
thing. so, yes, this needs to get cleaned up.

> Section 2.2

agree.

> meaning be lost if the second sentence of this paragraph were to be deleted?

agree.

> Section 2.3

because *architecturally*, very little need to be said, the rest of
the document defines the boundaries that the rules operate in...

> Section 2.4

agree, poor wording.

> callout protocol based on email style messaging, or file sharing, might be 

hmmm. i thought that the architecture was saying that there was only
one kind of OCP, regardless of the protocol being used in the data
flow.  in other words, there is no "seems to say" about it, it
"says" there's only one.

> think they should be explained.

so, what you are really asking, and what the working group should
discuss is this issue.

> according to the ruleset..."?

agree, poor wording.

> And a typo in the final para:  "detremine".

agree.

> Section 2.6

hmmm. again, i think it sets some architectural boundaries, but
doesn't make any implementation choices (questionable or not).

> end systems who need access to the diagnostic information.

i think that "Internet scale" means different things. there's also a
counter-balancing set of concerns dealing on the impact on the opes
entities.

my interpretation, which could be wrong, of the iab concerns, was
that the working group could get away with diagnosis after the
fact. and if you believe that (it's certainly open to discussion),
then i think that the logic of simplicity inevitably takes you to
what the document says now... (albeit with perhaps more simple
wording!)

> extensions to the protocol whose flow is being serviced by OPES.

i agree that problems like this should be subject to diagnosis. i
don't think it's

> features of the protocol whose flow is being OPES-serviced.

i'm with you right up to the "using standard features of the
protocol" ... because your own argument argues against that.

maintaining an audit of what's going on is fine (and real systems
will do that regardless of what the architecture document
says). figuring out how to transparently tap into the audit
information is problematic...

> determining what OPES component is responsible for what aspects of the 

i more or less agree.

> Section 3.2

i agree that one can interpret the IAB concerns as saying that
corporations can not address this security issue using OPES.

my reading of the document is that the architecture allows OPES to
be realized to address this security issue.

my understanding of the IESG's perspective on the IAB concerns is
that if a cogent argument is made as to why OPES isn't consistent
with certain aspects of the IAB concerns, then that's okay...

> #g

thanks! i look forward to seeing a lively discussion in the working group.

speaking of which: as a co-chair, my words on technical matters
don't have any more weight than anyone else's. i just happen to have
the phone bills from sitting in on the conference calls that
produced the architectural document, so i thought i'd reply...

/mtr

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 20 May 2002 13:28:01 -0400

Some notes on the OPES Architecture draft..

> 1. Introduction

>In some cases it may be impossible to offer the customization service
>at either the provider or the consumer applications.  In this case,
>one or more additional application entities may participate in the
>data stream service.

This term - "impossible" - may leave an impression that this is the
only, or at least main justification to use OPES. This does not look
right. The only scenario (from existing draft-beck-opes-esfnep) where
OPES is the only way to implement the service is request filtering
for hand-held devices, in all other cases service can be implemented
either at the server side or at the client side, or both.

Still use of OPES may be beneficial, so I'd suggest ether to use
a different wording, like:

"In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or
the consumer host. For certain services performed on end-user behalf
this may be the only option of service deployment".

> 2. The Architecture

> - OPES rules: these determine how a given data flow is modified by
>      an OPES entity.

This definition looks too restrictive. From the rest of the document
and previous discussions rules are used to determine when the
transformation has to be involved. The definition above suggests that
the only OPES applications permitted by this architecture are "rules
interpreters". I don't think this is what really was intended.

> 2.1 OPES Entities

The usage of terms "OPES service application" and "data dispatcher"
is not always consistent and sometimes even confusing. According to
the definition in 2.1 service application is invoked by data dispatcher.
If this is always a case (an according to the definition it is so)
Figure 1 should look like this:

                             +----------------+
                             | OPES service   |
                             | application    |
                             +----------------+
                             |data dispatcher |
                             +----------------+
                             |                |
                             |    HTTP        |
                             |                |
                             +----------------+
                             |   TCP/IP       |
                             +----------------+
                             |     ...        |
                             +----------------+

                    Figure 1: An OPES protocol stack

It also may have sense to point out explicitly that OPES application
may be executed either on the same box (or even in the same application
environment) with the dispatcher or on different box through OCP.
This was on of important features in initially discussed architecture,
there were even terms like "proxylet" flying in the air.

I thing it has sense to emphasize this possibility and to provide a
figure like this:

      +--------------------------+
      | +----------+             |
      | |   OPES   |             |
      | |  service |             |
      | |   appl   |             |
      | +----------+             |      +----------------+
      |     ||                   |      |                |
      | +----------------------+ |      | +--------+     |
      | |     data dispatcher  | |      | | Service|     |
      | +----------------------+ |      | |  App2  |     |
      | |   HTTP     | OCP     | |      | +--------+     |
      | +------------|         |===(2)====|  OCP   |     |
      | |   TCP/IP   |         | |      | +--------+     |
      | +------------+---------+ |      |                |
      +-------||-----------------+      | callout server |
              ||                        +----------------+
          ...........(1)

This is a kind of combination of figures 1, 3 and 4.
It also emphasizes some questions that remain unclear from the use
of different terms in different places:

- What is "OPES flow" - (1), (2) of both? Figure 2 suggests (1),
Figure 3 suggests (2), Figure 4 suggests (1). Maybe we need several
terms to distinguish between different data flows?

- What is "OPES processor"? Figures 2 and 4 suggest different
interpretations: is this a "processing point" in the data flow
that functionally combines both boxes above (as in Figure 2) or
just an infusion point, as in Figure 4? I'd suggest former, otherwise
we are putting too much emphasis on application execution point,
but again we may need more developed terminology.

> 2.3 OPES rules.

> In this model, all data filters are
>   invoked for all data.

This is very ambiguous. Again, depends on what is
a "data filter". If this is an OPES application this just does not
look right. If this is a specific rule this makes more sense but
looks too restrictive - unambiguous rule resolution may be checked
at the compilation time and then there is no need to go though all
rules after one of them has fired. At least I'd not include this
as an architecture requirement.

>2.4 Callout Servers

> The OPES ruleset is executed within a data dispatcher, which triggers
> the execution of local OPES service applications.  How the ruleset is
> executed is not the subject of the architecture.  ...

The word "executed" here is used three times. First and second uses
have a different meaning, the meaning of the third one is unclear.
I'd suggest "interpreted" for the first use. For the third one - do
you mean "implemented"? How does this come along with

"the OPES ruleset schema [6] which defines the syntax and semantics
      of the rules interpreted by a data dispatcher"

proposed in Summary?

>> Figure 3.

Why do we prescribe the use of TCP/IP for OCP in all cases? I agree
this may be the most practical way to implement OCP but I would not
carve it into the RFC.

>2.5 Policy Enforcement

> compiled ruleset

I'd suggest using the word "combined" - the word "compiled" may be
applied to the same ruleset in efficiency considerations (as opposed
to direct interpretation), and this may create some ambiguity.

>..............
>dispatcher constitutes an enhanced Policy Enforcement Point (PEP),

Use of PEP abbreviation may be a little confusing: this document
references RFC 3238, which uses this abbreviation in a different
sense - performance-enhancing proxies, originating in RFC 3135
(see RFC 3238, p.4).

> 2. The Architecture
- general composition.

The introduction lists three bullets, then we have 2.1, 2.2 and 2.3
explaining each of them in turn, very good documentation practice.
But then we have also 2.4, 2.5 and 2.6 - these breaks the composition.

I'd suggest moving 2.4 (callout servers) within 2.1 (maybe as 2.1.1)
and the rest (2.5 and 2.6) to part 3.

>> Ruleset definition.

In fact ruleset is defined in several places - 2.3, 2.4 and 2.5, each one
adds some more to the definition. It may have sense to combine all of them
in complete definition and place it in 2.3.

> 3. Security and Privacy Considerations

It looks like we are looking at one general scenario: there is a data
provider, there is a data consumer and there is an OPES server that
just happened to be in between - and now we are prescribing the
rules for legitimate coexistence.
While this is a valid general scenario I'd suggest to look at
two more:

- CDN scenario: OPES architecture is used to build a content
distribution network and OPES servers in fact constitute an
integral part of data provider. In this case such servers have
an absolute trust of data provider and the end user has no more
right or reason to question/interfere with there functionality
than it has now in relation to the architecture of the
provider's site web servers farm.

- Incoming/outging data filter (company/library/school, etc.).
In this case OPES server has an absolute trust of data consumer
(which in this case is an entity different from the end user's
browser), and as such it may block all attempts of the end user
application (be it browser or other) to interfere with OPES
functionality and trace changes.

Rules of engagement in these three scenarios are very different,
and it is very important to include them into the consideration
from the very beginning. It was (and still is) one of main
problems in web caching world: all protocols are build for the
case of "indpendent facilitator" scenario", and when web caches
are used as part of web site or CDN people start building
the architecture to circumvent protocol limitations. In the
web caches case historically these use cases emerged long
after protocols were developed, but for OPES these use scenarios
should be built into the architecture from the very beginning.
I believe this may save us a lot of pain and heated IETF
discussions.

> 4. Summary.

> - the OPES callout protocol (OCP)

I think we are in fact talking about family of protocols. OPES
may be used with different application protocols and this may
require different OCPs. This should be stated explicitly and
for each proposed OCP applicability description should be
included.

Oskar Batuner

---

From: Ian Cooper <[email-masked]>
Date: Mon, 20 May 2002 18:04:01 +0100

--On Monday, May 20, 2002 10:47 +0100 Graham Klyne 
<[email-masked]> wrote:

> locality.  Taking this as an example, I didn't notice anything later in
> the document about the source of information that an OPES processor might
> use as the basis for customization services.  I think some discussion
> might be appropriate;  e.g. is any such customization to be based on
> information provided by the party with respect of whom the customization
> is being performed?  Or conversely, If I connect via an ISP in a foreign
> country, might I expect to get information customized for that country?
> I think such sources of information should at least be clearly identified
> in any trace information.

Agree with that last part, and I think that first paragraph needs some 
clarification (or more accurate examples).  Geographic location and the 
prevailing language are related, but linking them as in the example is 
perhaps a bad idea (which is I think what you're suggesting also Graham). 
Customisation based on language is more likely to be useful where the 
requesting system doesn't want the material presented in the prevailing 
language, surely?

"resource availability" doesn't work for me on first parsing since I took 
the resource to be the requested entity, not the entity on which it was 
being displayed (but it might only be me that has that problem).

> Section 2.0

Agree that it's not clear. My initial reaction would be that by the 
definition given neither the provider nor consumer are *in* the network 
(they are at opposite edges of the network).  Of course, this is a 
simplification since the protocol specific output from an OPES intermediary 
could be a "provider" to things downstream of it :-)

> service application" that sits on the provider-consumer flow to contain
> the architectural elements you describe under "data dispatcher".

My reading is that the data dispatcher case is an OPES processor that 
provides the OPES entity by callout/vectoring, while an OPES service 
application is the system that can do the transformations (either within a 
single system or on the servicing end of the callout/vectoring system). 
Seeing Section 2.4 I'm not sure if that's the desired reading or not.

A diagram might help here?  (On which note, I'm not sure Figure 1 really 
serves any useful purpose, and appears to force an HTTP over TCP/IP 
implementation.)

> Section 2.2
> -----------
> Where you say "one or more OPES service applications" and "one or more
> data dispatchers" I think you mean "zero or more".  Later you mention
> "zero or more..."

Agree.

> meaning be lost if the second sentence of this paragraph were to be

I don't see any particular need for that second sentence.

I'm not particularly keen with the way the 3rd paragraph is worded.  One 
fix it to just not refer to a "data flow" at all.  My attempts at 
re-writing the first paragraph to introduce the term "OPES flow" with 
respect to being a specific type of data flow seemed to be rather 
cumbersome.

> Section 2.4

I'd prefer "evaluating" too.

> there is a single such protocol.  It is not clear to me why there needs
> to be a single such protocol, as different dispatcher/server combinations
> might use different protocols according to the needs of the application.
> For example, I'd imagine a session-oriented protocol appropriate for an
> HTTP callout service, but for processing email flows a callout protocol
> based on email style messaging, or file sharing, might be more
> appropriate.
>

I imagine that the lack of explanation might simply be due to historical 
reasons.  That said, simple re-wording in the text following Figure 3 would 
allow for multiple OCPs.  Unfortunately [7] is referenced (certainly later 
in the document) in a way that suggests there's one protocol while it 
actually refers to a requirements document.

Speaking of Figure 3, it's not immediately clear what's going on, making 
the appearance of the data dispatcher box different to the callout servers 
might help.

> Specifically, it calls for "in-band annotation through header extensions
> on the application protocol".  I believe that this approach will mean
> that the tracing facility is effectively unusable at Internet scale,
> because it depends on protocol extensions that will be largely
> unimplemented by the end systems who need access to the diagnostic
> information.

True.  This may also limit the number of protocols for which the 
architecture may be useful, though that might not necessarily be a bad 
thing.

> here:  my wife works from home as editorial manager for a website.
> Recently, she was reviewing website content and was getting old data when
> all the other parties involved were getting new data.  This occurred with
> different browsers, after cache-flushing, etc., so was almost certainly
> not a local problem.  It most likely was a fault in an intermediate
> transparent cache.  Now, I think this is exactly the kind of problem that
> OPES tracing should be able to diagnose.  For this to be useful, I'd say
> it must be possible to access the traces without any extensions to the
> protocol whose flow is being serviced by OPES.

Well... this is a demonstration of why you need that out-of-band access to 
the audit trail rather than a reliance on headers that are defined in the 
protocol spec. but are rarely used :-)

> features of the protocol whose flow is being OPES-serviced.

Seems reasonable, though would only work for a subset of the protocols that 
might benefit from modifications these systems might offer.  E.g. if video 
stream is modified I'm not sure that it would be possible to use the 
streaming delivery protocol to get acccess to the audit trail.  It does 
work for HTTP which was the primary target of this body of work though.

I'm also a little confused as to the apparent urgency to take this document 
WG (and presumably wider) Last Call when many of the supporting documents 
appear expired/non-existent in the I-D directory (perhaps it's just the 
titles that have changed? I thought I had an up-to-date mirror of the 
directory) making it impossible for the reader to fully understand this 
document.  (I.E. surely this document is just going to sit in RFC-Editor's 
queue anyway.)

---

From: Graham Klyne <[email-masked]>
Date: Mon, 20 May 2002 20:18:25 +0100

To pursue a few comments...

At 04:55 AM 5/20/02 -0700, Marshall Rose wrote:
>relationships.

Actually, I agree with that.  And this is what I felt the document didn't 
adequately address (though, as I said before, it did start out quite 
well.)  Mainly, in this area, I think it needs more work to clarify the 
components and their interactions, and in particular their role in 
addressing the security and diagnostic concerns.

>fundamental problem in the document...

If this document were the end of a process, I might agree.  But (I presume) 
it's laying some groundwork for ongoing cooperative design work, and for 
that I think some common, easily referenced vocabulary is particularly 
useful, in a FAQ kind of way.

>what the document says now... (albeit with perhaps more simple

I think diagnosis after-the-fact is fine.

>information is problematic...

Well... does it need to be "transparent"?

When I wrote my comments, I was thinking that there might be HTTP access to 
the audit trail (with appropriate authentication) from the client system in 
whose admin domain the OPES intermediary was operating.  That presumes the 
client knows what URL to use to query the audit, so its not transparent (in 
the sense of being automatically available), but I think that is 
information that could easily be made available.

(That was assuming an OPES intermediary on an HTTP flow;  for (say) an 
email flow, some variant of the mechanisms suggested by multipart/external 
might be used.  The key issue here is that an end user with standard 
off-the-shelf client software can access the diagnostic information, 
without dependence on protocol extensions.)

>with certain aspects of the IAB concerns, then that's okay...

Well, yes... I was trying to point out that I thought there was an 
important case here that the design should allow for, and acknowledging 
that it wasn't strictly (to my reading) aligned with the IAB requirements.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Ian Cooper <[email-masked]>
Date: Mon, 20 May 2002 20:13:06 +0100

> either at the server side or at the client side, or both.

In fairness I think it's fair to say that there are cases where it's 
impossible to insert localised advertisements without something like an 
OPES intermediary.

> this may be the only option of service deployment".

That seems limiting and doesn't seem (to me) to convey the aspect that some 
content can only be produced with the cooperation of (possibly 
non-exportable) information available to the ISP/IAP.  The problem is that 
without concrete examples (which are frequently limiting in themselves) it 
becomes very difficult to write introductory text like this.  The existing 
text (plus the introductory paragraph you omitted) seems, to me, a better 
approach to articulate the problem.

> Figure 1 should look like this:

Agree

> I thing it has sense to emphasize this possibility and to provide a

I like this diagram

> sense - performance-enhancing proxies, originating in RFC 3135

Thanks for bringing that one up; I'd had similar thoughts on the source of 
potential confusion.

> provider's site web servers farm.

Agree, though I'm not sure I see anything that suggests otherwise. 
(Apologies if I'm missing something in my jetlag induced haze.)

---

From: Marshall Rose <[email-masked]>
Date: Mon, 20 May 2002 14:23:50 -0700

> useful, in a FAQ kind of way.

all your comments were useful, but i'm going to focus on this one and let others in the design team focus on the rest.

we're not starting in a vacuum. part of the problem with the opes specification documents is that they are too long, verbose, etc., etc. the only way to get agreement is to continually simplify and refine until either: a) there's concensus on what's there, or b) what's there isn't worth doing.

either is an acceptable outcome to me. what isn't acceptable is spending a year on bofs producing documents that very few folks can understand.

so, the current architecture document tries to avoid the problematic nature of the previous set of pre-working group contributions by simply focusing on the basics. as a part of that, some niceties, e.g., glossaries get lost. i can live with that, because i'd rather not spend time having folks argue about definitions and spend yet another year making no forward progress...

others' mileage may vary, obviously.

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Mon, 20 May 2002 14:31:55 -0700

> document.  (I.E. surely this document is just going to sit in RFC-Editor's 

the document was published two weeks before the last call and there were ZERO comments on the list.

maybe everyone's on vacation, or everyone thinks its perfect, or everyone has stopped caring. maybe all three.

the only way to test that assertion is to do a working group last call and see what happens... based on your note and graham's note and oskar's note, the last call message had the desired effect. 

now, we need to see what others think and whether the discussion leads to a concensus on the existing document or what needs to go into the next revision...

/mtr

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 20 May 2002 17:45:24 -0400

Two typos:

Chapter 3.1:

line 3:
>  Stepwise means A delegates to B and B delegates to C and so force.

should be "so forth".

line 8:
   data "provider" color.  The only colors that are defined are data the
   "provider" and the data "consumer". 

Should be: 
   data "provider" color.  The only colors that are defined are the data 
   "provider" and the data "consumer". 

- Oskar

---

From: Robin Chen <[email-masked]>
Date: Tue, 21 May 2002 00:58:19 -0400

Ian and Oskar,

> (Apologies if I'm missing something in my jetlag induced haze.)

The architecture document does not exclude the CDN scenario -
check out Section 3.1 (Trust Domains) that talks about delegation
of authority.

The CDN scenario is also covered by the "Surrogate Overlay" section
in the original OPES model draft:

http://www.ietf.org/internet-drafts/draft-tomlinson-opes-model-01.txt

> 4.4 Surrogate Overlays
> 
>    A surrogate overlay is a specific type of 'content service 
>    network', which is delegated the authority to provide 'content 
>    services' on behalf of, and typically in close co-operation with, 
>    one or more 'origin servers'. Surrogate overlays can be seen as 
>    logical extension of 'origin servers'. 
> 

Note also that the term "authroritative domain" (instead of
trust domain) was used in the original model draft.

An upcoming OPES scenario document will cover the scenarios of 
surrogate overlay (server-centric), delegate overlay (client-centric),
and the enterprise scenario (data providers, data consumers, and all
OPES entities are in the same trust domain) - stay tuned ...
	
-- 
Robin Chen  AT&T Labs - Research   [email-masked] 
--------------------------------------------------------------
Room E219, 180 Park Avenue, Florham Park, NJ 07932-0971
phone:(973)-360-8653  http://www.research.att.com/info/chen

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 May 2002 01:00:01 -0400

Graham,

 > There's nothing like a last-call to raise a reviewer's priorities,

It can even overcome dead silence... :) Thanks for your feedback and 
for breaking the ice. While trying to catch up with emails, let me 
pursue some of your comments... I would expect some of the ID authors 
to jump in as well.

 > Section 1 ---------
 > locality.  Taking this as an example, I didn't notice anything
 > later in the document about the source of information that an OPES
 > processor might use as the basis for customization services.  I
 > think some discussion might be appropriate;  e.g. is any such
 > customization to be based on information provided by the party with
 > respect of whom the customization is being performed?  Or
 > conversely, If I connect via an ISP in a foreign country, might I
 > expect to get information customized for that country?  I think
 > such sources of information should at least be clearly identified

Should this kind of service-specific information (e.g. the source of 
customization information) really be part of the general OPES trace 
information? Wouldn't it be sufficient for OPES to provide trace 
information that identifies the performed OPES service, and provide a 
pointer from where an interested endpoint could obtain more detailed 
information (e.g. the source of customization information for that 
specific service)? This would be more flexible and scale better, since 
it seems challenging for general OPES traces to provide all possible 
aplication-specific trace information. OPES could just supply a "trace 
pointer" that would allow the endpoints to obtain the more 
(application-specific) information if desired.

 > Section 2.0 ----------- Do OPES entiries include the provider and
 > consumer?  It's not clear to me.  The second bullet here suggests
 > "yes", but elsewhere suggests "no".

 From an OPES perspective, I would assume "no", so we need some 
re-wording here. Maybe something like

   "OPES flows:  data flows that are cooperatively realized by
    a data provider, a data consumer, and zero or more OPES entities."

This would also need some re-wording in the last paragraph of section 
2.1, maybe something like

   "The OPES architecture is largely independent of the protocol that
    is used by the DATA CONSUMER AND THE DATA PROVIDER to exchange
    data."

 > Section 2.1 ----------- The distinctive roles of OPES service
 > application and data dispatchers aren't entirely clear.  I would
 > expect what you describe as an "Opes service application" that sits
 > on the provider-consumer flow to contain the architectural elements
 > you describe under "data dispatcher".

The "data dispatcher" is meant to be sort of a filter that determines 
which messages have to passed on to which "OPES service application(s)".

The "data dispatcher" always sits on a data processor box, while an 
"OPES service application" can reside on either a data processor box 
or a callout server.

Messages always pass through a "data dispatcher" before possibly being 
hand over to an "OPES service application", which can reside locally 
on the same data processor box as the "data dispatcher", or remotely 
on a separate "callout server".

Not sure whether the above might help, but I agree that we need some 
cleanup here.

 > Section 2.2 ----------- Where you say "one or more OPES service
 > applications" and "one or more data dispatchers" I think you mean
 > "zero or more".  Later you mention "zero or more..."

Yup, also one might say that if there are zero OPES service 
applications and zero data dispatchers, this is just a regular data 
flow, no OPES at all.

Maybe it should read "one or more data dispatchers" and "zero or more 
OPES service applications", since an OPES system is charaterized 
through the existence of a data dispatcher (i.e. all messages go 
through this data dispatcher), but it is not necessary that an OPES 
service appliation always gets executed.

 > 2nd para:  I found this description rather woolly.  Would any
 > significant meaning be lost if the second sentence of this
 > paragraph were to be deleted?

I'd assume no, although one interesting aspect might be that data 
processors and callout servers can reside in different admin domains...

 > Section 2.3 ----------- It seems to me that the OPES rules are a
 > cornerstone of the architecture, but very little is said about
 > them.

For the architecture we just need to describe their existence and 
where/how they fit in, but not their (internal) details.

 > Section 2.4 ----------- Maybe this is just a personal preference,
 > but talking about "executing" a ruleset seems to be very
 > implementation-choice-oriented;  would "evaluating" not be closer
 > to what you mean here?

Agreed.

 > You also discuss using "the OPES callout protocol", which seems to
 > say there is a single such protocol.  It is not clear to me why
 > there needs to be a single such protocol, as different
 > dispatcher/server combinations might use different protocols
 > according to the needs of the application.  For example, I'd
 > imagine a session-oriented protocol appropriate for an HTTP callout
 > service, but for processing email flows a callout protocol based on
 > email style messaging, or file sharing, might be more appropriate.

The goal is to have a single callout protocol independent from the 
protocol being used in the data flow. Whether this is possible or not, 
we'll see. Also, our current charter is restricted to HTTP and 
RTP/RTSP in the data flow.

 > Maybe there are reasons for defining a single protocol here:  if
 > so, I think they should be explained.

Yes, agreed, but this should be the outcome of some discussion in the WG.

 > The final sentence of the final paragraph is impenetrable to me.
 > What's this "...service aware vectoring capability that parses the
 > data flow according to the ruleset..."?

Yup, wording is somehow confusing. I believe it means to say that 
although the OCP itelf is application agnostic, the data dispatcher 
must very well be aware of the syntax and the sematics of the data 
flow protocol (see previous discussion on this list on "no-transform & 
warning").

 > The sort of design I might suggest would be that an OPES
 > intermediary maintains an audit of services that are applied,
 > possibly for a limited time.  This audit should be accessible to
 > affected clients using standard features of the protocol whose flow
 > is being OPES-serviced.

Would you say that the current draft rules out such a design? I could 
imagine that the general OPES tracing simply provides pointers and 
information to the endpoints on (a) which OPES services had been 
executed on the message, and (b) how the endpoints could retrieve more 
information about these services, possibly including an audit. I don't 
see the current draft would exclude something like that.

 > Section 3.2 ----------- This touches on an area where I take issue
 > with the IAB requirements on OPES (and have posted my comments
 > elsewhere).
 >
 > [[ The primary data flow occurs between the data provider and the
 > data consumer.  OPES must not interfere with the capability of
 > these parties to use end-to-end authentication and confidentiality.
 >  ]]
 >
 > Consider the case of an employee working for a corporation.  I is
 > the employee or the corporation considered to be the "data
 > provider" or "data consumer" here.  I particular, is OPES required
 > to allow an employee to send encrypted data out of the organization
 > without examination by an intermediary system?

Hm, one view expressed earlier is that the employee is the enduser and 
the corporation runs the OPES system. Per employment agreement, the 
enduser gives the corporation (i.e. the OPES provider) the right to 
filter the data, i.e. the employee allows the corporation to install 
the corresponding OPES rules. That might be controversial, but one 
possible view. An alternative would be to rule out the possibility to 
use OPES for these kinds of services...

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 May 2002 01:24:22 -0400

Ian Cooper wrote:

> the appearance of the data dispatcher box different to the callout 
> servers might help.

Hm, when looking at Figure 3 i nthe draft... I would assume the term 
"callout server" refers to the box itself, thus being the 
correspondence to "data processor", rather than being part of the 
protocol stack as shown in Figure 3. It seems to me that something 
like that would be more accurate.

            data         callout       callout        callout
          processor      server        server         server

         +----------+  +---------+   +---------+     +---------+
         |   data   |  | service |   | servive |     | service |
         |dispatcher|  | applic. |   | applic. |     | applic. |
         +----------+  +---------+   +---------+     +---------+
         |          |  |         |   |         |     |         |
         |   OCP    |  |   OCP   |   |   OCP   | ... |   OCP   |
         |          |  |         |   |         |     |         |
         +----------+  +---------+   +---------+     +---------+
         |  TCP/IP  |  |  TCP/IP |   |  TCP/IP |     |  TCP/IP |
         +----------+  +---------+   +---------+     +---------+
            ||              ||            ||              ||
            ||================            ||     ...      ||
            ||                            ||              ||
            ||==============================              ||
            ||                                            ||
            ================================================

> Seems reasonable, though would only work for a subset of the protocols 
> that might benefit from modifications these systems might offer.  E.g. 
> if video stream is modified I'm not sure that it would be possible to 
> use the streaming delivery protocol to get acccess to the audit trail.  
> It does work for HTTP which was the primary target of this body of work 
> though.

Why restrict it to the standard features of the data flow protocol? I 
would assume it's possible to indicate within the OPES trace HOW an 
endpoint could access such audits, potentially allowing/using other 
standard protocols (e.g. HTTP, FTP, or whatever). Architectural wise, 
this should be covered by the current draft...

> I'm also a little confused as to the apparent urgency to take this 
> document WG (and presumably wider) Last Call when many of the supporting 
> documents appear expired/non-existent in the I-D directory (perhaps it's 
> just the titles that have changed? I thought I had an up-to-date mirror 
> of the directory) making it impossible for the reader to fully 
> understand this document.  (I.E. surely this document is just going to 
> sit in RFC-Editor's queue anyway.)

Marshall already responded on that one, and I fully second his comments.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 May 2002 01:36:13 -0400

Graham,

> When I wrote my comments, I was thinking that there might be HTTP access 
> to the audit trail (with appropriate authentication) from the client 
> system in whose admin domain the OPES intermediary was operating.  That 
> presumes the client knows what URL to use to query the audit, so its not 
> transparent (in the sense of being automatically available), but I think 
> that is information that could easily be made available.

I agree, and it seems to me that Section 2.6 is basically refering to 
someting like that when stating "...One of those annotations could be 
a URL with more detailed information on the transformation that 
occurred to the data on the OPES flow."

-Markus

---

From: Graham Klyne <[email-masked]>
Date: Tue, 21 May 2002 11:37:23 +0100

At 01:00 AM 5/21/02 -0400, Markus Hofmann wrote:
>Wouldn't it be sufficient for OPES to provide trace information that 
>identifies the performed OPES service, and provide a pointer from where an 
>interested endpoint could obtain more detailed information (e.g. the 
>source of customization information for that specific service)?

Yes, that works for me.

>where/how they fit in, but not their (internal) details.

I agree, not their internal details.

But some kind of indication of the scope of possible "conditions" and 
"related actions" would be useful;  e.g. for the conditions, presumably 
there are expected to be mechanisms for testing the protocol parameters and 
data content?  And if examining data content, what sort of level of 
analysis is expected to be supported?

I guess this boils down to identifying some (broad) requirements on the 
standardized rule schema.  At least to the extent of giving some 
understanding of how much is expected to be handled by the filtering rules, 
and how much is left to a callout processor.

>we'll see. Also, our current charter is restricted to HTTP and RTP/RTSP in 
>the data flow.

I thought about this a little more - is it a goal to have multi-vendor 
interoperability between data dispatchers and callout servers?  If so, the 
role of OCP is clearer.

>Would you say that the current draft rules out such a design?

My my reading, yes, since it seems to depend on protocol extensions.

>  I could imagine that the general OPES tracing simply provides pointers 
> and information to the endpoints on (a) which OPES services had been 

As far as it goes, that's fine.  So why are protocol extension headers needed?

(See also my response to Marshall's comment about transparency.)

[later]

Yes, I see you responded too.  Maybe I misread the intent here.
The sentence that disturbs me is this:
[[
The OPES architecture **requires** that tracing be feasible
on the OPES flow per OPES processor **using  in-band annotation** through
header **extensions** on the application protocol that is used (e.g.,
HTTP).
]]

I think the requirement here should be that tracing is feasible *without* 
using extensions on the application protocol.  (Not saying that extensions 
MAY NOT be used, just not required to get at tracing information.)

>Hm, one view expressed earlier is that the employee is the enduser and the 
>corporation runs the OPES system. Per employment agreement, the enduser 
>gives the corporation (i.e. the OPES provider) the right to filter the 
>data, i.e. the employee allows the corporation to install the 
>corresponding OPES rules. That might be controversial, but one possible 
>view. An alternative would be to rule out the possibility to use OPES for 
>these kinds of services...

The first scenario you describe is consistent with my experience of the 
actual deployment of such software.  I think it would be very unfortunate 
if OPES couldn't handle this common case.  However, my reading of the IAB 
requirements didn't allow for that, so I'm thinking that it at least needs 
to be drawn out more clearly.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 May 2002 10:55:42 -0400

Graham Klyne wrote:

> understanding of how much is expected to be handled by the filtering 
> rules, and how much is left to a callout processor.

I agree, but I thought this would rather be part of the "endpoint 
authorization and enforcement requirements" document (which is also on 
our charter) rather than the architecture document.

> interoperability between data dispatchers and callout servers?  If so, 
> the role of OCP is clearer.

Absolutely, yes. Maybe this should be stated.

>>  I could imagine that the general OPES tracing simply provides 
>> pointers and information to the endpoints on (a) which OPES services 
>> had been executed on the message, and (b) how the endpoints could 
>> retrieve more information about these services, possibly including an 
>> audit. I don't see the current draft would exclude something like that.
> 

We somehow need to get these (tracing) pointers to the enduser - and 
one way of doing this is in-band.

> I think the requirement here should be that tracing is feasible 
> *without* using extensions on the application protocol.  (Not saying 
> that extensions MAY NOT be used, just not required to get at tracing 
> information.)

If there's no extensions/addition at all, how would we get the trace 
pointers to the enduser, so that the enduser can retrieve the more 
detailed information fro mthe OPES boxes?

> actual deployment of such software.  I think it would be very 
> unfortunate if OPES couldn't handle this common case.  However, my 
> reading of the IAB requirements didn't allow for that, so I'm thinking 
> that it at least needs to be drawn out more clearly.

Point taken. We need to see what the concensus of the WG is and than 
make a clear case for it.

-Markus

---

From: Graham Klyne <[email-masked]>
Date: Tue, 21 May 2002 20:13:17 +0100

At 10:55 AM 5/21/02 -0400, Markus Hofmann wrote:
>>using extensions on the application protocol.  (Not saying that 
>>extensions MAY NOT be used, just not required to get at tracing information.)
>

The short answer is:  out of band.  In-band would be nice if it could be 
achieved without protocol extensions.

I presume that the OPES intermediary would be communicating with the 
endpoint in whose admin domain it is operating, so some local arrangement 
is not unreasonable.  Returning to my earlier example (ISP web cache), the 
link for tracing information could be provided through a web page that is 
accessed through a login mechanism similar to that used for retrieving mail 
via a web browser.

Note, I'm not saying extensions cannot be used, just that obtaining the 
diagnostics should not depend on the endpoint having implemented such 
extensions.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 May 2002 16:10:02 -0400

Graham Klyne wrote:

> endpoint in whose admin domain it is operating, so some local 
> arrangement is not unreasonable.  Returning to my earlier example (ISP 
> web cache), the link for tracing information could be provided through a 
> web page that is accessed through a login mechanism similar to that used 
> for retrieving mail via a web browser.

What about endpoints that are *not* located within the admin domain of 
the (faulty) OPES system? And how would an endpoint learn about which 
OPES systems have been involved at all?

It's not only the OPES system in the enduser's admin domain that migth 
cause trouble, it might be any OPES system on the way betweem client 
and server. Therefore, the endpoint somehow needs to identify which 
OPES systems the message went through - and this is not static, it can 
be different on a per message basis.

> diagnostics should not depend on the endpoint having implemented such 

Please correct me if I'm wrong, but I think we're in agreement that an 
enduser would retrieve detailed tracing information from an OPES 
system out-of-band, via some standard mechanism (e.g. Web page etc.). 
I.e. there's no need to implement any extensiosn to retrieve the 
detailed tracing info. What remains open, though, is the question (a) 
how the enduser learns which OPES system(s) the message traveled 
through and, therefore, might have to be contacted, and (b) how to 
contact them.

-Markus

---

From: Mark Baker <[email-masked]>
Date: Wed, 22 May 2002 09:37:26 -0400

I just have one major comment ...

As I've stated here before, I can see no reason why "callout" receives
any mention in an architectural document.  Callout is an implementation
detail, where an OPES entity determines that it needs to go elsewhere to
accomplish its task.  Furthermore, not only do I not see a need to 
*identify* a callout protocol, I don't even see a need to standardize on
one.  The important interface is the one between entities, such as that
provided by HTTP, or other transfer protocols.  If you need to "callout"
to a service, give it an HTTP interface and call it an entity.  This is
how things work today with HTTP intermediaries (firewalls, caches,
etc..).

From a practical point of view, this additional hop introduces
unnecessary latency, when that processing could easily be done by the
entity within the flow.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               [email-masked]
http://www.markbaker.ca        http://www.idokorro.com

---

From: Marshall Rose <[email-masked]>
Date: Wed, 22 May 2002 09:18:25 -0700

> how things work today with HTTP intermediaries (firewalls, caches,

mark - the reason that callout is in the architecture is because we standardize a callout protocol. if we didn't care to have the protocol standardized, then you and i are in agreement; however, everyone i talk to in this space tells me that a standardized callout protocol is a real-world requirement. so, there you have it.

/mtr

---

From: Mark Baker <[email-masked]>
Date: Wed, 22 May 2002 13:12:52 -0400

> mark - the reason that callout is in the architecture is because we standardize a callout protocol. if we didn't care to have the protocol standardized, then you and i are in agreement; however, ev…

Thanks, that explains why it's in the document.  I just don't get why
people think one is needed.

If it's "obvious" to so many here, then I'll just save my breath for the
callout requirements gathering phase.

MB

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 22 May 2002 16:09:00 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ian Cooper
> Sent: Monday, May 20, 2002 3:13 PM
> To: OPES Group
> Cc: Oskar Batuner; Markus Hofmann
> Subject: RE: WG Last Call: draft-ietf-opes-architecture-00
>
>
>

> (Apologies if I'm missing something in my jetlag induced haze.)

Well, some practical implications of CDN scenario (or use of OPES
architecture in web server farm):

1. Data producer may delegate signing authority to OPES server;
2. OPES server may respond to any security-related (trace-type)
requests in exactly the same way the data origin would.

More issues with security:

It is not clear how to apply the proposed tracing and integrity
verification mechanisms to truly dynamic data.

Suppose a data producer wants to exploit XML processing abilities of
the latest browsers but still want to serve older browsers with
HTML data. He uses OPES to to perform XML transformation for certain
user-agents. Here original data does not exist at all, nor there is a
"real resource" Ian have mentioned in the previous message.

Use of OPES for filtering also creates a different situation. The data
consumer may have no trust authority at all. Authority belongs to the domain
administrator, who is not present in the data flow and has to
delegate this authority to some proxy - and this may be an OPES proxy.
This breaks the model described in 3.1 were trust is propagated along the
data distribution path. In fact in some cases data consumer may be not a
"primary party" in the draft terminology. The statement "OPES must not
interfere with the capability of these  parties to use end-to-end
authentication and confidentiality" does not work here.

Oskar

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 22 May 2002 16:09:11 -0400

Robin,

I've already sent comments to the initial thread,
sorry, my participation today may be kind of erratic:
ATT Broadband is in the process of another network overhaul,
moving servers and addresses, so my connectivity is
very unstable.

Your message raises one fundamental question: what is the set
of drafts the group is working on? My impression from the architecture
document was that the document set is listed in references, older drafts are
abandoned.

My impression was that the model draft was an initial approach to the
architecture description. Areas covered by these two documents are
very much overlapped. It the model draft has to be revived both documents
should be either released together or even merged.

Can you please summarize - what is the current active document set?

Thanks.

Oskar

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Wed, 22 May 2002 14:39:22 -0600

Dynamic data creation would be evident in the OPES tracing information;
further, the relationship between the request and the returned (created
by OPES) object would be evident.

In the case of the user's perogatives being subverted (errh, subsumed)
by his local administrator, the security viewpoint here is that the
end user has already "delegated" his authority to the local
administrator (color me data consumer), and thus, OPES is not
interfering with any ability that was not previously compromised.
I.e., OPES can avoid interfering but it cannot fix the world.

Hilarie

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 22 May 2002 16:50:25 -0400

Oskar Batuner wrote:

 > Your message raises one fundamental question: what is the set of
 > drafts the group is working on? My impression from the architecture
 > document was that the document set is listed in references, older
 > drafts are abandoned.

The list of docuemnts the WG is working on can be taken from our 
charter at http://www.ietf.org/html.charters/opes-charter.html. At the 
moment, an initial version of the architecture draft is published, 
initial proposals for the scenarios and protocol requirements draft 
are in the works, the other documents to follow.

 > My impression was that the model draft was an initial approach to
 > the architecture description. Areas covered by these two documents
 > are very much overlapped. It the model draft has to be revived both
 > documents should be either released together or even merged.

Your impression is correct, the old models draft is *not* intended to 
become an official WG document, but relevant architectural information 
  should be carried over/considered in the new architecture draft.

-Markus

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 22 May 2002 17:59:37 -0400

> From: The Purple Streak (Hilarie Orman) [mailto:[email-masked]]

> I.e., OPES can avoid interfering but it cannot fix the world.

You are right, but this means OPES should adapt to this imperfect world.

Specifically:

Situation with trust/administrative authority being different from the end
user (in the sense of end point of data reception) is completely valid and
should be explicitly included in the security considerations. This
configuration essentially means that there may be an intermediate point in
the data path that has higher authority than end point. And symmetric
configuration for CDN also moves "ultimate authority point" downstream in
the data flow.

I suggest to change the security model by introducing start of authority and
end of authority points different from the start and the end of data flow.
All the notion of end-to-end should be adjusted to the situation when
dataflow path and authority propagation path are different. This is
different from the proposed model:

----
3.1 Trust Domains

   The delegation of authority starts at either a data consumer or data
   provider and moves to more distant entities in a "stepwise" fashion.
----

These "higher authority" points may specifically limit Tracing/enquiry
abilities of the end user.

On the other hand tracing should support the ability to find the source of
authority.

One more security mechanism to consider in addition to tracing is reporting.
For example the data source may include a request to the end user to report
specific change notifications. Or the end user may (automatically?) report
suspected problems to the source of authority.

Oskar

---

From: John Morris <[email-masked]>
Date: Wed, 22 May 2002 18:22:52 -0400

At 1:12 PM -0400 5/22/02, Mark Baker wrote:
>  > mark - the reason that callout is in the architecture is because 
>we standardize a callout protocol. if we didn't care to have the 
>protocol standardized, then you and i are in agreement; however, 
>everyone i talk to in this space tells me that a standardized 
>callout protocol is a real-world requirement. so, there you have it.
>

I would add an additional reason to address callouts.  As I read it, 
the potential privacy implications of the use of callouts was one of 
the concerns addressed by the IAB.  When the IAB wrote as a 
consideration:

>    (5.1) Privacy: The overall OPES framework must provide for mechanisms
>    for end users to determine the privacy policies of OPES
>    intermediaries.

I think this means that the end user must be able to evaluate the 
privacy policies of any callout entity as well as as any OPES 
dispatcher.  Thus, the OPES architecture needs to anticipate the 
existance of OPES callouts.

John

--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------