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>

3 files changed, 1885 insertions, 748 deletions

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
-