, constraints regarding where to place VNFs VNF change management-for example, how software rollouts should be scheduled across VNFs and what health checks should be performed to validate changes 3. Management of the behavior of ONAP components-for example, how and when ONAP should collect data, and how long ONAP should retain that data ONAP's policy framework consists of the following modules (shown in Figure 7.10): 1. Policy creation: Enables policies to be specified by services designers and network opera- tors via a user interface and APIs 2. Policy evaluation: Evaluates/executes applicable policies reactively (responds to a query) and proactively (evaluates a policy and triggers actions) 3. Policy decision distribution: Distributes policy decisions to be enforced in distributed pol- icy elements adjacent to other ONAP components 4. Policy validation: Validates policies, designed to minimize the risk of introducing bad policies into ONAP There are many policy engine technologies in the industry, addressing different types of poli- cies. For example, Extensible Access Control Markup Language (XACML) enables access control, Models/ UI's (e.g., Dashboard Templates Editors) Policy Language / Intermediate Representation Decomposition Translation Distribution PDP (e.g., PDP, 2 (e.g., Congress Drools) XACML) FIGURE 7.10 ONAP policy component framework. The Network Operating System while Drools supports the construction, maintenance, and enforcement of business policies. Given the diversity of ONAP's policy needs, the ONAP policy framework uses multiple policy engines. However, supporting various policy engines requires these policies be decomposed and distributed from the common policy creation layer to the different policy engines, providing translation to the policy engine-specific languages along the way. ONAP's advanced automation facilitates operational efficiencies and faster and more consistent responses to network and service conditions. However, with automation comes risk. The policy framework thus uses a r