s policies (e.g., from the repository) to their points of use, in advance of when they are needed. This distribution is intelligent and precise, such that each distributed policy- enabled function automatically receives only the specific policies that match its needs and scope. Notifications or events can be used to communicate links/URLs for policies to components needing policies; so, components can utilize those links to fetch particular policies or groups of policies as needed. Components in some cases may also publish events indicating they need new policies, elic- iting a response with updated links/URLs. Also, in some cases, policies can be given to components indicating they should subscribe to one or more policies; so, they receive updates to those policies automatically as they become available. 7.7.3 POLICY DECISION AND ENFORCEMENT Runtime policy decision and enforcement functionality is a distributed system that can apply to the various ONAP modules in most cases (there could be some exceptions). For example, policy rules for data collection and their frequency are enforced by DCAE data collection functionality. Analytic policy rules, anomalous/abnormal condition identification, and publication of events sig- naling detection of such conditions are enforced by DCAE analytic applications. Policy rules for associated remedial or other action (e.g., further diagnosis) are enforced by the right actor/partici- pant in a control loop (MSO, controller, DCAE, etc.). Policy decision/enforcement functionality generally receives policies in advance, via policy distribution. In some cases, a particular runtime policy engine may be queried in real time for policies/guidance, as indicated in the previous section. Additional unifying mechanisms, meth- ods, and attributes help manage complexity and ensure that policy is not added inefficiently. Attribute values may be defined at creation time. Examples include policy scope attributes, described in the following section ("Policy Unification and Organization"). Note al