VNFRQTS - Testing Chapter 4 with new directive

Test push to see if the new directive introduced will build properly.

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

1 files changed, 164 insertions, 50 deletions

diff --git a/docs/Chapter4/Design.rst b/docs/Chapter4/Design.rst
index e9003e6..35acd65 100644
--- a/docs/Chapter4/Design.rst
+++ b/docs/Chapter4/Design.rst
@@ -26,57 +26,171 @@ Below are more detailed requirements for composing VNFs.
 
 VNF Design Requirements
 
-* R-58421 The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
-* R-82223 The VNF **MUST** be decomposed if the functions have
-  significantly different scaling characteristics (e.g., signaling
-  versus media functions, control versus data plane functions).
-* R-16496 The VNF **MUST** enable instantiating only the functionality that
-  is needed for the decomposed VNF (e.g., if transcoding is not needed it
-  should not be instantiated).
-* R-02360 The VNFC **MUST** be designed as a standalone, executable process.
-* R-34484 The VNF **SHOULD** create a single component VNF for VNFCs
-  that can be used by other VNFs.
-* R-23035 The VNF **MUST** be designed to scale horizontally (more
-  instances of a VNF or VNFC) and not vertically (moving the existing
-  instances to larger VMs or increasing the resources within a VM)
-  to achieve effective utilization of cloud resources.
-* R-30650 The VNF **MUST** utilize cloud provided infrastructure and
-  VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so
-  that the cloud can manage and provide a consistent service resiliency
-  and methods across all VNF's.
-* R-12709 The VNFC **SHOULD** be independently deployed, configured,
-  upgraded, scaled, monitored, and administered by ONAP.
-* R-37692 The VNFC **MUST** provide API versioning to allow for
-  independent upgrades of VNFC.
-* R-86585 The VNFC **SHOULD** minimize the use of state within
-  a VNFC to facilitate the movement of traffic from one instance
-  to another.
-* R-65134 The VNF **SHOULD** maintain state in a geographically
-  redundant datastore that may, in fact, be its own VNFC.
-* R-75850 The VNF **SHOULD** decouple persistent data from the VNFC
-  and keep it in its own datastore that can be reached by all instances
-  of the VNFC requiring the data.
-* R-88199 The VNF **MUST** utilize a persistent datastore service that
-  can meet the data performance/latency requirements. (For example:
-  Datastore service could be a VNFC in VNF or a DBaaS in the Cloud
-  execution environment)
-* R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC
-  instance fails.
-* R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF’s requiring
-  high packets/sec performance.  High packet throughput is defined as greater
-  than 500K packets/sec.
-* R-54430 The VNF **MUST** use the NCSP’s supported library and compute
-  flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_
-* R-18864 The VNF **MUST** NOT use technologies that bypass virtualization
-  layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary
-  to meet functional or performance requirements).
-* R-64768 The VNF **MUST** limit the size of application data packets
-  to no larger than 9000 bytes for SDN network-based tunneling when
-  guest data packets are transported between tunnel endpoints that
-  support guest logical networks.
-* R-74481 The VNF **MUST** NOT require the use of a dynamic routing
-  protocol unless necessary to meet functional requirements.
 
+.. req::
+    :id: R-58421
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
+
+.. req::
+    :id: R-82223
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** be decomposed if the functions have
+    significantly different scaling characteristics (e.g., signaling
+    versus media functions, control versus data plane functions).
+
+.. req::
+    :id: R-16496
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** enable instantiating only the functionality that
+    is needed for the decomposed VNF (e.g., if transcoding is not needed it
+    should not be instantiated).
+
+.. req::
+    :id: R-02360
+    :target: VNF
+    :keyword: MUST
+
+    The VNFC **MUST** be designed as a standalone, executable process.
+
+.. req::
+    :id: R-34484
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** create a single component VNF for VNFCs
+    that can be used by other VNFs.
+
+.. req::
+    :id: R-23035
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** be designed to scale horizontally (more
+    instances of a VNF or VNFC) and not vertically (moving the existing
+    instances to larger VMs or increasing the resources within a VM)
+    to achieve effective utilization of cloud resources.
+
+.. req::
+    :id: R-30650
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** utilize cloud provided infrastructure and
+    VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so
+    that the cloud can manage and provide a consistent service resiliency
+    and methods across all VNF's.
+
+.. req::
+    :id: R-12709
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNFC **SHOULD** be independently deployed, configured,
+    upgraded, scaled, monitored, and administered by ONAP.
+
+.. req::
+    :id: R-37692
+    :target: VNF
+    :keyword: MUST
+
+    The VNFC **MUST** provide API versioning to allow for
+    independent upgrades of VNFC.
+
+.. req::
+    :id: R-86585
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNFC **SHOULD** minimize the use of state within
+    a VNFC to facilitate the movement of traffic from one instance
+    to another.
+
+.. req::
+    :id: R-65134
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** maintain state in a geographically
+    redundant datastore that may, in fact, be its own VNFC.
+
+.. req::
+    :id: R-75850
+    :target: VNF
+    :keyword: SHOULD
+
+    The VNF **SHOULD** decouple persistent data from the VNFC
+    and keep it in its own datastore that can be reached by all instances
+    of the VNFC requiring the data.
+
+.. req::
+    :id: R-88199
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** utilize a persistent datastore service that
+    can meet the data performance/latency requirements. (For example:
+    Datastore service could be a VNFC in VNF or a DBaaS in the Cloud
+    execution environment)
+
+.. req::
+    :id: R-99656
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** NOT terminate stable sessions if a VNFC
+    instance fails.
+
+.. req::
+    :id: R-84473
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** enable DPDK in the guest OS for VNF's requiring
+    high packets/sec performance. High packet throughput is defined as greater
+    than 500K packets/sec.
+
+.. req::
+    :id: R-54430
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** use the NCSP's supported library and compute
+    flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_
+
+.. req::
+    :id: R-18864
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** use technologies that bypass virtualization
+    layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary
+    to meet functional or performance requirements).
+
+.. req::
+    :id: R-64768
+    :target: VNF
+    :keyword: MUST
+
+    The VNF **MUST** limit the size of application data packets
+    to no larger than 9000 bytes for SDN network-based tunneling when
+    guest data packets are transported between tunnel endpoints that
+    support guest logical networks.
+
+.. req::
+    :id: R-74481
+    :target: VNF
+    :keyword: MUST NOT
+
+    The VNF **MUST NOT** require the use of a dynamic routing
+    protocol unless necessary to meet functional requirements.
 
 .. [1]
    Refer to NCSP’s Network Cloud specification
+