Subject: RE: Start on OPES protocol work

From: "Abbie Barbir" <[email-masked]>
Date: Sun, 16 Feb 2003 17:48:34 -0500

hi,

remarks inline.

abbie

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:[email-masked]] 
> Sent: Friday, February 14, 2003 9:59 PM
> To: Barbir, Abbie [CAR:1A00:EXCH]
> Cc: [email-masked]
> 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
> 
> 
> 
> >  > 
> 
>

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 16 Feb 2003 16:41:26 -0700

Thanks for the explanation of what happened to the BOF-era material; my
bookmarks to it no longer work, so it was confusing.  I see that it is
on the new webpage, under "non WG".  It's really a shame, though, that
it wasn't possible to make the ietf-opes.org domain work transparently.
Overall, I think that in a practical sense, interoperability on the Internet
is being badly eroded, but that's a rant for another place.

I see that we already have a draft about using OPES and web services in
that non WG area:
http://standards.nortelnetworks.com/opes/non-wg-doc/draft-rrahman-web-service-00.txt

I think it probably serves as a reasonable starting point for the part of
the discussion, though it seems long on format and short on motivation.
It also seems to be proposing extensions to SOAP in order to provide random
access to message parts.  Is that right - SOAP messages don't normally
use a manifest?

Hilarie