RE: Bug 4558: Scalability and performance problems with expressing allowable nested policy assertions

Confused?  How so?  I believe this changes the design of matching.  And
I think the "intent" is that by design of ws-addressing assertions it
does match.

Cheers,
Dave

> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
> Sent: Wednesday, May 16, 2007 8:46 AM
> To: David Orchard; Ashok Malhotra; public-ws-policy@w3.org
> Subject: Re: Bug 4558: Scalability and performance problems 
> with expressing allowable nested policy assertions
> 
> Hi Dave
> 
> I'm confused :-). WSAddressing empty nested <Policy> does not 
> match the more qualified WSA nested Policy by design, but 
> this suggestion will make it match in a generic fashion even 
> though by design it can't match...
> 
> Cheers, Sergey
> 
> ----- Original Message -----
> From: "David Orchard" <dorchard@bea.com>
> To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>; "Ashok 
> Malhotra" <ashok.malhotra@oracle.com>; <public-ws-policy@w3.org>
> Sent: Wednesday, May 16, 2007 4:37 PM
> Subject: RE: Bug 4558: Scalability and performance problems 
> with expressing allowable nested policy assertions
> 
> 
> It's exactly intended to solve that kind of use case.  The caveat is
> that I'm not sure how much of a performance/scalability 
> problem there is
> with WS-Addressing...
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> > Sent: Wednesday, May 16, 2007 5:05 AM
> > To: Ashok Malhotra; David Orchard; public-ws-policy@w3.org
> > Subject: Re: Bug 4558: Scalability and performance problems
> > with expressing allowable nested policy assertions
> >
> > Hi
> >
> > Will it work with the WSAddressing nested <Policy> and say
> > <Policy><NoNAnonymousResponse/></Policy> ?
> >
> > The above two nesetd policies don't intersect, but if either
> > of the options below is used then the above options will
> > intersect...unless I'm missing something
> >
> > Cheers, Sergey
> >
> >
> > ----- Original Message -----
> > From: "Ashok Malhotra" <ashok.malhotra@oracle.com>
> > To: "David Orchard" <dorchard@bea.com>; <public-ws-policy@w3.org>
> > Sent: Wednesday, May 16, 2007 12:53 PM
> > Subject: RE: Bug 4558: Scalability and performance problems
> > with expressing allowable nested policy assertions
> >
> >
> >
> > +1
> >
> > All the best, Ashok
> >
> > > -----Original Message-----
> > > From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> > > request@w3.org] On Behalf Of David Orchard
> > > Sent: Tuesday, May 15, 2007 5:26 PM
> > > To: public-ws-policy@w3.org
> > > Subject: Bug 4558: Scalability and performance problems
> > with expressing
> > > allowable nested policy assertions
> > >
> > >
> > > The policy intersection algorithm results in policy 
> assertions with
> > > nesting to
> > > be verbosely expressed with all of the possible nested
> > assertions marked
> > > as
> > > optional="true".  One example of this is SecurityPolicy with X509,
> > > detailed in
> > >
> > http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0
> > 160.html.
> > >
> > >
> > > The scalability problem is that it may be difficult to list
> > and exchange
> > > all
> > > the possible nested assertions.  The performance problem is
> > that such a
> > > scale
> > > may result in slow policy processers performing intersection.
> > >
> > > One counter-arguments are that the number of nested
> > assertions is not
> > > large
> > > enough to warrant this optimization, and that the
> > optimization of adding
> > > optional="true" is sufficient.  The general argument of premature
> > > optimization
> > > applies.  This would be a close with no action or defer to v.Next.
> > >
> > > Proposal 1:
> > > Update the policy intersection algorithm so that an empty policy
> > > assertion
> > > matches a policy assertion with a nested assertion
> > resulting an the same
> > > policy
> > > assertion with a nested assertion.
> > >
> > > Proposal 2:
> > > Provide an explicit wildcard to match any nested assertions.
> > >
> >
> >
> > 
> 
>

Received on Wednesday, 16 May 2007 15:50:28 UTC