VNFRQTS - Correcting initial release info 99/57899/1
authorBozawglanian, Hagop (hb755d) <hb755d@att.com>
Fri, 27 Jul 2018 19:16:26 +0000 (19:16 +0000)
committerBozawglanian, Hagop (hb755d) <hb755d@att.com>
Fri, 27 Jul 2018 19:17:54 +0000 (19:17 +0000)
Removing references to initial release of ONAP from Open-O and OpenECOMP.

Change-Id: I749cfdf449d243720d47314525dd94a9fded16e1
Issue-ID: VNFRQTS-280
Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>
docs/Chapter1/index.rst
docs/Chapter3/index.rst
docs/Chapter4/Design.rst
docs/Chapter4/Devops.rst
docs/Chapter4/Resiliency.rst
docs/Chapter4/Security.rst

index a0b917e..f738542 100644 (file)
@@ -9,10 +9,9 @@ Purpose
   practices which will increase innovation, minimize customization needed to
   onboard xNFs as well as reduce implementation complexity, time and cost
   for all impacted stakeholders.
-- This initial release consolidates the requirements from Open-O and OpenECOMP
-  to provide common xNF requirements across the industry in order to drive
-  interoperability, simplify management, and reduce cost to build, deploy and
-  manage xNFs.
+- The consolidated requirements provide common xNF requirements across
+  the industry in order to drive interoperability, simplify management, and
+  reduce cost to build, deploy and manage xNFs.
 - These requirements serve multiple purposes:
     - Primarily it provides a detailed list of requirements for xNF
       providers to meet to be compatible with ONAP; xNF providers will use
index 84802f7..d63023e 100644 (file)
@@ -6,9 +6,6 @@
 Introduction
 ============
 
-- These requirements are specific to the current release of ONAP.
-  It is the initial release of requirements based on a merge of the Open-O
-  and OpenECOMP requirements.
 - Requirements are identified as either MUST, MUST NOT, SHOULD, SHOULD NOT,
   or MAY as defined in RFC 2119.
 - Requirements should be targeted to a restricted set of nouns related
index 35acd65..70f5598 100644 (file)
@@ -20,7 +20,7 @@ grouping functions in a common cloud data center to minimize
 inter-component latency. The VNFs should be designed with a goal of
 being modular and reusable to enable using best-in-breed vendors.
 
-Section 5.a VNF Design in *VNF Guidelines* describes
+Section 4.1 VNF Design in *VNF Guidelines* describes
 the overall guidelines for designing VNFs from VNF Components (VNFCs).
 Below are more detailed requirements for composing VNFs.
 
index c333523..aabd76f 100644 (file)
@@ -15,7 +15,7 @@ software bundle, VNF suppliers using standard images would typically
 provide the NCSP with an install package consistent with the default OS
 package manager (e.g. aptitude for Ubuntu, yum for Redhat/CentOS).
 
-Section 5.a DevOps in *VNF Guidelines* describes
+Section 4.5 DevOps in *VNF Guidelines* describes
 the DevOps guidelines for VNFs.
 
 DevOps Requirements
index 7047962..8c4bb75 100644 (file)
@@ -16,7 +16,7 @@ Network Cloud, resiliency must be designed into the VNF software to
 provide high availability versus relying on the Network Cloud to achieve
 that end.
 
-Section 5.a Resiliency in *VNF Guidelines* describes
+Section 4.2 Resiliency in *VNF Guidelines* describes
 the overall guidelines for designing VNFs to meet resiliency goals.
 Below are more detailed resiliency requirements for VNFs.
 
index 7ea5612..972d41c 100644 (file)
@@ -13,7 +13,7 @@ to all VNFs. Additional security requirements for specific types of VNFs
 will be applicable and are outside the scope of these general
 requirements.
 
-Section 5.a Security in *VNF Guidelines* outlines
+Section 4.3 Security in *VNF Guidelines* outlines
 the five broad security areas for VNFs that are detailed in the
 following sections: