VNFRQTS - Updating the release notes for frankfurt 26/104526/4
authorHagop Bozawglanian <hagop.bozawglanian@att.com>
Thu, 26 Mar 2020 18:01:19 +0000 (11:01 -0700)
committerHagop Bozawglanian <hagop.bozawglanian@att.com>
Thu, 26 Mar 2020 19:04:07 +0000 (19:04 +0000)
Issue-ID: VNFRQTS-854

Signed-off-by: Hagop Bozawglanian <hagop.bozawglanian@att.com>
Change-Id: I281b3fafc66a308b917fc835b1613f7b685532a2

docs/changes-by-section-frankfurt.rst [new file with mode: 0644]
docs/release-notes.rst

diff --git a/docs/changes-by-section-frankfurt.rst b/docs/changes-by-section-frankfurt.rst
new file mode 100644 (file)
index 0000000..90e6281
--- /dev/null
@@ -0,0 +1,3058 @@
+.. Modifications Copyright © 2017-2018 AT&T Intellectual Property.
+
+.. Licensed under the Creative Commons License, Attribution 4.0 Intl.
+   (the "License"); you may not use this documentation except in compliance
+   with the License. You may obtain a copy of the License at
+
+.. https://creativecommons.org/licenses/by/4.0/
+
+.. Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+
+
+Requirement Changes Introduced in Frankfurt
+========================================================
+
+This document summarizes the requirement changes by section that were
+introduced between the El Alto release and
+Frankfurt release. Click on the requirement number to
+navigate to the
+
+.. contents::
+    :depth: 2
+
+Summary of Changes
+------------------
+
+* **Requirements Added:** 22
+* **Requirements Changed:** 129
+* **Requirements Removed:** 6
+
+
+Configuration Management
+------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-305645`
+
+    The VNF or PNF MUST support configuration management including
+    life cycle management (LCM) using at least one of the following
+    protocols a)NETCONF/YANG, b)Ansible and c)Chef.
+
+
+Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Client Requirements
+-----------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-54373`
+
+    The VNF or PNF Provider **MUST** provide Ansible playbooks that are
+    compatible with the Operator’s deployed versions of Ansible and Python.
+    As the Ansible runtime itself is not deployed as part of ONAP, the ONAP
+    project cannot dictate the specific versions supported.
+
+
+Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Playbook Requirements
+-------------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-09209`
+
+    The VNF or PNF Provider **MUST** store any playbook configuration data
+    that requires encryption (passwords, secrets, etc.) in a JSON (.json),
+    YAML (.yaml|.yml) or INI (.ini) file, which will be placed in
+    <VNF type>/<Version>/ansible/vars directory.
+
+
+.. container:: note
+
+    :need:`R-20988`
+
+    The VNF or PNF provider **MUST** develop playbooks that do not log or
+    display passwords and other attributes that must remain secret when
+    running playbook in debug mode.
+
+    NOTE: Use "no_log: True"
+
+
+.. container:: note
+
+    :need:`R-39003`
+
+    The VNF or PNF provider **MUST** store passwords and other attributes
+    that must remain secret in JSON, YAML or INI files that can be
+    encrypted/decrypted using Ansible Vault capabilities.
+
+
+.. container:: note
+
+    :need:`R-42333`
+
+    The VNF or PNF playbooks targeting a subset of VMs (or servers/blades) part
+    of a VNF (or PNF) instance **MUST** be designed to use the VNF or PNF
+    inventory host file and to use a parameter named target_vm_list to provide
+    the subset of VMs in the VNF instance specifically targeted by the
+    playbook.
+
+    NOTE: Example of such playbooks would be playbooks used to configure VMs
+    added to a VNF instance as part of a scale-out/up or scale-in/down
+    operation. Such playbook is expected to also need to perform
+    configuration/reconfiguration tasks part of the base VNF instance build.
+
+
+.. container:: note
+
+    :need:`R-46823`
+
+    The VNF or PNF provider **MUST** store passwords and other attributes that
+    must remain secret in JSON, YAML or INI with differentiated names when
+    passwords and secrets vary from environment to environment. Example, name
+    must include <Mechanized user ID>_...json or <Mechanized user ID>_...xml
+    when labs and production use different passwords and/or secrets. The
+    <Mechanized user ID> is discovered from the environment
+    /etc/ansible/ansible.cfg where the playbook runs.
+
+
+.. container:: note
+
+    :need:`R-53245`
+
+    The VNF or PNF provider **MUST** provide playbooks that do not require
+    passwords or secrets to be passed in clear text in the command line or
+    Rest API request to run the playbook.
+
+
+.. container:: note
+
+    :need:`R-56988`
+
+    The VNF or PNF Provider **MUST** load any playbook configuration data
+    that requires encryption (passwords, secrets, etc.) in a JSON (.json),
+    YAML (.yaml|.yml) or INI (.ini) file, from the
+    <VNF type>/<Version>/ansible/vars directory.
+
+
+.. container:: note
+
+    :need:`R-78640`
+
+    The VNF or PNF provider **SHOULD** provide a single YAML or JSON file
+    with all the passwords and secrets to reduce the number of files to be
+    decrypted/encrypted before on-boarding into the central repository.
+
+
+.. container:: note
+
+    :need:`R-83092`
+
+    The VNF or PNF provider **MUST** develop playbooks that load passwords
+    and other attributes that must remain secret from JSON, YAML or INI files
+    that can be encrypted/decrypted using Ansible Vault capabilities.
+
+
+.. container:: note
+
+    :need:`R-88002`
+
+    The VNF or PNF provider **MUST** use a pre-agreed upon password to encrypt
+    the Ansible Vault file, or provide the vault password used to encrypt
+    the file to the customer, in a secure manner, to allow the customer to
+    decrypt/encrypt (rekey) Ansible Vault files before they are checked
+    into the central repository for distribution.
+
+
+.. container:: note
+
+    :need:`R-88786`
+
+    The VNF or PNF provider **SHOULD** place the passwords and secrets to
+    be edited at the top of the single YAML or JSON file with all the secrets,
+    and the (default) ones that are to remain unchanged towards the bottom,
+    with commentary separating them.
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-48698`
+
+    The VNF or PNF **MUST** utilize information from key value pairs that will
+    be provided by the Ansible Server as "extra-vars" during invocation to
+    execute the desired VNF or PNF action. The "extra-vars" attribute-value
+    pairs are passed to the Ansible Server by an APPC/SDN-C as part of the
+    Rest API request. 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. Any files
+    containing instance specific info (attribute-value pairs), not obtainable
+    from any ONAP inventory databases or other sources, referenced and used as
+    input by playbooks, shall be provisioned (and distributed) in advance of
+    use, e.g., VNF or PNF instantiation. Recommendation is to avoid these
+    instance specific, manually created in advance of instantiation, files.
+
+
+.. container:: note
+
+    :need:`R-50252`
+
+    The VNF or PNF **MUST** write to a response file in JSON format that will
+    be retrieved and made available by the Ansible Server if, as part of a VNF
+    or PNF action (e.g., audit), a playbook is required to return any VNF or
+    PNF information/response. The text files must be written in the main
+    playbook home directory, in JSON format. The JSON file must be created for
+    the VNF or PNF with the name '<VNF or PNF name>_results.txt'. All playbook
+    output results, for all VNF VMS or PNF Server/Blades, to be provided as a
+    response to the request, must be written to this response file.
+
+
+Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > LCM Operations via NETCONF
+----------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-246519`
+
+    As alternative to Ansible, Chef or REST, a VNF or PNF MAY support YANG models
+    allowing execution of standard controller LCM operations including HealthCheck.
+    Note: To support vendor YANG models for LCM operations, the controller is responsible
+    for performing VNF/PNF specific translation of north-bound API requests into one or more
+    south-bound NETCONF requests.
+
+
+Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > NETCONF Server Requirements
+-----------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-73468`
+
+    The VNF **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.
+
+
+Contrail Resource Parameters > Contrail Network Parameters > ONAP External Networks
+-----------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-02164`
+
+    When a VNF's Heat Orchestration Template's Contrail resource
+    ``OS::ContrailV2::InstanceIp`` and/or
+    ``OS::ContrailV2::VirtualMachineInterface``
+    contains the property ``virtual_network_refs``
+    that references an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    the property value **MUST** be obtained by a ``get_param`` and the
+    property parameter
+
+    * **MUST** follow the format ``{network-role}_net_fqdn``
+    * **MUST** be declared as type ``string``
+
+
+.. container:: note
+
+    :need:`R-92193`
+
+    A VNF's Heat Orchestration Template's Contrail resource
+    ``OS::ContrailV2::InstanceIp`` and/or
+    ``OS::ContrailV2::VirtualMachineInterface`` property
+    ``virtual_network_refs`` parameter ``{network-role}_net_fqdn``
+    **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
+    Environment File.
+
+
+Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > ONAP External Networks
+--------------------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-100350`
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
+    ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    and the IPv4 VIP address and/or IPv6 VIP address
+    is **not** supported by the ONAP data model,
+    the map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    * Parameter name **MAY** use any naming convention.  That is, there is no
+      ONAP mandatory parameter naming convention.
+    * Parameter **MAY** be declared as type ``string`` or type
+      ``comma_delimited_list``.
+
+    And the ``OS::ContrailV2::VirtualMachineInterface`` resource
+    **MUST** contain resource-level ``metadata`` (not property-level).
+
+    And the ``metadata`` format **MUST**  must contain the
+    key value ``aap_exempt`` with a list of all map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    parameters **not** supported by the ONAP data model.
+
+
+.. container:: note
+
+    :need:`R-100310`
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an ONAP external
+    network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    and an IPv4 Virtual IP (VIP)
+    is required to be supported by the ONAP data model,
+    the map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    parameter name **MUST** follow the naming convention
+
+    * ``{vm-type}_{network-role}_floating_ip``
+
+    where
+
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the ONAP external network
+
+    And the parameter **MUST** be declared as type ``string``.
+
+    The ONAP data model can only support one IPv4 VIP address.
+
+
+.. container:: note
+
+    :need:`R-100330`
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an ONAP
+    external
+    network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    and an IPv6 Virtual IP (VIP)
+    is required to be supported by the ONAP data model,
+    the map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    parameter name **MUST** follow the naming convention
+
+    * ``{vm-type}_{network-role}_floating_v6_ip``
+
+    where
+
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the ONAP external network
+
+    And the parameter **MUST** be declared as type ``string``.
+
+    The ONAP data model can only support one IPv6 VIP address.
+
+
+.. container:: note
+
+    :need:`R-100280`
+
+    If a VNF's Heat Orchestration Template's resource
+    ``OS::ContrailV2::VirtualMachineInterface``
+    is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968), the
+    map property
+
+    ``virtual_machine_interface_allowed_address_pairs``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
+
+    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+
+    parameter
+    **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
+
+
+Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > ONAP Internal Networks
+--------------------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-100360`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
+    ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv4 Virtual IP (VIP)
+    address is assigned using the map property,
+    ``virtual_machine_interface_allowed_address_pairs,
+    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
+    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
+    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+    , the parameter name **MUST** follow the
+    naming convention
+
+      * ``{vm-type}_int_{network-role}_floating_ip``
+
+    where
+
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the ONAP internal
+        network
+
+    And the parameter **MUST** be declared as ``type: string``
+    and **MUST** be enumerated in the environment file.
+
+    OR
+
+    the parameter name **MUST** follow the
+    naming convention
+
+      * ``{vm-type}_int_{network-role}_floating_ips``
+
+    where
+
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the ONAP internal
+        network
+
+    And the parameter **MUST** be declared as ``type: comma_delimited_list``
+    and **MUST** be enumerated in the environment file.
+
+
+.. container:: note
+
+    :need:`R-100370`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
+    ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv6 Virtual IP (VIP)
+    address is assigned
+    using the map property,
+    ``virtual_machine_interface_allowed_address_pairs,
+    virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
+    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
+    virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
+    , the parameter name **MUST** follow the
+    naming convention
+
+      * ``{vm-type}_int_{network-role}_floating_v6_ip``
+
+    where
+
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the ONAP internal
+        network
+
+    And the parameter **MUST** be declared as ``type: string``
+    and **MUST** be enumerated in the environment file
+
+    OR
+
+    the parameter name **MUST** follow the
+    naming convention
+
+      * ``{vm-type}_int_{network-role}_floating_v6_ips``
+
+    where
+
+      * ``{vm-type}`` is the {vm-type} associated with the
+        OS::Nova::Server
+      * ``{network-role}`` is the {network-role} of the ONAP internal
+        network
+
+    And the parameter **MUST** be declared as ``type: comma_delimited_list``
+    and **MUST** be enumerated in the environment file.
+
+
+Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property instance_ip_address
+-------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-100150`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address to an
+    ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv6 address is assigned
+    using the property ``instance_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 ONAP internal
+        network
+
+
+.. container:: note
+
+    :need:`R-100010`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    and an IPv4 address is assigned
+    using the property ``instance_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 ONAP external network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-100110`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv4 address is assigned
+    using the property ``instance_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 ONAP internal
+        network
+
+
+.. container:: note
+
+    :need:`R-100050`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP external network
+    (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    and an IPv6 address is assigned
+    using the property ``instance_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 ONAP external network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-100030`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    and an IPv4 address is assigned
+    using the property ``instance_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 ONAP external
+        network
+
+
+.. container:: note
+
+    :need:`R-100090`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv4 address is assigned
+    using the property ``instance_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 ONAP internal network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-100170`
+
+    The VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp``
+    property ``instance_ip_address``
+    parameter associated with an ONAP external network, i.e.,
+
+     * ``{vm-type}_{network-role}_ip_{index}``
+     * ``{vm-type}_{network-role}_v6_ip_{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.
+
+
+.. container:: note
+
+    :need:`R-100070`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    and an IPv6 address is assigned
+    using the property ``instance_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 ONAP external
+        network
+
+
+.. container:: note
+
+    :need:`R-100130`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` is assigning an IP address to an
+    ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv6 address is assigned
+    using the property ``instance_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 ONAP internal network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-100180`
+
+    The VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp``
+    property ``instance_ip_address``
+    parameter associated with an ONAP internal network, i.e.,
+
+     * ``{vm-type}_int_{network-role}_ip_{index}``
+     * ``{vm-type}_int_{network-role}_v6_ip_{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.
+
+
+Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property subnet_uuid
+-----------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-100220`
+
+    When the VNF's Heat Orchestration Template's
+    resource ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP external network (per the ONAP definition, see
+    Requirement R-57424 and R-16968),
+    and an IPv6 address is being cloud assigned by OpenStack's DHCP Service
+    and the ONAP external network IPv6 subnet is to be specified
+    using the property ``subnet_uuid``, the parameter
+    **MUST** follow the naming convention
+
+      * ``{network-role}_v6_subnet_id``
+
+    where
+
+      * ``{network-role}`` is the network role of the ONAP external network.
+
+
+.. container:: note
+
+    :need:`R-100200`
+
+    When the VNF's Heat Orchestration Template's
+    resource ``OS::ContrailV2::InstanceIp`` is assigning an IP address
+    to an ONAP external network (per the ONAP definition, see
+    Requirement R-57424 and R-16968),
+    and an IPv4 address is being cloud assigned by OpenStack's DHCP Service
+    and the ONAP external network IPv4 subnet is to be specified
+    using the property ``subnet_uuid``, the parameter
+    **MUST** follow the naming convention
+
+      * ``{network-role}_subnet_id``
+
+    where
+
+      * ``{network-role}`` is the network role of the ONAP external network.
+
+
+.. container:: note
+
+    :need:`R-100260`
+
+    When
+
+      * the VNF's Heat Orchestration Template's
+        resource ``OS::ContrailV2::InstanceIp`` in an Incremental Module is
+        attaching
+        to an ONAP internal network (per the ONAP definition,
+        see Requirements R-52425 and R-46461 and R-35666)
+        that is created in the Base Module, AND
+      * an IPv6 address is being cloud assigned by OpenStack's DHCP Service AND
+      * the ONAP internal network IPv6 subnet is to be specified
+        using the property ``subnet_uuid``,
+
+    the parameter **MUST** follow the naming convention
+
+      * ``int_{network-role}_v6_subnet_id``
+
+    where ``{network-role}`` is the network role of the ONAP internal network.
+
+    Note that the parameter **MUST** be defined as an ``output`` parameter in
+    the base module.
+
+
+.. container:: note
+
+    :need:`R-100240`
+
+    When
+
+      * the VNF's Heat Orchestration Template's
+        resource ``OS::ContrailV2::InstanceIp`` in an Incremental Module is
+        assigning an IP address
+        to an ONAP internal network (per the ONAP definition, see
+        Requirements R-52425 and R-46461 and R-35666)
+        that is created in the Base Module, AND
+      * an IPv4 address is being cloud assigned by OpenStack's DHCP Service AND
+      * the ONAP internal network IPv4 subnet is to be specified
+        using the property ``subnet_uuid``,
+
+    the parameter **MUST** follow the naming convention
+
+      * ``int_{network-role}_subnet_id``
+
+    where
+
+      * ``{network-role}`` is the network role of the ONAP internal network
+
+    Note that the parameter **MUST** be defined as an ``output`` parameter in
+    the base module.
+
+
+Monitoring & Management > Data Structure Specification of the Event Record
+--------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-570134`
+
+    The events produced by the VNF or PNF **MUST** be compliant with the
+    common event formats defined in either the
+    :ref:`VES Event Listener 7.1.1<ves_event_listener_7_1>` or
+    :ref:`VES Event Listener 5.4.1<ves_event_listener_5_4_1>`
+    specifications. Version 7.1.1 should be preferred, and VES 5.4.1 is only
+    provided for backwards compatibility.
+
+
+ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements
+----------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-17528`
+
+    A VNF's Heat Orchestration Template's first level Nested YAML file
+    **MUST NOT** contain more than one ``OS::Nova::Server`` resource.
+    A VNF's Heat Orchestration Template's second level Nested YAML file
+    **MUST NOT** contain any heat resources.
+
+
+ONAP Heat Networking > External Networks
+----------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-00606`
+
+    A VNF **MAY** be connected to zero, one or more than one ONAP external
+    network.
+
+
+.. container:: note
+
+    :need:`R-57424`
+
+    A VNF's port connected to an ONAP external network **MAY**
+    use the port for the purpose of
+
+    - Connecting a VM in the VNF to VMs in another VNF and/or
+    - Connecting a VM in the VNF to an external gateway or external router
+      and/or
+    - Connecting a VM in the VNF to other VMs in the same VNF
+
+
+.. container:: note
+
+    :need:`R-99794`
+
+    An ONAP external network **MUST** have one subnet. An external network
+    **MAY** have more than one subnet.
+
+
+.. container:: note
+
+    :need:`R-16968`
+
+    A VNF's Heat Orchestration Templates **MUST NOT** include heat
+    resources to create an ONAP external network.
+
+    An ONAP external network **MUST** be instantiated by using VID
+    or by invoking SO directly.
+
+
+ONAP Heat Networking > Internal Networks
+----------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-35666`
+
+    If a VNF has an ONAP internal network, the VNF's Heat Orchestration
+    Template **MUST** include the heat resources to create the
+    ONAP internal network.
+
+    A VNF's ONAP internal network is created using Neutron Heat Resources
+    (e.g., ``OS::Neutron::Net``, ``OS::Neutron::Subnet``,
+    ``OS::Neutron::ProviderNet``) and/or
+    Contrail Heat Resources (e.g., ``OS::ContrailV2::VirtualNetwork``,
+    ``OS::ContrailV2::NetworkIpam``).
+
+
+.. container:: note
+
+    :need:`R-46461`
+
+    A VNF's port connected to an ONAP internal network **MUST NOT**
+    use the port
+    for the purpose of reaching VMs in another VNF and/or an
+    external gateway and/or
+    external router.
+
+
+.. container:: note
+
+    :need:`R-16241`
+
+    A VNF's ONAP internal network **MUST** have one subnet.
+    A VNF's ONAP internal network **MAY** have more than one subnet.
+
+
+.. container:: note
+
+    :need:`R-86972`
+
+    A VNF **SHOULD** create the ONAP internal network in the VNF's Heat
+    Orchestration Template's Base Module.
+
+
+.. container:: note
+
+    :need:`R-52425`
+
+    A VNF's port connected to an ONAP internal network **MUST**
+    use the port for the purpose of reaching VMs in the same VNF.
+
+
+.. container:: note
+
+    :need:`R-22688`
+
+    When a VNF's Heat Orchestration Template creates an ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461
+    and R-35666) and the ONAP internal network needs to be shared between
+    modules within a VNF, the ONAP
+    internal network **MUST** be created either in the
+
+    * the base module
+    * a nested YAML file invoked by the base module
+
+    and the base module **MUST** contain an output parameter that provides
+    either the network UUID or network name.
+
+    * If the network UUID value is used to reference the network, the output
+      parameter name in the base module **MUST** follow the naming convention
+      ``int_{network-role}_net_id``
+    * If the network name in is used to reference the network, the output
+      parameter name in the base template **MUST** follow the naming convention
+      ``int_{network-role}_net_name``
+
+    The ``{network-role}`` **MUST** be the network-role of the ONAP
+    internal network created in the Base Module.
+
+    The Base Module Output Parameter MUST be declared in the ``parameters:``
+    section of the Incremental Module(s) where the ``OS::Neutron::Port``
+    resource(s) is attaching to the ONAP internal network.
+
+
+.. container:: note
+
+    :need:`R-87096`
+
+    A VNF **MAY** contain zero, one or more than one ONAP internal network.
+
+
+ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters
+--------------------------------------------------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-35413`
+
+    A VNF Heat Orchestration's template's base module **MAY** (or **MAY NOT**)
+    contain the section ``parameters:``.
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-35414`
+
+    A VNF Heat Orchestration's template's incremental module and volume module
+    **MUST** contain the section ``parameters:``.
+
+
+.. container:: note
+
+    :need:`R-90279`
+
+    A VNF Heat Orchestration's template's parameter **MUST** be used
+
+    - in a resource AND/OR
+    - in a output parameter (in the outputs section)
+
+    with the exception of the parameters for the ``OS::Nova::Server``
+    resource property ``availability_zone``.
+
+
+ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources
+-------------------------------------------------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-23663`
+
+    A VNF's Heat Orchestration template's base module
+    **MAY** (or **MAY NOT**)
+    contain the section ``resources:``.
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-23664`
+
+    A VNF's Heat Orchestration template's incremental
+    module and volume module **MUST**
+    contain the section ``resources:``.
+
+
+Resource IDs
+------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-82551`
+
+    When a VNF's Heat Orchestration Template's resource is associated with a
+    single ``{vm-type}`` and a single ONAP internal network (per the ONAP
+    definition, see Requirements R-52425 and R-46461 and R-35666),
+    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.
+      (e.g., ``{vm-type}_{index}_int_{network-role}``).
+
+
+.. container:: note
+
+    :need:`R-27970`
+
+    When a VNF's Heat Orchestration Template's resource is associated with
+    more than one ``{vm-type}`` and/or more than one ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666)
+    and/or ONAP external network (per the ONAP definition, see Requirement
+    R-57424 and R-16968), the Resource ID **MAY** contain the term
+    ``shared`` and/or **MAY**
+    contain text that identifies the VNF.
+
+
+.. container:: note
+
+    :need:`R-67793`
+
+    When a VNF's Heat Orchestration Template's resource is associated
+    with more than one ``{vm-type}`` and/or more than one ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666)
+    and/or
+    ONAP external network (per the ONAP definition, see Requirement R-57424
+    and R-16968), the Resource ID **MUST NOT** contain the
+    ``{vm-type}`` and/or ``{network-role}``/``int_{network-role}``.
+
+
+.. container:: note
+
+    :need:`R-82115`
+
+    When a VNF's Heat Orchestration Template's resource is associated with a
+    single ``{vm-type}``
+    and a single ONAP
+    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.  (e.g., ``{vm-type}_{index}_{network-role}``).
+
+
+.. container:: note
+
+    :need:`R-98138`
+
+    When a VNF's Heat Orchestration Template's resource is associated with a
+    single ONAP internal network (per the ONAP definition, see
+    Requirements R-52425 and R-46461 and R-35666), the Resource ID **MUST**
+    contain the text
+    ``int_{network-role}``.
+
+
+.. container:: note
+
+    :need:`R-96482`
+
+    When a VNF's Heat Orchestration Template's resource is associated
+    with a single ONAP external network, the Resource ID **MUST** contain the
+    text ``{network-role}``.
+
+
+Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::InstanceIp
+-------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-62187`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` Resource ID
+    that is configuring an IPv4 Address on a virtual machine interface
+    (i.e., OS::ContrailV2::VirtualMachineInterface)
+    attached to an ONAP internal network (per the ONAP definition, see
+    Requirements R-52425 and R-46461 and R-35666)
+    **MUST** use the naming convention
+
+    *  ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP internal network
+      that the port is attached to
+    * ``{vmi_index}`` references the instance of the virtual machine interface
+      on the ``{vm-type}`` attached to ``{network-role}`` network.  The
+      ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new virtual machine interface is defined on the instance of the
+      ``{vm-type}`` attached to ``{network-role}`` network.
+    * ``IP`` signifies that an IPv4 address is being configured
+    * ``{index}`` references the instance of the IPv4 address configured
+      on the virtual machine interface.  The ``{index}`` is a numeric value
+      that **MUST** start at zero on an
+      instance of a virtual machine interface and **MUST** increment by one
+      each time a new IPv4 address is configured on the
+      virtual machine interface.
+
+
+.. container:: note
+
+    :need:`R-87563`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` Resource ID
+    that is configuring an IPv6 Address on a virtual machine interface
+    (i.e., OS::ContrailV2::VirtualMachineInterface)
+    attached to an ONAP internal network (per the ONAP definition, see
+    Requirements R-52425 and R-46461 and R-35666)
+    **MUST** use the naming convention
+
+    *  ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_v6_IP_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP internal network
+      that the port is attached to
+    * ``{vmi_index}`` references the instance of the virtual machine interface
+      on the ``{vm-type}`` attached to ``{network-role}`` network.  The
+      ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new virtual machine interface is defined on the instance of the
+      ``{vm-type}`` attached to ``{network-role}`` network.
+    * ``v6_IP`` signifies that an IPv6 address is being configured
+    * ``{index}`` references the instance of the IPv6 address configured
+      on the virtual machine interface.  The ``{index}`` is a numeric value
+      that **MUST** start at zero on an
+      instance of a virtual machine interface and **MUST** increment by one
+      each time a new IPv6 address is configured on the
+      virtual machine interface.
+
+
+.. container:: note
+
+    :need:`R-53310`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` Resource ID
+    that is configuring an IPv4 Address on a virtual machine interface
+    (i.e., OS::ContrailV2::VirtualMachineInterface)
+    attached to an ONAP external network (per the ONAP definition,
+    see Requirement R-57424 and R-16968)
+    **MUST** use the naming convention
+
+    *  ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_IP_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP external
+      network that the virtual machine interface is attached to
+    * ``{vmi_index}`` references the instance of the virtual machine interface
+      on the ``{vm-type}`` attached to ``{network-role}`` network.  The
+      ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new virtual machine interface is defined on the instance of the
+      ``{vm-type}`` attached to ``{network-role}`` network.
+    * ``IP`` signifies that an IPv4 address is being configured
+    * ``{index}`` references the instance of the IPv4 address configured
+      on the virtual machine interface.  The ``{index}`` is a numeric value
+      that **MUST** start at zero on an
+      instance of a virtual machine interface and **MUST** increment by one
+      each time a new IPv4 address is configured on the
+      virtual machine interface.
+
+
+.. container:: note
+
+    :need:`R-46128`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::InstanceIp`` Resource ID
+    that is configuring an IPv6 Address on a virtual machine interface
+    (i.e., OS::ContrailV2::VirtualMachineInterface)
+    attached to an ONAP external network (per the ONAP definition,
+    see Requirement R-57424 and R-16968)
+    **MUST** use the naming convention
+
+    *  ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_v6_IP_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP external network
+      that the port is attached to
+    * ``{vmi_index}`` references the instance of the virtual machine interface
+      on the ``{vm-type}`` attached to ``{network-role}`` network.  The
+      ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new virtual machine interface is defined on the instance of the
+      ``{vm-type}`` attached to ``{network-role}`` network.
+    * ``v6_IP`` signifies that an IPv6 address is being configured
+    * ``{index}`` references the instance of the IPv6 address configured
+      on the virtual machine interface.  The ``{index}`` is a numeric value
+      that **MUST** start at zero on an
+      instance of a virtual machine interface and **MUST** increment by one
+      each time a new IPv6 address is configured on the
+      virtual machine interface.
+
+
+Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::NetworkIpam
+--------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-30753`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::NetworkIpam``
+    Resource ID
+    **MUST**
+    contain the ``{network-role}`` of the ONAP internal network (per the ONAP
+    definition, see Requirements R-52425 and R-46461 and R-35666) that the
+    resource is associated with.
+
+
+Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualMachineInterface
+--------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-50468`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::VirtualMachineInterface`` Resource ID
+    that is attaching to an ONAP internal network (per the ONAP definition, see
+    Requirements R-52425 and R-46461 and R-35666)
+    **MUST** use the naming convention
+
+    * ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP internal network
+      that the port (i.e. virtual machine interface) is attached to
+    * ``{vmi_index}`` references the instance of the virtual machine interface
+      on the ``{vm-type}`` attached to ``{network-role}`` network.  The
+      ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new virtual machine interface is defined on the instance of the
+      ``{vm-type}`` attached to ``{network-role}`` network.
+
+
+.. container:: note
+
+    :need:`R-96253`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::VirtualMachineInterface`` Resource ID
+    that is attaching to an ONAP external network (per the ONAP definition,
+    see Requirement R-57424 and R-16968)
+    **MUST** use the naming convention
+
+    * ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP external network
+      that the port (i.e. virtual machine interface) is attached to
+    * ``{vmi_index}`` references the instance of the virtual machine interface
+      on the ``{vm-type}`` attached to ``{network-role}`` network.  The
+      ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new virtual machine interface is defined on the instance of the
+      ``{vm-type}`` attached to ``{network-role}`` network.
+
+
+Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualNetwork
+-----------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-99110`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::ContrailV2::VirtualNetwork`` Resource ID **MUST** use the naming
+    convention
+
+    * ``int_{network-role}_network``
+
+    VNF Heat Orchestration Templates can only create ONAP internal networks
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666).
+    There is no ``{index}`` after ``{network-role}`` because ``{network-role}``
+    **MUST** be unique in the scope of the VNF's
+    Heat Orchestration Template.
+
+
+Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Net
+----------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-25720`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Net``
+    Resource ID **MUST** use the naming convention
+
+    * ``int_{network-role}_network``
+
+    VNF Heat Orchestration Templates can only create ONAP internal networks
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666).
+    There is no ``{index}`` after ``{network-role}`` because ``{network-role}``
+    **MUST** be unique in the scope of the VNF's
+    Heat Orchestration Template.
+
+
+Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Port
+-----------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-20453`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
+    that is attaching to an ONAP external network (per the ONAP definition,
+    see Requirement R-57424 and R-16968), the ``OS::Neutron::Port``
+    Resource ID
+    **MUST** use the naming convention
+
+    * ``{vm-type}_{vm-type_index}_{network-role}_port_{port-index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP external network
+      that the port is attached to
+    * ``{port_index}`` references the instance of the port on the ``{vm-type}``
+      attached to ``{network-role}`` network.  The
+      ``{port_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new port is defined on the instance of the ``{vm-type}`` attached to
+      ``{network-role}`` network.
+
+
+.. container:: note
+
+    :need:`R-68520`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
+    that is creating a *Reserve Port* with an IPv6 address, the
+    ``OS::Neutron::Port`` Resource ID
+    **SHOULD** use the naming convention
+
+    * ``reserve_port_{vm-type}_{network-role}_floating_v6_ip_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{network-role}`` is the network-role of the ONAP external network
+      that the port is attached to
+    * ``{index}`` is the instance of the IPv6 *Reserve Port*
+      for the vm-type attached to the network of ``{network-role}``.
+      The ``{index}`` starts at zero and increments by one
+      (as described in R-11690).
+
+
+.. container:: note
+
+    :need:`R-26351`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
+    that is attaching to an ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    the ``OS::Neutron::Port`` Resource ID **MUST**
+    use the naming convention
+
+    * ``{vm-type}_{vm-type_index}_int_{network-role}_port_{port-index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
+      the VNF.  The
+      ``{vm-type_index}`` is a numeric value that **MUST** start at zero
+      in the VNF and
+      **MUST** increment by one each time a new instance of a ``{vm-type}``
+      is referenced.
+    * ``{network-role}`` is the network-role of the ONAP internal network
+      that the port is attached to
+    * ``{port_index}`` references the instance of the port on the ``{vm-type}``
+      attached to ``{network-role}`` network.  The
+      ``{port_index}`` is a numeric value that **MUST** start at zero on an
+      instance of a ``{vm-type}`` and **MUST** increment by one each time a
+      new port is defined on the instance of the ``{vm-type}`` attached to
+      ``{network-role}`` network.
+
+
+.. container:: note
+
+    :need:`R-27469`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
+    that is creating a *Reserve Port* with an IPv4 address, the
+    ``OS::Neutron::Port`` Resource ID
+    **SHOULD** use the naming convention
+
+    * ``reserve_port_{vm-type}_{network-role}_floating_ip_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{network-role}`` is the network-role of the ONAP external network
+      that the port is attached to
+    * ``{index}`` is the instance of the IPv4 *Reserve Port*
+      for the vm-type attached to the network of ``{network-role}``.
+      The ``{index}`` starts at zero and increments by one
+      (as described in R-11690).
+
+
+Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::SecurityGroup
+--------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-17334`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::SecurityGroup``
+    that is applicable to one ``{vm-type}`` and one ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    the ``OS::Neutron::SecurityGroup`` Resource ID
+    **SHOULD** use the naming convention
+
+    * ``{vm-type}_{network-role}_security_group``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{network-role}`` is the network-role of the ONAP external network
+
+
+.. container:: note
+
+    :need:`R-08775`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::SecurityGroup``
+    that is applicable to one ``{vm-type}`` and more than one network
+    (ONAP internal network
+    and/or ONAP external network), the ``OS::Neutron::SecurityGroup``
+    Resource ID **SHOULD** use the naming convention
+
+    * ``{vm-type}_security_group``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+
+
+.. container:: note
+
+    :need:`R-03595`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::SecurityGroup`` that
+    is applicable to more than one ``{vm-type}`` and one ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    the ``OS::Neutron::SecurityGroup`` Resource ID
+    **SHOULD** use the naming convention
+
+    * ``{network-role}_security_group``
+
+    where
+
+    * ``{network-role}`` is the network-role of the ONAP external network
+
+
+.. container:: note
+
+    :need:`R-14198`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::SecurityGroup`` that
+    is applicable to one {vm-type} and one ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and
+    R-35666), the
+    ``OS::Neutron::SecurityGroup`` Resource ID **SHOULD**
+    use the naming convention
+
+    * ``{vm-type}_int_{network-role}_security_group``
+
+    where
+
+    * ``{vm-type}`` is the vm-type
+    * ``{network-role}`` is the network-role of the ONAP internal network
+
+
+.. container:: note
+
+    :need:`R-30005`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::SecurityGroup`` that
+    is applicable to more than one ``{vm-type}`` and more than one network
+    (internal and/or external), the ``OS::Neutron::SecurityGroup`` Resource ID
+    **MAY**
+    use the naming convention
+
+    * ``shared_security_group``
+
+    or
+
+    * ``{vnf-type}_security_group``
+
+    where
+
+    * ``{vnf-type}`` describes the VNF
+
+
+.. container:: note
+
+    :need:`R-73213`
+
+    A VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::SecurityGroup`` that
+    is applicable to more than one ``{vm-type}`` and one ONAP internal network,
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and
+    R-35666), the ``OS::Neutron::SecurityGroup`` Resource ID
+    **SHOULD** use the naming convention
+
+    * ``int_{network-role}_security_group``
+
+    where
+
+    * ``{network-role}`` is the network-role of the ONAP internal network
+
+
+Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Subnet
+-------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-59434`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Subnet``
+    Resource ID **SHOULD** use the naming convention
+
+    * ``int_{network-role}_subnet_{index}``
+
+    where
+
+    * ``{network-role}`` is the network-role of the ONAP internal network
+      (per the ONAP definition, see Requirements R-52425 and R-46461 and
+      R-35666).
+    * ``{index}`` is the ``{index}`` of the subnet of the ONAP internal network.
+      The ``{index}`` starts at zero and increments by one
+      (as described in R-11690).
+
+
+Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Keypair
+-----------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-24997`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Nova::Keypair``
+    that applies to one ``{vm-type}``, the ``OS::Nova::Keypair``
+    Resource ID **SHOULD** use the naming convention
+
+    * ``{vm-type}_keypair_{index}``
+
+    where
+
+    * ``{vm-type}`` is the vm-type of the ``OS::Nova::Server``
+    * ``{index}`` is the ``{index}`` of the keypair.
+      The ``{index}`` starts at zero and increments by one
+      (as described in R-11690).
+
+
+.. container:: note
+
+    :need:`R-65516`
+
+    A VNF's Heat Orchestration Template's Resource ``OS::Nova::Keypair``
+    that applies to all Virtual Machines in the VNF, the
+    ``OS::Nova::Keypair`` Resource ID **SHOULD** use the naming
+    convention
+
+    * ``{vnf-type}_keypair``
+
+    where
+
+    * ``{vnf-type}`` describes the VNF
+
+
+Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note
+-----------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-18001`
+
+    If the VNF's ports connected to a unique ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666)
+    and the port's IP addresses are statically assigned IP addresses,
+    the IPv4 addresses **MAY** be from different subnets and the
+    IPv6 addresses **MAY** be from different subnets.
+
+
+.. container:: note
+
+    :need:`R-63956`
+
+    If the VNF's ports connected to a unique ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968)
+    and the port's IP addresses are ONAP SDN-C assigned IP addresses,
+    the IPv4 addresses **MAY** be from different subnets and the IPv6
+    addresses **MAY** be from different subnets.
+
+
+.. container:: note
+
+    :need:`R-48880`
+
+    If a VNF's Port is attached to an ONAP external network (per the ONAP
+    definition, see Requirement R-57424 and R-16968) and the port's
+    IP addresses are assigned by ONAP's SDN-Controller,
+    the ``OS::Neutron::Port`` Resource's
+
+    * property ``fixed_ips`` map property ``ip_address`` **MUST** be used
+    * property ``fixed_ips`` map property ``subnet``
+      **MUST NOT** be used
+
+
+.. container:: note
+
+    :need:`R-70964`
+
+    If a VNF's Port is attached to an ONAP internal network
+    (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666)
+    and the port's
+    IP addresses are statically assigned by the VNF's Heat Orchestration
+    Template (i.e., enumerated in the Heat Orchestration Template's
+    environment file), the ``OS::Neutron::Port`` Resource's
+
+    * property ``fixed_ips`` map property ``ip_address`` **MUST** be used
+    * property ``fixed_ips`` map property ``subnet``
+      **MUST NOT** be used
+
+
+Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, ONAP External Networks
+---------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-41492`
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    and the IPv4 VIP is required to be supported by the ONAP data model,
+    the property ``allowed_address_pairs`` map property ``ip_address``
+    parameter name **MUST** follow the naming convention
+
+    * ``{vm-type}_{network-role}_floating_ip``
+
+    where
+
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the ONAP external network
+
+    And the parameter **MUST** be declared as type ``string``.
+
+    As noted in the introduction to this section, the ONAP data model
+    can only support one IPv4 VIP address.
+
+
+.. container:: note
+
+    :need:`R-83412`
+
+    If a VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968), the
+    property ``allowed_address_pairs``
+    map property ``ip_address`` parameter(s)
+    **MUST NOT** be enumerated in the
+    VNF's Heat Orchestration Template's Environment File.
+
+
+.. container:: note
+
+    :need:`R-41493`
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    and the IPv4 VIP address and/or IPv6 VIP address
+    is **not** supported by the ONAP data model,
+    the property ``allowed_address_pairs`` map property ``ip_address``
+
+    * Parameter name **MAY** use any naming convention.  That is, there is no
+      ONAP mandatory parameter naming convention.
+    * Parameter **MAY** be declared as type ``string`` or type
+    ``comma_delimited_list``.
+
+    And the ``OS::Neutron::Port`` resource **MUST** contain
+    resource-level ``metadata`` (not property-level).
+
+    And the ``metadata`` format **MUST**  must contain the
+    key value ``aap_exempt`` with a list of all
+    ``allowed_address_pairs`` map property ``ip_address`` parameters
+    **not** supported by the ONAP data model.
+
+
+.. container:: note
+
+    :need:`R-35735`
+
+    When the VNF's Heat Orchestration Template's resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network
+    (per the ONAP definition, see Requirement R-57424 and R-16968),
+    and the IPv6 VIP is required to be supported by the ONAP data model,
+    the property ``allowed_address_pairs`` map property ``ip_address``
+    parameter name **MUST** follow the naming convention
+
+    * ``{vm-type}_{network-role}_floating_v6_ip``
+
+    where
+
+    * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
+    * ``{network-role}`` is the {network-role} of the ONAP external network
+
+    And the parameter **MUST** be declared as type ``string``.
+
+    As noted in the introduction to this section, the ONAP data model
+    can only support one IPv6 VIP address.
+
+
+Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, ONAP Internal Networks
+---------------------------------------------------------------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-717227`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv4 Virtual IP (VIP)
+    address is assigned using the property ``allowed_address_pairs``
+    map property ``ip_address``,
+    the parameter name **MUST** follow the
+    naming convention
+
+    - ``{vm-type}_int_{network-role}_floating_ip``
+
+    where
+
+    - ``{vm-type}`` is the {vm-type} associated with the
+      OS::Nova::Server
+    - ``{network-role}`` is the {network-role} of the ONAP internal
+      network
+
+    And the parameter **MUST** be declared as ``type: string``
+    and **MUST** be enumerated in the environment file.
+
+    OR
+
+    the parameter name **MUST** follow the
+    naming convention
+
+    - ``{vm-type}_int_{network-role}_floating_ips``
+
+    where
+
+    - ``{vm-type}`` is the {vm-type} associated with the
+      OS::Nova::Server
+    - ``{network-role}`` is the {network-role} of the ONAP internal
+      network
+
+    And the parameter **MUST** be declared as ``type: comma_delimited_list``
+    and **MUST** be enumerated in the environment file.
+
+
+.. container:: note
+
+    :need:`R-805572`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    and an IPv6 Virtual IP (VIP)
+    address is assigned
+    using the property ``allowed_address_pairs``
+    map property ``ip_address``,
+    the parameter name **MUST** follow the
+    naming convention
+
+    - ``{vm-type}_int_{network-role}_floating_v6_ip``
+
+    where
+
+    - ``{vm-type}`` is the {vm-type} associated with the
+      OS::Nova::Server
+    - ``{network-role}`` is the {network-role} of the ONAP internal
+      network
+
+    And the parameter **MUST** be declared as ``type: string``
+    and **MUST** be enumerated in the environment file
+
+    OR
+
+    the parameter name **MUST** follow the
+    naming convention
+
+    - ``{vm-type}_int_{network-role}_floating_v6_ips``
+
+    where
+
+    - ``{vm-type}`` is the {vm-type} associated with the
+      OS::Nova::Server
+    - ``{network-role}`` is the {network-role} of the ONAP internal
+      network
+
+    And the parameter **MUST** be declared as ``type: comma_delimited_list``
+    and **MUST** be enumerated in the environment file.
+
+
+Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address
+----------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-27818`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    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 ONAP internal network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-40971`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    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 ONAP external network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-04697`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    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 ONAP external
+        network
+
+
+.. container:: note
+
+    :need:`R-78380`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    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 ONAP internal network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-23503`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    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 ONAP external
+        network
+
+
+.. container:: note
+
+    :need:`R-85235`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    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 ONAP internal
+        network
+
+
+.. container:: note
+
+    :need:`R-93496`
+
+    The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
+    property ``fixed_ips``
+    map property ``ip_address``
+    parameter associated with an ONAP internal network, i.e.,
+
+     * ``{vm-type}_int_{network-role}_ip_{index}``
+     * ``{vm-type}_int_{network-role}_v6_ip_{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.
+
+
+.. container:: note
+
+    :need:`R-71577`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968),
+    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 ONAP external network
+    * ``{index}`` is a numeric value that **MUST** start at zero in a
+      VNF's Heat Orchestration Template and **MUST** increment by one
+
+
+.. container:: note
+
+    :need:`R-62590`
+
+    The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
+    property ``fixed_ips``
+    map property ``ip_address``
+    parameter associated with an ONAP external network, i.e.,
+
+     * ``{vm-type}_{network-role}_ip_{index}``
+     * ``{vm-type}_{network-role}_v6_ip_{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.
+
+
+.. container:: note
+
+    :need:`R-29765`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    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 ONAP internal
+        network
+
+
+Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: subnet
+------------------------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-76160`
+
+    When
+
+    * the VNF's Heat Orchestration Template's
+      resource ``OS::Neutron::Port`` in an Incremental Module is attaching
+      to an ONAP internal network (per the ONAP definition, see Requirements
+      R-52425 and R-46461 and R-35666)
+      that is created in the Base Module, AND
+    * an IPv6 address is being cloud assigned by OpenStack's DHCP Service AND
+    * the ONAP internal network IPv6 subnet is to be specified
+      using the property ``fixed_ips`` map property ``subnet``,
+
+    the parameter **MUST** follow the naming convention
+
+    * ``int_{network-role}_v6_subnet_id``
+
+    where ``{network-role}`` is the network role of the ONAP internal network.
+
+    Note that the parameter **MUST** be defined as an ``output`` parameter in
+    the base module.
+
+
+.. container:: note
+
+    :need:`R-15287`
+
+    When the VNF's Heat Orchestration Template's
+    resource ``OS::Neutron::Port`` is attaching
+    to an ONAP external network (per the ONAP definition, see
+    Requirement R-57424 and R-16968),
+    and an IPv6 address is being cloud assigned by OpenStack's DHCP Service
+    and the ONAP external network IPv6 subnet is to be specified
+    using the property ``fixed_ips``
+    map property ``subnet``, the parameter
+    **MUST** follow the naming convention
+
+      * ``{network-role}_v6_subnet_id``
+
+    where
+
+      * ``{network-role}`` is the network role of the ONAP external network.
+
+
+.. container:: note
+
+    :need:`R-62802`
+
+    When the VNF's Heat Orchestration Template's
+    resource ``OS::Neutron::Port`` is attaching
+    to an ONAP external network (per the ONAP definition, see
+    Requirement R-57424 and R-16968),
+    and an IPv4 address is being cloud assigned by OpenStack's DHCP Service
+    and the ONAP external network IPv4 subnet is to be specified
+    using the property ``fixed_ips``
+    map property ``subnet``, the parameter
+    **MUST** follow the naming convention
+
+      * ``{network-role}_subnet_id``
+
+    where
+
+      * ``{network-role}`` is the network role of the ONAP external network.
+
+
+.. container:: note
+
+    :need:`R-84123`
+
+    When
+
+      * the VNF's Heat Orchestration Template's
+        resource ``OS::Neutron::Port`` in an Incremental Module is attaching
+        to an ONAP internal network (per the ONAP definition, see
+        Requirements R-52425 and R-46461 and R-35666)
+        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``,
+
+    the parameter **MUST** follow the naming convention
+
+      * ``int_{network-role}_subnet_id``
+
+    where
+
+      * ``{network-role}`` is the network role of the ONAP internal network
+
+    Note that the parameter **MUST** be defined as an ``output`` parameter in
+    the base module.
+
+
+Resource: OS::Neutron::Port - Parameters > Property: network
+------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-86182`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port``
+    is in an incremental module and
+    is attaching to an ONAP internal network (per the
+    ONAP definition, see Requirements R-52425 and R-46461 and R-35666),
+    the ``network`` parameter name **MUST**
+
+      * follow the naming convention ``int_{network-role}_net_id`` if the
+        network UUID value is used to reference the network
+      * follow the naming convention ``int_{network-role}_net_name`` if the
+        network name in is used to reference the network.
+
+    where ``{network-role}`` is the network-role of the ONAP internal network
+    and a ``get_param`` **MUST** be used as the intrinsic function.
+
+
+.. container:: note
+
+    :need:`R-62983`
+
+    When the VNF's Heat Orchestration Template's Resource
+    ``OS::Neutron::Port`` is attaching to an ONAP external network (per the
+    ONAP definition, see Requirement R-57424 and R-16968), 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 ONAP external network
+    and a ``get_param`` **MUST** be used as the intrinsic function.
+
+
+Resource: OS::Nova::Server Metadata Parameters > vf_module_index
+----------------------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-55307`
+
+    A VNF's Heat Orchestration Template's parameter ``vf_module_index``
+    **MUST NOT** be used for indexing an:
+
+    - ``OS::Nova::Server`` property ``name`` parameter (when defined as a
+      ``comma_delimited_list``).
+    - ``OS::Neutron::Port`` property ``fixed_ips`` map property ``ip_address``
+      parameter (when defined as a ``comma_delimited_list``) when the port is
+      attaching to an ONAP external network (per the ONAP
+      definition, see Requirement R-57424 and R-16968)
+    - ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
+      parameter (when defined as a ``comma_delimited_list``) when the port
+      (i.e, ``OS::ContrailV2::VirtualMachineInterface``) is
+      attaching to an ONAP external network (per the ONAP
+      definition, see Requirement R-57424 and R-16968)
+
+
+VNF Security > VNF General Security Requirements
+------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-353637`
+
+    Containerized components of VNFs **SHOULD** follow the recommendations for
+    Container Base Images and Build File Configuration in the latest available version
+    of the CIS Docker Community Edition Benchmarks to ensure that containerized VNFs
+    are secure. All non-compliances with the benchmarks MUST be documented.
+
+
+.. container:: note
+
+    :need:`R-381623`
+
+    Containerized components of VNFs **SHOULD** execute in a Docker run-time environment
+    that follows the Container Runtime Configuration in the latest available version
+    of the CIS Docker Community Edition Benchmarks to ensure that containerized VNFs
+    are secure. All non-compliances with the benchmarks MUST be documented.
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-842258`
+
+    The VNF **MUST** include a configuration (e.g. a heat template or CSAR package)
+    that specifies the targeted parameters (e.g. a limited set of ports)
+    over which the VNF will communicate; including internal, external and
+    management communication.
+
+
+.. container:: note
+
+    :need:`R-19082`
+
+    The VNF **MUST** not contain undocumented functionality.
+
+
+.. container:: note
+
+    :need:`R-46986`
+
+    The VNF provider **MUST** follow GSMA vendor practices and SEI CERT Coding
+    Standards when developing the VNF in order to minimize the risk of
+    vulnerabilities. See GSMA NESAS Network Equipment Security Assurance Scheme –
+    Development and Lifecycle Security Requirements Version 1.0 (https://www.gsma.com/
+    security/wp-content/uploads/2019/11/FS.16-NESAS-Development-and-Lifecycle-Security-
+    Requirements-v1.0.pdf) and SEI CERT Coding Standards (https://wiki.sei.cmu.edu/
+    confluence/display/seccode/SEI+CERT+Coding+Standards).
+
+
+.. container:: note
+
+    :need:`R-19768`
+
+    The VNF **SHOULD** support the separation of (1) signaling and payload traffic
+    (i.e., customer facing traffic), (2) operations, administration and management
+    traffic, and (3) internal VNF traffic (i.e., east-west traffic such as storage
+    access) using technologies such as VPN and VLAN.
+
+
+.. container:: note
+
+    :need:`R-86261`
+
+    The VNF **MUST** be able to authenticate and authorize all remote access.
+
+
+.. container:: note
+
+    :need:`R-62498`
+
+    The VNF **MUST** support only encrypted access protocols, e.g., TLS,
+    SSH, SFTP.
+
+
+.. container:: note
+
+    :need:`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. This does not preclude the VNF providing other
+    interfaces for modifying rules.
+
+
+Requirements Removed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    R-23882
+
+    The VNF **SHOULD** provide the capability for the Operator to run security
+    vulnerability scans of the operating system and all application layers.
+
+
+.. container:: note
+
+    R-343842
+
+    The VNF **MUST**, after a successful login at command line or a GUI,
+    display the last valid login date and time and the number of unsuccessful
+    attempts since then made with that user's ID. This requirement is only
+    applicable when the user account is defined locally in the VNF.
+
+
+.. container:: note
+
+    R-40813
+
+    The VNF **SHOULD** support the use of virtual trusted platform
+    module.
+
+
+VNF Security > VNF Identity and Access Management Requirements
+--------------------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-251639`
+
+    The VNF **MUST** provide explicit confirmation of a session termination
+    such as a message, new page, or rerouting to a login page.
+
+
+.. container:: note
+
+    :need:`R-358699`
+
+    The VNF **MUST** support at least the following roles: system administrator,
+    application administrator, network function O&M.
+
+
+.. container:: note
+
+    :need:`R-373737`
+
+    The VNF **MUST**, if not integrated with the operator's IAM system, provide
+    a mechanism for assigning roles and/or permissions to an identity.
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-86835`
+
+    The VNF **MUST** set the default settings for user access
+    to deny authorization, except for a super user type of account.
+
+
+.. container:: note
+
+    :need:`R-814377`
+
+    The VNF **MUST** have the capability of allowing the Operator to create,
+    manage, and automatically provision user accounts using one of the protocols
+    specified in Chapter 7.
+
+
+.. container:: note
+
+    :need:`R-231402`
+
+    The VNF **MUST** provide a means to explicitly logout, thus ending that session.
+
+
+.. container:: note
+
+    :need:`R-81147`
+
+    The VNF **MUST**, if not integrated with the Operator’s Identity and
+    Access Management system, support multifactor authentication on all
+    protected interfaces exposed by the VNF for use by human users.
+
+
+.. container:: note
+
+    :need:`R-78010`
+
+    The VNF **MUST** support LDAP in order to integrate with an external identity
+    and access manage system. It MAY support other identity and access management
+    protocols.
+
+
+.. container:: note
+
+    :need:`R-79107`
+
+    The VNF **MUST**, if not integrated with the Operator’s Identity
+    and Access Management system, support the ability to lock out the
+    userID after a configurable number of consecutive unsuccessful
+    authentication attempts using the same userID. The locking mechanism
+    must be reversible by an administrator and should be reversible after
+    a configurable time period.
+
+
+.. container:: note
+
+    :need:`R-42874`
+
+    The VNF **MUST** allow the Operator to restrict access to protected
+    resources based on the assigned permissions associated with an ID in
+    order to support Least Privilege (no more privilege than required to
+    perform job functions).
+
+
+.. container:: note
+
+    :need:`R-581188`
+
+    The VNF **MUST NOT** identify the reason for a failed authentication,
+    only that the authentication failed.
+
+
+.. container:: note
+
+    :need:`R-23135`
+
+    The VNF **MUST**, if not integrated with the Operator's identity and
+    access management system, authenticate all access to protected resources.
+
+
+.. container:: note
+
+    :need:`R-479386`
+
+    The VNF **MUST** provide the capability of setting a configurable message
+    to be displayed after successful login. It MAY provide a list of supported
+    character sets.
+
+
+.. container:: note
+
+    :need:`R-931076`
+
+    The VNF **MUST** support account names that contain at least A-Z, a-z,
+    and 0-9 character sets and be at least 6 characters in length.
+
+
+.. container:: note
+
+    :need:`R-45719`
+
+    The VNF **MUST**, if not integrated with the Operator's Identity and Access
+    Management system, enforce a configurable "terminate idle sessions"
+    policy by terminating the session after a configurable period of inactivity.
+
+
+Requirements Removed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    R-15671
+
+    The VNF **MUST** provide access controls that allow the Operator
+    to restrict access to VNF functions and data to authorized entities.
+
+
+.. container:: note
+
+    R-71787
+
+    Each architectural layer of the VNF (eg. operating system, network,
+    application) **MUST** support access restriction independently of all
+    other layers so that Segregation of Duties can be implemented.
+
+
+.. container:: note
+
+    R-85419
+
+    The VNF **SHOULD** support OAuth 2.0 authorization using an external
+    Authorization Server.
+
+
+VNF and PNF On-boarding and package management > Resource Configuration
+-----------------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-89571`
+
+    The VNF or PNF PROVIDER **MUST** provide artifacts for configuration
+    management using at least one of the following technologies;
+    a) Netconf/YANG, b) Chef, or c) Ansible.
+
+
+VNF or PNF CSAR Package > VNF or PNF Package Contents
+-----------------------------------------------------
+
+
+Requirements Added
+~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-972082`
+
+    If the Manifest file in the PNF CSAR package includes "onap_pnf_sw_information"
+    as a non-MANO artifact set identifiers, then the PNF software information file is
+    included in the package and it **MUST** be compliant to:
+
+    - The file extension which contains the PNF software version must be .yaml
+
+    - The PNF software version information must be specified as following:
+
+    .. code-block:: yaml
+
+       pnf_software_information:
+
+        - pnf_software_version:  "<version>"
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-40820`
+
+    The VNF or PNF CSAR PACKAGE **MUST** enumerate all of the open source
+    licenses their VNF(s) incorporate. CSAR License directory as per ETSI
+    SOL004.
+
+    for example ROOT\\Licenses\\ **License_term.txt**
+
+
+.. container:: note
+
+    :need:`R-795126`
+
+    The VNF CSAR package Manifest file **MUST** start with the VNF
+    package metadata in the form of a name-value pairs. Each pair shall appear
+    on a different line. The name is specified as following:
+
+      - vnf_provider_id
+
+      - vnf_product_name
+
+      - vnf_release_date_time
+
+      - vnf_package_version
+
+
+.. container:: note
+
+    :need:`R-01123`
+
+    The VNF or PNF CSAR package Manifest file **MUST** contain: VNF or PNF
+    package meta-data, a list of all artifacts (both internal and
+    external) entry's including their respected URI's, as specified
+    in ETSI GS NFV-SOL 004
+
+
+.. container:: note
+
+    :need:`R-221914`
+
+    The VNF or PNF CSAR package **MUST** contain a human-readable change log text
+    file. The Change Log file keeps a history describing any changes in the VNF
+    or PNF package. The Change Log file is kept up to date continuously from
+    the creation of the CSAR package.
+
+
+.. container:: note
+
+    :need:`R-57019`
+
+    The PNF CSAR PACKAGE Manifest file **MUST** start with the PNF
+    package metadata in the form of a name-value pairs. Each pair shall appear
+    on a different line. The name is specified as following:
+
+      - pnfd_provider
+
+      - pnfd_name
+
+      - pnfd_release_date_time
+
+      - pnfd_archive_version
+
+
+.. container:: note
+
+    :need:`R-146092`
+
+    If one or more non-MANO artifact(s) is included in the VNF or PNF CSAR
+    package, the Manifest file in this CSAR package **MUST** contain one or more
+    of the following ONAP non-MANO artifact set identifier(s):
+
+      - onap_ves_events: contains VES registration files
+
+      - onap_pm_dictionary: contains the PM dictionary files
+
+      - onap_yang_modules: contains Yang module files for configurations
+
+      - onap_ansible_playbooks: contains any ansible_playbooks
+
+      - onap_pnf_sw_information: contains the PNF software information file
+
+      - onap_others: contains any other non_MANO artifacts, e.g. informational
+        documents
+
+     *NOTE: According to ETSI SOL004 v.2.6.1, every non-MANO artifact set shall be
+     identified by a non-MANO artifact set identifier which shall be registered in
+     the ETSI registry. Approved ONAP non-MANO artifact set identifiers are documented
+     in the following page* https://wiki.onap.org/display/DW/ONAP+Non-MANO+Artifacts+Set+Identifiers
+
+
+VNF or PNF CSAR Package > VNF or PNF Package Structure and Format
+-----------------------------------------------------------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-506221`
+
+    The VNF or PNF CSAR file **MUST** be a zip file with .csar extension.
+
+
+.. container:: note
+
+    :need:`R-87234`
+
+    The VNF or PNF CSAR package provided by a VNF or PNF vendor **MUST** be with
+    TOSCA-Metadata directory (CSAR Option 1) as specified in
+    ETSI GS NFV-SOL004.
+
+    **Note:** SDC supports only the CSAR Option 1 in Dublin. The Option 2
+    will be considered in future ONAP releases.
+
+
+{network-role}
+--------------
+
+
+Requirements Changed
+~~~~~~~~~~~~~~~~~~~~
+
+
+.. container:: note
+
+    :need:`R-21330`
+
+    A VNF's Heat Orchestration Template's Resource property parameter that is
+    associated with an ONAP
+    external network **MUST** include the ``{network-role}``
+    as part of the parameter name.
+
+
+.. container:: note
+
+    :need:`R-84322`
+
+    A VNF's Heat Orchestration Template's Resource property parameter that
+    is associated with an ONAP internal network (per the ONAP definition, see
+    Requirements R-52425 and R-46461 and R-35666)
+    **MUST** include
+    ``int_{network-role}`` as part of the parameter name,
+    where ``int_`` is a hard coded string.
+
+
+.. container:: note
+
+    :need:`R-96983`
+
+    A VNF's Heat Orchestration Template's Resource ID that is associated
+    with an ONAP internal network (per the ONAP definition, see Requirements
+    R-52425 and R-46461 and R-35666)
+    **MUST** include ``int_{network-role}`` as part
+    of the Resource ID, where ``int_`` is a hard coded string.
+
+
+.. container:: note
+
+    :need:`R-11168`
+
+    A VNF's Heat Orchestration Template's Resource ID that is associated with
+    an ONAP external network **MUST** include the ``{network-role}`` as part
+    of the resource ID.
+
+
+.. container:: note
+
+    :need:`R-69014`
+
+    When a VNF's port connects to an ONAP internal network or ONAP
+    external network,
+    a network role, referred to
+    as the ``{network-role}`` **MUST** be assigned to the network for
+    use in the VNF's Heat Orchestration Template.  The ``{network-role}``
+    is used in the VNF's Heat Orchestration Template's resource IDs
+    and resource property parameter names.
+
index 73ad1fb..2ff8218 100644 (file)
 VNFRQTS Project Release Notes
 ==============================
 
+Version: 6.0.0
+--------------
+
+:Release Date: 2020-05-14
+
+.. container:: note
+
+   :doc:`Detailed Summary of Changes <changes-by-section-frankfurt>`
+
+A higher level summary of changes as well as non-requirement impacting
+changes can be found below.
+
+**New Features**
+    - Moved Release Notes to be more discover-able
+    - Significant additions, updates, and removals in Security requirements
+    - Updated latest
+      :ref:`VES Event Listener Specification  <ves_event_listener_7_1>` to 7.1.1
+    - Added :ref:`VES Event Listener Specification 5.4.1 <ves_event_listener_5_41>`
+      as ONAP still supports this version
+    - Updated Ansible Requirements in :ref:`vnf_configuration_management`
+
+**Bug Fixes**
+    - Fixed typos
+    - Fixed metadata errors
+    - Fixed traceability matrix rendering
+    - Reformatted VES spec docs
+    - Cleaning requirements for TOSCA/HEAT
+    - Cleaning requirements for VNF or PNF
+
+**Known Issues**
+    - Links that refer to "latest" version are static.  Please report
+      any broken links.
+
+**Security Issues**
+    - None
+
+**Upgrade Notes**
+    - If you would like to add requirements, you **MUST** follow
+      `instructions on Wiki <https://wiki.onap.org/display/DW/VNFRQTS+How+to+Contribute>`__.
+    - If you would like to see a list of JIRA tickets closed in El Alto,
+      `please click here for Frankfurt changes <https://jira.onap.org/projects/VNFRQTS/versions/10841>`_.
+
+**Deprecation Notes**
+    - None
+
+**Other**
+    - None
+
+
 Version: 5.0.1
 --------------