...
- ONAP must support Automation at every phase of Lifecycle
- Model Driven: All ONAP modules should be model-driven, avoiding, where possible, programming code. This allows for a catalog-based reusable repository for network & services lifecycle management.
- Meta-data & Policy Driven Automation: ONAP should support high levels of automation at every phase of lifecycle management – e.g. onboard, design, deployment, instantiation, upgrade, monitoring, management, to end of life cycle. These automations should be policy driven, allowing users to dynamically control automation behavior via policy changes.
- Self-Service & User Focused: ONAP Platform should support a self-service model with a fully integrated user-friendly design studio to design all facets of lifecycle management (product/ service design, operational automation, etc.). All interfaces and interactions with ONAP should be user friendly and easy to use.
- Integration Friendly: When an ONAP component relies on software outside of the ONAP project, the dependency on that external software should be designed to pluggable, API-oriented, supporting multiple possible implementations of that dependency.
- Multi-tenancy managed environment: The ONAP platform should support the ability manage multiple tenants and provide isolation for those tenants.
- Backward Compatibility: ONAP platform should support backward compatibility with every new release.
...