| Status | Choose One: DRAFT |
|---|---|
| Submitter | Steven Wright |
| Contributors | Names of additional contributors |
| Proposed Release | Casablanca |
| JIRA Ticket(s) | VNFRQTS-242 - Getting issue details... STATUS |
The objective is to extract / summarize VNF Requirements into a VNF Badge with a format similar to the CII Badging website see e.g. CII Badge for VVP.
The main difference is that the badge is for a VNF rather than an open source project.
As an initial target, it has been proposed to focus on the requirements associated with VNF Management (i.e. Chapter 7 of the ONAP VNF Requirements)
The specific badge would need to be aligned with the LFN guidance on logos, but something along the following lines may be a place to start.
The current CII badge has ~70 requirements, in 6 pulldown menus. The max requirements in a pulldown is 16.
For usability, we should constrain the number of pulldowns and the number of requirements per pulldown to a similar order of magnitude e.g. pulldowns < 10, reqts/pulldown <20
The VNF Requirements in Ch7 as of mid August (there are some changes pending for section 7.4 and 7.5 in VNFRQTS-278 - Getting issue details... STATUS and VNFRQTS-289 - Getting issue details... STATUS )
| Section | Number of Reqts | Topic |
|---|---|---|
| 7.1 | 0 | Service Design |
| 7.2 | 55 | VNF On-boarding and package management |
| 7.2.1 | 0 | Design Definition |
| 7.2.2 | 9 | Resource Description |
| 7.2.3 | 9 | Resource Configuration |
| 7.2.4 | 18 | Resource Control Loop |
| 7.2.5 | 7 | Compute, Network, and Storage Requirements |
| 7.2.6 | 3 | Testing |
| 7.2.7 | 9 | Licensing Requirements |
| 7.3 | 114 | Configuration Management |
| 7.3.1 | 20 | Controller Interactions With VNF |
| 7.3.2 | 63 | NETCONF Standards and Capabilities |
| 7.3.2.1 | 63 | VNF Configuration via NETCONF Requirements |
| 7.3.2.1.1 | 2 | Configuration Management |
| 7.3.2.1.2 | 61 | NETCONF Server Requirements |
| 7.3.2.1.2 | 44 | (other- no subheading) |
| 7.3.2.1.2 | 11 | Yang Models |
| 7.3.2.1.2 | 6 | Netconf RFCs |
| 7.3.3 | 1 | VNF REST APIs |
| 7.3.4 | 14 | Chef Standards and Capabilities |
| 7.3.5 | 16 | Ansible Standards and Capabilities |
| 7.3.6 | 0 | Support of Controller Commands And Southbound Protocols |
| 7.4 | 27 | Monitoring & Management |
| 7.4.1 | 0 | Data Model for Event Records |
| 7.4.2 | 0 | Event Records - Data Structure Description |
| 7.4.3 | 0 | Data Structure Specification of the Event Record |
| 7.4.4 | 0 | Transports and Protocols Supporting Resource Interfaces |
| 7.4.5 | 27 | Monitoring & Management Requirements |
| 7.4.5.1 | 1 | VNF telemetry via standardized interface |
| 7.4.5.2 | 0 | Encoding and Serialization |
| 7.4.5.3 | 1 | JSON |
| 7.4.5.4 | 0 | KV-GPB/GPB |
| 7.4.5.5 | 1 | Reporting Frequency |
| 7.4.5.6 | 8 | Addressing and Delivery Protocol |
| 7.4.5.7 | 9 | Asynchronous and Synchronous Data Delivery |
| 7.4.5.8 | 4 | Security |
| 7.4.5.9 | 3 | Bulk Performance Measurement |
Naively mapping sections to pulldowns would still have (Red) sections with more than 20 reqts, and would need some further breakdown or summarization.
Scoring with simple counts of Met/Unmet will not be sufficient:
R-89571 provides for alternatives (one or more of) : Netconf/ Chef/ Ansible
Section 7.4 has MAY or SHOULD requirements which should not have the same weight as a MUST requirement.