+* APEX supports multiple policy deployment in Frankfurt.
+ - Up through El Alto APEX-PDP had the capability to take in only a single ToscaPolicy. When PAP sends a list of Tosca Policies in PdpUpdate, only the first one is taken and only that single Policy is deployed in APEX. This is fixed in Frankfurt. Now, APEX can deploy a list of Tosca Policies altogether into the engine.
+
+ - Note: There shouldn’t be any duplicates in the deployed policies (for e.g. same input/output parameter names, or same event/task names etc).
+
+ - For example, when 3 policies are deployed and one has duplicates, say same input/task or any such concept is used in the 2nd and 3rd policy, then APEX-PDP ignores the 3rd policy and executes only the 1st and 2nd policies. APEX-PDP also respond back to PAP with the message saying that “only Policy 1 and 2 are deployed. Others failed due to duplicate concept”.
+
+* Context retainment during policy upgrade.
+ - In APEX-PDP, context is referred by the apex concept ‘contextAlbum’. When there is no major version change in the upgraded policy to be deployed, the existing context of the currently running policy is retained. When the upgraded policy starts running, it will have access to this context as well.
+
+ - For example, Policy A v1.1 is currently deployed to APEX. It has a contextAlbum named HeartbeatContext and heartbeats are currently added to the HeartbeatContext based on events coming in to the policy execution. Now, when Policy A v1.2 (with some other changes and same HeartbeatContext) is deployed, Policy Av1.1 is replaced by Policy A1.2 in the APEX engine, but the content in HeartbeatContext is retained for Policy A1.2.
+
+* APEX-PDP now specifies which PdpGroup it belongs to.
+ - Up through El Alto, PAP assigned each PDP to a PDP group based on the supportedPolicyTypes it sends in the heartbeat. But in Frankfurt, each PDP comes up saying which PdpGroup they belong to, and this is sent to PAP in the heartbeat. PAP then registers the PDP the PdpGroup specified by the PDP. If no group name is specified like this, then PAP assigns the PDP to defaultGroup by default. SupportedPolicyTypes are not sent to PAP by the PDP now.
+
+ - In APEX-PDP, this can be specified in the startup config file(OnapPfConfig.json). "pdpGroup": "<groupName>" is added under “pdpStatusParameters” in the config file.
+
+* APEX-PDP now sends PdpStatistics data in heartbeat.
+ - Apex now sends the PdpStatistics data in every heartbeat sent to PAP. PAP saves this data to the database, and this statistics data can be accessed from the monitoring GUI.
+
+* Removed “content” section from ToscaPolicy properties in APEX.
+ - Up through El Alto, APEX specific policy information was placed under properties|content in ToscaPolicy. Avoid placing under "content" and keep the information directly under properties. So, the ToscaPolicy structure will have apex specific policy information in properties|engineServiceParameters, properties|eventInputParameters, properties|eventOutputParameters.
+
+* Passing parameters from ApexConfig to policy logic.
+ - TaskParameters can be used to pass parameters from ApexConfig to the policy logic. Consider a scenario where from CLAMP, serviceId or closedLoopId has to be passed to the policy, and this should be available to perform some logic or action within the policy. In the CLAMP UI, while configuring the APEX Policy, specifying taskParameters with these will enable this.
+
+ - More information about the usage of Task Parameters can be found here: https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/APEX-User-Manual.html#configure-task-parameters
+
+ - In the taskLogic, taskParameters can be accessed as executor.parameters.get("ParameterKey1"))
+
+ - More information can be found here: https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/APEX-Policy-Guide.html#accessing-taskparameters
+
+* GRPC support for APEX-CDS interaction.
+ - APEX-PDP now supports interaction with CDS over gRPC. Up through El Alto, CDS interaction was possible over REST only. A new plugin was developed in APEX for this feature. Refer the link for more details. https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/APEX-User-Manual.html#grpc-io
+
+POLICY-XACML
+~~~~~~~~~~~~
+
+* Added optional Decision API param to Decision API for monitor decisions that returns abbreviated results.
+ - Return only an abbreviated list of policies (e.g. metadata Policy Id and Version) without the actual contents of the policies (e.g. the Properties).
+
+* XACML PDP now support PASSIVE_MODE.
+* Added support to return status and error if pdp-x failed to load a policy.
+* Changed optimization Decision API application to support "closest matches" algorithm.
+* Changed Xacml-pdp to report the pdp group defined in XacmlPdpParameters config file as part of heartbeat. Also, removed supportedPolicyType from pdpStatus message.
+* Design the TOSCA policy model for SDNC naming policies and implement an application that translates it to a working policy and is available for decision API.
+* XACML pdp support for Control Loop Coordination
+ - Added policies for SON and PCI to support each blocking the other, with test cases and appropriate requests
+
+* Extend PDP-X capabilities so that it can load in and enforce the native XACML policies deployed from PAP.
+
+POLICY-DROOLS-PDP
+~~~~~~~~~~~~~~~~~
+
+* Support for offline mode.
+ - The OOM deployment now supports offline mode for PDP-D by default.
+
+* Parameterize mvn repo urls and proxy settings
+ - This allows the users to build the docker images for drools-pdp and drools-application using their own CI pipelines if needed.
+
+* TOSCA Policy Type design for operational policy supported by Drools so that policy is compliant with TOSCA policies
+* pip updated to pip3 in docker.
+* Extend PDP-D capabilities so that it can instantiate new drools controller instances for executing native Drools policies deployed from PAP.
+* Updated drools to use the redesigned Actors in policy/models.
+* Server Pool feature for supporting multiple active Drools PDP hosts.
+* server-pool is a resilient implementation that supports redundancy within and across data centers involving multiple PDP-Drools. Implementation involves hashing of which PDP-Drools owns which transaction and routing transactions to the appropriate PDP-Drools. By implementing as a feature, any deployment can choose to use or not use server-pool for its redundancy needs.
+
+POLICY-DROOLS-APPLICATIONS
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+* Support for offline mode.
+* Rate limiting DCAE flooding of ONSETs
+ - Policy will get flooded with potentially hundreds of ONSETs at once being picked up from DMaaP. Processing of multiple ONSETs (potentially hundreds in a batch read) of the same underlying unique network alarm severely impacts performance.
+
+* Design Operational Policy Type for Drools
+ - Design and preload the drools operational policy type.
+ - Backwards compatible support for tosca operational policies in usecases.
+ - Tosca compliant vCPE, vFirewall, vDNS
+
+* PDP-D support for native Drools policy execution
+ - Topics are decoupled from controllers. Native policies require topics configured at installation. Topics can also be overridden or new ones added when being placed in the mounted config directory.
+
+* Update Drools to use new actors.
+ - Add frankfurt rules for Actor redesign
+ - Usecases controller disabled (to be removed shortly after Frankfurt release) and the Frankfurt controller will be used.
+
+* Delete template.demo sub-module and amsterdam controllers
+* Removed vLB from drools-apps.
+* Replace URL with host/port/contextURI in the controlloop properties.
+ - Corresponding changes in base.conf file in OOM which is mounted.