Page Comparison

...

In order to fulfill our need, we need first the FIRST call to policy to fetch subscriberPolicy for a particular service/scope.

...

Now, say if subscriberName = "subscriber_test_1" which is an instance/request specific data and based on which the corresponding subscriberRole is evaluated. i.e "test user" in this case.
Then, we need a second SECOND call to policy to fetch the affinityPolicy based on subscriberRole evaluated as above.

...

# The legacy way
{
"policyName": "OSDF_CASABLANCA.*",
"configAttributes": {"policyScope": "["vCPE", "INTERNATIONAL", "ip", "vG", "prod user"]"}
}
# Maybe the new decision like this:
{
  "ONAPName": "OOF",
  "ONAPComponent": "OOF-component",
  "ONAPInstance": "OOF-component-instance",
  "action": "optimize",
  "resource": {
      "services": ["vCPE"],
      "geography": ["INTERNATIONAL", "ip"],
      "resources": ["vG"],
      "subscriberRole": ["prod user"] #This is just an assumption here.
}}

Question:

- is there way any possible way out to push the decision making to policy engine, specifically on "which policies apply to a given instance", instead of the two-step fetch and filter process ? Which means the Policy engine would help us find out the first mapping relevant to the context and fetch the policies based on the attribute it bind to. 

...