summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-07-25 20:56:21 +0000
committerBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-07-25 20:57:03 +0000
commitc5ca89866fa8a2e932c35f5f77f7310ad8e63c1c (patch)
treec2f39ee0450ea2c5e84866bfab77fcc0fe9d234f
parent9e8d07abccaec2615b62fe4729b9a22c7e690a7c (diff)
VNFRQTS - Updated Requirements list with section
Removed old requirements list and updated table. Change-Id: I767bf4fcfbde1eccdf663120c4de31fe8b81eb10 Issue-ID: VNFRQTS-276 Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>
-rw-r--r--docs/Chapter8/Requirement-List.rst2888
-rw-r--r--docs/Chapter9/index.rst2
2 files changed, 1 insertions, 2889 deletions
diff --git a/docs/Chapter8/Requirement-List.rst b/docs/Chapter8/Requirement-List.rst
deleted file mode 100644
index 41c9ea2..0000000
--- a/docs/Chapter8/Requirement-List.rst
+++ /dev/null
@@ -1,2888 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-Requirement List
---------------------------------
-
-**VNF Development Requirements**
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-VNF Design
-~~~~~~~~~~~~~
-
-R-58421 The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
-
-R-82223 The VNF **MUST** be decomposed if the functions have
-significantly different scaling characteristics (e.g., signaling
-versus media functions, control versus data plane functions).
-
-R-16496 The VNF **MUST** enable instantiating only the functionality that
-is needed for the decomposed VNF (e.g., if transcoding is not needed it
-should not be instantiated).
-
-R-02360 The VNFC **MUST** be designed as a standalone, executable process.
-
-R-34484 The VNF **SHOULD** create a single component VNF for VNFCs
-that can be used by other VNFs.
-
-R-23035 The VNF **MUST** be designed to scale horizontally (more
-instances of a VNF or VNFC) and not vertically (moving the existing
-instances to larger VMs or increasing the resources within a VM)
-to achieve effective utilization of cloud resources.
-
-R-30650 The VNF **MUST** utilize cloud provided infrastructure and
-VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so
-that the cloud can manage and provide a consistent service resiliency
-and methods across all VNF's.
-
-R-12709 The VNFC **SHOULD** be independently deployed, configured,
-upgraded, scaled, monitored, and administered by ONAP.
-
-R-37692 The VNFC **MUST** provide API versioning to allow for
-independent upgrades of VNFC.
-
-R-86585 The VNFC **SHOULD** minimize the use of state within
-a VNFC to facilitate the movement of traffic from one instance
-to another.
-
-R-65134 The VNF **SHOULD** maintain state in a geographically
-redundant datastore that may, in fact, be its own VNFC.
-
-R-75850 The VNF **SHOULD** decouple persistent data from the VNFC
-and keep it in its own datastore that can be reached by all instances
-of the VNFC requiring the data.
-
-R-88199 The VNF **MUST** utilize a persistent datastore service that
-can meet the data performance/latency requirements. (For example:
-Datastore service could be a VNFC in VNF or a DBaaS in the Cloud
-execution environment)
-
-R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC
-instance fails.
-
-R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF’s requiring
-high packets/sec performance. High packet throughput is defined as greater
-than 500K packets/sec.
-
-R-54430 The VNF **MUST** use the NCSP’s supported library and compute
-flavor that supports DPDK to optimize network efficiency if using DPDK. [4]_
-
-R-18864 The VNF **MUST** NOT use technologies that bypass virtualization
-layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary
-to meet functional or performance requirements).
-
-R-64768 The VNF **MUST** limit the size of application data packets
-to no larger than 9000 bytes for SDN network-based tunneling when
-guest data packets are transported between tunnel endpoints that
-support guest logical networks.
-
-R-74481 The VNF **MUST** NOT require the use of a dynamic routing
-protocol unless necessary to meet functional requirements.
-
-VNF Resiliency
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-R-52499 The VNF **MUST** meet their own resiliency goals and not rely
-on the Network Cloud.
-
-R-42207 The VNF **MUST** design resiliency into a VNF such that the
-resiliency deployment model (e.g., active-active) can be chosen at
-run-time.
-
-R-03954 The VNF **MUST** survive any single points of failure within
-the Network Cloud (e.g., virtual NIC, VM, disk failure).
-
-R-89010 The VNF **MUST** survive any single points of software failure
-internal to the VNF (e.g., in memory structures, JMS message queues).
-
-R-67709 The VNF **MUST** be designed, built and packaged to enable
-deployment across multiple fault zones (e.g., VNFCs deployed in
-different servers, racks, OpenStack regions, geographies) so that
-in the event of a planned/unplanned downtime of a fault zone, the
-overall operation/throughput of the VNF is maintained.
-
-R-35291 The VNF **MUST** support the ability to failover a VNFC
-automatically to other geographically redundant sites if not
-deployed active-active to increase the overall resiliency of the VNF.
-
-R-36843 The VNF **MUST** support the ability of the VNFC to be deployable
-in multi-zoned cloud sites to allow for site support in the event of cloud
-zone failure or upgrades.
-
-R-00098 The VNF **MUST NOT** impact the ability of the VNF to provide
-service/function due to a single container restart.
-
-R-79952 The VNF **SHOULD** support container snapshots if not for rebuild
-and evacuate for rollback or back out mechanism.
-
-R-92935 The VNF **SHOULD** minimize the propagation of state information
-across multiple data centers to avoid cross data center traffic.
-
-R-26371 The VNF **MUST** detect communication failure for inter VNFC
-instance and intra/inter VNF and re-establish communication
-automatically to maintain the VNF without manual intervention to
-provide service continuity.
-
-R-18725 The VNF **MUST** handle the restart of a single VNFC instance
-without requiring all VNFC instances to be restarted.
-
-R-06668 The VNF **MUST** handle the start or restart of VNFC instances
-in any order with each VNFC instance establishing or re-establishing
-required connections or relationships with other VNFC instances and/or
-VNFs required to perform the VNF function/role without requiring VNFC
-instance(s) to be started/restarted in a particular order.
-
-R-80070 The VNF **MUST** handle errors and exceptions so that they do
-not interrupt processing of incoming VNF requests to maintain service
-continuity (where the error is not directly impacting the software
-handling the incoming request).
-
-R-32695 The VNF **MUST** provide the ability to modify the number of
-retries, the time between retries and the behavior/action taken after
-the retries have been exhausted for exception handling to allow the
-NCSP to control that behavior, where the interface and/or functional
-specification allows for altering behaviour.
-
-R-48356 The VNF **MUST** fully exploit exception handling to the extent
-that resources (e.g., threads and memory) are released when no longer
-needed regardless of programming language.
-
-R-67918 The VNF **MUST** handle replication race conditions both locally
-and geo-located in the event of a data base instance failure to maintain
-service continuity.
-
-R-36792 The VNF **MUST** automatically retry/resubmit failed requests
-made by the software to its downstream system to increase the success rate.
-
-R-70013 The VNF **MUST NOT** require any manual steps to get it ready for
-service after a container rebuild.
-
-R-65515 The VNF **MUST** provide a mechanism and tool to start VNF
-containers (VMs) without impacting service or service quality assuming
-another VNF in same or other geographical location is processing service
-requests.
-
-R-94978 The VNF **MUST** provide a mechanism and tool to perform a graceful
-shutdown of all the containers (VMs) in the VNF without impacting service
-or service quality assuming another VNF in same or other geographical
-location can take over traffic and process service requests.
-
-R-22059 The VNF **MUST NOT** execute long running tasks (e.g., IO,
-database, network operations, service calls) in a critical section
-of code, so as to minimize blocking of other operations and increase
-concurrent throughput.
-
-R-63473 The VNF **MUST** automatically advertise newly scaled
-components so there is no manual intervention required.
-
-R-74712 The VNF **MUST** utilize FQDNs (and not IP address) for
-both Service Chaining and scaling.
-
-R-41159 The VNF **MUST** deliver any and all functionality from any
-VNFC in the pool (where pooling is the most suitable solution). The
-VNFC pool member should be transparent to the client. Upstream and
-downstream clients should only recognize the function being performed,
-not the member performing it.
-
-R-85959 The VNF **SHOULD** automatically enable/disable added/removed
-sub-components or component so there is no manual intervention required.
-
-R-06885 The VNF **SHOULD** support the ability to scale down a VNFC pool
-without jeopardizing active sessions. Ideally, an active session should
-not be tied to any particular VNFC instance.
-
-R-12538 The VNF **SHOULD** support load balancing and discovery
-mechanisms in resource pools containing VNFC instances.
-
-R-98989 The VNF **SHOULD** utilize resource pooling (threads,
-connections, etc.) within the VNF application so that resources
-are not being created and destroyed resulting in resource management
-overhead.
-
-R-55345 The VNF **SHOULD** use techniques such as “lazy loading” when
-initialization includes loading catalogues and/or lists which can grow
-over time, so that the VNF startup time does not grow at a rate
-proportional to that of the list.
-
-R-35532 The VNF **SHOULD** release and clear all shared assets (memory,
-database operations, connections, locks, etc.) as soon as possible,
-especially before long running sync and asynchronous operations, so as
-to not prevent use of these assets by other entities.
-
-R-77334 The VNF **MUST** allow configurations and configuration parameters
-to be managed under version control to ensure consistent configuration
-deployment, traceability and rollback.
-
-R-99766 The VNF **MUST** allow configurations and configuration parameters
-to be managed under version control to ensure the ability to rollback to
-a known valid configuration.
-
-R-73583 The VNF **MUST** allow changes of configuration parameters
-to be consumed by the VNF without requiring the VNF or its sub-components
-to be bounced so that the VNF availability is not effected.
-
-R-21558 The VNF **SHOULD** use intelligent routing by having knowledge
-of multiple downstream/upstream endpoints that are exposed to it, to
-ensure there is no dependency on external services (such as load balancers)
-to switch to alternate endpoints.
-
-R-08315 The VNF **SHOULD** use redundant connection pooling to connect
-to any backend data source that can be switched between pools in an
-automated/scripted fashion to ensure high availability of the connection
-to the data source.
-
-R-27995 The VNF **SHOULD** include control loop mechanisms to notify
-the consumer of the VNF of their exceeding SLA thresholds so the consumer
-is able to control its load against the VNF.
-
-R-73364 The VNF **MUST** support at least two major versions of the
-VNF software and/or sub-components to co-exist within production
-environments at any time so that upgrades can be applied across
-multiple systems in a staggered manner.
-
-R-02454 The VNF **MUST** support the existence of multiple major/minor
-versions of the VNF software and/or sub-components and interfaces that
-support both forward and backward compatibility to be transparent to
-the Service Provider usage.
-
-R-57855 The VNF **MUST** support hitless staggered/rolling deployments
-between its redundant instances to allow "soak-time/burn in/slow roll"
-which can enable the support of low traffic loads to validate the
-deployment prior to supporting full traffic loads.
-
-R-64445 The VNF **MUST** support the ability of a requestor of the
-service to determine the version (and therefore capabilities) of the
-service so that Network Cloud Service Provider can understand the
-capabilities of the service.
-
-R-56793 The VNF **MUST** test for adherence to the defined performance
-budgets at each layer, during each delivery cycle with delivered
-results, so that the performance budget is measured and the code
-is adjusted to meet performance budget.
-
-R-77667 The VNF **MUST** test for adherence to the defined performance
-budget at each layer, during each delivery cycle so that the performance
-budget is measured and feedback is provided where the performance budget
-is not met.
-
-R-49308 The VNF **SHOULD** test for adherence to the defined resiliency
-rating recommendation at each layer, during each delivery cycle with
-delivered results, so that the resiliency rating is measured and the
-code is adjusted to meet software resiliency requirements.
-
-R-16039 The VNF **SHOULD** test for adherence to the defined
-resiliency rating recommendation at each layer, during each
-delivery cycle so that the resiliency rating is measured and
-feedback is provided where software resiliency requirements are
-not met.
-
-R-34957 The VNF **MUST** provide a method of metrics gathering for each
-layer's performance to identify/document variances in the allocations so
-they can be addressed.
-
-R-49224 The VNF **MUST** provide unique traceability of a transaction
-through its life cycle to ensure quick and efficient troubleshooting.
-
-R-52870 The VNF **MUST** provide a method of metrics gathering
-and analysis to evaluate the resiliency of the software from both
-a granular as well as a holistic standpoint. This includes, but is
-not limited to thread utilization, errors, timeouts, and retries.
-
-R-92571 The VNF **MUST** provide operational instrumentation such as
-logging, so as to facilitate quick resolution of issues with the VNF to
-provide service continuity.
-
-R-48917 The VNF **MUST** monitor for and alert on (both sender and
-receiver) errant, running longer than expected and missing file transfers,
-so as to minimize the impact due to file transfer errors.
-
-R-28168 The VNF **SHOULD** use an appropriately configured logging
-level that can be changed dynamically, so as to not cause performance
-degradation of the VNF due to excessive logging.
-
-R-87352 The VNF **SHOULD** utilize Cloud health checks, when available
-from the Network Cloud, from inside the application through APIs to check
-the network connectivity, dropped packets rate, injection, and auto failover
-to alternate sites if needed.
-
-R-16560 The VNF **SHOULD** conduct a resiliency impact assessment for all
-inter/intra-connectivity points in the VNF to provide an overall resiliency
-rating for the VNF to be incorporated into the software design and
-development of the VNF.
-
-VNF Security
-~~~~~~~~~~~~~~
-
-R-23740 The VNF **MUST** accommodate the security principle of
-“least privilege” during development, implementation and operation.
-The importance of “least privilege” cannot be overstated and must be
-observed in all aspects of VNF development and not limited to security.
-This is applicable to all sections of this document.
-
-R-61354 The VNF **MUST** implement access control list for OA&M
-services (e.g., restricting access to certain ports or applications).
-
-R-85633 The VNF **MUST** implement Data Storage Encryption
-(database/disk encryption) for Sensitive Personal Information (SPI)
-and other subscriber identifiable data. Note: subscriber’s SPI/data
-must be encrypted at rest, and other subscriber identifiable data
-should be encrypted at rest. Other data protection requirements exist
-and should be well understood by the developer.
-
-R-92207 The VNF **SHOULD** implement a mechanism for automated and
-frequent "system configuration (automated provisioning / closed loop)"
-auditing.
-
-R-23882 The VNF **SHOULD** be scanned using both network scanning
-and application scanning security tools on all code, including underlying
-OS and related configuration. Scan reports shall be provided. Remediation
-roadmaps shall be made available for any findings.
-
-R-46986 The VNF **SHOULD** have source code scanned using scanning
-tools (e.g., Fortify) and provide reports.
-
-R-55830 The VNF **MUST** distribute all production code from NCSP
-internal sources only. No production code, libraries, OS images, etc.
-shall be distributed from publically accessible depots.
-
-R-99771 The VNF **MUST** provide all code/configuration files in a
-"Locked down" or hardened state or with documented recommendations for
-such hardening. All unnecessary services will be disabled. VNF provider
-default credentials, community strings and other such artifacts will be
-removed or disclosed so that they can be modified or removed during
-provisioning.
-
-R-19768 The VNF **SHOULD** support L3 VPNs that enable segregation of
-traffic by application (dropping packets not belonging to the VPN) (i.e.,
-AVPN, IPSec VPN for Internet routes).
-
-R-33981 The VNF **SHOULD** interoperate with various access control
-mechanisms for the Network Cloud execution environment (e.g.,
-Hypervisors, containers).
-
-R-40813 The VNF **SHOULD** support the use of virtual trusted platform
-module, hypervisor security testing and standards scanning tools.
-
-R-56904 The VNF **MUST** interoperate with the ONAP (SDN) Controller so that
-it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual
-routing and forwarding rules.
-
-R-26586 The VNF **SHOULD** support the ability to work with aliases
-(e.g., gateways, proxies) to protect and encapsulate resources.
-
-R-49956 The VNF **MUST** pass all access to applications (Bearer,
-signaling and OA&M) through various security tools and platforms from
-ACLs, stateful firewalls and application layer gateways depending on
-manner of deployment. The application is expected to function (and in
-some cases, interwork) with these security tools.
-
-R-69649 The VNF **MUST** have all vulnerabilities patched as soon
-as possible. Patching shall be controlled via change control process
-with vulnerabilities disclosed along with mitigation recommendations.
-
-R-78010 The VNF **MUST** use the NCSP’s IDAM API for Identification,
-authentication and access control of customer or VNF application users.
-
-R-42681 The VNF **MUST** use the NCSP’s IDAM API or comply with
-the requirements if not using the NCSP’s IDAM API, for identification,
-authentication and access control of OA&M and other system level
-functions.
-
-R-68589 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-User-IDs and passwords to uniquely identify the user/application. VNF
-needs to have appropriate connectors to the Identity, Authentication
-and Authorization systems that enables access at OS, Database and
-Application levels as appropriate.
-
-R-52085 The VNF **MUST**, if not using the NCSP’s IDAM API, provide
-the ability to support Multi-Factor Authentication (e.g., 1st factor =
-Software token on device (RSA SecureID); 2nd factor = User Name+Password,
-etc.) for the users.
-
-R-98391 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-Role-Based Access Control to permit/limit the user/application to
-performing specific activities.
-
-R-63217 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-logging via ONAP for a historical view of “who did what and when”.
-
-R-62498 The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt
-OA&M access (e.g., SSH, SFTP).
-
-R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce
-a configurable maximum number of Login attempts policy for the users.
-VNF provider must comply with "terminate idle sessions" policy.
-Interactive sessions must be terminated, or a secure, locking screensaver
-must be activated requiring authentication, after a configurable period
-of inactivity. The system-based inactivity timeout for the enterprise
-identity and access management system must also be configurable.
-
-R-35144 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-with the NCSP’s credential management policy.
-
-R-75041 The VNF **MUST**, if not using the NCSP’s IDAM API, expire
-passwords at regular configurable intervals.
-
-R-46908 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-with "password complexity" policy. When passwords are used, they shall
-be complex and shall at least meet the following password construction
-requirements: (1) be a minimum configurable number of characters in
-length, (2) include 3 of the 4 following types of characters:
-upper-case alphabetic, lower-case alphabetic, numeric, and special,
-(3) not be the same as the UserID with which they are associated or
-other common strings as specified by the environment, (4) not contain
-repeating or sequential characters or numbers, (5) not to use special
-characters that may have command functions, and (6) new passwords must
-not contain sequences of three or more characters from the previous
-password.
-
-R-39342 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-with "password changes (includes default passwords)" policy. Products
-will support password aging, syntax and other credential management
-practices on a configurable basis.
-
-R-40521 The VNF **MUST**, if not using the NCSP’s IDAM API, support
-use of common third party authentication and authorization tools such
-as TACACS+, RADIUS.
-
-R-41994 The VNF **MUST**, if not using the NCSP’s IDAM API, comply
-with "No Self-Signed Certificates" policy. Self-signed certificates
-must be used for encryption only, using specified and approved
-encryption protocols such as TLS 1.2 or higher or equivalent security
-protocols such as IPSec, AES.
-
-R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API,
-authenticate system to system communications where one system
-accesses the resources of another system, and must never conceal
-individual accountability.
-
-R-95105 The VNF **MUST** host connectors for access to the application
-layer.
-
-R-45496 The VNF **MUST** host connectors for access to the OS
-(Operating System) layer.
-
-R-05470 The VNF **MUST** host connectors for access to the database layer.
-
-R-99174 The VNF **MUST** comply with Individual Accountability
-(each person must be assigned a unique ID) when persons or non-person
-entities access VNFs.
-
-R-42874 The VNF **MUST** comply with Least Privilege (no more
-privilege than required to perform job functions) when persons
-or non-person entities access VNFs.
-
-R-71787 The VNF **MUST** comply with Segregation of Duties (access to a
-single layer and no developer may access production without special
-oversight) when persons or non-person entities access VNFs.
-
-R-86261 The VNF **MUST NOT** allow VNF provider access to VNFs remotely.
-
-R-49945 The VNF **MUST** authorize VNF provider access through a
-client application API by the client application owner and the resource
-owner of the VNF before provisioning authorization through Role Based
-Access Control (RBAC), Attribute Based Access Control (ABAC), or other
-policy based mechanism.
-
-R-31751 The VNF **MUST** subject VNF provider access to privilege
-reconciliation tools to prevent access creep and ensure correct
-enforcement of access policies.
-
-R-34552 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for OWASP Top 10.
-
-R-29301 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Password Attacks.
-
-R-72243 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Phishing / SMishing.
-
-R-58998 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Malware (Key Logger).
-
-R-14025 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Session Hijacking.
-
-R-31412 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for XSS / CSRF.
-
-R-51883 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Replay.
-
-R-44032 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Man in the Middle (MITM).
-
-R-58977 The VNF **MUST** provide or support the Identity and Access
-Management (IDAM) based threat detection data for Eavesdropping.
-
-R-24825 The VNF **MUST** provide Context awareness data (device,
-location, time, etc.) and be able to integrate with threat detection system.
-
-R-59391 The VNF provider **MUST**, where a VNF provider requires
-the assumption of permissions, such as root or administrator, first
-log in under their individual user login ID then switch to the other
-higher level account; or where the individual user login is infeasible,
-must login with an account with admin privileges in a way that
-uniquely identifies the individual performing the function.
-
-R-85028 The VNF **MUST** authenticate system to system access and
-do not conceal a VNF provider user’s individual accountability for
-transactions.
-
-R-80335 The VNF **MUST** make visible a Warning Notice: A formal
-statement of resource intent, i.e., a warning notice, upon initial
-access to a VNF provider user who accesses private internal networks
-or Company computer resources, e.g., upon initial logon to an internal
-web site, system or application which requires authentication.
-
-R-73541 The VNF **MUST** use access controls for VNFs and their
-supporting computing systems at all times to restrict access to
-authorized personnel only, e.g., least privilege. These controls
-could include the use of system configuration or access control
-software.
-
-R-64503 The VNF **MUST** provide minimum privileges for initial
-and default settings for new user accounts.
-
-R-86835 The VNF **MUST** set the default settings for user access
-to sensitive commands and data to deny authorization.
-
-R-77157 The VNF **MUST** conform to approved request, workflow
-authorization, and authorization provisioning requirements when
-creating privileged users.
-
-R-81147 The VNF **MUST** have greater restrictions for access and
-execution, such as up to 3 factors of authentication and restricted
-authorization, for commands affecting network services, such as
-commands relating to VNFs.
-
-R-49109 The VNF **MUST** encrypt TCP/IP--HTTPS (e.g., TLS v1.2)
-transmission of data on internal and external networks.
-
-R-39562 The VNF **MUST** disable unnecessary or vulnerable cgi-bin programs.
-
-R-15671 The VNF **MUST NOT** provide public or unrestricted access
-to any data without the permission of the data owner. All data
-classification and access controls must be followed.
-
-R-89753 The VNF **MUST NOT** install or use systems, tools or
-utilities capable of capturing or logging data that was not created
-by them or sent specifically to them in production, without
-authorization of the VNF system owner.
-
-R-19082 The VNF **MUST NOT** run security testing tools and
-programs, e.g., password cracker, port scanners, hacking tools
-in production, without authorization of the VNF system owner.
-
-R-19790 The VNF **MUST NOT** include authentication credentials
-in security audit logs, even if encrypted.
-
-R-85419 The VNF **SHOULD** use REST APIs exposed to Client
-Applications for the implementation of OAuth 2.0 Authorization
-Code Grant and Client Credentials Grant, as the standard interface
-for a VNF.
-
-R-48080 The VNF **SHOULD** support SCEP (Simple Certificate
-Enrollment Protocol).
-
-R-37608 The VNF **MUST** provide a mechanism to restrict access based
-on the attributes of the VNF and the attributes of the subject.
-
-R-43884 The VNF **MUST** integrate with external authentication
-and authorization services (e.g., IDAM).
-
-R-25878 The VNF **MUST** use certificates issued from publicly
-recognized Certificate Authorities (CA) for the authentication process
-where PKI-based authentication is used.
-
-R-19804 The VNF **MUST** validate the CA signature on the certificate,
-ensure that the date is within the validity period of the certificate,
-check the Certificate Revocation List (CRL), and recognize the identity
-represented by the certificate where PKI-based authentication is used.
-
-R-47204 The VNF **MUST** protect the confidentiality and integrity of
-data at rest and in transit from unauthorized access and modification.
-
-R-33488 The VNF **MUST** protect against all denial of service
-attacks, both volumetric and non-volumetric, or integrate with external
-denial of service protection tools.
-
-R-21652 The VNF **MUST** implement the following input validation
-control: Check the size (length) of all input. Do not permit an amount
-of input so great that it would cause the VNF to fail. Where the input
-may be a file, the VNF API must enforce a size limit.
-
-R-54930 The VNF **MUST** implement the following input validation
-control: Do not permit input that contains content or characters
-inappropriate to the input expected by the design. Inappropriate input,
-such as SQL insertions, may cause the system to execute undesirable
-and unauthorized transactions against the database or allow other
-inappropriate access to the internal network.
-
-R-21210 The VNF **MUST** implement the following input validation
-control: Validate that any input file has a correct and valid
-Multipurpose Internet Mail Extensions (MIME) type. Input files
-should be tested for spoofed MIME types.
-
-R-23772 The VNF **MUST** validate input at all layers implementing VNF APIs.
-
-R-87135 The VNF **MUST** comply with NIST standards and industry
-best practices for all implementations of cryptography.
-
-R-02137 The VNF **MUST** implement all monitoring and logging as
-described in the Security Analytics section.
-
-R-15659 The VNF **MUST** restrict changing the criticality level of
-a system security alarm to administrator(s).
-
-R-19367 The VNF **MUST** monitor API invocation patterns to detect
-anomalous access patterns that may represent fraudulent access or
-other types of attacks, or integrate with tools that implement anomaly
-and abuse detection.
-
-R-78066 The VNF **MUST** support requests for information from law
-enforcement and government agencies.
-
-R-48470 The VNF **MUST** support Real-time detection and
-notification of security events.
-
-R-22286 The VNF **MUST** support Integration functionality via
-API/Syslog/SNMP to other functional modules in the network (e.g.,
-PCRF, PCEF) that enable dynamic security control by blocking the
-malicious traffic or malicious end users.
-
-R-32636 The VNF **MUST** support API-based monitoring to take care of
-the scenarios where the control interfaces are not exposed, or are
-optimized and proprietary in nature.
-
-R-61648 The VNF **MUST** support event logging, formats, and delivery
-tools to provide the required degree of event data to ONAP.
-
-R-22367 The VNF **MUST** support detection of malformed packets due to
-software misconfiguration or software vulnerability.
-
-R-31961 The VNF **MUST** support integrated DPI/monitoring functionality
-as part of VNFs (e.g., PGW, MME).
-
-R-20912 The VNF **MUST** support alternative monitoring capabilities
-when VNFs do not expose data or control traffic or use proprietary and
-optimized protocols for inter VNF communication.
-
-R-73223 The VNF **MUST** support proactive monitoring to detect and
-report the attacks on resources so that the VNFs and associated VMs can
-be isolated, such as detection techniques for resource exhaustion, namely
-OS resource attacks, CPU attacks, consumption of kernel memory, local
-storage attacks.
-
-R-58370 The VNF **MUST** coexist and operate normally with commercial
-anti-virus software which shall produce alarms every time when there is a
-security incident.
-
-R-56920 The VNF **MUST** protect all security audit logs (including
-API, OS and application-generated logs), security audit software, data,
-and associated documentation from modification, or unauthorized viewing,
-by standard OS access control mechanisms, by sending to a remote system,
-or by encryption.
-
-R-54520 The VNF **MUST** log successful and unsuccessful login attempts.
-
-R-55478 The VNF **MUST** log logoffs.
-
-R-08598 The VNF **MUST** log successful and unsuccessful changes to
-a privilege level.
-
-R-13344 The VNF **MUST** log starting and stopping of security
-logging.
-
-R-07617 The VNF **MUST** log creating, removing, or changing the
-inherent privilege level of users.
-
-R-94525 The VNF **MUST** log connections to a network listener of the
-resource.
-
-R-31614 The VNF **MUST** log the field “event type” in the security
-audit logs.
-
-R-97445 The VNF **MUST** log the field “date/time” in the security
-audit logs.
-
-R-25547 The VNF **MUST** log the field “protocol” in the security audit logs.
-
-R-06413 The VNF **MUST** log the field “service or program used for
-access” in the security audit logs.
-
-R-15325 The VNF **MUST** log the field “success/failure” in the
-security audit logs.
-
-R-89474 The VNF **MUST** log the field “Login ID” in the security audit logs.
-
-R-04982 The VNF **MUST NOT** include an authentication credential,
-e.g., password, in the security audit logs, even if encrypted.
-
-R-63330 The VNF **MUST** detect when the security audit log storage
-medium is approaching capacity (configurable) and issue an alarm via
-SMS or equivalent as to allow time for proper actions to be taken to
-pre-empt loss of audit data.
-
-R-41252 The VNF **MUST** support the capability of online storage of
-security audit logs.
-
-R-41825 The VNF **MUST** activate security alarms automatically when
-the following event is detected: configurable number of consecutive
-unsuccessful login attempts
-
-R-43332 The VNF **MUST** activate security alarms automatically when
-the following event is detected: successful modification of critical
-system or application files
-
-R-74958 The VNF **MUST** activate security alarms automatically when
-the following event is detected: unsuccessful attempts to gain permissions
-or assume the identity of another user
-
-R-15884 The VNF **MUST** include the field “date” in the Security alarms
-(where applicable and technically feasible).
-
-R-23957 The VNF **MUST** include the field “time” in the Security alarms
-(where applicable and technically feasible).
-
-R-71842 The VNF **MUST** include the field “service or program used for
-access” in the Security alarms (where applicable and technically feasible).
-
-R-57617 The VNF **MUST** include the field “success/failure” in the
-Security alarms (where applicable and technically feasible).
-
-R-99730 The VNF **MUST** include the field “Login ID” in the Security
-alarms (where applicable and technically feasible).
-
-R-29705 The VNF **MUST** restrict changing the criticality level of a
-system security alarm to administrator(s).
-
-R-13627 The VNF **MUST** monitor API invocation patterns to detect
-anomalous access patterns that may represent fraudulent access or other
-types of attacks, or integrate with tools that implement anomaly and
-abuse detection.
-
-R-21819 The VNF **MUST** support requests for information from law
-enforcement and government agencies.
-
-R-56786 The VNF **MUST** implement “Closed Loop” automatic implementation
-(without human intervention) for Known Threats with detection rate in low
-false positives.
-
-R-25094 The VNF **MUST** perform data capture for security functions.
-
-R-04492 The VNF **MUST** generate security audit logs that must be sent
-to Security Analytics Tools for analysis.
-
-R-19219 The VNF **MUST** provide audit logs that include user ID, dates,
-times for log-on and log-off, and terminal location at minimum.
-
-R-30932 The VNF **MUST** provide security audit logs including records
-of successful and rejected system access data and other resource access
-attempts.
-
-R-54816 The VNF **MUST** support the storage of security audit logs
-for agreed period of time for forensic analysis.
-
-R-57271 The VNF **MUST** provide the capability of generating security
-audit logs by interacting with the operating system (OS) as appropriate.
-
-R-84160 The VNF **MUST** have security logging for VNFs and their
-OSs be active from initialization. Audit logging includes automatic
-routines to maintain activity records and cleanup programs to ensure
-the integrity of the audit/logging systems.
-
-R-58964 The VNF **MUST** provide the capability to restrict read
-and write access to data.
-
-R-99112 The VNF **MUST** provide the capability to restrict access
-to data to specific users.
-
-R-83227 The VNF **MUST** Provide the capability to encrypt data in
-transit on a physical or virtual network.
-
-R-32641 The VNF **MUST** provide the capability to encrypt data on
-non-volatile memory.
-
-R-13151 The VNF **SHOULD** disable the paging of the data requiring
-encryption, if possible, where the encryption of non-transient data is
-required on a device for which the operating system performs paging to
-virtual memory. If not possible to disable the paging of the data
-requiring encryption, the virtual memory should be encrypted.
-
-R-93860 The VNF **MUST** provide the capability to integrate with an
-external encryption service.
-
-R-73067 The VNF **MUST** use industry standard cryptographic algorithms
-and standard modes of operations when implementing cryptography.
-
-R-22645 The VNF **SHOULD** use commercial algorithms only when there
-are no applicable governmental standards for specific cryptographic
-functions, e.g., public key cryptography, message digests.
-
-R-12467 The VNF **MUST NOT** use the SHA, DSS, MD5, SHA-1 and
-Skipjack algorithms or other compromised encryption.
-
-R-02170 The VNF **MUST** use, whenever possible, standard implementations
-of security applications, protocols, and format, e.g., S/MIME, TLS, SSH,
-IPSec, X.509 digital certificates for cryptographic implementations.
-These implementations must be purchased from reputable vendors and must
-not be developed in-house.
-
-R-70933 The VNF **MUST** provide the ability to migrate to newer
-versions of cryptographic algorithms and protocols with no impact.
-
-R-44723 The VNF **MUST** use symmetric keys of at least 112 bits in length.
-
-R-25401 The VNF **MUST** use asymmetric keys of at least 2048 bits in length.
-
-R-95864 The VNF **MUST** use commercial tools that comply with X.509
-standards and produce x.509 compliant keys for public/private key generation.
-
-R-12110 The VNF **MUST NOT** use keys generated or derived from
-predictable functions or values, e.g., values considered predictable
-include user identity information, time of day, stored/transmitted data.
-
-R-52060 The VNF **MUST** provide the capability to configure encryption
-algorithms or devices so that they comply with the laws of the jurisdiction
-in which there are plans to use data encryption.
-
-R-69610 The VNF **MUST** provide the capability of using certificates
-issued from a Certificate Authority not provided by the VNF provider.
-
-R-83500 The VNF **MUST** provide the capability of allowing certificate
-renewal and revocation.
-
-R-29977 The VNF **MUST** provide the capability of testing the validity
-of a digital certificate by validating the CA signature on the certificate.
-
-R-24359 The VNF **MUST** provide the capability of testing the validity
-of a digital certificate by validating the date the certificate is being
-used is within the validity period for the certificate.
-
-R-39604 The VNF **MUST** provide the capability of testing the
-validity of a digital certificate by checking the Certificate Revocation
-List (CRL) for the certificates of that type to ensure that the
-certificate has not been revoked.
-
-R-75343 The VNF **MUST** provide the capability of testing the
-validity of a digital certificate by recognizing the identity represented
-by the certificate — the "distinguished name".
-
-VNF Modularity
-~~~~~~~~~~~~~~~~~~
-
-R-37028 The VNF **MUST** be composed of one “base” module.
-
-R-41215 The VNF **MAY** have zero to many “incremental” modules.
-
-R-20974 The VNF **MUST** deploy the base module first, prior to
-the incremental modules.
-
-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-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.
-
-VNF Devops
-~~~~~~~~~~~~~~
-
-R-46960 NCSPs **MAY** operate a limited set of Guest OS and CPU
-architectures and families, virtual machines, etc.
-
-R-23475 VNFCs **SHOULD** be agnostic to the details of the Network Cloud
-(such as hardware, host OS, Hypervisor or container technology) and must run
-on the Network Cloud with acknowledgement to the paradigm that the Network
-Cloud will continue to rapidly evolve and the underlying components of
-the platform will change regularly.
-
-R-33846 The VNF **MUST** install the NCSP required software on Guest OS
-images when not using the NCSP provided Guest OS images. [4]_
-
-R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [4]_
-
-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.
-
-R-20860 The VNF **MUST** be agnostic to the underlying infrastructure
-(such as hardware, host OS, Hypervisor), any requirements should be
-provided as specification to be fulfilled by any hardware.
-
-R-89800 The VNF **MUST NOT** require Hypervisor-level customization
-from the cloud provider.
-
-R-86758 The VNF **SHOULD** provide an automated test suite to validate
-every new version of the software on the target environment(s). The tests
-should be of sufficient granularity to independently test various
-representative VNF use cases throughout its lifecycle. Operations might
-choose to invoke these tests either on a scheduled basis or on demand to
-support various operations functions including test, turn-up and
-troubleshooting.
-
-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" [1]_ 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" [1]_ 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-64713 The VNF **SHOULD** support a software promotion methodology
-from dev/test -> pre-prod -> production in software, development &
-testing and operations.
-
-**VNF Modeling Requirements**
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Heat
-~~~~
-
-R-95303 A VNF's Heat Orchestration Template **MUST**
-be defined using valid YAML.
-
-R-27078 A VNF's Heat Orchestration template **MUST** contain
-the section "heat_template_version:".
-
-R-39402 A VNF's Heat Orchestration Template **MUST**
-contain the section "description:".
-
-R-35414 A VNF Heat Orchestration's template **MUST**
-contain the section "parameters:".
-
-R-90279 A VNF Heat Orchestration's template's parameter **MUST**
-be used in a resource with the exception of the parameters
-for the OS::Nova::Server resource property availability_zone.
-
-R-91273 A VNF Heat Orchestration’s template’s parameter for
-the OS::Nova::Server resource property availability_zone
-**MAY NOT** be used in any OS::Nova::Resource.
-
-R-25877 A VNF's Heat Orchestration Template's parameter
-name (i.e., <param name>) **MUST** contain only
-alphanumeric characters and underscores ('_').
-
-R-36772 A VNF’s Heat Orchestration Template’s parameter
-**MUST** include the attribute “type:”.
-
-R-11441 A VNF’s Heat Orchestration Template’s parameter
-type **MUST** be one of the following values: "string",
-"number", "json", "comma_delimited_list" or "boolean".
-
-R-32094 A VNF's Heat Orchestration Template parameter
-declaration **MAY** contain the attribute "label:"
-
-R-44001 A VNF's Heat Orchestration Template parameter
-declaration **MUST** contain the attribute "description".
-
-R-90526 A VNF Heat Orchestration Template parameter
-declaration **MUST** not contain the default attribute.
-
-R-26124 If a VNF Heat Orchestration Template parameter
-requires a default value, it **MUST** be enumerated in the environment file.
-
-R-32557 A VNF's Heat Orchestration Template parameter
-declaration MAY contain the attribute "hidden:".
-
-R-88863 A VNF's Heat Orchestration Template's parameter defined as
-type "number" **MUST** have a parameter constraint of "range" or
-"allowed_values" defined.
-
-R-40518 A VNF's Heat Orchestration Template’s parameter defined as
-type "string" **MAY** have a parameter constraint defined.
-
-R-96227 A VNF's Heat Orchestration Template’s parameter defined as
-type "json" **MAY** have a parameter constraint defined.
-
-R-79817 A VNF's Heat Orchestration Template’s parameter defined as
-type "comma_delimited_list" **MAY** have a parameter constraint defined.
-
-R-06613 A VNF's Heat Orchestration Template’s parameter defined as
-type "boolean" **MAY** have a parameter constraint defined.
-
-R-00011 A VNF's Heat Orchestration Template's Nested YAML files
-parameter's **MUST NOT** have a parameter constraint defined.
-
-R-22589 A VNF’s Heat Orchestration Template parameter declaration
-**MAY** contain the attribute "immutable:".
-
-R-23664 A VNF's Heat Orchestration template **MUST** contain
-the section "resources:".
-
-R-90152 A VNF's Heat Orchestration Template's "resources:"
-section **MUST** contain the declaration of at least one resource.
-
-R-40551 A VNF's Heat Orchestration Template's Nested YAML files
-**MAY** contain the section "resources:".
-
-R-75141 A VNF's Heat Orchestration Template's resource name
-(i.e., <resource ID>) **MUST** only contain alphanumeric
-characters and underscores ('_').
-
-R-16447 A VNF's <resource ID> **MUST** be unique across all
-Heat Orchestration Templates and all HEAT Orchestration Template
-Nested YAML files that are used to create the VNF.
-
-R-53952 A VNF’s Heat Orchestration Template’s Resource
-**MUST NOT** reference a HTTP-based resource definitions.
-
-R-71699 A VNF’s Heat Orchestration Template’s Resource
-**MUST NOT** reference a HTTP-based Nested YAML file.
-
-R-10834 If a VNF Heat Orchestration Template resource attribute
-"property:" uses a nested "get_param", one level of nesting is
-supported and the nested "get_param" **MUST** reference an index
-
-R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
-resource **MUST** contain the attribute "metadata".
-
-R-46968 VNF’s Heat Orchestration Template’s Resource **MAY**
-declare the attribute “depends_on:”.
-
-R-63137 VNF’s Heat Orchestration Template’s Resource **MAY**
-declare the attribute “update_policy:”.
-
-R-43740 A VNF’s Heat Orchestration Template’s Resource
-**MAY** declare the attribute “deletion_policy:”.
-
-R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY**
-declare the attribute “external_id:”.
-
-R-36982 A VNF’s Heat Orchestration template **MAY** contain the
-“outputs:” section.
-
-R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
-environment file, even if no parameters are required to be enumerated.
-
-R-86285 The VNF Heat Orchestration Template **MUST** have a
-corresponding environment file, even if no parameters are required to be
-enumerated.
-
-R-03324 The VNF Heat Orchestration Template **MUST** contain the
-"parameters" section in the
-environment file
-
-R-68198 A VNF’s Heat Orchestration template’s Environment File’s
-“parameters:” section **MAY** enumerate parameters.
-
-R-59930 A VNF’s Heat Orchestration template’s Environment
-File’s **MAY** contain the “parameter_defaults:” section.
-
-R-46096 A VNF’s Heat Orchestration template’s Environment File’s
-**MAY** contain the “encrypted_parameters:” section.
-
-R-24893 A VNF’s Heat Orchestration template’s Environment File’s
-**MAY** contain the “event_sinks:” section.
-
-R-42685 A VNF’s Heat Orchestration template’s Environment File’s
-**MAY** contain the “parameter_merge_strategies:” section.
-
-R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
-contain the “resource_registry:” section.
-
-R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
-Templates, each of which represents a subset of the overall VNF.
-
-R-33132 A VNF’s Heat Orchestration Template **MAY** be 1.) Base Module
-Heat Orchestration Template (also referred to as a Base Module), 2.)
-Incremental Module Heat Orchestration Template (referred to as an Incremental
-Module), or 3.) a Cinder Volume Module Heat Orchestration Template
-(referred to as Cinder Volume Module).
-
-R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
-
-R-28980 A VNF’s incremental module **MAY** be used for initial VNF
-deployment only.
-
-R-86926 A VNF’s incremental module **MAY** be used for scale out only.
-
-R-91497 A VNF’s incremental module **MAY** be used for both deployment
-and scale out.
-
-R-68122 A VNF’s incremental module **MAY** be deployed more than once,
-either during initial VNF deployment and/or scale out.
-
-R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume
-**MAY** be defined in a Base Module.
-
-R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
-**MAY** be defined in an Incremental Module.
-
-R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
-**MAY** be defined in a Cinder Volume Module.
-
-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-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-36582 A VNF’s Base Module **MAY** utilize nested heat.
-
-R-56721 A VNF’s Incremental Module **MAY** utilize nested heat.
-
-R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat.
-
-R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST**
-be in the lower case format ‘.yaml’ or ‘.yml’.
-
-R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension
-**MUST** be in the lower case format ‘.yaml’ or ‘.yml’.
-
-R-74304 A VNF’s Heat Orchestration Template’s Environment file extension
-**MUST** be in the lower case format ‘.env’.
-
-R-81339 A VNF Heat Orchestration Template’s Base Module file name **MUST**
-include ‘base’ in the filename and **MUST** match one of the following four
-formats: 1.) ‘base_<text>.y[a]ml’, 2.) ‘<text>_base.y[a]ml’, 3.)
-‘base.y[a]ml’, or 4.) ‘<text>_base_<text>’.y[a]ml; where ‘base’ is case
-insensitive and where ‘<text>’ **MUST** contain only alphanumeric characters
-and underscores ‘_’ and **MUST NOT** contain the case insensitive word ‘base’.
-
-R-91342 A VNF Heat Orchestration Template’s Base Module’s Environment File
-**MUST** be named identical to the VNF Heat Orchestration Template’s Base
-Module with ‘.y[a]ml’ replaced with ‘.env’.
-
-R-87247 A VNF Heat Orchestration Template’s Incremental Module file name
-**MUST** contain only alphanumeric characters and underscores ‘_’ and
-**MUST NOT** contain the case insensitive word ‘base’.
-
-R-94509 A VNF Heat Orchestration Template’s Incremental Module’s Environment
-File **MUST** be named identical to the VNF Heat Orchestration Template’s
-Incremental Module with ‘.y[a]ml’ replaced with ‘.env’.
-
-R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be
-named identical to the base or incremental module it is supporting with
-‘_volume appended’
-
-R-31141 A VNF Heat Orchestration Template’s Cinder Volume Module’s Environment
-File **MUST** be named identical to the VNF Heat Orchestration Template’s
-Cinder Volume Module with .y[a]ml replaced with ‘.env’.
-
-R-76057 A VNF Heat Orchestration Template’s Nested YAML file name **MUST**
-contain only alphanumeric characters and underscores ‘_’ and **MUST NOT**
-contain the case insensitive word ‘base’.
-
-R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties
-all parameter values
-associated with the nested heat file in the resource definition defined
-in the parent heat template.
-
-R-52753 VNF’s Heat Orchestration Template’s Base Module’s output parameter’s
-name and type **MUST** match the VNF’s Heat Orchestration Template’s
-incremental Module’s name and type unless the output parameter is of type
-‘comma_delimited_list’, then the corresponding input parameter **MUST**
-be declared as type ‘json’.
-
-R-22608 When a VNF’s Heat Orchestration Template’s Base Module’s output
-parameter is declared as an input parameter in an Incremental Module,
-the parameter attribute ‘constraints:’ **MUST NOT** be declared.
-
-R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output
-Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in
-template, while other Output Parameters **MAY** be included.
-
-R-07443 A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output
-Parameter’s name and type **MUST** match the input parameter name and type
-in the corresponding Base Module or Incremental Module unless the Output
-Parameter is of the type ‘comma_delimited_list’, then the corresponding input
-parameter **MUST** be declared as type ‘json’.
-
-R-20547 When an ONAP Volume Module Output Parameter is declared as an input
-parameter in a base or an incremental module Heat Orchestration Template,
-parameter constraints **MUST NOT** be declared.
-
-R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to
-utilize the OpenStack ‘heat stack-update’ command for scaling
-(growth/de-growth).
-
-R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template
-design to support scaling (growth/de-growth).
-
-R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance
-specific or Cloud site specific
-
-R-56750 A VNF’s Heat Orchestration Template’s parameter values that are
-constant across all deployments **MUST** be declared in a Heat Orchestration
-Template Environment File.
-
-R-01896 A VNF’s Heat Orchestration Template’s parameter values that are
-constant across all deployments **MUST** be declared in a Heat Orchestration
-Template Environment File.
-
-R-16968 A VNF’s Heat Orchestration Templates **MUST NOT** include heat
-resources to create external networks.
-
-R-00606 A VNF **MAY** be connected to zero, one or more than one external
-networks.
-
-R-57424 A VNF’s port connected to an external network **MUST** connect the
-port to VMs in another VNF and/or an external gateway and/or external router.
-
-R-29865 A VNF’s port connected to an external network **MUST NOT** connect
-the port to VMs in the same VNF.
-
-R-69014 When a VNF connects to an external network, a network role, referred
-to as the ‘{network-role}’ **MUST** be assigned to the external network
-for use in the VNF’s Heat Orchestration Template.
-
-R-05201 When a VNF connects to two or more external networks, each external
-network **MUST** be assigned a unique ‘{network-role}’ in the context of
-the VNF for use in the VNF’s Heat Orchestration Template.
-
-R-83015 A VNF’s ‘{network-role}’ assigned to an external network **MUST**
-be different than the ‘{network-role}’ assigned to the VNF’s internal
-networks, if internal networks exist.
-
-R-87096 A VNF **MAY** contain zero, one or more than one internal networks.
-
-R-35666 If a VNF has an internal network, the VNF Heat Orchestration
-Template **MUST** include the heat resources to create the internal network.
-
-R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat
-Orchestration Template Base Module.
-
-R-52425 A VNF’s port connected to an internal network **MUST** connect
-the port to VMs in the same VNF.
-
-R-46461 A VNF’s port connected to an internal network **MUST NOT** connect
-the port to VMs in another VNF and/or an external gateway and/or
-external router.
-
-R-68936 When a VNF creates an internal network, a network role, referred to
-as the ‘{network-role}’ **MUST** be assigned to the internal network for
-use in the VNF’s Heat Orchestration Template.
-
-R-32025 When a VNF creates two or more internal networks, each internal
-network **MUST** be assigned a unique ‘{network-role}’ in the context of
-the VNF for use in the VNF’s Heat Orchestration Template.
-
-R-69874 A VNF’s ‘{network-role}’ assigned to an internal network **MUST**
-be different than the ‘{network-role}’ assigned to the VNF’s external
-networks.
-
-R-34726 If a VNF’s port is connected to an internal network and the port
-is created in the same Heat Orchestration Template as the internal network,
-then the port resource **MUST** use a ‘get_resource’ to obtain
-the network UUID.
-
-R-22688 If a VNF’s port is connected to an internal network and the
-port is created in an Incremental Module and the internal network is created
-in the Base Module then the UUID of the internal network **MUST** be exposed
-as a parameter in the ‘outputs:’ section of the Base Module and the port
-resource **MUST** use a ‘get_param’ to obtain the network UUID.
-
-R-01455 When a VNF's Heat Orchestration Template creates a
-Virtual Machine (i.e., 'OS::Nova::Server'),
-each 'class' of VMs **MUST** be assigned a VNF unique
-'{vm-type}'; where 'class' defines VMs that **MUST** have the following
-identical characteristics:
-
-R-82481 A VNF's Heat Orchestration Template's Resource
-property parameter that is associated with a unique Virtual
-Machine type **MUST** include '{vm-type}' as part of the
-parameter name with two exceptions:
-
-R-66729 A VNF’s Heat Orchestration Template’s Resource that is
-associated with a unique Virtual Machine type **MUST** include
-‘{vm-type}’ as part of the resource ID.
-
-R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
-only alphanumeric characters and/or underscores '_' and
-**MUST NOT** contain any of the following strings: '_int' or 'int\_'
-or '\_int\_'.
-
-R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
-substring of {network-role}.
-
-R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’
-in all Resource property parameter names **MUST** be the same case.
-
-R-46839 A VNF’s Heat Orchestration Template’s use of
-‘{vm-type}’ in all Resource IDs **MUST** be the same case.
-
-R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in
-Resource property parameter names **SHOULD** match the case of
-‘{vm-type}’ in Resource IDs and vice versa.
-
-R-21330 A VNF’s Heat Orchestration Template’s Resource property parameter
-that is associated with external network **MUST** include the
-‘{network-role}’’ as part of the parameter name
-
-R-11168 A VNF's Heat Orchestration Template's Resource ID that is
-associated with an external network **MUST** include the
-'{network-role}' as part of the resource ID.
-
-R-84322 A VNF's Heat Orchestration Template's Resource property
-parameter that is associated with an internal network
-**MUST** include 'int\_{network-role}' as part of the parameter
-name, where 'int\_' is a hard coded string.
-
-R-96983 A VNF's Heat Orchestration Template's Resource ID that is
-associated with an internal network **MUST** include
-'int\_{network-role}' as part of the Resource ID, where
-'int\_' is a hard coded string.
-
-R-26506 A VNF's Heat Orchestration Template's '{network-role}'
-**MUST** contain only alphanumeric characters and/or
-underscores '_' and **MUST NOT** contain any of the following
-strings: '_int' or 'int\_' or '\_int\_'.
-
-R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’
-**MUST NOT** be a substring of ‘{vm-type}’.
-
-R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
-in all Resource property parameter names **MUST** be the same case
-
-R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
-in all Resource IDs **MUST** be the same case.
-
-R-86588 A VNF’s Heat Orchestration Template’s ‘{network-role}’ case
-in Resource property parameter names **SHOULD** match the case
-of ‘{network-role}’ in Resource IDs and vice versa.
-
-R-54517 When a VNF’s Heat Orchestration Template’s resource is associated
-with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’.
-
-R-96482 When a VNF’s Heat Orchestration Template’s resource is associated
-with a single external network, the Resource ID MUST contain the text
-‘{network-role}’.
-
-R-98138 When a VNF’s Heat Orchestration Template’s resource is associated
-with a single internal network, the Resource ID MUST contain the text
-‘int\_{network-role}’.
-
-R-82115 When a VNF's Heat Orchestration Template's resource is associated
-with a single '{vm-type}' and a single external network, the Resource
-ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
-
-- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
- be separated by an underscore '_'
-
- - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}'
-
-- note that an '{index}' value **MAY** separate the '{vm-type}' and the
- '{network-role}' and when this occurs underscores **MUST** separate the
- three values.
-
-R-82551 When a VNF's Heat Orchestration Template's resource is associated
-with a single '{vm-type}' and a single internal network, the Resource ID
-**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
-
-- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
- **MUST** be separated by an underscore '_'
-
- - (e.g., '{vm-type}\_int\_{network-role}',
- '{vm-type}_{index}\_int\_{network-role}')
-
-- note that an '{index}' value **MAY** separate the '{vm-type}' and the
- 'int\_{network-role}' and when this occurs underscores **MUST** separate
- the three values.
-
-R-67793 When a VNF’s Heat Orchestration Template’s resource is associated
-with more than one ‘{vm-type}’ and/or more than one internal and/or
-external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’
-and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the
-term ‘shared’ and/or contain text that identifies the VNF
-
-R-27970 When a VNF’s Heat Orchestration Template’s resource is associated
-with more than one ‘{vm-type}’ and/or more than one internal and/or
-external network, the Resource ID **MAY** contain the term ‘shared’
-and/or **MAY** contain text that identifies the VNF.
-
-R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains
-an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’
-**MUST** start at zero and increment by one.
-
-R-71152 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as
-type: ‘string’.
-
-R-58670 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the
-naming convention ‘{vm-type}_image_name’.
-
-R-91125 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in
-the Heat Orchestration Template’s Environment File and a value **MUST** be
-assigned.
-
-R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’
-**MUST** have a unique parameter name for the ‘OS::Nova::Server’
-property ‘image’ even if more than one {vm-type} shares the same image.
-
-R-50436 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as
-type: ‘string’.
-
-R-45188 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the
-naming convention ‘{vm-type}_flavor_name’.
-
-R-69431 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the
-Heat Orchestration Template’s Environment File and a value **MUST** be
-assigned.
-
-R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST**
-have a unique parameter name for the ‘OS::Nova::Server’ property
-‘flavor’ even if more than one {vm-type} shares the same flavor.
-
-R-51430 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as
-either type ‘string’ or type ‘comma_delimited_list”.
-
-R-54171 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
-the parameter name **MUST** follow the naming convention
-‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts
-at zero and increments by one.
-
-R-40899 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
-a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource
-associated with the ‘{vm-type}’.
-
-R-87817 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘name’ parameter is defined as a
-‘comma_delimited_list’, the parameter name **MUST** follow the naming
-convention ‘{vm-type}_names’.
-
-R-85800 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘name’ parameter is defined as a
-‘comma_delimited_list’, a parameter **MUST** be delcared once for all
-‘OS::Nova::Server’ resources associated with the ‘{vm-type}’.
-
-R-22838 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated
-in the Heat Orchestration Template’s Environment File.
-
-R-44271 The VNF's Heat Orchestration Template's Resource
-'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
-contain special characters since the Contrail GUI has a limitation
-displaying special characters.
-
-R-98450 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘availability_zone’ parameter name
-**MUST** follow the naming convention ‘availability\_zone\_{index}’
-where the ‘{index}’ **MUST** start at zero and increment by one.
-
-R-23311 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST**
-be declared as type: ‘string’.
-
-R-59568 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT**
-be enumerated in the Heat Orchestration Template’s Environment File.
-
-R-01359 A VNF’s Heat Orchstration Template that contains an
-‘OS::Nova:Server’ Resource **MAY** define a parameter for the property
-‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’
-resources in the Heat Orchestration Template.
-
-R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine
-(i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
-boot from a Cinder Volume.
-
-R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine
-(i.e., ‘OS::Nova::Server’ Resource) boots from an image, the
-‘OS::Nova::Server’ resource property ‘image’ **MUST** be used.
-
-R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine
-(i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the
-‘OS::Nova::Server’ resource property ‘block_device_mapping’ or
-‘block_device_mapping_v2’ **MUST** be used.
-
-R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **MUST** contain the metadata map value parameter ‘vnf_id’.
-
-R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_id’ **MUST** be declared
-as type: ‘string’.
-
-R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have
-parameter contraints defined.
-
-R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be
-enumerated in the Heat Orchestration Template’s environment file.
-
-R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_id’ is passed into a
-Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change.
-
-R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **MUST** contain the metadata map value parameter
-‘vf\_module\_id’.
-
-R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_id’ **MUST**
-be declared as type: ‘string’.
-
-R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
-have parameter contraints defined.
-
-R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
-be enumerated in the Heat Orchestration Template’s environment file.
-
-R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf_module_id’ is passed
-into a Nested YAML file, the parameter name ‘vf\_module\_id’
-**MUST NOT** change.
-
-R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **MUST** contain the metadata map value parameter
-‘vnf_name’.
-
-R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_name’ **MUST** be
-declared as type: ‘string’.
-
-R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have
-parameter contraints defined.
-
-R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be
-enumerated in the Heat Orchestration Template’s environment file.
-
-R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_name’ is passed into a
-Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change.
-
-R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **SHOULD** contain the metadata map value parameter
-‘vf\_module\_name’.
-
-R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_name’ **MUST**
-be declared as type: ‘string’.
-
-R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_name’
-**MUST NOT** have parameter contraints defined.
-
-R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_name’
-**MUST NOT** be enumerated in the Heat Orchestration Template’s
-environment file.
-
-R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_name’ is passed
-into a Nested YAML file, the parameter name ‘vf\_module\_name’
-**MUST NOT** change.
-
-R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **MAY** contain the metadata map value parameter ‘vm_role’.
-
-R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vm_role’ **MUST** be
-declared as type: ‘string’.
-
-R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vm_role’ **MUST NOT** have
-parameter contraints defined.
-
-R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vnf_name’ **MUST** be
-either
-
- - enumerated in the VNF’s Heat Orchestration
- Template’s environment file.
-
- - hard coded in the VNF’s Heat Orchestration
- Template’s OS::Nova::Resource metadata property.
-
-R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vm_role’ value **MUST only**
-contain alphanumeric characters and underscores ‘_’.
-
-R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vm_role’ is passed into a
-Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change.
-
-R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **MAY** contain the metadata map value parameter
-‘vf\_module\_index’.
-
-R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be
-declared as type: ‘number’.
-
-R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
-have parameter contraints defined.
-
-R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
-be enumerated in the Heat Orchestration Template’s environment file.
-
-R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_index’ is passed
-into a Nested YAML file, the parameter name ‘vf\_module\_index’
-**MUST NOT** change.
-
-R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be
-used in a VNF’s Volume Template; it is not supported.
-
-R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **SHOULD** contain the metadata map value parameter
-‘workload_context’.
-
-R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘workload_context’ **MUST** be
-declared as type: ‘string’.
-
-R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘workload_context’ **MUST NOT**
-have parameter contraints defined.
-
-R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘workload_context’ **MUST NOT**
-be enumerated in the Heat Orchestration Template’s environment file.
-
-R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘workload_context’ is passed
-into a Nested YAML file, the parameter name ‘workload_context’
-**MUST NOT** change.
-
-R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource **SHOULD** contain the metadata map value parameter
-‘environment_context’.
-
-R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘environment_context’ **MUST**
-be declared as type: ‘string’.
-
-R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘environment_context’ **MUST NOT**
-have parameter contraints defined.
-
-R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘environment_context’ **MUST NOT**
-be enumerated in the Heat Orchestration Template’s environment file.
-
-R-62954 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
-Resource metadata map value parameter ‘environment_context’ is
-passed into a Nested YAML file, the parameter name
-‘environment_context’ **MUST NOT** change.
-
-R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
-property ‘network’ parameter **MUST** be declared as type: ‘string’.
-
-R-62983 When the VNF’s Heat Orchestration Template’s
-Resource ‘OS::Neutron::Port’ is attaching to an external
-network, the ‘network’ parameter name **MUST**
-
-- follow the naming convention ‘{network-role}_net_id’ if the Neutron
- network UUID value is used to reference the network
-- follow the naming convention ‘{network-role}_net_name’ if the OpenStack
- network name is used to reference the network.
-
-where ‘{network-role}’ is the network-role of the external network and
-a ‘get_param’ **MUST** be used as the intrinsic function.
-
-R-86182 When the VNF’s Heat Orchestration Template’s
-Resource ‘OS::Neutron::Port’ is attaching to an internal
-network, and the internal network is created in a different
-Heat Orchestration Template than the ‘OS::Neutron::Port’, the
-‘network’ parameter name **MUST**
-
-- follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron
- network UUID value is used to reference the network
-- follow the naming convention ‘int\_{network-role}_net_name’ if the
- OpenStack network name in is used to reference the network.
-
-where ‘{network-role}’ is the network-role of the internal network
-and a ‘get_param’ **MUST** be used as the intrinsic function.
-
-R-93177 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an internal network, and
-the internal network is created in the same Heat
-Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
-parameter name **MUST** obtain the UUID of the internal network by using
-the intrinsic function ‘get_resource’ or ‘get_attr’ and referencing the
-Resource ID of the internal network.
-
-R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’
-property ‘network’ parameter **MUST NOT** be enumerated in the Heat
-Orchestration Template’s Environment File.
-
-R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
-property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST** be
-declared as either type ‘string’ or type ‘comma_delimited_list’.
-
-R-40971 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an external network, and an
-IPv4 address is assigned using the property
-‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined
-as a string, the parameter name **MUST** follow the naming
-convention ‘{vm-type}_{network-role}\_ip\_{index}’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the external network
-- the value for {index} must start at zero (0) and increment by one
-
-R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
-property ‘fixed_ips’ map property ‘ip_address’ parameter
-‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the
-VNF’s Heat Orchestration Template’s Environment File.
-
-R-04697 When the VNF’s Heat Orchestration Template’s
-Resource ‘OS::Neutron::Port’ is attaching to an external
-network, and an IPv4 address is assigned using the property
-‘fixed_ips’ map property ‘ip_address’ and the parameter type
-is defined as a comma_delimited_list, the parameter name **MUST**
-follow the naming convention ‘{vm-type}_{network-role}_ips’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the external network
-
-R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
-property ‘fixed_ips’ map property ‘ip_address’ parameter
-‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s
-Heat Orchestration Template’s Environment File.
-
-R-71577 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address
-is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
-the parameter type is defined as a string, the parameter name **MUST** follow
-the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the external network
-- the value for {index} must start at zero (0) and increment by one
-
-R-87123 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’
-**MUST NOT** be enumerated in the VNF’s Heat Orchestration
-Template’s Environment File.
-
-R-23503 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
-address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
-and the parameter type is defined as a comma_delimited_list, the parameter
-name **MUST** follow the naming convention
-‘{vm-type}_{network-role}_v6_ips’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the external network
-
-R-93030 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the
-VNF’s Heat Orchestration Template’s Environment File.
-
-R-78380 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address
-is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
-the parameter type is defined as a string, the parameter name **MUST** follow
-the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the internal network
-- the value for {index} must start at zero (0) and increment by one
-
-R-28795 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated
-in the VNF’s Heat Orchestration Template’s Environment File.
-
-R-85235 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4
-address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
-and the parameter type is defined as a comma_delimited_list, the parameter
-name **MUST** follow the naming convention
-‘{vm-type}\_int\_{network-role}_ips’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the internal network
-
-R-90206 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in
-the VNF’s Heat Orchestration Template’s Environment File.
-
-R-27818 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address
-is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
-the parameter type is defined as a string, the parameter name **MUST** follow
-the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the internal network
-- the value for {index} must start at zero (0) and increment by one
-
-R-97201 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’
-**MUST** be enumerated in the VNF’s Heat Orchestration Template’s
-Environment File.
-
-R-29765 When the VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6
-address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
-and the parameter type is defined as a comma_delimited_list, the parameter
-name **MUST** follow the naming convention
-‘{vm-type}\_int\_{network-role}_v6_ips’, where
-
-- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
-- ‘{network-role}’ is the {network-role} of the internal network
-
-R-98569 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in
-the VNF’s Heat Orchestration Template’s Environment File.
-
-R-62590 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter associated with an external network, i.e.,
-
-- {vm-type}_{network-role}\_ip\_{index}
-- {vm-type}_{network-role}\_ip\_v6\_{index}
-- {vm-type}_{network-role}_ips
-- {vm-type}_{network-role}_v6_ips
-
-**MUST NOT** be enumerated in the Heat Orchestration Template’s
-Environment File. ONAP provides the IP address assignments at
-orchestration time.
-
-R-93496 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
-parameter associated with an internal network, i.e.,
-
-- {vm-type}\_int\_{network-role}\_ip\_{index}
-- {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
-- {vm-type}\_int\_{network-role}_ips
-- {vm-type}\_int\_{network-role}_v6_ips
-
-**MUST** be enumerated in the Heat Orchestration Template’s Environment
-File and IP addresses **MUST** be assigned.
-
-R-38236 The VNF’s Heat Orchestration Template’s resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property
-‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’.
-
-R-62802 When the VNF’s Heat Orchestration Template’s resource
-‘OS::Neutron::Port’ is attaching to an external network, and an IPv4
-address is being Cloud Assigned by OpenStack’s DHCP Service and the
-external network IPv4 subnet is to be specified using the property
-‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
-follow the naming convention ‘{network-role}_subnet_id’, where
-‘{network-role}’ is the network role of the network.
-
-R-83677 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property
-subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’
-**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
-Environment File.
-
-R-15287 When the VNF’s Heat Orchestration Template’s resource
-‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
-address is being Cloud Assigned by OpenStack’s DHCP Service and the
-external network IPv6 subnet is to be specified using the property
-‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
-follow the naming convention ‘{network-role}_subnet_v6_id’, where
-‘{network-role}’ is the network role of the network.
-
-R-80829 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property
-subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’
-**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
-Environment File.
-
-R-84123 When
-
-- the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
- in an Incremental Module is attaching to an internal network
- that is created in the Base Module, AND
-- an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND
-- the internal network IPv4 subnet is to be specified using the
- property ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
-
-the parameter **MUST** follow the naming convention
-‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the
-network role of the internal network
-
-- Note that the parameter **MUST** be defined as an ‘output’ parameter in
- the base module.
-
-R-69634 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property
-subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’
-**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
-Environment File.
-
-R-76160 When
-
-- the VNF’s Heat Orchestration Template’s resource
- ‘OS::Neutron::Port’ in an Incremental Module is attaching to an
- internal network that is created in the Base Module, AND
-- an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND
-- the internal network IPv6 subnet is to be specified using the property
- ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
-
-the parameter **MUST** follow the naming convention
-‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’
-is the network role of the internal network
-
-- Note that the parameter **MUST** be defined as an ‘output’ parameter in
- the base module.
-
-R-22288 The VNF’s Heat Orchestration Template’s Resource
-‘OS::Neutron::Port’ property ‘fixed_ips’ map property
-‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’
-**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
-Environment File.
-
-R-61282 The VNF Heat Orchestration Template **MUST**
-adhere to the following naming convention for the property
-allowed\_address\_pairs and Map Property ip\_address parameter,
-when the parameter is referencing an “external” network:
-
-- {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
-
-- {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
-
-R-16805 The VNF Heat Orchestration Template **MUST** adhere to the
-following naming convention for the property allowed\_address\_pairs
-and Map Property ip\_address parameter when the parameter is
-referencing an “internal” network.
-
-R-85734 The VNF Heat Orchestration Template **MUST** use the
-intrinsic function str\_replace in conjunction with the ONAP
-supplied metadata parameter vnf\_name to generate a unique value,
-when the property name for a non OS::Nova::Server resources is defined
-in a Heat Orchestration Template.
-
-R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1
-scope of a cinder volume module, when it exists, with the Base
-Module or Incremental Module
-
-R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
-environment file, even if no parameters are required to be enumerated.
-
-R-86285 The VNF Heat Orchestration Template **MUST** have a
-corresponding environment file, even if no parameters are required to be
-enumerated.
-
-R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
-environment file for a Base Module.
-
-R-35727 The VNF Heat Orchestration Template **MUST** have a
-corresponding environment file for an Incremental module.
-
-R-22656 The VNF Heat Orchestration Template **MUST** have a
-corresponding environment file for a Cinder Volume Module.
-
-R-89868 The VNF Heat Orchestration Template **MUST** have unique
-file names within the scope of the VNF for a nested heat yaml file.
-
-R-52530 The VNF Heat Orchestration Template **MUST NOT** use a
-directory hierarchy for nested templates. All templates must be
-in a single, flat directory (per VNF).
-
-R-76718 The VNF Heat Orchestration Template **MUST** reference the
-get\_files targets in Heat templates by file name, and the corresponding
-files should be delivered to ONAP along with the Heat templates.
-
-R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
-
-R-62177 The VNF Heat Orchestration Template **MUST** have unique
-file names for the included files within the scope of the VNF.
-
-**ONAP Management Requirements**
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-
-VNF On-boarding and package management
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
-R-77707 The xNF provider **MUST** include a Manifest File that
-contains a list of all the components in the xNF package.
-
-R-66070 The xNF Package **MUST** include xNF Identification Data to
-uniquely identify the resource for a given xNF provider. The identification
-data must include: an identifier for the xNF, the name of the xNF as was
-given by the xNF provider, xNF description, xNF provider, and version.
-
-R-69565 The xNF Package **MUST** include documentation describing xNF
-Management APIs, which must include information and tools for ONAP to
-deploy and configure (initially and ongoing) the xNF application(s)
-(e.g., NETCONF APIs) which includes a description of configurable
-parameters for the xNF and whether the parameters can be configured
-after xNF instantiation.
-
-R-00156 The xNF Package **MUST** include documentation describing xNF
-Management APIs, which must include information and tools for ONAP
-to monitor the health of the xNF (conditions that require healing
-and/or scaling responses).
-
-R-00068 The xNF Package **MUST** include documentation which includes
-a description of parameters that can be monitored for the xNF and
-event records (status, fault, flow, session, call, control plane,
-etc.) generated by the xNF after instantiation.
-
-R-12678 The xNF Package **MUST** include documentation which includes a
-description of runtime lifecycle events and related actions (e.g.,
-control responses, tests) which can be performed for the xNF.
-
-R-84366 The xNF Package **MUST** include documentation describing
-xNF Functional APIs that are utilized to build network and
-application services. This document describes the externally exposed
-functional inputs and outputs for the xNF, including interface
-format and protocols supported.
-
-R-36280 The xNF provider **MUST** provide documentation describing
-xNF Functional Capabilities that are utilized to operationalize the
-xNF and compose complex services.
-
-R-98617 The xNF provider **MUST** provide information regarding any
-dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
-
-R-89571 The xNF **MUST** support and provide artifacts for configuration
-management using at least one of the following technologies;
-a) Netconf/YANG, b) Chef, or c) Ansible.
-
-R-30278 The xNF provider **MUST** provide a Resource/Device YANG model
-as a foundation for creating the YANG model for configuration. This will
-include xNF attributes/parameters and valid values/attributes configurable
-by policy.
-
-R-13390 The xNF provider **MUST** provide cookbooks to be loaded
-on the appropriate Chef Server.
-
-R-18525 The xNF provider **MUST** provide a JSON file for each
-supported action for the xNF. The JSON file must contain key value
-pairs with all relevant values populated with sample data that illustrates
-its usage. The fields and their description are defined in Tables A1
-and A2 in the Appendix.
-
-R-75608 The xNF provider **MUST** provide playbooks to be loaded
-on the appropriate Ansible Server.
-
-R-16777 The xNF provider **MUST** provide a JSON file for each
-supported action for the xNF. The JSON file must contain key value
-pairs with all relevant values populated with sample data that illustrates
-its usage. The fields and their description are defined in Table B1 in
-the Appendix.
-
-R-46567 The xNF Package **MUST** include configuration scripts
-for boot sequence and configuration.
-
-R-16065 The xNF provider **MUST** provide configurable parameters
-(if unable to conform to YANG model) including xNF attributes/parameters
-and valid values, dynamic attributes and cross parameter dependencies
-(e.g., customer provisioning data).
-
-R-22888 The xNF provider **MUST** provide documentation for the xNF
-Policy Description to manage the xNF runtime lifecycle. The document
-must include a description of how the policies (conditions and actions)
-are implemented in the xNF.
-
-R-01556 The xNF Package **MUST** include documentation describing the
-fault, performance, capacity events/alarms and other event records
-that are made available by the xNF.
-
-R-16875 The xNF Package **MUST** include documentation which must include
-a unique identification string for the specific xNF, a description of
-the problem that caused the error, and steps or procedures to perform
-Root Cause Analysis and resolve the issue.
-
-R-35960 The xNF Package **MUST** include documentation which must include
-all events, severity level (e.g., informational, warning, error) and
-descriptions including causes/fixes if applicable for the event.
-
-R-42018 The xNF Package **MUST** include documentation which must include
-all events (fault, measurement for xNF Scaling, Syslogs, State Change
-and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
-
-R-27711 The xNF provider **MUST** provide an XML file that contains a
-list of xNF error codes, descriptions of the error, and possible
-causes/corrective action.
-
-R-01478 The xNF Package **MUST** include documentation describing all
-parameters that are available to monitor the xNF after instantiation
-(includes all counters, OIDs, PM data, KPIs, etc.) that must be
-collected for reporting purposes.
-
-R-73560 The xNF Package **MUST** include documentation about monitoring
-parameters/counters exposed for virtual resource management and xNF
-application management.
-
-R-90632 The xNF Package **MUST** include documentation about KPIs and
-metrics that need to be collected at each VM for capacity planning
-and performance management purposes.
-
-R-86235 The xNF Package **MUST** include documentation about the monitoring
-parameters that must include latencies, success rates, retry rates, load
-and quality (e.g., DPM) for the key transactions/functions supported by
-the xNF and those that must be exercised by the xNF in order to perform
-its function.
-
-R-33904 The xNF Package **MUST** include documentation for each KPI, provide
-lower and upper limits.
-
-R-53598 The xNF Package **MUST** include documentation to, when relevant,
-provide a threshold crossing alert point for each KPI and describe the
-significance of the threshold crossing.
-
-R-69877 The xNF Package **MUST** include documentation for each KPI,
-identify the suggested actions that need to be performed when a
-threshold crossing alert event is recorded.
-
-R-22680 The xNF Package **MUST** include documentation that describes
-any requirements for the monitoring component of tools for Network
-Cloud automation and management to provide these records to components
-of the xNF.
-
-R-33694 The xNF Package **MUST** include documentation to when applicable,
-provide calculators needed to convert raw data into appropriate reporting
-artifacts.
-
-R-56815 The xNF Package **MUST** include documentation describing
-supported xNF scaling capabilities and capacity limits (e.g., number
-of users, bandwidth, throughput, concurrent calls).
-
-R-48596 The xNF Package **MUST** include documentation describing
-the characteristics for the xNF reliability and high availability.
-
-R-74763 The xNF provider **MUST** provide an artifact per xNF that contains
-all of the xNF Event Records supported. The artifact should include reference
-to the specific release of the xNF Event Stream Common Event Data Model
-document it is based on. (e.g., `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
-
-R-35851 The xNF Package **MUST** include xNF topology that describes
-basic network and application connectivity internal and external to the
-xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
-applicable) for each interface.
-
-R-97102 The VNF Package **MUST** include VM requirements via a Heat
-template that provides the necessary data for VM specifications
-for all VNF components - for hypervisor, CPU, memory, storage.
-
-R-20204 The VNF Package **MUST** include VM requirements via a Heat
-template that provides the necessary data for network connections,
-interface connections, internal and external to VNF.
-
-R-44896 The VNF Package **MUST** include VM requirements via a Heat
-template that provides the necessary data for high availability
-redundancy model.
-
-R-55802 The VNF Package **MUST** include VM requirements via a Heat
-template that provides the necessary data for scaling/growth VM
-specifications.
-
-R-26881 The xNF provider **MUST** provide the binaries and images
-needed to instantiate the xNF (xNF and VNFC images).
-
-R-96634 The xNF provider **MUST** describe scaling capabilities
-to manage scaling characteristics of the xNF.
-
-R-43958 The xNF Package **MUST** include documentation describing
-the tests that were conducted by the xNF providor and the test results.
-
-R-04298 The xNF provider **MUST** provide their testing scripts to
-support testing.
-
-R-58775 The xNF provider **MUST** provide software components that
-can be packaged with/near the xNF, if needed, to simulate any functions
-or systems that connect to the xNF system under test. This component is
-necessary only if the existing testing environment does not have the
-necessary simulators.
-
-R-85653 The xNF **MUST** provide metrics (e.g., number of sessions,
-number of subscribers, number of seats, etc.) to ONAP for tracking
-every license.
-
-R-44125 The xNF provider **MUST** agree to the process that can
-be met by Service Provider reporting infrastructure. The Contract
-shall define the reporting process and the available reporting tools.
-
-R-40827 The xNF provider **MUST** enumerate all of the open
-source licenses their xNF(s) incorporate.
-
-R-97293 The xNF provider **MUST NOT** require audits of
-Service Provider’s business.
-
-R-44569 The xNF provider **MUST NOT** require additional
-infrastructure such as a xNF provider license server for xNF provider
-functions and metrics.
-
-R-13613 The VNF **MUST** provide clear measurements for licensing
-purposes to allow automated scale up/down by the management system.
-
-R-27511 The VNF provider **MUST** provide the ability to scale
-up a VNF provider supplied product during growth and scale down a
-VNF provider supplied product during decline without “real-time”
-restrictions based upon VNF provider permissions.
-
-R-85991 The xNF provider **MUST** provide a universal license key
-per xNF to be used as needed by services (i.e., not tied to a VM
-instance) as the recommended solution. The xNF provider may provide
-pools of Unique xNF License Keys, where there is a unique key for
-each xNF instance as an alternate solution. Licensing issues should
-be resolved without interrupting in-service xNFs.
-
-R-47849 The xNF provider **MUST** support the metadata about
-licenses (and their applicable entitlements) as defined in this
-document for xNF software, and any license keys required to authorize
-use of the xNF software. This metadata will be used to facilitate
-onboarding the xNF into the ONAP environment and automating processes
-for putting the licenses into use and managing the full lifecycle of
-the licenses. The details of this license model are described in
-Tables C1 to C8 in the Appendix. Note: License metadata support in
-ONAP is not currently available and planned for 1Q 2018.
-
-Configuration Management
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-R-20741 The xNF **MUST** support ONAP Controller’s **Configure** command.
-
-R-19366 The xNF **MUST** support ONAP Controller’s **ConfigModify** command.
-
-R-32981 The xNF **MUST** support ONAP Controller’s **ConfigBackup** command.
-
-R-48247 The xNF **MUST** support ONAP Controller’s **ConfigRestore** command.
-
-R-94084 The xNF **MUST** support ONAP Controller’s **ConfigScaleOut**
-command.
-
-R-56385 The xNF **MUST** support ONAP Controller’s **Audit** command.
-
-R-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic**
-command.
-
-R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic**
-command.
-
-R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication**
-command.
-
-R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication**
-command.
-
-R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck**
-command.
-
-R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware**
-command.
-
-R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck**
-command.
-
-R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup**
-command.
-
-R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut**
-command.
-
-R-11790 The VNF **MUST** support ONAP Controller’s
-**Restart (stop/start or reboot)** command.
-
-R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that
-moves container (VM) from a live Physical Server / Compute Node to
-another live Physical Server / Compute Node.
-
-R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command.
-
-R-76901 VNF MUST support a container rebuild mechanism based on existing
-image (e.g. Glance image in Openstack environment) or a snapshot.
-
-R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck**
-command.
-
-R-88026 The xNF **MUST** include a NETCONF server enabling
-runtime configuration and lifecycle management capabilities.
-
-R-95950 The xNF **MUST** provide a NETCONF interface fully defined
-by supplied YANG models for the embedded NETCONF server.
-
-R-73468 The xNF **MUST** allow the NETCONF server connection
-parameters to be configurable during virtual machine instantiation
-through Heat templates where SSH keys, usernames, passwords, SSH
-service and SSH port numbers are Heat template parameters.
-
-R-90007 The xNF **MUST** implement the protocol operation:
-**close-session()**- Gracefully close the current session.
-
-R-70496 The xNF **MUST** implement the protocol operation:
-**commit(confirmed, confirm-timeout)** - Commit candidate
-configuration datastore to the running configuration.
-
-R-18733 The xNF **MUST** implement the protocol operation:
-**discard-changes()** - Revert the candidate configuration
-datastore to the running configuration.
-
-R-44281 The xNF **MUST** implement the protocol operation:
-**edit-config(target, default-operation, test-option, error-option,
-config)** - Edit the target configuration datastore by merging,
-replacing, creating, or deleting new config elements.
-
-R-60106 The xNF **MUST** implement the protocol operation:
-**get(filter)** - Retrieve (a filtered subset of) the running
-configuration and device state information. This should include
-the list of xNF supported schemas.
-
-R-29488 The xNF **MUST** implement the protocol operation:
-**get-config(source, filter)** - Retrieve a (filtered subset of
-a) configuration from the configuration datastore source.
-
-R-11235 The xNF **MUST** implement the protocol operation:
-**kill-session(session)** - Force the termination of **session**.
-
-R-02597 The xNF **MUST** implement the protocol operation:
-**lock(target)** - Lock the configuration datastore target.
-
-R-96554 The xNF **MUST** implement the protocol operation:
-**unlock(target)** - Unlock the configuration datastore target.
-
-R-29324 The xNF **SHOULD** implement the protocol operation:
-**copy-config(target, source) -** Copy the content of the
-configuration datastore source to the configuration datastore target.
-
-R-88031 The xNF **SHOULD** implement the protocol operation:
-**delete-config(target) -** Delete the named configuration
-datastore target.
-
-R-97529 The xNF **SHOULD** implement the protocol operation:
-**get-schema(identifier, version, format) -** Retrieve the YANG schema.
-
-R-62468 The xNF **MUST** allow all configuration data to be
-edited through a NETCONF <edit-config> operation. Proprietary
-NETCONF RPCs that make configuration changes are not sufficient.
-
-R-01382 The xNF **MUST** allow the entire configuration of the
-xNF to be retrieved via NETCONF's <get-config> and <edit-config>,
-independently of whether it was configured via NETCONF or other
-mechanisms.
-
-R-28756 The xNF **MUST** support **:partial-lock** and
-**:partial-unlock** capabilities, defined in RFC 5717. This
-allows multiple independent clients to each write to a different
-part of the <running> configuration at the same time.
-
-R-83873 The xNF **MUST** support **:rollback-on-error** value for
-the <error-option> parameter to the <edit-config> operation. If any
-error occurs during the requested edit operation, then the target
-database (usually the running configuration) will be left unaffected.
-This provides an 'all-or-nothing' edit mode for a single <edit-config>
-request.
-
-R-68990 The xNF **MUST** support the **:startup** capability. It
-will allow the running configuration to be copied to this special
-database. It can also be locked and unlocked.
-
-R-68200 The xNF **MUST** support the **:url** value to specify
-protocol operation source and target parameters. The capability URI
-for this feature will indicate which schemes (e.g., file, https, sftp)
-that the server supports within a particular URL value. The 'file'
-scheme allows for editable local configuration databases. The other
-schemes allow for remote storage of configuration databases.
-
-R-20353 The xNF **MUST** implement both **:candidate** and
-**:writable-running** capabilities. When both **:candidate** and
-**:writable-running** are provided then two locks should be supported.
-
-R-11499 The xNF **MUST** fully support the XPath 1.0 specification
-for filtered retrieval of configuration and other database contents.
-The 'type' attribute within the <filter> parameter for <get> and
-<get-config> operations may be set to 'xpath'. The 'select' attribute
-(which contains the XPath expression) will also be supported by the
-server. A server may support partial XPath retrieval filtering, but
-it cannot advertise the **:xpath** capability unless the entire XPath
-1.0 specification is supported.
-
-R-83790 The xNF **MUST** implement the **:validate** capability
-
-R-49145 The xNF **MUST** implement **:confirmed-commit** If
-**:candidate** is supported.
-
-R-58358 The xNF **MUST** implement the **:with-defaults** capability
-[RFC6243].
-
-R-59610 The xNF **MUST** implement the data model discovery and
-download as defined in [RFC6022].
-
-R-93443 The xNF **MUST** define all data models in YANG [RFC6020],
-and the mapping to NETCONF shall follow the rules defined in this RFC.
-
-R-26115 The xNF **MUST** follow the data model upgrade rules defined
-in [RFC6020] section 10. All deviations from section 10 rules shall
-be handled by a built-in automatic upgrade mechanism.
-
-R-10716 The xNF **MUST** support parallel and simultaneous
-configuration of separate objects within itself.
-
-R-29495 The xNF **MUST** support locking if a common object is
-being manipulated by two simultaneous NETCONF configuration operations
-on the same xNF within the context of the same writable running data
-store (e.g., if an interface parameter is being configured then it
-should be locked out for configuration by a simultaneous configuration
-operation on that same interface parameter).
-
-R-53015 The xNF **MUST** apply locking based on the sequence of
-NETCONF operations, with the first configuration operation locking
-out all others until completed.
-
-R-02616 The xNF **MUST** permit locking at the finest granularity
-if a xNF needs to lock an object for configuration to avoid blocking
-simultaneous configuration operations on unrelated objects (e.g., BGP
-configuration should not be locked out if an interface is being
-configured or entire Interface configuration should not be locked out
-if a non-overlapping parameter on the interface is being configured).
-
-R-41829 The xNF **MUST** be able to specify the granularity of the
-lock via a restricted or full XPath expression.
-
-R-66793 The xNF **MUST** guarantee the xNF configuration integrity
-for all simultaneous configuration operations (e.g., if a change is
-attempted to the BUM filter rate from multiple interfaces on the same
-EVC, then they need to be sequenced in the xNF without locking either
-configuration method out).
-
-R-54190 The xNF **MUST** release locks to prevent permanent lock-outs
-when/if a session applying the lock is terminated (e.g., SSH session
-is terminated).
-
-R-03465 The xNF **MUST** release locks to prevent permanent lock-outs
-when the corresponding <partial-unlock> operation succeeds.
-
-R-63935 The xNF **MUST** release locks to prevent permanent lock-outs
-when a user configured timer has expired forcing the NETCONF SSH Session
-termination (i.e., product must expose a configuration knob for a user
-setting of a lock expiration timer)
-
-R-10173 The xNF **MUST** allow another NETCONF session to be able to
-initiate the release of the lock by killing the session owning the lock,
-using the <kill-session> operation to guard against hung NETCONF sessions.
-
-R-88899 The xNF **MUST** support simultaneous <commit> operations
-within the context of this locking requirements framework.
-
-R-07545 The xNF **MUST** support all operations, administration and
-management (OAM) functions available from the supplier for xNFs using
-the supplied YANG code and associated NETCONF servers.
-
-R-60656 The xNF **MUST** support sub tree filtering.
-
-R-80898 The xNF **MUST** support heartbeat via a <get> with null filter.
-
-R-25238 The xNF PACKAGE **MUST** validated YANG code using the open
-source pyang [2]_ program using the following commands:
-
-R-63953 The xNF **MUST** have the echo command return a zero value
-otherwise the validation has failed
-
-R-26508 The xNF **MUST** support a NETCONF server that can be mounted on
-OpenDaylight (client) and perform the operations of: modify, update,
-change, rollback configurations using each configuration data element,
-query each state (non-configuration) data element, execute each YANG
-RPC, and receive data through each notification statement.
-
-R-28545 The xNF **MUST** conform its YANG model to RFC 6060,
-“YANG - A Data Modeling Language for the Network Configuration
-Protocol (NETCONF)”
-
-R-22700 The xNF **MUST** conform its YANG model to RFC 6470,
-“NETCONF Base Notifications”.
-
-R-10353 The xNF **MUST** conform its YANG model to RFC 6244,
-“An Architecture for Network Management Using NETCONF and YANG”.
-
-R-53317 The xNF **MUST** conform its YANG model to RFC 6087,
-“Guidelines for Authors and Reviewers of YANG Data Model Documents”.
-
-R-33955 The xNF **SHOULD** conform its YANG model to RFC 6991,
-“Common YANG Data Types”.
-
-R-22946 The xNF **SHOULD** conform its YANG model to RFC 6536,
-“NETCONF Access Control Model”.
-
-R-10129 The xNF **SHOULD** conform its YANG model to RFC 7223,
-“A YANG Data Model for Interface Management”.
-
-R-12271 The xNF **SHOULD** conform its YANG model to RFC 7223,
-“IANA Interface Type YANG Module”.
-
-R-49036 The xNF **SHOULD** conform its YANG model to RFC 7277,
-“A YANG Data Model for IP Management”.
-
-R-87564 The xNF **SHOULD** conform its YANG model to RFC 7317,
-“A YANG Data Model for System Management”.
-
-R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407,
-“A YANG Data Model for SNMP Configuration”, if Netconf used to
-configure SNMP engine.
-
-R-33946 The xNF **MUST** conform to the NETCONF RFC 4741,
-“NETCONF Configuration Protocol”.
-
-R-04158 The xNF **MUST** conform to the NETCONF RFC 4742,
-“Using the NETCONF Configuration Protocol over Secure Shell (SSH)”.
-
-R-13800 The xNF **MUST** conform to the NETCONF RFC 5277,
-“NETCONF Event Notification”.
-
-R-01334 The xNF **MUST** conform to the NETCONF RFC 5717,
-“Partial Lock Remote Procedure Call”.
-
-R-08134 The xNF **MUST** conform to the NETCONF RFC 6241,
-“NETCONF Configuration Protocol”.
-
-R-78282 The xNF **MUST** conform to the NETCONF RFC 6242,
-“Using the Network Configuration Protocol over Secure Shell”.
-
-R-31809 The xNF **MUST** support the HealthCheck RPC. The HealthCheck
-RPC executes a xNF Provider-defined xNF HealthCheck over the scope of
-the entire xNF (e.g., if there are multiple VNFCs, then run a health check,
-as appropriate, for all VNFCs). It returns a 200 OK if the test completes.
-A JSON object is returned indicating state (healthy, unhealthy), scope
-identifier, time-stamp and one or more blocks containing info and fault
-information. If the xNF is unable to run the HealthCheck, return a
-standard http error code and message.
-
-R-79224 The xNF **MUST** have the chef-client be preloaded with
-validator keys and configuration to register with the designated
-Chef Server as part of the installation process.
-
-R-72184 The xNF **MUST** have routable FQDNs for all the endpoints
-(VMs) of a xNF that contain chef-clients which are used to register
-with the Chef Server. As part of invoking xNF actions, ONAP will
-trigger push jobs against FQDNs of endpoints for a xNF, if required.
-
-R-47068 The xNF **MAY** expose a single endpoint that is
-responsible for all functionality.
-
-R-67114 The xNF **MUST** be installed with Chef-Client >= 12.0 and
-Chef push jobs client >= 2.0.
-
-R-27310 The xNF Package **MUST** include all relevant Chef artifacts
-(roles/cookbooks/recipes) required to execute xNF actions requested by
-ONAP for loading on appropriate Chef Server.
-
-R-26567 The xNF Package **MUST** include a run list of
-roles/cookbooks/recipes, for each supported xNF action, that will
-perform the desired xNF action in its entirety as specified by ONAP
-(see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF
-actions and requirements), when triggered by a chef-client run list
-in JSON file.
-
-R-98911 The xNF **MUST NOT** use any instance specific parameters
-for the xNF in roles/cookbooks/recipes invoked for a xNF action.
-
-R-37929 The xNF **MUST** accept all necessary instance specific
-data from the environment or node object attributes for the xNF
-in roles/cookbooks/recipes invoked for a xNF action.
-
-R-62170 The xNF **MUST** over-ride any default values for
-configurable parameters that can be set by ONAP in the roles,
-cookbooks and recipes.
-
-R-78116 The xNF **MUST** update status on the Chef Server
-appropriately (e.g., via a fail or raise an exception) if the
-chef-client run encounters any critical errors/failures when
-executing a xNF action.
-
-R-44013 The xNF **MUST** populate an attribute, defined as node
-[‘PushJobOutput’] with the desired output on all nodes in the push job
-that execute chef-client run if the xNF action requires the output of a
-chef-client run be made available (e.g., get running configuration).
-
-R-30654 The xNF Package **MUST** have appropriate cookbooks that are
-designed to automatically ‘rollback’ to the original state in case of
-any errors for actions that change state of the xNF (e.g., configure).
-
-R-65755 The xNF **SHOULD** support callback URLs to return information
-to ONAP upon completion of the chef-client run for any chef-client run
-associated with a xNF action.
-
-R-15885 The xNF **MUST** Upon completion of the chef-client run,
-POST back on the callback URL, a JSON object as described in Table
-A2 if the chef-client run list includes a cookbook/recipe that is
-callback capable. Failure to POST on the Callback Url should not be
-considered a critical error. That is, if the chef-client successfully
-completes the xNF action, it should reflect this status on the Chef
-Server regardless of whether the Callback succeeded or not.
-
-R-32217 The xNF **MUST** have routable FQDNs that are reachable via
-the Ansible Server for the endpoints (VMs) of a xNF 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 xNF **MUST** have Python >= 2.6 on the endpoint VM(s)
-of a xNF on which an Ansible playbook will be executed.
-
-R-35401 The xNF **MUST** support SSH and allow SSH access by the
-Ansible server for the endpoint VM(s) and comply with the Network
-Cloud Service Provider guidelines for authentication and access.
-
-R-82018 The xNF **MUST** load the Ansible Server SSH public key onto xNF
-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 xNF login IDs
-and passwords.
-
-R-92866 The xNF **MUST** include as part of post-instantiation configuration
-done by Ansible Playbooks the removal/update of the SSH public key from
-/root/.ssh/authorized_keys, and update of SSH keys loaded through
-instantiation to support Ansible. This may include download and install of
-new SSH keys and new mechanized IDs.
-
-R-91745 The xNF **MUST** update the Ansible Server and other entities
-storing and using the SSH keys for authentication when the SSH keys used
-by Ansible are regenerated/updated.
-
-R-40293 The xNF **MUST** make available playbooks that conform
-to the ONAP requirement.
-
-R-49396 The xNF **MUST** support each ONAP (APPC) xNF action by invocation
-of **one** playbook [6]_. The playbook will be responsible
-for executing all necessary tasks (as well as calling other playbooks)
-to complete the request.
-
-R-33280 The xNF **MUST NOT** use any instance specific parameters
-in a playbook.
-
-R-48698 The xNF **MUST** utilize information from key value pairs
-that will be provided by the Ansible Server as "extra-vars" during
-invocation to execute the desired xNF action. If the playbook requires
-files, they must also be supplied using the methodology detailed in
-the Ansible Server API, unless they are bundled with playbooks, example,
-generic templates.
-
-R-43253 The xNF **MUST** use playbooks designed to allow Ansible
-Server to infer failure or success based on the “PLAY_RECAP” capability.
-NOTE: There are cases where playbooks need to interpret results of a task
-and then determine success or failure and return result accordingly
-(failure for failed tasks).
-
-R-50252 The xNF **MUST** write to a specific one text files that
-will be retrieved and made available by the Ansible Server if, as part
-of a xNF action (e.g., audit), a playbook is required to return any
-xNF information. The text files must be written in the same directory as
-the one from which the playbook is being executed. A text file must be
-created for the xNF playbook run targets/affects, with the name
-‘<VNFname>_results.txt’ into which any desired output from each
-respective VM/xNF must be written.
-
-R-51442 The xNF **SHOULD** use playbooks that are designed to
-automatically ‘rollback’ to the original state in case of any errors
-for actions that change state of the xNF (e.g., configure).
-
-R-58301 The xNF **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-02651 The xNF **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 xNF **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
-
-R-51910 The xNF **MUST** provide all telemetry (e.g., fault event
-records, syslog records, performance records etc.) to ONAP using the
-model, format and mechanisms described in this section.
-
-R-19624 The xNF **MUST** encode and serialize content delivered to
-ONAP using JSON (RFC 7159) plain text format. High-volume data is to
-be encoded and serialized using `Avro <http://avro.apache.org/>`_,
-where the Avro [5]_ data format are described using JSON.
-
-Note:
-
-- JSON plain text format is preferred for moderate volume data sets
- (option 1), as JSON has the advantage of having well-understood simple
- processing and being human-readable without additional decoding. Examples
- of moderate volume data sets include the fault alarms and performance
- alerts, heartbeat messages, measurements used for xNF scaling and syslogs.
-- Binary format using Avro is preferred for high volume data sets
- (option 2) such as mobility flow measurements and other high-volume
- streaming events (such as mobility signaling events or SIP signaling)
- or bulk data, as this will significantly reduce the volume of data
- to be transmitted. As of the date of this document, all events are
- reported using plain text JSON and REST.
-- Avro content is self-documented, using a JSON schema. The JSON schema is
- delivered along with the data content
- (http://avro.apache.org/docs/current/ ). This means the presence and
- position of data fields can be recognized automatically, as well as the
- data format, definition and other attributes. Avro content can be
- serialized as JSON tagged text or as binary. In binary format, the
- JSON schema is included as a separate data block, so the content is
- not tagged, further compressing the volume. For streaming data, Avro
- will read the schema when the stream is established and apply the
- schema to the received content.
-
-R-98191 The xNF **MUST** vary the frequency that asynchronous data is
-delivered based on the content and how data may be aggregated or grouped
-together.
-
-Note:
-
-- For example, alarms and alerts are expected to be delivered as soon
- as they appear. In contrast, other content, such as performance
- measurements, KPIs or reported network signaling may have various ways
- of packaging and delivering content. Some content should be streamed
- immediately; or content may be monitored over a time interval, then packaged
- as collection of records and delivered as block; or data may be collected
- until a package of a certain size has been collected; or content may be
- summarized statistically over a time interval, or computed as a KPI, with
- the summary or KPI being delivered.
-- We expect the reporting frequency to be configurable depending
- on the virtual network function’s needs for management. For example,
- Service Provider may choose to vary the frequency of collection between
- normal and trouble-shooting scenarios.
-- Decisions about the frequency of data reporting will affect the
- size of delivered data sets, recommended delivery method, and how the
- data will be interpreted by ONAP. These considerations should not
- affect deserialization and decoding of the data, which will be guided
- by the accompanying JSON schema or GPB definition files.
-
-R-88482 The xNF **SHOULD** use REST using HTTPS delivery of plain
-text JSON for moderate sized asynchronous data sets, and for high
-volume data sets when feasible.
-
-R-84879 The xNF **MUST** have the capability of maintaining a primary
-and backup DNS name (URL) for connecting to ONAP collectors, with the
-ability to switch between addresses based on conditions defined by policy
-such as time-outs, and buffering to store messages until they can be
-delivered. At its discretion, the service provider may choose to populate
-only one collector address for a xNF. In this case, the network will
-promptly resolve connectivity problems caused by a collector or network
-failure transparently to the xNF.
-
-R-81777 The xNF **MUST** be configured with initial address(es) to use
-at deployment time. Subsequently, address(es) may be changed through
-ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
-RESTful API, in the same manner that other controls over data reporting
-will be controlled by policy.
-
-R-08312 The xNF **MAY** use another option which is expected to include REST
-delivery of binary encoded data sets.
-
-R-79412 The xNF **MAY** use another option which is expected to include TCP
-for high volume streaming asynchronous data sets and for other high volume
-data sets. TCP delivery can be used for either JSON or binary encoded data
-sets.
-
-R-01033 The xNF **MAY** use another option which is expected to include SFTP
-for asynchronous bulk files, such as bulk files that contain large volumes of
-data collected over a long time interval or data collected across many xNFs.
-(Preferred is to reorganize the data into more frequent or more focused data
-sets, and deliver these by REST or TCP as appropriate.)
-
-R-63229 The xNF **MAY** use another option which is expected to include REST
-for synchronous data, using RESTCONF (e.g., for xNF state polling).
-
-R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
-as data destinations for each xNF, and may be changed by Policy while
-the xNF is in operation. We expect the xNF to be capable of redirecting
-traffic to changed destinations with no loss of data, for example from
-one REST URL to another, or from one TCP host and port to another.
-
-R-06924 The xNF **MUST** deliver asynchronous data as data becomes
-available, or according to the configured frequency.
-
-R-73285 The xNF **MUST** must encode, address and deliver the data
-as described in the previous paragraphs.
-
-R-42140 The xNF **MUST** respond to data requests from ONAP as soon
-as those requests are received, as a synchronous response.
-
-R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by
-the ONAP configuration subsystem for synchronous communication.
-
-R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF
-[RFC8040] (https://tools.ietf.org/html/rfc8040).
-
-R-11240 The xNF **MUST** respond with content encoded in JSON, as
-described in the RESTCONF specification. This way the encoding of a
-synchronous communication will be consistent with Avro.
-
-R-70266 The xNF **MUST** respond to an ONAP request to deliver the
-current data for any of the record types defined in
-Event Records - Data Structure Description by returning the requested
-record, populated with the current field values. (Currently the defined
-record types include fault fields, mobile flow fields, measurements for
-xNF scaling fields, and syslog fields. Other record types will be added
-in the future as they become standardized and are made available.)
-
-R-46290 The xNF **MUST** respond to an ONAP request to deliver granular
-data on device or subsystem status or performance, referencing the YANG
-configuration model for the xNF by returning the requested data elements.
-
-R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG
-<https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
-translated to and from JSON[RFC7951]. YANG configuration and content can
-be represented via JSON, consistent with Avro, as described in “Encoding
-and Serialization” section.
-
-R-42366 The xNF **MUST** support secure connections and transports such as
-Transport Layer Security (TLS) protocol
-[`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
-the best current practices outlined in
-`RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
-
-R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation
-of connections, through secure credentials, log-on and exchange mechanisms.
-
-R-47597 The xNF **MUST** carry data in motion only over secure connections.
-
-R-68165 The xNF **MUST** encrypt any content containing Sensitive Personal
-Information (SPI) or certain proprietary data, in addition to applying the
-regular procedures for securing access and delivery.
-
-
-.. [1]
- Not currently supported in ONAP release 1
-
-.. [2]
- https://github.com/mbj4668/pyang
-
-.. [3]
- Upstream elements must provide the appropriate FQDN in the request to
- ONAP for the desired action.
-
-.. [4]
- Refer to NCSP’s Network Cloud specification
-
-.. [5]
- This option is not currently supported in ONAP and it is currently
- under consideration.
-
-.. [6]
- Multiple ONAP actions may map to one playbook.
-
-
diff --git a/docs/Chapter9/index.rst b/docs/Chapter9/index.rst
index fd985a0..9556a16 100644
--- a/docs/Chapter9/index.rst
+++ b/docs/Chapter9/index.rst
@@ -8,4 +8,4 @@ Requirement List
.. needtable::
:style: datatables
- :columns: id;content;target;keyword;sections \ No newline at end of file
+ :columns: id;content;target;keyword;section_name \ No newline at end of file