This page captures scoping effort for designing the solution for Policy Filtering.
Solution #1 - Add new Filter Guard Policy Type and use in conjunction with existing Blacklist
Pros:
- Quick and easy to build and test with.
- Could solve the majority of the DevOps needs
DESIGN
TODO: List of A&AI queries for CLAMP to use. The queries used by CLAMP must match(?) the Policy Control Loop Custom Query called during runtime.
One filter per Policy
Field: generic-vnf.vnf-id
Value(s): vnf-0000-*
Constraint 
: [equal | regexp | ! equal | anyof | alloff]
Do we support compound fields? AND, OR
Solution #2 - Build a common Monitoring Policy Type for DCAE components to inherit from that captures filtering.
Each analytic would add common SDK to their analytic that enforces the filtering in each analytic.
Pros:
- Ultimate flexibility by DevOps team to place filtering wherever they wish in the Control Loop
- Simple control loops with only a one collector and analytic can be manageable
Cons:
- Must build the SDK and re-factor existing DCAE components to integrate the SDK and ensure it is operating.
- May become difficult to manage if we start adding multiple analytics into the flow. Highly unlikely but possible long term.
Solution #3 - Policy PDPs are scalable and lightweight - they could be positioned strategically in a control loop flow to capture and filter VES events going in/out of analytics
Requires PDP's to support VES events (small work?)
Pros:
- All policy and rule enforcement stays within Policy PDP-D and PDP-X
- Flexible PAP API can move and deploy policies as needed by DevOps team
- No modification to DCAE components to enforce filtering policies