VNFRQTS - Updating requirements to new structure

Updating the requirements to use the newly developed RST directive
Removing Chapter 7 updates to see if build would work.

Change-Id: I43bffa2b6c0a15e6f2e179c00d39f4ee46c5a046
Issue-ID: VNFRQTS-245
Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>

8 files changed, 7283 insertions, 2903 deletions

diff --git a/docs/Chapter4/Devops.rst b/docs/Chapter4/Devops.rst
index 702db95..c333523 100644
--- a/docs/Chapter4/Devops.rst
+++ b/docs/Chapter4/Devops.rst
@@ -20,50 +20,129 @@ the DevOps guidelines for VNFs.
 
 DevOps Requirements
 
-* R-46960 NCSPs **MAY** operate a limited set of Guest OS and CPU
-  architectures and families, virtual machines, etc.
-* R-23475 VNFCs **SHOULD** be agnostic to the details of the Network Cloud
-  (such as hardware, host OS, Hypervisor or container technology) and must run
-  on the Network Cloud with acknowledgement to the paradigm that the Network
-  Cloud will continue to rapidly evolve and the underlying components of
-  the platform will change regularly.
-* R-33846 The VNF **MUST** install the NCSP required software on Guest OS
-  images when not using the NCSP provided Guest OS images. [1]_
-* R-09467 The VNF **MUST**  utilize only NCSP standard compute flavors. [1]_
-* R-02997 The VNF **MUST** preserve their persistent data. Running VMs
-  will not be backed up in the Network Cloud infrastructure.
-* R-29760 The VNFC **MUST** be installed on non-root file systems,
-  unless software is specifically included with the operating system
-  distribution of the guest image.
-* R-20860 The VNF **MUST** be agnostic to the underlying infrastructure
-  (such as hardware, host OS, Hypervisor), any requirements should be
-  provided as specification to be fulfilled by any hardware.
-* R-89800 The VNF **MUST NOT** require Hypervisor-level customization
-  from the cloud provider.
-* R-86758 The VNF **SHOULD** provide an automated test suite to validate
-  every new version of the software on the target environment(s). The tests
-  should be of sufficient granularity to independently test various
-  representative VNF use cases throughout its lifecycle. Operations might
-  choose to invoke these tests either on a scheduled basis or on demand to
-  support various operations functions including test, turn-up and
-  troubleshooting.
-* R-39650 The VNF **SHOULD** provide the ability to test incremental
-  growth of the VNF.
-* R-14853 The VNF **MUST** respond to a "move traffic" [2]_ command
-  against a specific VNFC, moving all existing session elsewhere with
-  minimal disruption if a VNF provides a load balancing function across
-  multiple instances of its VNFCs. Note: Individual VNF performance
-  aspects (e.g., move duration or disruption scope) may require further
-  constraints.
-* R-06327 The VNF **MUST** respond to a "drain VNFC" [2]_ command against
-  a specific VNFC, preventing new session from reaching the targeted VNFC,
-  with no disruption to active sessions on the impacted VNFC, if a VNF
-  provides a load balancing function across multiple instances of its VNFCs.
-  This is used to support scenarios such as proactive maintenance with no
-  user impact.
-* R-64713 The VNF **SHOULD** support a software promotion methodology
-  from dev/test -> pre-prod -> production in software, development &
-  testing and operations.
+
+.. req::
+    :id: R-46960
+    :target: VNF
+    :keyword: MAY
+
+    NCSPs **MAY** operate a limited set of Guest OS and CPU
+    architectures and families, virtual machines, etc.
+
+.. req::
+    :id: R-23475
+    :target: VNF
+    :keyword: SHOULD
+
+    VNFCs **SHOULD** be agnostic to the details of the Network Cloud
+    (such as hardware, host OS, Hypervisor or container technology) and must run
+    on the Network Cloud with acknowledgement to the paradigm that the Network
+    Cloud will continue to rapidly evolve and the underlying components of
+    the platform will change regularly.
+
+.. req::
+    :id: R-33846
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** install the NCSP required software on Guest OS
+    images when not using the NCSP provided Guest OS images. [1]_
+
+.. req::
+    :id: R-09467
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** utilize only NCSP standard compute flavors. [1]_
+
+.. req::
+    :id: R-02997
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** preserve their persistent data. Running VMs
+    will not be backed up in the Network Cloud infrastructure.
+
+.. req::
+    :id: R-29760
+    :target: VNF
+    :keyword: MUST
+
+    The VNFC **MUST** be installed on non-root file systems,
+    unless software is specifically included with the operating system
+    distribution of the guest image.
+
+.. req::
+    :id: R-20860
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** be agnostic to the underlying infrastructure
+    (such as hardware, host OS, Hypervisor), any requirements should be
+    provided as specification to be fulfilled by any hardware.
+
+.. req::
+    :id: R-89800
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** require Hypervisor-level customization
+    from the cloud provider.
+
+.. req::
+    :id: R-86758
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** provide an automated test suite to validate
+    every new version of the software on the target environment(s). The tests
+    should be of sufficient granularity to independently test various
+    representative VNF use cases throughout its lifecycle. Operations might
+    choose to invoke these tests either on a scheduled basis or on demand to
+    support various operations functions including test, turn-up and
+    troubleshooting.
+
+.. req::
+    :id: R-39650
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** provide the ability to test incremental
+    growth of the VNF.
+
+.. req::
+    :id: R-14853
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** respond to a "move traffic" [2]_ command
+    against a specific VNFC, moving all existing session elsewhere with
+    minimal disruption if a VNF provides a load balancing function across
+    multiple instances of its VNFCs.
+
+    Note: Individual VNF performance aspects (e.g., move duration or
+    disruption scope) may require further constraints.
+
+.. req::
+    :id: R-06327
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** respond to a "drain VNFC" [2]_ command against
+    a specific VNFC, preventing new session from reaching the targeted VNFC,
+    with no disruption to active sessions on the impacted VNFC, if a VNF
+    provides a load balancing function across multiple instances of its VNFCs.
+    This is used to support scenarios such as proactive maintenance with no
+    user impact.
+
+.. req::
+    :id: R-64713
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support a software promotion methodology
+    from dev/test -> pre-prod -> production in software, development &
+    testing and operations.
 
 
 .. [1]
@@ -72,3 +151,4 @@ DevOps Requirements
 .. [2]
    Not currently supported in ONAP release 1
 
+
diff --git a/docs/Chapter4/Modularity.rst b/docs/Chapter4/Modularity.rst
index 12024bd..7238a1b 100644
--- a/docs/Chapter4/Modularity.rst
+++ b/docs/Chapter4/Modularity.rst
@@ -30,10 +30,17 @@ types:
 
 3. Cinder Volume Module
 
-* R-37028 The VNF **MUST** be composed of one “base” module.
-* R-41215 The VNF **MAY** have zero to many “incremental” modules.
-* R-20974 The VNF **MUST** deploy the base module first, prior to
-  the incremental modules.
+:need:`R-37028` - The VNF **MUST** be composed of one "base" module.
+
+.. req::
+    :id: R-41215
+    :target: VNF
+    :keyword: MAY
+
+    The VNF **MAY** have zero to many "incremental" modules.
+
+:need:`R-20974` - The VNF **MUST** deploy the base module first, prior to
+the incremental modules.
 
 ONAP also supports the concept of an optional, independently deployed
 Cinder volume via a separate Heat Orchestration Templates, referred to
@@ -42,21 +49,22 @@ Virtual Machine (VM) (i.e., OS::Nova::Server) is deleted, allowing the
 volume to be reused on another instance (e.g., during a failover
 activity).
 
-* R-11200 The VNF **MUST** keep the scope of a Cinder volume module,
-  when it exists, to be 1:1 with the VNF Base Module or Incremental Module.
+:need:`R-11200` - The VNF **MUST** keep the scope of a Cinder volume module,
+when it exists, to be 1:1 with the VNF Base Module or Incremental Module.
+
+:need:`R-38474` - The VNF **MUST** have a corresponding environment file for a
+Base Module.
 
-* R-38474 The VNF **MUST** have a corresponding environment file for
-  a Base Module.
-* R-81725 The VNF **MUST** have a corresponding environment file for
-  an Incremental Module.
-* R-53433 The VNF **MUST** have a corresponding environment file for
-  a Cinder Volume Module.
+:need:`R-81725` - The VNF **MUST** have a corresponding environment file for an
+Incremental Module.
+
+:need:`R-53433` - The VNF **MUST** have a corresponding environment file for a
+Cinder Volume Module.
 
 These concepts will be described in more detail throughout the document.
 This overview is provided to set the stage and help clarify the concepts
 that will be introduced.
 
-
 ONAP VNF Modularity
 ^^^^^^^^^^^^^^^^^^^^^^
 
@@ -350,3 +358,4 @@ incremental.yaml
        properties:
           network_id: { get_param: int_oam_net_id }
  ...
+
diff --git a/docs/Chapter4/Resiliency.rst b/docs/Chapter4/Resiliency.rst
index bf3e2e8..7047962 100644
--- a/docs/Chapter4/Resiliency.rst
+++ b/docs/Chapter4/Resiliency.rst
@@ -29,33 +29,86 @@ would include techniques such as multiple vLANs, multiple local and
 geographic instances, multiple local and geographic data replication,
 and virtualized services such as Load Balancers.
 
-
 All Layer Redundancy Requirements
 
-* R-52499 The VNF **MUST** meet their own resiliency goals and not rely
-  on the Network Cloud.
-* R-42207 The VNF **MUST** design resiliency into a VNF such that the
-  resiliency deployment model (e.g., active-active) can be chosen at
-  run-time.
-* R-03954 The VNF **MUST** survive any single points of failure within
-  the Network Cloud (e.g., virtual NIC, VM, disk failure).
-* R-89010 The VNF **MUST** survive any single points of software failure
-  internal to the VNF (e.g., in memory structures, JMS message queues).
-* R-67709 The VNF **MUST** be designed, built and packaged to enable
-  deployment across multiple fault zones (e.g., VNFCs deployed in
-  different servers, racks, OpenStack regions, geographies) so that
-  in the event of a planned/unplanned downtime of a fault zone, the
-  overall operation/throughput of the VNF is maintained.
-* R-35291 The VNF **MUST** support the ability to failover a VNFC
-  automatically to other geographically redundant sites if not
-  deployed active-active to increase the overall resiliency of the VNF.
-* R-36843 The VNF **MUST** support the ability of the VNFC to be deployable
-  in multi-zoned cloud sites to allow for site support in the event of cloud
-  zone failure or upgrades.
-* R-00098 The VNF **MUST NOT** impact the ability of the VNF to provide
-  service/function due to a single container restart.
-* R-79952 The VNF **SHOULD** support container snapshots if not for rebuild
-  and evacuate for rollback or back out mechanism.
+
+.. req::
+    :id: R-52499
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** meet their own resiliency goals and not rely
+    on the Network Cloud.
+
+.. req::
+    :id: R-42207
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** design resiliency into a VNF such that the
+    resiliency deployment model (e.g., active-active) can be chosen at
+    run-time.
+
+.. req::
+    :id: R-03954
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** survive any single points of failure within
+    the Network Cloud (e.g., virtual NIC, VM, disk failure).
+
+.. req::
+    :id: R-89010
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** survive any single points of software failure
+    internal to the VNF (e.g., in memory structures, JMS message queues).
+
+.. req::
+    :id: R-67709
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** be designed, built and packaged to enable
+    deployment across multiple fault zones (e.g., VNFCs deployed in
+    different servers, racks, OpenStack regions, geographies) so that
+    in the event of a planned/unplanned downtime of a fault zone, the
+    overall operation/throughput of the VNF is maintained.
+
+.. req::
+    :id: R-35291
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support the ability to failover a VNFC
+    automatically to other geographically redundant sites if not
+    deployed active-active to increase the overall resiliency of the VNF.
+
+.. req::
+    :id: R-36843
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support the ability of the VNFC to be deployable
+    in multi-zoned cloud sites to allow for site support in the event of cloud
+    zone failure or upgrades.
+
+.. req::
+    :id: R-00098
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** impact the ability of the VNF to provide
+    service/function due to a single container restart.
+
+.. req::
+    :id: R-79952
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support container snapshots if not for rebuild
+    and evacuate for rollback or back out mechanism.
 
 Minimize Cross Data-Center Traffic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -69,8 +122,14 @@ completed).
 
 Minimize Cross Data-Center Traffic Requirements
 
-* R-92935 The VNF **SHOULD** minimize the propagation of state information
-  across multiple data centers to avoid cross data center traffic.
+
+.. req::
+    :id: R-92935
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** minimize the propagation of state information
+    across multiple data centers to avoid cross data center traffic.
 
 Application Resilient Error Handling
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -83,45 +142,110 @@ applications.
 
 Application Resilient Error Handling Requirements
 
-* R-26371 The VNF **MUST** detect communication failure for inter VNFC
-  instance and intra/inter VNF and re-establish communication
-  automatically to maintain the VNF without manual intervention to
-  provide service continuity.
-* R-18725 The VNF **MUST** handle the restart of a single VNFC instance
-  without requiring all VNFC instances to be restarted.
-* R-06668 The VNF **MUST** handle the start or restart of VNFC instances
-  in any order with each VNFC instance establishing or re-establishing
-  required connections or relationships with other VNFC instances and/or
-  VNFs required to perform the VNF function/role without requiring VNFC
-  instance(s) to be started/restarted in a particular order.
-* R-80070 The VNF **MUST** handle errors and exceptions so that they do
-  not interrupt processing of incoming VNF requests to maintain service
-  continuity (where the error is not directly impacting the software
-  handling the incoming request).
-* R-32695 The VNF **MUST** provide the ability to modify the number of
-  retries, the time between retries and the behavior/action taken after
-  the retries have been exhausted for exception handling to allow the
-  NCSP to control that behavior, where the interface and/or functional
-  specification allows for altering behaviour.
-* R-48356 The VNF **MUST** fully exploit exception handling to the extent
-  that resources (e.g., threads and memory) are released when no longer
-  needed regardless of programming language.
-* R-67918 The VNF **MUST** handle replication race conditions both locally
-  and geo-located in the event of a data base instance failure to maintain
-  service continuity.
-* R-36792 The VNF **MUST** automatically retry/resubmit failed requests
-  made by the software to its downstream system to increase the success rate.
-* R-70013 The VNF **MUST NOT** require any manual steps to get it ready for
-  service after a container rebuild.
-* R-65515 The VNF **MUST** provide a mechanism and tool to start VNF
-  containers (VMs) without impacting service or service quality assuming
-  another VNF in same or other geographical location is processing service
-  requests.
-* R-94978 The VNF **MUST** provide a mechanism and tool to perform a graceful
-  shutdown of all the containers (VMs) in the VNF without impacting service
-  or service quality assuming another VNF in same or other geographical
-  location can take over traffic and process service requests.
 
+.. req::
+    :id: R-26371
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** detect communication failure for inter VNFC
+    instance and intra/inter VNF and re-establish communication
+    automatically to maintain the VNF without manual intervention to
+    provide service continuity.
+
+.. req::
+    :id: R-18725
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** handle the restart of a single VNFC instance
+    without requiring all VNFC instances to be restarted.
+
+.. req::
+    :id: R-06668
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** handle the start or restart of VNFC instances
+    in any order with each VNFC instance establishing or re-establishing
+    required connections or relationships with other VNFC instances and/or
+    VNFs required to perform the VNF function/role without requiring VNFC
+    instance(s) to be started/restarted in a particular order.
+
+.. req::
+    :id: R-80070
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** handle errors and exceptions so that they do
+    not interrupt processing of incoming VNF requests to maintain service
+    continuity (where the error is not directly impacting the software
+    handling the incoming request).
+
+.. req::
+    :id: R-32695
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the ability to modify the number of
+    retries, the time between retries and the behavior/action taken after
+    the retries have been exhausted for exception handling to allow the
+    NCSP to control that behavior, where the interface and/or functional
+    specification allows for altering behaviour.
+
+.. req::
+    :id: R-48356
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** fully exploit exception handling to the extent
+    that resources (e.g., threads and memory) are released when no longer
+    needed regardless of programming language.
+
+.. req::
+    :id: R-67918
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** handle replication race conditions both locally
+    and geo-located in the event of a data base instance failure to maintain
+    service continuity.
+
+.. req::
+    :id: R-36792
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** automatically retry/resubmit failed requests
+    made by the software to its downstream system to increase the success rate.
+
+.. req::
+    :id: R-70013
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** require any manual steps to get it ready for
+    service after a container rebuild.
+
+.. req::
+    :id: R-65515
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide a mechanism and tool to start VNF
+    containers (VMs) without impacting service or service quality assuming
+    another VNF in same or other geographical location is processing service
+    requests.
+
+.. req::
+    :id: R-94978
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide a mechanism and tool to perform a graceful
+    shutdown of all the containers (VMs) in the VNF without impacting service
+    or service quality assuming another VNF in same or other geographical
+    location can take over traffic and process service requests.
 
 System Resource Optimization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -133,42 +257,100 @@ processes or eating memory if they are unable to complete. Critical
 sections should only contain memory operation, and should not contain
 any network or IO operation.
 
-
 System Resource Optimization Requirements
 
-* R-22059 The VNF **MUST NOT** execute long running tasks (e.g., IO,
-  database, network operations, service calls) in a critical section
-  of code, so as to minimize blocking of other operations and increase
-  concurrent throughput.
-* R-63473 The VNF **MUST** automatically advertise newly scaled
-  components so there is no manual intervention required.
-* R-74712 The VNF **MUST** utilize FQDNs (and not IP address) for
-  both Service Chaining and scaling.
-* R-41159 The VNF **MUST** deliver any and all functionality from any
-  VNFC in the pool (where pooling is the most suitable solution). The
-  VNFC pool member should be transparent to the client. Upstream and
-  downstream clients should only recognize the function being performed,
-  not the member performing it.
-* R-85959 The VNF **SHOULD** automatically enable/disable added/removed
-  sub-components or component so there is no manual intervention required.
-* R-06885 The VNF **SHOULD** support the ability to scale down a VNFC pool
-  without jeopardizing active sessions. Ideally, an active session should
-  not be tied to any particular VNFC instance.
-* R-12538 The VNF **SHOULD** support load balancing and discovery
-  mechanisms in resource pools containing VNFC instances.
-* R-98989 The VNF **SHOULD** utilize resource pooling (threads,
-  connections, etc.) within the VNF application so that resources
-  are not being created and destroyed resulting in resource management
-  overhead.
-* R-55345 The VNF **SHOULD** use techniques such as “lazy loading” when
-  initialization includes loading catalogues and/or lists which can grow
-  over time, so that the VNF startup time does not grow at a rate
-  proportional to that of the list.
-* R-35532 The VNF **SHOULD** release and clear all shared assets (memory,
-  database operations, connections, locks, etc.) as soon as possible,
-  especially before long running sync and asynchronous operations, so as
-  to not prevent use of these assets by other entities.
 
+.. req::
+    :id: R-22059
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** execute long running tasks (e.g., IO,
+    database, network operations, service calls) in a critical section
+    of code, so as to minimize blocking of other operations and increase
+    concurrent throughput.
+
+.. req::
+    :id: R-63473
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** automatically advertise newly scaled
+    components so there is no manual intervention required.
+
+.. req::
+    :id: R-74712
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** utilize FQDNs (and not IP address) for
+    both Service Chaining and scaling.
+
+.. req::
+    :id: R-41159
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** deliver any and all functionality from any
+    VNFC in the pool (where pooling is the most suitable solution). The
+    VNFC pool member should be transparent to the client. Upstream and
+    downstream clients should only recognize the function being performed,
+    not the member performing it.
+
+.. req::
+    :id: R-85959
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** automatically enable/disable added/removed
+    sub-components or component so there is no manual intervention required.
+
+.. req::
+    :id: R-06885
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support the ability to scale down a VNFC pool
+    without jeopardizing active sessions. Ideally, an active session should
+    not be tied to any particular VNFC instance.
+
+.. req::
+    :id: R-12538
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support load balancing and discovery
+    mechanisms in resource pools containing VNFC instances.
+
+.. req::
+    :id: R-98989
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** utilize resource pooling (threads,
+    connections, etc.) within the VNF application so that resources
+    are not being created and destroyed resulting in resource management
+    overhead.
+
+.. req::
+    :id: R-55345
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** use techniques such as "lazy loading" when
+    initialization includes loading catalogues and/or lists which can grow
+    over time, so that the VNF startup time does not grow at a rate
+    proportional to that of the list.
+
+.. req::
+    :id: R-35532
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** release and clear all shared assets (memory,
+    database operations, connections, locks, etc.) as soon as possible,
+    especially before long running sync and asynchronous operations, so as
+    to not prevent use of these assets by other entities.
 
 Application Configuration Management
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -178,16 +360,33 @@ to develop gold configurations for technologies like Java, Python, etc.
 
 Application Configuration Management Requirements
 
-* R-77334 The VNF **MUST** allow configurations and configuration parameters
-  to be managed under version control to ensure consistent configuration
-  deployment, traceability and rollback.
-* R-99766 The VNF **MUST** allow configurations and configuration parameters
-  to be managed under version control to ensure the ability to rollback to
-  a known valid configuration.
-* R-73583 The VNF **MUST** allow changes of configuration parameters
-  to be consumed by the VNF without requiring the VNF or its sub-components
-  to be bounced so that the VNF availability is not effected.
 
+.. req::
+    :id: R-77334
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** allow configurations and configuration parameters
+    to be managed under version control to ensure consistent configuration
+    deployment, traceability and rollback.
+
+.. req::
+    :id: R-99766
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** allow configurations and configuration parameters
+    to be managed under version control to ensure the ability to rollback to
+    a known valid configuration.
+
+.. req::
+    :id: R-73583
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** allow changes of configuration parameters
+    to be consumed by the VNF without requiring the VNF or its sub-components
+    to be bounced so that the VNF availability is not effected.
 
 Intelligent Transaction Distribution & Management
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -204,17 +403,35 @@ deploying non-related elements in the same container).
 
 Intelligent Transaction Distribution & Management Requirements
 
-* R-21558 The VNF **SHOULD** use intelligent routing by having knowledge
-  of multiple downstream/upstream endpoints that are exposed to it, to
-  ensure there is no dependency on external services (such as load balancers)
-  to switch to alternate endpoints.
-* R-08315 The VNF **SHOULD** use redundant connection pooling to connect
-  to any backend data source that can be switched between pools in an
-  automated/scripted fashion to ensure high availability of the connection
-  to the data source.
-* R-27995 The VNF **SHOULD** include control loop mechanisms to notify
-  the consumer of the VNF of their exceeding SLA thresholds so the consumer
-  is able to control its load against the VNF.
+
+.. req::
+    :id: R-21558
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** use intelligent routing by having knowledge
+    of multiple downstream/upstream endpoints that are exposed to it, to
+    ensure there is no dependency on external services (such as load balancers)
+    to switch to alternate endpoints.
+
+.. req::
+    :id: R-08315
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** use redundant connection pooling to connect
+    to any backend data source that can be switched between pools in an
+    automated/scripted fashion to ensure high availability of the connection
+    to the data source.
+
+.. req::
+    :id: R-27995
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** include control loop mechanisms to notify
+    the consumer of the VNF of their exceeding SLA thresholds so the consumer
+    is able to control its load against the VNF.
 
 Deployment Optimization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -226,39 +443,87 @@ automation (remove the human from the mix).
 
 Deployment Optimization Requirements
 
-* R-73364 The VNF **MUST** support at least two major versions of the
-  VNF software and/or sub-components to co-exist within production
-  environments at any time so that upgrades can be applied across
-  multiple systems in a staggered manner.
-* R-02454 The VNF **MUST** support the existence of multiple major/minor
-  versions of the VNF software and/or sub-components and interfaces that
-  support both forward and backward compatibility to be transparent to
-  the Service Provider usage.
-* R-57855 The VNF **MUST** support hitless staggered/rolling deployments
-  between its redundant instances to allow "soak-time/burn in/slow roll"
-  which can enable the support of low traffic loads to validate the
-  deployment prior to supporting full traffic loads.
-* R-64445 The VNF **MUST** support the ability of a requestor of the
-  service to determine the version (and therefore capabilities) of the
-  service so that Network Cloud Service Provider can understand the
-  capabilities of the service.
-* R-56793 The VNF **MUST** test for adherence to the defined performance
-  budgets at each layer, during each delivery cycle with delivered
-  results, so that the performance budget is measured and the code
-  is adjusted to meet performance budget.
-* R-77667 The VNF **MUST** test for adherence to the defined performance
-  budget at each layer, during each delivery cycle so that the performance
-  budget is measured and feedback is provided where the performance budget
-  is not met.
-* R-49308 The VNF **SHOULD** test for adherence to the defined resiliency
-  rating recommendation at each layer, during each delivery cycle with
-  delivered results, so that the resiliency rating is measured and the
-  code is adjusted to meet software resiliency requirements.
-* R-16039 The VNF **SHOULD** test for adherence to the defined
-  resiliency rating recommendation at each layer, during each
-  delivery cycle so that the resiliency rating is measured and
-  feedback is provided where software resiliency requirements are
-  not met.
+
+.. req::
+    :id: R-73364
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support at least two major versions of the
+    VNF software and/or sub-components to co-exist within production
+    environments at any time so that upgrades can be applied across
+    multiple systems in a staggered manner.
+
+.. req::
+    :id: R-02454
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support the existence of multiple major/minor
+    versions of the VNF software and/or sub-components and interfaces that
+    support both forward and backward compatibility to be transparent to
+    the Service Provider usage.
+
+.. req::
+    :id: R-57855
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support hitless staggered/rolling deployments
+    between its redundant instances to allow "soak-time/burn in/slow roll"
+    which can enable the support of low traffic loads to validate the
+    deployment prior to supporting full traffic loads.
+
+.. req::
+    :id: R-64445
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support the ability of a requestor of the
+    service to determine the version (and therefore capabilities) of the
+    service so that Network Cloud Service Provider can understand the
+    capabilities of the service.
+
+.. req::
+    :id: R-56793
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** test for adherence to the defined performance
+    budgets at each layer, during each delivery cycle with delivered
+    results, so that the performance budget is measured and the code
+    is adjusted to meet performance budget.
+
+.. req::
+    :id: R-77667
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** test for adherence to the defined performance
+    budget at each layer, during each delivery cycle so that the performance
+    budget is measured and feedback is provided where the performance budget
+    is not met.
+
+.. req::
+    :id: R-49308
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** test for adherence to the defined resiliency
+    rating recommendation at each layer, during each delivery cycle with
+    delivered results, so that the resiliency rating is measured and the
+    code is adjusted to meet software resiliency requirements.
+
+.. req::
+    :id: R-16039
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** test for adherence to the defined
+    resiliency rating recommendation at each layer, during each
+    delivery cycle so that the resiliency rating is measured and
+    feedback is provided where software resiliency requirements are
+    not met.
 
 Monitoring & Dashboard
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -273,29 +538,78 @@ post-incident diagnostics.
 
 Monitoring & Dashboard Requirements
 
-* R-34957 The VNF **MUST** provide a method of metrics gathering for each
-  layer's performance to identify/document variances in the allocations so
-  they can be addressed.
-* R-49224 The VNF **MUST** provide unique traceability of a transaction
-  through its life cycle to ensure quick and efficient troubleshooting.
-* R-52870 The VNF **MUST** provide a method of metrics gathering
-  and analysis to evaluate the resiliency of the software from both
-  a granular as well as a holistic standpoint. This includes, but is
-  not limited to thread utilization, errors, timeouts, and retries.
-* R-92571 The VNF **MUST** provide operational instrumentation such as
-  logging, so as to facilitate quick resolution of issues with the VNF to
-  provide service continuity.
-* R-48917 The VNF **MUST** monitor for and alert on (both sender and
-  receiver) errant, running longer than expected and missing file transfers,
-  so as to minimize the impact due to file transfer errors.
-* R-28168 The VNF **SHOULD** use an appropriately configured logging
-  level that can be changed dynamically, so as to not cause performance
-  degradation of the VNF due to excessive logging.
-* R-87352 The VNF **SHOULD** utilize Cloud health checks, when available
-  from the Network Cloud, from inside the application through APIs to check
-  the network connectivity, dropped packets rate, injection, and auto failover
-  to alternate sites if needed.
-* R-16560 The VNF **SHOULD** conduct a resiliency impact assessment for all
-  inter/intra-connectivity points in the VNF to provide an overall resiliency
-  rating for the VNF to be incorporated into the software design and
-  development of the VNF.
+
+.. req::
+    :id: R-34957
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide a method of metrics gathering for each
+    layer's performance to identify/document variances in the allocations so
+    they can be addressed.
+
+.. req::
+    :id: R-49224
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide unique traceability of a transaction
+    through its life cycle to ensure quick and efficient troubleshooting.
+
+.. req::
+    :id: R-52870
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide a method of metrics gathering
+    and analysis to evaluate the resiliency of the software from both
+    a granular as well as a holistic standpoint. This includes, but is
+    not limited to thread utilization, errors, timeouts, and retries.
+
+.. req::
+    :id: R-92571
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide operational instrumentation such as
+    logging, so as to facilitate quick resolution of issues with the VNF to
+    provide service continuity.
+
+.. req::
+    :id: R-48917
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** monitor for and alert on (both sender and
+    receiver) errant, running longer than expected and missing file transfers,
+    so as to minimize the impact due to file transfer errors.
+
+.. req::
+    :id: R-28168
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** use an appropriately configured logging
+    level that can be changed dynamically, so as to not cause performance
+    degradation of the VNF due to excessive logging.
+
+.. req::
+    :id: R-87352
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** utilize Cloud health checks, when available
+    from the Network Cloud, from inside the application through APIs to check
+    the network connectivity, dropped packets rate, injection, and auto failover
+    to alternate sites if needed.
+
+.. req::
+    :id: R-16560
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** conduct a resiliency impact assessment for all
+    inter/intra-connectivity points in the VNF to provide an overall resiliency
+    rating for the VNF to be incorporated into the software design and
+    development of the VNF.
+
diff --git a/docs/Chapter4/Security.rst b/docs/Chapter4/Security.rst
index a0691ae..7ea5612 100644
--- a/docs/Chapter4/Security.rst
+++ b/docs/Chapter4/Security.rst
@@ -64,119 +64,301 @@ expected to understand and accommodate such controls and can expected
 to supply responsive interoperability support and testing throughout
 the product’s lifecycle.
 
-* R-23740 The VNF **MUST** accommodate the security principle of
-  “least privilege” during development, implementation and operation.
-  The importance of “least privilege” cannot be overstated and must be
-  observed in all aspects of VNF development and not limited to security.
-  This is applicable to all sections of this document.
-* R-61354 The VNF **MUST** implement access control list for OA&M
-  services (e.g., restricting access to certain ports or applications).
-* R-85633 The VNF **MUST** implement Data Storage Encryption
-  (database/disk encryption) for Sensitive Personal Information (SPI)
-  and other subscriber identifiable data. Note: subscriber’s SPI/data
-  must be encrypted at rest, and other subscriber identifiable data
-  should be encrypted at rest. Other data protection requirements exist
-  and should be well understood by the developer.
-* R-92207 The VNF **SHOULD** implement a mechanism for automated and
-  frequent "system configuration (automated provisioning / closed loop)"
-  auditing.
-* R-23882 The VNF **SHOULD** be scanned using both network scanning
-  and application scanning security tools on all code, including underlying
-  OS and related configuration. Scan reports shall be provided. Remediation
-  roadmaps shall be made available for any findings.
-* R-46986 The VNF **SHOULD** have source code scanned using scanning
-  tools (e.g., Fortify) and provide reports.
-* R-55830 The VNF **MUST** distribute all production code from NCSP
-  internal sources only. No production code, libraries, OS images, etc.
-  shall be distributed from publically accessible depots.
-* R-99771 The VNF **MUST** provide all code/configuration files in a
-  "Locked down" or hardened state or with documented recommendations for
-  such hardening. All unnecessary services will be disabled. VNF provider
-  default credentials, community strings and other such artifacts will be
-  removed or disclosed so that they can be modified or removed during
-  provisioning.
-* R-19768 The VNF **SHOULD** support L3 VPNs that enable segregation of
-  traffic by application (dropping packets not belonging to the VPN) (i.e.,
-  AVPN, IPSec VPN for Internet routes).
-* R-33981 The VNF **SHOULD** interoperate with various access control
-  mechanisms for the Network Cloud execution environment (e.g.,
-  Hypervisors, containers).
-* R-40813 The VNF **SHOULD** support the use of virtual trusted platform
-  module, hypervisor security testing and standards scanning tools.
-* R-56904 The VNF **MUST** interoperate with the ONAP (SDN) Controller so that
-  it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual
-  routing and forwarding rules.
-* R-26586 The VNF **SHOULD** support the ability to work with aliases
-  (e.g., gateways, proxies) to protect and encapsulate resources.
-* R-49956 The VNF **MUST** pass all access to applications (Bearer,
-  signaling and OA&M) through various security tools and platforms from
-  ACLs, stateful firewalls and application layer gateways depending on
-  manner of deployment. The application is expected to function (and in
-  some cases, interwork) with these security tools.
-* R-69649 The VNF **MUST** have all vulnerabilities patched as soon
-  as possible. Patching shall be controlled via change control process
-  with vulnerabilities disclosed along with mitigation recommendations.
-* R-78010 The VNF **MUST** use the NCSP’s IDAM API for Identification,
-  authentication and access control of customer or VNF application users.
-* R-42681 The VNF **MUST** use the NCSP’s IDAM API or comply with
-  the requirements if not using the NCSP’s IDAM API, for identification,
-  authentication and access control of OA&M and other system level
-  functions.
-* R-68589 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-  User-IDs and passwords to uniquely identify the user/application. VNF
-  needs to have appropriate connectors to the Identity, Authentication
-  and Authorization systems that enables access at OS, Database and
-  Application levels as appropriate.
-* R-52085 The VNF **MUST**, if not using the NCSP’s IDAM API, provide
-  the ability to support Multi-Factor Authentication (e.g., 1st factor =
-  Software token on device (RSA SecureID); 2nd factor = User Name+Password,
-  etc.) for the users.
-* R-98391 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-  Role-Based Access Control to permit/limit the user/application to
-  performing specific activities.
-* R-63217 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-  logging via ONAP for a historical view of “who did what and when”.
-* R-62498 The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt
-  OA&M access (e.g., SSH, SFTP).
-* R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce
-  a configurable maximum number of Login attempts policy for the users.
-  VNF provider must comply with "terminate idle sessions" policy.
-  Interactive sessions must be terminated, or a secure, locking screensaver
-  must be activated requiring authentication, after a configurable period
-  of inactivity. The system-based inactivity timeout for the enterprise
-  identity and access management system must also be configurable.
-* R-35144 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-  with the NCSP’s credential management policy.
-* R-75041 The VNF **MUST**, if not using the NCSP’s IDAM API, expire
-  passwords at regular configurable intervals.
-* R-46908 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-  with "password complexity" policy. When passwords are used, they shall
-  be complex and shall at least meet the following password construction
-  requirements: (1) be a minimum configurable number of characters in
-  length, (2) include 3 of the 4 following types of characters:
-  upper-case alphabetic, lower-case alphabetic, numeric, and special,
-  (3) not be the same as the UserID with which they are associated or
-  other common strings as specified by the environment, (4) not contain
-  repeating or sequential characters or numbers, (5) not to use special
-  characters that may have command functions, and (6) new passwords must
-  not contain sequences of three or more characters from the previous
-  password.
-* R-39342 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-  with "password changes (includes default passwords)" policy. Products
-  will support password aging, syntax and other credential management
-  practices on a configurable basis.
-* R-40521 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-  use of common third party authentication and authorization tools such
-  as TACACS+, RADIUS.
-* R-41994 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-  with "No Self-Signed Certificates" policy. Self-signed certificates
-  must be used for encryption only, using specified and approved
-  encryption protocols such as TLS 1.2 or higher or equivalent security
-  protocols such as IPSec, AES.
-* R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API,
-  authenticate system to system communications where one system
-  accesses the resources of another system, and must never conceal
-  individual accountability.
+
+.. req::
+    :id: R-23740
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** accommodate the security principle of
+    "least privilege" during development, implementation and operation.
+    The importance of "least privilege" cannot be overstated and must be
+    observed in all aspects of VNF development and not limited to security.
+    This is applicable to all sections of this document.
+
+.. req::
+    :id: R-61354
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement access control list for OA&M
+    services (e.g., restricting access to certain ports or applications).
+
+.. req::
+    :id: R-85633
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement Data Storage Encryption
+    (database/disk encryption) for Sensitive Personal Information (SPI)
+    and other subscriber identifiable data.
+
+    Note: Subscribers SPI/data must be encrypted at rest, and other
+    subscriber identifiable data should be encrypted at rest. Other
+    data protection requirements exist and should be well understood
+    by the developer.
+
+.. req::
+    :id: R-92207
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** implement a mechanism for automated and
+    frequent "system configuration (automated provisioning / closed loop)"
+    auditing.
+
+.. req::
+    :id: R-23882
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** be scanned using both network scanning
+    and application scanning security tools on all code, including underlying
+    OS and related configuration. Scan reports shall be provided. Remediation
+    roadmaps shall be made available for any findings.
+
+.. req::
+    :id: R-46986
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** have source code scanned using scanning
+    tools (e.g., Fortify) and provide reports.
+
+.. req::
+    :id: R-55830
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** distribute all production code from NCSP
+    internal sources only. No production code, libraries, OS images, etc.
+    shall be distributed from publically accessible depots.
+
+.. req::
+    :id: R-99771
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide all code/configuration files in a
+    "Locked down" or hardened state or with documented recommendations for
+    such hardening. All unnecessary services will be disabled. VNF provider
+    default credentials, community strings and other such artifacts will be
+    removed or disclosed so that they can be modified or removed during
+    provisioning.
+
+.. req::
+    :id: R-19768
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support L3 VPNs that enable segregation of
+    traffic by application (dropping packets not belonging to the VPN) (i.e.,
+    AVPN, IPSec VPN for Internet routes).
+
+.. req::
+    :id: R-33981
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** interoperate with various access control
+    mechanisms for the Network Cloud execution environment (e.g.,
+    Hypervisors, containers).
+
+.. req::
+    :id: R-40813
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support the use of virtual trusted platform
+    module, hypervisor security testing and standards scanning tools.
+
+.. req::
+    :id: R-56904
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** interoperate with the ONAP (SDN) Controller so that
+    it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual
+    routing and forwarding rules.
+
+.. req::
+    :id: R-26586
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support the ability to work with aliases
+    (e.g., gateways, proxies) to protect and encapsulate resources.
+
+.. req::
+    :id: R-49956
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** pass all access to applications (Bearer,
+    signaling and OA&M) through various security tools and platforms from
+    ACLs, stateful firewalls and application layer gateways depending on
+    manner of deployment. The application is expected to function (and in
+    some cases, interwork) with these security tools.
+
+.. req::
+    :id: R-69649
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** have all vulnerabilities patched as soon
+    as possible. Patching shall be controlled via change control process
+    with vulnerabilities disclosed along with mitigation recommendations.
+
+.. req::
+    :id: R-78010
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use the NCSP's IDAM API for Identification,
+    authentication and access control of customer or VNF application users.
+
+.. req::
+    :id: R-42681
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use the NCSP's IDAM API or comply with
+    the requirements if not using the NCSP's IDAM API, for identification,
+    authentication and access control of OA&M and other system level
+    functions.
+
+.. req::
+    :id: R-68589
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, support
+    User-IDs and passwords to uniquely identify the user/application. VNF
+    needs to have appropriate connectors to the Identity, Authentication
+    and Authorization systems that enables access at OS, Database and
+    Application levels as appropriate.
+
+.. req::
+    :id: R-52085
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, provide
+    the ability to support Multi-Factor Authentication (e.g., 1st factor =
+    Software token on device (RSA SecureID); 2nd factor = User Name+Password,
+    etc.) for the users.
+
+.. req::
+    :id: R-98391
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, support
+    Role-Based Access Control to permit/limit the user/application to
+    performing specific activities.
+
+.. req::
+    :id: R-63217
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, support
+    logging via ONAP for a historical view of "who did what and when."
+
+.. req::
+    :id: R-62498
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSPs IDAM API, encrypt
+    OA&M access (e.g., SSH, SFTP).
+
+.. req::
+    :id: R-79107
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, enforce
+    a configurable maximum number of Login attempts policy for the users.
+    VNF provider must comply with "terminate idle sessions" policy.
+    Interactive sessions must be terminated, or a secure, locking screensaver
+    must be activated requiring authentication, after a configurable period
+    of inactivity. The system-based inactivity timeout for the enterprise
+    identity and access management system must also be configurable.
+
+.. req::
+    :id: R-35144
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, comply
+    with the NCSP's credential management policy.
+
+.. req::
+    :id: R-75041
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, expire
+    passwords at regular configurable intervals.
+
+.. req::
+    :id: R-46908
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, comply
+    with "password complexity" policy. When passwords are used, they shall
+    be complex and shall at least meet the following password construction
+    requirements: (1) be a minimum configurable number of characters in
+    length, (2) include 3 of the 4 following types of characters:
+    upper-case alphabetic, lower-case alphabetic, numeric, and special,
+    (3) not be the same as the UserID with which they are associated or
+    other common strings as specified by the environment, (4) not contain
+    repeating or sequential characters or numbers, (5) not to use special
+    characters that may have command functions, and (6) new passwords must
+    not contain sequences of three or more characters from the previous
+    password.
+
+.. req::
+    :id: R-39342
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, comply
+    with "password changes (includes default passwords)" policy. Products
+    will support password aging, syntax and other credential management
+    practices on a configurable basis.
+
+.. req::
+    :id: R-40521
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, support
+    use of common third party authentication and authorization tools such
+    as TACACS+, RADIUS.
+
+.. req::
+    :id: R-41994
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API, comply
+    with "No Self-Signed Certificates" policy. Self-signed certificates
+    must be used for encryption only, using specified and approved
+    encryption protocols such as TLS 1.2 or higher or equivalent security
+    protocols such as IPSec, AES.
+
+.. req::
+    :id: R-23135
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST**, if not using the NCSP's IDAM API,
+    authenticate system to system communications where one system
+    accesses the resources of another system, and must never conceal
+    individual accountability.
 
 VNF Identity and Access Management Requirements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -187,101 +369,307 @@ management need to be met by the solution in a virtual environment:
 
 Identity and Access Management Requirements
 
-* R-95105 The VNF **MUST** host connectors for access to the application
-  layer.
-* R-45496 The VNF **MUST** host connectors for access to the OS
-  (Operating System) layer.
-* R-05470 The VNF **MUST** host connectors for access to the database layer.
-* R-99174 The VNF **MUST** comply with Individual Accountability
-  (each person must be assigned a unique ID) when persons or non-person
-  entities access VNFs.
-* R-42874 The VNF **MUST** comply with Least Privilege (no more
-  privilege than required to perform job functions) when persons
-  or non-person entities access VNFs.
-* R-71787 The VNF **MUST** comply with Segregation of Duties (access to a
-  single layer and no developer may access production without special
-  oversight) when persons or non-person entities access VNFs.
-* R-86261 The VNF **MUST NOT** allow VNF provider access to VNFs remotely.
-* R-49945 The VNF **MUST** authorize VNF provider access through a
-  client application API by the client application owner and the resource
-  owner of the VNF before provisioning authorization through Role Based
-  Access Control (RBAC), Attribute Based Access Control (ABAC), or other
-  policy based mechanism.
-* R-31751 The VNF **MUST** subject VNF provider access to privilege
-  reconciliation tools to prevent access creep and ensure correct
-  enforcement of access policies.
-* R-34552 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for OWASP Top 10.
-* R-29301 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Password Attacks.
-* R-72243 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Phishing / SMishing.
-* R-58998 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Malware (Key Logger).
-* R-14025 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Session Hijacking.
-* R-31412 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for XSS / CSRF.
-* R-51883 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Replay.
-* R-44032 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Man in the Middle (MITM).
-* R-58977 The VNF **MUST** provide or support the Identity and Access
-  Management (IDAM) based threat detection data for Eavesdropping.
-* R-24825 The VNF **MUST** provide Context awareness data (device,
-  location, time, etc.) and be able to integrate with threat detection system.
-* R-59391 The VNF provider **MUST**, where a VNF provider requires
-  the assumption of permissions, such as root or administrator, first
-  log in under their individual user login ID then switch to the other
-  higher level account; or where the individual user login is infeasible,
-  must login with an account with admin privileges in a way that
-  uniquely identifies the individual performing the function.
-* R-85028 The VNF **MUST** authenticate system to system access and
-  do not conceal a VNF provider user’s individual accountability for
-  transactions.
-* R-80335 The VNF **MUST** make visible a Warning Notice: A formal
-  statement of resource intent, i.e., a warning notice, upon initial
-  access to a VNF provider user who accesses private internal networks
-  or Company computer resources, e.g., upon initial logon to an internal
-  web site, system or application which requires authentication.
-* R-73541 The VNF **MUST** use access controls for VNFs and their
-  supporting computing systems at all times to restrict access to
-  authorized personnel only, e.g., least privilege. These controls
-  could include the use of system configuration or access control
-  software.
-* R-64503 The VNF **MUST** provide minimum privileges for initial
-  and default settings for new user accounts.
-* R-86835 The VNF **MUST** set the default settings for user access
-  to sensitive commands and data to deny authorization.
-* R-77157 The VNF **MUST** conform to approved request, workflow
-  authorization, and authorization provisioning requirements when
-  creating privileged users.
-* R-81147 The VNF **MUST** have greater restrictions for access and
-  execution, such as up to 3 factors of authentication and restricted
-  authorization, for commands affecting network services, such as
-  commands relating to VNFs.
-* R-49109 The VNF **MUST** encrypt TCP/IP--HTTPS (e.g., TLS v1.2)
-  transmission of data on internal and external networks.
-* R-39562 The VNF **MUST** disable unnecessary or vulnerable cgi-bin programs.
-* R-15671 The VNF **MUST NOT** provide public or unrestricted access
-  to any data without the permission of the data owner. All data
-  classification and access controls must be followed.
-* R-89753 The VNF **MUST NOT** install or use systems, tools or
-  utilities capable of capturing or logging data that was not created
-  by them or sent specifically to them in production, without
-  authorization of the VNF system owner.
-* R-19082 The VNF **MUST NOT** run security testing tools and
-  programs, e.g., password cracker, port scanners, hacking tools
-  in production, without authorization of the VNF system owner.
-* R-19790 The VNF **MUST NOT** include authentication credentials
-  in security audit logs, even if encrypted.
-* R-85419 The VNF **SHOULD** use REST APIs exposed to Client
-  Applications for the implementation of OAuth 2.0 Authorization
-  Code Grant and Client Credentials Grant, as the standard interface
-  for a VNF.
-* R-48080 The VNF **SHOULD** support SCEP (Simple Certificate
-  Enrollment Protocol).
 
+.. req::
+    :id: R-95105
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** host connectors for access to the application layer.
+
+.. req::
+    :id: R-45496
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** host connectors for access to the OS (Operating System) layer.
+
+.. req::
+    :id: R-05470
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** host connectors for access to the database layer.
+
+.. req::
+    :id: R-99174
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** comply with Individual Accountability
+    (each person must be assigned a unique ID) when persons or non-person
+    entities access VNFs.
+
+.. req::
+    :id: R-42874
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** comply with Least Privilege (no more
+    privilege than required to perform job functions) when persons
+    or non-person entities access VNFs.
+
+.. req::
+    :id: R-71787
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** comply with Segregation of Duties (access to a
+    single layer and no developer may access production without special
+    oversight) when persons or non-person entities access VNFs.
+
+.. req::
+    :id: R-86261
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** allow vendor access to VNFs remotely.
+
+.. req::
+    :id: R-49945
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** authorize VNF provider access through a
+    client application API by the client application owner and the resource
+    owner of the VNF before provisioning authorization through Role Based
+    Access Control (RBAC), Attribute Based Access Control (ABAC), or other
+    policy based mechanism.
+
+.. req::
+    :id: R-31751
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** subject VNF provider access to privilege
+    reconciliation tools to prevent access creep and ensure correct
+    enforcement of access policies.
+
+.. req::
+    :id: R-34552
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for OWASP Top 10.
+
+.. req::
+    :id: R-29301
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Password Attacks.
+
+.. req::
+    :id: R-72243
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Phishing / SMishing.
+
+.. req::
+    :id: R-58998
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Malware (Key Logger).
+
+.. req::
+    :id: R-14025
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Session Hijacking.
+
+.. req::
+    :id: R-31412
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for XSS / CSRF.
+
+.. req::
+    :id: R-51883
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Replay.
+
+.. req::
+    :id: R-44032
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Man in the Middle (MITM).
+
+.. req::
+    :id: R-58977
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide or support the Identity and Access
+    Management (IDAM) based threat detection data for Eavesdropping.
+
+.. req::
+    :id: R-24825
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide Context awareness data (device,
+    location, time, etc.) and be able to integrate with threat detection system.
+
+.. req::
+    :id: R-59391
+    :target: VNF
+    :keyword: MUST
+
+    The VNF provider **MUST**, where a VNF provider requires
+    the assumption of permissions, such as root or administrator, first
+    log in under their individual user login ID then switch to the other
+    higher level account; or where the individual user login is infeasible,
+    must login with an account with admin privileges in a way that
+    uniquely identifies the individual performing the function.
+
+.. req::
+    :id: R-85028
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** authenticate system to system access and
+    do not conceal a VNF provider user's individual accountability for
+    transactions.
+
+.. req::
+    :id: R-80335
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** make visible a Warning Notice: A formal
+    statement of resource intent, i.e., a warning notice, upon initial
+    access to a VNF provider user who accesses private internal networks
+    or Company computer resources, e.g., upon initial logon to an internal
+    web site, system or application which requires authentication.
+
+.. req::
+    :id: R-73541
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use access controls for VNFs and their
+    supporting computing systems at all times to restrict access to
+    authorized personnel only, e.g., least privilege. These controls
+    could include the use of system configuration or access control
+    software.
+
+.. req::
+    :id: R-64503
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide minimum privileges for initial
+    and default settings for new user accounts.
+
+.. req::
+    :id: R-86835
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** set the default settings for user access
+    to sensitive commands and data to deny authorization.
+
+.. req::
+    :id: R-77157
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** conform to approved request, workflow
+    authorization, and authorization provisioning requirements when
+    creating privileged users.
+
+.. req::
+    :id: R-81147
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** have greater restrictions for access and
+    execution, such as up to 3 factors of authentication and restricted
+    authorization, for commands affecting network services, such as
+    commands relating to VNFs.
+
+.. req::
+    :id: R-49109
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** encrypt TCP/IP--HTTPS (e.g., TLS v1.2)
+    transmission of data on internal and external networks.
+
+.. req::
+    :id: R-39562
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** disable unnecessary or vulnerable cgi-bin programs.
+
+.. req::
+    :id: R-15671
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** provide public or unrestricted access
+    to any data without the permission of the data owner. All data
+    classification and access controls must be followed.
+
+.. req::
+    :id: R-89753
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** install or use systems, tools or
+    utilities capable of capturing or logging data that was not created
+    by them or sent specifically to them in production, without
+    authorization of the VNF system owner.
+
+.. req::
+    :id: R-19082
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** run security testing tools and
+    programs, e.g., password cracker, port scanners, hacking tools
+    in production, without authorization of the VNF system owner.
+
+.. req::
+    :id: R-19790
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** include authentication credentials
+    in security audit logs, even if encrypted.
+
+.. req::
+    :id: R-85419
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** use REST APIs exposed to Client
+    Applications for the implementation of OAuth 2.0 Authorization
+    Code Grant and Client Credentials Grant, as the standard interface
+    for a VNF.
+
+.. req::
+    :id: R-48080
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** support SCEP (Simple Certificate Enrollment Protocol).
 
 VNF API Security Requirements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -299,49 +687,139 @@ security requirements:
 
 API Requirements
 
-* R-37608 The VNF **MUST** provide a mechanism to restrict access based
-  on the attributes of the VNF and the attributes of the subject.
-* R-43884 The VNF **MUST** integrate with external authentication
-  and authorization services (e.g., IDAM).
-* R-25878 The VNF **MUST** use certificates issued from publicly
-  recognized Certificate Authorities (CA) for the authentication process
-  where PKI-based authentication is used.
-* R-19804 The VNF **MUST** validate the CA signature on the certificate,
-  ensure that the date is within the validity period of the certificate,
-  check the Certificate Revocation List (CRL), and recognize the identity
-  represented by the certificate where PKI-based authentication is used.
-* R-47204 The VNF **MUST** protect the confidentiality and integrity of
-  data at rest and in transit from unauthorized access and modification.
-* R-33488 The VNF **MUST** protect against all denial of service
-  attacks, both volumetric and non-volumetric, or integrate with external
-  denial of service protection tools.
-* R-21652 The VNF **MUST** implement the following input validation
-  control: Check the size (length) of all input. Do not permit an amount
-  of input so great that it would cause the VNF to fail. Where the input
-  may be a file, the VNF API must enforce a size limit.
-* R-54930 The VNF **MUST** implement the following input validation
-  control: Do not permit input that contains content or characters
-  inappropriate to the input expected by the design. Inappropriate input,
-  such as SQL insertions, may cause the system to execute undesirable
-  and unauthorized transactions against the database or allow other
-  inappropriate access to the internal network.
-* R-21210 The VNF **MUST** implement the following input validation
-  control: Validate that any input file has a correct and valid
-  Multipurpose Internet Mail Extensions (MIME) type. Input files
-  should be tested for spoofed MIME types.
-* R-23772 The VNF **MUST** validate input at all layers implementing VNF APIs.
-* R-87135 The VNF **MUST** comply with NIST standards and industry
-  best practices for all implementations of cryptography.
-* R-02137 The VNF **MUST** implement all monitoring and logging as
-  described in the Security Analytics section.
-* R-15659 The VNF **MUST** restrict changing the criticality level of
-  a system security alarm to administrator(s).
-* R-19367 The VNF **MUST** monitor API invocation patterns to detect
-  anomalous access patterns that may represent fraudulent access or
-  other types of attacks, or integrate with tools that implement anomaly
-  and abuse detection.
-* R-78066 The VNF **MUST** support requests for information from law
-  enforcement and government agencies.
+
+.. req::
+    :id: R-37608
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide a mechanism to restrict access based
+    on the attributes of the VNF and the attributes of the subject.
+
+.. req::
+    :id: R-43884
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** integrate with external authentication
+    and authorization services (e.g., IDAM).
+
+.. req::
+    :id: R-25878
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use certificates issued from publicly
+    recognized Certificate Authorities (CA) for the authentication process
+    where PKI-based authentication is used.
+
+.. req::
+    :id: R-19804
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** validate the CA signature on the certificate,
+    ensure that the date is within the validity period of the certificate,
+    check the Certificate Revocation List (CRL), and recognize the identity
+    represented by the certificate where PKI-based authentication is used.
+
+.. req::
+    :id: R-47204
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** protect the confidentiality and integrity of
+    data at rest and in transit from unauthorized access and modification.
+
+.. req::
+    :id: R-33488
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** protect against all denial of service
+    attacks, both volumetric and non-volumetric, or integrate with external
+    denial of service protection tools.
+
+.. req::
+    :id: R-21652
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement the following input validation
+    control: Check the size (length) of all input. Do not permit an amount
+    of input so great that it would cause the VNF to fail. Where the input
+    may be a file, the VNF API must enforce a size limit.
+
+.. req::
+    :id: R-54930
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement the following input validation
+    control: Do not permit input that contains content or characters
+    inappropriate to the input expected by the design. Inappropriate input,
+    such as SQL insertions, may cause the system to execute undesirable
+    and unauthorized transactions against the database or allow other
+    inappropriate access to the internal network.
+
+.. req::
+    :id: R-21210
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement the following input validation
+    control: Validate that any input file has a correct and valid
+    Multipurpose Internet Mail Extensions (MIME) type. Input files
+    should be tested for spoofed MIME types.
+
+.. req::
+    :id: R-23772
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** validate input at all layers implementing VNF APIs.
+
+.. req::
+    :id: R-87135
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** comply with NIST standards and industry
+    best practices for all implementations of cryptography.
+
+.. req::
+    :id: R-02137
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement all monitoring and logging as
+    described in the Security Analytics section.
+
+.. req::
+    :id: R-15659
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** restrict changing the criticality level of
+    a system security alarm to administrator(s).
+
+.. req::
+    :id: R-19367
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** monitor API invocation patterns to detect
+    anomalous access patterns that may represent fraudulent access or
+    other types of attacks, or integrate with tools that implement anomaly
+    and abuse detection.
+
+.. req::
+    :id: R-78066
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support requests for information from law
+    enforcement and government agencies.
 
 
 VNF Security Analytics Requirements
@@ -391,111 +869,374 @@ solution in a virtual environment.
 
 Security Analytics Requirements
 
-* R-48470 The VNF **MUST** support Real-time detection and
-  notification of security events.
-* R-22286 The VNF **MUST** support Integration functionality via
-  API/Syslog/SNMP to other functional modules in the network (e.g.,
-  PCRF, PCEF) that enable dynamic security control by blocking the
-  malicious traffic or malicious end users
-* R-32636 The VNF **MUST** support API-based monitoring to take care of
-  the scenarios where the control interfaces are not exposed, or are
-  optimized and proprietary in nature.
-* R-61648 The VNF **MUST** support event logging, formats, and delivery
-  tools to provide the required degree of event data to ONAP
-* R-22367 The VNF **MUST** support detection of malformed packets due to
-  software misconfiguration or software vulnerability.
-* R-31961 The VNF **MUST** support integrated DPI/monitoring functionality
-  as part of VNFs (e.g., PGW, MME).
-* R-20912 The VNF **MUST** support alternative monitoring capabilities
-  when VNFs do not expose data or control traffic or use proprietary and
-  optimized protocols for inter VNF communication.
-* R-73223 The VNF **MUST** support proactive monitoring to detect and
-  report the attacks on resources so that the VNFs and associated VMs can
-  be isolated, such as detection techniques for resource exhaustion, namely
-  OS resource attacks, CPU attacks, consumption of kernel memory, local
-  storage attacks.
-* R-58370 The VNF **MUST** coexist and operate normally with commercial
-  anti-virus software which shall produce alarms every time when there is a
-  security incident.
-* R-56920 The VNF **MUST** protect all security audit logs (including
-  API, OS and application-generated logs), security audit software, data,
-  and associated documentation from modification, or unauthorized viewing,
-  by standard OS access control mechanisms, by sending to a remote system,
-  or by encryption.
-* R-54520 The VNF **MUST** log successful and unsuccessful login attempts.
-* R-55478 The VNF **MUST** log logoffs.
-* R-08598 The VNF **MUST** log successful and unsuccessful changes to
-  a privilege level.
-* R-13344 The VNF **MUST** log starting and stopping of security
-  logging.
-* R-07617 The VNF **MUST** log creating, removing, or changing the
-  inherent privilege level of users.
-* R-94525 The VNF **MUST** log connections to a network listener of the
-  resource.
-* R-31614 The VNF **MUST** log the field “event type” in the security
-  audit logs.
-* R-97445 The VNF **MUST** log the field “date/time” in the security
-  audit logs.
-* R-25547 The VNF **MUST** log the field “protocol” in the security audit logs.
-* R-06413 The VNF **MUST** log the field “service or program used for
-  access” in the security audit logs.
-* R-15325 The VNF **MUST** log the field “success/failure” in the
-  security audit logs.
-* R-89474 The VNF **MUST** log the field “Login ID” in the security audit logs.
-* R-04982 The VNF **MUST NOT** include an authentication credential,
-  e.g., password, in the security audit logs, even if encrypted.
-* R-63330 The VNF **MUST** detect when the security audit log storage
-  medium is approaching capacity (configurable) and issue an alarm via
-  SMS or equivalent as to allow time for proper actions to be taken to
-  pre-empt loss of audit data.
-* R-41252 The VNF **MUST** support the capability of online storage of
-  security audit logs.
-* R-41825 The VNF **MUST** activate security alarms automatically when
-  the following event is detected: configurable number of consecutive
-  unsuccessful login attempts
-* R-43332 The VNF **MUST** activate security alarms automatically when
-  the following event is detected: successful modification of critical
-  system or application files
-* R-74958 The VNF **MUST** activate security alarms automatically when
-  the following event is detected: unsuccessful attempts to gain permissions
-  or assume the identity of another user
-* R-15884 The VNF **MUST** include the field “date” in the Security alarms
-  (where applicable and technically feasible).
-* R-23957 The VNF **MUST** include the field “time” in the Security alarms
-  (where applicable and technically feasible).
-* R-71842 The VNF **MUST** include the field “service or program used for
-  access” in the Security alarms (where applicable and technically feasible).
-* R-57617 The VNF **MUST** include the field “success/failure” in the
-  Security alarms (where applicable and technically feasible).
-* R-99730 The VNF **MUST** include the field “Login ID” in the Security
-  alarms (where applicable and technically feasible).
-* R-29705 The VNF **MUST** restrict changing the criticality level of a
-  system security alarm to administrator(s).
-* R-13627 The VNF **MUST** monitor API invocation patterns to detect
-  anomalous access patterns that may represent fraudulent access or other
-  types of attacks, or integrate with tools that implement anomaly and
-  abuse detection.
-* R-21819 The VNF **MUST** support requests for information from law
-  enforcement and government agencies.
-* R-56786 The VNF **MUST** implement “Closed Loop” automatic implementation
-  (without human intervention) for Known Threats with detection rate in low
-  false positives.
-* R-25094 The VNF **MUST** perform data capture for security functions.
-* R-04492 The VNF **MUST** generate security audit logs that must be sent
-  to Security Analytics Tools for analysis.
-* R-19219 The VNF **MUST** provide audit logs that include user ID, dates,
-  times for log-on and log-off, and terminal location at minimum.
-* R-30932 The VNF **MUST** provide security audit logs including records
-  of successful and rejected system access data and other resource access
-  attempts.
-* R-54816 The VNF **MUST** support the storage of security audit logs
-  for agreed period of time for forensic analysis.
-* R-57271 The VNF **MUST** provide the capability of generating security
-  audit logs by interacting with the operating system (OS) as appropriate.
-* R-84160 The VNF **MUST** have security logging for VNFs and their
-  OSs be active from initialization. Audit logging includes automatic
-  routines to maintain activity records and cleanup programs to ensure
-  the integrity of the audit/logging systems.
+
+.. req::
+    :id: R-48470
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support Real-time detection and
+    notification of security events.
+
+.. req::
+    :id: R-22286
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support Integration functionality via
+    API/Syslog/SNMP to other functional modules in the network (e.g.,
+    PCRF, PCEF) that enable dynamic security control by blocking the
+    malicious traffic or malicious end users.
+
+.. req::
+    :id: R-32636
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support API-based monitoring to take care of
+    the scenarios where the control interfaces are not exposed, or are
+    optimized and proprietary in nature.
+
+.. req::
+    :id: R-61648
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support event logging, formats, and delivery
+    tools to provide the required degree of event data to ONAP.
+
+.. req::
+    :id: R-22367
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support detection of malformed packets due to
+    software misconfiguration or software vulnerability.
+
+.. req::
+    :id: R-31961
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support integrated DPI/monitoring functionality
+    as part of VNFs (e.g., PGW, MME).
+
+.. req::
+    :id: R-20912
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support alternative monitoring capabilities
+    when VNFs do not expose data or control traffic or use proprietary and
+    optimized protocols for inter VNF communication.
+
+.. req::
+    :id: R-73223
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support proactive monitoring to detect and
+    report the attacks on resources so that the VNFs and associated VMs can
+    be isolated, such as detection techniques for resource exhaustion, namely
+    OS resource attacks, CPU attacks, consumption of kernel memory, local
+    storage attacks.
+
+.. req::
+    :id: R-58370
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** coexist and operate normally with commercial
+    anti-virus software which shall produce alarms every time when there is a
+    security incident.
+
+.. req::
+    :id: R-56920
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** protect all security audit logs (including
+    API, OS and application-generated logs), security audit software, data,
+    and associated documentation from modification, or unauthorized viewing,
+    by standard OS access control mechanisms, by sending to a remote system,
+    or by encryption.
+
+.. req::
+    :id: R-54520
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log successful and unsuccessful login attempts.
+
+.. req::
+    :id: R-55478
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log logoffs.
+
+.. req::
+    :id: R-08598
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log successful and unsuccessful changes to a privilege level.
+
+.. req::
+    :id: R-13344
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log starting and stopping of security
+    logging.
+
+.. req::
+    :id: R-07617
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log creating, removing, or changing the
+    inherent privilege level of users.
+
+.. req::
+    :id: R-94525
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log connections to a network listener of the
+    resource.
+
+.. req::
+    :id: R-31614
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log the field "event type" in the security audit
+    logs.
+
+.. req::
+    :id: R-97445
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log the field "date/time" in the security audit
+    logs.
+
+.. req::
+    :id: R-25547
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log the field "protocol" in the security audit logs.
+
+.. req::
+    :id: R-06413
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log the field "service or program used for access"
+    in the security audit logs.
+
+.. req::
+    :id: R-15325
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log the field "success/failure" in the
+    security audit logs.
+
+.. req::
+    :id: R-89474
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** log the field "Login ID" in the security audit logs.
+
+.. req::
+    :id: R-04982
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** include an authentication credential,
+    e.g., password, in the security audit logs, even if encrypted.
+
+.. req::
+    :id: R-63330
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** detect when the security audit log storage
+    medium is approaching capacity (configurable) and issue an alarm via
+    SMS or equivalent as to allow time for proper actions to be taken to
+    pre-empt loss of audit data.
+
+.. req::
+    :id: R-41252
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support the capability of online storage of
+    security audit logs.
+
+.. req::
+    :id: R-41825
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** activate security alarms automatically when
+    the following event is detected: configurable number of consecutive
+    unsuccessful login attempts.
+
+.. req::
+    :id: R-43332
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** activate security alarms automatically when
+    the following event is detected: successful modification of critical
+    system or application files.
+
+.. req::
+    :id: R-74958
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** activate security alarms automatically when
+    the following event is detected: unsuccessful attempts to gain permissions
+    or assume the identity of another user.
+
+.. req::
+    :id: R-15884
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** include the field "date" in the Security alarms
+    (where applicable and technically feasible).
+
+.. req::
+    :id: R-23957
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** include the field "time" in the Security alarms
+    (where applicable and technically feasible).
+
+.. req::
+    :id: R-71842
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** include the field "service or program used for
+    access" in the Security alarms (where applicable and technically feasible).
+
+.. req::
+    :id: R-57617
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** include the field "success/failure" in the
+    Security alarms (where applicable and technically feasible).
+
+.. req::
+    :id: R-99730
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** include the field "Login ID" in the Security
+    alarms (where applicable and technically feasible).
+
+.. req::
+    :id: R-29705
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** restrict changing the criticality level of a
+    system security alarm to administrator(s).
+
+.. req::
+    :id: R-13627
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** monitor API invocation patterns to detect
+    anomalous access patterns that may represent fraudulent access or other
+    types of attacks, or integrate with tools that implement anomaly and
+    abuse detection.
+
+.. req::
+    :id: R-21819
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support requests for information from law
+    enforcement and government agencies.
+
+.. req::
+    :id: R-56786
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** implement "Closed Loop" automatic implementation
+    (without human intervention) for Known Threats with detection rate in low
+    false positives.
+
+.. req::
+    :id: R-25094
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** perform data capture for security functions.
+
+.. req::
+    :id: R-04492
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** generate security audit logs that must be sent
+    to Security Analytics Tools for analysis.
+
+.. req::
+    :id: R-19219
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide audit logs that include user ID, dates,
+    times for log-on and log-off, and terminal location at minimum.
+
+.. req::
+    :id: R-30932
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide security audit logs including records
+    of successful and rejected system access data and other resource access
+    attempts.
+
+.. req::
+    :id: R-54816
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support the storage of security audit logs
+    for agreed period of time for forensic analysis.
+
+.. req::
+    :id: R-57271
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of generating security
+    audit logs by interacting with the operating system (OS) as appropriate.
+
+.. req::
+    :id: R-84160
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** have security logging for VNFs and their
+    OSs be active from initialization. Audit logging includes automatic
+    routines to maintain activity records and cleanup programs to ensure
+    the integrity of the audit/logging systems.
 
 VNF Data Protection Requirements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -506,58 +1247,191 @@ applicable to security monitoring.
 
 Data Protection Requirements
 
-* R-58964 The VNF **MUST** provide the capability to restrict read
-  and write access to data.
-* R-99112 The VNF **MUST** provide the capability to restrict access
-  to data to specific users.
-* R-83227 The VNF **MUST** Provide the capability to encrypt data in
-  transit on a physical or virtual network.
-* R-32641 The VNF **MUST** provide the capability to encrypt data on
-  non-volatile memory.
-* R-13151 The VNF **SHOULD** disable the paging of the data requiring
-  encryption, if possible, where the encryption of non-transient data is
-  required on a device for which the operating system performs paging to
-  virtual memory. If not possible to disable the paging of the data
-  requiring encryption, the virtual memory should be encrypted.
-* R-93860 The VNF **MUST** provide the capability to integrate with an
-  external encryption service.
-* R-73067 The VNF **MUST** use industry standard cryptographic algorithms
-  and standard modes of operations when implementing cryptography.
-* R-22645 The VNF **SHOULD** use commercial algorithms only when there
-  are no applicable governmental standards for specific cryptographic
-  functions, e.g., public key cryptography, message digests.
-* R-12467 The VNF **MUST NOT** use the SHA, DSS, MD5, SHA-1 and
-  Skipjack algorithms or other compromised encryption.
-* R-02170 The VNF **MUST** use, whenever possible, standard implementations
-  of security applications, protocols, and format, e.g., S/MIME, TLS, SSH,
-  IPSec, X.509 digital certificates for cryptographic implementations.
-  These implementations must be purchased from reputable vendors and must
-  not be developed in-house.
-* R-70933 The VNF **MUST** provide the ability to migrate to newer
-  versions of cryptographic algorithms and protocols with no impact.
-* R-44723 The VNF **MUST** use symmetric keys of at least 112 bits in length.
-* R-25401 The VNF **MUST** use asymmetric keys of at least 2048 bits in length.
-* R-95864 The VNF **MUST** use commercial tools that comply with X.509
-  standards and produce x.509 compliant keys for public/private key generation.
-* R-12110 The VNF **MUST NOT** use keys generated or derived from
-  predictable functions or values, e.g., values considered predictable
-  include user identity information, time of day, stored/transmitted data.
-* R-52060 The VNF **MUST** provide the capability to configure encryption
-  algorithms or devices so that they comply with the laws of the jurisdiction
-  in which there are plans to use data encryption.
-* R-69610 The VNF **MUST** provide the capability of using certificates
-  issued from a Certificate Authority not provided by the VNF provider.
-* R-83500 The VNF **MUST** provide the capability of allowing certificate
-  renewal and revocation.
-* R-29977 The VNF **MUST** provide the capability of testing the validity
-  of a digital certificate by validating the CA signature on the certificate.
-* R-24359 The VNF **MUST** provide the capability of testing the validity
-  of a digital certificate by validating the date the certificate is being
-  used is within the validity period for the certificate.
-* R-39604 The VNF **MUST** provide the capability of testing the
-  validity of a digital certificate by checking the Certificate Revocation
-  List (CRL) for the certificates of that type to ensure that the
-  certificate has not been revoked.
-* R-75343 The VNF **MUST** provide the capability of testing the
-  validity of a digital certificate by recognizing the identity represented
-  by the certificate — the "distinguished name".
+
+.. req::
+    :id: R-58964
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability to restrict read
+    and write access to data.
+
+.. req::
+    :id: R-99112
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability to restrict access
+    to data to specific users.
+
+.. req::
+    :id: R-83227
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** Provide the capability to encrypt data in
+    transit on a physical or virtual network.
+
+.. req::
+    :id: R-32641
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability to encrypt data on
+    non-volatile memory.
+
+.. req::
+    :id: R-13151
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** disable the paging of the data requiring
+    encryption, if possible, where the encryption of non-transient data is
+    required on a device for which the operating system performs paging to
+    virtual memory. If not possible to disable the paging of the data
+    requiring encryption, the virtual memory should be encrypted.
+
+.. req::
+    :id: R-93860
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability to integrate with an
+    external encryption service.
+
+.. req::
+    :id: R-73067
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use industry standard cryptographic algorithms
+    and standard modes of operations when implementing cryptography.
+
+.. req::
+    :id: R-22645
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** use commercial algorithms only when there
+    are no applicable governmental standards for specific cryptographic
+    functions, e.g., public key cryptography, message digests.
+
+.. req::
+    :id: R-12467
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** use the SHA, DSS, MD5, SHA-1 and
+    Skipjack algorithms or other compromised encryption.
+
+.. req::
+    :id: R-02170
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use, whenever possible, standard implementations
+    of security applications, protocols, and format, e.g., S/MIME, TLS, SSH,
+    IPSec, X.509 digital certificates for cryptographic implementations.
+    These implementations must be purchased from reputable vendors and must
+    not be developed in-house.
+
+.. req::
+    :id: R-70933
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the ability to migrate to newer
+    versions of cryptographic algorithms and protocols with no impact.
+
+.. req::
+    :id: R-44723
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use symmetric keys of at least 112 bits in length.
+
+.. req::
+    :id: R-25401
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use asymmetric keys of at least 2048 bits in length.
+
+.. req::
+    :id: R-95864
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use commercial tools that comply with X.509
+    standards and produce x.509 compliant keys for public/private key generation.
+
+.. req::
+    :id: R-12110
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** use keys generated or derived from
+    predictable functions or values, e.g., values considered predictable
+    include user identity information, time of day, stored/transmitted data.
+
+.. req::
+    :id: R-52060
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability to configure encryption
+    algorithms or devices so that they comply with the laws of the jurisdiction
+    in which there are plans to use data encryption.
+
+.. req::
+    :id: R-69610
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of using certificates
+    issued from a Certificate Authority not provided by the VNF provider.
+
+.. req::
+    :id: R-83500
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of allowing certificate
+    renewal and revocation.
+
+.. req::
+    :id: R-29977
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of testing the validity
+    of a digital certificate by validating the CA signature on the certificate.
+
+.. req::
+    :id: R-24359
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of testing the validity
+    of a digital certificate by validating the date the certificate is being
+    used is within the validity period for the certificate.
+
+.. req::
+    :id: R-39604
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of testing the
+    validity of a digital certificate by checking the Certificate Revocation
+    List (CRL) for the certificates of that type to ensure that the
+    certificate has not been revoked.
+
+.. req::
+    :id: R-75343
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide the capability of testing the
+    validity of a digital certificate by recognizing the identity represented
+    by the certificate - the "distinguished name".
+
diff --git a/docs/Chapter5/Heat.rst b/docs/Chapter5/Heat.rst
index fb9cf33..04c56af 100644
--- a/docs/Chapter5/Heat.rst
+++ b/docs/Chapter5/Heat.rst
@@ -12,8 +12,13 @@ This section contains general Heat Orchestration Template guidelines.
 YAML Format
 ~~~~~~~~~~~
 
-R-95303 A VNF's Heat Orchestration Template **MUST** be defined
-using valid YAML.
+
+.. req::
+    :id: R-95303
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template **MUST** be defined using valid YAML.
 
 YAML (YAML Ain't
 Markup Language) is a human friendly data serialization standard for all
@@ -65,8 +70,14 @@ https://docs.openstack.org/developer/heat/template_guide/hot_spec.html
 heat_template_version
 +++++++++++++++++++++
 
-R-27078 A VNF's Heat Orchestration template **MUST** contain
-the section "heat_template_version:".
+
+.. req::
+    :id: R-27078
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration template **MUST** contain
+    the section "heat_template_version:".
 
 The section "heat_template_version:" must be set to a date
 that is supported by the OpenStack environment.
@@ -74,8 +85,14 @@ that is supported by the OpenStack environment.
 description
 +++++++++++
 
-R-39402 A VNF's Heat Orchestration Template **MUST**
-contain the section "description:".
+
+.. req::
+    :id: R-39402
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template **MUST**
+    contain the section "description:".
 
 parameter_groups
 ++++++++++++++++
@@ -86,8 +103,14 @@ contain the section "parameter_groups:".
 parameters
 ++++++++++
 
-R-35414 A VNF Heat Orchestration's template **MUST**
-contain the section "parameters:".
+
+.. req::
+    :id: R-35414
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration's template **MUST**
+    contain the section "parameters:".
 
 
 .. code-block:: yaml
@@ -118,13 +141,24 @@ the template. Each parameter is specified in a separate nested block
 with the name of the parameters defined in the first line and additional
 attributes (e.g., type, label) defined as nested elements.
 
-R-90279 A VNF's Heat Orchestration template's parameter **MUST**
-be used in a resource with the exception of the parameters
-for the OS::Nova::Server resource property availability_zone.
 
-R-91273 A VNF's Heat Orchestration template's parameter for
-the OS::Nova::Server resource property availability_zone
-**MAY NOT** be used in any OS::Nova::Resource.
+.. req::
+    :id: R-90279
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration template's parameter **MUST**
+    be used in a resource with the exception of the parameters
+    for the OS::Nova::Server resource property availability_zone.
+
+.. req::
+    :id: R-91273
+    :target: VNF
+    :keyword: MAY NOT
+
+    A VNF Heat Orchestration's template's parameter for
+    the OS::Nova::Server resource property availability_zone
+    **MAY NOT** be used in any OS::Nova::Resource.
 
 That is, the parameter associated with the property 'availability_zone'
 maybe declared but not used in a resource.
@@ -134,44 +168,84 @@ ____________
 
 The name of the parameter.
 
-R-25877 A VNF's Heat Orchestration Template's parameter
-name (i.e., <param name>) **MUST** contain only
-alphanumeric characters and underscores ('_').
+
+.. req::
+    :id: R-25877
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's parameter
+    name (i.e., <param name>) **MUST** contain only
+    alphanumeric characters and underscores ('_').
 
 type
 ____
 
-R-36772 A VNF's Heat Orchestration Template's parameter
-**MUST** include the attribute "type:".
 
-R-11441 A VNF's Heat Orchestration Template's parameter
-type **MUST** be one of the following values: "string",
-"number", "json", "comma_delimited_list" or "boolean".
+.. req::
+    :id: R-36772
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's parameter
+    **MUST** include the attribute "type:".
+
+.. req::
+    :id: R-11441
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's parameter
+    type **MUST** be one of the following values: "string",
+    "number", "json", "comma_delimited_list" or "boolean".
 
 label
 _____
 
-R-32094 A VNF's Heat Orchestration Template parameter
-declaration **MAY** contain the attribute "label:"
+
+.. req::
+    :id: R-32094
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template parameter
+    declaration **MAY** contain the attribute "label:".
 
 description
 ___________
 
-R-44001 A VNF's Heat Orchestration Template parameter
-declaration **MUST** contain the attribute "description".
 
-Note that the parameter attribute "description:" is an
-OpenStack optional attribute that provides a description
-of the parameter. ONAP implementation requires this attribute.
+.. req::
+    :id: R-44001
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template parameter
+    declaration **MUST** contain the attribute "description".
+
+Note that the parameter attribute "description:" is an OpenStack
+optional attribute that provides a description of the parameter.
+ONAP implementation requires this attribute.
 
 default
 _______
 
-R-90526 A VNF Heat Orchestration Template parameter
-declaration **MUST** not contain the default attribute.
 
-R-26124 If a VNF Heat Orchestration Template parameter
-requires a default value, it **MUST** be enumerated in the environment file.
+.. req::
+    :id: R-90526
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template parameter
+    declaration **MUST** not contain the default attribute.
+
+.. req::
+    :id: R-26124
+    :target: VNF
+    :keyword: MUST
+
+    If a VNF Heat Orchestration Template parameter
+    requires a default value, it **MUST** be enumerated in the environment file.
 
 Note that the parameter attribute "default:" is an OpenStack
 optional attribute that declares the default value of the
@@ -180,8 +254,14 @@ parameter. ONAP implementation prohibits the use of this attribute.
 hidden
 ______
 
-R-32557 A VNF's Heat Orchestration Template parameter
-declaration MAY contain the attribute "hidden:".
+
+.. req::
+    :id: R-32557
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template parameter
+    declaration **MAY** contain the attribute "hidden:".
 
 The parameter attribute "hidden:" is an OpenStack optional
 attribute that defines whether the parameters should be
@@ -195,24 +275,55 @@ ___________
 The parameter attribute "constraints:" is an OpenStack optional
 attribute that defines a list of constraints to apply to the parameter.
 
-R-88863 A VNF's Heat Orchestration Template's parameter defined as
-type "number" **MUST** have a parameter constraint of "range" or
-"allowed_values" defined.
 
-R-40518 A VNF's Heat Orchestration Template's parameter defined as
-type "string" **MAY** have a parameter constraint defined.
+.. req::
+    :id: R-88863
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's parameter defined as
+    type "number" **MUST** have a parameter constraint of "range" or
+    "allowed_values" defined.
+
+.. req::
+    :id: R-40518
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's parameter defined as
+    type "string" **MAY** have a parameter constraint defined.
+
+.. req::
+    :id: R-96227
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's parameter defined as
+    type "json" **MAY** have a parameter constraint defined.
+
+.. req::
+    :id: R-79817
+    :target: VNF
+    :keyword: MAY
 
-R-96227 A VNF's Heat Orchestration Template's parameter defined as
-type "json" **MAY** have a parameter constraint defined.
+    A VNF's Heat Orchestration Template's parameter defined as
+    type "comma_delimited_list" **MAY** have a parameter constraint defined.
 
-R-79817 A VNF's Heat Orchestration Template's parameter defined as
-type "comma_delimited_list" **MAY** have a parameter constraint defined.
+.. req::
+    :id: R-06613
+    :target: VNF
+    :keyword: MAY
 
-R-06613 A VNF's Heat Orchestration Template's parameter defined as
-type "boolean" **MAY** have a parameter constraint defined.
+    A VNF's Heat Orchestration Template's parameter defined as
+    type "boolean" **MAY** have a parameter constraint defined.
 
-R-00011 A VNF's Heat Orchestration Template's Nested YAML files
-parameter's **MUST NOT** have a parameter constraint defined.
+.. req::
+    :id: R-00011
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's Nested YAML files
+    parameter's **MUST NOT** have a parameter constraint defined.
 
 The constraints block of a parameter definition defines additional
 validation constraints that apply to the value of the parameter.
@@ -291,8 +402,14 @@ list. The syntax of the allowed_values constraint is
 immutable
 _________
 
-R-22589 A VNF's Heat Orchestration Template parameter declaration
-**MAY** contain the attribute "immutable:".
+
+.. req::
+    :id: R-22589
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template parameter declaration
+    **MAY** contain the attribute "immutable:".
 
 The parameter attribute \"immutable:\" is an OpenStack optional
 attribute that defines whether the parameter is updatable. A Heat
@@ -303,14 +420,30 @@ true and the parameter value is changed.  This attribute
 resources
 +++++++++
 
-R-23664 A VNF's Heat Orchestration template **MUST** contain
-the section "resources:".
 
-R-90152 A VNF's Heat Orchestration Template's "resources:"
-section **MUST** contain the declaration of at least one resource.
+.. req::
+    :id: R-23664
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration template **MUST** contain
+    the section "resources:".
 
-R-40551 A VNF's Heat Orchestration Template's Nested YAML files
-**MAY** contain the section "resources:".
+.. req::
+    :id: R-90152
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's "resources:"
+    section **MUST** contain the declaration of at least one resource.
+
+.. req::
+    :id: R-40551
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Nested YAML files
+    **MAY** contain the section "resources:".
 
 Each resource is defined as a
 separate block in the resources section with the following syntax.
@@ -346,13 +479,24 @@ separate block in the resources section with the following syntax.
 resource ID
 ___________
 
-R-75141 A VNF's Heat Orchestration Template's resource name
-(i.e., <resource ID>) **MUST** only contain alphanumeric
-characters and underscores ('_').
 
-R-16447 A VNF's <resource ID> **MUST** be unique across all
-Heat Orchestration Templates and all HEAT Orchestration Template
-Nested YAML files that are used to create the VNF.
+.. req::
+    :id: R-75141
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's resource name
+    (i.e., <resource ID>) **MUST** only contain alphanumeric
+    characters and underscores ('_').
+
+.. req::
+    :id: R-16447
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's <resource ID> **MUST** be unique across all
+    Heat Orchestration Templates and all HEAT Orchestration Template
+    Nested YAML files that are used to create the VNF.
 
 Note that a VNF can be composed of one or more Heat Orchestration Templates.
 
@@ -370,11 +514,22 @@ OS::Nova::Server or OS::Neutron::Port.
 The resource attribute \"type:\" may specify a VNF HEAT
 Orchestration Template Nested YAML file.
 
-R-53952 A VNF's Heat Orchestration Template's Resource
-**MUST NOT** reference a HTTP-based resource definitions.
 
-R-71699 A VNF's Heat Orchestration Template's Resource
-**MUST NOT** reference a HTTP-based Nested YAML file.
+.. req::
+    :id: R-53952
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's Resource
+    **MUST NOT** reference a HTTP-based resource definitions.
+
+.. req::
+    :id: R-71699
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's Resource
+    **MUST NOT** reference a HTTP-based Nested YAML file.
 
 properties
 __________
@@ -384,20 +539,34 @@ attribute that provides a list of resource-specific properties.
 The property value can be provided in place, or via a function
 (e.g., `Intrinsic functions <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-intrinsic-functions>`__).
 
-R-10834 If a VNF Heat Orchestration Template resource attribute
-"property:" uses a nested "get_param", one level of nesting is
-supported and the nested "get_param" **MUST** reference an index
+
+.. req::
+    :id: R-10834
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF Heat Orchestration Template resource attribute
+    "property:" uses a nested "get_param", one level of nesting is
+    supported and the nested "get_param" **MUST** reference an index.
 
 metadata
 ________
 
 The resource attribute \"metadata:\" is an OpenStack optional attribute.
 
-R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
-resource **MUST** contain the attribute "metadata".
 
-Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
+.. req::
+    :id: R-97199
+    :target: VNF
+    :keyword: MUST
 
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    resource **MUST** contain the attribute "metadata".
+
+Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
 
 depends_on
 __________
@@ -407,20 +576,38 @@ attribute.
 See `OpenStack documentation <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-resources-dependencies>`__
 for additional details.
 
-R-46968 VNF's Heat Orchestration Template's Resource **MAY**
-declare the attribute "depends_on:".
+
+.. req::
+    :id: R-46968
+    :target: VNF
+    :keyword: MAY
+
+    VNF's Heat Orchestration Template's Resource **MAY**
+    declare the attribute "depends_on:".
 
 update_policy
 _____________
 
-R-63137 VNF's Heat Orchestration Template's Resource **MAY**
-declare the attribute "update_policy:".
+
+.. req::
+    :id: R-63137
+    :target: VNF
+    :keyword: MAY
+
+    VNF's Heat Orchestration Template's Resource **MAY**
+    declare the attribute "update_policy:".
 
 deletion_policy
 _______________
 
-R-43740 A VNF's Heat Orchestration Template's Resource
-**MAY** declare the attribute "deletion_policy:".
+
+.. req::
+    :id: R-43740
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Resource
+    **MAY** declare the attribute "deletion_policy:".
 
 If specified, the \"deletion_policy:\" attribute for resources
 allows values 'Delete', 'Retain', and 'Snapshot'.
@@ -433,8 +620,14 @@ deleting a resource from the stack.
 external_id
 ___________
 
-R-78569 A VNF's Heat Orchestration Template's Resouce **MAY**
-declare the attribute "external_id:".
+
+.. req::
+    :id: R-78569
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Resouce **MAY**
+    declare the attribute "external_id:".
 
 This attribute allows for specifying the resource_id for an
 existing external (to the stack) resource. External resources
@@ -457,8 +650,14 @@ in the Newton release of OpenStack.
 outputs
 +++++++
 
-R-36982 A VNF's Heat Orchestration template **MAY**
-contain the "outputs:" section.
+
+.. req::
+    :id: R-36982
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration template **MAY**
+    contain the "outputs:" section.
 
 This section allows for specifying output parameters
 available to users once the template has been instantiated. If the
@@ -472,54 +671,99 @@ Environment File Format
 The environment file is a yaml text file.
 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
 
-R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
-environment file, even if no parameters are required to be enumerated.
+
+.. req::
+    :id: R-86285
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Heat Orchestration Template **MUST** have a corresponding
+    environment file, even if no parameters are required to be enumerated.
 
 The use of an environment file in OpenStack is optional.
 In ONAP, it is mandatory.
 
-R-03324 The VNF Heat Orchestration Template **MUST** contain the
-"parameters" section in the
-environment file
 
-R-68198 A VNF's Heat Orchestration template's Environment File's
-"parameters:" section **MAY** enumerate parameters.
+.. req::
+    :id: R-03324
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Heat Orchestration Template **MUST** contain the
+    "parameters" section in the environment file.
+
+.. req::
+    :id: R-68198
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration template's Environment File's
+    "parameters:" section **MAY** enumerate parameters.
 
 ONAP implementation requires the parameters section in the
 environmental file to be declared. The parameters section
 contains a list of key/value pairs.
 
-R-59930 A VNF's Heat Orchestration template's Environment
-File's **MAY** contain the "parameter_defaults:" section.
+
+.. req::
+    :id: R-59930
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration template's Environment
+    File's **MAY** contain the "parameter_defaults:" section.
 
 The "parameter_defaults:" section contains default parameters
 that are passed to all template resources.
 
-R-46096 A VNF's Heat Orchestration template's Environment File's
-**MAY** contain the "encrypted_parameters:" section.
+
+.. req::
+    :id: R-46096
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration template's Environment File's
+    **MAY** contain the "encrypted_parameters:" section.
 
 The "encrypted_parameters:" section contains a list of encrypted parameters.
 
-R-24893 A VNF's Heat Orchestration template's Environment File's
-**MAY** contain the "event_sinks:" section.
+
+.. req::
+    :id: R-24893
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration template's Environment File's
+    **MAY** contain the "event_sinks:" section.
 
 The "event_sinks:" section contains the list of endpoints that would
 receive stack events.
 
-R-42685 A VNF's Heat Orchestration template's Environment File's
-**MAY** contain the "parameter_merge_strategies:" section.
+
+.. req::
+    :id: R-42685
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration template's Environment File's
+    **MAY** contain the "parameter_merge_strategies:" section.
 
 The "parameter_merge_strategies:" section provides the merge strategies
 for merging parameters and parameter defaults from the environment file.
 
-R-67231 A VNF's Heat Orchestration template's Environment File's **MUST NOT**
-contain the "resource_registry:" section.
+
+.. req::
+    :id: R-67231
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration template's Environment File's **MUST NOT**
+    contain the "resource_registry:" section.
 
 ONAP implementation does not support the Environment File
 resource_registry section. The resource_registry section
 allows for the definition of custom resources.
 
-
 SDC Treatment of Environment Files
 ++++++++++++++++++++++++++++++++++
 
@@ -546,52 +790,117 @@ referred to as *VNF Modularity.*
 ONAP VNF Modularity Overview
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
-Templates, each of which represents a subset of the overall VNF.
+
+.. req::
+    :id: R-69663
+    :target: VNF
+    :keyword: MAY
+
+    A VNF **MAY** be composed from one or more Heat Orchestration
+    Templates, each of which represents a subset of the overall VNF.
 
 The Heat Orchestration Templates can be thought of a components or
 modules of the VNF and are referred to as "\ *VNF Modules*\ ".
 During orchestration, these modules are
 deployed incrementally to create the complete VNF.
 
-R-33132 A VNF's Heat Orchestration Template **MAY** be
 
-   * a Base Module Heat Orchestration Template
-     (also referred to as a Base Module)
-   * an Incremental Module Heat Orchestration Template
-     (referred to as an Incremental Module)
-   * a Cinder Volume Module Heat Orchestration Template
-     (referred to as Cinder Volume Module).
+.. req::
+    :id: R-33132
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template **MAY** be
+
+       * a Base Module Heat Orchestration Template
+         (also referred to as a Base Module)
 
-R-37028 The VNF **MUST** be composed of one "base" module.
+       * an Incremental Module Heat Orchestration Template
+         (referred to as an Incremental Module)
 
-R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
+       * a Cinder Volume Module Heat Orchestration Template
+         (referred to as Cinder Volume Module).
 
-R-20974 The VNF **MUST** deploy the base module first, prior to
-the incremental modules.
+.. req::
+    :id: R-37028
+    :target: VNF
+    :keyword: MUST
 
-R-28980 A VNF's incremental module **MAY** be used for initial VNF
-deployment only.
+    The VNF **MUST** be composed of one "base" module.
 
-R-86926 A VNF's incremental module **MAY** be used for scale out only.
+.. req::
+    :id: R-13196
+    :target: VNF
+    :keyword: MAY
+
+    A VNF **MAY** be composed of zero to many Incremental Modules.
+
+.. req::
+    :id: R-20974
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** deploy the base module first, prior to
+    the incremental modules.
+
+.. req::
+    :id: R-28980
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's incremental module **MAY** be used for initial VNF
+    deployment only.
+
+.. req::
+    :id: R-86926
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's incremental module **MAY** be used for scale out only.
 
 A VNF's Incremental Module that is used for scale out is deployed
 sometime after initial VNF deployment to add capacity.
 
-R-91497 A VNF's incremental module **MAY** be used for both deployment
-and scale out.
 
-R-68122 A VNF's incremental module **MAY** be deployed more than once,
-either during initial VNF deployment and/or scale out.
+.. req::
+    :id: R-91497
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's incremental module **MAY** be used for both deployment
+    and scale out.
 
-R-46119 A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
-**MAY** be defined in a Base Module.
+.. req::
+    :id: R-68122
+    :target: VNF
+    :keyword: MAY
 
-R-90748 A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
-**MAY** be defined in an Incremental Module.
+    A VNF's incremental module **MAY** be deployed more than once,
+    either during initial VNF deployment and/or scale out.
 
-R-03251 A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
-**MAY** be defined in a Cinder Volume Module.
+.. req::
+    :id: R-46119
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
+    **MAY** be defined in a Base Module.
+
+.. req::
+    :id: R-90748
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
+    **MAY** be defined in an Incremental Module.
+
+.. req::
+    :id: R-03251
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
+    **MAY** be defined in a Cinder Volume Module.
 
 ONAP also supports the concept of an optional, independently deployed Cinder
 volume via a separate Heat Orchestration Templates, referred to as a Cinder
@@ -599,20 +908,37 @@ Volume Module. This allows the volume to persist after a Virtual Machine
 (VM) (i.e., OS::Nova::Server) is deleted, allowing the volume to be reused
 on another instance (e.g., during a failover activity).
 
-R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it
-exists, to be 1:1 with the VNF Base Module or Incremental Module.
+.. req::
+    :id: R-11200
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** keep the scope of a Cinder volume module,
+    when it exists, to be 1:1 with the VNF Base Module or Incremental Module.
 
 It is strongly recommended that Cinder Volumes be created in a Cinder Volume
 Module.
 
-R-38474 The VNF **MUST** have a corresponding environment file for a
-Base Module.
+.. req::
+    :id: R-38474
+    :target: VNF
+    :keyword: MUST
 
-R-81725 The VNF **MUST** have a corresponding environment file for an
-Incremental Module.
+    The VNF **MUST** have a corresponding environment file for a Base Module.
+
+.. req::
+    :id: R-81725
+    :target: VNF
+    :keyword: MUST
 
-R-53433 The VNF **MUST** have a corresponding environment file for a
-Cinder Volume Module.
+    The VNF **MUST** have a corresponding environment file for an Incremental Module.
+
+.. req::
+    :id: R-53433
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** have a corresponding environment file for a Cinder Volume Module.
 
 These concepts will be described in more detail throughout the document.
 This overview is provided to set the stage and help clarify the concepts
@@ -624,11 +950,27 @@ Nested Heat Orchestration Templates Overview
 ONAP supports nested Heat Orchestration Templates per OpenStack
 specifications.
 
-R-36582 A VNF's Base Module **MAY** utilize nested heat.
 
-R-56721 A VNF's Incremental Module **MAY** utilize nested heat.
+.. req::
+    :id: R-36582
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Base Module **MAY** utilize nested heat.
+
+.. req::
+    :id: R-56721
+    :target: VNF
+    :keyword: MAY
 
-R-30395 A VNF's Cinder Volume Module **MAY** utilize nested heat.
+    A VNF's Incremental Module **MAY** utilize nested heat.
+
+.. req::
+    :id: R-30395
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Cinder Volume Module **MAY** utilize nested heat.
 
 Nested templates may be suitable for larger VNFs that contain many
 repeated instances of the same VM type(s). A common usage pattern is to
@@ -649,50 +991,95 @@ In the examples below, <text> represents any alphanumeric string that
 must not contain any special characters and must not contain the word
 "base".
 
-R-87485 A VNF's Heat Orchestration Template's file extension **MUST**
-be in the lower case format '.yaml' or '.yml'.
 
-R-56438 A VNF's Heat Orchestration Template's Nested YAML file extension
-**MUST** be in the lower case format '.yaml' or '.yml'.
+.. req::
+    :id: R-87485
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's file extension **MUST**
+    be in the lower case format '.yaml' or '.yml'.
+
+.. req::
+    :id: R-56438
+    :target: VNF
+    :keyword: MUST
 
-R-74304 A VNF's Heat Orchestration Template's Environment file extension
-**MUST** be in the lower case format '.env'.
+    A VNF's Heat Orchestration Template's Nested YAML file extension
+    **MUST** be in the lower case format '.yaml' or '.yml'.
 
-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-74304
+    :target: VNF
+    :keyword: MUST
 
+    A VNF's Heat Orchestration Template's Environment file extension
+    **MUST** be in the lower case format '.env'.
+
+.. req::
+    :id: R-99646
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    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.
 
 Base Modules
 ++++++++++++
 
-R-81339 A VNF Heat Orchestration Template's Base Module file name **MUST**
-include 'base' in the filename and **MUST** match one of the following four
-formats:
 
-   * 'base_<text>.y[a]ml'
-   * '<text>_base.y[a]ml'
-   * 'base.y[a]ml'
-   * '<text>_base_<text>'.y[a]ml
+.. req::
+    :id: R-81339
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Base Module file name **MUST**
+    include 'base' in the filename and **MUST** match one of the following four
+    formats:
+
+       * 'base_<text>.y[a]ml'
+       * '<text>_base.y[a]ml'
+       * 'base.y[a]ml'
+       * '<text>_base_<text>'.y[a]ml
 
-where 'base' is case insensitive and where '<text>'
-**MUST** contain only alphanumeric characters
-and underscores '_' and **MUST NOT** contain the case
-insensitive word 'base'.
+    where 'base' is case insensitive and where '<text>'
+    **MUST** contain only alphanumeric characters
+    and underscores '_' and **MUST NOT** contain the case
+    insensitive word 'base'.
 
-R-91342  A VNF Heat Orchestration Template's Base Module's Environment File
-**MUST** be named identical to the VNF Heat Orchestration Template's Base
-Module with '.y[a]ml' replaced with '.env'.
+.. req::
+    :id: R-91342
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Base Module's Environment File
+    **MUST** be named identical to the VNF Heat Orchestration Template's Base
+    Module with '.y[a]ml' replaced with '.env'.
 
 Incremental Modules
 +++++++++++++++++++
 
-R-87247 A VNF Heat Orchestration Template's Incremental Module file name
-**MUST** contain only alphanumeric characters and underscores '_' and
-**MUST NOT** contain the case insensitive word 'base'.
 
-R-94509 A VNF Heat Orchestration Template's Incremental Module's Environment
-File **MUST** be named identical to the VNF Heat Orchestration Template's
-Incremental Module with '.y[a]ml' replaced with '.env'.
+.. req::
+    :id: R-87247
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Incremental Module file name
+    **MUST** contain only alphanumeric characters and underscores '_' and
+    **MUST NOT** contain the case insensitive word 'base'.
+
+.. req::
+    :id: R-94509
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Incremental Module's Environment
+    File **MUST** be named identical to the VNF Heat Orchestration Template's
+    Incremental Module with '.y[a]ml' replaced with '.env'.
 
 To clearly identify the incremental module, it is recommended to use the
 following naming options for modules:
@@ -708,24 +1095,49 @@ following naming options for modules:
 Cinder Volume Modules
 +++++++++++++++++++++
 
-R-82732 A VNF Heat Orchestration Template's Cinder Volume Module **MUST** be
-named identical to the base or incremental module it is supporting with
-'_volume appended'
 
-R-31141 A VNF Heat Orchestration Template's Cinder Volume Module's Environment
-File **MUST** be named identical to the VNF Heat Orchestration Template's
-Cinder Volume Module with .y[a]ml replaced with '.env'.
+.. req::
+    :id: R-82732
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Cinder Volume Module **MUST** be
+    named identical to the base or incremental module it is supporting with
+    '_volume appended'
+
+.. req::
+    :id: R-31141
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Cinder Volume Module's Environment
+    File **MUST** be named identical to the VNF Heat Orchestration Template's
+    Cinder Volume Module with .y[a]ml replaced with '.env'.
 
 Nested Heat file
 ++++++++++++++++
 
-R-76057 A VNF Heat Orchestration Template's Nested YAML file name **MUST**
-contain only alphanumeric characters and underscores '_' and **MUST NOT**
-contain the case insensitive word 'base'.
 
-R-70276 A VNF HEAT's Orchestration Nested Template's YAML file
-name **MUST NOT** be in the format '{vm-type}.y[a]ml' where
-'{vm-type}' is defined in the Heat Orchestration Template.
+.. req::
+    :id: R-76057
+    :target: VNF
+    :keyword: MUST
+
+    A VNF Heat Orchestration Template's Nested YAML file name **MUST**
+    contain only alphanumeric characters and underscores '_' and **MUST NOT**
+    contain the case insensitive word 'base'.
+
+.. req::
+    :id: R-70276
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF HEAT's Orchestration Nested Template's YAML file
+    name **MUST NOT** be in the format '{vm-type}.y[a]ml' where
+    '{vm-type}' is defined in the Heat Orchestration Template.
 
 Examples include
 
@@ -767,20 +1179,32 @@ A Base Module Output Parameter may be used as an input parameter in any
 incremental module in the VNF.  Note that the parameter is not
 available to other VNFs.
 
-R-52753 VNF's Heat Orchestration Template's Base Module's output parameter's
-name and type **MUST** match the VNF's Heat Orchestration Template's
-incremental Module's name and type unless the output parameter is of type
-'comma_delimited_list', then the corresponding input parameter **MUST**
-be declared as type 'json'.
+
+.. req::
+    :id: R-52753
+    :target: VNF
+    :keyword: MUST
+
+    VNF's Heat Orchestration Template's Base Module's output parameter's
+    name and type **MUST** match the VNF's Heat Orchestration Template's
+    incremental Module's name and type unless the output parameter is of type
+    'comma_delimited_list', then the corresponding input parameter **MUST**
+    be declared as type 'json'.
 
 If the Output parameter has a comma_delimited_list value (e.g., a collection
 of UUIDs from a Resource Group), then the corresponding input parameter
 must be declared as type json and not a comma_delimited_list, which is
 actually a string value with embedded commas.
 
-R-22608 When a VNF's Heat Orchestration Template's Base Module's output
-parameter is declared as an input parameter in an Incremental Module,
-the parameter attribute 'constraints:' **MUST NOT** be declared.
+
+.. req::
+    :id: R-22608
+    :target: VNF
+    :keyword: MUST NOT
+
+    When a VNF's Heat Orchestration Template's Base Module's output
+    parameter is declared as an input parameter in an Incremental Module,
+    the parameter attribute 'constraints:' **MUST NOT** be declared.
 
 Additional details on ONAP Base Module Output Parameters are provided in
 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
@@ -788,28 +1212,46 @@ Additional details on ONAP Base Module Output Parameters are provided in
 ONAP Volume Module Output Parameters
 ++++++++++++++++++++++++++++++++++++
 
-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 other Output Parameters **MAY** be included.
+
+.. req::
+    :id: R-89913
+    :target: VNF
+    :keyword: MUST
+
+    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 other Output Parameters **MAY** be included.
 
 A VNF's Heat Orchestration Template's Cinder Volume Module Output Parameter(s)
 are only available for the module (base or incremental) that the volume
 template is associated with.
 
-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'.
+
+.. req::
+    :id: R-07443
+    :target: VNF
+    :keyword: MUST
+
+    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'.
 
 If the Output parameter has a comma_delimited_list value (e.g., a collection
 of UUIDs from a Resource Group), then the corresponding input parameter must
 be declared as type json and not a comma\_delimited\_list, which is actually a
 string value with embedded commas.
 
-R-20547 When an ONAP Volume Module Output Parameter is declared as an input
-parameter in a base or an incremental module Heat Orchestration Template,
-parameter constraints **MUST NOT** be declared.
+
+.. req::
+    :id: R-20547
+    :target: VNF
+    :keyword: MUST NOT
+
+    When an ONAP Volume Module Output Parameter is declared as an input
+    parameter in a base or an incremental module Heat Orchestration Template,
+    parameter constraints **MUST NOT** be declared.
 
 Additional details on ONAP Base Module Output Parameters are provided in
 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
@@ -828,25 +1270,48 @@ Support of heat stack update
 ONAP does not support the use of heat stack-update command for scaling
 (growth/de-growth).
 
-R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to
-utilize the OpenStack 'heat stack-update' command for scaling
-(growth/de-growth).
 
-R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template
-design to support scaling (growth/de-growth).
+.. req::
+    :id: R-39349
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF Heat Orchestration Template **MUST NOT** be designed to
+    utilize the OpenStack 'heat stack-update' command for scaling
+    (growth/de-growth).
+
+.. req::
+    :id: R-43413
+    :target: VNF
+    :keyword: MUST
+
+    A VNF **MUST** utilize a modular Heat Orchestration Template
+    design to support scaling (growth/de-growth).
 
 Scope of a Heat Orchestration Template
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-R-59482 A VNF's Heat Orchestration Template **MUST NOT** be VNF instance
-specific or Cloud site specific
+
+.. req::
+    :id: R-59482
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template **MUST NOT** be VNF instance
+    specific or Cloud site specific.
 
 ONAP provides the instance specific parameter values to the Heat
 Orchestration Template at orchestration time.
 
-R-01896 A VNF's Heat Orchestration Template's parameter values that are
-constant across all deployments **MUST** be declared in a Heat Orchestration
-Template Environment File.
+
+.. req::
+    :id: R-01896
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's parameter values that are
+    constant across all deployments **MUST** be declared in a Heat Orchestration
+    Template Environment File.
 
 Networking
 ^^^^^^^^^^
@@ -863,40 +1328,85 @@ VMs in another VNF or an external gateway or external router.
 
 An External Network may be a Neutron Network or a Contrail Network.
 
-R-16968 A VNF's Heat Orchestration Templates **MUST NOT** include heat
-resources to create external networks.
+
+.. req::
+    :id: R-16968
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Templates **MUST NOT** include heat
+    resources to create external networks.
 
 External networks must be orchestrated separately, independent of the VNF.
 This allows the network to be shared by multiple VNFs and managed
 independently of VNFs.
 
-R-00606 A VNF **MAY** be connected to zero, one or more than one external
-networks.
-
-R-57424 A VNF's port connected to an external network **MUST**
-use the port for the purpose of reaching VMs in another VNF
-and/or an external gateway and/or external router. A VNF's port
-connected to an external network **MAY** use the port for
-the purpose of reaching VMs in the same VNF.
-
-R-29865 When a VNF connects to an external network, a network role,
-referred to as the '{network-role}' **MUST** be assigned to the
-external network for use in the VNF's Heat Orchestration Template.
-
-R-69014 When a VNF connects to an external network, a network role, referred
-to as the '{network-role}' **MUST** be assigned to the external network
-for use in the VNF's Heat Orchestration Template.
-
-R-05201 When a VNF connects to two or more external networks, each external
-network **MUST** be assigned a unique '{network-role}' in the context of
-the VNF for use in the VNF's Heat Orchestration Template.
 
-R-83015 A VNF's '{network-role}' assigned to an external network **MUST**
-be different than the '{network-role}' assigned to the VNF's internal
-networks, if internal networks exist.
-
-R-99794 An external network **MUST** have one subnet.  An external network
-**MAY** have more than one subnet.
+.. req::
+    :id: R-00606
+    :target: VNF
+    :keyword: MAY
+
+    A VNF **MAY** be connected to zero, one or more than one external
+    networks.
+
+.. req::
+    :id: R-57424
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's port connected to an external network **MUST**
+    use the port for the purpose of reaching VMs in another VNF
+    and/or an external gateway and/or external router. A VNF's port
+    connected to an external network **MAY** use the port for
+    the purpose of reaching VMs in the same VNF.
+
+.. req::
+    :id: R-29865
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF connects to an external network, a network role,
+    referred to as the '{network-role}' **MUST** be assigned to the
+    external network for use in the VNF's Heat Orchestration Template.
+
+.. req::
+    :id: R-69014
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF connects to an external network, a network role, referred
+    to as the '{network-role}' **MUST** be assigned to the external network
+    for use in the VNF's Heat Orchestration Template.
+
+.. req::
+    :id: R-05201
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF connects to two or more external networks, each external
+    network **MUST** be assigned a unique '{network-role}' in the context of
+    the VNF for use in the VNF's Heat Orchestration Template.
+
+.. req::
+    :id: R-83015
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's '{network-role}' assigned to an external network **MUST**
+    be different than the '{network-role}' assigned to the VNF's internal
+    networks, if internal networks exist.
+
+.. req::
+    :id: R-99794
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    An external network **MUST** have one subnet. An external network
+    **MAY** have more than one subnet.
 
 Note that this document refers to **'{network-role}'** which in reality
 is the **'{network-role-tag}'**.  The value of the
@@ -936,50 +1446,109 @@ to as "intra-VNF" networks or "private" networks. An internal network
 only connects VMs in a single VNF; it must not connect to other VNFs
 or an external gateway or router
 
-R-87096 A VNF **MAY** contain zero, one or more than one internal networks.
-
-R-35666 If a VNF has an internal network, the VNF Heat Orchestration
-Template **MUST** include the heat resources to create the internal network.
-
-R-86972 A VNF **SHOULD** create the internal network in the VNF's Heat
-Orchestration Template Base Module.
-
-An Internal Network may be created using Neutron Heat Resources and/or
-Contrail Heat Resources.
 
-R-52425 A VNF's port connected to an internal network **MUST** connect
-the port to VMs in the same VNF.
+.. req::
+    :id: R-87096
+    :target: VNF
+    :keyword: MAY
 
-R-46461 A VNF's port connected to an internal network **MUST NOT** connect
-the port to VMs in another VNF and/or an external gateway and/or
-external router.
+    A VNF **MAY** contain zero, one or more than one internal networks.
 
-R-68936 When a VNF creates an internal network, a network role, referred to
-as the '{network-role}' **MUST** be assigned to the internal network for
-use in the VNF's Heat Orchestration Template.
+.. req::
+    :id: R-35666
+    :target: VNF
+    :keyword: MUST
 
-R-32025 When a VNF creates two or more internal networks, each internal
-network **MUST** be assigned a unique '{network-role}' in the context of
-the VNF for use in the VNF's Heat Orchestration Template.
+    If a VNF has an internal network, the VNF Heat Orchestration
+    Template **MUST** include the heat resources to create the internal network.
 
-R-69874 A VNF's '{network-role}' assigned to an internal network **MUST**
-be different than the '{network-role}' assigned to the VNF's external
-networks.
+.. req::
+    :id: R-86972
+    :target: VNF
+    :keyword: SHOULD
 
-R-16241 A VNF's internal network **MUST** have one subnet.
-A VNF's internal network **MAY** have more than one subnet.
+    A VNF **SHOULD** create the internal network in the VNF's Heat
+    Orchestration Template Base Module.
 
-R-34726 If a VNF's port is connected to an internal network and the port
-is created in the same Heat Orchestration Template as the internal network,
-then the port resource **MUST** use a 'get_resource' to obtain
-the network UUID.
+An Internal Network may be created using Neutron Heat Resources and/or
+Contrail Heat Resources.
 
-R-22688  If a VNF's port is connected to an internal network and the
-port is created in an Incremental Module and the internal network is created
-in the Base Module then the UUID of the internal network **MUST** be exposed
-as a parameter in the 'outputs:' section of the Base Module and the port
-resource **MUST** use a 'get_param' to obtain the network UUID.
 
+.. req::
+    :id: R-52425
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's port connected to an internal network **MUST** connect
+    the port to VMs in the same VNF.
+
+.. req::
+    :id: R-46461
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's port connected to an internal network **MUST NOT** connect
+    the port to VMs in another VNF and/or an external gateway and/or
+    external router.
+
+.. req::
+    :id: R-68936
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF creates an internal network, a network role, referred to
+    as the '{network-role}' **MUST** be assigned to the internal network for
+    use in the VNF's Heat Orchestration Template.
+
+.. req::
+    :id: R-32025
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF creates two or more internal networks, each internal
+    network **MUST** be assigned a unique '{network-role}' in the context of
+    the VNF for use in the VNF's Heat Orchestration Template.
+
+.. req::
+    :id: R-69874
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's '{network-role}' assigned to an internal network **MUST**
+    be different than the '{network-role}' assigned to the VNF's external
+    networks.
+
+.. req::
+    :id: R-16241
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's internal network **MUST** have one subnet.
+    A VNF's internal network **MAY** have more than one subnet.
+
+.. req::
+    :id: R-34726
+    :target: VNF
+    :keyword: MUST
+
+    If a VNF's port is connected to an internal network and the port
+    is created in the same Heat Orchestration Template as the internal network,
+    then the port resource **MUST** use a 'get_resource' to obtain
+    the network UUID.
+
+.. req::
+    :id: R-22688
+    :target: VNF
+    :keyword: MUST
+
+    If a VNF's port is connected to an internal network and the
+    port is created in an Incremental Module and the internal network is created
+    in the Base Module then the UUID of the internal network **MUST** be exposed
+    as a parameter in the 'outputs:' section of the Base Module and the port
+    resource **MUST** use a 'get_param' to obtain the network UUID.
 ONAP does not programmatically enforce a naming convention for
 parameters for internal network. However, a naming convention is
 provided that must be followed.
@@ -998,10 +1567,16 @@ This section provides the ONAP naming requirements for
 {vm-type}
 ~~~~~~~~~
 
-R-01455 When a VNF's Heat Orchestration Template creates a
-Virtual Machine  (i.e., 'OS::Nova::Server'), each 'class' of VMs
-**MUST** be assigned a VNF unique '{vm-type}'; where 'class'
-defines VMs that **MUST** have the following identical characteristics:
+
+.. req::
+    :id: R-01455
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF's Heat Orchestration Template creates a
+    Virtual Machine  (i.e., 'OS::Nova::Server'), each 'class' of VMs
+    **MUST** be assigned a VNF unique '{vm-type}'; where 'class'
+    defines VMs that **MUST** have the following identical characteristics:
 
       1.) OS::Nova::Server property flavor value
 
@@ -1016,89 +1591,170 @@ defines VMs that **MUST** have the following identical characteristics:
           of ports connecting to the identical networks and requiring the
           identical IP address configuration.
 
-R-82481 A VNF's Heat Orchestration Template's Resource property
-parameter that is
-associated with a unique Virtual Machine type **MUST**
-include '{vm-type}'  as part of the parameter name with two
-exceptions:
+.. req::
+    :id: R-82481
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's Resource property
+    parameter that is associated with a unique Virtual Machine
+    type **MUST** include '{vm-type}'  as part of the parameter
+    name with two exceptions:
+
+      1.) The Resource OS::Nova::Server property availability_zone parameter
+      **MUST NOT** be prefixed with a common '{vm-type} identifier,
 
-     1.) The Resource OS::Nova::Server property availability_zone parameter
-     **MUST NOT** be prefixed with a common '{vm-type} identifier,
+      2.) The Resource OS::Nova::Server eight mandatory and optional metadata
+      parameters (vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role,
+      vf_module_index, environment_context, workload_context) **MUST NOT**
+      be prefixed with a common '{vm-type}' identifier.
 
-     2.) The Resource OS::Nova::Server eight mandatory and optional metadata
-     parameters (vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role,
-     vf_module_index, environment_context, workload_context) **MUST NOT**
-     be prefixed with a common '{vm-type}' identifier.
+.. req::
+    :id: R-66729
+    :target: VNF
+    :keyword: MUST
 
+    A VNF's Heat Orchestration Template's Resource that is
+    associated with a unique Virtual Machine type **MUST** include
+    '{vm-type}' as part of the resource ID.
 
-R-66729 A VNF's Heat Orchestration Template's Resource that is
-associated with a unique Virtual Machine type **MUST** include
-'{vm-type}' as part of the resource ID.
+.. req::
+    :id: R-98407
+    :target: VNF
+    :keyword: MUST NOT
 
-R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
-only alphanumeric characters and/or underscores '_' and
-**MUST NOT** contain any of the following strings: '\_int' or 'int\_'
-or '\_int\_'.
+    A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
+    only alphanumeric characters and/or underscores '_' and
+    **MUST NOT** contain any of the following strings: '_int' or 'int\_'
+    or '\_int\_'.
 
-R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
-substring of {network-role}.
+.. req::
+    :id: R-48067
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
+    substring of {network-role}.
 
 It may cause the VNF Validation Program validation-scripts project
 to produce erroneous error messages.
 
-R-32394 A VNF's Heat Orchestration Template's use of '{vm-type}'
-in all Resource property parameter names **MUST** be the same case.
 
-R-46839 A VNF's Heat Orchestration Template's use of
-'{vm-type}' in all Resource IDs **MUST** be the same case.
+.. req::
+    :id: R-32394
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's use of '{vm-type}'
+    in all Resource property parameter names **MUST** be the same case.
+
+.. req::
+    :id: R-46839
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's use of
+    '{vm-type}' in all Resource IDs **MUST** be the same case.
 
-R-36687 A VNF's Heat Orchestration Template's '{vm-type}' case in
-Resource property parameter names **SHOULD** match the case of
-'{vm-type}' in Resource IDs and vice versa.
+.. req::
+    :id: R-36687
+    :target: VNF
+    :keyword: SHOULD
+
+    A VNF's Heat Orchestration Template's '{vm-type}' case in
+    Resource property parameter names **SHOULD** match the case of
+    '{vm-type}' in Resource IDs and vice versa.
 
 {network-role}
 ~~~~~~~~~~~~~~
 
 The assignment of a {network-role} is discussed in `Networking`_.
 
-R-21330 A VNF's Heat Orchestration Template's Resource property
-parameter that is associated with external network **MUST**
-include the '{network-role}' as part of the parameter name
 
-R-11168 A VNF's Heat Orchestration Template's Resource ID that is
-associated with an external network **MUST** include the
-'{network-role}' as part of the resource ID.
+.. req::
+    :id: R-21330
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's Resource property
+    parameter that is associated with external network **MUST**
+    include the '{network-role}' as part of the parameter name.
+
+.. req::
+    :id: R-11168
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's Resource ID that is
+    associated with an external network **MUST** include the
+    '{network-role}' as part of the resource ID.
+
+.. req::
+    :id: R-84322
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's Resource property
+    parameter that is associated with an internal network
+    **MUST** include 'int\_{network-role}' as part of the parameter
+    name, where 'int\_' is a hard coded string.
+
+.. req::
+    :id: R-96983
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's Resource ID that is
+    associated with an internal network **MUST** include
+    'int\_{network-role}' as part of the Resource ID, where
+    'int\_' is a hard coded string.
 
-R-84322 A VNF's Heat Orchestration Template's Resource property
-parameter that is associated with an internal network
-**MUST** include 'int\_{network-role}' as part of the parameter
-name, where 'int\_' is a hard coded string.
+.. req::
+    :id: R-26506
+    :target: VNF
+    :keyword: MUST
 
-R-96983 A VNF's Heat Orchestration Template's Resource ID that is
-associated with an internal network **MUST** include
-'int\_{network-role}' as part of the Resource ID, where
-'int\_' is a hard coded string.
+    A VNF's Heat Orchestration Template's '{network-role}'
+    **MUST** contain only alphanumeric characters and/or
+    underscores '_' and **MUST NOT** contain any of the following
+    strings: '_int' or 'int\_' or '\_int\_'.
 
-R-26506 A VNF's Heat Orchestration Template's '{network-role}'
-**MUST** contain only alphanumeric characters and/or
-underscores '_' and **MUST NOT** contain any of the following
-strings: '\_int' or 'int\_' or '\_int\_'.
+.. req::
+    :id: R-00977
+    :target: VNF
+    :keyword: MUST NOT
 
-R-00977 A VNF's Heat Orchestration Template's '{network-role}'
-**MUST NOT** be a substring of '{vm-type}'.
+    A VNF's Heat Orchestration Template's '{network-role}'
+    **MUST NOT** be a substring of '{vm-type}'.
 
 For example, if a VNF has a '{vm-type}' of 'oam' and a
 '{network-role}' of 'oam\_protected' would be a violation of the requirement.
 
-R-58424 A VNF's Heat Orchestration Template's use of '{network-role}'
-in all Resource property parameter names **MUST** be the same case
 
-R-21511 A VNF's Heat Orchestration Template's use of '{network-role}'
-in all Resource IDs **MUST** be the same case.
+.. req::
+    :id: R-58424
+    :target: VNF
+    :keyword: MUST
 
-R-86588 A VNF's Heat Orchestration Template's '{network-role}' case
-in Resource property parameter names **SHOULD** match the case
-of '{network-role}' in Resource IDs and vice versa.
+    A VNF's Heat Orchestration Template's use of '{network-role}'
+    in all Resource property parameter names **MUST** be the same case.
+
+.. req::
+    :id: R-21511
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's use of '{network-role}'
+    in all Resource IDs **MUST** be the same case.
+
+.. req::
+    :id: R-86588
+    :target: VNF
+    :keyword: SHOULD
+
+    A VNF's Heat Orchestration Template's '{network-role}' case
+    in Resource property parameter names **SHOULD** match the case
+    of '{network-role}' in Resource IDs and vice versa.
 
 Resource IDs
 ~~~~~~~~~~~~
@@ -1117,66 +1773,98 @@ Orchestration Templates the compose the VNF.
 
 Heat Orchestration Template resources are described in `resources`_
 
-R-54517 When a VNF's Heat Orchestration Template's resource is associated
-with a single '{vm-type}', the Resource ID **MUST** contain the '{vm-type}'.
 
-R-96482 When a VNF's Heat Orchestration Template's resource is associated
-with a single external network, the Resource ID MUST contain the text
-'{network-role}'.
+.. req::
+    :id: R-54517
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF's Heat Orchestration Template's resource is associated
+    with a single '{vm-type}', the Resource ID **MUST** contain the '{vm-type}'.
+
+.. req::
+    :id: R-96482
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF's Heat Orchestration Template's resource is associated
+    with a single external network, the Resource ID **MUST** contain the text
+    '{network-role}'.
+
+.. req::
+    :id: R-98138
+    :target: VNF
+    :keyword: MUST
 
-R-98138 When a VNF's Heat Orchestration Template's resource is associated
-with a single internal network, the Resource ID MUST contain the text
-'int\_{network-role}'.
+    When a VNF's Heat Orchestration Template's resource is associated
+    with a single internal network, the Resource ID **MUST** contain the text
+    'int\_{network-role}'.
 
-R-82115 When a VNF's Heat Orchestration Template's resource is associated
-with a single '{vm-type}' and a single external network, the Resource
-ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
+.. req::
+    :id: R-82115
+    :target: VNF
+    :keyword: MUST
 
-- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
-  be separated by an underscore '_'
+    When a VNF's Heat Orchestration Template's resource is associated
+    with a single '{vm-type}' and a single external network, the Resource
+    ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
 
-   - e.g., '{vm-type}\_{network-role}', '{vm-type}\_{index}\_{network-role}'
+      - the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
+        be separated by an underscore '_'
 
-- note that an '{index}' value **MAY** separate the '{vm-type}' and the
-  '{network-role}' and when this occurs underscores **MUST** separate the
-  three values.
+          - e.g.,'{vm-type}\_{network-role}', '{vm-type}\_{index}\_{network-role}'
 
-Note that an '{index}' value may separate the '{vm-type}' and the
-'{network-role}'. An underscore must separate the three values
-(e.g., {vm-type}_{index}_{network-role}).
+      - note that an '{index}' value **MAY** separate the '{vm-type}' and the
+        '{network-role}' and when this occurs underscores **MUST** separate the
+        three values.
 
-R-82551 When a VNF's Heat Orchestration Template's resource is associated
-with a single '{vm-type}' and a single internal network, the Resource ID
-**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
+.. req::
+    :id: R-82551
+    :target: VNF
+    :keyword: MUST
 
-- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
-  **MUST** be separated by an underscore '_'
+    When a VNF's Heat Orchestration Template's resource is associated
+    with a single '{vm-type}' and a single internal network, the Resource ID
+    **MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
 
-   - (e.g., '{vm-type}\_int\_{network-role}',
-     '{vm-type}_{index}\_int\_{network-role}')
+      - the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
+      **MUST** be separated by an underscore '_'
 
-- note that an '{index}' value **MAY** separate the '{vm-type}' and the
-  'int\_{network-role}' and when this occurs underscores **MUST** separate
-  the three values.
+        - e.g.,'{vm-type}\_int\_{network-role}', '{vm-type}_{index}\_int\_{network-role}'
 
-Note that an '{index}' value may separate the '{vm-type}' and the
-'int_{network-role}'. An underscore will separate the three values
-(e.g., {vm-type}_{index}_int_{network-role}).
+      - note that an '{index}' value **MAY** separate the '{vm-type}' and the
+        'int\_{network-role}' and when this occurs underscores **MUST** separate
+        the three values.
 
-R-67793 When a VNF's Heat Orchestration Template's resource is associated
-with more than one '{vm-type}' and/or more than one internal and/or
-external network, the Resource ID **MUST NOT** contain the '{vm-type}'
-and/or '{network-role}'/'int\_{network-role}'. It also should contain the
-term 'shared' and/or contain text that identifies the VNF.
+.. req::
+    :id: R-67793
+    :target: VNF
+    :keyword: MUST NOT
 
-R-27970 When a VNF's Heat Orchestration Template's resource is associated
-with more than one '{vm-type}' and/or more than one internal and/or
-external network, the Resource ID **MAY** contain the term 'shared'
-and/or **MAY** contain text that identifies the VNF.
+    When a VNF's Heat Orchestration Template's resource is associated
+    with more than one '{vm-type}' and/or more than one internal and/or
+    external network, the Resource ID **MUST NOT** contain the '{vm-type}'
+    and/or '{network-role}'/'int\_{network-role}'. It also should contain the
+    term 'shared' and/or contain text that identifies the VNF
 
-R-11690 When a VNF's Heat Orchestration Template's Resource ID contains
-an {index} value (e.g. multiple VMs of same {vm-type}), the '{index}'
-**MUST** start at zero and increment by one.
+.. req::
+    :id: R-27970
+    :target: VNF
+    :keyword: MAY
+
+    When a VNF's Heat Orchestration Template's resource is associated
+    with more than one '{vm-type}' and/or more than one internal and/or
+    external network, the Resource ID **MAY** contain the term 'shared'
+    and/or **MAY** contain text that identifies the VNF.
+
+.. req::
+    :id: R-11690
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF's Heat Orchestration Template's Resource ID contains
+    an {index} value (e.g. multiple VMs of same {vm-type}), the '{index}'
+    **MUST** start at zero and increment by one.
 
 OpenStack Heat Resources Resource ID Naming Convention
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
@@ -1188,60 +1876,112 @@ in the following sections.
 OS::Cinder::Volume
 __________________
 
-R-87004 A VNF's Heat Orchestration Template's Resource
-OS::Cinder::Volume Resource ID **SHOULD** use the naming convention
 
-   * {vm-type}\_volume\_{index}
+.. req::
+    :id: R-87004
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    OS::Cinder::Volume Resource ID **SHOULD** use the naming convention
 
-   * {vm-type} is the vm-type
-   * {index} starts at zero and increments by one
+       * {vm-type}_volume_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {index} starts at zero and increments by one
 
 OS::Cinder::VolumeAttachment
 ____________________________
 
-R-86497 A VNF's Heat Orchestration Template's Resource
-OS::Cinder::VolumeAttachment Resource ID **SHOULD** use the naming convention
 
-   * {vm-type}\_volume\_attachment_{index}
+.. req::
+    :id: R-86497
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    OS::Cinder::VolumeAttachment Resource ID **SHOULD** use the naming convention
+
+       * {vm-type}_volume_attachment_{index}
 
-   * {vm-type} is the vm-type
-   * {index} starts at zero and increments by one
+    where
+
+       * {vm-type} is the vm-type
+       * {index} starts at zero and increments by one
 
 OS::Heat::CloudConfig
 _____________________
 
-R-04747 A VNF's Heat Orchestration Template's Resource
-'OS::Heat::CloudConfig' Resource ID **MUST** contain the '{vm-type}'.
 
-R-20319 A VNF's Heat Orchestration Template's Resource 'OS::Heat::CloudConfig'
-Resource ID **MAY** use the naming convention
+.. req::
+    :id: R-04747
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type}\_RCC
+    A VNF's Heat Orchestration Template's Resource
+    'OS::Heat::CloudConfig' Resource ID **MUST** contain the '{vm-type}'.
 
-where
+.. req::
+    :id: R-20319
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource 'OS::Heat::CloudConfig'
+    Resource ID **MAY** use the naming convention
+
+       * {vm-type}_RCC
 
-   * {vm-type} is the vm-type
-   * 'RCC' signifies that it is the Resource Cloud Config
+    where
+
+       * {vm-type} is the vm-type
+       * 'RCC' signifies that it is the Resource Cloud Config
 
 OS::Heat::MultipartMime
 _______________________
 
-R-30804 A VNF's Heat Orchestration Template's Resource
-'OS::Heat::MultipartMime' Resource ID **MUST** contain the '{vm-type}'.
 
-R-18202 A VNF's Heat Orchestration Template's Resource
-'OS::Heat::MultipartMime' Resource ID **MAY** use the naming convention
+.. req::
+    :id: R-30804
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type}\_RMM
+    A VNF's Heat Orchestration Template's Resource
+    'OS::Heat::MultipartMime' Resource ID **MUST** contain the '{vm-type}'.
 
-where
+.. req::
+    :id: R-18202
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::Heat::MultipartMime' Resource ID **MAY** use the naming convention
+
+       * {vm-type}_RMM
 
-   * {vm-type} is the vm-type
-   * 'RMM' signifies that it is the Resource Multipart Mime
+    where
+
+       * {vm-type} is the vm-type
+       * 'RMM' signifies that it is the Resource Multipart Mime
 
 OS::Heat::ResourceGroup
 _______________________
@@ -1249,45 +1989,79 @@ _______________________
 There is only a mandatory naming convention for a 'OS::Heat::ResourceGroup'
 that is is creating sub-interfaces.
 
-R-64197 A VNF's Heat Orchestration Template's Resource
-OS::Heat::ResourceGroup Resource ID that creates sub-interfaces **MUST**
-use the naming convention
 
-   * {vm-type}\_{vm-type_index}\_subint_{network-role}\_port_\
-     {port-index}\_subinterfaces
+.. req::
+    :id: R-64197
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    OS::Heat::ResourceGroup Resource ID that creates sub-interfaces **MUST**
+    use the naming convention
+
+       * {vm-type}_{vm-type_index}_subint_{network-role}_port_{port-index}_subinterfaces
+
+    where
 
-   * {vm-type} is the vm-type
-   * {vm-type_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the networks
-     that the sub-interfaces attach to
-   * {port-index} is the instance of the the port on the vm-type
-     attached to the network of {network-role}
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the networks
+         that the sub-interfaces attach to
+       * {port-index} is the instance of the the port on the vm-type
+         attached to the network of {network-role}
 
 OS::Heat::SoftwareConfig
 ________________________
 
-R-08975 A VNF's Heat Orchestration Template's Resource
-'OS::Heat::SoftwareConfig' Resource ID **MUST** contain the '{vm-type}'.
 
-R-03656 A VNF's Heat Orchestration Template's Resource
-'OS::Heat::SoftwareConfig' Resource ID **MAY** use the naming convention
+.. req::
+    :id: R-08975
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type}\_RSC
+    A VNF's Heat Orchestration Template's Resource
+    'OS::Heat::SoftwareConfig' Resource ID **MUST** contain the '{vm-type}'.
 
-where
+.. req::
+    :id: R-03656
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::Heat::SoftwareConfig' Resource ID **MAY** use the naming convention
+
+       * {vm-type}_RSC
+
+    where
 
-   * {vm-type} is the vm-type
-   * 'RSC' signifies that it is the Resource Software Config
+       * {vm-type} is the vm-type
+       * 'RSC' signifies that it is the Resource Software Config
 
 OS::Neutron::Net
 ________________
 
-R-25720 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::Net Resource ID **MUST** use the naming convention
 
-   * int\_{network-role}\_network
+.. req::
+    :id: R-25720
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::Net Resource ID **MUST** use the naming convention
+
+       * int_{network-role}_network
 
 VNF Heat Orchestration Templates can only create internal networks.
 There is no {index} after {network-role} because {network-role}
@@ -1297,211 +2071,332 @@ Heat Orchestration Template.
 OS::Neutron::Port
 _________________
 
-R-20453 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::Port that is attaching to an external network Resource ID
-**MUST** use the naming convention
-
-   * {vm-type}\_{vm-type_index}\_{network-role}\_port\_{port-index}
-
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {port-index} is the instance of the the port on the vm-type
-     attached to the network of {network-role}
-
-R-26351 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::Port that is attaching to an internal network Resource ID
-**MUST** use the naming convention
-
-   * {vm-type}\_{vm-type_index}\_int\_{network-role}\_port\_{port-index}
 
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {port-index} is the instance of the the port on the vm-type
-     attached to the network of {network-role}
-
-R-27469 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::Port that is creating a *Reserve Port* with an IPv4 address
-Resource ID **MUST** use the naming convention
-
-   * reserve\_port\_{vm-type}\_{network-role}\_floating\_ip\_{index}
+.. req::
+    :id: R-20453
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::Port that is attaching to an external network Resource ID
+    **MUST** use the naming convention
+
+       * {vm-type}_{vm-type_index}_{network-role}_port_{port-index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {port-index} is the instance of the the port on the vm-type
+         attached to the network of {network-role}
+
+.. req::
+    :id: R-26351
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::Port that is attaching to an internal network Resource ID
+    **MUST** use the naming convention
+
+       * {vm-type}_{vm-type_index}_int_{network-role}_port_{port-index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {port-index} is the instance of the the port on the vm-type
+         attached to the network of {network-role}
+
+.. req::
+    :id: R-27469
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::Port that is creating a *Reserve Port* with an IPv4 address
+    Resource ID **MUST** use the naming convention
+
+       * reserve_port_{vm-type}_{network-role}_floating_ip_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {index} is the instance of the IPv4 *Reserve Port*
+         for the vm-type attached to the network of {network-role}
+
+.. req::
+    :id: R-68520
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource OS::Neutron::Port
+    that is creating a *Reserve Port* with an IPv6 address Resource ID
+    **MUST** use the naming convention
+
+       * reserve_port_{vm-type}_{network-role}_floating_v6_ip_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {index} is the instance of the IPv6 *Reserve Port*
+         for the vm-type attached to the network of {network-role}
 
-where
+OS::Neutron::SecurityGroup
+__________________________
 
-   * {vm-type} is the vm-type
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {index} is the instance of the IPv4 *Reserve Port*
-     for the vm-type attached to the network of {network-role}
 
-R-68520 A VNF's Heat Orchestration Template's Resource OS::Neutron::Port
-that is creating a *Reserve Port* with an IPv6 address Resource ID
-**MUST** use the naming convention
+.. req::
+    :id: R-08775
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * reserve\_port\_{vm-type}\_{network-role}\_floating
-     \_v6\_ip\_{index}
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::SecurityGroup that is applicable to one {vm-type} and
+    more than one network (internal and/or external) Resource ID
+    **SHOULD** use the naming convention
 
-where
+       * {vm-type}_security_group
 
-   * {vm-type} is the vm-type
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {index} is the instance of the IPv6 *Reserve Port*
-     for the vm-type attached to the network of {network-role}
+    where
 
-OS::Neutron::SecurityGroup
-__________________________
+       * {vm-type} is the vm-type
 
-R-08775 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::SecurityGroup that is applicable to one {vm-type} and
-more than one network (internal and/or external) Resource ID
-**SHOULD** use the naming convention
+.. req::
+    :id: R-03595
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type}\_security\_group
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::SecurityGroup that is applicable to more than
+    one {vm-type} and one external network Resource ID **SHOULD**
+    use the naming convention
 
-where
+       * {network-role}_security_group
 
-   * {vm-type} is the vm-type
+    where
 
-R-03595 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::SecurityGroup that is applicable to more than
-one {vm-type} and one external network Resource ID **SHOULD**
-use the naming convention
+       * {network-role} is the network-role
 
-   * {network-role}\_security\_group
+.. req::
+    :id: R-73213
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::SecurityGroup that is applicable to more than
+    one {vm-type} and one internal network Resource ID **SHOULD**
+    use the naming convention
 
-   * {network-role} is the network-role
+       * int_{network-role}_security_group
 
-R-73213 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::SecurityGroup that is applicable to more than
-one {vm-type} and one internal network Resource ID **SHOULD**
-use the naming convention
+    where
 
-   * int\_{network-role}\_security\_group
+       * {network-role} is the network-role
 
-where
+.. req::
+    :id: R-17334
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {network-role} is the network-role
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::SecurityGroup that is applicable to one {vm-type}
+    and one external network Resource ID **SHOULD** use the naming convention
 
-R-17334 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::SecurityGroup that is applicable to one {vm-type}
-and one external network Resource ID **SHOULD** use the naming convention
+       * {vm-type}_{network-role}_security_group
 
-   * {vm-type}\_{network-role}\_security\_group
+    where
 
-where
+       * {vm-type} is the vm-type
+       * {network-role} is the network-role
 
-   * {vm-type} is the vm-type
-   * {network-role} is the network-role
+.. req::
+    :id: R-14198
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-R-14198 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::SecurityGroup that is applicable to one {vm-type}
-and one internal network Resource ID **SHOULD** use the naming convention
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::SecurityGroup that is applicable to one {vm-type}
+    and one internal network Resource ID **SHOULD** use the naming convention
 
-   * {vm-type}\_int\_{network-role}\_security\_group
+       * {vm-type}_int_{network-role}_security_group
 
-where
+    where
 
-   * {vm-type} is the vm-type
-   * {network-role} is the network-role
+       * {vm-type} is the vm-type
+       * {network-role} is the network-role
 
-R-30005 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::SecurityGroup that is applicable to more than one
-{vm-type} and more than one network (internal and/or external)
-Resource ID **MAY** use the naming convention
+.. req::
+    :id: R-30005
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * shared_security_group
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::SecurityGroup that is applicable to more than one
+    {vm-type} and more than one network (internal and/or external)
+    Resource ID **MAY** use the naming convention
 
-or
+       * shared_security_group
 
-   * {vnf-type}\_security\_group
+    or
 
-where
+       * {vnf-type}_security_group
 
-   * {vnf-type} describes the VNF
+    where
 
+       * {vnf-type} describes the VNF
 
 OS::Neutron::Subnet
 ___________________
 
-R-59434 A VNF's Heat Orchestration Template's Resource
-OS::Neutron::Subnet Resource ID **SHOULD** use the naming convention
 
-   * int\_{network-role}\_subnet\_{index}
+.. req::
+    :id: R-59434
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    OS::Neutron::Subnet Resource ID **SHOULD** use the naming convention
+
+       * int_{network-role}_subnet_{index}
 
-   * {network-role} is the network-role
-   * {index} is the {index} of the subnet of the network
+    where
+
+       * {network-role} is the network-role
+       * {index} is the {index} of the subnet of the network
 
 OS::Nova::Keypair
 _________________
 
-R-24997 A VNF's Heat Orchestration Template's Resource
-OS::Nova::Keypair applies to one {vm-type} Resource ID **SHOULD**
-use the naming convention
 
-   * {vm-type}\_keypair\_{index}
+.. req::
+    :id: R-24997
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    OS::Nova::Keypair applies to one {vm-type} Resource ID **SHOULD**
+    use the naming convention
 
-   * {network-role} is the network-role
-   * {index} is the {index} of the keypair
+       * {vm-type}_keypair_{index}
 
-R-65516 A VNF's Heat Orchestration Template's Resource OS::Nova::Keypair
-applies to all Virtual Machines in the the VNF, the Resource ID **SHOULD**
-use the naming convention
+    where
 
-   * {vnf-type}\_keypair
+       * {network-role} is the network-role
+       * {index} is the {index} of the keypair
 
-where
+.. req::
+    :id: R-65516
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource OS::Nova::Keypair
+    applies to all Virtual Machines in the the VNF, the Resource ID **SHOULD**
+    use the naming convention
 
-   * {vnf-type} describes the VNF
+       * {vnf-type}_keypair
 
+    where
+
+       * {vnf-type} describes the VNF
 
 OS::Nova::Server
 ________________
 
-R-29751 A VNF's Heat Orchestration Template's Resource OS::Nova::Server
-Resource ID **MUST** use the naming convention
 
-   * {vm-type}\_server\_{index}
+.. req::
+    :id: R-29751
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource OS::Nova::Server
+    Resource ID **MUST** use the naming convention
 
-   * {vm-type} is the vm-type
-   * {index} is the index
+       * {vm-type}_server_{index}
 
+    where
+
+       * {vm-type} is the vm-type
+       * {index} is the index
 
 OS::Nova::ServerGroup
 _____________________
 
-R-15189 A VNF's Heat Orchestration Template's Resource OS::Nova::ServerGroup
-Resource ID **MAY** use the naming convention
 
-   * {vm-type}\_RSG
+.. req::
+    :id: R-15189
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource OS::Nova::ServerGroup
+    Resource ID **MAY** use the naming convention
 
-or
+       * {vm-type}_RSG
 
-   * {vm-type}\_Server\_Grp
+    or
 
-or
+       * {vm-type}_Server_Grp
 
-   * {vm-type}\_ServerGroup
+    or
 
-or
+       * {vm-type}_ServerGroup
 
-   * {vm-type}\_servergroup
+    or
 
+       * {vm-type}_servergroup
 
 Contrail Heat Resources Resource ID Naming Convention
 +++++++++++++++++++++++++++++++++++++++++++++++++++++
@@ -1514,285 +2409,442 @@ in the following sections.
 OS::ContrailV2::InstanceIp
 __________________________
 
-R-53310 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InstanceIp' that is configuring an IPv4 Address
-on a port attached to an external network Resource ID **MUST**
-use the naming convention
-
-   *  {vm-type}\_{vm-type\_index}\_{network-role}\_vmi
-      \_{vmi\_index}\_IP\_{index}
-
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {vmi_index} is the instance of the the virtual machine interface
-     (e.g., port)  on the vm-type
-     attached to the network of {network-role}
-   * 'IP' signifies that an IPv4 address is being configured
-   * {index} is the index of the IPv4 address
-
-R-46128 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InstanceIp' that is configuring an
-IPv6 Address on a port attached to an external network
-Resource ID **MUST** use the naming convention
-
-   *  {vm-type}\_{vm-type\_index}\_{network-role}\_vmi
-      \_{vmi\_index}\_v6\_IP\_{index}
-
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {vmi\_index} is the instance of the the virtual machine interface
-     (e.g., port)  on the vm-type
-     attached to the network of {network-role}
-   * 'v6\_IP' signifies that an IPv6 address is being configured
-   * {index} is the index of the IPv6 address
-
-R-62187 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InstanceIp' that is configuring an
-IPv4 Address on a port attached to an internal network
-Resource ID **MUST** use the naming convention
-
-   *  {vm-type}\_{vm-type\_index}\_int\_{network-role}
-      \_vmi\_{vmi\_index}\_IP\_{index}
-
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {vmi_index} is the instance of the the virtual machine interface
-     (e.g., port)  on the vm-type
-     attached to the network of {network-role}
-   * 'IP' signifies that an IPv4 address is being configured
-   * {index} is the index of the IPv4 address
-
-R-87563 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InstanceIp' that is configuring an
-IPv6 Address on a port attached to an internal network
-Resource ID **MUST** use the naming convention
-
-   *  {vm-type}\_{vm-type\_index}\_int\_{network-role}
-      \_vmi\_{vmi\_index}\_v6\_IP\_{index}
-
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {vmi\_index} is the instance of the the virtual machine
-     interface (e.g., port)  on the vm-type
-     attached to the network of {network-role}
-   * 'v6\_IP' signifies that an IPv6 address is being configured
-   * {index} is the index of the IPv6 address
-
-R-20947 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InstanceIp' that is configuring an IPv4 Address
-on a sub-interface port attached to a sub-interface network
-Resource ID **MUST** use the naming convention
-
-   *  {vm-type}\_{vm-type\_index}\_subint\_{network-role}
-      \_vmi\_{vmi\_index}\_IP\_{index}
-
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {vmi\_index} is the instance of the the virtual machine
-     interface (e.g., port)  on the vm-type
-     attached to the network of {network-role}
-   * 'IP' signifies that an IPv4 address is being configured
-   * {index} is the index of the IPv4 address
-
-R-88540 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InstanceIp' that is configuring an IPv6 Address
-on a sub-interface port attached to a sub-interface network
-Resource ID **MUST** use the naming convention
-
-   *  {vm-type}\_{vm-type\_index}\_subint\_{network-role}
-      \_vmi\_{vmi\_index}\_v6\_IP\_{index}
 
-where
-
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port is attached to
-   * {vmi\_index} is the instance of the the virtual machine interface
-     (e.g., port)  on the vm-type
-     attached to the network of {network-role}
-   * 'v6\_IP' signifies that an IPv6 address is being configured
-   * {index} is the index of the IPv6 address
+.. req::
+    :id: R-53310
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InstanceIp' that is configuring an IPv4 Address
+    on a port attached to an external network Resource ID **MUST**
+    use the naming convention
+
+       *  {vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_IP_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {vmi_index} is the instance of the the virtual machine interface
+         (e.g., port)  on the vm-type
+         attached to the network of {network-role}
+       * 'IP' signifies that an IPv4 address is being configured
+       * {index} is the index of the IPv4 address
+
+.. req::
+    :id: R-46128
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InstanceIp' that is configuring an
+    IPv6 Address on a port attached to an external network
+    Resource ID **MUST** use the naming convention
+
+       *  {vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_v6_IP_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {vmi_index} is the instance of the the virtual machine interface
+         (e.g., port)  on the vm-type
+         attached to the network of {network-role}
+       * 'v6_IP' signifies that an IPv6 address is being configured
+       * {index} is the index of the IPv6 address
+
+.. req::
+    :id: R-62187
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InstanceIp' that is configuring an
+    IPv4 Address on a port attached to an internal network
+    Resource ID **MUST** use the naming convention
+
+       *  {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {vmi_index} is the instance of the the virtual machine interface
+         (e.g., port)  on the vm-type
+         attached to the network of {network-role}
+       * 'IP' signifies that an IPv4 address is being configured
+       * {index} is the index of the IPv4 address
+
+.. req::
+    :id: R-87563
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InstanceIp' that is configuring an
+    IPv6 Address on a port attached to an internal network
+    Resource ID **MUST** use the naming convention
+
+       *  {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_v6_IP_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {vmi_index} is the instance of the the virtual machine interface
+         (e.g., port)  on the vm-type
+         attached to the network of {network-role}
+       * 'v6_IP' signifies that an IPv6 address is being configured
+       * {index} is the index of the IPv6 address
+
+.. req::
+    :id: R-20947
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InstanceIp' that is configuring an IPv4 Address
+    on a sub-interface port attached to a sub-interface network
+    Resource ID **MUST** use the naming convention
+
+       *  {vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_IP_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {vmi_index} is the instance of the the virtual machine interface
+         (e.g., port)  on the vm-type
+         attached to the network of {network-role}
+       * 'IP' signifies that an IPv4 address is being configured
+       * {index} is the index of the IPv4 address
+
+.. req::
+    :id: R-88540
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InstanceIp' that is configuring an IPv6 Address
+    on a sub-interface port attached to a sub-interface network
+    Resource ID **MUST** use the naming convention
+
+       *  {vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_v6_IP_{index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port is attached to
+       * {vmi_index} is the instance of the the virtual machine interface
+         (e.g., port)  on the vm-type
+         attached to the network of {network-role}
+       * 'v6_IP' signifies that an IPv6 address is being configured
+       * {index} is the index of the IPv6 address
 
 OS::ContrailV2::InterfaceRouteTable
 ___________________________________
 
-R-81214 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InterfaceRouteTable' Resource ID **MUST**
-contain the '{network-role}'.
 
-R-28189 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::InterfaceRouteTable' Resource ID **MAY**
-use the naming convention
+.. req::
+    :id: R-81214
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {network-role}\_RIRT
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InterfaceRouteTable' Resource ID **MUST**
+    contain the '{network-role}'.
 
-where
+.. req::
+    :id: R-28189
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::InterfaceRouteTable' Resource ID **MAY**
+    use the naming convention
 
-   * {network-role} is the network-role
-   * 'RIRT' signifies that it is the Resource Interface Route Table
+       * {network-role}_RIRT
 
+    where
+
+       * {network-role} is the network-role
+       * 'RIRT' signifies that it is the Resource Interface Route Table
 
 OS::ContrailV2::NetworkIpam
 ___________________________
 
-R-30753 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::NetworkIpam' Resource ID **MUST**
-contain the '{network-role}'.
-
-R-81979 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::NetworkIpam' Resource ID **MAY**
-use the naming convention
 
-   * {network-role}\_RNI
+.. req::
+    :id: R-30753
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::NetworkIpam' Resource ID **MUST**
+    contain the '{network-role}'.
 
-   * {network-role} is the network-role
-   * 'RNI' signifies that it is the Resource Network IPAM
+.. req::
+    :id: R-81979
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-OS::ContrailV2::PortTuple
-_________________________
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::NetworkIpam' Resource ID **MAY**
+    use the naming convention
 
-R-20065 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::PortTuple' Resource ID **MUST**
-contain the '{vm-type}'.
+       * {network-role}_RNI
 
-R-84457 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::PortTuple' Resource ID **MAY**
-use the naming convention
+    where
 
-   * {vm-type}\_RPT
+       * {network-role} is the network-role
+       * 'RNI' signifies that it is the Resource Network IPAM
 
-where
+OS::ContrailV2::PortTuple
+_________________________
 
-   * {vm-type} is the vm-type
-   * 'RPT' signifies that it is the Resource Port Tuple
 
+.. req::
+    :id: R-20065
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-OS::ContrailV2::ServiceHealthCheck
-__________________________________
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::PortTuple' Resource ID **MUST**
+    contain the '{vm-type}'.
 
-R-76014 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::ServiceHealthCheck' Resource ID **MUST**
-contain the '{vm-type}'.
+.. req::
+    :id: R-84457
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-R-65618 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::ServiceHealthCheck' Resource ID
-**MAY** use the naming convention
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::PortTuple' Resource ID **MAY**
+    use the naming convention
 
-   * {vm-type}\_RSHC\_{LEFT|RIGHT}
+       * {vm-type}_RPT
 
-where
+    where
 
-   * {vm-type} is the vm-type
-   * 'RSHC' signifies that it is the Resource Service Health Check
-   * 'LEFT' is used if the Service Health Check is on the left interface
-   * 'RIGHT' is used if the Service Health Check is on the right interface
+       * {vm-type} is the vm-type
+       * 'RPT' signifies that it is the Resource Port Tuple
 
+OS::ContrailV2::ServiceHealthCheck
+__________________________________
 
-OS::ContrailV2::ServiceTemplate
-_______________________________
 
+.. req::
+    :id: R-76014
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-R-16437 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::ServiceTemplate' Resource ID **MUST**
-contain the '{vm-type}'.
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::ServiceHealthCheck' Resource ID **MUST**
+    contain the '{vm-type}'.
 
-R-14447 A VNF's Heat Orchestration Template's Resource
-'OS::ContrailV2::ServiceTemplate' Resource ID **MAY**
-use the naming convention
+.. req::
+    :id: R-65618
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type}\_RST\_{index}
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::ServiceHealthCheck' Resource ID
+    **MAY** use the naming convention
 
-where
+       * {vm-type}_RSHC_{LEFT|RIGHT}
 
-   * {vm-type} is the vm-type
-   * 'RST' signifies that it is the Resource Service Template
-   * '{index}' is is the index
+    where
 
-OS::ContrailV2::VirtualMachineInterface
-_______________________________________
+       * {vm-type} is the vm-type
+       * 'RSHC' signifies that it is the Resource Service Health Check
+       * 'LEFT' is used if the Service Health Check is on the left interface
+       * 'RIGHT' is used if the Service Health Check is on the right interface
 
-R-96253 A VNF's Heat Orchestration Template's Resource
-OS::ContrailV2::VirtualMachineInterface that is attaching
-to an external network Resource ID **MUST**
-use the naming convention
+OS::ContrailV2::ServiceTemplate
+_______________________________
 
-   * {vm-type}\_{vm-type\_index}\_{network-role}
-     \_vmi\_{vmi\_index}
 
-where
+.. req::
+    :id: R-16437
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port (i.e. virtual machine interface) is attached to
-   * {vmi\_index} is the instance of the the vmi on the vm-type
-     attached to the network of {network-role}
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::ServiceTemplate' Resource ID **MUST**
+    contain the '{vm-type}'.
 
-R-50468 A VNF's Heat Orchestration Template's Resource
-OS::ContrailV2::VirtualMachineInterface that is attaching
-to an internal network Resource ID **MUST** use the naming convention
+.. req::
+    :id: R-14447
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-   * {vm-type}\_{vm-type\_index}\_int\_{network-role}\_vmi\_{vmi\_index}
+    A VNF's Heat Orchestration Template's Resource
+    'OS::ContrailV2::ServiceTemplate' Resource ID **MAY**
+    use the naming convention
 
-where
+       * {vm-type}_RST_{index}
 
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port (i.e. virtual machine interface) is attached to
-   * {vmi\_index} is the instance of the the vmi on the vm-type
-     attached to the network of {network-role}
+    where
 
-R-54458 A VNF's Heat Orchestration Template's Resource
-OS::ContrailV2::VirtualMachineInterface that is attaching to
-a sub-interface network Resource ID **MUST** use the naming convention
+       * {vm-type} is the vm-type
+       * 'RST' signifies that it is the Resource Service Template
+       * '{index}' is is the index
 
-   * {vm-type}\_{vm-type\_index}\_subint\_{network-role}\_vmi\_{vmi\_index}
+OS::ContrailV2::VirtualMachineInterface
+_______________________________________
 
-where
 
-   * {vm-type} is the vm-type
-   * {vm-type\_index} is the instance of the {vm-type}
-   * {network-role} is the network-role of the network
-     that the port (i.e. virtual machine interface) is attached to
-   * {vmi\_index} is the instance of the the vmi on the vm-type
-     attached to the network of {network-role}
+.. req::
+    :id: R-96253
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::ContrailV2::VirtualMachineInterface that is attaching
+    to an external network Resource ID **MUST**
+    use the naming convention
+
+       * {vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port (i.e. virtual machine interface) is attached to
+       * {vmi_index} is the instance of the the vmi on the vm-type
+         attached to the network of {network-role}
+
+.. req::
+    :id: R-50468
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::ContrailV2::VirtualMachineInterface that is attaching
+    to an internal network Resource ID **MUST** use the naming convention
+
+       * {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port (i.e. virtual machine interface) is attached to
+       * {vmi_index} is the instance of the the vmi on the vm-type
+         attached to the network of {network-role}
+
+.. req::
+    :id: R-54458
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::ContrailV2::VirtualMachineInterface that is attaching to
+    a sub-interface network Resource ID **MUST** use the naming convention
+
+       * {vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}
+
+    where
+
+       * {vm-type} is the vm-type
+       * {vm-type_index} is the instance of the {vm-type}
+       * {network-role} is the network-role of the network
+         that the port (i.e. virtual machine interface) is attached to
+       * {vmi_index} is the instance of the the vmi on the vm-type
+         attached to the network of {network-role}
 
 OS::ContrailV2::VirtualNetwork
 ______________________________
 
-R-99110 A VNF's Heat Orchestration Template's Resource
-OS::ContrailV2::VirtualNetwork Resource ID **MUST**
-use the naming convention
 
-   * 'int\_{network-role}\_network'
+.. req::
+    :id: R-99110
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Resource
+    OS::ContrailV2::VirtualNetwork Resource ID **MUST**
+    use the naming convention
 
-or
+       * 'int_{network-role}_network'
 
-   * 'int\_{network-role}\_RVN' where RVN represents Resource Virtual Network
+    or
+
+       * 'int_{network-role}_RVN' where RVN represents Resource Virtual Network
 
 VNF Heat Orchestration Templates can only create internal networks.
 There is no {index} after {network-role} because {network-role}
@@ -1840,22 +2892,43 @@ the detailed requirements.
 Property: image
 +++++++++++++++
 
-R-71152 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'image' parameter **MUST** be declared as
-type: 'string'.
 
-R-58670 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'image' parameter name **MUST** follow the
-naming convention '{vm-type}\_image\_name'.
+.. req::
+    :id: R-71152
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'image' parameter **MUST** be declared as
+    type: 'string'.
+
+.. req::
+    :id: R-58670
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'image' parameter name **MUST** follow the
+    naming convention '{vm-type}_image_name'.
+
+.. req::
+    :id: R-91125
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'image' parameter **MUST** be enumerated in
+    the Heat Orchestration Template's Environment File and a value **MUST** be
+    assigned.
 
-R-91125 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'image' parameter **MUST** be enumerated in
-the Heat Orchestration Template's Environment File and a value **MUST** be
-assigned.
+.. req::
+    :id: R-57282
+    :target: VNF
+    :keyword: MUST
 
-R-57282 Each VNF's Heat Orchestration Template's '{vm-type}'
-**MUST** have a unique parameter name for the 'OS::Nova::Server'
-property 'image' even if more than one {vm-type} shares the same image.
+    Each VNF's Heat Orchestration Template's '{vm-type}'
+    **MUST** have a unique parameter name for the 'OS::Nova::Server'
+    property 'image' even if more than one {vm-type} shares the same image.
 
 *Example Parameter Definition*
 
@@ -1869,22 +2942,43 @@ property 'image' even if more than one {vm-type} shares the same image.
 Property: flavor
 ++++++++++++++++
 
-R-50436 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'flavor' parameter **MUST** be declared as
-type: 'string'.
 
-R-45188 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'flavor' parameter name **MUST** follow the
-naming convention '{vm-type}\_flavor\_name'.
+.. req::
+    :id: R-50436
+    :target: VNF
+    :keyword: MUST
 
-R-69431 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'flavor' parameter **MUST** be enumerated in the
-Heat Orchestration Template's Environment File and a value **MUST** be
-assigned.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'flavor' parameter **MUST** be declared as
+    type: 'string'.
 
-R-40499 Each VNF's Heat Orchestration Template's '{vm-type}' **MUST**
-have a unique parameter name for the 'OS::Nova::Server' property
-'flavor' even if more than one {vm-type} shares the same flavor.
+.. req::
+    :id: R-45188
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'flavor' parameter name **MUST** follow the
+    naming convention '{vm-type}_flavor_name'.
+
+.. req::
+    :id: R-69431
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'flavor' parameter **MUST** be enumerated in the
+    Heat Orchestration Template's Environment File and a value **MUST** be
+    assigned.
+
+.. req::
+    :id: R-40499
+    :target: VNF
+    :keyword: MUST
+
+    Each VNF's Heat Orchestration Template's '{vm-type}' **MUST**
+    have a unique parameter name for the 'OS::Nova::Server' property
+    'flavor' even if more than one {vm-type} shares the same flavor.
 
 *Example Parameter Definition*
 
@@ -1898,34 +2992,65 @@ have a unique parameter name for the 'OS::Nova::Server' property
 Property: Name
 ++++++++++++++
 
-R-51430 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter **MUST** be declared as
-either type 'string' or type 'comma\_delimited\_list".
-
-R-54171 When the VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter is defined as a 'string',
-the parameter name **MUST** follow the naming convention
-'{vm-type}\_name\_{index}', where {index} is a numeric value that starts
-at zero and increments by one.
-
-R-40899 When the VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter is defined as a 'string',
-a parameter **MUST** be declared for each 'OS::Nova::Server' resource
-associated with the '{vm-type}'.
-
-R-87817 When the VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter is defined as a
-'comma\_delimited\_list', the parameter name **MUST** follow the naming
-convention '{vm-type}\_names'.
 
-R-85800 When the VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter is defined as a
-'comma\_delimited\_list', a parameter **MUST** be delcared once for all
-'OS::Nova::Server' resources associated with the '{vm-type}'.
-
-R-22838 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter **MUST NOT** be enumerated
-in the Heat Orchestration Template's Environment File.
+.. req::
+    :id: R-51430
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter **MUST** be declared as
+    either type 'string' or type 'comma\_delimited\_list".
+
+.. req::
+    :id: R-54171
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter is defined as a 'string',
+    the parameter name **MUST** follow the naming convention
+    '{vm-type}\_name\_{index}', where {index} is a numeric value that starts
+    at zero and increments by one.
+
+.. req::
+    :id: R-40899
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter is defined as a 'string',
+    a parameter **MUST** be declared for each 'OS::Nova::Server' resource
+    associated with the '{vm-type}'.
+
+.. req::
+    :id: R-87817
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter is defined as a
+    'comma_delimited_list', the parameter name **MUST** follow the naming
+    convention '{vm-type}_names'.
+
+.. req::
+    :id: R-85800
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter is defined as a
+    'comma_delimited_list', a parameter **MUST** be delcared once for all
+    'OS::Nova::Server' resources associated with the '{vm-type}'.
+
+.. req::
+    :id: R-22838
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter **MUST NOT** be enumerated
+    in the Heat Orchestration Template's Environment File.
 
 If a VNF's Heat Orchestration Template's contains more than three
 OS::Nova::Server resources of a given {vm-type}, the comma\_delimited\_list
@@ -2005,10 +3130,16 @@ In this example, the {vm-type} has been defined as "lb" for load balancer.
 Contrail Issue with Values for OS::Nova::Server Property Name
 _____________________________________________________________
 
-R-44271 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
-contain special characters since the Contrail GUI has a limitation
-displaying special characters.
+
+.. req::
+    :id: R-44271
+    :target: VNF
+    :keyword: SHOULD NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
+    contain special characters since the Contrail GUI has a limitation
+    displaying special characters.
 
 However, if special characters must be used, the only special characters
 supported are:
@@ -2019,21 +3150,38 @@ supported are:
 Property: availability\_zone
 ++++++++++++++++++++++++++++
 
-R-98450 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'availability\_zone' parameter name
-**MUST** follow the naming convention 'availability\_zone\_{index}'
-where the '{index}' **MUST** start at zero and increment by one.
 
-R-23311 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'availability\_zone' parameter **MUST**
-be declared as type: 'string'.
+.. req::
+    :id: R-98450
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'availability\_zone' parameter name
+    **MUST** follow the naming convention 'availability\_zone\_{index}'
+    where the '{index}' **MUST** start at zero and increment by one.
+
+.. req::
+    :id: R-23311
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'availability_zone' parameter **MUST**
+    be declared as type: 'string'.
 
 The parameter must not be declared as type 'comma\_delimited\_list',
 ONAP does not support it.
 
-R-59568  The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'availability_zone' parameter **MUST NOT**
-be enumerated in the Heat Orchestration Template's Environment File.
+
+.. req::
+    :id: R-59568
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Nova::Server' property 'availability_zone' parameter **MUST NOT**
+    be enumerated in the Heat Orchestration Template's Environment File.
 
 Example Parameter Definition
 
@@ -2048,10 +3196,16 @@ Requirement R-90279 states that a VNF Heat Orchestration's template's
 parameter MUST be used in a resource with the exception of the parameters
 for the OS::Nova::Server resource property availability_zone.
 
-R-01359 A VNF's Heat Orchstration Template that contains an
-'OS::Nova:Server' Resource **MAY** define a parameter for the property
-'availability_zone' that is not utilized in any 'OS::Nova::Server'
-resources in the Heat Orchestration Template.
+
+.. req::
+    :id: R-01359
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchstration Template that contains an
+    'OS::Nova:Server' Resource **MAY** define a parameter for the property
+    'availability_zone' that is not utilized in any 'OS::Nova::Server'
+    resources in the Heat Orchestration Template.
 
 Example
 +++++++
@@ -2150,21 +3304,38 @@ comma_delimited_list for dns and a string for oam.
 Boot Options
 ++++++++++++
 
-R-99798 A VNF's Heat Orchestration Template's Virtual Machine
-(i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
-boot from a Cinder Volume.
 
-R-83706 When a VNF's Heat Orchestration Template's Virtual Machine
-(i.e., 'OS::Nova::Server' Resource) boots from an image, the
-'OS::Nova::Server' resource property 'image' **MUST** be used.
+.. req::
+    :id: R-99798
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's Virtual Machine
+    (i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
+    boot from a Cinder Volume.
+
+.. req::
+    :id: R-83706
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF's Heat Orchestration Template's Virtual Machine
+    (i.e., 'OS::Nova::Server' Resource) boots from an image, the
+    'OS::Nova::Server' resource property 'image' **MUST** be used.
 
 The requirements associated with
 the 'image' property are detailed in `Property: image`_
 
-R-69588 When a VNF's Heat Orchestration Template's Virtual Machine
-(i.e., 'OS::Nova::Server' Resource) boots from Cinder Volume, the
-'OS::Nova::Server' resource property 'block_device_mapping' or
-'block_device_mapping_v2' **MUST** be used.
+
+.. req::
+    :id: R-69588
+    :target: VNF
+    :keyword: MUST
+
+    When a VNF's Heat Orchestration Template's Virtual Machine
+    (i.e., 'OS::Nova::Server' Resource) boots from Cinder Volume, the
+    'OS::Nova::Server' resource property 'block_device_mapping' or
+    'block_device_mapping_v2' **MUST** be used.
 
 There are currently no heat guidelines
 associated with these two properties:
@@ -2203,25 +3374,50 @@ is an ONAP generated UUID that identifies the VNF.  The value
 is provided by ONAP to the VNF's Heat Orchestration
 Template at orchestration time.
 
-R-37437 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **MUST** contain the metadata map value parameter 'vnf_id'.
 
-R-07507 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf_id' **MUST** be declared
-as type: 'string'.
+.. req::
+    :id: R-37437
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **MUST** contain the metadata map value parameter 'vnf_id'.
 
-R-55218 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf_id' **MUST NOT** have
-parameter contraints defined.
+.. req::
+    :id: R-07507
+    :target: VNF
+    :keyword: MUST
 
-R-20856 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf_id' **MUST NOT** be
-enumerated in the Heat Orchestration Template's environment file.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf_id' **MUST** be declared
+    as type: 'string'.
 
-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.
+.. req::
+    :id: R-55218
+    :target: VNF
+    :keyword: MUST NOT
 
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf_id' **MUST NOT** have
+    parameter contraints defined.
+
+.. req::
+    :id: R-20856
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf_id' **MUST NOT** be
+    enumerated in the Heat Orchestration Template's environment file.
+
+.. req::
+    :id: R-44491
+    :target: VNF
+    :keyword: MUST NOT
+
+    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.
 
 *Example 'vnf_id' Parameter Definition*
 
@@ -2242,26 +3438,52 @@ Orchestration Template).  The value
 is provided by ONAP to the VNF's Heat Orchestration
 Template at orchestration time.
 
-R-71493 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **MUST** contain the metadata map value parameter
-'vf\_module\_id'.
 
-R-82134 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_id' **MUST**
-be declared as type: 'string'.
+.. req::
+    :id: R-71493
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **MUST** contain the metadata map value parameter
+    'vf\_module\_id'.
+
+.. req::
+    :id: R-82134
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_id' **MUST**
+    be declared as type: 'string'.
+
+.. req::
+    :id: R-98374
+    :target: VNF
+    :keyword: MUST NOT
 
-R-98374 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_id' **MUST NOT**
-have parameter contraints defined.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_id' **MUST NOT**
+    have parameter contraints defined.
 
-R-72871 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_id' **MUST NOT**
-be enumerated in the Heat Orchestration Template's environment file.
+.. req::
+    :id: R-72871
+    :target: VNF
+    :keyword: MUST NOT
 
-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.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_id' **MUST NOT**
+    be enumerated in the Heat Orchestration Template's environment file.
+
+.. req::
+    :id: R-86237
+    :target: VNF
+    :keyword: MUST NOT
+
+    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.
 
 *Example 'vf\_module\_id' Parameter Definition*
 
@@ -2284,25 +3506,51 @@ is provided by ONAP to the VNF's Heat Orchestration
 Template at orchestration time.
 The parameter must be declared as type: string
 
-R-72483 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **MUST** contain the metadata map value parameter
-'vnf\_name'.
 
-R-62428 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf_name' **MUST** be
-declared as type: 'string'.
+.. req::
+    :id: R-72483
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **MUST** contain the metadata map value parameter
+    'vnf_name'.
+
+.. req::
+    :id: R-62428
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf_name' **MUST** be
+    declared as type: 'string'.
+
+.. req::
+    :id: R-44318
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf\_name' **MUST NOT** have
+    parameter contraints defined.
+
+.. req::
+    :id: R-36542
+    :target: VNF
+    :keyword: MUST NOT
 
-R-44318 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf\_name' **MUST NOT** have
-parameter contraints defined.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf\_name' **MUST NOT** be
+    enumerated in the Heat Orchestration Template's environment file.
 
-R-36542 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf\_name' **MUST NOT** be
-enumerated in the Heat Orchestration Template's environment file.
+.. req::
+    :id: R-16576
+    :target: VNF
+    :keyword: MUST NOT
 
-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.
+    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.
 
 *Example 'vnf\_name' Parameter Definition*
 
@@ -2325,27 +3573,53 @@ in the command 'Heat stack-create'
 The 'vf_module_name' (e.g., <STACK_NAME> is specified as
 part of the orchestration process.
 
-R-68023 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **SHOULD** contain the metadata map value parameter
-'vf\_module\_name'.
 
-R-39067 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_name' **MUST**
-be declared as type: 'string'.
+.. req::
+    :id: R-68023
+    :target: VNF
+    :keyword: SHOULD
 
-R-15480 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_name'
-**MUST NOT** have parameter contraints defined.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **SHOULD** contain the metadata map value parameter
+    'vf\_module\_name'.
 
-R-80374 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_name'
-**MUST NOT** be enumerated in the Heat Orchestration Template's
-environment file.
+.. req::
+    :id: R-39067
+    :target: VNF
+    :keyword: MUST
 
-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.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_name' **MUST**
+    be declared as type: 'string'.
+
+.. req::
+    :id: R-15480
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_name'
+    **MUST NOT** have parameter contraints defined.
+
+.. req::
+    :id: R-80374
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_name'
+    **MUST NOT** be enumerated in the Heat Orchestration Template's
+    environment file.
+
+.. req::
+    :id: R-49177
+    :target: VNF
+    :keyword: MUST
+
+    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.
 
 *Example 'vf_module_name' Parameter Definition*
 
@@ -2365,37 +3639,69 @@ is a metadata tag that describes the role of the Virtual Machine.
 The 'vm\_role' is stored in ONAP's A&AI module and is
 available for use by other ONAP components and/or north bound systems.
 
-R-85328 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **MAY** contain the metadata map value parameter 'vm\_role'.
 
-R-95430 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vm\_role' **MUST** be
-declared as type: 'string'.
+.. req::
+    :id: R-85328
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **MAY** contain the metadata map value parameter 'vm_role'.
+
+.. req::
+    :id: R-95430
+    :target: VNF
+    :keyword: MUST
 
-R-67597 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vm\_role' **MUST NOT** have
-parameter contraints defined.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vm_role' **MUST** be
+    declared as type: 'string'.
 
-R-46823 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vnf\_name' **MUST** be
-either
+.. req::
+    :id: R-67597
+    :target: VNF
+    :keyword: MUST NOT
 
- - enumerated in the VNF's Heat Orchestration
-   Template's environment file.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vm_role' **MUST NOT** have
+    parameter contraints defined.
 
- - hard coded in the VNF's Heat Orchestration
-   Template's OS::Nova::Resource metadata property.
+
+.. req::
+    :id: R-46823
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vnf_name' **MUST** be
+    either
+
+     - enumerated in the VNF's Heat Orchestration
+       Template's environment file.
+
+     - hard coded in the VNF's Heat Orchestration
+       Template's OS::Nova::Resource metadata property.
 
 Defining the 'vm_role' as the '{vm-type}' is a recommended convention
 
-R-86476 If a VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vm\_role' value **MUST only**
-contain alphanumeric characters and underscores '_'.
 
-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.
+.. req::
+    :id: R-86476
+    :target: VNF
+    :keyword: MUST
 
+    If a VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vm_role' value **MUST** only
+    contain alphanumeric characters and underscores '_'.
+
+.. req::
+    :id: R-70757
+    :target: VNF
+    :keyword: MUST NOT
+
+    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.
 
 *Example 'vm\_role' Parameter Definition*
 
@@ -2480,30 +3786,61 @@ for load balancer.
 vf\_module\_index
 +++++++++++++++++
 
-R-50816 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **MAY** contain the metadata map value parameter
-'vf\_module\_index'.
 
-R-54340 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_index' **MUST** be
-declared as type: 'number'.
+.. req::
+    :id: R-50816
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **MAY** contain the metadata map value parameter
+    'vf\_module\_index'.
+
+.. req::
+    :id: R-54340
+    :target: VNF
+    :keyword: MUST
 
-R-09811 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_index' **MUST NOT**
-have parameter contraints defined.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_index' **MUST** be
+    declared as type: 'number'.
 
-R-37039 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_index' **MUST NOT**
-be enumerated in the Heat Orchestration Template's environment file.
+.. req::
+    :id: R-09811
+    :target: VNF
+    :keyword: MUST NOT
 
-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.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_index' **MUST NOT**
+    have parameter contraints defined.
 
-R-55306 If a VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'vf\_module\_index' **MUST NOT** be
-used in a VNF's Volume Template; it is not supported.
+.. req::
+    :id: R-37039
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_index' **MUST NOT**
+    be enumerated in the Heat Orchestration Template's environment file.
+
+.. req::
+    :id: R-22441
+    :target: VNF
+    :keyword: MUST NOT
+
+    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.
+
+.. req::
+    :id: R-55306
+    :target: VNF
+    :keyword: MUST NOT
+
+    If a VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'vf\_module\_index' **MUST NOT** be
+    used in a VNF's Volume Template; it is not supported.
 
 The vf\_module_index parameter indicates which instance of the module is being
 deployed into the VNF.
@@ -2575,26 +3912,52 @@ YAML File
 workload\_context
 ++++++++++++++++++
 
-R-47061 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **SHOULD** contain the metadata map value parameter
-'workload\_context'.
 
-R-74978 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'workload\_context' **MUST** be
-declared as type: 'string'.
+.. req::
+    :id: R-47061
+    :target: VNF
+    :keyword: SHOULD
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **SHOULD** contain the metadata map value parameter
+    'workload_context'.
+
+.. req::
+    :id: R-74978
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'workload_context' **MUST** be
+    declared as type: 'string'.
 
-R-34055 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'workload\_context' **MUST NOT**
-have parameter contraints defined.
+.. req::
+    :id: R-34055
+    :target: VNF
+    :keyword: MUST NOT
 
-R-02691 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'workload\_context' **MUST NOT**
-be enumerated in the Heat Orchestration Template's environment file.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'workload_context' **MUST NOT**
+    have parameter contraints defined.
 
-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.
+.. req::
+    :id: R-02691
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'workload_context' **MUST NOT**
+    be enumerated in the Heat Orchestration Template's environment file.
+
+.. req::
+    :id: R-75202
+    :target: VNF
+    :keyword: MUST NOT
+
+    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.
 
 The 'workload\_context' parameter value will be chosen by the Service Model
 Distribution context client in VID and will be supplied to the
@@ -2634,26 +3997,52 @@ Heat Orchestration Template by ONAP at orchestration time.
 environment\_context
 ++++++++++++++++++++++
 
-R-88536 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource **SHOULD** contain the metadata map value parameter
-'environment\_context'.
 
-R-20308 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'environment\_context' **MUST**
-be declared as type: 'string'.
+.. req::
+    :id: R-88536
+    :target: VNF
+    :keyword: SHOULD
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource **SHOULD** contain the metadata map value parameter
+    'environment_context'.
+
+.. req::
+    :id: R-20308
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'environment_context' **MUST**
+    be declared as type: 'string'.
+
+.. req::
+    :id: R-56183
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'environment_context' **MUST NOT**
+    have parameter contraints defined.
 
-R-56183 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'environment\_context' **MUST NOT**
-have parameter contraints defined.
+.. req::
+    :id: R-13194
+    :target: VNF
+    :keyword: MUST NOT
 
-R-13194 A VNF's Heat Orchestration Template's OS::Nova::Server
-Resource metadata map value parameter 'environment\_context' **MUST NOT**
-be enumerated in the Heat Orchestration Template's environment file.
+    A VNF's Heat Orchestration Template's OS::Nova::Server
+    Resource metadata map value parameter 'environment_context' **MUST NOT**
+    be enumerated in the Heat Orchestration Template's environment file.
 
-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.
+.. req::
+    :id: R-62954
+    :target: VNF
+    :keyword: MUST NOT
+
+    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.
 
 The 'environment\_context' parameter value will be defined by the
 service designer as part of the service model during the SDC
@@ -2750,58 +4139,119 @@ This will be described in the forth coming sections.
 Items to Note
 _____________
 
-R-93272 A VNF **MAY** have one or more ports connected to a unique
-external network.  All VNF ports connected
-to the unique external network **MUST** have Cloud Assigned IP Addresses
-or **MUST** have ONAP SDN-C assigned IP addresses.
-
-R-13841 A VNF **MAY** have one or more ports connected to a unique
-internal network.  All VNF ports connected
-to the unique internal network **MUST** have Cloud Assigned IP Addresses
-or **MUST** have statically assigned IP addresses.
-
-R-07577 If the VNF's ports connected to a unique network (internal or external)
-and the port's IP addresses are Cloud Assigned IP Addresses,
-all the IPv4 Addresses **MUST** be from
-the same subnet and all the IPv6 Addresses **MUST** be from the
-same subnet.
-
-R-45602 If a VNF's Port is attached to a network (internal or external)
-and the port's IP addresses are Cloud Assigned by OpenStack's DHCP
-Service, the 'OS::Neutron::Port' Resource's
-
-   * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
-   * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
-
-R-63956 If the VNF's ports connected to a unique external network
-and the port's IP addresses are ONAP SDN-C assigned IP Addresses,
-the IPv4 Addresses **MAY** be from
-different subnets and the IPv6 Addresses **MAY** be from different
-subnets.
-
-R-48880 If a VNF's Port is attached to an external network and the port's
-IP addresses are assigned by ONAP's SDN-Controller,
-the 'OS::Neutron::Port' Resource's
-
-   * property 'fixed_ips' map property 'ip_address' **MUST** be used
-   * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT**
-     be used
-
-R-18001 If the VNF's ports connected to a unique internal network
-and the port's IP addresses are statically assigned IP Addresses,
-the IPv4 Addresses **MAY** be from
-different subnets and the IPv6 Addresses **MAY** be from different
-subnets.
-
-R-70964 If a VNF's Port is attached to an internal network and the port's
-IP addresses are statically assigned by the VNF's Heat Orchestration\
-Template (i.e., enumerated in the Heat Orchestration Template's
-environment file), the 'OS::Neutron::Port' Resource's
-
-   * property 'fixed_ips' map property 'ip_address' **MUST** be used
-   * property 'fixed_ips' map property 'subnet'/'subnet_id'
-     **MUST NOT** be used
 
+.. req::
+    :id: R-93272
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF **MAY** have one or more ports connected to a unique
+    external network. All VNF ports connected to the unique external
+    network **MUST** have Cloud Assigned IP Addresses
+    or **MUST** have ONAP SDN-C assigned IP addresses.
+
+.. req::
+    :id: R-13841
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF **MAY** have one or more ports connected to a unique
+    internal network. All VNF ports connected to the unique internal
+    network **MUST** have Cloud Assigned IP Addresses
+    or **MUST** have statically assigned IP addresses.
+
+.. req::
+    :id: R-07577
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If the VNF's ports connected to a unique network (internal or external)
+    and the port's IP addresses are Cloud Assigned IP Addresses,
+    all the IPv4 Addresses **MUST** be from
+    the same subnet and all the IPv6 Addresses **MUST** be from the
+    same subnet.
+
+.. req::
+    :id: R-45602
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Port is attached to a network (internal or external)
+    and the port's IP addresses are Cloud Assigned by OpenStack's DHCP
+    Service, the 'OS::Neutron::Port' Resource's
+
+       * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+       * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
+
+.. req::
+    :id: R-63956
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If the VNF's ports connected to a unique external network
+    and the port's IP addresses are ONAP SDN-C assigned IP Addresses,
+    the IPv4 Addresses **MAY** be from different subnets and the IPv6
+    Addresses **MAY** be from different subnets.
+
+.. req::
+    :id: R-48880
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Port is attached to an external network and the port's
+    IP addresses are assigned by ONAP's SDN-Controller,
+    the 'OS::Neutron::Port' Resource's
+
+       * property 'fixed_ips' map property 'ip_address' **MUST** be used
+       * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used
+
+.. req::
+    :id: R-18001
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If the VNF's ports connected to a unique internal network
+    and the port's IP addresses are statically assigned IP Addresses,
+    the IPv4 Addresses **MAY** be from different subnets and the
+    IPv6 Addresses **MAY** be from different subnets.
+
+.. req::
+    :id: R-70964
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Port is attached to an internal network and the port's
+    IP addresses are statically assigned by the VNF's Heat Orchestration\
+    Template (i.e., enumerated in the Heat Orchestration Template's
+    environment file), the 'OS::Neutron::Port' Resource's
+
+       * property 'fixed_ips' map property 'ip_address' **MUST** be used
+       * property 'fixed_ips' map property 'subnet'/'subnet_id'
+         **MUST NOT** be used
 
 Property: network
 +++++++++++++++++
@@ -2810,34 +4260,46 @@ The Resource 'OS::Neutron::Port' property 'network' determines what network
 the port is attached to.
 
 
-R-18008 The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
-property 'network' parameter **MUST** be declared as type: 'string'.
+.. req::
+    :id: R-18008
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
+    property 'network' parameter **MUST** be declared as type: 'string'.
 
-R-62983 When the VNF's Heat Orchestration Template's
-Resource 'OS::Neutron::Port' is attaching to an external network,
-the 'network' parameter name **MUST**
+.. req::
+    :id: R-62983
+    :target: VNF
+    :keyword: MUST
 
-- follow the naming convention '{network-role}_net_id' if the Neutron
-  network UUID value is used to reference the network
-- follow the naming convention '{network-role}_net_name' if the OpenStack
-  network name is used to reference the network.
+    When the VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
+    is attaching to an external network, the 'network' parameter name **MUST**
 
-where '{network-role}' is the network-role of the external network and
-a 'get_param' **MUST** be used as the intrinsic function.
+    - follow the naming convention '{network-role}_net_id' if the Neutron
+      network UUID value is used to reference the network
+    - follow the naming convention '{network-role}_net_name' if the OpenStack
+      network name is used to reference the network.
 
-R-86182 When the VNF's Heat Orchestration Template's
-Resource 'OS::Neutron::Port' is attaching to an internal network,
-and the internal network is created in a different
-Heat Orchestration Template than the 'OS::Neutron::Port', the 'network'
-parameter name **MUST**
+    where '{network-role}' is the network-role of the external network and
+    a 'get_param' **MUST** be used as the intrinsic function.
 
-- follow the naming convention 'int\_{network-role}_net_id' if the Neutron
-  network UUID value is used to reference the network
-- follow the naming convention 'int\_{network-role}_net_name' if the
-  OpenStack network name in is used to reference the network.
+.. req::
+    :id: R-86182
+    :target: VNF
+    :keyword: MUST
 
-where '{network-role}' is the network-role of the internal network
-and a 'get_param' **MUST** be used as the intrinsic function.
+    When the VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
+    is attaching to an internal network, and the internal network is created in a different
+    Heat Orchestration Template than the 'OS::Neutron::Port', the 'network'
+    parameter name **MUST**
+
+    - follow the naming convention 'int\_{network-role}_net_id' if the Neutron
+      network UUID value is used to reference the network
+    - follow the naming convention 'int\_{network-role}_net_name' if the
+      OpenStack network name in is used to reference the network.
+
+    where '{network-role}' is the network-role of the internal network and a 'get_param' **MUST** be used as the intrinsic function.
 
 In Requirement R-86182, the internal network is created in the VNF's
 Base Module (Heat Orchestration Template) and the parameter name is
@@ -2845,17 +4307,28 @@ declared in the Base Module's outputs' section.
 The output parameter name will be declared as a parameter in the
 'parameters' section of the incremental module.
 
-R-93177 When the VNF's Heat Orchestration Template's
-Resource 'OS::Neutron::Port' is attaching to an internal
-network, and the internal network is created in the same Heat
-Orchestration Template than the 'OS::Neutron::Port', the 'network'
-parameter name **MUST** obtain the UUID of the internal network
-by using the intrinsic function 'get_resource' or 'get_attr'
-and referencing the Resource ID of the internal network.
 
-R-29872 The VNF's Heat Orchestration Template's Resource 'OS::Nova::Server'
-property 'network' parameter **MUST NOT** be enumerated in the Heat
-Orchestration Template's Environment File.
+.. req::
+    :id: R-93177
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's
+    Resource 'OS::Neutron::Port' is attaching to an internal
+    network, and the internal network is created in the same Heat
+    Orchestration Template than the 'OS::Neutron::Port', the 'network'
+    parameter name **MUST** obtain the UUID of the internal network
+    by using the intrinsic function 'get_resource' or 'get_attr'
+    and referencing the Resource ID of the internal network.
+
+.. req::
+    :id: R-29872
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource 'OS::Nova::Server'
+    property 'network' parameter **MUST NOT** be enumerated in the Heat
+    Orchestration Template's Environment File.
 
 The parameter values for external networks are provided by ONAP
 to the VNF's Heat Orchestration Template at orchestration time.
@@ -2905,29 +4378,44 @@ addresses to port.
 One 'OS::Neutron::Port' resource may assign one or more
 IPv4 and/or IPv6 addresses.
 
-R-34037 The VNF's Heat Orchestration Template's resource 'OS::Neutron::Port'
-property 'fixed_ips' map property 'ip_address' parameter **MUST**
-be declared as either type 'string' or type 'comma_delimited_list'.
 
-R-40971 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an external network, and an IPv4 address is
-assigned using the property
-'fixed_ips' map property 'ip_address' and the parameter type is defined
-as a string, the parameter name **MUST** follow the naming
-convention
+.. req::
+    :id: R-34037
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's resource 'OS::Neutron::Port'
+    property 'fixed_ips' map property 'ip_address' parameter **MUST**
+    be declared as either type 'string' or type 'comma_delimited_list'.
 
-   * '{vm-type}_{network-role}\_ip\_{index}'
+.. req::
+    :id: R-40971
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an external network, and an IPv4 address is
+    assigned using the property
+    'fixed_ips' map property 'ip_address' and the parameter type is defined
+    as a string, the parameter name **MUST** follow the naming
+    convention
+    - '{vm-type}_{network-role}\_ip\_{index}'
 
 where
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the external network
-   * the value for {index} must start at zero (0) and increment by one
+    - '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+    - '{network-role}' is the {network-role} of the external network
+    - the value for {index} must start at zero (0) and increment by one
+
+.. req::
+    :id: R-39841
+    :target: VNF
+    :keyword: MUST NOT
 
-R-39841 The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
-property 'fixed_ips' map property 'ip_address' parameter
-'{vm-type}_{network-role}\_ip\_{index}' **MUST NOT** be enumerated in the
-VNF's Heat Orchestration Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
+    property 'fixed_ips' map property 'ip_address' parameter
+    '{vm-type}_{network-role}\_ip\_{index}' **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
 
 ONAP's SDN-Controller assigns the IP Address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
@@ -2942,24 +4430,34 @@ the value at orchestration to the Heat Orchestration Template.
       type: string
       description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
 
-R-04697 When the VNF's Heat Orchestration Template's
-Resource 'OS::Neutron::Port' is attaching to an external
-network, and an IPv4 address is assigned using the property
-'fixed_ips' map property 'ip_address' and the parameter type
-is defined as a comma_delimited_list, the parameter name **MUST**
-follow the naming convention
 
-   * '{vm-type}_{network-role}_ips',
+.. req::
+    :id: R-04697
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
+    is attaching to an external network, and an IPv4 address is assigned using
+    the property 'fixed_ips' map property 'ip_address' and the parameter type
+    is defined as a comma_delimited_list, the parameter name **MUST** follow the
+    naming convention
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the external network
+      * '{vm-type}_{network-role}_ips',
 
-R-98905 The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
-property 'fixed_ips' map property 'ip_address' parameter
-'{vm-type}_{network-role}_ips' **MUST NOT** be enumerated in the VNF's
-Heat Orchestration Template's Environment File.
+    where
+
+      * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+      * '{network-role}' is the {network-role} of the external network
+
+.. req::
+    :id: R-98905
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port'
+    property 'fixed_ips' map property 'ip_address' parameter
+    '{vm-type}_{network-role}_ips' **MUST NOT** be enumerated in the VNF's
+    Heat Orchestration Template's Environment File.
 
 ONAP's SDN-Controller assigns the IP Address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
@@ -2975,26 +4473,36 @@ Parameter Definition*
       type: comma_delimited_list
       description: Fixed IPv4 assignments for {vm-type} VMs on the {network-role} network
 
-R-71577 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an external network, and an IPv6 address
-is assigned using the property 'fixed_ips' map property 'ip_address' and
-the parameter type is defined as a string, the parameter name **MUST** follow
-the naming convention
 
-   * '{vm-type}_{network-role}\_v6\_ip\_{index}'
+.. req::
+    :id: R-71577
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an external network, and an IPv6 address
+    is assigned using the property 'fixed_ips' map property 'ip_address' and
+    the parameter type is defined as a string, the parameter name **MUST** follow
+    the naming convention
+
+      * '{vm-type}_{network-role}\_v6\_ip\_{index}'
+
+    where
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the external network
-   * the value for {index} must start at zero (0) and increment by one
+      * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+      * '{network-role}' is the {network-role} of the external network
+      * the value for {index} must start at zero (0) and increment by one
 
+.. req::
+    :id: R-87123
+    :target: VNF
+    :keyword: MUST NOT
 
-R-87123 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter '{vm-type}_{network-role}\_v6\_ip\_{index}'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration
-Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter '{vm-type}_{network-role}\_v6\_ip\_{index}'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration
+    Template's Environment File.
 
 ONAP's SDN-Controller assigns the IP Address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
@@ -3009,23 +4517,34 @@ the value at orchestration to the Heat Orchestration Template.
       type: string
       description: Fixed IPv6 assignment for {vm-type} VM {index} on the {network-role} network
 
-R-23503 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an external network, and an IPv6
-address is assigned using the property 'fixed_ips' map property 'ip_address'
-and the parameter type is defined as a comma_delimited_list, the parameter
-name **MUST** follow the naming convention
 
-   * '{vm-type}_{network-role}_v6_ips'
+.. req::
+    :id: R-23503
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an external network, and an IPv6
+    address is assigned using the property 'fixed_ips' map property 'ip_address'
+    and the parameter type is defined as a comma_delimited_list, the parameter
+    name **MUST** follow the naming convention
+
+      * '{vm-type}_{network-role}_v6_ips'
+
+    where
+
+      * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+      * '{network-role}' is the {network-role} of the external network
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the external network
+.. req::
+    :id: R-93030
+    :target: VNF
+    :keyword: MUST NOT
 
-R-93030 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter '{vm-type}_{network-role}_v6_ips' **MUST NOT** be enumerated in the
-VNF's Heat Orchestration Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter '{vm-type}_{network-role}_v6_ips' **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
 
 ONAP's SDN-Controller assigns the IP Address and ONAP provides
 the value at orchestration to the Heat Orchestration Template.
@@ -3041,24 +4560,35 @@ Definition*
       type: comma_delimited_list
       description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
 
-R-78380 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an internal network, and an IPv4 address
-is assigned using the property 'fixed_ips' map property 'ip_address' and
-the parameter type is defined as a string, the parameter name **MUST** follow
-the naming convention
 
-   * '{vm-type}\_int\_{network-role}\_ip\_{index}'
+.. req::
+    :id: R-78380
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an internal network, and an IPv4 address
+    is assigned using the property 'fixed_ips' map property 'ip_address' and
+    the parameter type is defined as a string, the parameter name **MUST** follow
+    the naming convention
+
+       * '{vm-type}\_int\_{network-role}\_ip\_{index}'
+
+    where
+
+       * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+       * '{network-role}' is the {network-role} of the internal network
+       * the value for {index} must start at zero (0) and increment by one
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the internal network
-   * the value for {index} must start at zero (0) and increment by one
+.. req::
+    :id: R-28795
+    :target: VNF
+    :keyword: MUST
 
-R-28795 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter '{vm-type}\_int\_{network-role}\_ip\_{index}' **MUST** be enumerated
-in the VNF's Heat Orchestration Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter '{vm-type}\_int\_{network-role}\_ip\_{index}' **MUST** be enumerated
+    in the VNF's Heat Orchestration Template's Environment File.
 
 The IP address is local to the VNF's internal network and is (re)used
 in every VNF spin up, thus the constant value is declared in the VNF's
@@ -3074,23 +4604,34 @@ Heat Orchestration Template's Environment File.
       type: string
       description: Fixed IPv4 assignment for {vm-type} VM {index} on the int_{network-role} network
 
-R-85235 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an internal network, and an IPv4
-address is assigned using the property 'fixed_ips' map property 'ip_address'
-and the parameter type is defined as a comma_delimited_list, the parameter
-name **MUST** follow the naming convention
 
-   * '{vm-type}\_int\_{network-role}_ips'
+.. req::
+    :id: R-85235
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an internal network, and an IPv4
+    address is assigned using the property 'fixed_ips' map property 'ip_address'
+    and the parameter type is defined as a comma_delimited_list, the parameter
+    name **MUST** follow the naming convention
+
+       * '{vm-type}\_int\_{network-role}_ips'
+
+    where
+
+       * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+       * '{network-role}' is the {network-role} of the internal network
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the internal network
+.. req::
+    :id: R-90206
+    :target: VNF
+    :keyword: MUST
 
-R-90206 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter '{vm-type}\_int\_{network-role}_int_ips' **MUST** be enumerated in
-the VNF's Heat Orchestration Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter '{vm-type}\_int\_{network-role}_int_ips' **MUST** be enumerated in
+    the VNF's Heat Orchestration Template's Environment File.
 
 The IP address is local to the VNF's internal network and is (re)used
 in every VNF spin up, thus the constant value is declared in the VNF's
@@ -3104,25 +4645,36 @@ Heat Orchestration Template's Environment File.
       type: comma_delimited_list
       description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
 
-R-27818 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an internal network, and an IPv6 address
-is assigned using the property 'fixed_ips' map property 'ip_address' and
-the parameter type is defined as a string, the parameter name **MUST** follow
-the naming convention
 
-   * '{vm-type}\_int\_{network-role}\_v6\_ip\_{index}'
+.. req::
+    :id: R-27818
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an internal network, and an IPv6 address
+    is assigned using the property 'fixed_ips' map property 'ip_address' and
+    the parameter type is defined as a string, the parameter name **MUST** follow
+    the naming convention
+
+       * '{vm-type}\_int\_{network-role}\_v6\_ip\_{index}'
+
+    where
+
+       * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+       * '{network-role}' is the {network-role} of the internal network
+       * the value for {index} must start at zero (0) and increment by one
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the internal network
-   * the value for {index} must start at zero (0) and increment by one
+.. req::
+    :id: R-97201
+    :target: VNF
+    :keyword: MUST
 
-R-97201 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter '{vm-type}\_int\_{network-role}\_v6\_ip\_{index}'
-**MUST** be enumerated in the VNF's Heat Orchestration
-Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter '{vm-type}\_int\_{network-role}\_v6\_ip\_{index}'
+    **MUST** be enumerated in the VNF's Heat Orchestration
+    Template's Environment File.
 
 The IP address is local to the VNF's internal network and is (re)used
 in every VNF spin up, thus the constant value is declared in the VNF's
@@ -3138,18 +4690,24 @@ Heat Orchestration Template's Environment File.
       type: string
       description: Fixed IPv6 assignment for {vm-type} VM {index} on the int_{network-role} network
 
-R-29765 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an internal network, and an IPv6
-address is assigned using the property 'fixed_ips' map property 'ip_address'
-and the parameter type is defined as a comma_delimited_list, the parameter
-name **MUST** follow the naming convention
 
-   * '{vm-type}\_int\_{network-role}_v6_ips'
+.. req::
+    :id: R-29765
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an internal network, and an IPv6
+    address is assigned using the property 'fixed_ips' map property 'ip_address'
+    and the parameter type is defined as a comma_delimited_list, the parameter
+    name **MUST** follow the naming convention
+
+       * '{vm-type}\_int\_{network-role}_v6_ips'
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the internal network
+    where
+
+       * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+       * '{network-role}' is the {network-role} of the internal network
 
 *Example Internal Network IPv6 Address comma_delimited_list Parameter
 Definition*
@@ -3162,39 +4720,55 @@ Definition*
       type: comma_delimited_list
       description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
 
-R-98569 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter '{vm-type}\_int\_{network-role}_v6_ips' **MUST** be enumerated in
-the VNF's Heat Orchestration Template's Environment File.
+
+.. req::
+    :id: R-98569
+    :target: VNF
+    :keyword: MUST
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter '{vm-type}\_int\_{network-role}_v6_ips' **MUST** be enumerated in
+    the VNF's Heat Orchestration Template's Environment File.
 
 The IP address is local to the VNF's internal network and is (re)used
 in every VNF spin up, thus the constant value is declared in the VNF's
 Heat Orchestration Template's Environment File.
 
-R-62590 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter associated with an external network, i.e.,
 
-- {vm-type}_{network-role}\_ip\_{index}
-- {vm-type}_{network-role}\_ip\_v6\_{index}
-- {vm-type}_{network-role}_ips
-- {vm-type}_{network-role}_v6_ips
+.. req::
+    :id: R-62590
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter associated with an external network, i.e.,
+
+    - {vm-type}_{network-role}\_ip\_{index}
+    - {vm-type}_{network-role}\_ip\_v6\_{index}
+    - {vm-type}_{network-role}_ips
+    - {vm-type}_{network-role}_v6_ips
+
+    **MUST NOT** be enumerated in the Heat Orchestration Template's Environment File.
+    ONAP provides the IP address assignments at orchestration time.
 
-**MUST NOT** be enumerated in the Heat Orchestration Template's
-Environment File. ONAP provides the IP address assignments at
-orchestration time.
+.. req::
+    :id: R-93496
+    :target: VNF
+    :keyword: MUST
 
-R-93496 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
-parameter associated with an internal network, i.e.,
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address'
+    parameter associated with an internal network, i.e.,
 
-- {vm-type}\_int\_{network-role}\_ip\_{index}
-- {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
-- {vm-type}\_int\_{network-role}_ips
-- {vm-type}\_int\_{network-role}_v6_ips
+    - {vm-type}\_int\_{network-role}\_ip\_{index}
+    - {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
+    - {vm-type}\_int\_{network-role}_ips
+    - {vm-type}\_int\_{network-role}_v6_ips
 
-**MUST** be enumerated in the Heat Orchestration Template's Environment
-File and IP addresses **MUST** be assigned.
+    **MUST** be enumerated in the Heat Orchestration Template's Environment
+    File and IP addresses **MUST** be assigned.
 
 Summary Table
 _____________
@@ -3399,28 +4973,44 @@ the IP address will be assigned from.
 The property fixed_ips is used to assign IPs to a port. The Map Property
 subnet_id specifies the subnet the IP is assigned from.
 
-R-38236 The VNF's Heat Orchestration Template's resource
-'OS::Neutron::Port' property 'fixed_ips' map property
-'subnet'/'subnet_id' parameter **MUST** be declared type 'string'.
 
-R-62802 When the VNF's Heat Orchestration Template's resource
-'OS::Neutron::Port' is attaching to an external network, and an IPv4
-address is being Cloud Assigned by OpenStack's DHCP Service and the
-external network IPv4 subnet is to be specified using the property
-'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST**
-follow the naming convention
+.. req::
+    :id: R-38236
+    :target: VNF
+    :keyword: MUST
 
-   * '{network-role}_subnet_id'
+    The VNF's Heat Orchestration Template's resource
+    'OS::Neutron::Port' property 'fixed_ips' map property
+    'subnet'/'subnet_id' parameter **MUST** be declared type 'string'.
 
-where
+.. req::
+    :id: R-62802
+    :target: VNF
+    :keyword: MUST
+
+    When the VNF's Heat Orchestration Template's resource
+    'OS::Neutron::Port' is attaching to an external network, and an IPv4
+    address is being Cloud Assigned by OpenStack's DHCP Service and the
+    external network IPv4 subnet is to be specified using the property
+    'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST**
+    follow the naming convention
+
+       * '{network-role}_subnet_id'
+
+    where
 
-   * '{network-role}' is the network role of the network.
+       * '{network-role}' is the network role of the network.
 
-R-83677 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property
-subnet'/'subnet_id' parameter '{network-role}_subnet_id'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
-Environment File.
+.. req::
+    :id: R-83677
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property
+    subnet'/'subnet_id' parameter '{network-role}_subnet_id'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
 
 ONAP's SDN-Controller provides the network's subnet's UUID
 value at orchestration to the Heat Orchestration Template.
@@ -3435,24 +5025,35 @@ value at orchestration to the Heat Orchestration Template.
       type: string
       description: Neutron IPv4 subnet UUID for the {network-role} network
 
-R-15287 When the VNF's Heat Orchestration Template's resource
-'OS::Neutron::Port' is attaching to an external network, and an IPv6
-address is being Cloud Assigned by OpenStack's DHCP Service and the
-external network IPv6 subnet is to be specified using the property
-'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST**
-follow the naming convention
 
-   * '{network-role}_subnet_v6_id'
+.. req::
+    :id: R-15287
+    :target: VNF
+    :keyword: MUST
 
-where
+    When the VNF's Heat Orchestration Template's resource
+    'OS::Neutron::Port' is attaching to an external network, and an IPv6
+    address is being Cloud Assigned by OpenStack's DHCP Service and the
+    external network IPv6 subnet is to be specified using the property
+    'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST**
+    follow the naming convention
+
+       * '{network-role}_subnet_v6_id'
+
+    where
 
-   * '{network-role}' is the network role of the network.
+       * '{network-role}' is the network role of the network.
 
-R-80829 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property
-subnet'/'subnet_id' parameter '{network-role}_subnet_v6_id'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
-Environment File.
+.. req::
+    :id: R-80829
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property
+    subnet'/'subnet_id' parameter '{network-role}_subnet_v6_id'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
 
 ONAP's SDN-Controller provides the network's subnet's UUID
 value at orchestration to the Heat Orchestration Template.
@@ -3522,28 +5123,39 @@ balancer.
           - subnet_id: { get_param: oam_subnet_id }
           - subnet_id: { get_param: oam_v6_subnet_id }
 
-R-84123 When
 
-- the VNF's Heat Orchestration Template's resource 'OS::Neutron::Port'
-  in an Incremental Module is attaching to an internal network
-  that is created in the Base Module, AND
-- an IPv4 address is being Cloud Assigned by OpenStack's DHCP Service AND
-- the internal network IPv4 subnet is to be specified using the
-  property 'fixed_ips' map property 'subnet'/'subnet_id',
+.. req::
+    :id: R-84123
+    :target: VNF
+    :keyword: MUST
 
-the parameter **MUST** follow the naming convention
-   * 'int\_{network-role}_subnet_id'
-where
-   * '{network-role}' is the network role of the internal network
+    When
+
+    - the VNF's Heat Orchestration Template's resource 'OS::Neutron::Port'
+      in an Incremental Module is attaching to an internal network
+      that is created in the Base Module, AND
+    - an IPv4 address is being Cloud Assigned by OpenStack's DHCP Service AND
+    - the internal network IPv4 subnet is to be specified using the
+      property 'fixed_ips' map property 'subnet'/'subnet_id',
+
+    the parameter **MUST** follow the naming convention
+       * 'int\_{network-role}_subnet_id'
+    where
+       * '{network-role}' is the network role of the internal network
 
-- Note that the parameter **MUST** be defined as an 'output' parameter in
-  the base module.
+    - Note that the parameter **MUST** be defined as an 'output' parameter in
+      the base module.
 
-R-69634 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property
-subnet'/'subnet_id' parameter 'int\_{network-role}_subnet_id'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
-Environment File.
+.. req::
+    :id: R-69634
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property
+    subnet'/'subnet_id' parameter 'int\_{network-role}_subnet_id'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
 
 The assumption is that internal networks are created in the base module.
 The Neutron subnet network ID will be passed as an output parameter
@@ -3561,28 +5173,39 @@ input parameter.
       type: string
       description: Neutron IPv4 subnet UUID for the int_{network-role} network
 
-R-76160 When
 
-- the VNF's Heat Orchestration Template's resource
-  'OS::Neutron::Port' in an Incremental Module is attaching to an
-  internal network that is created in the Base Module, AND
-- an IPv6 address is being Cloud Assigned by OpenStack's DHCP Service AND
-- the internal network IPv6 subnet is to be specified using the property
-  'fixed_ips' map property 'subnet'/'subnet_id',
+.. req::
+    :id: R-76160
+    :target: VNF
+    :keyword: MUST
 
-the parameter **MUST** follow the naming convention
-   * 'int\_{network-role}_v6_subnet_id'
-where
-   * '{network-role}' is the network role of the internal network
+    When
+
+    - the VNF's Heat Orchestration Template's resource
+      'OS::Neutron::Port' in an Incremental Module is attaching to an
+      internal network that is created in the Base Module, AND
+    - an IPv6 address is being Cloud Assigned by OpenStack's DHCP Service AND
+    - the internal network IPv6 subnet is to be specified using the property
+      'fixed_ips' map property 'subnet'/'subnet_id',
+
+    the parameter **MUST** follow the naming convention
+       * 'int\_{network-role}_v6_subnet_id'
+    where
+       * '{network-role}' is the network role of the internal network
 
-- Note that the parameter **MUST** be defined as an 'output' parameter in
-  the base module.
+    - Note that the parameter **MUST** be defined as an 'output' parameter in
+      the base module.
 
-R-22288 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'fixed_ips' map property
-'subnet'/'subnet_id' parameter 'int\_{network-role}_v6_subnet_id'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
-Environment File.
+.. req::
+    :id: R-22288
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'fixed_ips' map property
+    'subnet'/'subnet_id' parameter 'int\_{network-role}_v6_subnet_id'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
 
 *Example Parameter Definition*
 
@@ -3611,9 +5234,15 @@ Note that the management of the VIP IP addresses (i.e. transferring
 ownership between active and standby VMs) is the responsibility of
 the VNF application.
 
-R-62300 If a VNF has two or more ports that require a Virtual IP Address (VIP),
-a VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' property
-'allowed_address_pairs' map property 'ip_address' parameter **MUST** be used.
+
+.. req::
+    :id: R-62300
+    :target: VNF
+    :keyword: MUST
+
+    If a VNF has two or more ports that require a Virtual IP Address (VIP),
+    a VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' property
+    'allowed_address_pairs' map property 'ip_address' parameter **MUST** be used.
 
 The 'allowed_address_pairs' is an optional property. It is not required.
 
@@ -3631,52 +5260,96 @@ VIP Assignment, External Networks, Supported by Automation
 __________________________________________________________
 
 
-R-91810 If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
-ports connected an external network, the port
-**MUST NOT** have more than one IPv4 VIP address.
-
-R-41956 If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
-ports connected an external network, the port
-**MUST NOT** have more than one IPv6 VIP address.
-
-R-10754 If a VNF has two or more ports that
-attach to an external network that require a Virtual IP Address (VIP),
-and the VNF requires ONAP automation to assign the IP address,
-all the Virtual Machines using the VIP address **MUST**
-be instantiated in the same Base Module Heat Orchestration Template
-or in the same Incremental Module Heat Orchestration Template.
-
-
-R-98748 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'allowed_address_pairs'
-map property 'ip_address' parameter
-**MUST** be declared as type 'string'.
-
-
-R-41492 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an external network,
-and an IPv4 Virtual IP (VIP)
-address is assigned via ONAP automation
-using the property 'allowed_address_pairs'
-map property 'ip_address' and
-the parameter name **MUST** follow the
-naming convention
-
-   * '{vm-type}_{network-role}_floating_ip'
-
-where
-
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the external network
-
-And the parameter **MUST** be declared as type 'string'.
 
-R-83412 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'allowed_address_pairs'
-map property 'ip_address' parameter
-'{vm-type}_{network-role}_floating_ip'
-**MUST NOT** be enumerated in the
-VNF's Heat Orchestration Template's Environment File.
+.. req::
+    :id: R-91810
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
+    ports connected an external network, the port
+    **MUST NOT** have more than one IPv4 VIP address.
+
+.. req::
+    :id: R-41956
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
+    ports connected an external network, the port
+    **MUST NOT** have more than one IPv6 VIP address.
+
+.. req::
+    :id: R-10754
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF has two or more ports that
+    attach to an external network that require a Virtual IP Address (VIP),
+    and the VNF requires ONAP automation to assign the IP address,
+    all the Virtual Machines using the VIP address **MUST**
+    be instantiated in the same Base Module Heat Orchestration Template
+    or in the same Incremental Module Heat Orchestration Template.
+
+.. req::
+    :id: R-98748
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'allowed_address_pairs'
+    map property 'ip_address' parameter
+    **MUST** be declared as type 'string'.
+
+.. req::
+    :id: R-41492
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an external network,
+    and an IPv4 Virtual IP (VIP) address is assigned via ONAP automation
+    using the property 'allowed_address_pairs' map property 'ip_address' and
+    the parameter name **MUST** follow the naming convention
+
+       * '{vm-type}_{network-role}_floating_ip'
+
+    where
+
+       * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+       * '{network-role}' is the {network-role} of the external network
+
+    And the parameter **MUST** be declared as type 'string'.
+
+.. req::
+    :id: R-83412
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'allowed_address_pairs'
+    map property 'ip_address' parameter
+    '{vm-type}_{network-role}_floating_ip'
+    **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
 
 *Example Parameter Definition*
 
@@ -3690,32 +5363,44 @@ VNF's Heat Orchestration Template's Environment File.
 
 
 
-R-35735 When the VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' is attaching to an external network,
-and an IPv6 Virtual IP (VIP)
-address is assigned via ONAP automation
-using the property 'allowed_address_pairs'
-map property 'ip_address',
-the parameter name **MUST** follow the
-naming convention
 
-   * '{vm-type}_{network-role}_v6_floating_ip'
+.. req::
+    :id: R-35735
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-where
+    When the VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' is attaching to an external network,
+    and an IPv6 Virtual IP (VIP) address is assigned via ONAP automation
+    using the property 'allowed_address_pairs' map property 'ip_address',
+    the parameter name **MUST** follow the naming convention
+
+       * '{vm-type}_{network-role}_v6_floating_ip'
 
-   * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
-   * '{network-role}' is the {network-role} of the external network
+    where
 
-And the parameter **MUST** be declared as type 'string'.
+       * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server
+       * '{network-role}' is the {network-role} of the external network
 
+    And the parameter **MUST** be declared as type 'string'.
 
+.. req::
+    :id: R-83418
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
 
-R-83418 The VNF's Heat Orchestration Template's Resource
-'OS::Neutron::Port' property 'allowed_address_pairs'
-map property 'ip_address' parameter
-'{vm-type}_{network-role}_floating_v6_ip'
-**MUST NOT** be enumerated in the
-VNF's Heat Orchestration Template's Environment File.
+    The VNF's Heat Orchestration Template's Resource
+    'OS::Neutron::Port' property 'allowed_address_pairs'
+    map property 'ip_address' parameter
+    '{vm-type}_{network-role}_floating_v6_ip'
+    **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
 
 *Example Parameter Definition*
 
@@ -3736,11 +5421,28 @@ Neutron-style Floating IPs.  That is, ONAP does not support the
 resources 'OS::Neutron::FloatingIP'
 and 'OS::Neutron::FloatingIPAssociation'.
 
-R-05257 A VNF's Heat Orchestration Template's **MUST NOT**
-contain the Resource 'OS::Neutron::FloatingIP'.
 
-R-76449 A VNF's Heat Orchestration Template's **MUST NOT**
-contain the Resource 'OS::Neutron::FloatingIPAssociation'.
+.. req::
+    :id: R-05257
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's **MUST NOT**
+    contain the Resource 'OS::Neutron::FloatingIP'.
+
+.. req::
+    :id: R-76449
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's **MUST NOT**
+    contain the Resource 'OS::Neutron::FloatingIPAssociation'.
 
 The Floating IP functions as a NAT.  They are allocated within
 Openstack, and always "terminate" within the Openstack infrastructure.
@@ -4150,17 +5852,32 @@ OS::Nova::Server resources must be defined when the property is used.
 Not all resources require the property name (e.g., it is optional) and
 some resources do not support the property.
 
-R-85734 If a VNF's Heat Orchestration Template contains the property 'name'
-for a non 'OS::Nova::Server' resource, the intrinsic function
-'str_replace' **MUST** be used in conjunction with the ONAP
-supplied metadata parameter 'vnf_name' to generate a unique value.
+
+.. req::
+    :id: R-85734
+    :target: VNF
+    :keyword: MUST
+
+    If a VNF's Heat Orchestration Template contains the property 'name'
+    for a non 'OS::Nova::Server' resource, the intrinsic function
+    'str_replace' **MUST** be used in conjunction with the ONAP
+    supplied metadata parameter 'vnf_name' to generate a unique value.
 
 This prevents the enumeration of a
 unique value for the property name in a per instance environment file.
 
-R-99812 A value for VNF's Heat Orchestration Template's property 'name'
-for a non 'OS::Nova::Server' resource **MUST NOT** be declared
-in the VNF's Heat Orchestration Template's Environment File.
+
+.. req::
+    :id: R-99812
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A value for VNF's Heat Orchestration Template's property 'name'
+    for a non 'OS::Nova::Server' resource **MUST NOT** be declared
+    in the VNF's Heat Orchestration Template's Environment File.
 
 In most cases the use of the metadata value 'vnf_name' is required to create a
 unique property name.  If this will not provide a unique value,
@@ -4171,13 +5888,22 @@ additional options include:
  - Resources created in a nested heat file invoked by an
    'OS::Heat::ResourceGroup' can use the 'index' to construct a unique name
 
-R-32408 If a VNF's Heat Orchestration Template property 'name'
-for a non 'OS::Nova::Server' resource uses the intrinsic function
-'str_replace' in conjunction with the ONAP
-supplied metadata parameter 'vnf_name' and does not create
-a unique value, additional data **MUST** be used in the
-'str_replace' to create a unique value, such as 'OS::stack_name'
-and/or the 'OS::Heat::ResourceGroup' 'index'.
+
+.. req::
+    :id: R-32408
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Heat Orchestration Template property 'name'
+    for a non 'OS::Nova::Server' resource uses the intrinsic function
+    'str_replace' in conjunction with the ONAP
+    supplied metadata parameter 'vnf_name' and does not create
+    a unique value, additional data **MUST** be used in the
+    'str_replace' to create a unique value, such as 'OS::stack_name'
+    and/or the 'OS::Heat::ResourceGroup' 'index'.
 
 *Example: Property 'name' for resource 'OS::Neutron::SecurityGroup'*
 
@@ -4234,22 +5960,31 @@ and/or the 'OS::Heat::ResourceGroup' 'index'.
 Contrail Issue with Values for the Property Name
 ++++++++++++++++++++++++++++++++++++++++++++++++
 
-R-84517 The Contrail GUI has a limitation displaying special characters.
-The issue is documented in
-https://bugs.launchpad.net/juniperopenstack/+bug/1590710.
-It is recommended that special **SHOULD** characters be avoided.
-However, if special characters must be used, note that for
-the following resources:
 
-   * Virtual Machine
-   * Virtual Network
-   * Port
-   * Security Group
-   * Policies
-   * IPAM Creation
+.. req::
+    :id: R-84517
+    :target: VNF
+    :keyword: SHOULD
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    The Contrail GUI has a limitation displaying special characters.
+    The issue is documented in
+    https://bugs.launchpad.net/juniperopenstack/+bug/1590710.
+    It is recommended that special **SHOULD** characters be avoided.
+    However, if special characters must be used, note that for
+    the following resources:
 
-the only special characters supported
-are - \" ! $\ \ ' ( ) = ~ ^ | @ ` { } [ ] > , . _"
+       * Virtual Machine
+       * Virtual Network
+       * Port
+       * Security Group
+       * Policies
+       * IPAM Creation
+
+    the only special characters supported
+    are - \" ! $\ \ ' ( ) = ~ ^ | @ ` { } [ ] > , . _"
 
 ONAP Output Parameter Names
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -4263,15 +5998,33 @@ ONAP Base Module Output Parameters:
 ONAP Base Module Output Parameters do not have an explicit naming
 convention.
 
-R-97726 A VNF's Heat Orchestration Template's Base Module Output
-Parameter names **MUST** contain {vm-type} and/or {network-role}
-when appropriate.
+
+.. req::
+    :id: R-97726
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Base Module Output
+    Parameter names **MUST** contain {vm-type} and/or {network-role}
+    when appropriate.
 
 ONAP Volume Template Output Parameters:
 +++++++++++++++++++++++++++++++++++++++
 
-R-88524 A VNF's Heat Orchestration Template's Volume Template
-Output Parameter names **MUST** contain {vm-type} when appropriate.
+
+.. req::
+    :id: R-88524
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's Volume Template
+    Output Parameter names **MUST** contain {vm-type} when appropriate.
 
 Predefined Output Parameters
 ++++++++++++++++++++++++++++
@@ -4289,35 +6042,69 @@ of this interface must be captured and inventoried by ONAP. The IP
 address might be a VIP if the VNF contains an HA pair of management VMs,
 or may be a single IP address assigned to one VM.
 
-R-47874 A VNF **MAY** have
-
-   * Only an IPv4 OAM Management IP Address
-   * Only an IPv6 OAM Management IP Address
-   * Both a IPv4 and IPv6 OAM Management IP Addresses
 
-R-18683 If a VNF has one IPv4 OAM Management IP Address and the
-IP Address needs to be inventoried in ONAP's A&AI
-database, an output parameter **MUST** be declared in only one of the
-VNF's Heat Orchestration Templates and the parameter **MUST** be named
-'oam_management_v4_address'.
-
-R-94669 If a VNF has one IPv6 OAM Management IP Address and the
-IP Address needs to be inventoried in ONAP's A&AI
-database, an output parameter **MUST** be declared in only one of the
-VNF's Heat Orchestration Templates and the parameter **MUST** be named
-'oam_management_v6_address'.
+.. req::
+    :id: R-47874
+    :target: VNF
+    :keyword: MAY
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF **MAY** have
+
+     * Only an IPv4 OAM Management IP Address
+     * Only an IPv6 OAM Management IP Address
+     * Both a IPv4 and IPv6 OAM Management IP Addresses
+
+.. req::
+    :id: R-18683
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF has one IPv4 OAM Management IP Address and the
+    IP Address needs to be inventoried in ONAP's A&AI
+    database, an output parameter **MUST** be declared in only one of the
+    VNF's Heat Orchestration Templates and the parameter **MUST** be named
+    'oam_management_v4_address'.
+
+.. req::
+    :id: R-94669
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF has one IPv6 OAM Management IP Address and the
+    IP Address needs to be inventoried in ONAP's AAI
+    database, an output parameter **MUST** be declared in only one of the
+    VNF's Heat Orchestration Templates and the parameter **MUST** be named
+    'oam_management_v6_address'.
 
 The OAM Management IP Address maybe assigned either via
   *  ONAP SDN-C
   *  DHCP
 
-R-56287 If the VNF's OAM Management IP Address is assigned by ONAP SDN-C and
-assigned in the VNF's Heat Orchestration Template's via a heat resource
-'OS::Neutron::Port' property 'fixed_ips' map property
-'ip_adress' parameter (e.g., '{vm-type}_{network-role}_ip_{index}',
-'{vm-type}_{network-role}_v6_ip_{index}')
-and the OAM IP Address is required to be inventoried in ONAP AAI,
-then the parameter **MUST** be echoed in an output statement.
+
+.. req::
+    :id: R-56287
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If the VNF's OAM Management IP Address is assigned by ONAP SDN-C and
+    assigned in the VNF's Heat Orchestration Template's via a heat resource
+    'OS::Neutron::Port' property 'fixed_ips' map property
+    'ip_adress' parameter (e.g., '{vm-type}_{network-role}_ip_{index}',
+    '{vm-type}_{network-role}_v6_ip_{index}')
+    and the OAM IP Address is required to be inventoried in ONAP AAI,
+    then the parameter **MUST** be echoed in an output statement.
 
 .. code-block:: yaml
 
@@ -4367,10 +6154,18 @@ oam_management_v4_address*
         value: {get_param: admin_oam_ip_0 }
 
 
-R-48987 If the VNF's OAM Management IP Address is Cloud assigned and
-and the OAM IP Address is required to be inventoried in ONAP AAI,
-then the parameter **MUST** be obtained by the resource 'OS::Neutron::Port'
-attribute 'ip_address'.
+.. req::
+    :id: R-48987
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If the VNF's OAM Management IP Address is Cloud assigned and
+    and the OAM IP Address is required to be inventoried in ONAP AAI,
+    then the parameter **MUST** be obtained by the resource 'OS::Neutron::Port'
+    attribute 'ip_address'.
 
 .. code-block:: yaml
 
@@ -4428,24 +6223,49 @@ using the network FQDN.
 External Networks
 _________________
 
-R-02164 When a VNF's Heat Orchestration Template's Contrail resource
-has a property that
-references an external network that requires the network's
-Fully Qualified Domain Name (FQDN), the property parameter
 
-   * **MUST** follow the format '{network-role}_net_fqdn'
-   * **MUST** be declared as type 'string'
-   * **MUST NOT** be enumerated in the NF's Heat Orchestration Template's
-     Environment File
-
-R-73228 A VNF's Heat Orchestration Template's parameter
-'{network-role}_net_fqdn'
-**MUST** be declared as type 'string'.
-
-R-92193 A VNF's Heat Orchestration Template's parameter
-'{network-role}_net_fqdn'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
-Environment File.
+.. req::
+    :id: R-02164
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    When a VNF's Heat Orchestration Template's Contrail resource
+    has a property that
+    references an external network that requires the network's
+    Fully Qualified Domain Name (FQDN), the property parameter
+
+       * **MUST** follow the format '{network-role}_net_fqdn'
+       * **MUST** be declared as type 'string'
+       * **MUST NOT** be enumerated in the NF's Heat Orchestration Template's
+         Environment File
+
+.. req::
+    :id: R-73228
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's parameter
+    '{network-role}_net_fqdn'
+    **MUST** be declared as type 'string'.
+
+.. req::
+    :id: R-92193
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    A VNF's Heat Orchestration Template's parameter
+    '{network-role}_net_fqdn'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
 
 *Example: Parameter declaration*
 
@@ -4486,28 +6306,53 @@ virtual_network_refs references a contrail network FQDN.
 Interface Route Table Prefixes for Contrail InterfaceRoute Table
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-R-28222 If a VNF's Heat Orchestration Template
-'OS::ContrailV2::InterfaceRouteTable' resource
-'interface_route_table_routes' property
-'interface_route_table_routes_route' map property parameter name
-**MUST** follow the format
-
-   * {vm-type}_{network-role}_route_prefixes
-
-R-19756 If a VNF's Heat Orchestration Template
-OS::ContrailV2::InterfaceRouteTable resource
-'interface_route_table_routes' property
-'interface_route_table_routes_route' map property parameter
-'{vm-type}_{network-role}_route_prefixes'
-**MUST** be defined as type 'json'.
-
-R-76682 If a VNF's Heat Orchestration Template
-OS::ContrailV2::InterfaceRouteTable resource
-'interface_route_table_routes' property
-'interface_route_table_routes_route' map property parameter
-'{vm-type}_{network-role}_route_prefixes'
-**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
-Environment File.
+
+.. req::
+    :id: R-28222
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Heat Orchestration Template
+    'OS::ContrailV2::InterfaceRouteTable' resource
+    'interface_route_table_routes' property
+    'interface_route_table_routes_route' map property parameter name
+    **MUST** follow the format
+
+       * {vm-type}_{network-role}_route_prefixes
+
+.. req::
+    :id: R-19756
+    :target: VNF
+    :keyword: MUST
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Heat Orchestration Template
+    'OS::ContrailV2::InterfaceRouteTable' resource
+    'interface_route_table_routes' property
+    'interface_route_table_routes_route' map property parameter
+    '{vm-type}_{network-role}_route_prefixes'
+    **MUST** be defined as type 'json'.
+
+.. req::
+    :id: R-76682
+    :target: VNF
+    :keyword: MUST NOT
+    :test: no test found
+    :test_case: no test found
+    :test_file: no test found
+
+    If a VNF's Heat Orchestration Template
+    'OS::ContrailV2::InterfaceRouteTable' resource
+    'interface_route_table_routes' property
+    'interface_route_table_routes_route' map property parameter
+    '{vm-type}_{network-role}_route_prefixes'
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
 
 The parameter '{vm-type}_{network-role}_route_prefixes'
 supports IP addresses in the format:
@@ -4607,7 +6452,6 @@ property 'instance_ip_address' parameter
 that apply to the resource 'OS::Neutron' property 'fixed_ips' map
 property 'ip_address' parameter.
 
-
 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
 instance_ip_address*
 
@@ -4918,7 +6762,7 @@ represents a subset of the overall VNF. These component parts are
 referred to as *VNF Modules*. During orchestration, these modules
 are deployed incrementally to create the complete VNF.
 
-A stated in R-33132, a VNF's Heat Orchestration Template **MAY** be
+As stated in 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
@@ -4959,13 +6803,19 @@ other Heat Resources either in the Base Module or an
 Incremental Module.
 
 
-R-61001 A shared Heat Orchestration Template resource must be defined
-in the base module. A shared resource is a resource that that will
-be referenced by another resource that is defined in the Base Module
-and/or one or more incremental modules. 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.
+
+.. req::
+    :id: R-61001
+    :target: VNF
+    :keyword: MUST
+
+    A shared Heat Orchestration Template resource must be defined
+    in the base module. A shared resource is a resource that that will
+    be referenced by another resource that is defined in the Base Module
+    and/or one or more incremental modules. 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.
 
 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
@@ -5234,9 +7084,15 @@ module, the scope of volume templates must be 1:1 with Base module or
 Incremental module. A single volume module must create only the volumes
 required by a single Incremental module or Base module.
 
-R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1
-scope of a cinder volume module, when it exists, with the
-Base Module or Incremental Module.
+
+.. req::
+    :id: R-47788
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Heat Orchestration Template **MUST** have a 1:1
+    scope of a cinder volume module, when it exists, with the
+    Base Module or Incremental Module.
 
 As stated in R-11200, a VNF's Cinder Volume Module, when it exists,
 **MUST** be 1:1 with a Base module or Incremental module.  That is,
@@ -5262,10 +7118,16 @@ required by a single Incremental module or Base module.
 
 The following rules apply to independent volume Heat templates:
 
--  R-79531 The VNF Heat Orchestration Template **MUST** define
-   "outputs" in the volume template for each Cinder volume
-   resource universally unique identifier (UUID) (i.e. ONAP
-   Volume Template Output Parameters).
+
+.. req::
+    :id: R-79531
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Heat Orchestration Template **MUST** define
+    "outputs" in the volume template for each Cinder volume
+    resource universally unique identifier (UUID) (i.e. ONAP
+    Volume Template Output Parameters).
 
 -  The VNF Incremental Module or Base Module must define input
    parameters that match each Volume output parameter (i.e., ONAP Volume
@@ -5279,8 +7141,14 @@ The following rules apply to independent volume Heat templates:
 Optional Property availability_zone
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-R-25190 A VNF's Heat Orchestration Template's Resource 'OS::Cinder::Volume'
-**SHOULD NOT** declare the property 'availability_zone'.
+
+.. req::
+    :id: R-25190
+    :target: VNF
+    :keyword: SHOULD NOT
+
+    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
@@ -5379,14 +7247,30 @@ be enumerated.
 (Note that ONAP does not programmatically enforce the use of
 an environment file.)
 
-R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
-environment file for a Base Module.
 
-R-35727 The VNF Heat Orchestration Template **MUST** have a
-corresponding environment file for an Incremental module.
+.. req::
+    :id: R-67205
+    :target: VNF
+    :keyword: MUST
+
+    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
 
-R-22656 The VNF Heat Orchestration Template **MUST** have a
-corresponding environment file for a Cinder Volume Module.
+    The VNF Heat Orchestration Template **MUST** have a
+    corresponding environment file for a Cinder Volume Module.
 
 A nested heat template must not have an environment file; OpenStack does
 not support it.
@@ -5452,20 +7336,41 @@ Nested Heat Template Requirements
 ONAP supports nested Heat Orchestration Templates. A Base Module,
 Incremental Module, and Cinder Volume Module may use nested heat.
 
-R-00228 A VNF's Heat Orchestration Template **MAY**
-reference the nested heat statically by repeated definition.
 
-R-01101 A VNF's Heat Orchestration Template **MAY**
-reference the nested heat dynamically using the resource
-'OS::Heat::ResourceGroup'.
+.. req::
+    :id: R-00228
+    :target: VNF
+    :keyword: MAY
 
-R-60011 A VNF's Heat Orchestration Template **MUST** have no more than
-two levels of nesting.
+    A VNF's Heat Orchestration Template **MAY**
+    reference the nested heat statically by repeated definition.
 
-R-70112 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.
+.. req::
+    :id: R-01101
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Template **MAY**
+    reference the nested heat dynamically using the resource
+    'OS::Heat::ResourceGroup'.
+
+.. req::
+    :id: R-60011
+    :target: VNF
+    :keyword: MUST
+
+    A VNF's Heat Orchestration Template **MUST** have no more than
+    two levels of nesting.
+
+.. req::
+    :id: R-70112
+    :target: VNF
+    :keyword: MUST
+
+    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
@@ -5474,25 +7379,51 @@ 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.
 
-R-89868 The VNF Heat Orchestration Template **MUST** have unique
-file names within the scope of the VNF for a nested heat yaml file.
 
-R-52530 A VNF's Heat Orchestration Template's Nested YAML file
-**MUST** be in the same directory hierarchy as the VNF's Heat
-Orchestration Templates.
+.. req::
+    :id: R-89868
+    :target: VNF
+    :keyword: MUST
 
-R-90022 A VNF's Nested YAML file **MAY** be invoked more than
-once by a VNF's Heat Orchestration Template.
+    The VNF Heat Orchestration Template **MUST** have unique
+    file names within the scope of the VNF for a nested heat yaml file.
 
-R-04344 A VNF's Nested YAML file **MAY** be invoked by more than one of
-a VNF's Heat Orchestration Templates (when the VNF is composed of two
-or more Heat Orchestration Templates).
+.. req::
+    :id: R-52530
+    :target: VNF
+    :keyword: MUST
 
-Note that:
+    A VNF's Heat Orchestration Template's Nested YAML file
+    **MUST** be in the same directory hierarchy as the VNF's Heat
+    Orchestration Templates.
+
+.. req::
+    :id: R-90022
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Nested YAML file **MAY** be invoked more than
+    once by a VNF's Heat Orchestration Template.
 
--  R-11041 All parameters defined in a VNFs Nested YAML file
-   **MUST** be passed in as properties of the resource calling
-   the nested yaml file.
+.. req::
+    :id: R-04344
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Nested YAML file **MAY** be invoked by more than one of
+    a VNF's Heat Orchestration Templates (when the VNF is composed of two
+    or more Heat Orchestration Templates).
+
+.. req::
+    :id: R-11041
+    :target: VNF
+    :keyword: MUST
+
+    All parameters defined in a VNFs Nested YAML file
+    **MUST** be passed in as properties of the resource calling
+    the nested yaml file.
+
+Note that:
 
 -  As stated in requirement R-00011, a VNF's Heat Orchestration
    Template's Nested YAML file's parameter's **MUST NOT** have
@@ -5675,10 +7606,16 @@ You can then reference within the nested template as:
 OS::Heat::ResourceGroup Property count
 ________________________________________
 
-R-50011 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.
+
+.. req::
+    :id: R-50011
+    :target: VNF
+    :keyword: MUST
+
+    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.
 
 This is required for ONAP to build the TOSCA model for the VNF.
 
@@ -5977,32 +7914,60 @@ a VM on startup via the "personality" property.
 
 Support for Heat Files is subject to the following limitations:
 
-R-76718 If a VNF's Heat Orchestration Template uses the intrinsic function
-'get\_file', the 'get\_file' target **MUST** be referenced in
-the Heat Orchestration Template by file name.
+
+.. req::
+    :id: R-76718
+    :target: VNF
+    :keyword: MUST
+
+    If a VNF's Heat Orchestration Template uses the intrinsic function
+    '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
 that contains the VNF's complete Heat Orchestration Template.
 
-R-41888 A VNF's Heat Orchestration Template intrinsic function
-'get\_file' **MUST NOT** utilize URL-based file retrieval.
 
-R-62177 When using the intrinsic function get_file, the included files
-**MUST** have unique file names within the scope of the VNF.
+.. req::
+    :id: R-41888
+    :target: VNF
+    :keyword: MUST NOT
+
+    A VNF's Heat Orchestration Template intrinsic function
+    'get\_file' **MUST NOT** utilize URL-based file retrieval.
+
+.. req::
+    :id: R-62177
+    :target: VNF
+    :keyword: MUST
+
+    When using the intrinsic function get_file, the included files
+    **MUST** have unique file names within the scope of the VNF.
 
-R-87848 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.
+.. req::
+    :id: R-87848
+    :target: VNF
+    :keyword: MUST
+
+    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.
 
-R-05050 A VNF's Heat Orchestration Templates intrinsic function
-'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
-      * in a VNF's Heat Orchestration Templates nested YAML file
+.. req::
+    :id: R-05050
+    :target: VNF
+    :keyword: MAY
+
+    A VNF's Heat Orchestration Templates intrinsic function
+    '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
+        * in a VNF's Heat Orchestration Templates nested YAML file
 
 Key Pairs
 ~~~~~~~~~
@@ -6241,3 +8206,4 @@ to the Heat template.
 *Note:* It is important to follow this convention to the extent possible
 even in the short-term as of the long-term direction.
 
+
diff --git a/docs/Chapter7/Configuration-Management.rst b/docs/Chapter7/Configuration-Management.rst
index 075c005..34f6ecc 100644
--- a/docs/Chapter7/Configuration-Management.rst
+++ b/docs/Chapter7/Configuration-Management.rst
@@ -75,13 +75,48 @@ scale-out. This command is being introduced in the Beijing release.
 **Audit**: The Controller client is requesting that the current (last known
 configuration update) is audited against the running configuration on the VNF.
 
-* R-20741 The xNF **MUST** support ONAP Controller’s **Configure** command.
-* R-19366 The xNF **MUST** support ONAP Controller’s **ConfigModify** command.
-* R-32981 The xNF **MUST** support ONAP Controller’s **ConfigBackup** command.
-* R-48247 The xNF **MUST** support ONAP Controller’s **ConfigRestore** command.
-* R-94084 The xNF **MUST** support ONAP Controller’s **ConfigScaleOut**
-  command.
-* R-56385 The xNF **MUST** support ONAP Controller’s **Audit** command.
+
+.. req::
+    :id: R-20741    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **Configure** command.
+
+.. req::
+    :id: R-19366    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **ConfigModify** command.
+
+.. req::
+    :id: R-32981    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **ConfigBackup** command.
+
+.. req::
+    :id: R-48247    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **ConfigRestore** command.
+
+.. req::
+    :id: R-94084    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **ConfigScaleOut** command.
+
+.. req::
+    :id: R-56385    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **Audit** command.
 
 LifeCycle Management Related Commands
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,24 +166,69 @@ up prior to the UpgradeSoftware.
 is backed out (in the event that the SoftwareUpgrade or UpgradePostCheck
 failed).
 
-* R-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic**
-  command.
-* R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic**
-  command.
-* R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication**
-  command.
-* R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication**
-  command.
-* R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck**
-  command.
-* R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware**
-  command.
-* R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck**
-  command.
-* R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup**
-  command.
-* R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut**
-  command.
+
+.. req::
+    :id: R-12706    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **QuiesceTraffic** command.
+
+.. req::
+    :id: R-07251    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **ResumeTraffic** command.
+
+.. req::
+    :id: R-83146    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **StopApplication** command.
+
+.. req::
+    :id: R-82811    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **StartApplication** command.
+
+.. req::
+    :id: R-19922    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **UpgradePrecheck** command.
+
+.. req::
+    :id: R-49466    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **UpgradeSoftware** command.
+
+.. req::
+    :id: R-45856    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **UpgradePostCheck** command.
+
+.. req::
+    :id: R-97343    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **UpgradeBackup** command.
+
+.. req::
+    :id: R-65641    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **UpgradeBackOut** command.
 
 Virtual Function - Container Recovery Requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -167,21 +247,43 @@ without having to rebuild entire VNFs or even entire sites these basic
 recovery capabilities of individual containers, Virtual Machines or other,
 must be supported.
 
-* R-11790 The VNF **MUST** support ONAP Controller’s
-  **Restart (stop/start or reboot)** command.
-* R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that
-  moves container (VM) from a live Physical Server / Compute Node to
-  another live Physical Server / Compute Node.
 
-NOTE: Container migrations MUST be transparent to the VNF and no more
-intrusive than a stop, followed by some down time for the migration to
-be performed from one Compute Node / Physical Server to another, followed
-by a start of the same VM with same configuration on the new Compute
-Node / Physical Server.
+.. req::
+    :id: R-11790    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support ONAP Controller's
+    **Restart (stop/start or reboot)** command.
+
+.. req::
+    :id: R-56218    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support ONAP Controller's Migrate command that
+    moves container (VM) from a live Physical Server / Compute Node to
+    another live Physical Server / Compute Node.
+
+        Note: Container migrations MUST be transparent to the VNF and no more intrusive than a stop,
+        followed by some down time for the migration to be performed from one Compute Node / Physical
+        Server to another, followed by a start of the same VM with same configuration on the new
+        Compute Node / Physical Server.
 
-* R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command.
-* R-76901 VNF MUST support a container rebuild mechanism based on existing
-  image (e.g. Glance image in Openstack environment) or a snapshot.
+.. req::
+    :id: R-38001    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support ONAP Controller's **Rebuild** command.
+
+.. req::
+    :id: R-76901    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** support a container rebuild mechanism based on existing
+    image (e.g. Glance image in Openstack environment) or a snapshot.
 
 HealthCheck and Failure Related Commands
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -197,8 +299,13 @@ Openstack failure recovery related commands that are executed on-demand or via
 Control Loop at the VM level.  The VNF must support these commands in a fully
 automated fashion.
 
-* R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck**
-  command.
+
+.. req::
+    :id: R-41430    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support ONAP Controller's **HealthCheck** command.
 
 Notes On Command Support Using Controller Southbound Protocols
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -224,7 +331,10 @@ Notes:
 * REST is specified as an option only for the HealthCheck.
 
 
-Additional details can be found in the `ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20API%20Guide/APPC%20API%20Guide.html>`_, `ONAP VF-C project <http://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and the `ONAP SDNC project <http://onap.readthedocs.io/en/latest/submodules/sdnc/northbound.git/docs/index.html>`_.
+Additional details can be found in the
+`ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20API%20Guide/APPC%20API%20Guide.html>`_,
+`ONAP VF-C project <http://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and
+the `ONAP SDNC project <http://onap.readthedocs.io/en/latest/submodules/sdnc/northbound.git/docs/index.html>`_.
 
 NETCONF Standards and Capabilities
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -241,203 +351,577 @@ VNF Configuration via NETCONF Requirements
 Configuration Management
 +++++++++++++++++++++++++++
 
-* R-88026 The xNF **MUST** include a NETCONF server enabling
-  runtime configuration and lifecycle management capabilities.
-* R-95950 The xNF **MUST** provide a NETCONF interface fully defined
-  by supplied YANG models for the embedded NETCONF server.
+
+.. req::
+    :id: R-88026    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** include a NETCONF server enabling
+    runtime configuration and lifecycle management capabilities.
+
+.. req::
+    :id: R-95950    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** provide a NETCONF interface fully defined
+    by supplied YANG models for the embedded NETCONF server.
 
 NETCONF Server Requirements
 ++++++++++++++++++++++++++++++
 
-* R-73468 The xNF **MUST** allow the NETCONF server connection
-  parameters to be configurable during virtual machine instantiation
-  through Heat templates where SSH keys, usernames, passwords, SSH
-  service and SSH port numbers are Heat template parameters.
-* R-90007 The xNF **MUST** implement the protocol operation:
-  **close-session()**- Gracefully close the current session.
-* R-70496 The xNF **MUST** implement the protocol operation:
-  **commit(confirmed, confirm-timeout)** - Commit candidate
-  configuration datastore to the running configuration.
-* R-18733 The xNF **MUST** implement the protocol operation:
-  **discard-changes()** - Revert the candidate configuration
-  datastore to the running configuration.
-* R-44281 The xNF **MUST** implement the protocol operation:
-  **edit-config(target, default-operation, test-option, error-option,
-  config)** - Edit the target configuration datastore by merging,
-  replacing, creating, or deleting new config elements.
-* R-60106 The xNF **MUST** implement the protocol operation:
-  **get(filter)** - Retrieve (a filtered subset of) the running
-  configuration and device state information. This should include
-  the list of xNF supported schemas.
-* R-29488 The xNF **MUST** implement the protocol operation:
-  **get-config(source, filter)** - Retrieve a (filtered subset of
-  a) configuration from the configuration datastore source.
-* R-11235 The xNF **MUST** implement the protocol operation:
-  **kill-session(session)** - Force the termination of **session**.
-* R-02597 The xNF **MUST** implement the protocol operation:
-  **lock(target)** - Lock the configuration datastore target.
-* R-96554 The xNF **MUST** implement the protocol operation:
-  **unlock(target)** - Unlock the configuration datastore target.
-* R-29324 The xNF **SHOULD** implement the protocol operation:
-  **copy-config(target, source) -** Copy the content of the
-  configuration datastore source to the configuration datastore target.
-* R-88031 The xNF **SHOULD** implement the protocol operation:
-  **delete-config(target) -** Delete the named configuration
-  datastore target.
-* R-97529 The xNF **SHOULD** implement the protocol operation:
-  **get-schema(identifier, version, format) -** Retrieve the YANG schema.
-* R-62468 The xNF **MUST** allow all configuration data to be
-  edited through a NETCONF <edit-config> operation. Proprietary
-  NETCONF RPCs that make configuration changes are not sufficient.
-* R-01382 The xNF **MUST** allow the entire configuration of the
-  xNF to be retrieved via NETCONF's <get-config> and <edit-config>,
-  independently of whether it was configured via NETCONF or other
-  mechanisms.
-* R-28756 The xNF **MUST** support **:partial-lock** and
-  **:partial-unlock** capabilities, defined in RFC 5717. This
-  allows multiple independent clients to each write to a different
-  part of the <running> configuration at the same time.
-* R-83873 The xNF **MUST** support **:rollback-on-error** value for
-  the <error-option> parameter to the <edit-config> operation. If any
-  error occurs during the requested edit operation, then the target
-  database (usually the running configuration) will be left unaffected.
-  This provides an 'all-or-nothing' edit mode for a single <edit-config>
-  request.
-* R-68990 The xNF **MUST** support the **:startup** capability. It
-  will allow the running configuration to be copied to this special
-  database. It can also be locked and unlocked.
-* R-68200 The xNF **MUST** support the **:url** value to specify
-  protocol operation source and target parameters. The capability URI
-  for this feature will indicate which schemes (e.g., file, https, sftp)
-  that the server supports within a particular URL value. The 'file'
-  scheme allows for editable local configuration databases. The other
-  schemes allow for remote storage of configuration databases.
-* R-20353 The xNF **MUST** implement both **:candidate** and
-  **:writable-running** capabilities. When both **:candidate** and
-  **:writable-running** are provided then two locks should be supported.
-* R-11499 The xNF **MUST** fully support the XPath 1.0 specification
-  for filtered retrieval of configuration and other database contents.
-  The 'type' attribute within the <filter> parameter for <get> and
-  <get-config> operations may be set to 'xpath'. The 'select' attribute
-  (which contains the XPath expression) will also be supported by the
-  server. A server may support partial XPath retrieval filtering, but
-  it cannot advertise the **:xpath** capability unless the entire XPath
-  1.0 specification is supported.
-* R-83790 The xNF **MUST** implement the **:validate** capability
-* R-49145 The xNF **MUST** implement **:confirmed-commit** If
-  **:candidate** is supported.
-* R-58358 The xNF **MUST** implement the **:with-defaults** capability
-  [RFC6243].
-* R-59610 The xNF **MUST** implement the data model discovery and
-  download as defined in [RFC6022].
-* R-93443 The xNF **MUST** define all data models in YANG [RFC6020],
-  and the mapping to NETCONF shall follow the rules defined in this RFC.
-* R-26115 The xNF **MUST** follow the data model upgrade rules defined
-  in [RFC6020] section 10. All deviations from section 10 rules shall
-  be handled by a built-in automatic upgrade mechanism.
-* R-10716 The xNF **MUST** support parallel and simultaneous
-  configuration of separate objects within itself.
-* R-29495 The xNF **MUST** support locking if a common object is
-  being manipulated by two simultaneous NETCONF configuration operations
-  on the same xNF within the context of the same writable running data
-  store (e.g., if an interface parameter is being configured then it
-  should be locked out for configuration by a simultaneous configuration
-  operation on that same interface parameter).
-* R-53015 The xNF **MUST** apply locking based on the sequence of
-  NETCONF operations, with the first configuration operation locking
-  out all others until completed.
-* R-02616 The xNF **MUST** permit locking at the finest granularity
-  if a xNF needs to lock an object for configuration to avoid blocking
-  simultaneous configuration operations on unrelated objects (e.g., BGP
-  configuration should not be locked out if an interface is being
-  configured or entire Interface configuration should not be locked out
-  if a non-overlapping parameter on the interface is being configured).
-* R-41829 The xNF **MUST** be able to specify the granularity of the
-  lock via a restricted or full XPath expression.
-* R-66793 The xNF **MUST** guarantee the xNF configuration integrity
-  for all simultaneous configuration operations (e.g., if a change is
-  attempted to the BUM filter rate from multiple interfaces on the same
-  EVC, then they need to be sequenced in the xNF without locking either
-  configuration method out).
-* R-54190 The xNF **MUST** release locks to prevent permanent lock-outs
-  when/if a session applying the lock is terminated (e.g., SSH session
-  is terminated).
-* R-03465 The xNF **MUST** release locks to prevent permanent lock-outs
-  when the corresponding <partial-unlock> operation succeeds.
-* R-63935 The xNF **MUST** release locks to prevent permanent lock-outs
-  when a user configured timer has expired forcing the NETCONF SSH Session
-  termination (i.e., product must expose a configuration knob for a user
-  setting of a lock expiration timer)
-* R-10173 The xNF **MUST** allow another NETCONF session to be able to
-  initiate the release of the lock by killing the session owning the lock,
-  using the <kill-session> operation to guard against hung NETCONF sessions.
-* R-88899 The xNF **MUST** support simultaneous <commit> operations
-  within the context of this locking requirements framework.
-* R-07545 The xNF **MUST** support all operations, administration and
-  management (OAM) functions available from the supplier for xNFs using
-  the supplied YANG code and associated NETCONF servers.
-* R-60656 The xNF **MUST** support sub tree filtering.
-* R-80898 The xNF **MUST** support heartbeat via a <get> with null filter.
-* R-25238 The xNF PACKAGE **MUST** validated YANG code using the open
-  source pyang [1]_ program using the following commands:
-
-.. code-block:: python
-
- $ pyang --verbose --strict <YANG-file-name(s)>
- $ echo $!
-
-* R-63953 The xNF **MUST** have the echo command return a zero value
-  otherwise the validation has failed
-* R-26508 The xNF **MUST** support a NETCONF server that can be mounted on
-  OpenDaylight (client) and perform the operations of: modify, update,
-  change, rollback configurations using each configuration data element,
-  query each state (non-configuration) data element, execute each YANG
-  RPC, and receive data through each notification statement.
 
+.. req::
+    :id: R-73468    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** allow the NETCONF server connection
+    parameters to be configurable during virtual machine instantiation
+    through Heat templates where SSH keys, usernames, passwords, SSH
+    service and SSH port numbers are Heat template parameters.
+
+.. req::
+    :id: R-90007    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **close-session()**- Gracefully close the current session.
+
+.. req::
+    :id: R-70496    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **commit(confirmed, confirm-timeout)** - Commit candidate
+    configuration datastore to the running configuration.
+
+.. req::
+    :id: R-18733    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **discard-changes()** - Revert the candidate configuration
+    datastore to the running configuration.
+
+.. req::
+    :id: R-44281    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **edit-config(target, default-operation, test-option, error-option,
+    config)** - Edit the target configuration datastore by merging,
+    replacing, creating, or deleting new config elements.
+
+.. req::
+    :id: R-60106    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **get(filter)** - Retrieve (a filtered subset of) the running
+    configuration and device state information. This should include
+    the list of xNF supported schemas.
+
+.. req::
+    :id: R-29488    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **get-config(source, filter)** - Retrieve a (filtered subset of
+    a) configuration from the configuration datastore source.
+
+.. req::
+    :id: R-11235    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **kill-session(session)** - Force the termination of **session**.
+
+.. req::
+    :id: R-02597    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **lock(target)** - Lock the configuration datastore target.
+
+.. req::
+    :id: R-96554    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the protocol operation:
+    **unlock(target)** - Unlock the configuration datastore target.
+
+.. req::
+    :id: R-29324    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** implement the protocol operation:
+    **copy-config(target, source) -** Copy the content of the
+    configuration datastore source to the configuration datastore target.
+
+.. req::
+    :id: R-88031    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** implement the protocol operation:
+    **delete-config(target) -** Delete the named configuration
+    datastore target.
+
+.. req::
+    :id: R-97529    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** implement the protocol operation:
+    **get-schema(identifier, version, format) -** Retrieve the YANG schema.
+
+.. req::
+    :id: R-62468    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** allow all configuration data to be
+    edited through a NETCONF <edit-config> operation. Proprietary
+    NETCONF RPCs that make configuration changes are not sufficient.
+
+.. req::
+    :id: R-01382    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** allow the entire configuration of the xNF to be
+    retrieved via NETCONF's <get-config> and <edit-config>, independently
+    of whether it was configured via NETCONF or other mechanisms.
+
+.. req::
+    :id: R-28756    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support **:partial-lock** and
+    **:partial-unlock** capabilities, defined in RFC 5717. This
+    allows multiple independent clients to each write to a different
+    part of the <running> configuration at the same time.
+
+.. req::
+    :id: R-83873    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support **:rollback-on-error** value for
+    the <error-option> parameter to the <edit-config> operation. If any
+    error occurs during the requested edit operation, then the target
+    database (usually the running configuration) will be left unaffected.
+    This provides an 'all-or-nothing' edit mode for a single <edit-config>
+    request.
+
+.. req::
+    :id: R-68990    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support the **:startup** capability. It
+    will allow the running configuration to be copied to this special
+    database. It can also be locked and unlocked.
+
+.. req::
+    :id: R-68200    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support the **:url** value to specify
+    protocol operation source and target parameters. The capability URI
+    for this feature will indicate which schemes (e.g., file, https, sftp)
+    that the server supports within a particular URL value. The 'file'
+    scheme allows for editable local configuration databases. The other
+    schemes allow for remote storage of configuration databases.
+
+.. req::
+    :id: R-20353    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement both **:candidate** and
+    **:writable-running** capabilities. When both **:candidate** and
+    **:writable-running** are provided then two locks should be supported.
+
+.. req::
+    :id: R-11499    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** fully support the XPath 1.0 specification
+    for filtered retrieval of configuration and other database contents.
+    The 'type' attribute within the <filter> parameter for <get> and
+    <get-config> operations may be set to 'xpath'. The 'select' attribute
+    (which contains the XPath expression) will also be supported by the
+    server. A server may support partial XPath retrieval filtering, but
+    it cannot advertise the **:xpath** capability unless the entire XPath
+    1.0 specification is supported.
+
+.. req::
+    :id: R-83790    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the **:validate** capability.
+
+.. req::
+    :id: R-49145    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement **:confirmed-commit** If
+    **:candidate** is supported.
+
+.. req::
+    :id: R-58358    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the **:with-defaults** capability
+    [RFC6243].
+
+.. req::
+    :id: R-59610    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** implement the data model discovery and
+    download as defined in [RFC6022].
+
+.. req::
+    :id: R-93443    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** define all data models in YANG [RFC6020],
+    and the mapping to NETCONF shall follow the rules defined in this RFC.
+
+.. req::
+    :id: R-26115    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** follow the data model upgrade rules defined
+    in [RFC6020] section 10. All deviations from section 10 rules shall
+    be handled by a built-in automatic upgrade mechanism.
+
+.. req::
+    :id: R-10716    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support parallel and simultaneous
+    configuration of separate objects within itself.
+
+.. req::
+    :id: R-29495    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support locking if a common object is
+    being manipulated by two simultaneous NETCONF configuration operations
+    on the same xNF within the context of the same writable running data
+    store (e.g., if an interface parameter is being configured then it
+    should be locked out for configuration by a simultaneous configuration
+    operation on that same interface parameter).
+
+.. req::
+    :id: R-53015    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** apply locking based on the sequence of
+    NETCONF operations, with the first configuration operation locking
+    out all others until completed.
+
+.. req::
+    :id: R-02616    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** permit locking at the finest granularity
+    if a xNF needs to lock an object for configuration to avoid blocking
+    simultaneous configuration operations on unrelated objects (e.g., BGP
+    configuration should not be locked out if an interface is being
+    configured or entire Interface configuration should not be locked out
+    if a non-overlapping parameter on the interface is being configured).
+
+.. req::
+    :id: R-41829    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** be able to specify the granularity of the
+    lock via a restricted or full XPath expression.
+
+.. req::
+    :id: R-66793    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** guarantee the xNF configuration integrity
+    for all simultaneous configuration operations (e.g., if a change is
+    attempted to the BUM filter rate from multiple interfaces on the same
+    EVC, then they need to be sequenced in the xNF without locking either
+    configuration method out).
+
+.. req::
+    :id: R-54190    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** release locks to prevent permanent lock-outs
+    when/if a session applying the lock is terminated (e.g., SSH session
+    is terminated).
+
+.. req::
+    :id: R-03465    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** release locks to prevent permanent lock-outs
+    when the corresponding <partial-unlock> operation succeeds.
+
+.. req::
+    :id: R-63935    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** release locks to prevent permanent lock-outs
+    when a user configured timer has expired forcing the NETCONF SSH Session
+    termination (i.e., product must expose a configuration knob for a user
+    setting of a lock expiration timer).
+
+.. req::
+    :id: R-10173    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** allow another NETCONF session to be able to
+    initiate the release of the lock by killing the session owning the lock,
+    using the <kill-session> operation to guard against hung NETCONF sessions.
+
+.. req::
+    :id: R-88899    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support simultaneous <commit> operations
+    within the context of this locking requirements framework.
+
+.. req::
+    :id: R-07545    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support all operations, administration and
+    management (OAM) functions available from the supplier for xNFs using
+    the supplied YANG code and associated NETCONF servers.
+
+.. req::
+    :id: R-60656    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support sub tree filtering.
+
+.. req::
+    :id: R-80898    
+    :target: XNF
+    :keyword: MUST
+
+    TThe xNF **MUST** support heartbeat via a <get> with null filter.
+
+.. req::
+    :id: R-25238    
+    :target: VNF
+    :keyword: MUST
+
+    The xNF PACKAGE **MUST** validated YANG code using the open
+    source pyang [1]_ program using the following commands:
+
+    .. code-block:: python
+
+        $ pyang --verbose --strict <YANG-file-name(s)> $ echo $!
+
+.. req::
+    :id: R-63953    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have the echo command return a zero value
+    otherwise the validation has failed.
+
+.. req::
+    :id: R-26508    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support a NETCONF server that can be mounted on
+    OpenDaylight (client) and perform the operations of: modify, update,
+    change, rollback configurations using each configuration data element,
+    query each state (non-configuration) data element, execute each YANG
+    RPC, and receive data through each notification statement.
 
 The following requirements provides the Yang models that suppliers must
 conform, and those where applicable, that suppliers need to use.
 
-* R-28545 The xNF **MUST** conform its YANG model to RFC 6060,
-  “YANG - A Data Modeling Language for the Network Configuration
-  Protocol (NETCONF)”
-* R-22700 The xNF **MUST** conform its YANG model to RFC 6470,
-  “NETCONF Base Notifications”.
-* R-10353 The xNF **MUST** conform its YANG model to RFC 6244,
-  “An Architecture for Network Management Using NETCONF and YANG”.
-* R-53317 The xNF **MUST** conform its YANG model to RFC 6087,
-  “Guidelines for Authors and Reviewers of YANG Data Model Documents”.
-* R-33955 The xNF **SHOULD** conform its YANG model to RFC 6991,
-  “Common YANG Data Types”.
-* R-22946 The xNF **SHOULD** conform its YANG model to RFC 6536,
-  “NETCONF Access Control Model”.
-* R-10129 The xNF **SHOULD** conform its YANG model to RFC 7223,
-  “A YANG Data Model for Interface Management”.
-* R-12271 The xNF **SHOULD** conform its YANG model to RFC 7223,
-  “IANA Interface Type YANG Module”.
-* R-49036 The xNF **SHOULD** conform its YANG model to RFC 7277,
-  “A YANG Data Model for IP Management”.
-* R-87564 The xNF **SHOULD** conform its YANG model to RFC 7317,
-  “A YANG Data Model for System Management”.
-* R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407,
-  “A YANG Data Model for SNMP Configuration”, if Netconf used to
-  configure SNMP engine.
+
+.. req::
+    :id: R-28545    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform its YANG model to RFC 6060,
+    "YANG - A Data Modeling Language for the Network Configuration
+    Protocol (NETCONF)".
+
+.. req::
+    :id: R-22700    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform its YANG model to RFC 6470,
+    "NETCONF Base Notifications".
+
+.. req::
+    :id: R-10353    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform its YANG model to RFC 6244,
+    "An Architecture for Network Management Using NETCONF and YANG".
+
+.. req::
+    :id: R-53317    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform its YANG model to RFC 6087,
+    "Guidelines for Authors and Reviewers of YANG Data Model Documents".
+
+.. req::
+    :id: R-33955    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 6991,
+    "Common YANG Data Types".
+
+.. req::
+    :id: R-22946    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 6536,
+    "NETCONF Access Control Model".
+
+.. req::
+    :id: R-10129    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 7223,
+    "A YANG Data Model for Interface Management".
+
+.. req::
+    :id: R-12271    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 7223,
+    "IANA Interface Type YANG Module".
+
+.. req::
+    :id: R-49036    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 7277,
+    "A YANG Data Model for IP Management".
+
+.. req::
+    :id: R-87564    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 7317,
+    "A YANG Data Model for System Management".
+
+.. req::
+    :id: R-24269    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** conform its YANG model to RFC 7407,
+    "A YANG Data Model for SNMP Configuration", if Netconf used to
+    configure SNMP engine.
 
 The NETCONF server interface shall fully conform to the following
 NETCONF RFCs.
 
-* R-33946 The xNF **MUST** conform to the NETCONF RFC 4741,
-  “NETCONF Configuration Protocol”.
-* R-04158 The xNF **MUST** conform to the NETCONF RFC 4742,
-  “Using the NETCONF Configuration Protocol over Secure Shell (SSH)”.
-* R-13800 The xNF **MUST** conform to the NETCONF RFC 5277,
-  “NETCONF Event Notification”.
-* R-01334 The xNF **MUST** conform to the NETCONF RFC 5717,
-  “Partial Lock Remote Procedure Call”.
-* R-08134 The xNF **MUST** conform to the NETCONF RFC 6241,
-  “NETCONF Configuration Protocol”.
-* R-78282 The xNF **MUST** conform to the NETCONF RFC 6242,
-  “Using the Network Configuration Protocol over Secure Shell”.
+
+.. req::
+    :id: R-33946    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform to the NETCONF RFC 4741,
+    "NETCONF Configuration Protocol".
+
+.. req::
+    :id: R-04158    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform to the NETCONF RFC 4742,
+    "Using the NETCONF Configuration Protocol over Secure Shell (SSH)".
+
+.. req::
+    :id: R-13800    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform to the NETCONF RFC 5277,
+    "NETCONF Event Notification".
+
+.. req::
+    :id: R-01334    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform to the NETCONF RFC 5717,
+    "Partial Lock Remote Procedure Call".
+
+.. req::
+    :id: R-08134    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform to the NETCONF RFC 6241, 
+    "NETCONF Configuration Protocol".
+
+.. req::
+    :id: R-78282    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** conform to the NETCONF RFC 6242,
+    "Using the Network Configuration Protocol over Secure Shell".
 
 VNF REST APIs
 ^^^^^^^^^^^^^^^
@@ -466,14 +950,20 @@ by the VNF provider.
 REST APIs
 ~~~~~~~~~
 
-* R-31809 The xNF **MUST** support the HealthCheck RPC. The HealthCheck
-  RPC executes a xNF Provider-defined xNF HealthCheck over the scope of
-  the entire xNF (e.g., if there are multiple VNFCs, then run a health check,
-  as appropriate, for all VNFCs). It returns a 200 OK if the test completes.
-  A JSON object is returned indicating state (healthy, unhealthy), scope
-  identifier, time-stamp and one or more blocks containing info and fault
-  information. If the xNF is unable to run the HealthCheck, return a
-  standard http error code and message.
+
+.. req::
+    :id: R-31809    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support the HealthCheck RPC. The HealthCheck
+    RPC executes a xNF Provider-defined xNF HealthCheck over the scope of
+    the entire xNF (e.g., if there are multiple VNFCs, then run a health check,
+    as appropriate, for all VNFCs). It returns a 200 OK if the test completes.
+    A JSON object is returned indicating state (healthy, unhealthy), scope
+    identifier, time-stamp and one or more blocks containing info and fault
+    information. If the xNF is unable to run the HealthCheck, return a
+    standard http error code and message.
 
 Examples of responses when HealthCheck runs and is able to provide a healthy
 or unhealthy response:
@@ -526,69 +1016,152 @@ VNF Configuration via Chef Requirements
 Chef Client Requirements
 +++++++++++++++++++++++++
 
-* R-79224 The xNF **MUST** have the chef-client be preloaded with
-  validator keys and configuration to register with the designated
-  Chef Server as part of the installation process.
-* R-72184 The xNF **MUST** have routable FQDNs for all the endpoints
-  (VMs) of a xNF that contain chef-clients which are used to register
-  with the Chef Server.  As part of invoking xNF actions, ONAP will
-  trigger push jobs against FQDNs of endpoints for a xNF, if required.
-* R-47068 The xNF **MAY** expose a single endpoint that is
-  responsible for all functionality.
-* R-67114 The xNF **MUST** be installed with Chef-Client >= 12.0 and
-  Chef push jobs client >= 2.0.
+
+.. req::
+    :id: R-79224    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have the chef-client be preloaded with
+    validator keys and configuration to register with the designated
+    Chef Server as part of the installation process.
+
+.. req::
+    :id: R-72184    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have routable FQDNs for all the endpoints
+    (VMs) of a xNF that contain chef-clients which are used to register
+    with the Chef Server.  As part of invoking xNF actions, ONAP will
+    trigger push jobs against FQDNs of endpoints for a xNF, if required.
+
+.. req::
+    :id: R-47068    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** expose a single endpoint that is
+    responsible for all functionality.
+
+.. req::
+    :id: R-67114    
+    :target: VNF
+    :keyword: MUST
+
+    The xNF **MUST** be installed with Chef-Client >= 12.0 and Chef
+    push jobs client >= 2.0.
 
 Chef Roles/Requirements
 ++++++++++++++++++++++++++
 
-* R-27310 The xNF Package **MUST** include all relevant Chef artifacts
-  (roles/cookbooks/recipes) required to execute xNF actions requested by
-  ONAP for loading on appropriate Chef Server.
-* R-26567 The xNF Package **MUST** include a run list of
-  roles/cookbooks/recipes, for each supported xNF action, that will
-  perform the desired xNF action in its entirety as specified by ONAP
-  (see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF
-  actions and requirements), when triggered by a chef-client run list
-  in JSON file.
-* R-98911 The xNF **MUST NOT** use any instance specific parameters
-  for the xNF in roles/cookbooks/recipes invoked for a xNF action.
-* R-37929 The xNF **MUST** accept all necessary instance specific
-  data from the environment or node object attributes for the xNF
-  in roles/cookbooks/recipes invoked for a xNF action.
-* R-62170 The xNF **MUST** over-ride any default values for
-  configurable parameters that can be set by ONAP in the roles,
-  cookbooks and recipes.
-* R-78116 The xNF **MUST** update status on the Chef Server
-  appropriately (e.g., via a fail or raise an exception) if the
-  chef-client run encounters any critical errors/failures when
-  executing a xNF action.
-* R-44013 The xNF **MUST** populate an attribute, defined as node
-  [‘PushJobOutput’] with the desired output on all nodes in the push job
-  that execute chef-client run if the xNF action requires the output of a
-  chef-client run be made available (e.g., get running configuration).
-* R-30654 The xNF Package **MUST** have appropriate cookbooks that are
-  designed to automatically ‘rollback’ to the original state in case of
-  any errors for actions that change state of the xNF (e.g., configure).
-* R-65755 The xNF **SHOULD** support callback URLs to return information
-  to ONAP upon completion of the chef-client run for any chef-client run
-  associated with a xNF action.
-
--  As part of the push job, ONAP will provide two parameters in the
-   environment of the push job JSON object:
-
-    -  ‘RequestId’ a unique Id to be used to identify the request,
-    -  ‘CallbackUrl’, the URL to post response back.
-
--  If the CallbackUrl field is empty or missing in the push job, then
-   the chef-client run need not post the results back via callback.
-
-* R-15885 The xNF **MUST** Upon completion of the chef-client run,
-  POST back on the callback URL, a JSON object as described in Table
-  A2 if the chef-client run list includes a cookbook/recipe that is
-  callback capable. Failure to POST on the Callback Url should not be
-  considered a critical error. That is, if the chef-client successfully
-  completes the xNF action, it should reflect this status on the Chef
-  Server regardless of whether the Callback succeeded or not.
+
+.. req::
+    :id: R-27310    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include all relevant Chef artifacts
+    (roles/cookbooks/recipes) required to execute xNF actions requested by
+    ONAP for loading on appropriate Chef Server.
+
+.. req::
+    :id: R-26567    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include a run list of
+    roles/cookbooks/recipes, for each supported xNF action, that will
+    perform the desired xNF action in its entirety as specified by ONAP
+    (see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF
+    actions and requirements), when triggered by a chef-client run list
+    in JSON file.
+
+.. req::
+    :id: R-98911    
+    :target: XNF
+    :keyword: MUST NOT
+
+    The xNF **MUST NOT** use any instance specific parameters
+    for the xNF in roles/cookbooks/recipes invoked for a xNF action.
+
+.. req::
+    :id: R-37929    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** accept all necessary instance specific
+    data from the environment or node object attributes for the xNF
+    in roles/cookbooks/recipes invoked for a xNF action.
+
+.. req::
+    :id: R-62170    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** over-ride any default values for
+    configurable parameters that can be set by ONAP in the roles,
+    cookbooks and recipes.
+
+.. req::
+    :id: R-78116    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** update status on the Chef Server
+    appropriately (e.g., via a fail or raise an exception) if the
+    chef-client run encounters any critical errors/failures when
+    executing a xNF action.
+
+.. req::
+    :id: R-44013    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** populate an attribute, defined as node
+    ['PushJobOutput'] with the desired output on all nodes in the push job
+    that execute chef-client run if the xNF action requires the output of a
+    chef-client run be made available (e.g., get running configuration).
+
+.. req::
+    :id: R-30654    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** have appropriate cookbooks that are
+    designed to automatically 'rollback' to the original state in case of
+    any errors for actions that change state of the xNF (e.g., configure).
+
+.. req::
+    :id: R-65755    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** support callback URLs to return information
+    to ONAP upon completion of the chef-client run for any chef-client run
+    associated with a xNF action.
+
+    -  As part of the push job, ONAP will provide two parameters in the
+       environment of the push job JSON object:
+
+        -  "RequestId" a unique Id to be used to identify the request,
+        -  "CallbackUrl", the URL to post response back.
+
+    -  If the CallbackUrl field is empty or missing in the push job, then
+       the chef-client run need not post the results back via callback.
+
+.. req::
+    :id: R-15885    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** Upon completion of the chef-client run,
+    POST back on the callback URL, a JSON object as described in Table
+    A2 if the chef-client run list includes a cookbook/recipe that is
+    callback capable. Failure to POST on the Callback Url should not be
+    considered a critical error. That is, if the chef-client successfully
+    completes the xNF action, it should reflect this status on the Chef
+    Server regardless of whether the Callback succeeded or not.
 
 ONAP Chef API Usage
 ~~~~~~~~~~~~~~~~~~~
@@ -663,37 +1236,73 @@ VNF Configuration via Ansible Requirements
 Ansible Client Requirements
 +++++++++++++++++++++++++++++
 
-* R-32217 The xNF **MUST** have routable FQDNs that are reachable via
-  the Ansible Server for the endpoints (VMs) of a xNF on which playbooks
-  will be executed. ONAP will initiate requests to the Ansible Server
-  for invocation of playbooks against these end points [3]_.
-* R-54373 The xNF **MUST** have Python >= 2.6 on the endpoint VM(s)
-  of a xNF on which an Ansible playbook will be executed.
-* R-35401 The xNF **MUST** support SSH and allow SSH access by the
-  Ansible server for the endpoint VM(s) and comply with the Network
-  Cloud Service Provider guidelines for authentication and access.
-* R-82018 The xNF **MUST** load the Ansible Server SSH public key onto xNF
-  VM(s) as part
-  of instantiation. This will allow the Ansible Server to authenticate
-  to perform post-instantiation configuration without manual intervention
-  and without requiring specific xNF login IDs and passwords.
-
- CAUTION: For VNFs configured using Ansible, to eliminate the need
- for manual steps, post-instantiation and pre-configuration, to upload
- of SSH public keys, SSH public keys loaded during (heat) instantiation shall
- be preserved and not removed by (heat) embedded (userdata) scripts.
-
-* R-92866 The xNF **MUST** include as part of post-instantiation configuration
-  done by Ansible Playbooks the removal/update of the SSH public key from
-  /root/.ssh/authorized_keys, and  update of SSH keys loaded through
-  instantiation to support Ansible. This may include download and install of
-  new SSH keys and new mechanized IDs.
-* R-91745 The xNF **MUST** update the Ansible Server and other entities
-  storing and using the SSH keys for authentication when the SSH keys used
-  by Ansible are regenerated/updated.
-
-  NOTE: Ansible Server itself may be used to upload new SSH public keys
-  onto supported VNFs.
+
+.. req::
+    :id: R-32217    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have routable FQDNs that are reachable via
+    the Ansible Server for the endpoints (VMs) of a xNF on which playbooks
+    will be executed. ONAP will initiate requests to the Ansible Server
+    for invocation of playbooks against these end points [3]_.
+
+.. req::
+    :id: R-54373    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have Python >= 2.6 on the endpoint VM(s)
+    of a xNF on which an Ansible playbook will be executed.
+
+.. req::
+    :id: R-35401    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support SSH and allow SSH access by the
+    Ansible server for the endpoint VM(s) and comply with the Network
+    Cloud Service Provider guidelines for authentication and access.
+
+.. req::
+    :id: R-82018    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** load the Ansible Server SSH public key onto xNF
+    VM(s) as part of instantiation. This will allow the Ansible Server
+    to authenticate to perform post-instantiation configuration without
+    manual intervention and without requiring specific xNF login IDs and
+    passwords.
+
+    CAUTION: For VNFs configured using Ansible, to eliminate the need
+    for manual steps, post-instantiation and pre-configuration, to
+    upload of SSH public keys, SSH public keys loaded during (heat)
+    instantiation shall be preserved and not removed by (heat) embedded
+    (userdata) scripts.
+
+.. req::
+    :id: R-92866    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** include as part of post-instantiation configuration
+    done by Ansible Playbooks the removal/update of the SSH public key from
+    /root/.ssh/authorized_keys, and  update of SSH keys loaded through
+    instantiation to support Ansible. This may include download and install of
+    new SSH keys and new mechanized IDs.
+
+.. req::
+    :id: R-91745    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** update the Ansible Server and other entities
+    storing and using the SSH keys for authentication when the SSH
+    keys used by Ansible are regenerated/updated.
+
+    Note: Ansible Server itself may be used to upload new SSH public
+    keys onto supported VNFs.
 
 Ansible Playbook Requirements
 +++++++++++++++++++++++++++++++
@@ -702,21 +1311,44 @@ An Ansible playbook is a collection of tasks that is executed on the
 Ansible server (local host) and/or the target VM (s) in order to
 complete the desired action.
 
-* R-40293 The xNF **MUST** make available playbooks that conform
-  to the ONAP requirement.
-* R-49396 The xNF **MUST** support each ONAP (APPC) xNF action
-  by invocation of **one** playbook [4]_. The playbook will be responsible
-  for executing
-  all necessary tasks (as well as calling other playbooks) to complete
-  the request.
-* R-33280 The xNF **MUST NOT** use any instance specific parameters
-  in a playbook.
-* R-48698 The xNF **MUST** utilize information from key value pairs
-  that will be provided by the Ansible Server as "extra-vars" during
-  invocation to execute the desired xNF action. If the playbook requires
-  files, they must also be supplied using the methodology detailed in
-  the Ansible Server API, unless they are bundled with playbooks, example,
-  generic templates.
+
+.. req::
+    :id: R-40293    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** make available playbooks that conform
+    to the ONAP requirement.
+
+.. req::
+    :id: R-49396    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support each ONAP (APPC) xNF action
+    by invocation of **one** playbook [4]_. The playbook will be responsible
+    for executing all necessary tasks (as well as calling other playbooks)
+    to complete the request.
+
+.. req::
+    :id: R-33280    
+    :target: XNF
+    :keyword: MUST NOT
+
+    The xNF **MUST NOT** use any instance specific parameters
+    in a playbook.
+
+.. req::
+    :id: R-48698    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** utilize information from key value pairs
+    that will be provided by the Ansible Server as "extra-vars" during
+    invocation to execute the desired xNF action. If the playbook requires
+    files, they must also be supplied using the methodology detailed in
+    the Ansible Server API, unless they are bundled with playbooks, example,
+    generic templates.
 
 The Ansible Server will determine if a playbook invoked to execute a
 xNF action finished successfully or not using the “PLAY_RECAP” summary
@@ -725,82 +1357,118 @@ only if the “PLAY RECAP” section at the end of playbook execution output
 has no unreachable hosts and no failed tasks. Otherwise, the playbook
 will be considered to have failed.
 
-* R-43253 The xNF **MUST** use playbooks designed to allow Ansible
-  Server to infer failure or success based on the “PLAY_RECAP” capability.
-  NOTE: There are cases where playbooks need to interpret results of a task
-  and then determine success or failure and return result accordingly
-  (failure for failed tasks).
-* R-50252 The xNF **MUST** write to a specific one text files that
-  will be retrieved and made available by the Ansible Server if, as part
-  of a xNF action (e.g., audit), a playbook is required to return any
-  xNF information. The text files must be written in the same directory as
-  the one from which the playbook is being executed. A text file must be
-  created for the xNF playbook run targets/affects, with the name
-  ‘<VNFname>_results.txt’ into which any desired output from each
-  respective VM/xNF must be written.
-* R-51442 The xNF **SHOULD** use playbooks that are designed to
-  automatically ‘rollback’ to the original state in case of any errors
-  for actions that change state of the xNF (e.g., configure).
-
- NOTE: In case rollback at the playbook level is not supported or possible,
- the xNF provider shall provide alternative locking mechanism (e.g., for a
- small xNF the rollback mechanism may rely on workflow to terminate and
- re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated
- files also recommended to support rollback when soft rollback is feasible.
-
-* R-58301 The xNF **SHOULD NOT** use playbooks that make requests to
-  Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.);
-  therefore, there is no use for Cloud specific variables like Openstack
-  UUIDs in Ansible Playbooks.
-
- Rationale: Flows that require interactions with Cloud services
- e.g. Openstack shall rely on workflows run by an Orchestrator
- (Change Management) or
- other capability (such as a control loop or Operations GUI) outside
- Ansible Server which can be executed by a Controller such as APPC.
- There are policies, as part of Control Loop models, that send remediation
- action requests to APPC; these are triggered as a response to an event
- or correlated events published to Event Bus.
-
-* R-02651 The xNF **SHOULD** use the Ansible backup feature to save a
-  copy of configuration files before implementing changes to support
-  operations such as backing out of software upgrades, configuration
-  changes or other work as this will help backing out of configuration
-  changes when needed.
-* R-43353 The xNF **MUST** return control from Ansible Playbooks only
-  after tasks are fully complete, signaling that the playbook completed
-  all tasks. When starting services, return control only after all services
-  are up. This is critical for workflows where the next steps are dependent
-  on prior tasks being fully completed.
-
- Detailed examples:
-
- StopApplication Playbook – StopApplication Playbook shall return control
- and a completion status only after VNF application is fully stopped, all
- processes/services stopped.
- StartApplication Playbook – StartApplication Playbook shall return control
- and a completion status only after all VNF application services are fully up,
- all processes/services started and ready to provide services. NOTE: Start
- Playbook should not be declared complete/done after starting one or several
- processes that start the other processes.
-
- HealthCheck Playbook:
-
- SUCCESS – HealthCheck success shall be returned (return code 0) by a
- Playbook or Cookbook only when VNF is 100% healthy, ready to take requests
- and provide services, with all VNF required capabilities ready to provide
- services and with all active and standby resources fully ready with no
- open MINOR, MAJOR or CRITICAL alarms.
-
- NOTE: In some cases, a switch may need to be turned on, but a VNF
- reported as healthy, should be ready to take service requests or be
- already processing service requests successfully.
-
- A successful execution of a health-check playbook shall also create one
- file per VNF VM, named after the VNF instance name followed by
- “_results.txt (<vnf_instance>_results.txt) to indicate health-check was
- executed and completed successfully, example: vfdb9904v_results.txt,
- with the following contents:
+
+.. req::
+    :id: R-43253    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** use playbooks designed to allow Ansible
+    Server to infer failure or success based on the "PLAY_RECAP" capability.
+
+    Note: There are cases where playbooks need to interpret results
+    of a task and then determine success or failure and return result
+    accordingly (failure for failed tasks).
+
+.. req::
+    :id: R-50252    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** write to a specific one text files that
+    will be retrieved and made available by the Ansible Server if, as part
+    of a xNF action (e.g., audit), a playbook is required to return any
+    xNF information. The text files must be written in the same directory as
+    the one from which the playbook is being executed. A text file must be
+    created for the xNF playbook run targets/affects, with the name
+    '<VNFname>_results.txt' into which any desired output from each
+    respective VM/xNF must be written.
+
+.. req::
+    :id: R-51442    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** use playbooks that are designed to
+    automatically 'rollback' to the original state in case of any errors
+    for actions that change state of the xNF (e.g., configure).
+
+        Note: In case rollback at the playbook level is not supported or
+        possible, the xNF provider shall provide alternative locking
+        mechanism (e.g., for a small xNF the rollback mechanism may rely
+        on workflow to terminate and re-instantiate VNF VMs and then re-run
+        playbook(s)). Backing up updated files also recommended to support
+        rollback when soft rollback is feasible.
+
+.. req::
+    :id: R-58301    
+    :target: XNF
+    :keyword: SHOULD NOT
+
+    The xNF **SHOULD NOT** use playbooks that make requests to
+    Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.);
+    therefore, there is no use for Cloud specific variables like Openstack
+    UUIDs in Ansible Playbooks.
+
+    Rationale: Flows that require interactions with Cloud services e.g.
+    Openstack shall rely on workflows run by an Orchestrator
+    (Change Management) or other capability (such as a control loop or
+    Operations GUI) outside Ansible Server which can be executed by a
+    Controller such as APPC. There are policies, as part of Control Loop
+    models, that send remediation action requests to APPC; these are
+    triggered as a response to an event or correlated events published
+    to Event Bus.
+
+.. req::
+    :id: R-02651    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** use the Ansible backup feature to save a
+    copy of configuration files before implementing changes to support
+    operations such as backing out of software upgrades, configuration
+    changes or other work as this will help backing out of configuration
+    changes when needed.
+
+.. req::
+    :id: R-43353    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** return control from Ansible Playbooks only
+    after tasks are fully complete, signaling that the playbook completed
+    all tasks. When starting services, return control only after all services
+    are up. This is critical for workflows where the next steps are dependent
+    on prior tasks being fully completed.
+
+Detailed examples:
+
+StopApplication Playbook – StopApplication Playbook shall return control
+and a completion status only after VNF application is fully stopped, all
+processes/services stopped.
+StartApplication Playbook – StartApplication Playbook shall return control
+and a completion status only after all VNF application services are fully up,
+all processes/services started and ready to provide services. NOTE: Start
+Playbook should not be declared complete/done after starting one or several
+processes that start the other processes.
+
+HealthCheck Playbook:
+
+SUCCESS – HealthCheck success shall be returned (return code 0) by a
+Playbook or Cookbook only when VNF is 100% healthy, ready to take requests
+and provide services, with all VNF required capabilities ready to provide
+services and with all active and standby resources fully ready with no
+open MINOR, MAJOR or CRITICAL alarms.
+
+NOTE: In some cases, a switch may need to be turned on, but a VNF
+reported as healthy, should be ready to take service requests or be
+already processing service requests successfully.
+
+A successful execution of a health-check playbook shall also create one
+file per VNF VM, named after the VNF instance name followed by
+“_results.txt (<vnf_instance>_results.txt) to indicate health-check was
+executed and completed successfully, example: vfdb9904v_results.txt,
+with the following contents:
 
 .. code-block:: java
 
@@ -822,19 +1490,19 @@ Example:
   }
 ..
 
- FAILURE – A health check playbook shall return a non-zero return code in
- case VNF is not 100% healthy because one or more VNF application processes
- are stopped or not ready to take service requests or because critical or
- non-critical resources are not ready or because there are open MINOR, MAJOR
- or CRITICAL traps/alarms or because there are issues with the VNF that
- need attention even if they do not impact services provided by the VNF.
+FAILURE – A health check playbook shall return a non-zero return code in
+case VNF is not 100% healthy because one or more VNF application processes
+are stopped or not ready to take service requests or because critical or
+non-critical resources are not ready or because there are open MINOR, MAJOR
+or CRITICAL traps/alarms or because there are issues with the VNF that
+need attention even if they do not impact services provided by the VNF.
 
- A failed health-check playbook shall also create one file per VNF,
- named after the VNF instance name, followed by
- “_results.txt to indicate health-check was executed and found issues
- in the health of the VNF. This is to differentiate from failure to
- run health-check playbook or playbook tasks to verify the health of the VNF,
- example: vfdb9904v_results.txt, with the following contents:
+A failed health-check playbook shall also create one file per VNF,
+named after the VNF instance name, followed by
+“_results.txt to indicate health-check was executed and found issues
+in the health of the VNF. This is to differentiate from failure to
+run health-check playbook or playbook tasks to verify the health of the VNF,
+example: vfdb9904v_results.txt, with the following contents:
 
 .. code-block:: java
 
@@ -851,7 +1519,7 @@ Example:
  }
 ..
 
- Example:
+Example:
 
 .. code-block:: java
 
@@ -869,7 +1537,9 @@ Example:
  }
 ..
 
- See `VNF REST APIs`_ for additional details on HealthCheck.
+See `VNF REST APIs`_ for additional details on HealthCheck.
+
+
 
 ONAP Controller / Ansible API Usage
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1020,3 +1690,4 @@ Table 8. ONAP Controller APIs and NETCONF Commands
       :width: 4.74in
       :height: 3.3in
 
+
diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst
index a54671f..d8ec148 100644
--- a/docs/Chapter7/Monitoring-And-Management.rst
+++ b/docs/Chapter7/Monitoring-And-Management.rst
@@ -345,9 +345,15 @@ Monitoring & Management Requirements
 VNF telemetry via standardized interface
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-51910 The xNF **MUST** provide all telemetry (e.g., fault event
-  records, syslog records, performance records etc.) to ONAP using the
-  model, format and mechanisms described in this section.
+
+.. req::
+    :id: R-51910    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** provide all telemetry (e.g., fault event
+    records, syslog records, performance records etc.) to ONAP using the
+    model, format and mechanisms described in this section.
 
 Encoding and Serialization
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -357,33 +363,40 @@ Content delivered from VNFs to ONAP is to be encoded and serialized using JSON:
 JSON
 ~~~~~~~~~~~~~~~~~~
 
-* R-19624 The xNF **MUST** encode and serialize content delivered to
-  ONAP using JSON (RFC 7159) plain text format. High-volume data
-  is to be encoded and serialized using `Avro <http://avro.apache.org/>`_, where the Avro [1]_ data format are described using JSON.
-
-  Note:
-
-  - JSON plain text format is preferred for moderate volume data sets
-    (option 1), as JSON has the advantage of having well-understood simple
-    processing and being human-readable without additional decoding. Examples
-    of moderate volume data sets include the fault alarms and performance
-    alerts, heartbeat messages, measurements used for xNF scaling and syslogs.
-  - Binary format using Avro is preferred for high volume data sets
-    (option 2) such as mobility flow measurements and other high-volume
-    streaming events (such as mobility signaling events or SIP signaling)
-    or bulk data, as this will significantly reduce the volume of data
-    to be transmitted. As of the date of this document, all events are
-    reported using plain text JSON and REST.
-  - Avro content is self-documented, using a JSON schema. The JSON schema is
-    delivered along with the data content
-    (http://avro.apache.org/docs/current/ ). This means the presence and
-    position of data fields can be recognized automatically, as well as the
-    data format, definition and other attributes. Avro content can be
-    serialized as JSON tagged text or as binary. In binary format, the
-    JSON schema is included as a separate data block, so the content is
-    not tagged, further compressing the volume. For streaming data, Avro
-    will read the schema when the stream is established and apply the
-    schema to the received content.
+
+.. req::
+    :id: R-19624    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** encode and serialize content delivered to
+    ONAP using JSON (RFC 7159) plain text format. High-volume data
+    is to be encoded and serialized using `Avro <http://avro.apache.org/>`_,
+    where the Avro [1]_ data format are described using JSON.
+
+    Note:
+
+        - JSON plain text format is preferred for moderate volume data sets
+          (option 1), as JSON has the advantage of having well-understood simple
+          processing and being human-readable without additional decoding. Examples
+          of moderate volume data sets include the fault alarms and performance
+          alerts, heartbeat messages, measurements used for xNF scaling and syslogs.
+        - Binary format using Avro is preferred for high volume data sets
+          (option 2) such as mobility flow measurements and other high-volume
+          streaming events (such as mobility signaling events or SIP signaling)
+          or bulk data, as this will significantly reduce the volume of data
+          to be transmitted. As of the date of this document, all events are
+          reported using plain text JSON and REST.
+        - Avro content is self-documented, using a JSON schema. The JSON schema is
+          delivered along with the data content
+          (http://avro.apache.org/docs/current/ ). This means the presence and
+          position of data fields can be recognized automatically, as well as the
+          data format, definition and other attributes. Avro content can be
+          serialized as JSON tagged text or as binary. In binary format, the
+          JSON schema is included as a separate data block, so the content is
+          not tagged, further compressing the volume. For streaming data, Avro
+          will read the schema when the stream is established and apply the
+          schema to the received content.
 
 In addition to the preferred method (JSON), content can be delivered
 from xNFs to ONAP can be encoded and serialized using Google Protocol
@@ -426,30 +439,37 @@ can be serialized in one of the following methods:
 Reporting Frequency
 ~~~~~~~~~~~~~~~~~~~~~
 
-* R-98191 The xNF **MUST** vary the frequency that asynchronous data
-  is delivered based on the content and how data may be aggregated or
-  grouped together.
-
-  Note:
-
-  - For example, alarms and alerts are expected to be delivered as
-    soon as they appear. In contrast, other content, such as
-    performance measurements, KPIs or reported network signaling may have
-    various ways of packaging and delivering content. Some content should
-    be streamed immediately; or content may be monitored over a time interval,
-    then packaged as collection of records and delivered as block; or data
-    may be collected until a package of a certain size has been collected;
-    or content may be summarized statistically over a time interval, or
-    computed as a KPI, with the summary or KPI being delivered.
-  - We expect the reporting frequency to be configurable depending
-    on the virtual network function’s needs for management. For example,
-    Service Provider may choose to vary the frequency of collection between
-    normal and trouble-shooting scenarios.
-  - Decisions about the frequency of data reporting will affect the
-    size of delivered data sets, recommended delivery method, and how the
-    data will be interpreted by ONAP. These considerations should not
-    affect deserialization and decoding of the data, which will be guided
-    by the accompanying JSON schema or GPB definition files.
+.. req::
+    :id: R-98191    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** vary the frequency that asynchronous data
+    is delivered based on the content and how data may be aggregated or
+    grouped together.
+
+        Note:
+
+        - For example, alarms and alerts are expected to be delivered as
+          soon as they appear. In contrast, other content, such as performance
+          measurements, KPIs or reported network signaling may have various
+          ways of packaging and delivering content. Some content should be
+          streamed immediately; or content may be monitored over a time
+          interval, then packaged as collection of records and delivered
+          as block; or data may be collected until a package of a certain
+          size has been collected; or content may be summarized statistically
+          over a time interval, or computed as a KPI, with the summary or KPI
+          being delivered.
+        - We expect the reporting frequency to be configurable depending on
+          the virtual network functions needs for management. For example,
+          Service Provider may choose to vary the frequency of collection
+          between normal and trouble-shooting scenarios.
+        - Decisions about the frequency of data reporting will affect
+          the size of delivered data sets, recommended delivery method,
+          and how the data will be interpreted by ONAP. These considerations
+          should not affect deserialization and decoding of the data, which
+          will be guided by the accompanying JSON schema or GPB definition
+          files.
 
 Addressing and Delivery Protocol
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -459,87 +479,210 @@ data sets may also be addressed by host name and port number for TCP
 streaming, or by host name and landing zone directory for SFTP transfer
 of bulk files.
 
-* R-88482 The xNF **SHOULD** use REST using HTTPS delivery of plain
-  text JSON for moderate sized asynchronous data sets, and for high
-  volume data sets when feasible.
-* R-84879 The xNF **MUST** have the capability of maintaining a primary
-  and backup DNS name (URL) for connecting to ONAP collectors, with the
-  ability to switch between addresses based on conditions defined by policy
-  such as time-outs, and buffering to store messages until they can be
-  delivered. At its discretion, the service provider may choose to populate
-  only one collector address for a xNF. In this case, the network will
-  promptly resolve connectivity problems caused by a collector or network
-  failure transparently to the xNF.
-* R-81777 The xNF **MUST** be configured with initial address(es) to use
-  at deployment time. Subsequently, address(es) may be changed through
-  ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
-  RESTful API, in the same manner that other controls over data reporting
-  will be controlled by policy.
-* R-08312 The xNF **MAY** use another option which is expected to include REST
-  delivery of binary encoded data sets.
-* R-79412 The xNF **MAY** use another option which is expected to include TCP
-  for high volume streaming asynchronous data sets and for other high volume
-  data sets. TCP delivery can be used for either JSON or binary encoded data
-  sets.
-* R-01033 The xNF **MAY** use another option which is expected to include SFTP
-  for asynchronous bulk files, such as bulk files that contain large volumes of
-  data collected over a long time interval or data collected across many xNFs.
-  (Preferred is to reorganize the data into more frequent or more focused data
-  sets, and deliver these by REST or TCP as appropriate.)
-* R-63229 The xNF **MAY** use another option which is expected to include REST
-  for synchronous data, using RESTCONF (e.g., for xNF state polling).
-* R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
-  as data destinations for each xNF, and may be changed by Policy while
-  the xNF is in operation. We expect the xNF to be capable of redirecting
-  traffic to changed destinations with no loss of data, for example from
-  one REST URL to another, or from one TCP host and port to another.
+.. req::
+    :id: R-88482    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** use REST using HTTPS delivery of plain
+    text JSON for moderate sized asynchronous data sets, and for high
+    volume data sets when feasible.
+
+.. req::
+    :id: R-84879    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have the capability of maintaining a primary
+    and backup DNS name (URL) for connecting to ONAP collectors, with the
+    ability to switch between addresses based on conditions defined by policy
+    such as time-outs, and buffering to store messages until they can be
+    delivered. At its discretion, the service provider may choose to populate
+    only one collector address for a xNF. In this case, the network will
+    promptly resolve connectivity problems caused by a collector or network
+    failure transparently to the xNF.
+
+.. req::
+    :id: R-81777    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** be configured with initial address(es) to use
+    at deployment time. Subsequently, address(es) may be changed through
+    ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
+    RESTful API, in the same manner that other controls over data reporting
+    will be controlled by policy.
+
+.. req::
+    :id: R-08312    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include REST
+    delivery of binary encoded data sets.
+
+.. req::
+    :id: R-79412    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include TCP
+    for high volume streaming asynchronous data sets and for other high volume
+    data sets. TCP delivery can be used for either JSON or binary encoded data
+    sets.
+
+.. req::
+    :id: R-01033    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include SFTP
+    for asynchronous bulk files, such as bulk files that contain large volumes
+    of data collected over a long time interval or data collected across many
+    xNFs. (Preferred is to reorganize the data into more frequent or more focused
+    data sets, and deliver these by REST or TCP as appropriate.)
+
+.. req::
+    :id: R-63229    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include REST
+    for synchronous data, using RESTCONF (e.g., for xNF state polling).
+
+.. req::
+    :id: R-03070    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
+    as data destinations for each xNF, and may be changed by Policy while
+    the xNF is in operation. We expect the xNF to be capable of redirecting
+    traffic to changed destinations with no loss of data, for example from
+    one REST URL to another, or from one TCP host and port to another.
 
 Asynchronous and Synchronous Data Delivery
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-06924 The xNF **MUST** deliver asynchronous data as data becomes
-  available, or according to the configured frequency.
-* R-73285 The xNF **MUST** must encode, address and deliver the data
-  as described in the previous paragraphs.
-* R-42140 The xNF **MUST** respond to data requests from ONAP as soon
-  as those requests are received, as a synchronous response.
-* R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by
-  the ONAP configuration subsystem for synchronous communication.
-* R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF
-  [RFC8040] (https://tools.ietf.org/html/rfc8040).
-* R-11240 The xNF **MUST** respond with content encoded in JSON, as
-  described in the RESTCONF specification. This way the encoding of a
-  synchronous communication will be consistent with Avro.
-* R-70266 The xNF **MUST** respond to an ONAP request to deliver the
-  current data for any of the record types defined in
-  `Event Records - Data Structure Description`_ by returning the requested
-  record, populated with the current field values. (Currently the defined
-  record types include fault fields, mobile flow fields, measurements for
-  xNF scaling fields, and syslog fields. Other record types will be added
-  in the future as they become standardized and are made available.)
-* R-46290 The xNF **MUST** respond to an ONAP request to deliver granular
-  data on device or subsystem status or performance, referencing the YANG
-  configuration model for the xNF by returning the requested data elements.
-* R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG
-  <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
-  translated to and from JSON{RFC7951]. YANG configuration and content can
-  be represented via JSON, consistent with Avro, as described in “Encoding
-  and Serialization” section.
+.. req::
+    :id: R-06924    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** deliver asynchronous data as data becomes
+    available, or according to the configured frequency.
+
+.. req::
+    :id: R-73285    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** must encode, address and deliver the data
+    as described in the previous paragraphs.
+
+.. req::
+    :id: R-42140    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond to data requests from ONAP as soon
+    as those requests are received, as a synchronous response.
+
+.. req::
+    :id: R-34660    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** use the RESTCONF/NETCONF framework used by
+    the ONAP configuration subsystem for synchronous communication.
+
+.. req::
+    :id: R-86586    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** use the YANG configuration models and RESTCONF
+    [RFC8040] (https://tools.ietf.org/html/rfc8040).
+
+.. req::
+    :id: R-11240    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond with content encoded in JSON, as
+    described in the RESTCONF specification. This way the encoding of a
+    synchronous communication will be consistent with Avro.
+
+.. req::
+    :id: R-70266    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond to an ONAP request to deliver the
+    current data for any of the record types defined in
+    `Event Records - Data Structure Description`_ by returning the requested
+    record, populated with the current field values. (Currently the defined
+    record types include fault fields, mobile flow fields, measurements for
+    xNF scaling fields, and syslog fields. Other record types will be added
+    in the future as they become standardized and are made available.)
+
+.. req::
+    :id: R-46290    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond to an ONAP request to deliver granular
+    data on device or subsystem status or performance, referencing the YANG
+    configuration model for the xNF by returning the requested data elements.
+
+.. req::
+    :id: R-43327    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** use `Modeling JSON text with YANG
+    <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
+    translated to and from JSON{RFC7951]. YANG configuration and content can
+    be represented via JSON, consistent with Avro, as described in "Encoding
+    and Serialization" section.
 
 Security
 ~~~~~~~~~~
 
-* R-42366 The xNF **MUST** support secure connections and transports such as
-  Transport Layer Security (TLS) protocol
-  [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
-  the best current practices outlined in
-  `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
-* R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation
-  of connections, through secure credentials, log-on and exchange mechanisms.
-* R-47597 The xNF **MUST** carry data in motion only over secure connections.
-* R-68165 The xNF **MUST** encrypt any content containing Sensitive Personal
-  Information (SPI) or certain proprietary data, in addition to applying the
-  regular procedures for securing access and delivery.
+.. req::
+    :id: R-42366    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support secure connections and transports such as
+    Transport Layer Security (TLS) protocol
+    [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
+    the best current practices outlined in
+    `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
+
+.. req::
+    :id: R-44290    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** control access to ONAP and to xNFs, and creation
+    of connections, through secure credentials, log-on and exchange mechanisms.
+
+.. req::
+    :id: R-47597    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** carry data in motion only over secure connections.
+
+.. req::
+    :id: R-68165    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** encrypt any content containing Sensitive Personal
+    Information (SPI) or certain proprietary data, in addition to applying the
+    regular procedures for securing access and delivery.
 
 .. [1]
    This option is not currently supported in ONAP and it is currently
@@ -560,4 +703,3 @@ Security
 .. |image3| image:: Protocol_Buffers_Driven_Model.png
       :width: 4.74in
       :height: 3.3in
-
diff --git a/docs/Chapter7/VNF-On-boarding-and-package-management.rst b/docs/Chapter7/VNF-On-boarding-and-package-management.rst
index 7628aaa..226efd6 100644
--- a/docs/Chapter7/VNF-On-boarding-and-package-management.rst
+++ b/docs/Chapter7/VNF-On-boarding-and-package-management.rst
@@ -27,232 +27,557 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization
 Resource Description
 ^^^^^^^^^^^^^^^^^^^^^^
 
-* R-77707 The xNF provider **MUST** include a Manifest File that
-  contains a list of all the components in the xNF package.
-* R-66070 The xNF Package **MUST** include xNF Identification Data to
-  uniquely identify the resource for a given xNF provider. The identification
-  data must include: an identifier for the xNF, the name of the xNF as was
-  given by the xNF provider, xNF description, xNF provider, and version.
-* R-69565 The xNF Package **MUST** include documentation describing xNF
-  Management APIs, which must include information and tools for ONAP to
-  deploy and configure (initially and ongoing) the xNF application(s)
-  (e.g., NETCONF APIs) which includes a description of configurable
-  parameters for the xNF and whether the parameters can be configured
-  after xNF instantiation.
-* R-00156 The xNF Package **MUST** include documentation describing xNF
-  Management APIs, which must include information and tools for ONAP
-  to monitor the health of the xNF (conditions that require healing
-  and/or scaling responses).
-* R-00068 The xNF Package **MUST** include documentation which includes
-  a description of parameters that can be monitored for the xNF and
-  event records (status, fault, flow, session, call, control plane,
-  etc.) generated by the xNF after instantiation.
-* R-12678 The xNF Package **MUST** include documentation which includes a
-  description of runtime lifecycle events and related actions (e.g.,
-  control responses, tests) which can be performed for the xNF.
-* R-84366 The xNF Package **MUST** include documentation describing
-  xNF Functional APIs that are utilized to build network and
-  application services. This document describes the externally exposed
-  functional inputs and outputs for the xNF, including interface
-  format and protocols supported.
-* R-36280 The xNF provider **MUST** provide documentation describing
-  xNF Functional Capabilities that are utilized to operationalize the
-  xNF and compose complex services.
-* R-98617 The xNF provider **MUST** provide information regarding any
-  dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
+
+.. req::
+    :id: R-77707    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** include a Manifest File that
+    contains a list of all the components in the xNF package.
+
+.. req::
+    :id: R-66070    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include xNF Identification Data to
+    uniquely identify the resource for a given xNF provider. The identification
+    data must include: an identifier for the xNF, the name of the xNF as was
+    given by the xNF provider, xNF description, xNF provider, and version.
+
+.. req::
+    :id: R-69565    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing xNF
+    Management APIs, which must include information and tools for ONAP to
+    deploy and configure (initially and ongoing) the xNF application(s)
+    (e.g., NETCONF APIs) which includes a description of configurable
+    parameters for the xNF and whether the parameters can be configured
+    after xNF instantiation.
+
+.. req::
+    :id: R-00156    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing xNF
+    Management APIs, which must include information and tools for
+    ONAP to monitor the health of the xNF (conditions that require
+    healing and/or scaling responses).
+
+.. req::
+    :id: R-00068    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation which includes
+    a description of parameters that can be monitored for the xNF
+    and event records (status, fault, flow, session, call, control
+    plane, etc.) generated by the xNF after instantiation.
+
+.. req::
+    :id: R-12678    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation which includes a
+    description of runtime lifecycle events and related actions (e.g.,
+    control responses, tests) which can be performed for the xNF.
+
+.. req::
+    :id: R-84366    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing
+    xNF Functional APIs that are utilized to build network and
+    application services. This document describes the externally exposed
+    functional inputs and outputs for the xNF, including interface
+    format and protocols supported.
+
+.. req::
+    :id: R-36280    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide documentation describing
+    xNF Functional Capabilities that are utilized to operationalize the
+    xNF and compose complex services.
+
+.. req::
+    :id: R-98617    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide information regarding any
+    dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
 
 Resource Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-* R-89571 The xNF **MUST** support and provide artifacts for configuration
-  management using at least one of the following technologies;
-  a) Netconf/YANG, b) Chef, or c) Ansible.
 
-  Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
-  are provided separately and must be supported only if the corresponding
-  protocol option is provided by the xNF providor.
+.. req::
+    :id: R-89571    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support and provide artifacts for configuration
+    management using at least one of the following technologies;
+    a) Netconf/YANG, b) Chef, or c) Ansible.
+
+    Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
+    are provided separately and must be supported only if the corresponding
+    protocol option is provided by the xNF providor.
+
 
 Configuration Management via NETCONF/YANG
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-30278 The xNF provider **MUST** provide a Resource/Device YANG model
-  as a foundation for creating the YANG model for configuration. This will
-  include xNF attributes/parameters and valid values/attributes configurable
-  by policy.
+.. req::
+    :id: R-30278    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide a Resource/Device YANG model
+    as a foundation for creating the YANG model for configuration. This will
+    include xNF attributes/parameters and valid values/attributes configurable
+    by policy.
 
 Configuration Management via Chef
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-13390 The xNF provider **MUST** provide cookbooks to be loaded
-  on the appropriate Chef Server.
-* R-18525 The xNF provider **MUST** provide a JSON file for each
-  supported action for the xNF.  The JSON file must contain key value
-  pairs with all relevant values populated with sample data that illustrates
-  its usage. The fields and their description are defined in Tables A1
-  and A2 in the Appendix.
 
- Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
+.. req::
+    :id: R-13390    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide cookbooks to be loaded
+    on the appropriate Chef Server.
+
+.. req::
+    :id: R-18525    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide a JSON file for each
+    supported action for the xNF. The JSON file must contain key value
+    pairs with all relevant values populated with sample data that illustrates
+    its usage. The fields and their description are defined in Tables A1
+    and A2 in the Appendix.
+
+    Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
+
 
 Configuration Management via Ansible
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-75608 The xNF provider **MUST** provide playbooks to be loaded
-  on the appropriate Ansible Server.
-* R-16777 The xNF provider **MUST** provide a JSON file for each
-  supported action for the xNF.  The JSON file must contain key value
-  pairs with all relevant values populated with sample data that illustrates
-  its usage. The fields and their description are defined in Table B1
-  in the Appendix.
-
-* R-46567 The xNF Package **MUST** include configuration scripts
-  for boot sequence and configuration.
-* R-16065 The xNF provider **MUST** provide configurable parameters
-  (if unable to conform to YANG model) including xNF attributes/parameters
-  and valid values, dynamic attributes and cross parameter dependencies
-  (e.g., customer provisioning data).
+
+.. req::
+    :id: R-75608    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide playbooks to be loaded
+    on the appropriate Ansible Server.
+
+.. req::
+    :id: R-16777    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide a JSON file for each
+    supported action for the xNF. The JSON file must contain key value
+    pairs with all relevant values populated with sample data that illustrates
+    its usage. The fields and their description are defined in Table B1
+    in the Appendix.
+
+.. req::
+    :id: R-46567    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include configuration scripts
+    for boot sequence and configuration.
+
+.. req::
+    :id: R-16065    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide configurable parameters
+    (if unable to conform to YANG model) including xNF attributes/parameters
+    and valid values, dynamic attributes and cross parameter dependencies
+    (e.g., customer provisioning data).
 
 Resource Control Loop
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-* R-22888 The xNF provider **MUST** provide documentation for the xNF
-  Policy Description to manage the xNF runtime lifecycle. The document
-  must include a description of how the policies (conditions and actions)
-  are implemented in the xNF.
-* R-01556 The xNF Package **MUST** include documentation describing the
-  fault, performance, capacity events/alarms and other event records
-  that are made available by the xNF.
-* R-16875 The xNF Package **MUST** include documentation which must include
-  a unique identification string for the specific xNF, a description of
-  the problem that caused the error, and steps or procedures to perform
-  Root Cause Analysis and resolve the issue.
-* R-35960 The xNF Package **MUST** include documentation which must include
-  all events, severity level (e.g., informational, warning, error) and
-  descriptions including causes/fixes if applicable for the event.
-* R-42018 The xNF Package **MUST** include documentation which must include
-  all events (fault, measurement for xNF Scaling, Syslogs, State Change
-  and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
-* R-27711 The xNF provider **MUST** provide an XML file that contains a
-  list of xNF error codes, descriptions of the error, and possible
-  causes/corrective action.
-* R-01478 The xNF Package **MUST** include documentation describing all
-  parameters that are available to monitor the xNF after instantiation
-  (includes all counters, OIDs, PM data, KPIs, etc.) that must be
-  collected for reporting purposes.
-* R-73560 The xNF Package **MUST** include documentation about monitoring
-  parameters/counters exposed for virtual resource management and xNF
-  application management.
-* R-90632 The xNF Package **MUST** include documentation about KPIs and
-  metrics that need to be collected at each VM for capacity planning
-  and performance management purposes.
-* R-86235 The xNF Package **MUST** include documentation about the monitoring
-  parameters that must include latencies, success rates, retry rates, load
-  and quality (e.g., DPM) for the key transactions/functions supported by
-  the xNF and those that must be exercised by the xNF in order to perform
-  its function.
-* R-33904 The xNF Package **MUST** include documentation for each KPI, provide
-  lower and upper limits.
-* R-53598 The xNF Package **MUST** include documentation to, when relevant,
-  provide a threshold crossing alert point for each KPI and describe the
-  significance of the threshold crossing.
-* R-69877 The xNF Package **MUST** include documentation for each KPI,
-  identify the suggested actions that need to be performed when a
-  threshold crossing alert event is recorded.
-* R-22680 The xNF Package **MUST** include documentation that describes
-  any requirements for the monitoring component of tools for Network
-  Cloud automation and management to provide these records to components
-  of the xNF.
-* R-33694 The xNF Package **MUST** include documentation to when applicable,
-  provide calculators needed to convert raw data into appropriate reporting
-  artifacts.
-* R-56815 The xNF Package **MUST** include documentation describing
-  supported xNF scaling capabilities and capacity limits (e.g., number
-  of users, bandwidth, throughput, concurrent calls).
-* R-48596 The xNF Package **MUST** include documentation describing
-  the characteristics for the xNF reliability and high availability.
-* R-74763 The xNF provider **MUST** provide an artifact per xNF that contains
-  all of the xNF Event Records supported. The artifact should include
-  reference to the specific release of the xNF Event Stream Common Event
-  Data Model document it is based on. (e.g.,
-  `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
+
+.. req::
+    :id: R-22888    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide documentation for the xNF
+    Policy Description to manage the xNF runtime lifecycle. The document
+    must include a description of how the policies (conditions and actions)
+    are implemented in the xNF.
+
+.. req::
+    :id: R-01556    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing the
+    fault, performance, capacity events/alarms and other event records
+    that are made available by the xNF.
+
+.. req::
+    :id: R-16875    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation which must include
+    a unique identification string for the specific xNF, a description of
+    the problem that caused the error, and steps or procedures to perform
+    Root Cause Analysis and resolve the issue.
+
+.. req::
+    :id: R-35960    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation which must include
+    all events, severity level (e.g., informational, warning, error) and
+    descriptions including causes/fixes if applicable for the event.
+
+.. req::
+    :id: R-42018    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation which must include
+    all events (fault, measurement for xNF Scaling, Syslogs, State Change
+    and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
+
+.. req::
+    :id: R-27711    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide an XML file that contains a
+    list of xNF error codes, descriptions of the error, and possible
+    causes/corrective action.
+
+.. req::
+    :id: R-01478    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing all
+    parameters that are available to monitor the xNF after instantiation
+    (includes all counters, OIDs, PM data, KPIs, etc.) that must be
+    collected for reporting purposes.
+
+.. req::
+    :id: R-73560    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation about monitoring
+    parameters/counters exposed for virtual resource management and xNF
+    application management.
+
+.. req::
+    :id: R-90632    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation about KPIs and
+    metrics that need to be collected at each VM for capacity planning
+    and performance management purposes.
+
+.. req::
+    :id: R-86235    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation about the monitoring
+    parameters that must include latencies, success rates, retry rates, load
+    and quality (e.g., DPM) for the key transactions/functions supported by
+    the xNF and those that must be exercised by the xNF in order to perform
+    its function.
+
+.. req::
+    :id: R-33904    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation for each KPI, provide
+    lower and upper limits.
+
+.. req::
+    :id: R-53598    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation to, when relevant,
+    provide a threshold crossing alert point for each KPI and describe the
+    significance of the threshold crossing.
+
+.. req::
+    :id: R-69877    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation for each KPI,
+    identify the suggested actions that need to be performed when a
+    threshold crossing alert event is recorded.
+
+.. req::
+    :id: R-22680    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation that describes
+    any requirements for the monitoring component of tools for Network
+    Cloud automation and management to provide these records to components
+    of the xNF.
+
+.. req::
+    :id: R-33694    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation to when applicable,
+    provide calculators needed to convert raw data into appropriate reporting
+    artifacts.
+
+.. req::
+    :id: R-56815    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing
+    supported xNF scaling capabilities and capacity limits (e.g., number
+    of users, bandwidth, throughput, concurrent calls).
+
+.. req::
+    :id: R-48596    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing
+    the characteristics for the xNF reliability and high availability.
+
+.. req::
+    :id: R-74763    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide an artifact per xNF that contains
+    all of the xNF Event Records supported. The artifact should include
+    reference to the specific release of the xNF Event Stream Common Event
+    Data Model document it is based on. (e.g.,
+    `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
 
 Compute, Network, and Storage Requirements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-* R-35851 The xNF Package **MUST** include xNF topology that describes
-  basic network and application connectivity internal and external to the
-  xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
-  applicable) for each interface.
-* R-97102 The VNF Package **MUST** include VM requirements via a Heat
-  template that provides the necessary data for VM specifications
-  for all VNF components - for hypervisor, CPU, memory, storage.
-* R-20204 The VNF Package **MUST** include VM requirements via a Heat
-  template that provides the necessary data for network connections,
-  interface connections, internal and external to VNF.
-* R-44896 The VNF Package **MUST** include VM requirements via a Heat
-  template that provides the necessary data for high availability
-  redundancy model.
-* R-55802 The VNF Package **MUST** include VM requirements via a Heat
-  template that provides the necessary data for scaling/growth VM
-  specifications.
-
-  Note: Must comply with the *Heat requirements in 5.b*.
-
-* R-26881 The xNF provider **MUST** provide the binaries and images
-  needed to instantiate the xNF (xNF and VNFC images).
-* R-96634 The xNF provider **MUST** describe scaling capabilities
-  to manage scaling characteristics of the xNF.
 
+.. req::
+    :id: R-35851    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include xNF topology that describes
+    basic network and application connectivity internal and external to the
+    xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
+    applicable) for each interface.
+
+.. req::
+    :id: R-97102    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Package **MUST** include VM requirements via a Heat
+    template that provides the necessary data for VM specifications
+    for all VNF components - for hypervisor, CPU, memory, storage.
+
+.. req::
+    :id: R-20204    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Package **MUST** include VM requirements via a Heat
+    template that provides the necessary data for network connections,
+    interface connections, internal and external to VNF.
+
+.. req::
+    :id: R-44896    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Package **MUST** include VM requirements via a Heat
+    template that provides the necessary data for high availability
+    redundancy model.
+
+.. req::
+    :id: R-55802    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF Package **MUST** include VM requirements via a Heat
+    template that provides the necessary data for scaling/growth VM
+    specifications.
+
+    Note: Must comply with the *Heat requirements in 5.b*.
+
+.. req::
+    :id: R-26881    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide the binaries and images
+    needed to instantiate the xNF (xNF and VNFC images).
+
+.. req::
+    :id: R-96634    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** describe scaling capabilities
+    to manage scaling characteristics of the xNF.
 
 Testing
 ^^^^^^^^^^
 
-* R-43958 The xNF Package **MUST** include documentation describing
-  the tests that were conducted by the xNF providor and the test results.
-* R-04298 The xNF provider **MUST** provide their testing scripts to
-  support testing.
-* R-58775 The xNF provider **MUST** provide software components that
-  can be packaged with/near the xNF, if needed, to simulate any functions
-  or systems that connect to the xNF system under test. This component is
-  necessary only if the existing testing environment does not have the
-  necessary simulators.
+
+.. req::
+    :id: R-43958    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF Package **MUST** include documentation describing
+    the tests that were conducted by the xNF providor and the test results.
+
+.. req::
+    :id: R-04298    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide their testing scripts to
+    support testing.
+
+.. req::
+    :id: R-58775    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide software components that
+    can be packaged with/near the xNF, if needed, to simulate any functions
+    or systems that connect to the xNF system under test. This component is
+    necessary only if the existing testing environment does not have the
+    necessary simulators.
 
 Licensing Requirements
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-* R-85653 The xNF **MUST** provide metrics (e.g., number of sessions,
-  number of subscribers, number of seats, etc.) to ONAP for tracking
-  every license.
-* R-44125 The xNF provider **MUST** agree to the process that can
-  be met by Service Provider reporting infrastructure. The Contract
-  shall define the reporting process and the available reporting tools.
-* R-40827 The xNF provider **MUST** enumerate all of the open
-  source licenses their xNF(s) incorporate.
-* R-97293 The xNF provider **MUST NOT** require audits of
-  Service Provider’s business.
-* R-44569 The xNF provider **MUST NOT** require additional
-  infrastructure such as a xNF provider license server for xNF provider
-  functions and metrics.
-* R-13613 The VNF **MUST** provide clear measurements for licensing
-  purposes to allow automated scale up/down by the management system.
-* R-27511 The VNF provider **MUST** provide the ability to scale
-  up a VNF provider supplied product during growth and scale down a
-  VNF provider supplied product during decline without “real-time”
-  restrictions based upon VNF provider permissions.
-* R-85991 The xNF provider **MUST** provide a universal license key
-  per xNF to be used as needed by services (i.e., not tied to a VM
-  instance) as the recommended solution. The xNF provider may provide
-  pools of Unique xNF License Keys, where there is a unique key for
-  each xNF instance as an alternate solution. Licensing issues should
-  be resolved without interrupting in-service xNFs.
-* R-47849 The xNF provider **MUST** support the metadata about
-  licenses (and their applicable entitlements) as defined in this
-  document for xNF software, and any license keys required to authorize
-  use of the xNF software.  This metadata will be used to facilitate
-  onboarding the xNF into the ONAP environment and automating processes
-  for putting the licenses into use and managing the full lifecycle of
-  the licenses. The details of this license model are described in
-  Tables C1 to C8 in the Appendix. Note: License metadata support in
-  ONAP is not currently available and planned for 1Q 2018.
+
+.. req::
+    :id: R-85653    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** provide metrics (e.g., number of sessions,
+    number of subscribers, number of seats, etc.) to ONAP for tracking
+    every license.
+
+.. req::
+    :id: R-44125    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** agree to the process that can
+    be met by Service Provider reporting infrastructure. The Contract
+    shall define the reporting process and the available reporting tools.
+
+.. req::
+    :id: R-40827    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** enumerate all of the open
+    source licenses their xNF(s) incorporate.
+
+.. req::
+    :id: R-97293    
+    :target: XNF
+    :keyword: MUST NOT
+
+    The xNF provider **MUST NOT** require audits
+    of Service Provider's business.
+
+.. req::
+    :id: R-44569    
+    :target: XNF
+    :keyword: MUST NOT
+
+    The xNF provider **MUST NOT** require additional
+    infrastructure such as a xNF provider license server for xNF provider
+    functions and metrics.
+
+.. req::
+    :id: R-13613    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** provide clear measurements for licensing
+    purposes to allow automated scale up/down by the management system.
+
+.. req::
+    :id: R-27511    
+    :target: VNF
+    :keyword: MUST
+
+    The VNF provider **MUST** provide the ability to scale
+    up a VNF provider supplied product during growth and scale down a
+    VNF provider supplied product during decline without "real-time"
+    restrictions based upon VNF provider permissions.
+
+.. req::
+    :id: R-85991    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** provide a universal license key
+    per xNF to be used as needed by services (i.e., not tied to a VM
+    instance) as the recommended solution. The xNF provider may provide
+    pools of Unique xNF License Keys, where there is a unique key for
+    each xNF instance as an alternate solution. Licensing issues should
+    be resolved without interrupting in-service xNFs.
+
+.. req::
+    :id: R-47849    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF provider **MUST** support the metadata about
+    licenses (and their applicable entitlements) as defined in this
+    document for xNF software, and any license keys required to authorize
+    use of the xNF software.  This metadata will be used to facilitate
+    onboarding the xNF into the ONAP environment and automating processes
+    for putting the licenses into use and managing the full lifecycle of
+    the licenses. The details of this license model are described in
+    Tables C1 to C8 in the Appendix.
+
+    Note: License metadata support in ONAP is not currently available
+    and planned for 1Q 2018.
+
 
 .. |image0| image:: Data_Model_For_Event_Records.png
       :width: 7in
@@ -269,4 +594,3 @@ Licensing Requirements
 .. |image3| image:: Protocol_Buffers_Driven_Model.png
       :width: 4.74in
       :height: 3.3in
-