summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--docs/Chapter5.rst10
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst
index dc73969..eff10e0 100644
--- a/docs/Chapter5.rst
+++ b/docs/Chapter5.rst
@@ -5099,12 +5099,12 @@ even in the short-term as of the long-term direction.
c. VNFM Driver Development Steps
================================
-Refer to the ONAP documentation for VNF Provider instructions on integrating
+Refer to the ONAP documentation for VNF Provider instructions on integrating
vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
-highlighted below.
+highlighted below.
1. Use the VNF SDK tools to design the VNF with TOSCA models to output
-the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
+the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
validated and tested.
2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
@@ -5119,8 +5119,8 @@ VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific VNFM to O
vendor-specific VNFM adaptor is added to ONAP implementing the interface of the vendor-specific VNFM.
A vendor-specific VNFM adaptor is a microservice with a unique name and an appointed
-port. When started up, the vendor-specific VNFM adaptor microservice is automatically registered to the
-Microservices Bus (MSB). The following RESTful example describes the scenario of
+port. When started up, the vendor-specific VNFM adaptor microservice is automatically registered to the
+Microservices Bus (MSB). The following RESTful example describes the scenario of
registering a vendor-specific VNFM adaptor to MSB:
.. code-block:: java