VNFRQTS - Dynamic footnote generation

Updating footnotes to be generated more dynamically.

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

diff --git a/docs/Chapter4/Design.rst b/docs/Chapter4/Design.rst
index 70f5598..a4288d0 100644 (file)
--- a/docs/Chapter4/Design.rst
+++ b/docs/Chapter4/Design.rst
@@ -162,7 +162,7 @@ VNF Design Requirements
     :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]_
+    flavor that supports DPDK to optimize network efficiency if using DPDK. [#4.1.1]_
 
 .. req::
     :id: R-18864
@@ -191,6 +191,6 @@ VNF Design Requirements
     The VNF **MUST NOT** require the use of a dynamic routing
     protocol unless necessary to meet functional requirements.
 
-.. [1]
+.. [#4.1.1]
    Refer to NCSP’s Network Cloud specification
 

diff --git a/docs/Chapter4/Devops.rst b/docs/Chapter4/Devops.rst
index aabd76f..589e382 100644 (file)
--- a/docs/Chapter4/Devops.rst
+++ b/docs/Chapter4/Devops.rst
@@ -46,14 +46,14 @@ DevOps Requirements
     :keyword: MUST
 
     The VNF **MUST** install the NCSP required software on Guest OS
-    images when not using the NCSP provided Guest OS images. [1]_
+    images when not using the NCSP provided Guest OS images. [#4.5.1]_
 
 .. req::
     :id: R-09467
     :target: VNF
     :keyword: MUST
 
-    The VNF **MUST** utilize only NCSP standard compute flavors. [1]_
+    The VNF **MUST** utilize only NCSP standard compute flavors. [#4.5.1]_
 
 .. req::
     :id: R-02997
@@ -115,7 +115,7 @@ DevOps Requirements
     :target: VNF
     :keyword: MUST
 
-    The VNF **MUST** respond to a "move traffic" [2]_ command
+    The VNF **MUST** respond to a "move traffic" [#4.5.2]_ command
     against a specific VNFC, moving all existing session elsewhere with
     minimal disruption if a VNF provides a load balancing function across
     multiple instances of its VNFCs.
@@ -128,7 +128,7 @@ DevOps Requirements
     :target: VNF
     :keyword: MUST
 
-    The VNF **MUST** respond to a "drain VNFC" [2]_ command against
+    The VNF **MUST** respond to a "drain VNFC" [#4.5.2]_ command against
     a specific VNFC, preventing new session from reaching the targeted VNFC,
     with no disruption to active sessions on the impacted VNFC, if a VNF
     provides a load balancing function across multiple instances of its VNFCs.
@@ -145,10 +145,10 @@ DevOps Requirements
     testing and operations.
 
 
-.. [1]
+.. [#4.5.1]
    Refer to NCSP’s Network Cloud specification
 
-.. [2]
+.. [#4.5.2]
    Not currently supported in ONAP release 1
 
 

diff --git a/docs/Chapter7/Configuration-Management.rst b/docs/Chapter7/Configuration-Management.rst
index 8adb330..c650f7a 100644 (file)
--- a/docs/Chapter7/Configuration-Management.rst
+++ b/docs/Chapter7/Configuration-Management.rst
@@ -752,7 +752,7 @@ NETCONF Server Requirements
     :keyword: MUST
 
     The xNF PACKAGE **MUST** validated YANG code using the open
-    source pyang [1]_ program using the following commands:
+    source pyang [#7.3.1]_ program using the following commands:
 
     .. code-block:: python
 
@@ -1182,7 +1182,7 @@ action request against a Chef managed VNF.
 
 3. Next, it creates a Node Object from the “Node” JSON dictionary for
    all elements listed in the NodeList (using the FQDN to construct the
-   endpoint) by replicating it  [2]_. As part of this process, it will
+   endpoint) by replicating it  [#7.3.2]_. As part of this process, it will
    set the name field in each Node Object to the corresponding FQDN.
    These node objects are then posted on the Chef Server to
    corresponding Node Object REST endpoints to update the corresponding
@@ -1245,7 +1245,7 @@ Ansible Client Requirements
     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]_.
+    for invocation of playbooks against these end points [#7.3.3]_.
 
 .. req::
     :id: R-54373    
@@ -1326,7 +1326,7 @@ complete the desired action.
     :keyword: MUST
 
     The xNF **MUST** support each ONAP (APPC) xNF action
-    by invocation of **one** playbook [4]_. The playbook will be responsible
+    by invocation of **one** playbook [#7.3.4]_. The playbook will be responsible
     for executing all necessary tasks (as well as calling other playbooks)
     to complete the request.
 
@@ -1660,18 +1660,18 @@ Table 8. ONAP Controller APIs and NETCONF Commands
 |             |                    |                    |results.            |
 +-------------+--------------------+--------------------+--------------------+
 
-.. [1]
+.. [#7.3.1]
    https://github.com/mbj4668/pyang
 
-.. [2]
+.. [#7.3.2]
    Recall that the Node Object **is required** to be identical across
    all VMs of a VNF invoked as part of the action except for the “name”.
 
-.. [3]
+.. [#7.3.3]
    Upstream elements must provide the appropriate FQDN in the request to
    ONAP for the desired action.
 
-.. [4]
+.. [#7.3.4]
    Multiple ONAP actions may map to one playbook.
 
 

diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst
index 38edab8..4ef2eae 100644 (file)
--- a/docs/Chapter7/Monitoring-And-Management.rst
+++ b/docs/Chapter7/Monitoring-And-Management.rst
@@ -372,7 +372,7 @@ JSON
     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.
+    where the Avro [#7.4.1]_ data format are described using JSON.
 
     Note:
 
@@ -684,7 +684,7 @@ Security
     Information (SPI) or certain proprietary data, in addition to applying the
     regular procedures for securing access and delivery.
 
-.. [1]
+.. [#7.4.1]
    This option is not currently supported in ONAP and it is currently
    under consideration.
 

diff --git a/docs/Chapter8/Chef-JSON-Key-Value-Description.rst b/docs/Chapter8/Chef-JSON-Key-Value-Description.rst
index 7144159..8a51a85 100644 (file)
--- a/docs/Chapter8/Chef-JSON-Key-Value-Description.rst
+++ b/docs/Chapter8/Chef-JSON-Key-Value-Description.rst
@@ -127,7 +127,7 @@ a. The JSON file must be created for each action for each VNF.
 b. If a VNF action involves multiple endpoints (VMs) of a VNF, ONAP will
    replicate the “Node” JSON dictionary in the template and post it to
    each FQDN (i.e., endpoint) in the NodeList after setting the “name”
-   field in the Node object to be the respective FQDN [1]_. Hence, it
+   field in the Node object to be the respective FQDN [#8.1.1]_. Hence, it
    is required that all end points (VMs) of a VNF involved in a VNF
    action support the same set of Node Object attributes.
 
@@ -173,6 +173,6 @@ Table A2. JSON Dictionary to Post in Callback
 |              | to be returned to ONAP.    |         | be included.          |
 +--------------+----------------------------+---------+-----------------------+
 
-.. [1]
+.. [#8.1.1]
    The “name” field is a mandatory field in a valid Chef Node Object
    JSON dictionary.