VNFRQTS - Fixing doc8 errors

Issue-ID: VNFRQTS-441

Change-Id: I3fe71b72a8165739c03e3b2ba70a4ab392c9b0fc
Signed-off-by: Bozawglanian, Hagop (hb755d) <hagop.bozawglanian@att.com>

13 files changed, 247 insertions, 179 deletions

diff --git a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
index c38158a..6677a06 100644
--- a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
@@ -37,15 +37,15 @@ single Incremental module or Base module.
 As stated in :need:`R-30395`, a VNF's Cinder Volume Module **MAY** utilize
 nested heat.
 
-As stated in :need:`R-89913`, a VNF's Heat Orchestration Template's Cinder Volume
-Module Output Parameter(s) **MUST** include the
+As stated in :need:`R-89913`, a VNF's Heat Orchestration Template's Cinder
+Volume Module Output Parameter(s) **MUST** include the
 UUID(s) of the Cinder Volumes created in template,
 while others **MAY** be included.
 
-As stated in :need:`R-07443`, a VNF's Heat Orchestration Templates' Cinder Volume
-Module Output Parameter's name and type **MUST** match the input parameter
-name and type in the corresponding Base Module or Incremental Module unless
-the Output Parameter is of the type ``comma_delimited_list``,
+As stated in :need:`R-07443`, a VNF's Heat Orchestration Templates' Cinder
+Volume Module Output Parameter's name and type **MUST** match the input
+parameter name and type in the corresponding Base Module or Incremental
+Module unless the Output Parameter is of the type ``comma_delimited_list``,
 then the corresponding input parameter **MUST** be declared as type ``json``.
 
 A single volume module must create only the volumes
@@ -74,9 +74,9 @@ The following rules apply to independent volume Heat templates:
 
 .. req::
     :id: R-270358
-    :target: VNF 
-    :keyword: MUST 
-    :validation_mode: static 
+    :target: VNF
+    :keyword: MUST
+    :validation_mode: static
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's Cinder Volume Template **MUST**
diff --git a/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst b/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst
index f6c4541..bf810b7 100644
--- a/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst
@@ -416,8 +416,8 @@ immutable
 
 The parameter attribute ``immutable`` is an OpenStack optional attribute
 that defines whether the parameter is updatable. A Heat Orchestration Template
-stack update fails if ``immutable`` is set to ``true`` and the parameter value is
-changed.  This attribute ``immutable`` defaults to ``false``.
+stack update fails if ``immutable`` is set to ``true`` and the parameter
+value is changed.  This attribute ``immutable`` defaults to ``false``.
 
 .. _resources:
 
@@ -482,11 +482,9 @@ separate block in the resources section with the following syntax.
       condition: <condition name or expression or boolean>
 
 
-
 resource ID
 +++++++++++++
 
-
 .. req::
     :id: R-75141
     :target: VNF
@@ -517,7 +515,8 @@ type
 +++++
 
 The resource attribute ``type`` is an OpenStack required attribute that
-defines the resource type, such as ``OS::Nova::Server`` or ``OS::Neutron::Port``.
+defines the resource type, such as ``OS::Nova::Server`` or
+``OS::Neutron::Port``.
 
 The resource attribute ``type`` may specify a VNF HEAT
 Orchestration Template Nested YAML file.
@@ -565,7 +564,6 @@ metadata
 
 The resource attribute ``metadata`` is an OpenStack optional attribute.
 
-
 .. req::
     :id: R-67386
     :target: VNF
@@ -575,14 +573,12 @@ The resource attribute ``metadata`` is an OpenStack optional attribute.
     A VNF's Heat Orchestration Template's Resource **MAY** declare the
     attribute ``metadata``.
 
-
 depends_on
 +++++++++++
 
 The resource attribute ``depends_on`` is an OpenStack optional attribute.
 See `Section <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-resources-dependencies>`__ 9.7 for additional details.
 
-
 .. req::
     :id: R-46968
     :target: VNF
diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst
index f0d2212..948f8aa 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst
@@ -20,8 +20,8 @@ naming convention. The four properties are:
 3. fixed_ips, subnet
 
  * Note that earlier versions of this document mentioned the property
-   fixed_ips, subnet_id.  This property has been removed from the document since
-   it has been deprecated.
+   fixed_ips, subnet_id.  This property has been removed from the document
+   since it has been deprecated.
    See https://github.com/openstack/heat/blob/stable/ocata/heat/engine/resources/openstack/neutron/port.py
 
 4. allowed_address_pairs, ip_address
@@ -833,8 +833,9 @@ Examples
 *Example: comma_delimited_list parameters for IPv4 and IPv6 Address
 Assignments to an external network*
 
-In this example, the ``{network-role}`` has been defined as ``oam`` to represent
-an oam network and the ``{vm-type}`` has been defined as ``db`` for database.
+In this example, the ``{network-role}`` has been defined as ``oam`` to
+represent an oam network and the ``{vm-type}`` has been defined as ``db``
+for database.
 
 .. code-block:: yaml
 
@@ -1044,7 +1045,7 @@ The property ``fixed_ips`` is used to assign IPs to a port. The Map Property
       * ``{network-role}_subnet_id``
 
     where
-    
+
       * ``{network-role}`` is the network role of the network.
 
 .. req::
@@ -1091,12 +1092,12 @@ value at orchestration to the Heat Orchestration Template.
     and the external network IPv6 subnet is to be specified
     using the property ``fixed_ips``
     map property ``subnet``, the parameter
-    **MUST** follow the naming convention 
+    **MUST** follow the naming convention
 
       * ``{network-role}_v6_subnet_id``
 
-    where 
-      
+    where
+
       * ``{network-role}`` is the network role of the network.
 
 .. req::
@@ -1116,10 +1117,10 @@ value at orchestration to the Heat Orchestration Template.
 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
 that has two or more IPv4 subnets*
 
-In this example, the ``{network-role}`` has been defined as ``oam`` to represent
-an oam network and the ``{vm-type}`` has been defined as ``lb`` for load
-balancer. The cloud assigned IP Address uses the OpenStack DHCP service
-to assign IP addresses.
+In this example, the ``{network-role}`` has been defined as ``oam`` to
+represent an oam network and the ``{vm-type}`` has been defined as ``lb``
+for load balancer. The cloud assigned IP Address uses the OpenStack
+DHCP service to assign IP addresses.
 
 .. code-block:: yaml
 
@@ -1142,9 +1143,9 @@ to assign IP addresses.
 address assigned to a network that has at least one IPv4 subnet and one
 IPv6 subnet*
 
-In this example, the ``{network-role}`` has been defined as ``oam`` to represent
-an oam network and the ``{vm-type}`` has been defined as ``lb`` for load
-balancer.
+In this example, the ``{network-role}`` has been defined as ``oam`` to
+represent an oam network and the ``{vm-type}`` has been defined as
+``lb`` for load balancer.
 
 .. code-block:: yaml
 
@@ -1186,7 +1187,7 @@ balancer.
         using the property ``fixed_ips`` map property ``subnet``,
 
     the parameter **MUST** follow the naming convention
-    
+
       * ``int_{network-role}_subnet_id``
 
     where
@@ -1237,7 +1238,7 @@ input parameter.
 
       * the VNF's Heat Orchestration Template's
         resource ``OS::Neutron::Port`` in an Incremental Module is attaching
-        to an internal network (per the ONAP definition, see Requirements 
+        to an internal network (per the ONAP definition, see Requirements
         R-52425 and R-46461)
         that is created in the Base Module, AND
       * an IPv6 address is being cloud assigned by OpenStack's DHCP Service AND
@@ -1393,7 +1394,7 @@ VIP Assignment, External Networks, Supported by Automation
         OS::Nova::Server
       * ``{network-role}`` is the {network-role} of the external
         network
-    
+
     And the parameter **MUST** be declared as type ``string``.
 
 .. req::
@@ -1433,7 +1434,7 @@ VIP Assignment, External Networks, Supported by Automation
     and an IPv6 Virtual IP (VIP)
     address is assigned via ONAP automation
     using the property ``allowed_address_pairs``
-    map property ``ip_address``, 
+    map property ``ip_address``,
     the parameter name **MUST** follow the
     naming convention
 
diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Metadata Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Metadata Parameters.rst
index 0fe1286..7055e6e 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Metadata Parameters.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Metadata Parameters.rst
@@ -7,8 +7,8 @@
 Resource: OS::Nova::Server - Metadata Parameters
 --------------------------------------------------------------------------------
 
-The ``OS::Nova::Server`` resource property ``metadata`` is an optional OpenStack
-property.
+The ``OS::Nova::Server`` resource property ``metadata`` is an optional
+OpenStack property.
 Table 2 summarizes the mandatory and optional ``metadata`` supported by ONAP.
 The sections that follow provides the requirements associated with each
 ``metadata`` parameter.
@@ -93,7 +93,7 @@ Template at orchestration time.
     :updated: casablanca
 
     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property 
+    property
     ``metadata`` key/value pair ``vnf_id`` is passed into a Nested YAML
     file, the key/value pair name ``vnf_id`` **MUST NOT** change.
 
@@ -123,7 +123,7 @@ Template at orchestration time.
     :validation_mode: static
     :updated: casablanca
 
-    A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource 
+    A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
     property ``metadata`` **MUST**
     contain the key/value pair ``vf_module_id``
     and the value MUST be obtained via a ``get_param``.
@@ -230,7 +230,7 @@ Template at orchestration time.
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``vnf_name`` 
+    property ``metadata`` key/value pair ``vnf_name``
     parameter ``vnf_name`` **MUST NOT**
     have parameter constraints defined.
 
@@ -255,7 +255,7 @@ Template at orchestration time.
 
 
     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property 
+    property
     ``metadata`` key/value pair ``vnf_name`` is passed into a Nested YAML
     file, the key/value pair name ``vnf_name`` **MUST NOT** change.
 
@@ -272,7 +272,7 @@ Template at orchestration time.
 vf_module_name
 ^^^^^^^^^^^^^^^^^^
 
-The ``OS::Nova::Server`` Resource ``metadata`` map value parameter 
+The ``OS::Nova::Server`` Resource ``metadata`` map value parameter
 ``vf_module_name``
 is the deployment name of the heat stack created (e.g., ``<STACK_NAME>``)
 from the
@@ -288,7 +288,7 @@ part of the orchestration process.
     :keyword: SHOULD
     :updated: casablanca
 
-    A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource 
+    A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
     property ``metadata`` **SHOULD**
     contain the key/value pair ``vf_module_name`` and the value **MUST**
     be obtained via a ``get_param``.
@@ -301,7 +301,7 @@ part of the orchestration process.
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property 
+    property
     ``metadata`` key/value pair ``vf_module_name`` parameter **MUST** be
     declared as ``vf_module_name`` and the parameter **MUST**
     be defined as type: ``string``.
@@ -314,7 +314,7 @@ part of the orchestration process.
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property 
+    property
     ``metadata`` key/value pair ``vf_module_name`` parameter ``vf_module_name``
     **MUST NOT** have parameter constraints defined.
 
@@ -327,7 +327,7 @@ part of the orchestration process.
 
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``vf_module_name`` 
+    property ``metadata`` key/value pair ``vf_module_name``
     parameter ``vf_module_name`` **MUST NOT**
     be enumerated in the Heat Orchestration Template's environment file.
 
@@ -369,7 +369,7 @@ available for use by other ONAP components and/or north bound systems.
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
     ``metadata`` **MAY**
-    contain the key/value pair ``vm_role`` and the value **MUST** be 
+    contain the key/value pair ``vm_role`` and the value **MUST** be
     obtained either via
 
     - ``get_param``
@@ -384,8 +384,8 @@ available for use by other ONAP components and/or north bound systems.
 
     If a VNF's Heat Orchestration Template's ``OS::Nova::Server``
     resource property
-    ``metadata`` key/value pair ``vm_role`` value is obtained via 
-    ``get_param``, the parameter **MUST** be declared as ``vm_role`` 
+    ``metadata`` key/value pair ``vm_role`` value is obtained via
+    ``get_param``, the parameter **MUST** be declared as ``vm_role``
     and the parameter **MUST** be defined as type: ``string``.
 
 .. req::
@@ -693,7 +693,7 @@ workload_context
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``workload_context`` 
+    property ``metadata`` key/value pair ``workload_context``
     parameter **MUST**
     be declared as ``workload_context`` and the parameter **MUST**
     be defined as type: ``string``.
@@ -706,7 +706,7 @@ workload_context
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``workload_context`` 
+    property ``metadata`` key/value pair ``workload_context``
     parameter ``workload_context`` **MUST NOT**
     have parameter constraints defined.
 
@@ -719,7 +719,7 @@ workload_context
 
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``workload_context`` 
+    property ``metadata`` key/value pair ``workload_context``
     parameter ``workload_context`` **MUST NOT**
     be enumerated in the Heat Orchestration Template's environment file.
 
@@ -731,7 +731,7 @@ workload_context
     :updated: casablanca
 
     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``workload_context`` 
+    property ``metadata`` key/value pair ``workload_context``
     is passed into a Nested YAML
     file, the key/value pair name ``workload_context`` **MUST NOT** change.
 
@@ -792,7 +792,7 @@ environment_context
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property ``metadata`` key/value pair ``environment_context`` 
+    property ``metadata`` key/value pair ``environment_context``
     parameter **MUST** be declared as ``environment_context`` and the
     parameter type **MUST** be defined as type: ``string``.
 
@@ -816,7 +816,7 @@ environment_context
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
-    property 
+    property
     ``metadata`` key/value pair ``environment_context`` **MUST NOT**
     be enumerated in the Heat Orchestration Template's environment file.
 
diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst
index 47cbc17..5f16802 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst
@@ -28,9 +28,9 @@ Requirement R-82481 defines how the ``{vm-type}`` is used.
 
 .. req::
     :id: R-304011
-    :target: VNF 
-    :keyword: MUST 
-    :validation_mode: static 
+    :target: VNF
+    :keyword: MUST
+    :validation_mode: static
     :updated: casablanca
 
     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's
@@ -39,7 +39,7 @@ Requirement R-82481 defines how the ``{vm-type}`` is used.
     * property ``image`` parameter name
     * property ``flavor`` parameter name
     * property ``name`` parameter name
-    
+
 
     **MUST** contain the identical ``{vm-type}``
     and **MUST** follow the naming conventions defined
diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/ONAP Output Parameter Names.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/ONAP Output Parameter Names.rst
index 48596ec..98f5119 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/ONAP Output Parameter Names.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/ONAP Output Parameter Names.rst
@@ -171,7 +171,7 @@ oam_management_v4_address*
 
     If the VNF's OAM Management IP Address is cloud assigned and
     and the OAM IP Address is required to be inventoried in ONAP A&AI,
-    then the parameter **MUST** be obtained by the 
+    then the parameter **MUST** be obtained by the
     resource ``OS::Neutron::Port``
     attribute ``ip_address``.
 
diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Resource Property.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Resource Property.rst
index b6c7c3b..3109754 100644
--- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Resource Property.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Resource Property.rst
@@ -6,7 +6,7 @@ Resource Property "name"
 ----------------------------
 
 The parameter naming convention of the property ``name`` for the resource
-``OS::Nova::Server`` has been defined in 
+``OS::Nova::Server`` has been defined in
 :ref:`Nova Server - Metadata Parameters`.
 
 This section provides specifies how the property ``name`` for non
diff --git a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
index aed56e5..35286f0 100644
--- a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
@@ -17,9 +17,11 @@ an environment file.)*
 
 As stated in :need:`R-38474`, :need:`R-81725`, and :need:`R-53433`:
 
+
   * A VNF's Base Module **MUST** have a corresponding Environment File.
   * A VNF's Incremental Module **MUST** have a corresponding Environment File.
-  * A VNF's Cinder Volume Module **MUST** have a corresponding environment File.
+  * A VNF's Cinder Volume Module **MUST** have a corresponding environment
+    File.
 
 A nested heat template must not have an environment file; OpenStack does
 not support it.
diff --git a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
index 76ec0c1..07d9151 100644
--- a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
@@ -57,7 +57,7 @@ Module may use nested heat.
     A VNF's Heat Orchestration Template **MUST** have no more than
     two levels of nesting.
 
-.. req:: 
+.. req::
     :id: R-70112
     :target: VNF
     :keyword: MUST
@@ -835,7 +835,7 @@ balancer and db for database.
       properties:
         ...
         scheduler_hints:
-        group: {get_resource: lb_server_group} 
+        group: {get_resource: lb_server_group}
 
 Resource Data Synchronization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
index 3a19ea9..bbb706c 100644
--- a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
+++ b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
@@ -22,8 +22,8 @@ As stated in :need:`R-33132`, a VNF's Heat Orchestration Template **MAY** be
      3. a Cinder Volume Module Heat Orchestration Template (referred to as
         Cinder Volume  Module).
 
-As stated in :need:`R-20974`, at orchestration time, the VNF's Base Module **MUST**
-be deployed first, prior to any incremental modules.
+As stated in :need:`R-20974`, at orchestration time, the VNF's Base
+Module **MUST** be deployed first, prior to any incremental modules.
 
 As stated in :need:`R-28980`, :need:`R-86926`, and :need:`R-91497`, a
 VNF's incremental module **MAY** be used for
@@ -66,7 +66,7 @@ Incremental Module.
 
 
     A shared Heat Orchestration Template resource is a resource that **MUST**
-    be defined in the base module and will be referenced by one or 
+    be defined in the base module and will be referenced by one or
     more resources in one more more incremental modules.
 
     The UUID of the shared resource (created in the base module) **MUST** be
diff --git a/docs/Chapter5/Tosca.rst b/docs/Chapter5/Tosca.rst
index 3cfef75..59ff0d0 100644
--- a/docs/Chapter5/Tosca.rst
+++ b/docs/Chapter5/Tosca.rst
@@ -200,7 +200,7 @@ VNF Package ONAP Extensions
 1. TOACA data type extension tosca.datatypes.nfv.injectFile is used for vCPE
    use case.
 2. ONAP extensions for VNF package that is currently proposed for Dublin
-   release is VES extension described below. 
+   release is VES extension described below.
 
 TOSCA Introduction
 ^^^^^^^^^^^^^^^^^^^
@@ -234,7 +234,7 @@ This section describing TOSCA modeling principles and data model for
 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
 V1.0], or new type based on ETSI NFV requirements, etc.
 
-TOSCA VNF Descriptor 
+TOSCA VNF Descriptor
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 General
@@ -297,7 +297,7 @@ General
         Connection Point Descriptors (VduCpd), Virtual Link Descriptors
         (VnfVld) and VNF External Connection Point Descriptors
         (VnfExternalCpd);
-    
+
       - VNF deployment aspects: they are described in one or more
         deployment flavours, including configurable parameters, instantiation
         levels, placement constraints (affinity / antiaffinity), minimum and
@@ -306,7 +306,7 @@ General
         flavours;
 
     **Note**: The deployment aspects (deployment flavour etc.) are postponed
-    for future ONAP releases. 
+    for future ONAP releases.
 
       - VNF lifecycle management (LCM) operations: describes the LCM operations
         supported per deployment flavour, and their input parameters;
@@ -344,7 +344,6 @@ Data Types
     data definitions/attributes used in VNFD **MUST** comply with the below
     table.
 
-
 .. csv-table:: **NFV Data Types**
    :file: NFV_data_type.csv
    :header-rows: 1
@@ -368,12 +367,10 @@ Data Types
    :align: center
    :widths: auto
 
-
 Artifact Types
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-No artifact type is currently supported in ONAP. 
-
+No artifact type is currently supported in ONAP.
 
 Capability Types
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -407,7 +404,7 @@ Capability Types
 
       **Note**: This capability type is used in Casablanca how it does
       not exist in the last SOL001 draft
-      
+
       **tosca.capabilities.nfv.VirtualCompute** and
       **tosca.capabilities.nfv.VirtualStorage** includes flavours of VDU
 
diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst
index d622b5a..8ff1eb3 100755
--- a/docs/Chapter7/Monitoring-And-Management.rst
+++ b/docs/Chapter7/Monitoring-And-Management.rst
@@ -21,9 +21,9 @@ is directly dependent on the interfaces provided by the xNFs’ APIs. These can
 be in the form of asynchronous interfaces for event, fault notifications, and
 autonomous data streams. They can also be synchronous interfaces for on-demand
 requests to retrieve various performance, usage, and other event information.
-It should be understood that events are well structured packages of information,
-identified by an eventName, which are communicated to subscribers who are
-interested in the eventName. Events are simply a way of communicating
+It should be understood that events are well structured packages of
+information, identified by an eventName, which are communicated to subscribers
+who are interested in the eventName. Events are simply a way of communicating
 well-structured packages of information to one or more instances of an Event
 Listener service.
 
@@ -45,15 +45,17 @@ Data Model for Event Records
 
 This section describes the data model for the collection of telemetry data from
 xNFs by Service Providers (SPs) to manage xNF health and run-time life cycle.
-This data model is referred to as the VES Data Model. The VES acronym originally
-stood for Virtual-function Event Streaming, but VES has been generalized to
-support network-function event streaming, whether virtualized or not.
+This data model is referred to as the VES Data Model. The VES acronym
+originally stood for Virtual-function Event Streaming, but VES has been
+generalized to support network-function event streaming, whether virtualized or
+not.
 
 The VES Data Model describes a vendor-agnostic common vocabulary of event
 payloads. Vendor-specific, product-specific or service-specific data is
-supported by the inclusion of a flexible additional information field structure.
-The VES Data Models' common vocabulary is used to drive standard and automated
-data analytics (policy-driven analytics) within the ONAP DCAE Framework.
+supported by the inclusion of a flexible additional information field
+structure. The VES Data Models' common vocabulary is used to drive
+standard and automated data analytics (policy-driven analytics) within the
+ONAP DCAE Framework.
 
 While this document is focused on specifying some of the records from the ONAP
 perspective, there may be other external bodies using the same framework to
@@ -64,10 +66,10 @@ network devices, etc.) and virtual infrastructure managers (cloud controllers,
 SDN controllers). It uses ONAP’s VES Agent to generate VES events from the xNF
 and Intel’s collectD agent to generate infrastructure VES events. Note that any
 configurable parameters for these data records (e.g., frequency, granularity,
-policy-based configuration) will be managed using the “Configuration” framework
-described in the prior sections of this document. The infrastructure metrics have
-been funneled via the ONAP Multi-VIM Project and are now included in current
-specifications.
+policy-based configuration) will be managed using the "Configuration" framework
+described in the prior sections of this document. The infrastructure metrics
+have been funneled via the ONAP Multi-VIM Project and are now included in
+current specifications.
 
 The Data Model consists of:
 
@@ -76,24 +78,25 @@ The Data Model consists of:
 
    * Technology Independent Records: This version of the document specifies the
      model for Fault, Heartbeat, Measurements, Notification, pnfRegistration,
-     State Change, Syslog, and Threshold Crossing Alerts records. In the future,
-     these may be extended to support other types of technology independent
-     records (work is currently progressing to define a new Performance Domain
-     that would be able to support already defined 3GPP Metrics for xNF, e.g.
-     5G RAN device Use Case in Casablanca). Each of these records allows
-     additional fields (name/ value pairs) for extensibility. The xNF provider
-     may use these xNF provider-specific additional fields to provide additional
-     information that may be relevant to the managing systems.
+     State Change, Syslog, and Threshold Crossing Alerts records. In the
+     future, these may be extended to support other types of technology
+     independent records (work is currently progressing to define a new
+     Performance Domain that would be able to support already defined 3GPP
+     Metrics for xNF, e.g. 5G RAN device Use Case in Casablanca). Each of
+     these records allows additional fields (name/ value pairs) for
+     extensibility. The xNF provider may use these xNF provider-specific
+     additional fields to provide additional information that may be relevant
+     to the managing systems.
 
    * Technology Specific Records: This version of the document specifies the
-     model for Mobile Flow records, Signaling and Voice Quality records. In the
-     future, these may be extended to support other types of records (e.g.
-     Network Fabric, Security records, etc.). Each of these records allows
-     additional fields (name/value pairs) for extensibility. The xNF provider
-     can use these xNF-specific additional fields to provide additional
-     information that may be relevant to the managing systems. A placeholder for
-     additional technology specific areas of interest to be defined in the
-     future documents has been depicted.
+     model for Mobile Flow records, Signaling and Voice Quality records.
+     In the future, these may be extended to support other types of records
+     (e.g. Network Fabric, Security records, etc.). Each of these records
+     allows additional fields (name/value pairs) for extensibility. The xNF
+     provider can use these xNF-specific additional fields to provide
+     additional information that may be relevant to the managing systems.
+     A placeholder for additional technology specific areas of interest to
+     be defined in the future documents has been depicted.
 
 |image0|
 
@@ -163,13 +166,14 @@ independent event records:
      etc.
 
    * ``Heartbeat`` - the Heartbeat Record provides an optional structure for
-     communicating information about device health. Heartbeat records would only
-     have the Common Event Header block. An optional heartbeat domain is
-     available to specify information such as heartbeat interval and recommended
-     action upon missing heartbeat interval. Heartbeat avoids the need to ping
-     a device.  A communication failure can be determined via missing heartbeat
-     events being delivered to DCAE and appropriate action (e.g. restart VM,
-     rebuild xNF or create ticket) can be taken by DCAE CLAMP.
+     communicating information about device health. Heartbeat records would
+     only have the Common Event Header block. An optional heartbeat domain is
+     available to specify information such as heartbeat interval and
+     recommended action upon missing heartbeat interval. Heartbeat avoids the
+     need to ping a device.  A communication failure can be determined via
+     missing heartbeat events being delivered to DCAE and appropriate action
+     (e.g. restart VM, rebuild xNF or create ticket) can be taken by DCAE
+     CLAMP.
 
    * ``Measurements`` - the Measurements Record contains information about xNF
      and xNF resource structure and its condition to help in the management of
@@ -195,9 +199,10 @@ independent event records:
      domain ideas.)
 
    * ``pnfRegistration`` - the pnfRegistration Record provides a structure for
-     registration of a physical network function. The pnfRegistration Record can
-     contain information about attributes related to the physical network function
-     including serial number, software revision, unit type and vendor name.
+     registration of a physical network function. The pnfRegistration Record
+     can contain information about attributes related to the physical network
+     function including serial number, software revision, unit type and vendor
+     name.
 
    * ``State Change`` - the State Change Record provides a structure for
      communicating information about data flow through the xNF. The State
@@ -327,10 +332,10 @@ Data Structure Specification of the Event Record
    conditions repeat within a specified time interval, using the semantics and
    syntax described by the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`.
 
-**NOTE:** The Service Provider may override xNF provider Event Registrations using
-the ONAP SDC Design Studio to finalizes Service Provider engineering rules
-for the processing of the xNF events.  These changes may modify any of the
-following:
+**NOTE:** The Service Provider may override xNF provider Event
+Registrations using the ONAP SDC Design Studio to finalizes Service
+Provider engineering rules for the processing of the xNF events.
+These changes may modify any of the following:
 
 * Threshold levels
 * Specified actions related to conditions
@@ -461,8 +466,8 @@ xNF Telemetry using Google Protocol Buffers
 Figure 3. xNF Telemetry using Google Protocol Buffers
 
 
-**NOTE:** For high-volume xNF telemetry, native (binary) Google Protocol Buffers
-(GPB) is the preferred serialization method. While supporting the GPB
+**NOTE:** For high-volume xNF telemetry, native (binary) Google Protocol
+Buffers (GPB) is the preferred serialization method. While supporting the GPB
 telemetry delivery approach described above, the default delivery method
 is the VES/REST JSON based model in DCAE. The purpose of the diagram above
 is to illustrate the GPB delivery concept only and not to imply a specific
diff --git a/docs/Chapter7/PNF-Plug-and-Play.rst b/docs/Chapter7/PNF-Plug-and-Play.rst
index 8a23af6..78c25d1 100644
--- a/docs/Chapter7/PNF-Plug-and-Play.rst
+++ b/docs/Chapter7/PNF-Plug-and-Play.rst
@@ -1,4 +1,3 @@
-
 .. Modifications Copyright © 2017-2018 AT&T Intellectual Property.
 
 .. Licensed under the Creative Commons License, Attribution 4.0 Intl.
@@ -24,117 +23,157 @@ The following are the requirements related to PNF Plug and Play.
 
 .. req::
     :id: R-56718
-    :target: XNF
+    :target: PNF
     :keyword: MAY
     :introduced: casablanca
 
-    The PNF Vendor **MAY** (optional) provide software Version(s) to be supported by PNF for SDC Design Studio PNF Model. This is set in the PNF Model property software_versions.
+    The PNF Vendor **MAY** provide software version(s) to be supported by PNF
+    for SDC Design Studio PNF Model. This is set in the PNF Model property
+    software_versions.
 
 .. req::
     :id: R-106240
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    The following VES Events **MUST** be supported by the PNF: pnfRegistration VES Event, HVol VES Event, and Fault VES Event. These are onboarded via the SDC Design Studio.  
-    Note: these VES Events are emitted from the PNF to support PNF Plug and Play, High Volume Measurements, and Fault events respectively."
+    The following VES Events **MUST** be supported by the PNF: pnfRegistration
+    VES Event, HVol VES Event, and Fault VES Event. These are onboarded via
+    he SDC Design Studio.
+
+    Note: these VES Events are emitted from the PNF to support PNF Plug and
+    Play, High Volume Measurements, and Fault events respectively.
 
 .. req::
     :id: R-258352
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    The PNF **MUST** support & accept the provisioning of an ONAP contact IP address (in IPv4 or IPv6 format).
-    Note: For example, it a possibility is that an external EMS would configure & provision the ONAP contact IP address to the PNF (in either IPv4 or IPv6 format). For the PNF Plug and Play Use Case, this IP address is the service provider's ""point of entry"" to the DCAE VES Listener. 
+    The PNF **MUST** support & accept the provisioning of an ONAP contact IP
+    address (in IPv4 or IPv6 format).
+
+    Note: For example, it a possibility is that an external EMS would configure
+    & provision the ONAP contact IP address to the PNF (in either IPv4 or
+    IPv6 format). For the PNF Plug and Play Use Case, this IP address is the
+    service provider's "point of entry" to the DCAE VES Listener.
 
-    Note: different service provider's network architecture may also require special setup to allow an external PNF to contact the ONAP installation. For example, in the AT&T network, a maintenance tunnel is used to access ONAP.
+    Note: different service provider's network architecture may also require
+    special setup to allow an external PNF to contact the ONAP installation.
+    For example, in the AT&T network, a maintenance tunnel is used to access
+    ONAP.
 
 .. req::
     :id: R-793716
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    The PNF **MUST** have ""ONAP Aware"" software which is capable of performing PNF PnP registration with ONAP. The ""ONAP Aware"" software is capable of performing the PNF PnP Registration with ONAP MUST either be loaded separately or integrated into the PNF software upon physical delivery and installation of the PNF.
+    The PNF **MUST** have "ONAP Aware" software which is capable of performing
+    PNF PnP registration with ONAP. The "ONAP Aware" software is capable of
+    performing the PNF PnP Registration with ONAP MUST either be loaded
+    separately or integrated into the PNF software upon physical delivery
+    and installation of the PNF.
 
-    Note: It is up to the specific vendor to design the software management functions. "
+    Note: It is up to the specific vendor to design the software management
+    functions.
 
 .. req::
     :id: R-01427
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
- 
-    The PNF **MUST** support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE (in ONAP).
 
-    Note: In R3, a username and password are used with the DCAE VES Event Listener which are used for HTTP Basic Authentication.
+    The PNF **MUST** support the provisioning of security and authentication
+    parameters (HTTP username and password) in order to be able to authenticate
+    with DCAE (in ONAP).
 
-    Note: The configuration management and provisioning software are specific to a vendor architecture. "
+    Note: In R3, a username and password are used with the DCAE VES Event
+    Listener which are used for HTTP Basic Authentication.
+
+    Note: The configuration management and provisioning software are specific
+    to a vendor architecture.
 
 .. req::
     :id: R-894004
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    When the PNF sets up a HTTP or HTTPS connection, it **MUST** provide a username and password to the DCAE VES Collector for HTTP Basic Authentication.
+    When the PNF sets up a HTTP or HTTPS connection, it **MUST** provide a
+    username and password to the DCAE VES Collector for HTTP Basic
+    Authentication.
 
-    Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, Authorization with Username/Password Credentials, and Authentication Status as per RFC7617 and RFC 2617
+    Note: HTTP Basic Authentication has 4 steps: Request, Authenticate,
+    Authorization with Username/Password Credentials, and Authentication Status
+    as per RFC7617 and RFC 2617.
 
 .. req::
     :id: R-952314
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    If the PNF set up a TLS connection and mutual (two-way) authentication is being used, then the PNF **MUST** provide its own X.509v3 Certificate to the DCAE VES Collector for authentication.
+    If the PNF set up a TLS connection and mutual (two-way) authentication is
+    being used, then the PNF **MUST** provide its own X.509v3 Certificate to
+    the DCAE VES Collector for authentication.
 
-    Note: This allows TLS authentication by DCAE VES Collector..
+    Note: This allows TLS authentication by DCAE VES Collector.
 
-    Note: The PNF got its X.509 certificate through Enrollment with an operator certificate authority or a X.509 vendor certificate from the vendor factory CA.
+    Note: The PNF got its X.509 certificate through Enrollment with an
+    operator certificate authority or a X.509 vendor certificate from the
+    vendor factory CA.
 
     Note: In R3 three authentication options are supported:
 
-    (1) HTTP with Username & Password and no TLS
+    (1) HTTP with Username & Password and no TLS.
 
-    (2) HTTP with Username & Password & TLS with two-way certificate authentication;
+    (2) HTTP with Username & Password & TLS with two-way certificate
+        authentication.
 
-    (3) HTTP with Username & Password & TLS with server-side certificate authentication."
+    (3) HTTP with Username & Password & TLS with server-side
+        certificate authentication.
 
 .. req::
     :id: R-809261
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
     The PNF **MUST** use a IP address to contact ONAP.
 
-    Note: it is expected that an ONAP operator can ascertain the ONAP IP address or the security gateway to reach ONAP on the VID or ONAP portal GUI. Note: The ONAP contact IP address has been previously configured and provisioned prior to this step.
+    Note: it is expected that an ONAP operator can ascertain the ONAP IP
+    address or the security gateway to reach ONAP on the VID or ONAP portal
+    GUI.
+
+    Note: The ONAP contact IP address has been previously configured and
+    provisioned prior to this step.
 
-    Note: The ONAP IP address could be provisioned or resolved through FQDN & DNS.
+    Note: The ONAP IP address could be provisioned or resolved through
+    FQDN & DNS.
 
 .. req::
     :id: R-763774
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    The PNF **MUST** support a HTTPS connection to the DCAE VES Event Listener.
+    The PNF **MUST** support a HTTPS connection to the DCAE VES Event
+    Listener.
 
 .. req::
     :id: R-579051
-    :target: XNF
+    :target: PNF
     :keyword: MAY
     :introduced: casablanca
 
     The PNF **MAY** support a HTTP connection to the DCAE VES Event Listener.
 
-    Note: HTTP is allowed but not recommended."
+    Note: HTTP is allowed but not recommended.
 
 .. req::
     :id: R-686466
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
@@ -142,7 +181,7 @@ The following are the requirements related to PNF Plug and Play.
 
 .. req::
     :id: R-980039
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
@@ -150,69 +189,97 @@ The following are the requirements related to PNF Plug and Play.
 
 .. req::
     :id: R-981585
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
     The pnfRegistration VES event periodicity **MUST** be configurable.
 
-    Note: The PNF uses the service configuration request as a semaphore to stop sending the pnfRegistration sent. See the requirement PNP-5360 requirement."
+    Note: The PNF uses the service configuration request as a semaphore to
+    stop sending the pnfRegistration sent. See the requirement PNP-5360
+    requirement.
 
 .. req::
     :id: R-284934
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    If the PNF encounters an error authenticating, reaching the ONAP DCAE VES Event listener or recieves an error response from sending the pnfRegistration VES Event, it **MAY** log the error, and notify the operator. 
+    If the PNF encounters an error authenticating, reaching the ONAP DCAE VES
+    Event listener or recieves an error response from sending the pnfRegistration
+    VES Event, it **MAY** log the error, and notify the operator.
 
-    Note: the design of how errors are logged, retrieved and reported will be a vendor-specific architecture. Reporting faults and errors is also a vendor specific design. It is expected that the PNF shall have a means to log an error and notify a user when a fault condition occurs in trying to contact ONAP, authenticate or send a pnfRegistration event."
+    Note: the design of how errors are logged, retrieved and reported
+    will be a vendor-specific architecture. Reporting faults and errors
+    is also a vendor specific design. It is expected that the PNF shall
+    have a means to log an error and notify a user when a fault condition
+    occurs in trying to contact ONAP, authenticate or send a pnfRegistration
+    event.
 
 .. req::
     :id: R-256347
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    The PNF **MUST** support the Ansible protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP). 
+    The PNF **MUST** support the Ansible protocol for a Service Configuration
+    message exchange between the PNF and PNF Controller (in ONAP).
 
-    Note: this exchange may be either Ansible, Chef, or NetConf depending on the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported."
+    Note: this exchange may be either Ansible, Chef, or NetConf depending on
+    the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the
+    PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.
 
 .. req::
     :id: R-707977
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    When the PNF receives a Service configuration from ONAP, the PNF **MUST** cease sending the pnfRegistration VES Event.
+    When the PNF receives a Service configuration from ONAP, the PNF **MUST**
+    cease sending the pnfRegistration VES Event.
 
 .. req::
     :id: R-17624
-    :target: XNF
+    :target: PNF
     :keyword: MAY
     :introduced: casablanca
 
-    The PNF **MAY** support the optional parameters for Service Configuration Parameters.
+    The PNF **MAY** support the optional parameters for Service
+    Configuration Parameters.
 
-    Note: These are detailed in the Stage 5 PnP 
+    Note: These are detailed in the Stage 5 PnP
 
-    Note: These parameters are optional, and not all PNFs will support any or all of these parameters, it is up to the vendor and service provider to ascertain which ones are supported up to an including all of the ones that have been defined. Note: It is expected that there will be a growing list of supported configuration parameters in future releases of ONAP."
+    Note: These parameters are optional, and not all PNFs will support any
+    or all of these parameters, it is up to the vendor and service provider
+    to ascertain which ones are supported up to an including all of the ones
+    that have been defined. Note: It is expected that there will be a growing
+    list of supported configuration parameters in future releases of ONAP.
 
 .. req::
     :id: R-378131
-    :target: XNF
+    :target: PNF
     :keyword: MAY
     :introduced: casablanca
 
-    (Error Case) - If an error is encountered by the PNF during a Service Configuration exchange with ONAP, the PNF **MAY** log the error and notify an operator.
+    (Error Case) - If an error is encountered by the PNF during a
+    Service Configuration exchange with ONAP, the PNF **MAY** log the
+    error and notify an operator.
 
 .. req::
     :id: R-638216
-    :target: XNF
+    :target: PNF
     :keyword: MUST
     :introduced: casablanca
 
-    (Error Case) - The PNF **MUST** support a configurable timer to stop the periodicity sending of the pnfRegistration VES event. If this timer expires during a Service Configuration exchange between the PNF and ONAP, it MAY log a time-out error and notify an operator.
-
-    Note: It is expected that each vendor will enforce and define a PNF service configuration timeout period. This is because the PNF cannot wait indefinitely as there may also be a technician on-site trying to complete installation & commissioning. The management of the VES event exchange is also a requirement on the PNF to be developed by the PNF vendor."
+    (Error Case) - The PNF **MUST** support a configurable timer to stop the
+    periodicity sending of the pnfRegistration VES event. If this timer expires
+    during a Service Configuration exchange between the PNF and ONAP, it
+    MAY log a time-out error and notify an operator.
+
+    Note: It is expected that each vendor will enforce and define a PNF
+    service configuration timeout period. This is because the PNF cannot
+    wait indefinitely as there may also be a technician on-site trying to
+    complete installation & commissioning. The management of the VES event
+    exchange is also a requirement on the PNF to be developed by the PNF
+    vendor.