...

Policy Design creates a concrete policy from a policy template. Policy Design is a Design Time framework for ingestion of models for policies and any optional support code, rules, tasks, or flow specifications. Policy Design can consume policy models organically and not require any development work.

Policy Design can occur in several ways during a "design" process. At design time, a service designer and/or operations team can use the models specified on a policy template to express and capture a policy at its highest abstraction level. Alternatively, the logic of the policy can be expressed using a specific policy language if desired.

...

A number of mechanisms for  policy design that are supported in ONAP. The process in the ONAP Policy Framework for generating a concrete policy is the same for all mechanisms. The most general mechanism for creating a concrete policy is using the RESTful Policy Design API, which provides a full interface to the templating and concrete policy generation support of the Policy Framework. This API may be exercised directly using utilities such as curl. The Policy Framework provides a command line tool that is a loose wrapper around the API. It also provides a general purpose client purpose Policy GUI in the ONAP Portal for policy generation, which again is a general purpose wrapper around the Policy Design API. The Policy GUI can interpret any TOSCA Model ingested and flexibly presents a GUI for a user to create policies from.

A number of ONAP components use policy in manners which are specific to their particular needs. The manner in which the policy creation process is triggered and the way in which information required to specialize a policy template is specified and accessed is specialized for these ONAP components.

...

All policies must be certified as being fit for deployment prior to run time deployment. This certification may be performed over the ONAP Policy Framework APIs in the case where other ONAP components such as SDC crete policies. For Policies created directly in the PF, governance of policy certification and testing is supported in the system.

*******

• The Policy GUI Dashboard is created from the ONAP Portal SDK to create a consistent user experience
• The Policy GUI Designer is created from the ONAP SDC SDK to create a consistent user experience

Design Time Capabilities

• Design Time policies should be easy to specify and capture from either the SDC GUI or the Policy GUI
  • High-level Conflict Detection and Resolution tools will be utilized to help identify possible conflicts
• Provide a model-driven Design Time framework for ingestion of models for policies and any optional support code
• Policy Development Environment for designing models and their support code
  
  • Conflict Detection and Resolution for Policies should be available during development and testing phases

1. Policies are easy to specify

Discuss support for SDC.

The platform can consume policy models organically and not require any development work. The Policy GUI should be to interpret any TOSCA Model ingested and flexibly present a GUI for a user to create policies fromDiscuss support for SDC.

Policy Model/Template/Rule Development and Orchestration - Pamela Dragosh 

...

• Policy-core has definitions of the Policy protocols and the interfaces for all the interactions between the policy components. It doesn’t have much functional code, it’s mainly the model of the system and to enforce the overall structure and interactions in the system. Some of the current engine goes in there. Implementation of the protocols is in this modules including the Inter-PDP protocol and the generic parts of the Intra-PDP protocol
• PAP functionality extended to do life cycle monitoring and run time monitoring of PDPs, moves out of engine to separate git repository. The Deployment and Monitoring could be separate modules
• Generic PDP functionality is in a separate PDP module, the current generic PDP functionality moves there and is extended to provide generic model driven PDP support for arbitrary PDPs
• PDP-X specific functionality goes to the PDP-X module
• PDP-D and BRMSGW combined in PDP-D (PDP-D related functions in engine and the current drools-pdp combined)
• The drools-applications module generalized to provide interfaces for all the Policy Framework including arbitrary PDPs towards the other ONAP components in the Policy Interactions module. This must have a mechanism to allow model-driven interactions, in other words define interfaces at run time rather than at design time in Java or JAXB.
• All persistence is In the Policy Persistence module in order to keep persistence nastiness out of the other modules, state from PDPs can be persisted by reading state over the Policy Management Protocol. The Policy Management Protocol could use Distributed Hash Maps to share state with Persistence.
• All PDP implementations specialize the generic interfaces from Policy-core and PDP and can extend the Intra-PDP protocol with PDP-specific support, for example for state and context sharing
• Not much thought gone into the Portal as yet except that it will use REST interfaces for interactions.

...

• REST interfaces for interactions.

4.1 Policy Design Implementation

• The Policy GUI Dashboard is created from the ONAP Portal SDK to create a consistent user experience
• The Policy GUI Designer is created from the ONAP SDC SDK to create a consistent user experience

4.2 Policy Deployment Implementation

...

11. Scope not covered in this document

1. Conflict Detection and Resolution
   1. High-level Conflict Detection and Resolution tools to help identify possible conflicts
   2. Availability of Conflict Detection and Resolution for Policies during development and testing phases