VNFRQTS - Requirement IDs

VNFRQTS - Added new ids to new requirements

Change-Id: I4d73e989f8b42fce113e5d423a37e0f7c23ae8e2
Issue-ID: VNFRQTS-98
Signed-off-by: rr929y <rr929y@att.com>

2 files changed, 11 insertions, 11 deletions

diff --git a/docs/Chapter4.rst b/docs/Chapter4.rst
index 76907d0..2d823c7 100644
--- a/docs/Chapter4.rst
+++ b/docs/Chapter4.rst
@@ -540,9 +540,9 @@ activity).
 
 * R-11200 The VNF MUST keep the scope of a Cinder volume module, when it exists, to be 1:1 with the VNF Base Module or Incremental Module.
 
-* R-nnnnn The VNF MUST have a corresponding environment file for a Base Module.
-* R-nnnnn The VNF MUST have a corresponding environment file for an Incremental Module.
-* R-nnnnn The VNF MUST have a corresponding environment file for a Cinder Volume Module.
+* R-38474 The VNF MUST have a corresponding environment file for a Base Module.
+* R-81725 The VNF MUST have a corresponding environment file for an Incremental Module.
+* R-53433 The VNF MUST have a corresponding environment file for a Cinder Volume Module.
 
 These concepts will be described in more detail throughout the document.
 This overview is provided to set the stage and help clarify the concepts
@@ -863,7 +863,7 @@ DevOps Requirements
 
 * R-46960 The VNF **MUST** utilize only the Guest OS versions that are supported by the NCSP’s Network Cloud. [1]_
 * R-23475 The VNF **SHOULD** utilize only NCSP provided Guest OS images. [1]_
-* R-NNNNN The VNF **MUST** install the NCSP required software on Guest OS images when not using the NCSP provided Guest OS images. [1]_
+* R-33846 The VNF **MUST** install the NCSP required software on Guest OS images when not using the NCSP provided Guest OS images. [1]_
 * R-09467 The VNF **MUST**  utilize only NCSP standard compute flavors. [1]_
 * R-02997 The VNF **MUST** preserve their persistent data. Running VMs will not be backed up in the Network Cloud infrastructure.
 * R-29760 The VNFC **MUST** be installed on non-root file systems, unless software is specifically included with the operating system distribution of the guest image.
@@ -873,7 +873,7 @@ DevOps Requirements
 * R-39650 The VNF **SHOULD** provide the ability to test incremental growth of the VNF.
 * R-14853 The VNF **MUST** respond to a "move traffic" [2]_ command against a specific VNFC, moving all existing session elsewhere with minimal disruption if a VNF provides a load balancing function across multiple instances of its VNFCs. Note: Individual VNF performance aspects (e.g., move duration or disruption scope) may require further constraints.
 * R-06327 The VNF **MUST** respond to a "drain VNFC" [2]_ command against a specific VNFC, preventing new session from reaching the targeted VNFC, with no disruption to active sessions on the impacted VNFC, if a VNF provides a load balancing function across multiple instances of its VNFCs. This is used to support scenarios such as proactive maintenance with no user impact.
-* R-NNNNN The VNF **SHOULD** support a software promotion methodology from dev/test -> pre-prod -> production in software, development & testing and operations. 
+* R-64713 The VNF **SHOULD** support a software promotion methodology from dev/test -> pre-prod -> production in software, development & testing and operations. 
 
 f. VNF Develop Steps
 =======================
diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst
index b4e164c..df862e1 100644
--- a/docs/Chapter7.rst
+++ b/docs/Chapter7.rst
@@ -421,12 +421,12 @@ will host and run playbooks to manage VNFs that support Ansible.
 * R-32217 The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF 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 VNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a VNF on which an Ansible playbook will be executed.
 * R-35401 The VNF **MUST** support SSH and allow SSH access to the Ansible server for the endpoint VM(s) and comply with the  Network Cloud Service Provider guidelines for authentication and access.
-* R-NNNNN The VNF **SHOULD** load the SSH key onto VNF 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 VNF login IDs and passwords.
+* R-82018 The VNF **SHOULD** load the SSH key onto VNF 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 VNF 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 keys, SSH keys loaded during (heat) instantiation shall be preserved and not removed by (heat) embedded scripts. 
 
-* R-NNNNN The VNF **MUST** include as part of post-instantiation configuration done by Ansible Playbooks the removal/update of SSH keys loaded through instantiation to support Ansible. This may include download and install of new SSH keys.
-* R-NNNNN The VNF **MUST** update the Ansible Server and other entities storing and using the SSH key for authentication when the SSH key used by Ansible is regenerated/updated.
+* R-92866 The VNF **MUST** include as part of post-instantiation configuration done by Ansible Playbooks the removal/update of SSH keys loaded through instantiation to support Ansible. This may include download and install of new SSH keys.
+* R-91745 The VNF **MUST** update the Ansible Server and other entities storing and using the SSH key for authentication when the SSH key used by Ansible is regenerated/updated.
 
 **Ansible Playbook Requirements**
 
@@ -445,12 +445,12 @@ The Ansible Server will determine if a playbook invoked to execute a VNF action
 
  NOTE: In case rollback at the playbook level is not supported or possible, the VNF provider shall provide alternative locking mechanism (e.g., for a small VNF 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-NNNNN The VNF **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.
+* R-58301 The VNF **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 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-NNNNN The VNF **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-NNNNN The VNF **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.
+* R-02651 The VNF **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 VNF **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: