Create APIproposal_QoS_Booking_KDDI. md

documentation/API proposals/APIproposal_QoS_Booking_KDDI. md

@@ -0,0 +1,12 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Name of the API or API family |
+| API family owner | Company submitting the API proposal. |
+| API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. |
+| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity. <br><em>Example: this API requires the availability of NEF with this Rel-15 "X"feature</em>. 
+| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities. <br><em> NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.</em>|
+| YAML code available? | YES / NO. |
+| Validated in lab/productive environments? | YES / NO. <br>If YES, specify if it was lab network or productive network. |
+| Validated with real customers? | YES / NO. <br>If YES, specify how many customers participated in the evaluation, and what their use cases were. <br><em>NOTE: It is not mandatory (though recommendable) to specify the name of the customers. </em> |
+| Validated with operators? | YES / NO. <br> If YES, specify how many operators participated in the evaluation. <br><em>NOTE: It is not mandatory (though recommendable) to specify the name of the operators. </em> |
+| Supporters in API Backlog Working Group | List of supporters. <br><em> NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation.</em> |