RE: Start on OPES protocol work

hi,

remarks inline.

abbie

-----Original Message-----
From: The Purple Streak, Hilarie Orman 
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu] 
Sent: Friday, February 14, 2003 9:59 PM
To: Barbir, Abbie [CAR:1A00:EXCH]
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: Start on OPES protocol work

1. Can you give us a list of pointers to these XML documents? 
 If it is the XML security specs, I believe that is 
well-defined, at least at some useful version level from 
2001.  Is there ongoing work, though?  Who can tell us?


check the xmldsig (RFC 3275), check also http://www.w3.org/Signature/


2. Performance must be considered in detail.  If, at the end, 
the group consensus is to go with XML, it must be an informed 
decision, with the performance impact clearly understood.  I 
assert that web caches will be the baseline systems, and that 
is the only logical place to evaluate performance.


agreed on checking in detail. however, i have a problem with accepting we
caches as a baseline, simply OPES is not a web caching system.

3. We need to have all references to SOAP capabilities backed 
up by references to a spec.  Could someone provide pointers 
to the necessary documents?


see http://www.w3.org/2000/xp/Group/

4. Are there IPR issues wrt to SOAP?


W3C has an Royalty free polic, so there should not be any.

5. I need more detail about how web services can help with 
OPES.  I understand that there are directories, 
query/response protocols, semantics for defining entries in 
the directories, etc.  But can someone elaborate to the next 
level and describe how OPES will use them?


hilarie, i will elaborate later in the week.

6. It looks like the original website that we used during the 
BOF stage has been replaced.  It would be really nice to have 
the contents of that site restored to someplace convenient, 
because there was some excellent information there.  Markus, 
Abbie, have you got the content from the machine Intel used for us?



the new site is hosted by Nortel. I am the web master. it should have about
all the material from the older site.
http://standards.nortelnetworks.com/opes/index.htm

More inline below:

Abbie Barbir, in replying to Hilarie Orman's messages:

 > How can we keep track of this W3C work-in-progress from the
 > IETF vantage point?  I'm not a member of W3C, and I cannot 
 > judge the maturity of their drafts, the likelihood of 
 > standardization of any of the documents.  Can you and others 
 > promise to serve as liasons, keeping us apprised of what's 
 > going on?  Or perhaps there's already someone who does this 
 > for the XML security work, like Don Eastlake.

 I acn do what I can, but a lot of the SOAP security work

is done in

OASIS  and they have a open process (I beilive), where u can get 
access to all the  doc.

 >
 > >  I know off hand that performance issues will be used 
 > aginst adopting 
 > > SOAP.  However, keep in mind that performance is only one 
 > factor and 
 > > it can be  argued that with continous improvments in

CPU speed and

 > > Hardware  acceleration, this will not (or should not)

be a major

 > > issue.
 > 
 > I'm not objecting to examining performance vs. ease-of-use, 
 > but it is important to keep the whole picture in mind.  If a 
 > single CPU with no special hardware enhancements can keep a 2 
 > Gbps line busy, carefully balancing CPU cycles and I/O, then 
 > you have to be very careful about adding extra per packet 
 > processing that multiplies the CPU cycles by a factor of 1000 
 > - this would mean that an organization would need many more 
 > CPU's to do the same job.  So let's be very specific when we 
 > discuss performance and acceleration - the numbers are 
 > important because they determine the cost of the

deployed systems.

 --- abbie

 Before u can do that, we need to know what we are

comapring SOAP to.

I bet you, that whatever protocol will be developed there will be a 
need to  define a structured way of invoking RPC, which

will involve

some form of XML  or metadata.


Not an RPC, and not XML.  Yes, some minimal metadata, but 
probably not on every packet.

First, OPES must be compared to not-OPES.
My performance goal is to have OPES impose only a few 
instructions per packet for packets which do not get OPES 
enhancements.  For those that do get OPES processing, my goal 
is to be close to line speed out-and-back to the callout 
servers.  Of course, this doubles the I/O load; that being 
nearly unavoidable, unless there's a second bus, perhaps I'd 
accept a doubling of the CPU load.

 Even if you ICAP, you still need to know how to find

services and how

to  invoke them, which means some way must be developed to do that. 
Otherwise,  you will be binding the OPES architecture to a group of 
very limitted  services, and you will be forcing the

service provider

to get hooked on one  the services of one vendor.

 > >  There is a lot of work that is being done now on SOAP
 > security that 
 > > can be  very usefull to OPES.
 > 
 > How can we know what that very useful work is?
 >

 ---- abbie

 SOAP security involves header extensions that allow for  
Authorization/Authentication information to be exchaged (including 
info for

ppp>  XML encryption/Sig)

 There are also provision for Policy exchange, Privacy

exchange, Trust

and  routing.

 In SOAP, you can use routing information to state which SOAP Actor 
can be  involved in the data path etc. This help OPES

since, since it

can define  which callout server can be used and it can also define 
what policy to use  etc.. (including privacy info...)


We have to have the spec and an expert in implementation in 
order order to appreciate this.

 > >  For OPES to be usefull, I think it should be able to 
interoperate
 > > with web  services. At the end of the day, OPES provide a 
 > service to 
 > > the data  provider/consumer application.
 > 
 > Can you tell us what it means to interoperate with web 
 > services?  I'm not against it, but I've got only the vaguest 
 > notion of what it might mean for OPES.
 >

 ---- ABBIE
 WHat I mean here, is that the service provider that deploy OPES, 
should be  able to offer services as they become avilable

and as long

as they make good  financial sence. Since off hand you do not know 
what a killer APP is, the  OPES platform should be

extendale, meaning,

the OPES provider should be able  to offer a service at a minimal 
cost. SO if SOAP ids the callout protocol,  and the new

service ids a

web service, implementiung it in OPES is quick and  strighat fwd. 
Otherwise, u need to customise the service at leat at the OPES  end.

 WOrst case secnario, the actual provider of the service

need to TALK

OPES.


What does that mean?

 > >  I know that SOAP has been looked at before by OPES. As a
 > start, do we 
 > > have a  pointer on the previous work, if yes can someone 
 > please advice 
 > > where we can  get it.
 > 
 > My memory of this is that Lee Rafalow was a strong advocate 
 > of looking at SOAP, but there was no work beyond that 
 > advocacy.  Perhaps others have done work since then, but have 
 > not reported it to OPES because we were concentrating only on 
 > the initial documents.  We need to spread the word that we 
 > are now in a new WG phase and it is safe to come back to the 
 > mailing list.
 > 
 > Hilarie

 I have access to that info, but i thought that there was a

talk about

 comparing SOAP, ICAP etc.. that was presented in one of

the BOFs meetings.

Don't remember it, but the original website has been consumed.

 abbie