DRAFT PROPOSAL FOR COMMENTS

...

• This project will deliver a unified set of VNF Guidelines and VNF Requirements.
• The VNF Guidelines and VNF Requirements must be  versioned to enable evolution based on operational experience
• The VNF Guidelines and VNF Requirements will support the ONAP Architecture Principles.
• • Update the  VNF Requirements as prototype RFP text for the ONAP/Beijing release including:
    • Hardware Platform Awareness (HPA) Requirements
    • HEAT/TOSCA Information Model updates
  • Update the  VNF Guidelines as  for the ONAP/Beijing release
    
• Identify a list of features and functionality will be developed.
• The VNF Guidelines and Requirements will support the Release 1 Use Cases.
  • Use cases focused on VNF Requirements may be developed in this project, and they will need to be aligned with the ETE Platform use cases.  
  • Document the VNF Provider Guidelines for VNF Scaleout Use Case for the ONAP/Beijing release
• VNF Guidelines and Requirements  are to be refined beyond prototype text  (e.g. through EPIC statements, use cases)  to deliver test cases and test procedures for us in VNF onboarding & validation. VNF Requirement level use cases to be aligned with ETE platform use cases
  • Document the VNF Test Case Descriptions  for VNF Package testing for the ONAP/Beijing release
• Identify what is in or out of scope. During the development phase, it helps reduce discussion.
• VNF Guidelines may be forward looking, or include best practices in VNF design and VNF lifecycle processes.
• VNF Requirements from ONAP APIs should be linked to the ONAP Release
• VNF  Requirements may include: 
• expected  operational characteristics ( e.g. security, resilience, upgradeability) 
• conditional  requirements (e.g. When configured for deployment on High Availability Network Cloud Infrastructure, the VNF Shall …)
• Tool chain improvements
  • Develop requirements structure/ metadata to support better linkage / tracking with other ONAP projects
  • Develop templates for VNFs to demonstrate VNF Requirements conformance 

...

...

The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.

Team Internal Milestone

This section is optional and may be used to document internal milestones within a project team or multiple project teams. For instance, in the case the team has made agreement with other team to deliver some artifacts on a certain date that are not in the release milestone, it is erecommended to provide these agreements and dates in this section.

...