Splitting NF reqt from VES spec

- Moved content in VES Event Listener spec that was specific
  to defining NF behavior to Monitoring requirements
- Expanded requirements regarding protocol selection
- Provided additional guidance for VES client configuration
- Reorganized sections of Event Listener for a more logical flow
- Fixed various small formatting issues in VES 7.2 spec

Issue-ID: VNFRQTS-813
Signed-off-by: Lovett, Trevor <trevor.lovett@att.com>
Change-Id: I4ca6fa4d846465c90520f8ebb133a1301d3509cf
Signed-off-by: Lovett, Trevor <trevor.lovett@att.com>

1 files changed, 376 insertions, 875 deletions

diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst
index 1f84a66..b461a47 100755
--- a/docs/Chapter7/Monitoring-And-Management.rst
+++ b/docs/Chapter7/Monitoring-And-Management.rst
@@ -12,302 +12,183 @@
    See the License for the specific language governing permissions and
    limitations under the License.
 
-
 Monitoring & Management
 -----------------------
 
-This section addresses data collection and event processing functionality that
-is directly dependent on the interfaces provided by the VNFs' or PNFs' APIs.
-These can be in the form of asynchronous interfaces for event, fault
-notifications, and autonomous data streams. They can also be synchronous
-interfaces for on-demand requests to retrieve various performance, usage, and
-other event information. It should be understood that events are well
-structured packages of information, identified by an eventName, which are
-communicated to subscribers who are interested in the eventName. Events are
-simply a way of communicating well-structured packages of information to one
-or more instances of an Event Listener service.
-
-The target direction for these interfaces is to employ APIs that are
-implemented utilizing standardized messaging and modeling protocols over
-standardized transports. Standardized environments (physical, virtual) present
-a tremendous opportunity to eliminate the need for proprietary interfaces while
-removing the traditional boundaries between Network Management Systems and
-Element Management Systems. Additionally, virtualized NFs provide the ability
-to instrument networking applications by creating event records to test and
-monitor end-to-end data flow through the network, similar to what physical or
-virtual probes provide without the need to insert probes at various points in
-the network. Providers must be able to provide the aforementioned set of
-required data directly to the ONAP collection layer using standardized
-interfaces.
-
-
-Data Model for Event Records
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes the data model for the collection of telemetry data from
-physical or virtual NFs by Service Providers (SPs) to manage NF health and
-run-time life cycle. This data model is referred to as the VES Data Model. The
-VES acronym originally stood for Virtual-function Event Streaming, but VES has
-been generalized to support network-function event streaming, whether
-virtualized or not.
-
-The VES Data Model describes a vendor-agnostic common vocabulary of event
-payloads. Vendor-specific, product-specific or service-specific data is
-supported by the inclusion of a flexible additional information field
-structure. The VES Data Models' common vocabulary is used to drive standard
-and automated data analytics (policy-driven analytics) within the ONAP
-DCAE Framework.
-
-While this document is focused on specifying some of the records from the
-ONAP perspective, there may be other external bodies using the same framework
-to specify additional records. For example, OPNFV has a VES project that is
-looking to specify records for OpenStack's internal telemetry to manage
-application (VNFs or PNFs), physical and virtual infrastructure (compute,
-storage, network devices, etc.) and virtual infrastructure managers (cloud
-controllers, SDN controllers). It uses ONAP's VES Agent to generate VES events
-from the NF and Intel's collectD agent to generate infrastructure VES events.
-Note that any configurable parameters for these data records (e.g., frequency,
-granularity, policy-based configuration) will be managed using the
-"Configuration" framework described in the prior sections of this document.
-The infrastructure metrics have been funneled via the ONAP Multi-VIM Project
-and are now included in current specifications.
-
-The Data Model consists of:
-
-  - Common Header Record: This data structure precedes each of the
-    Technology Independent and Technology Specific records sections of
-    the data model.
-
-  - Technology Independent Records: This version of the document specifies
-    the model for fault, heartbeat, measurement, notification, perf3gpp,
-    pnfRegistration, stateChange, syslog, and thresholdCrossingAlert (TCA)
-    records. In the future, these may be extended to support other types of
-    technology independent records. Each of these records allows additional
-    fields (name/value pairs) for extensibility. The NF provider may use these
-    NF provider-specific additional fields to provide additional information
-    that may be relevant to the managing systems.
-
-  - Technology Specific Records: This version of the document specifies the
-    model for mobileFlow, sipSignaling and voiceQuality records. In the
-    future, these may be extended to support other types of records (e.g.
-    Network Fabric, Security records, etc.). Each of these records allows
-    additional fields (name/value pairs) for extensibility. The NF provider can
-    use these NF-specific additional fields to provide additional information
-    that may be relevant to the managing systems. A placeholder for additional
-    technology specific areas of interest to be defined in the future documents
-    has been depicted.
-
-|image0|
-
-Figure 1. Data Model for Event Records
-
-Event Records - Data Structure Description
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The data structure for event records consists of:
-
--  a Common Event Header block; and
-
--  zero (heartbeat) or more technology independent domain blocks; or
-
-   - e.g. fault, measurement, notification, perf3gpp, pnfRegistration,
-     stateChange, syslog, TCA, otherFields etc.
-
--  technology specific domain blocks.
-
-   - e.g. mobileFlow, sipSignaling, voiceQuality, etc.
-
-Common Event Header
-~~~~~~~~~~~~~~~~~~~~~
-
-The common header that precedes any of the domain-specific records contains
-information identifying the type of record to follow, information about the
-sender and other identifying characteristics related to the domain and event.
-(e.g., name, priority, sequence number, source, timestamp, type, etc.).
+In ONAP, DCAE is responsible of collecting, receiving, and analyzing
+NF monitoring data. This data serves the basis for tracking the health,
+performance, and operational status of the NF. DCAE provides a
+number of predefined interfaces based upon accepted, open standards to support
+monitoring data ingestion. Some of these interfaces collect data by polling or
+pulling data from the NF using standard protocols. Other DCAE interfaces receive
+monitoring data (such as VES events) that are pushed from the NFs.
+
+A NF that produces monitoring data and uses protocols that are compatible with
+ONAP's predefined monitoring ingestion capabilities can easily be integrated
+with ONAP through simple configuration rather than custom development.
+
+This chapter will define the expected requirements for a NF to easily integrate
+with an instance of ONAP.
+
+Monitoring and Fault Protocol Selection
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section provides the proper guidance on how a NF should determine the
+protocol and data format for providing a specific types of telemetry data to
+ONAP.
 
 .. req::
-   :id: R-528866
-   :target: VNF
-   :introduced: casablanca
-   :validation_mode: in_service
-   :impacts: dcae
+   :id: R-82909
+   :target: VNF or PNF
    :keyword: MUST
-   :updated: dublin
+   :introduced: guilin
 
-   The VNF **MUST** produce VES events that include the following mandatory
-   fields in the common event header.
-
-    * ``domain`` - the event domain enumeration
-    * ``eventId`` - the event key unique to the event source
-    * ``eventName`` - the unique event name
-    * ``lastEpochMicrosec`` - the latest unix time (aka epoch time) associated
-      with the event
-    * ``priority`` - the processing priority enumeration
-    * ``reportingEntityName`` - name of the entity reporting the event or
-      detecting a problem in another VNF or PNF
-    * ``sequence`` - the ordering of events communicated by an event source
-    * ``sourceName`` - name of the entity experiencing the event issue, which
-      may be detected and reported by a separate reporting entity
-    * ``startEpochMicrosec`` - the earliest unix time (aka epoch time)
-      associated with the event
-    * ``version`` - the version of the event header
-    * ``vesEventListenerVersion`` - Version of the VES event listener API spec
-      that this event is compliant with
-
-Technology Independent Records
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The current version of the data model supports the following technology
-independent event records:
-
-   * ``fault`` - the fault record, describing a condition in the fault domain,
-     contains information about device failures. The fault event provides data
-     such as the entity experiencing a fault, the severity, resulting status,
-     etc.
-
-   * ``heartbeat`` - the heartbeat record provides an optional structure for
-     communicating information about device health. Heartbeat records would
-     only have the Common Event Header block. An optional heartbeat domain is
-     available to specify information such as heartbeat interval and
-     recommended action upon missing heartbeat interval. Heartbeat avoids the
-     need to ping a device.  A communication failure can be determined via
-     missing heartbeat events being delivered to DCAE and appropriate action
-     (e.g. restart VM, rebuild VNF or create ticket) can be taken by DCAE
-     CLAMP.
-
-   * ``Measurements`` - the Measurements Record contains information about
-     PNF or VNF and PNF or VNF resource structure and its condition to help
-     in the management of the resources for purposes of capacity planning,
-     elastic scaling, performance management and service assurance. These
-     are soft alarms providing an opportunity for proactive maintenance.
-
-   * ``Notification`` - the Notification Record provides a structure for
-     communicating notification information from the PNF or VNF. It can contain
-     notification information related to the current operational state that is
-     reported by the PNF or VNF. As an example, when cards or port name of the
-     entity have changed state. (e.g., offline -> online) Other use cases
-     include notification of file ready for collection using Bulk Data Transfer
-     or notification on configuration changes to a device.
-
-   * ``Other`` - the Other Record defines fields for events that do not have a
-     defined domain but are needed to be collected and sent to DCAE. This
-     record provides a mechanism to convey a complex set of fields (possibly
-     nested or opaque) and is purely intended to address miscellaneous needs
-     such as addressing time-to-market considerations or other proof-of-concept
-     evaluations. Hence, use of this record type is discouraged and should be
-     minimized. (Note: the Other domain could be used to create and test new
-     domain ideas.)
-
-   * ``perf3gpp`` - the perf3gpp record provides a structure for communicating
-     information that supports 3GPP defined performance metrics. The perf3gpp
-     record can contain information from vendors, including measurement name,
-     measurement family, measured object class, description, collection method,
-     value ranges, unit of measure, triggering conditions and other measurement
-     information.
-
-   * ``pnfRegistration`` - the pnfRegistration Record provides a structure for
-     registration of a physical network function. The pnfRegistration Record
-     can contain information about attributes related to the physical network
-     function including serial number, software revision, unit type and vendor
-     name.
-
-   * ``stateChange`` - the State Change Record provides a structure for
-     communicating information about data flow through the PNF or VNF. The
-     State Change Record can contain information about state change related to
-     physical device that is reported by the PNF or VNF. As an example, when
-     cards or port name of the entity that has changed state. Note: The
-     Notification Domain can also communicate similar information.
-
-   * ``Syslog`` - the Syslog Record provides a structure for communicating any
-     type of information that may be logged by the PNF or VNF. It can contain
-     information about system internal events, status, errors, etc. It is
-     recommended that low volume control or session logs are communicated via a
-     push mechanism, while other large volume logs should be sent via file
-     transfer.
-
-   * ``thresholdCrossingAlert`` - the Threshold Crossing Alert (TCA) Record
-     provides a structure for communicating information about threshold
-     crossing alerts. It uses data from the Measurement or a similar domain to
-     watch for a Key Performance Indicator (KPI) threshold that has been
-     crossed. TCA provides alert definitions and types, actions, events,
-     timestamps and physical or logical details.
-
-
-Technology Specific Records
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   The VNF or PNF **MUST** report faults and alarms using either
+   :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`
+   or :ref:`SNMP <snmp_monitoring_requirements>`. (NOTE: See relevant sections
+   for more detailed requirements)
 
-The current version of the data model supports the following technology
-specific event records:
+.. req::
+   :id: R-554966
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-   * ``Mobile Flow`` - the Mobile Flow Record provides a structure for
-     communicating information about data flow through the NF. It can contain
-     information about connectivity and data flows between serving elements for
-     mobile service, such as between LTE reference points, etc.
+   The VNF or PNF **MUST** report performance metrics using
+   :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`
+   or :ref:`bulk_performance_measurement`.
 
-   * ``Signaling`` - the Signaling Record provides a structure for
-     communicating information about signaling messages, parameters and
-     signaling state. It can contain information about data flows for signaling
-     and controlling multimedia communication sessions such as voice and video
-     calls.
+.. req::
+   :id: R-69111
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-   * ``Voice Quality`` - the Voice Quality Record provides a structure for
-     communicating information about voice quality statistics including media
-     connection information, such as transmitted octet and packet counts,
-     packet loss, packet delay variation, round-trip delay, QoS parameters and
-     codec selection.
+   The VNF or PNF **MUST** report application logs using either
+   :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`
+   or Syslog in compliance with
+   `RFC 5424 <https://tools.ietf.org/html/rfc5424>`__ .
 
-   * ``Future Domains`` - the Future Domains Record is a placeholder for
-     additional technology specific areas of interest that will be defined and
-     described in the future documents.
 
-Miscellaneous
-~~~~~~~~~~~~~
+.. req::
+   :id: R-209104
+   :target: VNF or PNF
+   :keyword: SHOULD
+   :introduced: guilin
 
-The event specification contains various extensible structures (e.g. hashMap)
-that enable event publishers to send information that has not been explicitly
-defined.
+   The VNF or PNF producing VES syslog events **SHOULD** restrict these
+   events to those that convey significant errors or warnings needed to support
+   the operation or troubleshooting of the VNF or PNF. It is expected the
+   volume of such events would be lower (e.g. less than 2000 per day) than
+   more detailed events produced in the course of normal operations.
 
 .. req::
-   :id: R-283988
-   :target: VNF
-   :introduced: casablanca
-   :validation_mode: in_service
+   :id: R-332680
+   :target: VNF or PNF
+   :keyword: SHOULD
    :impacts: dcae
-   :keyword: MUST NOT
+   :validation_mode: in_service
+   :introduced: casablanca
+   :updated: guilin
 
-   The VNF, when publishing events, **MUST NOT** send information through
-   extensible structures if the event specification has explicitly defined
-   fields for that information.
+   The VNF or PNF producing VES events **SHOULD** deliver syslog messages
+   that meet the criteria in R-209104 to the VES Event Listener using the
+   ``syslog`` VES domain.
 
 .. req::
-   :id: R-470963
-   :target: VNF
+   :id: R-935717
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
+
+   The VNF or PNF **MUST** report heartbeats using
+   :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`.
+
+.. req::
+   :id: R-697654
+   :target: VNF or PNF
+   :keyword: MAY
    :introduced: casablanca
+   :updated: guilin
+   :impacts: DCAE
    :validation_mode: in_service
-   :impacts: dcae
-   :keyword: MUST
 
-   The VNF, when publishing events, **MUST** leverage camel case to separate
-   words and acronyms used as keys that will be sent through extensible fields.
-   When an acronym is used as the key, then only the first letter shall be
-   capitalized.
+   The VNF or PNF **MAY** leverage ONAP's High Volume VNF Event Streaming
+   (HV-VES) when there is a need to deliver large volumes of real-time
+   performance management metrics. See
+   `HV-VES Collector <https://onap-doc.readthedocs.io/projects/onap-dcaegen2/en/latest/sections/services/ves-hv/index.html>`__
+   service details for more information.
 
 .. req::
-   :id: R-408813
-   :target: VNF
+   :id: R-857511
+   :target: VNF or PNF PROVIDER
    :keyword: MUST
-   :introduced: casablanca
+   :introduced: guilin
+   :impacts: DCAE
    :validation_mode: none
-   :impacts: dcae
 
-   The VNF, when publishing events, **MUST** pass all information it is
-   able to collect even if the information field is identified as optional.
-   However, if the data cannot be collected, then optional fields can be
-   omitted.
+   VNF or PNF Provider **MUST** have agreement with the Service Provider before
+   utilizing the HV-VES option for monitoring as this option does not fully
+   integrate with the ONAP's DCAE event processing capabilities.
+
+.. req::
+   :id: R-908291
+   :target: VNF or PNF
+   :keyword: MAY
+   :introduced: casablanca
+   :impacts: dcae, dmaap
+   :validation_mode: in_service
+   :updated: guilin
+
+   The VNF or PNF **MAY** leverage a bulk VNF or PNF telemetry transmission
+   mechanism in instances where other transmission
+   methods are not practical or advisable.
+
+   NOTE: For additional information and use cases for the Bulk Telemetry
+   Transmission Mechanism, please refer to
+   the :ref:`bulk_performance_measurement` requirements and the
+   `5G - Bulk PM ONAP Development <https://wiki.onap.org/display/DW/5G+-+Bulk+PM>`__
+   Wiki page.
 
+.. _snmp_monitoring_requirements:
+
+SNMP Monitoring Requirements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. req::
+   :id: R-261501
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-Data Structure Specification of the Event Record
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+   If the VNF or PNF is using SNMP, then the VNF or PNF Provider **MUST**
+   provide a Management Information Base (MIB) file that uniquely identifies
+   and describes all SNMP events exposed by the network function.
+
+.. req::
+   :id: R-233922
+   :target: VNF or PNF
+   :keyword: SHOULD
+   :introduced: guilin
+
+   If the VNF or PNF is using SNMP, then the VNF or PNF Provider **SHOULD**
+   provide examples of all SNMP alarms.
+
+.. _ves_monitoring_requirements:
+
+Virtual Function Event Streaming (VES) Client Requirements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The VES protocol enables NFs to transmit telemetry data in a non-proprietary,
+extensible format to ONAP using the HTTP protocol. This chapter will define
+the requirements for a NF to deliver events to ONAP's VES event listeners in
+a manner that conforms with the appropriate VES Event Listener specifications,
+and ensures the NF can be configured to maximize the reliability of telemetry
+data delivery.
+
+
+Event Definition and Registration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. req::
    :id: R-520802
@@ -316,10 +197,11 @@ Data Structure Specification of the Event Record
    :introduced: casablanca
    :validation_mode: static
    :impacts: dcae
-   :updated: el alto
+   :updated: guilin
 
-   The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with
-   the :ref:`VES Event Registration specification <ves_event_registration_3_2>`
+   If the VNF or PNF is using VES, then the VNF or PNF Provider **MUST** provide
+   a YAML file formatted in adherence with the
+   :ref:`VES Event Registration specification <ves_event_registration_3_2>`
    that defines the following information for each event produced by the VNF:
 
    * ``eventName``
@@ -332,39 +214,23 @@ Data Structure Specification of the Event Record
    :target: VNF or PNF PROVIDER
    :keyword: MUST
    :introduced: casablanca
+   :updated: guilin
    :validation_mode: static
    :impacts: dcae
-   :updated: el alto
-
-   The VNF or PNF provider **MUST** indicate specific conditions that may arise, and
-   recommend actions that may be taken at specific thresholds, or if specific
-   conditions repeat within a specified time interval, using the semantics and
-   syntax described by the :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
 
-**NOTE:** The Service Provider may override VNF or PNF provider Event
-Registrations using the ONAP SDC Design Studio to finalizes Service
-Provider engineering rules for the processing of the VNF or PNF events.
-These changes may modify any of the following:
+   A VNF or PNF Provider utilizing VES **MUST** indicate specific conditions
+   that may arise, and recommend actions that may be taken at specific
+   thresholds, or if specific conditions repeat within a specified time
+   interval, using the semantics and syntax described by the
+   :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
 
-* Threshold levels
-* Specified actions related to conditions
+   **NOTE:** The Service Provider may override VNF or PNF provider Event
+   Registrations using the ONAP SDC Design Studio to finalizes Service
+   Provider engineering rules for the processing of the VNF or PNF events.
+   These changes may modify any of the following:
 
-
-.. req::
-   :id: R-570134
-   :target: VNF or PNF
-   :keyword: MUST
-   :introduced: casablanca
-   :validation_mode: in_service
-   :impacts: dcae
-   :updated: frankfurt
-
-   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.
+   * Threshold levels
+   * Specified actions related to conditions
 
 .. req::
    :id: R-123044
@@ -375,549 +241,308 @@ These changes may modify any of the following:
    :impacts: dcae
    :updated: dublin
 
-   The VNF or PNF Provider **MAY** require that specific events, identified by their
-   ``eventName``, require that certain fields, which are optional in the common
-   event format, must be present when they are published.
+   The VNF or PNF Provider **MAY** require that specific events, identified by
+   their ``eventName``, require that certain fields, which are optional in the
+   common event format, must be present when they are published.
 
-
-Transports and Protocols Supporting Resource Interfaces
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Transport mechanisms and protocols have been selected to enable both high
-volume and moderate volume data sets, as well as asynchronous and synchronous
-communications over secure connections. The specified encoding provides
-self-documenting content, so data fields can be changed as needs evolve, while
-minimizing changes to data delivery.
-
-.. req::
-   :id: R-798933
-   :target: VNF or PNF
-   :keyword: SHOULD
-   :impacts: dcae
-   :validation_mode: in_service
-   :introduced: casablanca
-   :updated: dublin
-
-   The VNF or PNF **SHOULD** deliver event records that fall into the event domains
-   supported by VES.
+Event Formatting and Usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. req::
-   :id: R-821839
+   :id: R-570134
    :target: VNF or PNF
    :keyword: MUST
-   :impacts: dcae
-   :validation_mode: in_service
    :introduced: casablanca
-   :updated: dublin
-
-   The VNF or PNF **MUST** deliver event records to ONAP using the common
-   transport mechanisms and protocols defined in this specification.
-
-The term 'Event Record' is used throughout this document to represent various
-forms of telemetry or instrumentation made available by the VNFs or PNFs
-including, faults, status events, various other types of VNF or PNF
-measurements and logs.
-
-Common structures and delivery protocols for other types of data will be given
-in future versions of this document as we gain more insight into data volumes
-and required processing.
-
-In the following sections, we provide options for encoding, serialization and
-data delivery. Agreements between Service Providers and VNF or PNF providers
-determine which encoding, serialization and delivery method to use for
-particular data sets.
-
-.. req::
-   :id: R-932071
-   :target: VNF or PNF
-   :keyword: MUST
+   :updated: guilin
+   :validation_mode: in_service
    :impacts: dcae
-   :validation_mode: none
-   :introduced: casablanca
-   :updated: dublin
 
-   The VNF or PNF provider **MUST** reach agreement with the Service Provider on
-   the selected methods for encoding, serialization and data delivery
-   prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio.
+   The VES events produced by the VNF or PNF **MUST** be compliant with the
+   common event formats defined in one of the following specifications:
 
+   * :ref:`VES Event Listener 5.4.1<ves_event_listener_5_4_1>`
+   * :ref:`VES Event Listener 7.1.1<ves_event_listener_7_1>`
+   * :ref:`VES Event Listener 7.2<ves_event_listener_7_2>`
 
-VNF or PNF Telemetry using VES/JSON Model
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   The latest version (7.2) should be preferred. Earlier versions are
+   provided for backwards compatibility.
 
 .. req::
-   :id: R-659655
+   :id: R-528866
    :target: VNF or PNF
-   :keyword: SHOULD
-   :impacts: dcae
-   :validation_mode: in_service
    :introduced: casablanca
-   :updated: dublin
-
-   The VNF or PNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2,
-   for data delivery unless there are specific performance or operational
-   concerns agreed upon by the Service Provider that would warrant using an
-   alternate model.
-
-|image1|
-
-Figure 2. VES/JSON Driven Model
+   :validation_mode: in_service
+   :impacts: dcae
+   :keyword: MUST
+   :updated: guilin
 
-VNF or PNF Telemetry using Google Protocol Buffers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   The VES events produced by the VNF or PNF **MUST** conform to the schema and
+   other formatting requirements specified in the relevant VES Event Listener
+   specification.
 
 .. req::
-   :id: R-697654
+   :id: R-283988
    :target: VNF or PNF
-   :keyword: MAY
-   :impacts: dcae
-   :validation_mode: in_service
    :introduced: casablanca
-   :updated: dublin
-
-   The VNF or PNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model
-   depicted in Figure 3 to support real-time performance management (PM) data.
-   In this model the VES events are streamed as binary-encoded GBPs over via
-   TCP sockets.
-
-|image2|
-
-Figure 3. VNF or PNF Telemetry using Google Protocol Buffers
-
-
-**NOTE:** For high-volume VNF or PNF telemetry, native (binary) Google Protocol
-Buffers (GPB) is the preferred serialization method. While supporting the GPB
-telemetry delivery approach described above, the default delivery method
-is the VES/REST JSON based model in DCAE. The purpose of the diagram above
-is to illustrate the GPB delivery concept only and not to imply a specific
-implementation.
-
-For additional information and uses cases for Real Time Performance
-Management and High Volume Stream Data Collection, please refer to the
-`5G - Real Time PM and High Volume Stream Data Collection ONAP Development <https://wiki.onap.org/display/DW/5G+-+Real+Time+PM+and+High+Volume+Stream+Data+Collection>`__
-Wiki page.
+   :updated: guilin
+   :validation_mode: in_service
+   :impacts: dcae
+   :keyword: MUST NOT
 
-Bulk Telemetry Transmission
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   A VNF or PNF producing VES events **MUST NOT** send information through
+   extensible structures if the event specification has explicitly defined
+   fields for that information.
 
 .. req::
-   :id: R-908291
+   :id: R-470963
    :target: VNF or PNF
-   :keyword: MAY
    :introduced: casablanca
-   :impacts: dcae, dmaap
+   :updated: guilin
    :validation_mode: in_service
-   :updated: dublin
-
-   The VNF or PNF **MAY** leverage bulk VNF or PNF telemetry transmission mechanism, as
-   depicted in Figure 4, in instances where other transmission methods are not
-   practical or advisable.
-
-|image3|
-
-Figure 4. VNF or PNF Telemetry using Bulk Transmission
-
-**NOTE:** An optional VES mapper micro-service can be leveraged to to extract
-measurements and publish them as VES events.
-
-For additional information and use cases for the Bulk Telemetry Transmission
-Mechanism, please refer to the `5G - Bulk PM ONAP Development <https://wiki.onap.org/display/DW/5G+-+Bulk+PM>`__
-Wiki page.
-
-Monitoring & Management Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+   :impacts: dcae
+   :keyword: SHOULD
 
-VNF telemetry via standardized interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   A VNF or PNF producing VES events **SHOULD** leverage camel case to
+   separate words and acronyms used as keys that will be sent through extensible
+   fields. When an acronym is used as the key, then only the first letter shall
+   be capitalized.
 
 .. req::
-   :id: R-821473
+   :id: R-408813
    :target: VNF or PNF
    :keyword: MUST
    :introduced: casablanca
+   :updated: guilin
+   :validation_mode: none
    :impacts: dcae
-   :validation_mode: in_service
-   :updated: dublin
-
-   The VNF or PNF MUST produce heartbeat indicators consisting of events containing
-   the common event header only per the VES Listener Specification.
 
+   A VNF or PNF producing VES events **MUST** pass all information it is
+   able to collect even if the information field is identified as optional.
+   However, if the data cannot be collected, then optional fields can be
+   omitted.
 
-JSON
-~~~~~~~~~~~~~~~~~~
+Configuration Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. req::
-    :id: R-19624
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+This section defines the types the configuration options and defaults a NF
+producing VES events should provide to ensure the NF can be configured properly
+for the Service Provider's ONAP environment and ensure reliable delivery of
+VES events.
 
-    The VNF or PNF, when leveraging JSON for events, **MUST** encode and serialize
-    content delivered to ONAP using JSON (RFC 7159) plain text format.
-    High-volume data is to be encoded and serialized using
-    `Avro <http://avro.apache.org/>`_, where the Avro data
-    format are described using JSON.
-
-Note:
-
-  - JSON plain text format is preferred for moderate volume data sets
-    (option 1), as JSON has the advantage of having well-understood simple
-    processing and being human-readable without additional decoding. Examples
-    of moderate volume data sets include the fault alarms and performance
-    alerts, heartbeat messages, measurements used for VNF scaling and syslogs.
-
-  - Binary format using Avro is preferred for high volume data sets (option 2)
-    such as mobility flow measurements and other high-volume streaming events
-    (such as mobility signaling events, mobility trace data or SIP signaling)
-    or bulk data, as this will significantly reduce the volume of data to be
-    transmitted. As of the date of this document, all events are reported
-    using plain text JSON and REST.
-
-  - Avro content is self-documented, using a JSON schema. The JSON schema is
-    delivered along with the data content
-    (http://avro.apache.org/docs/current/ ). This means the presence and
-    position of data fields can be recognized automatically, as well as the
-    data format, definition and other attributes. Avro content can be
-    serialized as JSON tagged text or as binary. In binary format, the JSON
-    schema is included as a separate data block, so the content is not tagged,
-    further compressing the volume. For streaming data, Avro will read the
-    schema when the stream is established and apply the schema to the
-    received content.
-
-  - In addition to the preferred delivery format (JSON), content delivered
-    from PNFs or VNFs to ONAP can be encoded and serialized using Google
-    Protocol Buffers (GPB). Please refer to the next section of this document
-    for additional information.
-
-In addition to the preferred method (JSON), content can be delivered
-from VNFs or PNFs to ONAP can be encoded and serialized using Google Protocol
-Buffers (GPB).
-
-Google Protocol Buffers (GPB)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+There are several methods available to provide configuration settings to a
+network function. This document does not specify the exact manner in which
+the configuration elements described below must be required. The
+configuration can be provided during instantiation (e.g. preload), provided by
+an ONAP controller action, or provided manually.
 
 .. req::
-   :id: R-257367
+   :id: R-460012
    :target: VNF or PNF
    :keyword: MUST
-   :introduced: casablanca
-   :validation_mode: in_service
-   :updated: dublin
-
-   The VNF or PNF, when leveraging Google Protocol Buffers for events, **MUST**
-   serialize the events using native Google Protocol Buffers (GPB) according
-   to the following guidelines:
+   :introduced: guilin
 
-      * The keys are represented as integers pointing to the system resources
-        for the VNF or PNF being monitored
-      * The values correspond to integers or strings that identify the
-        operational state of the VNF resource, such a statistics counters and
-        the state of an VNF or PNF resource.
-      * The required Google Protocol Buffers (GPB) metadata is provided in the
-        form of .proto files.
+   The VNF or PNF producing VES events **MUST** allow the configuration of
+   the attributes defined in Table 1 and utilize the provided default value
+   (where applicable) when the configuration value is not provided by the
+   Service Provider.
 
 .. req::
-   :id: R-978752
-   :target: VNF or PNF PROVIDER
+   :id: R-940591
+   :target: VNF or PNF
+   :keyword: SHOULD
+   :introduced: guilin
+
+   A VNF or PNF producing VES events **SHOULD** use the recommended parameter
+   name for the configurable value from Table 1.
+
+.. table:: **Table 1**: VES Configurable Values
+
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+   |Parameter             | Description                       |  Default       | Parameter Name (VES 7.2+)           |
+   +======================+===================================+================+=====================================+
+   |VES Listener Endpoint | FQDN or IP of the Event Listener  |       n/a      | ves_listener_endpoint               |
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+   |Heartbeat Interval    | Frequency in seconds the NF must  |        60      | ves_heartbeat_interval_seconds      |
+   |                      | send a heartbeat to the event     |                |                                     |
+   |                      | listener                          |                |                                     |
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+   |Timeout Value         | Duration in seconds the NF should |         5      | ves_timeout_seconds                 |
+   |                      | wait for ACK from the event       |                |                                     |
+   |                      | listener before timeout           |                |                                     |
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+   |Measurement Interval  | Window size in seconds to use for |        300     | ves_measurement_interval_seconds    |
+   |                      | aggregated measurements           |                |                                     |
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+   |HTTP Username         | Required if NF supports HTTP      |        n/a     | ves_http_username                   |
+   |                      | Basic Authentication with the     |                |                                     |
+   |                      | VES Event Listener                |                |                                     |
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+   |HTTP Password         | Required if NF supports HTTP      |        n/a     | ves_http_password                   |
+   |                      | Basic Authentication with the     |                |                                     |
+   |                      | VES Event Listener                |                |                                     |
+   +----------------------+-----------------------------------+----------------+-------------------------------------+
+
+
+VES Listener Endpoint and DNS Resolution
+++++++++++++++++++++++++++++++++++++++++
+
+In a high availability deployment of a VES Event Listener, a round-robin DNS or
+dynamic DNS may be used to either load balance or provide fault tolerance of
+the Event Listener.  Adherence to the following requirements ensure the VNF or
+PNF interacts properly with this deployment configuration.
+
+.. req::
+   :id: R-70492
+   :target: VNF or PNF
    :keyword: MUST
-   :introduced: casablanca
-   :validation_mode: static
-   :updated: dublin
-
-   The VNF or PNF providers **MUST** provide the Service Provider the following
-   artifacts to support the delivery of high-volume VNF or PNF telemetry to
-   DCAE via GPB over TLS/TCP:
-
-      * A valid VES Event .proto definition file, to be used validate and
-        decode an event
-      * A valid high volume measurement .proto definition file, to be used for
-        processing high volume events
-      * A supporting PM content metadata file to be used by analytics
-        applications to process high volume measurement events
+   :introduced: guilin
 
-Reporting Frequency
-~~~~~~~~~~~~~~~~~~~~~
+   The VNF or PNF **MUST** support DNS resolution of the VES Listener Endpoint
+   if a Fully Qualified Domain Name (FQDN) is provided.
 
 .. req::
-   :id: R-146931
+   :id: R-130645
    :target: VNF or PNF
    :keyword: MUST
-   :introduced: casablanca
-   :validation_mode: in_service
-   :updated: dublin
-
-   The VNF or PNF **MUST** report exactly one Measurement event per period
-   per source name.
+   :introduced: guilin
 
-.. req::
-    :id: R-98191
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   The VNF or PNF **MUST** respect the Time To Live provided by the DNS for
+   the VES Event Listener FQDN.
 
-    The VNF or PNF **MUST** vary the frequency that asynchronous data
-    is delivered based on the content and how data may be aggregated or
-    grouped together.
-
-        Note:
-
-        - For example, alarms and alerts are expected to be delivered as
-          soon as they appear. In contrast, other content, such as performance
-          measurements, KPIs or reported network signaling may have various
-          ways of packaging and delivering content. Some content should be
-          streamed immediately; or content may be monitored over a time
-          interval, then packaged as collection of records and delivered
-          as block; or data may be collected until a package of a certain
-          size has been collected; or content may be summarized statistically
-          over a time interval, or computed as a KPI, with the summary or KPI
-          being delivered.
-        - We expect the reporting frequency to be configurable depending on
-          the virtual network functions needs for management. For example,
-          Service Provider may choose to vary the frequency of collection
-          between normal and trouble-shooting scenarios.
-        - Decisions about the frequency of data reporting will affect
-          the size of delivered data sets, recommended delivery method,
-          and how the data will be interpreted by ONAP. These considerations
-          should not affect deserialization and decoding of the data, which
-          will be guided by the accompanying JSON schema or GPB definition
-          files.
-
-Addressing and Delivery Protocol
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-ONAP destinations can be addressed by URLs for RESTful data PUT. Future
-data sets may also be addressed by host name and port number for TCP
-streaming, or by host name and landing zone directory for SFTP transfer
-of bulk files.
-
-.. req::
-    :id: R-88482
-    :target: VNF or PNF
-    :keyword: SHOULD
-    :updated: dublin
-
-    The VNF or PNF **SHOULD** use REST using HTTPS delivery of plain
-    text JSON for moderate sized asynchronous data sets, and for high
-    volume data sets when feasible.
+Event Delivery Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. req::
-    :id: R-84879
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   :id: R-06924
+   :target: VNF or PNF
+   :keyword: MUST
+   :updated: guilin
 
-    The VNF or PNF **MUST** have the capability of maintaining a primary
-    and backup DNS name (URL) for connecting to ONAP collectors, with the
-    ability to switch between addresses based on conditions defined by policy
-    such as time-outs, and buffering to store messages until they can be
-    delivered. At its discretion, the service provider may choose to populate
-    only one collector address for a VNF or PNF. In this case, the network will
-    promptly resolve connectivity problems caused by a collector or network
-    failure transparently to the VNF or PNF.
+   The VNF or PNF producing VES events **MUST** deliver VES events as it
+   becomes available or according to the configured measurement interval.
 
 .. req::
-    :id: R-81777
+    :id: R-655209
     :target: VNF or PNF
     :keyword: MUST
-    :updated: dublin
-
-    The VNF or PNF **MUST** be configured with initial address(es) to use
-    at deployment time. Subsequently, address(es) may be changed through
-    ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a
-    RESTful API, in the same manner that other controls over data reporting
-    will be controlled by policy.
-
-.. req::
-    :id: R-08312
-    :target: VNF or PNF
-    :keyword: MAY
-    :updated: dublin
-
-    The VNF or PNF **MAY** use another option which is expected to include REST
-    delivery of binary encoded data sets.
-
-.. req::
-    :id: R-79412
-    :target: VNF or PNF
-    :keyword: MAY
-    :updated: dublin
-
-    The VNF or PNF **MAY** use another option which is expected to include TCP
-    for high volume streaming asynchronous data sets and for other high volume
-    data sets. TCP delivery can be used for either JSON or binary encoded data
-    sets.
-
-.. req::
-    :id: R-01033
-    :target: VNF or PNF
-    :keyword: MAY
-    :updated: dublin
+    :introduced: guilin
 
-    The VNF or PNF **MAY** use another option which is expected to include SFTP
-    for asynchronous bulk files, such as bulk files that contain large volumes
-    of data collected over a long time interval or data collected across many
-    VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused
-    data sets, and deliver these by REST or TCP as appropriate.)
+    The VNF or PNF producing VES events **MUST** respect the configured
+    VES Timeout Value when delivering VES events, and abort any call where
+    the VES Event Listener does not successfully acknowledge the delivery of
+    event(s) within the Timeout Value. These failed transactions should be
+    buffered and retried in accordance with the
+    :ref:`ves_buffering_requirements` Requirements.
 
 .. req::
-    :id: R-63229
-    :target: VNF or PNF
-    :keyword: MAY
-    :updated: dublin
+   :id: R-176945
+   :target: VNF or PNF
+   :keyword: SHOULD NOT
+   :introduced: guilin
 
-    The VNF or PNF **MAY** use another option which is expected to include REST
-    for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling).
+   The VNF or PNF producing VES events **SHOULD NOT** send syslog events to the
+   VES Event Listener during debug mode, but rather store syslog events locally
+   for access or possible file transfer.
 
-.. req::
-    :id: R-03070
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+.. _ves_buffering_requirements:
 
-    The VNF or PNF **MUST**, by ONAP Policy, provide the ONAP addresses
-    as data destinations for each VNF or PNF, and may be changed by Policy while
-    the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting
-    traffic to changed destinations with no loss of data, for example from
-    one REST URL to another, or from one TCP host and port to another.
+Buffering and Redelivery
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-Asynchronous and Synchronous Data Delivery
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To maximize the reliable delivery of VES events when the VES Listener becomes
+unavailable or unhealthy, the NF must adhere to these requirements.
 
 .. req::
-    :id: R-06924
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   :id: R-658596
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-    The VNF or PNF **MUST** deliver asynchronous data as data becomes
-    available, or according to the configured frequency.
+   A VNF or PNF producing VES events **MUST** buffer events that meet the
+   following criteria if the VES Event Listener is unreachable or the request
+   encounters a timeout.
 
-.. req::
-    :id: R-73285
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
-
-    The VNF or PNF **MUST** must encode, address and deliver the data
-    as described in the previous paragraphs.
+   * Faults with eventSeverity of ``MINOR``, ``MAJOR``, ``NORMAL``, or
+     ``CRITICAL``
+   * Syslog with syslogSev of ``Emergency``, ``Alert``, ``Critical``,
+     ``Error``, or ``Warning``
+   * All measurement events
 
 .. req::
-    :id: R-42140
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   :id: R-636251
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-    The VNF or PNF **MUST** respond to data requests from ONAP as soon
-    as those requests are received, as a synchronous response.
+   A VNF or PNF producing VES events **MUST** size the event buffer
+   referenced in R-658596 such that it can buffer a minimum of 1 hours of
+   events under nominal load.
 
 .. req::
-    :id: R-34660
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   :id: R-498679
+   :target: VNF or PNF
+   :keyword: MAY
+   :introduced: guilin
 
-    The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by
-    the ONAP configuration subsystem for synchronous communication.
+   A VNF or PNF producing VES events **MAY** discard buffered events older
+   than a maximum retention period, not less than 1 hour, even if the event
+   was never successfully delivered to the event listener. While discarding
+   based on this retention period is supported for backwards compatibility, it
+   is recommended to retain events until the maximum buffer size is reached per
+   R-346137 as that will maximize the number of events delivered.
 
 .. req::
-    :id: R-86586
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   :id: R-346137
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-    The VNF or PNF **MUST** use the YANG configuration models and RESTCONF
-    [RFC8040] (https://tools.ietf.org/html/rfc8040).
+   A VNF or PNF producing VES events that is buffering events per R-658596
+   **MUST** store in-scope events even when the maximum capacity of the
+   buffer (defined in R-636251) has been reached. To make room for new events
+   in this situation, hte oldest event in the buffer shall be removed
+   as necessary. (i.e. First In First Out)
 
 .. req::
-    :id: R-11240
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
-
-    The VNF or PNF **MUST** respond with content encoded in JSON, as
-    described in the RESTCONF specification. This way the encoding of a
-    synchronous communication will be consistent with Avro.
+   :id: R-379523
+   :target: VNF or PNF
+   :keyword: MUST
+   :introduced: guilin
 
-.. req::
-    :id: R-70266
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   A VNF or PNF producing VES events that is buffering events due to an
+   unavailable VES Event Listener **MUST** redeliver all buffered events
+   according to the following rules when the VNF or PNF detects the VES Event
+   Listener has become available:
 
-    The VNF or PNF **MUST** respond to an ONAP request to deliver the
-    current data for any of the record types defined in
-    `Event Records - Data Structure Description`_ by returning the requested
-    record, populated with the current field values. (Currently the defined
-    record types include fault fields, mobile flow fields, measurements for
-    VNF or PNF scaling fields, and syslog fields. Other record types will be added
-    in the future as they become standardized and are made available.)
+   * Deliver all previously buffered events before sending new events
+   * Deliver buffered events in the order they were received
 
 .. req::
-   :id: R-332680
+   :id: R-818859
    :target: VNF or PNF
-   :keyword: SHOULD
-   :impacts: dcae
-   :validation_mode: in_service
-   :introduced: casablanca
-   :updated: dublin
-
-   The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the
-   specifications in Monitoring and Management chapter.
-
-.. req::
-    :id: R-46290
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
+   :keyword: MUST
+   :introduced: guilin
 
-    The VNF or PNF **MUST** respond to an ONAP request to deliver granular
-    data on device or subsystem status or performance, referencing the YANG
-    configuration model for the VNF or PNF by returning the requested data elements.
+   The VNF or PNF producing VES events **MUST** not allow an unavailable or
+   timing out VES Event Listener to impact the performance, stability, or
+   correct execution of network function.
 
 .. req::
-    :id: R-43327
-    :target: VNF or PNF
-    :keyword: SHOULD
-    :updated: dublin
+   :id: R-103464
+   :target: VNF or PNF
+   :keyword: MAY
+   :introduced: guilin
 
-    The VNF or PNF **SHOULD** use `Modeling JSON text with YANG
-    <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
-    translated to and from JSON{RFC7951]. YANG configuration and content can
-    be represented via JSON, consistent with Avro, as described in "Encoding
-    and Serialization" section.
+   A VNF or PNF producing VES events that is buffering events due to an
+   unavailable VES Event Listener **MAY** leverage to ``publishEventBatch``
+   operation to redeliver buffered events. Please note this can only be
+   used when all buffered events belong to the same domain due to the
+   restrictions in place for the operation.
 
 Security
 ~~~~~~~~~~
 
 .. req::
-    :id: R-42366
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
-
-    The VNF or PNF **MUST** support secure connections and transports such as
-    Transport Layer Security (TLS) protocol
-    [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
-    the best current practices outlined in
-    `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
-
-.. req::
-    :id: R-44290
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
-
-    The VNF or PNF **MUST** control access to ONAP and to VNFs or PNFs, and creation
-    of connections, through secure credentials, log-on and exchange mechanisms.
-
-.. req::
-    :id: R-47597
-    :target: VNF or PNF
-    :keyword: MUST
-    :updated: dublin
-
-    The VNF or PNF **MUST** carry data in motion only over secure connections.
-
-.. req::
     :id: R-68165
     :target: VNF or PNF
     :keyword: MUST
@@ -927,80 +552,21 @@ Security
     Information (SPI) or certain proprietary data, in addition to applying the
     regular procedures for securing access and delivery.
 
-.. req::
-    :id: R-01427
-    :target: VNF or PNF
-    :keyword: MUST
-    :introduced: casablanca
-    :updated: el alto
-
-    If the VNF or PNF is using Basic Authentication, then the VNF or
-    PNF **MUST** support the provisioning of security and authentication
-    parameters (HTTP username and password) in order to be able to
-    authenticate with DCAE VES Event Listener.
-
-    Note: The configuration management and provisioning software
-    are specific to a vendor architecture.
-
-.. req::
-    :id: R-894004
-    :target: VNF or PNF
-    :keyword: MUST
-    :introduced: casablanca
-    :updated: el alto
-
-    If the VNF or PNF is using Basic Authentication, then when the VNF
-    or PNF sets up a HTTPS connection to the DCAE VES Event Listener,
-    the VNF or PNF **MUST** provide a username and password to the
-    DCAE VES Event Listener in the Authorization header and the VNF
-    or PNF MUST support one-way TLS authentication.
-
-    Note: In one-way TLS authentication, the client (VNF or PNF)
-    must authentication the server (DCAE) certificate.
-
-.. req::
-   :id: R-55634
-   :target: VNF or PNF
-   :keyword: MUST
-   :introduced: el alto
-
-   If VNF or PNF is using Basic Authentication, then the VNF or PNF
-   **MUST** be in compliance with
-   `RFC7617 <https://tools.ietf.org/html/rfc7617>`_ for authenticating HTTPS
-   connections to the DCAE VES Event Listener.
-
-.. req::
-   :id: R-43387
-   :target: VNF or PNF
-   :keyword: MUST
-   :introduced: el alto
-
-   If the VNF or PNF is using Certificate Authentication, the
-   VNF or PNF **MUST** support mutual TLS authentication and the Subject
-   Name in the end-entity certificate MUST be used according to
-   `RFC5280 <https://tools.ietf.org/html/rfc5280>`_.
-
-   Note: In mutual TLS authentication, the client (VNF or PNF) must
-   authenticate the server (DCAE) certificate and must provide its own
-   X.509v3 end-entity certificate to the server for authentication.
 
 .. req::
    :id: R-33878
    :target: VNF or PNF
    :keyword: MUST
    :introduced: el alto
+   :updated: guilin
 
-   The VNF or PNF **MUST** support one of the following authentication
-   methods for authenticating HTTPS connections to the DCAE VES Event
-   Listener:
-
-   - The preferred method is Certificate Authentication
-
-   - The non-preferred option is Basic Authentication.
+   The VNF or PNF **MUST** utilize one of the authentication methods
+   prescribed by the relevant VES Event Listener specification.
 
+.. _bulk_performance_measurement:
 
 Bulk Performance Measurement
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. req::
     :id: R-841740
@@ -1013,7 +579,6 @@ Bulk Performance Measurement
     The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer
     of monitoring data.
 
-
 .. req::
     :id: R-440220
     :target: VNF or PNF
@@ -1049,70 +614,6 @@ Bulk Performance Measurement
     Note: Recommended period is at least 24 hours.
 
 
-PM Dictionary
-^^^^^^^^^^^^^^
-
-The Performance Management (PM) Dictionary is used by analytics applications
-to interpret and process perf3gpp measurement information from vendors,
-including measurement name, measurement family, measured object class,
-description, collection method, value ranges, unit of measure, triggering
-conditions and other information. The ultimate goal is for analytics
-applications to dynamically process new and updated measurements based on
-information in the PM Dictionary.
-
-The PM dictionary is supplied by NF vendors in two parts:
-
-  - PM Dictionary Schema: specifies meta-information about perf3gpp
-    measurement events from that vendor. The meta-information is conveyed
-    using standard meta-information keywords, and may be extended to include
-    vendor-specific meta-information keywords. The PM Dictionary Schema may
-    also convey a range of vendor-specific values for some of the keywords.
-
-  - PM Dictionary: defines specific perf3gpp measurements sent by vendor VNFs
-    or PNFs (each of which is compliant with a referenced PM Dictionary
-    Schema).
-
-Note:
-
-  - A vendor may provide multiple versions of the PM Dictionary Schema and
-    refer to those versions from the PM Dictionary.
-
-  - Please refer to the latest version of the VES Event Registration
-    specification for the listing of the PM Dictionary schema keywords, PM
-    Dictionary Schema example and PM Dictionary example.
-
-
-FM Meta Data
-^^^^^^^^^^^^^^
-
-FM Meta Data enables vendors to provide meta information about FM events using
-a set of standard keywords. FM Meta Data is conveyed in the YAML event
-registration using the YAML Comment qualifier. The FM Meta Data section is
-optional.
-
-FM Meta Data includes Alarm Meta Data and Fault Meta Data:
-
-  - FM Meta Data keywords must be provided in 'hash format' as Keyword: Value.
-
-  - FM Meta Data values containing whitespace must be enclosed in single
-    quotes. Successive keywords must be separated by commas.
-
-  - Alarm Meta Data, if provided, shall be placed in the YAML comments
-    qualifier at the top of the event registration for the alarm.
-
-  - Fault Meta Data, if provided, shall be placed in the YAML comments
-    qualifier of faultFields.alarmAdditionalInformation within each alarm.
-
-The above conventions will make machine processing of FM Meta Data Keywords
-easier to perform.
-
-Note:
-
-  - Please refer to the latest version of the VES Event Registration
-    specification for the listing of the FM Alarm Meta Data keywords, Fault
-    Meta Data keywords and FM Meta Data examples.
-
-
 .. |image0| image:: ../Data_Model_For_Event_Records.png
 
 .. |image1| image:: ../VES_JSON_Driven_Model.png