| VNF or PNF | Function behavior to both VNFs and PNFs |
+---------------------+-------------------------------------------------------+
| {VNF|PNF|VNF or PNF}| Something the provider of the VNF, PNF, or VNF/PNF |
-| Provider | must do. This is often used to describe delivering |
+| PROVIDER | must do. This is often used to describe delivering |
| | artifacts or specific documentation that may not be |
| | part of a standard VNF package format. |
+---------------------+-------------------------------------------------------+
| | Descriptor, etc.), but the :target: metadata would |
| | stay at the package level. |
+---------------------+-------------------------------------------------------+
+| {VNF|PNF|VNF or PNF}| VNFs and PNFs are expected to provide human readable |
+| DOCUMENTATION | documentation. This may come in the form of URLs or |
+| PACKAGE | pdfs. This documentation may vary by VNF or PNF. |
+| | The structure of the documentation is intended for |
+| | human consumption and is not highly structured for |
+| | machine ingestion. The human readable documentation |
+| | may be provided through the RFP/acquisition process. |
++---------------------+-------------------------------------------------------+
+
- Chapter 4 contains the xNF requirements involving the design and
development of xNFs. These requirements help VNFs/PNFs operate
efficiently within a cloud environment. Requirements cover design,
instantiating virtual resources in an OpenStack environment. At this
time the HEAT files will be passed to the Service provider as a data
element within the TOSCA onboarding package.
+
- Chapter 6 details the requirements specific to an implementation.
The current implementations documented are OpenStack and Azure.
- Chapter 7 provides the comprehensive set of requirements for xNFs to