ONAP Policy Framework Weekly Meeting
June 7, 2017
Agenda
 ONAP
Developer Event June 8-9
 TSC Feedback for Project Proposal
 Project Driven VNF Orchestration Project integration
 Modeling Project collaboration
ONAP Developer Event June 8-9
 Project

is being presented at 9:30am UTC Thursday 6/8
https://wiki.onap.org/display/DW/ONAP+Project+Developer+Remote+Project+Presentation+Times
 5:30am
EST, 5:30pm Beijing
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.
TSC Feedback (Stephen Terrill)






Stephen
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).
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?
TSC Feedback - Summary
 Project
Scope & Description
 Classification of Policies
 R1 Deliverables
 Committers
Modeling Project Collaboration
 6/6
Modeling Weekly Meeting touched on Service
Assurance
 SDC, DCAE, CLAMP and Policy roles
 Presentation regarding MEF by John Strassner