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

From: "Abbie Barbir"<[email-masked]>
Date: Tue, 21 May 2002 13:48:56 -0400

noted,

abbie

> -----Original Message-----
> From: Oskar Batuner [mailto:[email-masked]]
> Sent: Monday, May 20, 2002 5:45 PM
> To: Markus Hofmann; OPES Group
> Subject: RE: WG Last Call: draft-ietf-opes-architecture-00
> 
> 
> 
> 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: "Abbie Barbir"<[email-masked]>
Date: Tue, 21 May 2002 13:48:40 -0400

thanks for the responces,

see remarks inline

abbie

> From: Graham Klyne [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2002 6:37 AM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
> 
SNIP

> > > 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.
> 
> 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.
> 

The purpose of the architecture document is just to mention the rules. The
details need not be part of it. If there is enough interest, the need for an
example document may arise, and then some examples of the rules may be
presented. Here keep in mind, the architecture documnet needed to be focused
and to the point.

SNIP

> >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.
> 

yes, the goal is to have a single OCP that is seperate from the one that is
used 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.
> 
> > > 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?
> 
> My my reading, yes, since it seems to depend on protocol extensions.

agreed.

SNIP

> 
> 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.)
> 

The problem here is that tracing can be in-band or out of band.
in band will require header extensions. Out of band will not, but the
question will be where and by whom it is supported.

The IAB requires the architeture to provide tracing.

SNIP

abbie

---

From: "Abbie Barbir"<[email-masked]>
Date: Tue, 21 May 2002 14:03:51 -0400

see remarks inline

abbie

> Sent: Monday, May 20, 2002 5:47 AM
> To: Markus Hofmann
> Cc: OPES Group; Allison Mankin; Ned Freed
 SNIP

> 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.
> 

here, i agree with Markus comments, basically, it is sufficient for OPES to
provide trace 
information that identifies the performed OPES service.

> 
> 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".
> 
> 

No, this will be clarified in the text.

> 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 responsible for invoking (for the lack of a better
work) the opes application service. if this is not clear in the text, then
we should revisit it.

> 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..."
> 

zero means regular data flow, so we will revisit this one.

> 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?
> 

no

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

and i see no problem with that. this document is not a rule specification
document.

> 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?
> 
yes, we will address it.

> You also discuss using "the OPES callout protocol", which 
> seems to say 
> there is a single such protocol.  

yes,

SNIP

> 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.
> 

disagree, if you have followed the discussion and debate on these issues you
would have noted that traceability is intended for the qualified user and
not the general purpose user.
The objective here is to allow a qualified administrator to trace what
happended to the data when the end user gets errors.

> 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 
...
SNIP

see previous remark. 

SNIP

abbie

---

From: "Abbie Barbir"<[email-masked]>
Date: Tue, 21 May 2002 15:33:03 -0400

see inline,

> Sent: Tuesday, May 21, 2002 3:21 PM
> To: Barbir, Abbie [CAR:1A00:EXCH]
> Cc: OPES Group
SNIP

> In which case, I don't think that's an adequate level of tracing 
> capability.  That is, I don't think it fully addresses the 
> spirit of the 
> IAB requirements.
> 
> I refer you to the example I mentioned, of a problem with an ISP's 
> transparent caching.  I don't think it's acceptable that only 
> the ISP's 
> administrator can find out what happened, because in practice 
> the ISP won't 
> bother and will spin some lie about it being (say) a browser problem.
> 
> I think it's crucial to put diagnostic capability in the hands of the 
> endpoint on whose behalf (authority) the service is being 
> performed.  (Even 
> if the endpoint isn't given any choice about having the service.)
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <[email-masked]>
> 
> 

This is why header extensions may be needed. simply keeping a log will
suffer from the same problems that u mention plus it does not scale.

abbie

---

From: "Abbie Barbir"<[email-masked]>
Date: Tue, 21 May 2002 15:50:19 -0400

so,

there is no major diagreement.
the architecture talks about out-of band.

abbie

> Sent: Tuesday, May 21, 2002 3:13 PM
> To: Markus Hofmann
> Cc: OPES Group
> 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.)
> >
> >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?
> 
> 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: "Abbie Barbir"<[email-masked]>
Date: Tue, 21 May 2002 16:08:14 -0400

Amen,

abbie

> From: The Purple Streak (Hilarie Orman) [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2002 3:51 PM
> To: OPES Group
> Tracing is meant for the end system user as well as qualified
> administrators.  Just like email headers.  I run a mailing
> list that uses three separate methods of including "unsubscribe"
> information in every message.  Still, for some combinations of
> mail agent and message, the enduser cannot see the information.
> They send haughty email to the list administrator complaining
> about how defective the list is.  OPES tracing will have similar
> benefits and deficiencies in practice.  The inband method means
> that the user will always have information stored locally and
> will always be able to show it to someone else, but there is no
> way to guarantee that all users will always have enough clues to
> use it.  Just like anything else having to do with the Internet,
> computers, or motorcycles (don't ask).
> 
> Hilarie
> 
>

---

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 22 May 2002 17:22:45 -0700

some comments inline..which might have already being discussed, but I'm
starting to read the thread now...

>From: Ian Cooper [mailto:[email-masked]]
>Sent: Monday, May 20, 2002 12:13 PM
>To: OPES Group
>Cc: Oskar Batuner; Markus Hofmann
>--On Monday, May 20, 2002 13:28 -0400 Oskar Batuner 
><[email-masked]> 
>wrote:
>
>>
>> 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.
>
>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.

concrete examples would be on the scenarios document. I'm not sure an
architecture document should have examples. Maybe the best way is just to
reference the scenarios document.

>
>> 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".
>
>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.
>
>>> 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

I have a problem with this picture since the OPES Service application and
data dispatcher are not in the "protocol stack per se". They do talk to each
other internally but not with outside entities, as shown in the proposed
diagran below. Maybe what we need is to replace the word stack by "logical
implementation" or something the like.

>>
>>
>> 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.
>
>Agree
>
>> 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.
>
>I like this diagram
>

---

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 22 May 2002 17:31:07 -0700

more comments inline..

>Sent: Monday, May 20, 2002 12:18 PM
>To: Marshall Rose
>Cc: [email-masked]

<snip>....<snip>....<snip>

>
>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.)

Taking the "Internet Scale" discussion of the table, I kind of agree with
that. We had several discussions about this. My concern with headers
extensions is that we would need to do that for every single protocol that
OPES might use, which might slow down OPES adoption. Not only from an
implementation perspective but also that all these extensions would need to
go throught the IETF ptocess, sometimes spanning more than one working
group.

But the crux of the question then is, as you put it, how to convey this
information to end user in a way that with off the shelf software he can
check the audit trail. With HTTP would that be a Redirect? With email, would
that be a mime/multipart as you put it? And how about RTP, FTP, etc?

---

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 22 May 2002 17:45:28 -0700

more comments...

>From: Markus Hofmann [mailto:[email-masked]]
>Sent: Monday, May 20, 2002 10:24 PM
>To: Ian Cooper
>Cc: OPES Group
>Ian Cooper wrote:
>> 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.
>
>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 |
>         +----------+  +---------+   +---------+     +---------+
>            ||              ||            ||              ||
>            ||================            ||     ...      ||
>            ||                            ||              ||
>            ||==============================              ||
>            ||                                            ||
>            ================================================
>
>

yep, the same we did for the picture. The "upper entities" are not part of
the stack per se

>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.
>> 
>> 
>> 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 agree with that. Keeping up state in the OPES intermidiary it might sound
good on paper but I'm not sure it will scale. It would be the same thing to
ask a web server to be able to read through recent log files in order to
provide this information to any user real time.

>
>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...
>

So, I kind of agree on what was proposed of conveying this info through
alrady avalable means, but keeping state is touchy. Just like email, you get
all the headers, now if the SMTP servers on the way, keep ot not that
information is up to the administrator. 

-Reinaldo

---

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 22 May 2002 17:56:20 -0700

yep, seems reasonable.

We convey some information, but we surely cannot guarantee that we are going
to keep state around waiting for some user to query it. This is definitely
an implementation (or should I say administrator decision).

And as Markus pointed previously, although in an email you get the headers,
you surely cannot query a server in another domain/AS/whatver.

-Reinaldo

>Sent: Tuesday, May 21, 2002 12:51 PM
>To: OPES Group