forked from camaraproject/APIBacklog
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update APIproposal_QoS_Booking_KDDI. md
- Loading branch information
Showing
1 changed file
with
7 additions
and
7 deletions.
There are no files selected for viewing
14 changes: 7 additions & 7 deletions
14
documentation/API proposals/APIproposal_QoS_Booking_KDDI. md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,12 +1,12 @@ | ||
| | **Field** | Description | | ||
| | ---- | ----- | | ||
| | API family name | Name of the API or API family | | ||
| | API family owner | Company submitting the API proposal. | | ||
| | API family name | QoS Booking | | ||
| | API family owner | KDDI | | ||
| | 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> | | ||
| | YAML code available? | YES | | ||
| | Validated in lab/productive environments? | NO | | ||
| | Validated with real customers? | NO | | ||
| | Validated with operators? | NO | | ||
| | Supporters in API Backlog Working Group | List of supporters. <br><em> NOTE: That shall be added by the Working Group.</em> | |