1. ONAP Policy Framework Weekly Meeting June 7, 2017

2. Agenda ONAP Developer Event June 8-9 TSC Feedback for Project Proposal
Project Driven VNF Orchestration Project integration
Modeling Project collaboration

3. ONAP Developer Event June 8-9
Project is being presented at 9:30am UTC Thursday 6/8
5:30am EST, 5:30pm Beijing

4. TSC Feedback (Chris Donnelly)
Clarity: Project description and scope are unclear. They were written from the perspective of someone who is familiar with the module in ECOMP, but many of the TSC members are not as familiar and we need more clarification.  Please add more detail about the big picture (problem you're solving and vision).  Also, please clarify what you're delivering (code, requirements, etc.).
Overlap: How does this relate to other projects? Are you developing APIs? Are you producing requirements that you expect others to implement (and did they agree)?
Risk management: It appears that you have sufficient resources.  We would like to see committers from different companies. It would be helpful to clarify your deliverables - is there a subset that can be delivered in the R1 timeframe?
Relevance and prioritization: this is relevant to the ONAP release.

5. TSC Feedback (Stephen Terrill)
It would be great to state the APIs that this project feels it is responsible to define
Pamela Dragosh- yes we can update the API's.
If possible, consider a committer from another company as well (this shouldn't block approval).
Pamela Dragosh - sure we can consider other committers. Initial thought was that for Release 1, best to have only folks that know the code. But the project is designed to evolve the Policy Framework and address its current limitations, which will require us to expand the list of committers.
In the scope there is text on classification of policies.  What is unclear to me is the deliverable from that.  Is it a document? is that in internal deliverable?
Pamela Dragosh - I don't think we had enough time to clarify that. My thought is that the project should define the flow for all the types of policy required by ONAP. For example, how it is expressed/captured, when it translated, which component calls the API to create/update it, etc. That would at least involve documentation of that flow. I will start discussion on how to clarify this.
Seems to have a good level of resourcing
Is there any models that this is dependant on, or expected to define?
Pamela Dragosh - Yes. The current Policy seed code is model-driven and we utilize models from the DCAE team in order for the DCAE components to be policy-driven. We have used EMF in the past, but are phasing that out in support of TOSCA/JSON approach. We expect to be the team that defines how policy is expressed if there are any specific models that are going to be used to express policy. (i.e. the outcome from the Modeling Project).

6. TSC Feedback (Ranny Haiby)
It might be cleaner to keep all references to Release 1 in the release plan.
Could the outcome of the classification process also include guidelines to ONAP developers on when the policy framework should be used (and when not)
Could you please clarify the scope? Is a Policy Decision Engine one of the deliverable? Is there one central instance of the engine for the entire ONAP or could each module have its own? If central, how do you determine which technology to use?

7. TSC Feedback - Summary Project Scope & Description
Classification of Policies
R1 Deliverables
Committers

8. Modeling Project Collaboration
6/6 Modeling Weekly Meeting touched on Service Assurance
SDC, DCAE, CLAMP and Policy roles
Presentation regarding MEF by John Strassner