VNFRQTS - update HEAT Batch 2

Including changes for sections 5.6 - 5.9

Issue-ID: VNFRQTS-438

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

6 files changed, 480 insertions, 535 deletions

diff --git a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
index 90fb33b..8c10e4b 100644
--- a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
@@ -45,8 +45,8 @@ 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',
-then the corresponding input parameter **MUST** be declared as type 'json'.
+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
 required by a single Incremental module or Base module.
@@ -79,94 +79,90 @@ Optional Property availability_zone
     :id: R-25190
     :target: VNF
     :keyword: SHOULD NOT
+    :updated: casablanca
 
-    A VNF's Heat Orchestration Template's Resource 'OS::Cinder::Volume'
-    **SHOULD NOT** declare the property 'availability_zone'.
+    A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
+    **SHOULD NOT** declare the property ``availability_zone``.
 
 If the property is used, the value **MUST**
-be enumerated in the environment file and must be set to nova', which
+be enumerated in the environment file and must be set to ``nova``, which
 is the default. There are no requirements on the parameter naming
 convention with the exception that the naming convention **MUST NOT** be the
-same as the 'OS::Nova::Server' property 'availability_zone' (i.e.,
-'availability_zone_{index}').
+same as the ``OS::Nova::Server`` property ``availability_zone`` (i.e.,
+``availability_zone_{index}``).
 
 Optional Property volume_type
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-OpenStack supports multiple volume types. If the OS::Cinder::Volume optional
-property volume_type is not specified, the OpenStack default volume type is
-used. If a specific volume type is required, the property is used and
-the value **MUST** be enumerated in the environment file. There are no
-requirements on the parameter naming convention
+OpenStack supports multiple volume types. If the ``OS::Cinder::Volume``
+optional property ``volume_type`` is not specified, the OpenStack default
+``volume type`` is used. If a specific volume type is required, the property
+is used and the value **MUST** be enumerated in the environment file. There
+are no requirements on the parameter naming convention.
 
 Cinder Volume Examples
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 *Examples: Volume Template*
 
-A VNF has a Cinder volume module, named incremental\_volume.yaml, that
-creates an independent Cinder volume for a VM in the module
-incremental.yaml. The incremental\_volume.yaml defines a parameter in
-the output section, lb\_volume\_id\_0 which is the UUID of the cinder
-volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
-ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
+A VNF has a Cinder volume module, named incremental_volume.yaml,
+that creates an independent Cinder volume for a VM in the module
+incremental.yaml. The incremental_volume.yaml defines a parameter in
+the output section, dns_volume_id_0 which is the UUID of the cinder volume.
+dns_volume_id_0 is defined as a parameter in incremental.yaml.
+ONAP captures the UUID value of dns_volume_id_0 from the volume module
 output statement and provides the value to the incremental module.
 
 Note that the example below is not a complete Heat Orchestration
-Template. The {vm-type} has been defined as "lb" for load balancer
+Template. The {vm-type} has been defined as "dns".
 
-incremental\_volume.yaml
+incremental_volume.yaml
 
 .. code-block:: yaml
 
- parameters:
+  parameters:
     vnf_name:
-       type: string
-    lb_volume_size_0:
-       type: number
-    ...
+      type: string
+    dns_volume_size_0:
+      type: number
+  ...
 
- resources:
+  resources:
     dns_volume_0:
-       type: OS::Cinder::Volume
-       properties:
-          name:
-             str_replace:
-                template: VNF_NAME_volume_0
-                params:
-                   VNF_NAME: { get_param: vnf_name }
-          size: {get_param: dns_volume_size_0}
-    ...
-
- outputs:
-    lb_volume_id_0:
-       value: {get_resource: dns_volume_0}
-    ...
-
+      type: OS::Cinder::Volume
+      properties:
+        name:
+          str_replace:
+            template: VNF_NAME_volume_0
+            params:
+              VNF_NAME: { get_param: vnf_name }
+        size: {get_param: dns_volume_size_0}
+  ...
+  outputs:
+    dns_volume_id_0:
+      value: {get_resource: dns_volume_0}
+  ...
 
 incremental.yaml
 
 .. code-block:: yaml
 
- parameters:
-    lb_name_0:
-       type: string
-    lb_volume_id_0:
-       type: string
-    ...
-
- resources:
-    lb_0:
-       type: OS::Nova::Server
-       properties:
-          name: {get_param: dns_name_0}
-          networks:
-          ...
-
-    lb_0_volume_attach:
-       type: OS::Cinder::VolumeAttachment
-       properties:
-          instance_uuid: { get_resource: lb_0 }
-          volume_id: { get_param: lb_volume_id_0 }
-
-
+  parameters:
+    dns_server_0:
+      type: string
+    dns_volume_id_0:
+      type: string
+  ...
+
+  resources:
+    dns_server_0:
+      type: OS::Nova::Server
+      properties:
+        name: {get_param: dns_name_0}
+        networks:
+  ...
+    dns_volume_attach_0:
+      type: OS::Cinder::VolumeAttachment
+      properties:
+        instance_uuid: { get_resource: dns_server_0 }
+        volume_id: { get_param: dns_volume_id_0 }
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 ba8cd68..aed56e5 100644
--- a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
@@ -12,32 +12,14 @@ mandatory. A Heat Orchestration Template uploaded to ONAP must have a
 corresponding environment file, even if no parameters are required to
 be enumerated.
 
-(Note that ONAP does not programmatically enforce the use of
-an environment file.)
+*(Note that ONAP does not programmatically enforce the use of
+an environment file.)*
 
-.. req::
-    :id: R-67205
-    :target: VNF
-    :keyword: MUST
+As stated in :need:`R-38474`, :need:`R-81725`, and :need:`R-53433`:
 
-    The VNF Heat Orchestration Template **MUST** have a corresponding
-    environment file for a Base Module.
-
-.. req::
-    :id: R-35727
-    :target: VNF
-    :keyword: MUST
-
-    The VNF Heat Orchestration Template **MUST** have a
-    corresponding environment file for an Incremental module.
-
-.. req::
-    :id: R-22656
-    :target: VNF
-    :keyword: MUST
-
-    The VNF Heat Orchestration Template **MUST** have a
-    corresponding environment file for a Cinder Volume Module.
+  * 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 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 f24d2f4..76ec0c1 100644
--- a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
@@ -21,11 +21,13 @@ either statically by repeated definition or dynamically by using the
 resource OS::Heat::ResourceGroup.
 
 Nested Heat Template Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-ONAP supports nested Heat Orchestration Templates. A Base Module,
-Incremental Module, and Cinder Volume Module may use nested heat.
+ONAP supports nested Heat Orchestration Templates.
 
+As stated in Requirements :need:`R-36582`, :need:`R-56721`, and
+:need:`R-30395`, a Base Module, Incremental Module, and Cinder Volume
+Module may use nested heat.
 
 .. req::
     :id: R-00228
@@ -39,42 +41,50 @@ Incremental Module, and Cinder Volume Module may use nested heat.
     :id: R-01101
     :target: VNF
     :keyword: MAY
+    :updated: casablanca
 
     A VNF's Heat Orchestration Template **MAY**
     reference the nested heat dynamically using the resource
-    'OS::Heat::ResourceGroup'.
+    ``OS::Heat::ResourceGroup``.
 
 .. req::
     :id: R-60011
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     A VNF's Heat Orchestration Template **MUST** have no more than
     two levels of nesting.
 
-As stated in :need:`R-67231` a VNF's Heat Orchestration template's
-Environment File's **MUST NOT** contain the "resource_registry:" section.
+.. req:: 
+    :id: R-70112
+    :target: VNF
+    :keyword: MUST
+    :validation_mode: static
+    :introduced: casablanca
+
+    A VNF's Heat Orchestration Template **MUST** reference a Nested YAML
+    file by name. The use of ``resource_registry`` in the VNF's Heat
+    Orchestration Templates Environment File **MUST NOT** be used.
 
 Two levels of nesting is defined as follows:  A base module, incremental
 module, or cinder volume module references a nested heat file either
-statically or by using the resource 'OS::Heat::ResourceGroup'.
-This file is the first level of nesting.
-If first level file then references a nested file, that file is
-the second level of nesting.
-
+statically or by using the resource ``OS::Heat::ResourceGroup``.
+The referenced YAML heat file is the first level of nested heat.
+If first level nested YAML file references a nested heat file, that file is
+the second level of nested heat.
 
-.. req::
-    :id: R-89868
-    :target: VNF
-    :keyword: MUST
-
-    The VNF Heat Orchestration Template **MUST** have unique
-    file names within the scope of the VNF for a nested heat yaml file.
+As stated in requirement :need:`R-99646`, a VNF's YAML files
+(i.e, Heat Orchestration Template files and Nested files) **MUST**
+have a unique name in the scope of the VNF.
 
 .. req::
     :id: R-52530
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     A VNF's Heat Orchestration Template's Nested YAML file
     **MUST** be in the same directory hierarchy as the VNF's Heat
@@ -97,10 +107,16 @@ the second level of nesting.
     a VNF's Heat Orchestration Templates (when the VNF is composed of two
     or more Heat Orchestration Templates).
 
+Note that as stated in requirement :need:`R-00011`, a VNF's Heat Orchestration
+Template's Nested YAML file's parameter's **MUST NOT** have a parameter
+constraint defined.
+
 .. req::
     :id: R-11041
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     All parameters defined in a VNFs Nested YAML file
     **MUST** be passed in as properties of the resource calling
@@ -108,66 +124,64 @@ the second level of nesting.
 
 Note that:
 
--  As stated in requirement :need:`R-00011`, a VNF's Heat Orchestration
-   Template's Nested YAML file's parameter's **MUST NOT** have
-   a parameter constraint defined.
-
--  As stated in Requirement :need:`R-44491`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'vnf\_id' is passed into a Nested YAML
-   file, the parameter name 'vnf\_id' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-86237`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'vf\_module\_id' is passed into a Nested YAML
-   file, the parameter name 'vf\_module\_id' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-16576`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'vnf\_name' is passed into a Nested YAML
-   file, the parameter name 'vnf\_name' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-49177`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'vf\_module\_name' is passed into a Nested YAML
-   file, the parameter name 'vf\_module\_name' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-70757`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'vm\_role' is passed into a Nested YAML
-   file, the parameter name 'vm\_role' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-22441`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'vf\_module\_index' is passed into a Nested YAML
-   file, the parameter name 'vf\_module\_index' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-75202`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'workload\_context' is passed into a Nested YAML
-   file, the parameter name 'workload\_context' **MUST NOT** change.
-
--  As stated in Requirement :need:`R-62954`, if a VNF's Heat Orchestration
-   Template's OS::Nova::Server Resource metadata map value parameter
-   'environment\_context' is passed into a Nested YAML
-   file, the parameter name 'environment\_context' **MUST NOT** change.
-
--  With nested templates, outputs are required to expose any resource
-   properties of the child templates to the parent template. Those would
-   not explicitly be declared as parameters but simply referenced as
-   get\_attribute targets against the "parent" resource.
-
--  A parameter declared in the outputs: section of a nested template can
-   be accessed from the parent template as an attribute (i.e., via
-   get\_attr) of the "pseudo resource" whose type is in the nested
-   template. In the case of a OS::Heat::ResourceGroup, an output will be
-   an attribute of the OS::Heat::ResourceGroup itself, and will be an
-   array from the perspective of the parent template.
+As stated in Requirement :need:`R-44491`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vnf_id`` is passed into a Nested YAML file, the parameter name
+``vnf_id`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-86237`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vf_module_id`` is passed into a Nested YAML file, the parameter name
+``vf_module_id`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-16576`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vnf_name`` is passed into a Nested YAML file, the parameter name
+``vnf_name`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-49177`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vf_module_name`` is passed into a Nested YAML file, the parameter name
+``vf_module_name`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-70757`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vm_role`` is passed into a Nested YAML file, the parameter name
+``vm_role`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-22441`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vf_module_index`` is passed into a Nested YAML file, the parameter
+name ``vf_module_index`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-75202`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``workload_context`` is passed into a Nested YAML file, the parameter
+name ``workload_context`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-62954`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``environment_context`` is passed into a Nested YAML file, the parameter
+name ``environment_context`` **MUST NOT** change.
+
+With nested templates, outputs are required to expose any resource
+properties of the child templates to the parent template. Those would
+not explicitly be declared as parameters but simply referenced as
+``get_attribute`` targets against the "parent" resource.
+
+A parameter declared in the outputs: section of a nested template can
+be accessed from the parent template as an attribute (i.e., via
+``get_attr``) of the "pseudo resource" whose type is in the nested
+template. In the case of a ``OS::Heat::ResourceGroup``, an output will be
+an attribute of the ``OS::Heat::ResourceGroup`` itself, and will be an
+array from the perspective of the parent template.
 
 .. req::
     :id: R-17528
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     A VNF's Heat Orchestration Template's first level Nested YAML file
     **MUST NOT** contain more than one ``OS::Nova::Server`` resource.
@@ -181,71 +195,71 @@ incremental.yaml
 
 .. code-block:: yaml
 
- Resources:
-   dns_server_0:
-     type: nested.yaml
-     properties:
-       dns_image_name: { get_param: dns_image_name }
-       dns_flavor_name: { get_param: dns_flavor_name }
-       availability_zone: { get_param: availability_zone_0 }
-       security_group: { get_param: DNS_shared_sec_grp_id }
-       oam_net_id: { get_param: oam_protected_net_id }
-       dns_oam_ip: { get_param: dns_oam_ip_0 }
-       dns_name: { get_param: dns_name_0 }
-       vnf_name: { get_param: vnf_name }
-       vnf_id: { get_param: vnf_id }
-       vf_module_id: {get_param: vf_module_id}
-
- dns_server_1:
-   type: nested.yaml
-   properties:
-     dns_image_name: { get_param: dns_image_name }
-     dns_flavor_name: { get_param: dns_flavor_name }
-     availability_zone: { get_param: availability_zone_1 }
-     security_group: { get_param: DNS_shared_sec_grp_id }
-     oam_net_id: { get_param: oam_protected_net_id }
-     dns_oam_ip: { get_param: dns_oam_ip_1 }
-     dns_name: { get_param: dns_name_1 }
-     vnf_name: { get_param: vnf_name }
-     vnf_id: { get_param: vnf_id }
-     vf_module_id: {get_param: vf_module_id}
+  resources:
+    dns_server_0:
+      type: nested.yaml
+      properties:
+        dns_image_name: { get_param: dns_image_name }
+        dns_flavor_name: { get_param: dns_flavor_name }
+        availability_zone: { get_param: availability_zone_0 }
+        security_group: { get_param: DNS_shared_sec_grp_id }
+        oam_net_id: { get_param: oam_protected_net_id }
+        dns_oam_ip: { get_param: dns_oam_ip_0 }
+        dns_name: { get_param: dns_name_0 }
+        vnf_name: { get_param: vnf_name }
+        vnf_id: { get_param: vnf_id }
+        vf_module_id: {get_param: vf_module_id}
+
+    dns_server_1:
+      type: nested.yaml
+      properties:
+        dns_image_name: { get_param: dns_image_name }
+        dns_flavor_name: { get_param: dns_flavor_name }
+        availability_zone: { get_param: availability_zone_1 }
+        security_group: { get_param: DNS_shared_sec_grp_id }
+        oam_net_id: { get_param: oam_protected_net_id }
+        dns_oam_ip: { get_param: dns_oam_ip_1 }
+        dns_name: { get_param: dns_name_1 }
+        vnf_name: { get_param: vnf_name }
+        vnf_id: { get_param: vnf_id }
+        vf_module_id: {get_param: vf_module_id}
 
 nested.yaml
 
 .. code-block:: yaml
 
- dns_oam_0_port:
-   type: OS::Neutron::Port
-   properties:
-     name:
-       str_replace:
-         template: VNF_NAME_dns_oam_port
-         params:
-           VNF_NAME: {get_param: vnf_name}
-     network: { get_param: oam_net_id }
-     fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
-     security_groups: [{ get_param: security_group }]
-
- dns_servers:
-   type: OS::Nova::Server
-   properties:
-     name: { get_param: dns_names }
-     image: { get_param: dns_image_name }
-     flavor: { get_param: dns_flavor_name }
-     availability_zone: { get_param: availability_zone }
-     networks:
-       - port: { get_resource: dns_oam_0_port }
-     metadata:
-       vnf_id: { get_param: vnf_id }
-       vf_module_id: { get_param: vf_module_id }
-       vnf_name {get_param: vnf_name }
+  dns_oam_0_port:
+    type: OS::Neutron::Port
+    properties:
+      name:
+        str_replace:
+          template: VNF_NAME_dns_oam_port
+          params:
+            VNF_NAME: {get_param: vnf_name}
+      network: { get_param: oam_net_id }
+      fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
+      security_groups: [{ get_param: security_group }]
+
+  dns_servers:
+    type: OS::Nova::Server
+    properties:
+      name: { get_param: dns_names }
+      image: { get_param: dns_image_name }
+      flavor: { get_param: dns_flavor_name }
+      availability_zone: { get_param: availability_zone }
+      networks:
+      - port: { get_resource: dns_oam_0_port }
+      metadata:
+        vnf_id: { get_param: vnf_id }
+        vf_module_id: { get_param: vf_module_id }
+        vnf_name {get_param: vnf_name }
 
 Use of Heat ResourceGroup
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The OS::Heat::ResourceGroup is a useful Heat element for creating
 multiple instances of a given resource or collection of resources.
-Typically, it is used with a nested Heat template, to create, for
+Typically, it is used with a nested Heat template to create, for
 example, a set of identical OS::Nova::Server resources plus their
 related OS::Neutron::Port resources via a single resource in a master
 template.
@@ -267,11 +281,13 @@ OS::Heat::ResourceGroup:
 
 .. code-block:: yaml
 
- type: OS::Heat::ResourceGroup
-   resource_def:
-     type: my_nested_vm_template.yaml
-     properties:
-       name: {get_param: [vm_name_list, "%index%"]}
+  type: OS::Heat::ResourceGroup
+  properties:
+      . . .
+      resource_def:
+        type: my_nested_vm_template.yaml
+        properties:
+          name: {get_param: [vm_name_list, "%index%"]}
 
 Although this appears to use the nth entry of the vm_name_list list for
 the nth element of the OS::Heat::ResourceGroup, it will in fact result
@@ -285,16 +301,18 @@ ResourceGroup:
 
 .. code-block:: yaml
 
- type: OS::Heat::ResourceGroup
-   resource_def:
-     type: my_nested_vm_template.yaml
-     properties:
-       names: {get_param: vm_name_list}
-       index: "%index%"
+  type: OS::Heat::ResourceGroup
+  properties:
+    . . .
+    resource_def:
+      type: my_nested_vm_template.yaml
+      properties:
+        names: {get_param: vm_name_list}
+        index: "%index%"
 
 You can then reference within the nested template as:
 
-{ get\_param: [names, {get\_param: index} ] }
+{ get_param: [names, {get_param: index} ] }
 
 OS::Heat::ResourceGroup Property count
 ++++++++++++++++++++++++++++++++++++++++
@@ -304,9 +322,11 @@ OS::Heat::ResourceGroup Property count
     :id: R-50011
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
-    A VNF's Heat Orchestration Template's 'OS::Heat::ResourceGroup'
-    property 'count' **MUST** be enumerated in the VNF's
+    A VNF's Heat Orchestration Template's ``OS::Heat::ResourceGroup``
+    property ``count`` **MUST** be enumerated in the VNF's
     Heat Orchestration Template's Environment File and **MUST** be
     assigned a value.
 
@@ -314,63 +334,63 @@ This is required for ONAP to build the TOSCA model for the VNF.
 
 .. code-block:: yaml
 
- type: OS::Heat::ResourceGroup
- properties:
-   count: { get_param: count }
-   index_var: index
-   resource_def:
-     type: my_nested_vm_template.yaml
-     properties:
-       names: {get_param: vm_name_list}
-       index: index
+  type: OS::Heat::ResourceGroup
+  properties:
+    count: { get_param: count }
+    index_var: index
+    resource_def:
+      type: my_nested_vm_template.yaml
+      properties:
+        names: {get_param: vm_name_list}
+        index: index
 
 Availability Zone and ResourceGroups
 ++++++++++++++++++++++++++++++++++++++++
 
-The resource OS::Heat::ResourceGroup and the property availability\_zone
+The resource OS::Heat::ResourceGroup and the property availability_zone
 has been an "issue" with a few VNFs since ONAP only supports
-availability\_zone as a string parameter and not a
-comma\_delimited\_list. This makes it difficult to use a
-OS::Heat::ResourceGroup to create Virtual Machines in more
-than one availability zone.
+availability_zone as a string parameter and not as a
+comma_delimited_list. This makes it difficult to use a
+OS::Heat::ResourceGroup to create Virtual Machines in more than one
+availability zone.
 
 There are numerous solutions to this issue. Below are two suggested
 usage patterns.
 
 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
-resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
-availability\_zones by using the intrinsic function list\_join.
+resource type: OS::Heat::ResourceGroup, create a comma_delimited_list
+availability_zones by using the intrinsic function list_join.
 
 .. code-block:: yaml
 
- <resource name>:
-  type: OS::Heat::ResourceGroup
-  properties:
-    count: { get_param: node_count }
-    index_var: index
-    resource_def:
-      type: nested.yaml
-      properties:
-        index: index
-        avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
+  <resource name>:
+    type: OS::Heat::ResourceGroup
+    properties:
+      count: { get_param: node_count }
+      index_var: index
+      resource_def:
+        type: nested.yaml
+        properties:
+          index: index
+          availability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
 
 In the nested heat
 
 .. code-block:: yaml
 
- parameters:
-   avaialability_zones:
-     type: comma_delimited_list
-     description:
+  parameters:
+    availability_zones:
+      type: comma_delimited_list
+      description:
 
- resources:
-   servers:
-     type: OS::Nova::Server
-     properties:
-       name: { get_param: [ dns_names, get_param: index ] }
-       image: { get_param: dns_image_name }
-       flavor: { get_param: dns_flavor_name }
-       availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
+  resources:
+    servers:
+      type: OS::Nova::Server
+      properties:
+        name: { get_param: [ dns_names, get_param: index ] }
+        image: { get_param: dns_image_name }
+        flavor: { get_param: dns_flavor_name }
+        availability_zone: { get_param: [ availability_zones, get_param: index ] }
 
 **Option 2:** Create a CDL by passing the availability zone parameter
 into a nested heat template. An example is provided below.
@@ -426,21 +446,21 @@ az_list_generate.yaml
 Nested Heat Template Example: OS::Heat::ResourceGroup
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-In this example, ocgapp\_volume.yml creates volumes using a
+In this example, ocgapp_volume.yml creates volumes using a
 OS::Heat::ResourceGroup that uses nested heat by calling
-ocgapp_nested_volume.yml. ocgapp\_volume.yml has an outputs: parameter
-ocgapp\_volume\_ids which is declared a input parameter of type: json in
-ocgapp\_volume.yml.
+ocgapp_nested_volume.yml. ocgapp_volume.yml has an outputs: parameter
+ocgapp_volume_ids which is declared a input parameter of type: json in
+ocgapp_volume.yml.
 
 
 This is an example of requirement :need:`R-07443`, where
 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'.
+Parameter is of the type ``comma_delimited_list``, then the corresponding
+input parameter **MUST** be declared as type ``json``.
 
-ocgapp\_volume.yml
+ocgapp_volume.yml
 
 .. code-block:: yaml
 
@@ -532,6 +552,14 @@ ocgapp_nested_volume.yml
    description: the ocgapp volume uuid
    value: {get_resource: ocgapp_volume_0}
 
+Below is a screen shot of parameter ocgapp_volume_ids from the OpenStack
+Horizon GUI showing the output.
+
+.. image:: ../../heat_picture3.png
+  :height: 334px
+  :width: 1186px
+  :scale: 50 %
+
 The heat template below is a partial heat template,
 
 ocgapp.yml
@@ -571,19 +599,19 @@ ocgapp.yml
 External References
 ^^^^^^^^^^^^^^^^^^^^^^
 
-Heat templates *should not* reference any HTTP-based resource
+Heat templates *must not* reference any HTTP-based resource
 definitions, any HTTP-based nested configurations, or any HTTP-based
 environment files.
 
--  During orchestration, ONAP *should not* retrieve any such resources
+-  During orchestration, ONAP *must not* retrieve any such resources
    from external/untrusted/unknown sources.
 
--  VNF images should not contain such references in user-data or other
+-  VNF images must not contain external references in user-data or other
    configuration/operational scripts that are specified via Heat or
    encoded into the VNF image itself.
 
-*Note:* HTTP-based references are acceptable if the HTTP-based reference
-is accessing information with the VM private/internal network.
+*Note: HTTP-based references are acceptable if the HTTP-based reference
+is accessing information utilizing the VM private/internal network.*
 
 Note that Namespaces in XML (defined at
 http://www.w3.org/TR/2009/REC-xml-names-20091208/) are allowed if the
@@ -597,11 +625,11 @@ Name (URN). The namespace URI is not used by XML the parser to look up
 information. The purpose of using an URI is to give the namespace a
 unique name.
 
-Heat Files Support (get\_file)
+Heat Files Support (get_file)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Heat Templates may contain the inclusion of text files into Heat
-templates via the Heat get\_file directive. This may be used, for
+templates via the Heat get_file directive. This may be used, for
 example, to define a common "user-data" script, or to inject files into
 a VM on startup via the "personality" property.
 
@@ -612,12 +640,14 @@ Support for Heat Files is subject to the following limitations:
     :id: R-76718
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     If a VNF's Heat Orchestration Template uses the intrinsic function
-    'get\_file', the 'get\_file' target **MUST** be referenced in
+    ``get_file``, the ``get_file`` target **MUST** be referenced in
     the Heat Orchestration Template by file name.
 
-The 'get\_file' target files are on-boarded to SDC in the same package
+The ``get_file`` target files are on-boarded to SDC in the same package
 that contains the VNF's complete Heat Orchestration Template.
 
 
@@ -625,14 +655,18 @@ that contains the VNF's complete Heat Orchestration Template.
     :id: R-41888
     :target: VNF
     :keyword: MUST NOT
+    :validation_mode: static
+    :updated: casablanca
 
     A VNF's Heat Orchestration Template intrinsic function
-    'get\_file' **MUST NOT** utilize URL-based file retrieval.
+    ``get_file`` **MUST NOT** utilize URL-based file retrieval.
 
 .. req::
     :id: R-62177
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     When using the intrinsic function get_file, the included files
     **MUST** have unique file names within the scope of the VNF.
@@ -641,22 +675,26 @@ that contains the VNF's complete Heat Orchestration Template.
     :id: R-87848
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
-    A VNF's Heat Orchestration Template's 'get\_file' target files
-    **MUST** be in the same directory hierarchy as the VNF's Heat
-    Orchestration Templates.
+    When using the intrinsic function get_file, ONAP does not support
+    a directory hierarchy for included files. All files must be in a
+    single, flat directory per VNF. A VNF's Heat Orchestration
+    Template's ``get_file`` target files **MUST** be in the same
+    directory hierarchy as the VNF's Heat Orchestration Templates.
 
 ONAP does not support a hierarchical structure.  A VNF's YAML files
 must be in a single, flat directory.
 
-
 .. req::
     :id: R-05050
     :target: VNF
     :keyword: MAY
+    :updated: casablanca
 
     A VNF's Heat Orchestration Templates intrinsic function
-    'get\_file' <content key> **MAY** be used:
+    ``get_file`` <content key> **MAY** be used:
 
         * more than once in a VNF's Heat Orchestration Template
         * in two or more of a VNF's Heat Orchestration Templates
@@ -687,10 +725,10 @@ Due to this behavior, the recommended usage of keypairs is in a more
 generic manner which does not require the pre-requisite creation of a
 keypair. The Heat should be structured in such a way as to:
 
--  Pass a public key as a parameter value instead of a keypair name
+ -  Pass a public key as a parameter value instead of a keypair name
 
--  Create a new keypair within The VNF Heat Orchestration Template (in the
-   base module) based on an existing public key for use within that VNF
+ -  Create a new keypair within the VNF Heat templates (in the base module)
+    based on an existing public key for use within that VNF
 
 By following this approach, the end result is the same as pre-creating
 the keypair using the public key – i.e., that public key will be
@@ -709,23 +747,23 @@ of lb (for load balancer)):*
 
 .. code-block:: yaml
 
- parameters:
+  parameters:
     vnf_name:
-       type: string
+      type: string
     lb_ssh_public_key:
-       type: string
+      type: string
 
- resources:
-    my_keypair:
-       type: OS::Nova::Keypair
-       properties:
-          name:
-             str_replace:
-                template: VNF_NAME_key_pair
-                params:
-                VNF_NAME: { get_param: vnf_name }
-          public_key: {get_param: lb_ssh_public_key}
-          save_private_key: false
+  resources:
+    lb_keypair_0:
+      type: OS::Nova::Keypair
+      properties:
+        name:
+          str_replace:
+            template: VNF_NAME_key_pair
+            params:
+              VNF_NAME: { get_param: vnf_name }
+        public_key: {get_param: lb_ssh_public_key}
+        save_private_key: false
 
 Security Groups
 ^^^^^^^^^^^^^^^^^
@@ -759,49 +797,45 @@ balancer and db for database.
 
 .. code-block:: yaml
 
- resources:
- db_server_group:
-    type: OS::Nova::ServerGroup
-    properties:
-       name:
+  resources:
+    db_server_group:
+      type: OS::Nova::ServerGroup
+      properties:
+        name:
           str_replace:
-             params:
-                $vnf_name: {get_param: vnf_name}
-             template: $vnf_name-server_group1
-       policies:
-          - anti-affinity
-
- lb_server_group:
-    type: OS::Nova::ServerGroup
-    properties:
-       name:
+            params:
+              $vnf_name: {get_param: vnf_name}
+            template: $vnf_name-server_group1
+        policies:
+        - anti-affinity
+    lb_server_group:
+      type: OS::Nova::ServerGroup
+      properties:
+        name:
           str_replace:
-             params:
-                $vnf_name: {get_param: vnf_name}
-             template: $vnf_name-server_group2
-       policies:
-          - affinity
-
- db_0:
-    type: OS::Nova::Server
-    properties:
-    ...
-    scheduler_hints:
-       group: {get_resource: db_server_group}
-
- db_1:
-    type: OS::Nova::Server
-    properties:
-    ...
-    scheduler_hints:
-       group: {get_resource: db_server_group}
-
- lb_0:
-    type: OS::Nova::Server
-    properties:
-    ...
-    scheduler_hints:
-       group: {get_resource: lb_server_group} 
+            params:
+              $vnf_name: {get_param: vnf_name}
+            template: $vnf_name-server_group2
+        policies:
+        - affinity
+    db_server_0:
+      type: OS::Nova::Server
+      properties:
+        ...
+        scheduler_hints:
+        group: {get_resource: db_server_group}
+    db_server_1:
+      type: OS::Nova::Server
+      properties:
+        ...
+        scheduler_hints:
+        group: {get_resource: db_server_group}
+    lb_server_0:
+      type: OS::Nova::Server
+      properties:
+        ...
+        scheduler_hints:
+        group: {get_resource: lb_server_group} 
 
 Resource Data Synchronization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -809,7 +843,7 @@ Resource Data Synchronization
 For cases where synchronization is required in the orchestration of Heat
 resources, two approaches are recommended:
 
--  Standard Heat depends\_on property for resources
+-  Standard Heat depends_on property for resources
 
    -  Assures that one resource completes before the dependent resource
       is orchestrated.
@@ -823,12 +857,12 @@ resources, two approaches are recommended:
    -  Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
       resources.
 
-   -  Pre-requisite resources issue *wc\_notify* commands in user\_data.
+   -  Pre-requisite resources issue *wc_notify* commands in user_data.
 
-   -  Dependent resource define depends\_on in the
+   -  Dependent resource define depends_on in the
       OS::Heat::WaitCondition resource.
 
-*Example: "depends\_on" case*
+*Example: "depends_on" case*
 
 In this example, the {network-role} has been defined as oam to represent
 an oam network and the {vm-type} has been defined as oam to represent an
@@ -836,41 +870,38 @@ oam server.
 
 .. code-block:: yaml
 
- resources:
-   oam_server_01:
-     type: OS::Nova::Server
-     properties:
-       name: {get_param: [oam_ names, 0]}
-       image: {get_param: oam_image_name}
-       flavor: {get_param: oam_flavor_name}
-       availability_zone: {get_param: availability_zone_0}
-       networks:
-         - port: {get_resource: oam01_port_0}
-         - port: {get_resource: oam01_port_1}
-       user_data:
-       scheduler_hints: {group: {get_resource: oam_servergroup}}
-       user_data_format: RAW
-
- oam_01_port_0:
-   type: OS::Neutron::Port
-   properties:
-     network: {get_resource: oam_net_name}
-     fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
-     security_groups: [{get_resource: oam_security_group}]
-
- oam_01_port_1:
-   type: OS::Neutron::Port
-   properties:
-     network: {get_param: oam_net_name}
-     fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
-     security_groups: [{get_resource: oam_security_group}]
-
- oam_01_vol_attachment:
-   type: OS::Cinder::VolumeAttachment
-   depends_on: oam_server_01
-   properties:
-     volume_id: {get_param: oam_vol_1}
-     mountpoint: /dev/vdb
-     instance_uuid: {get_resource: oam_server_01}
+  resources:
+    oam_server_01:
+      type: OS::Nova::Server
+      properties:
+        name: {get_param: [oam_names, 0]}
+        image: {get_param: oam_image_name}
+        flavor: {get_param: oam_flavor_name}
+        availability_zone: {get_param: availability_zone_0}
+        networks:
+        - port: {get_resource: oam01_port_0}
+        - port: {get_resource: oam01_port_1}
+        user_data:
+        scheduler_hints: {group: {get_resource: oam_servergroup}}
+        user_data_format: RAW
+    oam_01_port_0:
+      type: OS::Neutron::Port
+      properties:
+        network: {get_resource: oam_net_name}
+        fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
+        security_groups: [{get_resource: oam_security_group}]
+    oam_01_port_1:
+      type: OS::Neutron::Port
+      properties:
+        network: {get_param: oam_net_name}
+        fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
+        security_groups: [{get_resource: oam_security_group}]
+    oam_volume_attachment_0:
+      type: OS::Cinder::VolumeAttachment
+      depends_on: oam_server_01
+      properties:
+        volume_id: {get_param: oam_vol_1}
+        mountpoint: /dev/vdb
+        instance_uuid: {get_resource: oam_server_01}
 
 
diff --git a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
index 70ba197..7e1ebe3 100644
--- a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
+++ b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
@@ -15,12 +15,12 @@ referred to as *VNF Modules*. During orchestration, these modules
 are deployed incrementally to create the complete VNF.
 
 As stated in :need:`R-33132`, a VNF's Heat Orchestration Template **MAY** be
-     1.) Base Module Heat Orchestration Template (also referred to as a
-      Base Module),
-     2.) Incremental Module Heat Orchestration Template (referred to as
-      an Incremental Module), or
-     3.) a Cinder Volume Module Heat Orchestration Template (referred to as
-      Cinder Volume  Module).
+     1. Base Module Heat Orchestration Template (also referred to as a
+        Base Module),
+     2. Incremental Module Heat Orchestration Template (referred to as
+        an Incremental Module), or
+     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.
@@ -39,6 +39,9 @@ As stated in :need:`R-37028` and :need:`R-13196`, a VNF **MUST** be composed
 of one Base Module and *MAY** be composed of zero to many 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.
+
 ONAP also supports the concept of an optional, independently deployed
 Cinder volume via a separate Heat Orchestration Templates, referred to
 as a Cinder Volume Module. This allows the volume to persist after a VM
@@ -58,6 +61,8 @@ Incremental Module.
     :id: R-61001
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     A shared Heat Orchestration Template resource must be defined
     in the base module. A shared resource is a resource that that will
@@ -71,6 +76,9 @@ When the shared resource needs to be referenced by a resource in an
 incremental module, the UUID of the shared resource must be exposed by
 declaring an ONAP Base Module Output Parameter.
 
+Note that a Cinder volume is not a shared resource. A volume template
+must correspond 1:1 with a base module or incremental module.
+
 An example of a shared resource is the resource
 OS::Neutron::SecurityGroup. Security groups are sets of IP filter rules
 that are applied to a VNF’s networking. The resource OS::Neutron::Port
diff --git a/docs/data/needs.json b/docs/data/needs.json
index 6ca56f3..e77e864 100644
--- a/docs/data/needs.json
+++ b/docs/data/needs.json
@@ -1,5 +1,5 @@
 {
-    "created": "2018-09-12T17:22:55.929421",
+    "created": "2018-09-12T23:20:21.160620",
     "current_version": "casablanca",
     "project": "",
     "versions": {
@@ -21858,7 +21858,7 @@
             "needs_amount": 750
         },
         "casablanca": {
-            "created": "2018-09-12T17:22:55.929309",
+            "created": "2018-09-12T23:20:21.160546",
             "needs": {
                 "R-00011": {
                     "description": "A VNF's Heat Orchestration Template's parameter defined\nin a nested YAML file\n**MUST NOT** have a parameter constraint defined.",
@@ -21987,6 +21987,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -22087,7 +22088,7 @@
                     "validation_mode": ""
                 },
                 "R-01101": {
-                    "description": "A VNF's Heat Orchestration Template **MAY**\nreference the nested heat dynamically using the resource\n'OS::Heat::ResourceGroup'.",
+                    "description": "A VNF's Heat Orchestration Template **MAY**\nreference the nested heat dynamically using the resource\n``OS::Heat::ResourceGroup``.",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-01101",
@@ -22099,6 +22100,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -22110,7 +22112,7 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
                     "validation_mode": ""
                 },
@@ -22842,6 +22844,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -22971,7 +22974,7 @@
                     "validation_mode": ""
                 },
                 "R-05050": {
-                    "description": "A VNF's Heat Orchestration Templates intrinsic function\n'get\\_file' <content key> **MAY** be used:\n\n    * more than once in a VNF's Heat Orchestration Template\n    * in two or more of a VNF's Heat Orchestration Templates\n    * in a VNF's Heat Orchestration Templates nested YAML file",
+                    "description": "A VNF's Heat Orchestration Templates intrinsic function\n``get_file`` <content key> **MAY** be used:\n\n    * more than once in a VNF's Heat Orchestration Template\n    * in two or more of a VNF's Heat Orchestration Templates\n    * in a VNF's Heat Orchestration Templates nested YAML file",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-05050",
@@ -22994,7 +22997,7 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
                     "validation_mode": ""
                 },
@@ -23819,6 +23822,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -23830,9 +23834,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-11168": {
                     "description": "A VNF's Heat Orchestration Template's Resource ID that is\nassociated with an external network **MUST** include the\n'{network-role}' as part of the resource ID.",
@@ -25156,6 +25160,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -25167,9 +25172,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-18001": {
                     "description": "If the VNF's ports connected to a unique internal network\nand the port's IP addresses are statically assigned IP Addresses,\nthe IPv4 Addresses **MAY** be from different subnets and the\nIPv6 Addresses **MAY** be from different subnets.",
@@ -26307,33 +26312,6 @@
                     "validated_by": "",
                     "validation_mode": "static"
                 },
-                "R-22656": {
-                    "description": "The VNF Heat Orchestration Template **MUST** have a\ncorresponding environment file for a Cinder Volume Module.",
-                    "full_title": "",
-                    "hide_links": "",
-                    "id": "R-22656",
-                    "impacts": "",
-                    "introduced": "",
-                    "keyword": "MUST",
-                    "links": [],
-                    "notes": "",
-                    "section_name": "ONAP Heat Support of Environment Files",
-                    "sections": [
-                        "ONAP Heat Support of Environment Files"
-                    ],
-                    "status": null,
-                    "tags": [],
-                    "target": "VNF",
-                    "test": "",
-                    "test_case": "",
-                    "test_file": "",
-                    "title": "",
-                    "title_from_content": "",
-                    "type_name": "Requirement",
-                    "updated": "",
-                    "validated_by": "",
-                    "validation_mode": ""
-                },
                 "R-22680": {
                     "description": "The xNF Package **MUST** include documentation that describes\nany requirements for the monitoring component of tools for Network\nCloud automation and management to provide these records to components\nof the xNF.",
                     "full_title": "",
@@ -26873,7 +26851,7 @@
                     "validation_mode": ""
                 },
                 "R-25190": {
-                    "description": "A VNF's Heat Orchestration Template's Resource 'OS::Cinder::Volume'\n**SHOULD NOT** declare the property 'availability_zone'.",
+                    "description": "A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``\n**SHOULD NOT** declare the property ``availability_zone``.",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-25190",
@@ -26896,7 +26874,7 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
                     "validation_mode": ""
                 },
@@ -29243,33 +29221,6 @@
                     "validated_by": "",
                     "validation_mode": ""
                 },
-                "R-35727": {
-                    "description": "The VNF Heat Orchestration Template **MUST** have a\ncorresponding environment file for an Incremental module.",
-                    "full_title": "",
-                    "hide_links": "",
-                    "id": "R-35727",
-                    "impacts": "",
-                    "introduced": "",
-                    "keyword": "MUST",
-                    "links": [],
-                    "notes": "",
-                    "section_name": "ONAP Heat Support of Environment Files",
-                    "sections": [
-                        "ONAP Heat Support of Environment Files"
-                    ],
-                    "status": null,
-                    "tags": [],
-                    "target": "VNF",
-                    "test": "",
-                    "test_case": "",
-                    "test_file": "",
-                    "title": "",
-                    "title_from_content": "",
-                    "type_name": "Requirement",
-                    "updated": "",
-                    "validated_by": "",
-                    "validation_mode": ""
-                },
                 "R-35735": {
                     "description": "When the VNF's Heat Orchestration Template's Resource\n'OS::Neutron::Port' is attaching to an external network,\nand an IPv6 Virtual IP (VIP) address is assigned via ONAP automation\nusing the property 'allowed_address_pairs' map property 'ip_address',\nthe parameter name **MUST** follow the naming convention\n\n   * '{vm-type}_{network-role}_v6_floating_ip'\n\nwhere\n\n   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server\n   * '{network-role}' is the {network-role} of the external network\n\nAnd the parameter **MUST** be declared as type 'string'.",
                     "full_title": "",
@@ -30489,7 +30440,7 @@
                     "validation_mode": ""
                 },
                 "R-41888": {
-                    "description": "A VNF's Heat Orchestration Template intrinsic function\n'get\\_file' **MUST NOT** utilize URL-based file retrieval.",
+                    "description": "A VNF's Heat Orchestration Template intrinsic function\n``get_file`` **MUST NOT** utilize URL-based file retrieval.",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-41888",
@@ -30512,9 +30463,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-41956": {
                     "description": "If a VNF requires ONAP to assign a Virtual IP (VIP) Address to\nports connected an external network, the port\n**MUST NOT** have more than one IPv6 VIP address.",
@@ -32460,7 +32411,7 @@
                     "validation_mode": ""
                 },
                 "R-50011": {
-                    "description": "A VNF's Heat Orchestration Template's 'OS::Heat::ResourceGroup'\nproperty 'count' **MUST** be enumerated in the VNF's\nHeat Orchestration Template's Environment File and **MUST** be\nassigned a value.",
+                    "description": "A VNF's Heat Orchestration Template's ``OS::Heat::ResourceGroup``\nproperty ``count`` **MUST** be enumerated in the VNF's\nHeat Orchestration Template's Environment File and **MUST** be\nassigned a value.",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-50011",
@@ -32473,7 +32424,7 @@
                     "sections": [
                         "OS::Heat::ResourceGroup Property count",
                         "Use of Heat ResourceGroup",
-                        "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -32485,9 +32436,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-50252": {
                     "description": "The xNF **MUST** write to a specific one text files that\nwill be retrieved and made available by the Ansible Server if, as part\nof a xNF action (e.g., audit), a playbook is required to return any\nxNF information. The text files must be written in the same directory as\nthe one from which the playbook is being executed. A text file must be\ncreated for the xNF playbook run targets/affects, with the name\n'<VNFname>_results.txt' into which any desired output from each\nrespective VM/xNF must be written.",
@@ -32788,6 +32739,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -32799,9 +32751,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-52753": {
                     "description": "VNF's Heat Orchestration Template's Base Module's output parameter's\nname and type **MUST** match the VNF's Heat Orchestration Template's\nincremental Module's name and type unless the output parameter is of\ntype ``comma_delimited_list``, then the corresponding input parameter\n**MUST** be declared as type ``json``.",
@@ -34291,6 +34243,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -34302,9 +34255,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-60106": {
                     "description": "The xNF **MUST** implement the protocol operation:\n**get(filter)** - Retrieve (a filtered subset of) the running\nconfiguration and device state information. This should include\nthe list of xNF supported schemas.",
@@ -34389,9 +34342,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-61354": {
                     "description": "The VNF **MUST** provide a mechanism (e.g., access control list) to\npermit and/or restrict access to services on the VNF by source,\ndestination, protocol, and/or port.",
@@ -34503,9 +34456,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-62187": {
                     "description": "A VNF's Heat Orchestration Template's Resource\n'OS::ContrailV2::InstanceIp' that is configuring an\nIPv4 Address on a port attached to an internal network\nResource ID **MUST** use the naming convention\n\n   *  {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}\n\nwhere\n\n   * {vm-type} is the vm-type\n   * {vm-type_index} is the instance of the {vm-type}\n   * {network-role} is the network-role of the network\n     that the port is attached to\n   * {vmi_index} is the instance of the the virtual machine interface\n     (e.g., port)  on the vm-type\n     attached to the network of {network-role}\n   * 'IP' signifies that an IPv4 address is being configured\n   * {index} is the index of the IPv4 address",
@@ -35392,33 +35345,6 @@
                     "validated_by": "",
                     "validation_mode": ""
                 },
-                "R-67205": {
-                    "description": "The VNF Heat Orchestration Template **MUST** have a corresponding\nenvironment file for a Base Module.",
-                    "full_title": "",
-                    "hide_links": "",
-                    "id": "R-67205",
-                    "impacts": "",
-                    "introduced": "",
-                    "keyword": "MUST",
-                    "links": [],
-                    "notes": "",
-                    "section_name": "ONAP Heat Support of Environment Files",
-                    "sections": [
-                        "ONAP Heat Support of Environment Files"
-                    ],
-                    "status": null,
-                    "tags": [],
-                    "target": "VNF",
-                    "test": "",
-                    "test_case": "",
-                    "test_file": "",
-                    "title": "",
-                    "title_from_content": "",
-                    "type_name": "Requirement",
-                    "updated": "",
-                    "validated_by": "",
-                    "validation_mode": ""
-                },
                 "R-67231": {
                     "description": "A VNF's Heat Orchestration template's Environment File's\n**MUST NOT** contain the ``resource_registry:`` section.",
                     "full_title": "",
@@ -36126,6 +36052,35 @@
                     "validated_by": "",
                     "validation_mode": ""
                 },
+                "R-70112": {
+                    "description": "A VNF's Heat Orchestration Template **MUST** reference a Nested YAML\nfile by name. The use of ``resource_registry`` in the VNF's Heat\nOrchestration Templates Environment File **MUST NOT** be used.",
+                    "full_title": "",
+                    "hide_links": "",
+                    "id": "R-70112",
+                    "impacts": "",
+                    "introduced": "casablanca",
+                    "keyword": "MUST",
+                    "links": [],
+                    "notes": "",
+                    "section_name": "Nested Heat Template Requirements",
+                    "sections": [
+                        "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
+                        "ONAP Heat Heat Template Constructs"
+                    ],
+                    "status": null,
+                    "tags": [],
+                    "target": "VNF",
+                    "test": "",
+                    "test_case": "",
+                    "test_file": "",
+                    "title": "",
+                    "title_from_content": "",
+                    "type_name": "Requirement",
+                    "updated": "",
+                    "validated_by": "",
+                    "validation_mode": "static"
+                },
                 "R-70266": {
                     "description": "The xNF **MUST** respond to an ONAP request to deliver the\ncurrent data for any of the record types defined in\n`Event Records - Data Structure Description`_ by returning the requested\nrecord, populated with the current field values. (Currently the defined\nrecord types include fault fields, mobile flow fields, measurements for\nxNF scaling fields, and syslog fields. Other record types will be added\nin the future as they become standardized and are made available.)",
                     "full_title": "",
@@ -37322,7 +37277,7 @@
                     "validation_mode": ""
                 },
                 "R-76718": {
-                    "description": "If a VNF's Heat Orchestration Template uses the intrinsic function\n'get\\_file', the 'get\\_file' target **MUST** be referenced in\nthe Heat Orchestration Template by file name.",
+                    "description": "If a VNF's Heat Orchestration Template uses the intrinsic function\n``get_file``, the ``get_file`` target **MUST** be referenced in\nthe Heat Orchestration Template by file name.",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-76718",
@@ -37345,9 +37300,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-76901": {
                     "description": "The VNF **MUST** support a container rebuild mechanism based on existing\nimage (e.g. Glance image in Openstack environment) or a snapshot.",
@@ -39730,7 +39685,7 @@
                     "validation_mode": ""
                 },
                 "R-87848": {
-                    "description": "A VNF's Heat Orchestration Template's 'get\\_file' target files\n**MUST** be in the same directory hierarchy as the VNF's Heat\nOrchestration Templates.",
+                    "description": "When using the intrinsic function get_file, ONAP does not support\na directory hierarchy for included files. All files must be in a\nsingle, flat directory per VNF. A VNF's Heat Orchestration\nTemplate's ``get_file`` target files **MUST** be in the same\ndirectory hierarchy as the VNF's Heat Orchestration Templates.",
                     "full_title": "",
                     "hide_links": "",
                     "id": "R-87848",
@@ -39753,9 +39708,9 @@
                     "title": "",
                     "title_from_content": "",
                     "type_name": "Requirement",
-                    "updated": "",
+                    "updated": "casablanca",
                     "validated_by": "",
-                    "validation_mode": ""
+                    "validation_mode": "static"
                 },
                 "R-88026": {
                     "description": "The xNF **MUST** include a NETCONF server enabling\nruntime configuration and lifecycle management capabilities.",
@@ -40129,34 +40084,6 @@
                     "validated_by": "",
                     "validation_mode": ""
                 },
-                "R-89868": {
-                    "description": "The VNF Heat Orchestration Template **MUST** have unique\nfile names within the scope of the VNF for a nested heat yaml file.",
-                    "full_title": "",
-                    "hide_links": "",
-                    "id": "R-89868",
-                    "impacts": "",
-                    "introduced": "",
-                    "keyword": "MUST",
-                    "links": [],
-                    "notes": "",
-                    "section_name": "Nested Heat Template Requirements",
-                    "sections": [
-                        "Nested Heat Template Requirements",
-                        "ONAP Heat Heat Template Constructs"
-                    ],
-                    "status": null,
-                    "tags": [],
-                    "target": "VNF",
-                    "test": "",
-                    "test_case": "",
-                    "test_file": "",
-                    "title": "",
-                    "title_from_content": "",
-                    "type_name": "Requirement",
-                    "updated": "",
-                    "validated_by": "",
-                    "validation_mode": ""
-                },
                 "R-89913": {
                     "description": "A VNF's Heat Orchestration Template's Cinder Volume Module Output\nParameter(s)\n**MUST** include the\nUUID(s) of the Cinder Volumes created in template,\nwhile others **MAY** be included.",
                     "full_title": "",
@@ -40229,6 +40156,7 @@
                     "section_name": "Nested Heat Template Requirements",
                     "sections": [
                         "Nested Heat Template Requirements",
+                        "Nested Heat Templates",
                         "ONAP Heat Heat Template Constructs"
                     ],
                     "status": null,
@@ -42205,7 +42133,7 @@
                     "validation_mode": ""
                 }
             },
-            "needs_amount": 715
+            "needs_amount": 712
         }
     }
 }
\ No newline at end of file
diff --git a/docs/heat_picture3.png b/docs/heat_picture3.png
new file mode 100755
index 0000000..f785bcb
--- /dev/null
+++ b/docs/heat_picture3.png