diff --git a/Release7/MongoDBAsAFilesystem.md b/Release7/MongoDBAsAFilesystem.md
new file mode 100644
index 0000000..c64fae3
--- /dev/null
+++ b/Release7/MongoDBAsAFilesystem.md
@@ -0,0 +1,28 @@
+# MongoDB as a Filesystem #
+
+## Proposer ##
+Adam Israel (Canonical)
+David Garcia (Canonical)
+Eduardo Sousa (Canonical)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+NBI, LCM
+
+## Description ##
+Kubernetes orchestration of OSM Services has shortcomings since NBI and LCM require a 
+shared volume to pass VNFD packages between them. This allows them to share the files 
+between them without a major hassle. In order for this to be possible, Kubernetes needs 
+to be deployed with a storage provider that supports read-write-many volumes so that 
+both components can use the shared files. This puts the burden in the Kubernetes deployment.
+
+This feature aims to reduce this dependency of the Kubernetes deployment to provide a 
+shared volume by using MongoDB to share the files between the two components. The MongoDB 
+as a Filesystem can be achieved by using MongoDB in conjunction with GridFS and storing 
+the files as documents in MongoDB.
+
+## Demo or definition of done ##
+* The files are written to MongoDB.
+* OSM is capable to instantiate a NS and make use of VNF configuration primitives.
diff --git a/Release7/Re-enable_NS_primitives.md b/Release7/Re-enable_NS_primitives.md
new file mode 100644
index 0000000..e675e01
--- /dev/null
+++ b/Release7/Re-enable_NS_primitives.md
@@ -0,0 +1,27 @@
+# Re-enable NS primitives #
+
+## Proposer ##
+Adam Israel
+Gerardo Garcia
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+IM, LCM, N2VC, NBI, osmclient
+
+## Description ##
+With the new OSM internal architecture, support of NS primitives based on
+scripts, offered in the past by the SO, has disappeared. Enabling again NS
+primitives is required to allow day-1 and day-2 operations over NS.
+
+Due to the need to implement it from scratch, it is better to follow an approach
+for NS primitives similar to VNF so that the same procedures and code could
+be used. Moreover, similar constructs for VNF and NS primitives enable a
+natural path for nesting NS, where a NS can be considered as a VNF building
+block to construct other NS. In this regard, the IM changes for NS primitives
+(primitives, charms, relations) should be as similar as possible to the ones
+currently present in the VNFD and VNFR IM.
+
+## Demo or definition of done ##
+To be added.
diff --git a/Release7/Support_of_high_level_primitives_in_SDN_plugin_model_for_SDN_assist.md b/Release7/Support_of_high_level_primitives_in_SDN_plugin_model_for_SDN_assist.md
new file mode 100644
index 0000000..4d84a58
--- /dev/null
+++ b/Release7/Support_of_high_level_primitives_in_SDN_plugin_model_for_SDN_assist.md
@@ -0,0 +1,36 @@
+# Support of high level primitives in SDN plugin model for SDN assist #
+ 
+## Proposer ##
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+ 
+## Type ##
+**Feature**
+ 
+## Target MDG/TF ##
+RO
+ 
+## Description ##
+The SDN plugin model in OSM assumes the existence of a set of calls in the 
+plugin that allow RO to interact with different but equivalent primitives from 
+various SDN controllers in an homogeneous fashion.
+
+The current set of calls assumes the availability of a number of basic 
+flow-level provided by the SDN Controller, letting the RO assume the logic to 
+create the various kinds of underlay networks supported by OSM, namely E-Line 
+and E-LAN types.
+
+While this model of use might be a reasonable approach for many cases, it might 
+be suboptimal for modern SDN controllers, which can be already capable of 
+providing high level API operations to set up E-LAN and/or E-Line connections 
+(and even prevent the use of flow-level operations.
+
+This feature proposes to augment the current SDN plugin model to support also 
+CRUD operations for complete networks, leveraging on existing API calls of 
+modern SDN controllers.
+
+## Demo or definition of done ##
+Show that it is possible to create, read, update and delete underlay 
+connections of E-LAN and E-line types with, at least, one of the supported 
+types of SDN controllers.
\ No newline at end of file
diff --git a/Release7/provider_network_support.md b/Release7/provider_network_support.md
new file mode 100644
index 0000000..309ceb7
--- /dev/null
+++ b/Release7/provider_network_support.md
@@ -0,0 +1,30 @@
+# Support for network creation based on provider network attributes #
+​
+## Proposer ##
+​
+- Vanessa Little (VMware)
+- Mark Beierl (VMware)
+- Matt Harper (RIFT)
+- Ravi Chamarty (RIFT)
+​
+## Type ##
+*Feature**
+​
+## Target MDG/TF ##
+NBI, LCM, RO
+​
+## Description ##
+The OSM instantiation parameters needs enhancement to support the following VIM specific per-VL attributes supports
+​
+provider-network:
+   physical-network: string
+   segmentation-id: uint32
+​
+NBI module shall validate the new OSM instantiation parameters. LCM module shalle pass the above parameters to RO during NS instantiation. OSM RO should support creation of VL based on provider-network.
+​
+In the case of VMware VCD, this allows creation of VL based on a specific VDC external network.
+In the case of Openstack, this allows creation of VL based on a specific physical network.
+​
+​
+## Demo or definition of done ##
+Instantiate NS VL based on provider network attributes
diff --git a/Release7/vmware_vcd_95_support.md b/Release7/vmware_vcd_95_support.md
new file mode 100644
index 0000000..befbdfd
--- /dev/null
+++ b/Release7/vmware_vcd_95_support.md
@@ -0,0 +1,19 @@
+# Support for VMware VCD 9.5 #
+
+## Proposer ##
+
+- Vanessa Little (VMware)
+- Matt Harper (RIFT)
+- Ravi Chamarty (RIFT)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+This is primarily a test effort. We will test VMware VCD VIMConnector against VCD 9.5
+
+## Demo or definition of done ##
+Verify OSM R5 descriptor packages using VCD 9.5