Documentation clean-up

Cleaned up documentation per:
(1) Docs project feedback
(2) License cleanup
(3) other typos, etc.

Issue-ID: VNFSDK-129

Change-Id: If125784b3b0656128ca897e82ad0e5d9873a7e07
Signed-off-by: Chris Donley <christopher.donley@huawei.com>

1 files changed, 37 insertions, 29 deletions

diff --git a/docs/files/VNF SDK - Guide for Bundling VNFs.rst b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
index 2cb1556..99f3ccf 100644
--- a/docs/files/VNF SDK - Guide for Bundling VNFs.rst
+++ b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
@@ -1,4 +1,8 @@
-VNF SDK - Guide for Bundling VNFs
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2017 Huawei Technologies Co., Ltd.
+
+VNF SDK - Guide for Bundling VNFs
 =================================
 
 
@@ -6,7 +10,8 @@ Step 1: Requirements
 --------------------
 
 1. Virtual machine images for each of your VDUs (likely in qcow2 format).
-2. Scripts for installing and configuring each VDU per the standard TOSCA lifecycle workflows.
+2. Scripts for installing and configuring each VDU per the standard TOSCA
+   lifecycle workflows.
 3. Optional: scripts for retrieving indicators from each VDU.
 4. VNF SDK pkgtools
 
@@ -28,35 +33,38 @@ The "dependency" requirement should have a relationship of type
 
 There are two optional properties you can assign to this relationship:
 
-1. "indicators" is a map of indicators. The keys are arbitrary, for you to name,
-   and depend on the specific capabilities of your VNF. These provide the link
-   between TOSCA and your indicator retrieval scripts.
-2. "compute_dependencies" is a map of features you require the infrastructure to
-   provide for the compute node hosting your VDU. The keys are arbitrary, however
-   we will maintain a master list of names supported by various orchestrators
-   (TBD). Note that new names will likely be supported in the future as
-   technological innovation progresses, while deprecated ones will be ignored by
-   orchestrators. Likewise, names unsupported by a particular orchestrator will
-   be ignored.
+1. "indicators" is a map of indicators. The keys are arbitrary, for you to
+   name, and depend on the specific capabilities of your VNF. These provide
+   the link between TOSCA and your indicator retrieval scripts.
+2. "compute_dependencies" is a map of features you require the infrastructure
+   to provide for the compute node hosting your VDU. The keys are arbitrary,
+   however we will maintain a master list of names supported by various
+   orchestrators (TBD). Note that new names will likely be supported in the
+   future as technological innovation progresses, while deprecated ones will be
+   ignored by orchestrators. Likewise, names unsupported by a particular
+   orchestrator will be ignored.
 
 Notes:
 
-1. For "compute_dependencies", you have the option of specifying a single special key, "profile", that refers to a bundle of compute dependencies specified in
-   "compute-profiles.yaml". Optionally, you can override any of the dependencies
-   in the bundle by specifying them explicitly under "compute_dependencies".
+1. For "compute_dependencies", you have the option of specifying a single
+   special key, "profile", that refers to a bundle of compute dependencies
+   specified in "compute-profiles.yaml". Optionally, you can override any of
+   the dependencies in the bundle by specifying them explicitly under
+   "compute_dependencies".
 2. By default, compute dependencies are considered to be absolute requirements
-   for your VNF to function. However, if your VNF can also function without them,
-   you can set "optional: true". This way the orchestrator will try to satisfy
-   the optional requirements, but will not report an error if it cannot.
-3. You may optionally consider allowing operators to override your dependencies.
-   This is useful for allowing the VNF to run on various compute infrastructures
-   other than the defaults you specify, as long as they are indeed supported by
-   your VNF. In TOSCA, this is easily handled by declaring "inputs" for your
-   blueprint, with "default" values, and then using the "get_input" intrinsic
-   function to apply the provided value to any specific "compute_dependencies".
-   The "pingpong.yaml" has an example of such usage. The same technique can be
-   used to allow the operator to override your indicator scripts, and there is an
-   example of that as well.
+   for your VNF to function. However, if your VNF can also function without
+   them, you can set "optional: true". This way the orchestrator will try to
+   satisfy the optional requirements, but will not report an error if it
+   cannot.
+3. You may optionally consider allowing operators to override your
+   dependencies. This is useful for allowing the VNF to run on various compute
+   infrastructures other than the defaults you specify, as long as they are
+   indeed supported by your VNF. In TOSCA, this is easily handled by declaring
+   "inputs" for your blueprint, with "default" values, and then using the
+   "get_input" intrinsic function to apply the provided value to any specific
+   "compute_dependencies". The "pingpong.yaml" has an example of such usage.
+   The same technique can be used to allow the operator to override your
+   indicator scripts, and there is an example of that as well.
 
 Otherwise, this is a standard TOSCA blueprint using the Simple Profile for NFV,
 and you may extend the blueprint as is required.
@@ -68,8 +76,8 @@ Arrange all your files (the TOSCA template, your scripts, and your virtual
 machine images) in the correct directory structure. File references provided in
 the blueprint must match the directory structure. If a script is referenced
 using a path with sub-directory "example" the initial directory must contain a
-directory called "example" with that script file inside. The directory structure
-will be kept inside the CSAR archive.
+directory called "example" with that script file inside. The directory
+structure will be kept inside the CSAR archive.
 
 Run the bundling tool that is included in the VNF SDK.