DETAILED DESCRIPTION:
This recommendation is the result of comments 
received during our investigations.  Steve Weitzeil 
requested this be entered in Remedy so it can be 
scheduled and tracked.

Problem to be solved:  Often it is necessary to 
limit the scope of the objects and events a driver 
processes.
Possible solution:  The current DirXML filter limits 
the objects and attributes a driver's policies and 
shim have to deal with.  This request is to extend 
the filtering concept.  The extension would be to 
also specify the scope of objects to be allowed 
through the filter.  There are two proposed scoping 
methods.  Both should be implemented.  1) by 
container, let the admin browse and select the 
containers of interest to this driver葉he driver 
will only receive events for objects in these 
containers,  2) let the admin specify a filter 
predicate, for example, an LDAP query or something 
like a dynamic group.  The driver will only be 
presented with events that pass the predicate.  A 
use-case would be load balancing.  This 
functionality can be done through policies but it 
would reduce complexity, implementation time, and 
processing time if it was provided by DirXML.

NOTES:
tsanders (  11/30/2004 9:23:46 AM  Fixing - Approved 
for Investigation ) Nate, this is something to 
consider as you develop DirXML Script for Designer.
 
svella (  11/23/2004 3:54:37 PM  Fixing - New ) I 
already went down the design and prototyping of 
adding explicit scope filtering to the engine that 
was separate from policies and rapidly came to the 
conclusion that there was little point to it since 
it is very easily accomplished in DirXML Script. and 
in order to be flexible enough to be useful for the 
general case it needs just about the complete set of 
conditions implemented by DirXML Script. It appears 
that the primary problem that people have with scope 
filtering via DirXML Script is that they don't know 
where to go in the UI to do it and even if they know 
where to go they don't know what to do with the 
clean slate that is presented to them. As such there 
are many things that can be done in the UI to 
alleviate this problem, some of which I believe are 
part of the long term plan for Designer. Some of 
these would be:

1. Task oriented help
2. Task oriented wizards - could be as simple as 
load up a template DirXML-Script Policy and leave 
them in Policy Builder with the edit field or 
chooser where they would pick the scope.
3. Driver imports that create a scope filter based 
on the scope information that most of them already 
prompt for but only use for the placement and 
matching rules.

In summary, I don't think the engine needs any 
enhancement in this area, but there definitely 
should be some work done in this area. 
jwootton (  11/23/2004 3:07:03 PM  Fixing - Under 
Investigation ) Reassigned to Shon Vella.  Shon, 
if/when support for this is implemented in the 
engine please reassign this defect back to me so I 
can change the ui.
 
drfoster (  7/6/2004 8:19:00 AM  Fixing - Under 
Investigation ) I think this goes more with the 
filtering feature. 

dwholbrook (  6/14/2004 12:11:32 PM  Fixing - 
Info/Resources Required ) This additional 
functionality should be added with a UI wizard.
 
tsanders (  6/3/2004 9:42:56 AM  Fixing - 
Info/Resources Required ) Please explain what you 
mean?  What exactly does the customer want?


BUILD NUMBER: 
Oses/CONFIG: 
STEPS TO REPRO: 
RESULTS:
EXPECTED: 
WORKAROUNDS: 
CUSTOMER IMPACT: 


NTS entered defects should also include:
Additional debug info like screenshots, screencams, 
log files, trace files,
packet traces, memory coredump location.
Accurate customer information so that proper 
prioritizing of the defect is
possible (mainly for NTS defects)