benefits, as with NFV, it comes with associated challenges. 15.2.4.1 Safe Policies With the tremendous power of automation comes risk. A "bad" automation, such as a "bad" control loop, introduced either accidentally or maliciously, could have significant negative impact on net- work and service. In theory, a control loop could do something like shut down the entire network- clearly not a typically desired outcome! We thus need to introduce processes and technologies to minimize the risk of introducing policies that could result in negative outcomes. Security mecha- nisms are of course vital here-we must ensure that only those approved to author policies have access to do SO. We also need to consider how we validate policies-both to ensure that a policy achieves its desired intent, and that it does not have negative side effects or negative interactions with other policies in the system. ONAP's policy framework thus uses a range of techniques to ensure "safe policies"-minimizing the risk associated with introducing policies that have an inad- vertent effect on the outcome of automation. Figure 15.3 illustrates the life cycle of a policy-from its design and authorship through to when it has reached its "end of life." For illustrative purposes here, we consider the example of control loop policies, which specify the events (issues) that are to be detected, and the correlations and actions to be performed in response to the detected events. Policies are designed, authored, and entered into the ONAP platform by service designers and network operators. As a new policy is introduced, it should pass through a series of validations- which may include laboratory testing, simulation, and offline analysis. Once it has passed all of these tests and the policy has been approved for deployment, it is then activated in the field where it runs until it is no longer needed, when it can be deactivated (either removed, or put in a "sleep" mode monitoring the events without taking automated actions). In addition, a new policy may res