Subject: RE: Draft Agenda for IETF 56

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 11 Mar 2003 10:13:13 -0500

Jfcm,

good points. The discussion really affect the consideration if we should
adopt SOAP or not.

I do think that TCP is needed. TCP provides many faetures that we need (that
is for the callout protocol).

Abbie

> -----Original Message-----
> From: jfcm [mailto:[email-masked]] 
> Sent: Monday, March 10, 2003 10:14 AM
> To: Markus Hofmann; OPES Group
> Subject: Re: Draft Agenda for IETF 56
> 
> 
> My main question is about the entry and the ending points of the OPES 
> concept. If it is accepted that  not only HTTP but any 
> protocol is OK, and 
> that alternatively both end points can be user/producer or 
> that we may have 
> a peer to peer support, it will mean that any entry/output 
> protocol is OK, 
> including a keyboard/user file/application etc, towards a 
> screen, a file, etc.
> 
> This means there is no pseudo-synchoronous (like in hhtp) 
> obligation (or as 
> options).
> This means that we have a general purpose concept of a 
> filter/transformer 
> system on a flow.
> Which will standardize everywhere.
> 
> This means that, the filter/transformer relation (callout 
> protocol) can be 
> anything from realtime to soap. Am I correct? Because this 
> means that we 
> will  have a good general framework for a protected/acked 
> balanced protocol 
> able to support one to many or even many to many relations.
> 
> Then the next question will be: will it always be under TCP? jfc
> 
> 
> At 13:02 10/03/03, Markus Hofmann wrote:
> >we want to continue the lively discussion on the mailing list at the 
> >IETF
> >56 meeting in San Francisco next week.
> >
> >We intend to spend a few minutes provding a quick update on 
> the status 
> >of
> >our five submitted WG documents, and then go immediatelly 
> over to the OPES 
> >prototol work. Focus will be on resolving the higher-level issues, 
> >starting with a discussion of major decision points for 
> protocol design 
> >and of the "protocol pre-draft" throughts. We will cover 
> further topics 
> >under "general discussion".
> >
> >If you've topics to be dicussed under "general discussion" 
> and would be
> >interested to present in San Francisco, please send Marshall 
> and myself a 
> >note ASAP.
> >
> >Thanks,
> >   Markus
> >
> >-----------------------------------------------------
> >
> >Open Pluggable Edge Services WG (opes) 
> >======================================
> >Monday, March 17, 1530-1730
> >
> >CHAIR(S):
> >    Marshall Rose <[email-masked]>
> >    Markus Hofmann <[email-masked]>
> >
> >TECHNICAL ADVISOR(S):
> >    Allison Mankin <[email-masked]>
> >    Hilarie Orman <[email-masked]>
> >
> >AGENDA:
> >    - Introduction, minutes taker, blue sheets
> >    - Agenda bashing
> >    - Status of WG documents
> >        draft-ietf-opes-architecture-04
> >        draft-ietf-opes-protocol-reqs-03
> >        draft-ietf-opes-scenarios-01
> >        draft-ietf-opes-authorization-02
> >        draft-ietf-opes-threats-02
> >    - Start on OPES protocol work
> >      - Introduction
> >      - Major decision points for protocol design
> >      - OPES protocol pre-draft thoughts
> >      - General discussion
> >
> >
> >
> >
> >
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03
>

---

From: jfcm <[email-masked]>
Date: Tue, 11 Mar 2003 18:50:13 +0100

At 16:13 11/03/03, Abbie Barbir wrote:
>I do think that TCP is needed. TCP provides many faetures that we need 
>(that is for the callout protocol).

Certainly. What I mean is that dependng on the where, speed, security, 
interactivity, there may be many ways to implement the OPES protocl. I 
suppose that IP will be used in most of the cases - not sure  as it would 
fit well under a qnet (QNX) system. So the envelopes could be very 
different while the relation process between dispatchers and servers could 
be the same.
jfc

> > From: jfcm [<mailto:[email-masked]>mailto:[email-masked]]
> > >Checked by AVG anti-virus system 
> (<http://www.grisoft.com>http://www.grisoft.com).

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 12 Mar 2003 09:06:27 -0500

hi,
 
it sounds like a plan.
 
abbie

-----Original Message-----
From: jfcm [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2003 9:01 AM
To: [email-masked]
Subject: RE: Draft Agenda for IETF 56

This was my initial point. We are asked to build a bicycle. We see that we
can also build a car. Let avoid building an Harley Davidson everyone will
enjoy but no one will use.

1. let build the bicycle
2. in keeping in mind what could be reused from a car production later on,
so we keep consistent.

This is why I think we should do as you say: http. The real project I would
propose would be a redirect system upon decision of a server (I have a real
need :-). I suppose that if a few ones could have in mind a similar
application, we could confront with real life examples.

Then we could list every time there is a decision how it would work with
other entry systems and other callout protocol transport solution. Choosing
the simplest transport solution to implement (may be local interaction?) for
that part, so we can test quickly and exchange code?

Then may be we could check SMTP to be sure it works well in a different
model? 
jfc

On 12:39 12/03/03, Abbie Barbir said:

Hi all, 

This discussions are really getting interesting. 

However, it seems to be that we should fundemantely agree on the deployment
(where, what and for what) of OPES in the services area.

The discussions give me the feeling that we are trying to design a (very
flexible) system that is looking for a place in the field.

I could see the benefits to have various bindings for the callout protocol.
It gives felexibility. But at what expense? I really have problems
developing an architecture/protocols that can go all over the field.

The architecture document states that the example protocol is HTTP. I know
that we should be open minded in the design of the callout protocol.

However, I would like to start with HTTP and then come up with a callout
protocol that can work with it. After that, I would like to see how we
address all of the IAB issues regarding OPES. We can then move the excerise
to RTP (SRTP etc..), and use that knowledge to ensure that we have a
flexible protocol.

At this point, the issues of notification/tracing have not been brought up
(yet?). 

Abbie 

> From: Alex Rousskov [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, March 12, 2003 12:24 AM 
> To: OPES Group 
> On Tue, 11 Mar 2003, Markus Hofmann wrote: 
> 
> > General question now is whethr we feel that coupling the transport 
> > protocol for the callout to the application message protocol is 
> > flexible enough, or whether we need more flexibility? 
> > 
> > For example, is it OK to assume that whenever the 
> application message 
> > protocol is A, that the transport protocol for the callout 
> is B. Or is 
> > there a case to make that for the same message protocol A, we 
> > sometimes need to use transport protocol B for the callout, and 
> > sometimes transport protocol C (substitute A, B, and C with your 
> > favorite protocols :) If so, how is this achieved without protocol 
> > negotiation? 
> 
> I was not on that conference call so I may be missing some 
> important caveats. Said that, it seems to me that we should 
> not care about the ways transport protocols are selected as 
> long as we do not have to support true negotiations. In most 
> cases, protocol selection can be handled by static 
> configurations (with rules if needed), and should be out of 
> our current scope. 
> 
> No need to limit the selection/matching rules; just prohibit 
> in-protocol negotiations. Let implementations decide what is 
> the right protocol selection method is. 
> 
> $0.02, 
> 
> Alex. 
> 

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com
<http://www.grisoft.com/> ).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 12 Mar 2003 09:05:34 -0500

Markus,

it all do with HTTP extension etc.
I will detail later,

abbie

> From: Markus Hofmann [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 8:28 AM
> To: OPES Group
> Abbie Barbir wrote:
> > At this point, the issues of notification/tracing have not been 
> > brought up (yet?).
> 
> Absolutley correct and an important point!! Is there anything me must 
> consider in the callout protocl design for tracing and 
> notification? I 
> would assume so... Any thoughts?
> 
> While probably separate from the callout protocol design, we 
> also need 
> to discuss possible impact on the application message protocol, for 
> example for an "OPES bypass" mechanism. This refers to the 
> requirement 
> that a user must be able to signal an OPES processor that (s)he wants 
> to bypass any OPES service (one of the IAB requirements)  - 
> as briefly 
> discussed some time earlier, using (user-defined?) HTTP headers might 
> be an option.... So we also need to consider possible 
> impact/extensions on the application message protocol. Anyone some 
> thoughts on this one?
> 
> -Markus
> 
> 
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 12 Mar 2003 08:52:33 -0800

> Sent: Wednesday, March 12, 2003 11:33 AM
> To: OPES Group
> Reinaldo Penno wrote:
> > I guess there are two approaches here:
> > 
> > 1) Making extensions for every single application protocol 
> that might 
> > use OPES.
> >   ...Although some people that in realitly we will have 
> maybe 4 (HTTP, 
> > RTP, SMTP, FTP).
> 
> Just a reminder - although we've a SHOULD requirement that 
> states that 
> our solutions should be protocol agnostic (and I think we all 
> agree on 
> that), our charter is focused on HTTP (and RTP, although we 
> agreed the 
> main focus being on HTTP).

Yes, I was pointing out some issues that could influence the protocol choice
(in vs out of band). Although we can make HTTP work, it *might* be waste of
cycles if we foresee the use of other protocols in the future and
using/designing a general out of band protocol is not that much extra
effort.

This is the kind of tradeoffs we should discuss before actually making a
choice of in vs out of band. And I agree we should discuss
functionality/requirements wihthout a specific solution in mind.

> 
> > 2) Developing an out of band protocol to signal such preferences. 
> > That's why I said in the past looking at NSIS could be 
> interesting if 
> > we feel the list in 1) is already big/complicated enough or might 
> > grow.
> > 
> > There is also the practical uses of either approaches. Certainly, 
> > negotiating with the OPES processor what will/not receive treatment 
> > every single HTTP session could add a lot of overhead. 
> Although HTTP 
> > could be used to negotiate, I guess we should have 
> provisions to say 
> > "bypass OPES for all HTTP sessions, until I say otherwise", or 
> > vice-versa.
> 
> I'd suggest we go down a similar path as we currently do with the 
> callout protocol, namely discussing required functionality 
> and general 
> design issues, first (rather than starting to discuss how and 
> in which 
> specific form to do it). I.e. what exactly do we need to signal (one 
> example is the "OPES bypass"), what are the interaction schemes, what 
> needs to be signaled, etc. Then we can discuss what's the best way to 
> do this (e.g. "in-band" vs. "out-of-band") etc. [Note: Just to avoid 
> confustion - this is *not* about the callout protocol, this is about 
> the application protocl path).
> 
> Maybe Abbie and Reinaldo you want to take a first shot, since 
> you seem 
> to look at this from slightly different perspectives. Of course, 
> anyone else should feel free to take a first step as well...

Okay. Abbie and I will take a first shot on this...

---

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 12 Mar 2003 12:53:56 -0500

Hi,

sorry, sick today, just came back from doctor.

good thread, however, the good thing here is the start of the work by alex
on determining the traceability/notification requirements.

My opinion at this stage, is that let us get it right starting with HTTP and
then determine how it relates to the other protocols.

thanks

abbie

> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 12:33 PM
> To: OPES Group
> On Wed, 12 Mar 2003, Markus Hofmann wrote:
> 
> > our solutions should be protocol agnostic (and I think we 
> all agree on 
> What it means to me is that:
> 	- we MUST support HTTP as an application protocol
> 	- we SHOULD support more than just HTTP
> 	- in case of a specific design conflict, HTTP-arguments MAY
> 	  have higher priority than arguments for other application
> 	  protocols
> 
> The above is different from
> 	- we MUST support HTTP as an application protocol
> 	- we MUST NOT consider other application protocols
> 	  until HTTP is supported
> 	- we SHOULD check other application protocols
> 	  after HTTP is supported
> 
> > design issues, first (rather than starting to discuss how 
> and in which 
> > do this (e.g. "in-band" vs.
> > "out-of-band") etc.
> 
> I, obviously, agree.
> 
> > [Note: Just to avoid confustion - this is *not* about the callout 
> > protocol, this is about the application protocl path).
> 
> There is some interaction between the two though. For 
> example, we need to decide whether the callout server or OPES 
> dispatcher/processor is responsible for tracing (could be 
> both too!). If callout server is responsible, then the 
> callout protocol may have to provide appropriate support, 
> especially if we decide to use out-of-bound (#2) approach.
> 
> Hmm... The latter actually demonstrates another weakness of 
> the out-of-bound approach: it makes it difficult for callout 
> servers to participate in tracing and similar activities 
> because the "end" is not talking to them but to the proxy. On 
> the other hand, maybe this is a sign that callout servers 
> must not participate?
> 
> Alex.
> 
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 12 Mar 2003 09:55:46 -0800

> the other hand, maybe this is a sign that callout servers 

Independent of in vs out of band, IMO the end points always talk to the OPES
processor. The OPES processor will use whatever means necessary to perform
the requested services, including use of a callout server. You might even
use a callout server for a certain service only if your CPU is above a
certain watermark, so there is no pre-established behaviour of what the OPES
processor will do to honor the request.

Whatever tracing messages the callout might include on the message, the OPES
processor can easily relay them to the end points with its own tracing.

[],

---

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 12 Mar 2003 13:18:30 -0500

-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH] 
Sent: Wednesday, March 12, 2003 12:56 PM
To: 'Alex Rousskov'; OPES Group
Subject: RE: Draft Agenda for IETF 56

 SNIP  

 SNIP 

I fully agree.

Abbie

---

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 13 Mar 2003 06:13:23 -0500

hi,
see inline,

Abbie

> Sent: Thursday, March 13, 2003 12:47 AM
> To: OPES Group

SNIP

> Do you agree that users may have service-specific (not just OPES
> box-specific) preferences? Or do we provide tracing without 
> any OPES-specific way to use the information?
> 
> Thanks,
> 
> Alex.
> 

Alex, 

I agree that users may have service-specific preferences. How these will be
indicated. (Are we going to have the concept of a session, are the OPES
rules static per session (for a user), can we have dynamic rules, etc..). If
OPES is used as a personalization engine (please see
http://www.ietf.org/internet-drafts/draft-barbir-opes-fsp-03.txt,
http://www.ietf.org/internet-drafts/draft-barbir-opes-spcs-03.txt) dynamic
rules will be needed. Dynamic can mean that a subset of the overall rules
can be assigned to a given OPES Flow at a given time (per user basically).

In some scenarios the OPES providers can provide the service as a package,
then the user may only have access to the package as a whole. 

Abbie

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Mar 2003 08:55:54 -0800

> Sent: Thursday, March 13, 2003 11:29 AM
> To: OPES Group
> On Thu, 13 Mar 2003, Reinaldo wrote:
> 
> > it's a black box in regards of the services it provides, not the 
> > tracing/events. Everytime you access a web page you do not 
> get a list 
> > of all the routers in your path.
> 
> Actually, I do from HTTP point of view! I get a list of all 
> proxies in the Via: header.

Only if you are addressing it directly, and that's the point of the
discussion. 

> 
> > But you can use a traceroute or maybe get an ICMP type/code back to 
> > let you know of some error.
> 
> That does not count for many reasons. For example, the 
> traceroute output may have nothing to do with how my HTTP 
> transaction was routed. This is not only out-of-band, but is 
> also out-of-sync.
> 
> 
> But this is just a minor terminology disagreement. This 
> thread has clarified that we do expect individual services to 
> be traceable and that we may want ends to be able to bypass 
> them. The latter is not required for a fully functional OPES 
> system though.
> 
> Alex.
> 
>