Remove text about OpenStack securityHEADmaster

1 files changed, 6 insertions, 8 deletions

diff --git a/docs/requirements/02-use_cases.rst b/docs/requirements/02-use_cases.rst
index 828cdab..6d36240 100644
--- a/docs/requirements/02-use_cases.rst
+++ b/docs/requirements/02-use_cases.rst
@@ -8,7 +8,7 @@ introduce versus a typical data center (DC) deployment.
 
 1. vE-CPE.
     [vE-CPE]_ is related to most popular NFV use case where a NFVI compute node is
-    located at customer premises. 
+    located at customer premises.
     Typical applications are virtual firewall and virtual router to replace physical equivalents.
     The service chain can include VNFs hosted in vE-CPE host and/or a centralized data center.
     Complexities include:
@@ -23,7 +23,7 @@ introduce versus a typical data center (DC) deployment.
 
 #. Residential GW.
     Similar to vE-CPE, the major difference is scale. Typical VNFs are "WAN fault monitoring",
-    "Performance monitoring". 
+    "Performance monitoring".
     Ratio between deployed vE-CPE and Residential GW might reach 1:100 or even 1:1000,
     so VNF management overhead must be minimized.
     For instance, self-termination after predefined activity period seems preferable over
@@ -41,19 +41,17 @@ introduce versus a typical data center (DC) deployment.
     If OpenStack is run in a distributed fashion, with a central node controlling distributed
     NFVI servers, the following issues may be seen:
 
-    * Lack of security between OpenStack client and server.
     * Lack of compatibility between different versions of OpenStack.
     * Scalability of OpenStack.
     * Operation in low speed or lossy networks is complicated by the amount of messaging required.
-    * OpenStack communications are not secured. This creates a vulnerability in a distributed application.
-    * OpenStack numbers VNF ports in a sequential manner, with the sequence serially numbered 
-      in the VM/VNF. 
-      The difficulty comes when trying to verify that the LAN has been connected to the correct LAN port, 
+    * OpenStack numbers VNF ports in a sequential manner, with the sequence serially numbered
+      in the VM/VNF.
+      The difficulty comes when trying to verify that the LAN has been connected to the correct LAN port,
       the WAN has been connected to the correct WAN port and so on.
     * While OpenStack provides a rich set of APIs, critical support is lacking:
 
       * No APIs for ssh access to VM/VNFs.
       * No APIs for port mirroring in Neutron.
-      * No APIs for OpenStack oversubscription parameter setting 
+      * No APIs for OpenStack oversubscription parameter setting
 
 .. [#f1] In all above use cases management traffic is coming inband with tenant traffic.