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>

7 files changed, 850 insertions, 1485 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
diff --git a/docs/Chapter8/index.rst b/docs/Chapter8/index.rst
index 3526c4b..628f28c 100644
--- a/docs/Chapter8/index.rst
+++ b/docs/Chapter8/index.rst
@@ -27,4 +27,5 @@ Appendix
     VES_Registration_3_2.rst
     ves7_1spec.rst
     ves_5_4_1/VESEventListener.rst
+    ves_7_2/ves_event_listener_7_2.rst
     OPNFV-Verified-Badging.rst
diff --git a/docs/Chapter8/ves_5_4_1/VESEventListener.rst b/docs/Chapter8/ves_5_4_1/VESEventListener.rst
index 8409255..d027910 100644
--- a/docs/Chapter8/ves_5_4_1/VESEventListener.rst
+++ b/docs/Chapter8/ves_5_4_1/VESEventListener.rst
@@ -3,7 +3,7 @@
 .. Copyright 2020 AT&T Intellectual Property, All rights reserved
 .. Copyright 2017-2018 Huawei Technologies Co., Ltd.
 
-.. _ves_event_listener_5_41:
+.. _ves_event_listener_5_4_1:
 
 ===================================
 Service: *VES Event Listener 5.4.1*
diff --git a/docs/Chapter8/ves_7_2/Use-Case-1.png b/docs/Chapter8/ves_7_2/Use-Case-1.png
new file mode 100644
index 0000000..f1f6c92
--- /dev/null
+++ b/docs/Chapter8/ves_7_2/Use-Case-1.png
diff --git a/docs/Chapter8/ves_7_2/Use-Case-2.png b/docs/Chapter8/ves_7_2/Use-Case-2.png
new file mode 100644
index 0000000..cff08c2
--- /dev/null
+++ b/docs/Chapter8/ves_7_2/Use-Case-2.png
diff --git a/docs/Chapter8/ves_7_2/ves_event_listener_7_2.rst b/docs/Chapter8/ves_7_2/ves_event_listener_7_2.rst
index 2c8b933..fa36bb3 100644
--- a/docs/Chapter8/ves_7_2/ves_event_listener_7_2.rst
+++ b/docs/Chapter8/ves_7_2/ves_event_listener_7_2.rst
@@ -3,10 +3,10 @@
 .. Copyright 2017 AT&T Intellectual Property, All rights reserved
 .. Copyright 2017-2018 Huawei Technologies Co., Ltd.
 
-.. _ves_event_listener_7_1:
+.. _ves_event_listener_7_2:
 
-Service: VES Event Listener 7.1.1
----------------------------------
+Service: VES Event Listener 7.2
+-------------------------------
 
 +-----------------------------------------------------------------------------+
 | **Legal Disclaimer**                                                        |
@@ -26,9 +26,9 @@ Service: VES Event Listener 7.1.1
 
 
 :Document: VES Event Listener
-:Revision: 7.1.1
-:Revision Date: January 28th, 2020
-:Author: Rich Erickson
+:Revision: 7.2
+:Revision Date: May 6th, 2020
+:Author: Trevor Lovett
 
 +-----------------+-----------------------------+
 | Contributors:   | **Min Chen – AT&T**         |
@@ -50,6 +50,10 @@ Service: VES Event Listener 7.1.1
 |                 | **Tim Verall – Intel**      |
 |                 |                             |
 |                 | **Sumit Verdi – VMWare**    |
+|                 |                             |
+|                 | **Trevor Lovett – AT&T**    |
+|                 |                             |
+|                 | **Rich Erickson – AT&T**    |
 +-----------------+-----------------------------+
 
 .. contents:: Table of Contents
@@ -61,385 +65,26 @@ This document describes the RESTful interface for the VES Event
 Listener. 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 Event Listener is
-capable of receiving any event sent in the VES Common Event Format. The
-Common Event Format is expressed in JSON schema in section 4 of this
-document. In the Common Event Format, an event consists of a required
-Common Event Header block (i.e., object) accompanied by zero or more
-event domain blocks.
+capable of receiving any event sent in the VES
+:ref:`ves_common_event_format_7_2`. In the VES Common Event Format, an event
+consists of a required
+:ref:`Common Event Header <ves_common_event_header_7_2>` (i.e., object)
+accompanied by zero or more event domain blocks.
 
 It should be understood that events are well structured packages of
-information, identified by an eventName, which are asynchronously
-communicated to subscribers who are interested in the eventName. Events
+information, identified by an ``eventName``, which are asynchronously
+communicated to subscribers who are interested in the ``eventName``. Events
 can convey measurements, faults, syslogs, threshold crossing alerts and
 other types of information. Events are simply a way of communicating
 well-structured packages of information to one or more instances of an
-Event Listener service.
-
-This document describes a RESTful connectionless push event listener
-can receive single events or batches of events in the
-Common Event Format. In future, additional documents may describe other
-transports which make use of persistent TCP connections for high volumes
-of streaming events.
-
-Compatibility with ONAP
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Unless otherwise stated, this version of the Event Listener specification is
-compatible with the release of ONAP the specification is released under.  In
-other words, if the specification is released under the Frankfurt ONAP Release,
-then the VES Event Collectors provided by DCAE will also be compatible with
-the specification.
-
-Event Registration
-~~~~~~~~~~~~~~~~~~
-
-All events must be compliant with the common event format, but specific
-events identified by their eventNames, may require that certain fields,
-which are optional in the common event format, be present when they are
-published. For example, a specific eventName may require that specific
-name-value pairs be present in the extensible structures provided within
-the Common Event Format.
-
-Events are registered using an extensible YAML format (defined in a
-separate document), which specifies, for each eventName, the fields that
-are required, what field values may be sent, and any special handling
-that should be performed on those eventNames.
-
-Naming Standards for eventName
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To prevent naming collisions, eventNames sent as part of the
-commonEventHeader, should conform to the following naming convention
-designed to summarize the purpose and type of the event, and to ensure
-the uniqueness of the eventName:
-
-    {DomainAbbreviation}\_{PublisherName}\_{Description}
-
-Each underscore-separated subfield above should start with a capital
-letter and use camel-casing to separate words and acronyms. Acronyms
-should capitalize only the first letter of the acronym. Spaces and
-underscores should not appear within any subfield.
-
-The DomainAbbreviation subfield derives from the ‘domain’ field in the
-commonEventHeader, as specified below:
-
--  ‘Fault’ for the fault domain
-
--  ‘Heartbeat’ for the heartbeat domain
-
--  ‘Measurement’ for the measurement domain
-
--  ‘MobileFlow’ for the mobileFlow domain
-
--  ‘Notification’ for the notification domain
-
--  ‘Other’ for the other domain
-
--  ‘Perf3gpp’ for the perf3gpp domain
-
--  ‘PnfReg’ for the pnfRegistration domain
-
--  ‘SipSignaling’ for the sipSignaling domain
-
--  ‘StateChange’ for the stateChange domain
-
--  ‘Syslog’ for the syslog domain
-
--  ‘Tca’ for the thresholdCrossingAlert domain
-
--  ‘VoiceQuality’ for the voiceQuality domain
-
-The PublisherName subfield describes the vendor product or application
-publishing the event. This subfield conforms to the following
-conventions:
-
--  Vendor products are specified as:
-
-     {productName}-{vendorName}
-
-    For example: Visbc-Metaswitch or Vdbe-Juniper, where a hyphen is
-    used to separate the productName and vendorName subfields. Note that
-    the productName and vendorName subfields must not include hyphens
-    themselves.
-
-    Organizing the information in this way will cause an alphabetical
-    listing of eventNames to sort similar network functions together,
-    rather than to sort them by vendor.
-
-    The productName subfield may describe a NF or a NFC. Where NFC names
-    may be reused across different NF’s, they should be specified as:
-
-     {NfName}:{NfcName}
-
-    where a colon is used to separate the NfName and NfcName subfields.
-    Note that the NfName and NfcName subfields must not include colons
-    themselves.
-
-    The ProductName may also describe other types of vendor modules or
-    components such as a VM, application or hostname. As with NFs and
-    NFCs, parent:child relationships may be communicated using colon as
-    a subfield delimiter.
-
--  Service providers who adopt the VES Common Event Format for internal
-   use, may provide PublisherName without the vendorName subfield. They
-   would typically identify an application, system, service or
-   microservice publishing the event (e.g., ‘Policy’, ‘So’,
-   ‘MobileCallRecording’ or ‘Dkat’). As with NFs and NFCs, parent:child
-   relationships may be communicated using colon as a subfield delimiter
-   (e.g., ApplicationName:ApplicationComponent).
-
-The final subfield of the eventName name should describe, in a compact
-camel case format the specific information being conveyed by the event.
-In some cases, this final subfield may not be required (e.g., in the
-case of certain heartbeats).
-
-Examples of eventNames following the naming standards are provided
-below:
-
-- Tca\_Vdbe-Ericsson\_CpuThresholdExceeded
-
-- Heartbeat\_Visbc:Mmc-Metaswitch
-
-- Syslog\_Vdbe-Ericsson
-
-- Fault\_MobileCallRecording\_PilotNumberPoolExhaustion
-
-- Other\_So:WanBonding\_InstantiationPart1Complete
-
-EventId Use Cases Examples
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
-eventId Examples:
-
-**NOTE**: Please note, the following are only *examples*, and other formats
-can be used provided they meet the requirement that the ``eventId`` is unique
-for all events or unique fault occurrence.
-
-**Example 1**: assumes a unique key for each domain consisting of domain
-followed by an integer domain<n> or domainId<n>, where <n> is a positive integer,
-e.g. fault000001, heartbeat000001, measurement000005,
-notification3gppPerfFileReady0005
-
-**Example 2**: assumes a unique integer key for all events across all domains
-<n>: 000000001, 00000002, 000000003
-
-Rules:
-
-1. All domains except Fault: each time a subsequent event is sent the
-   integer part of eventId will increment by 1. Repeat of eventId
-   assumes duplicate event. Sequence number is set to 0 for all domains
-   except fault.
-
-2. eventId construction for Fault Events:
-
-   a. Most likely scenario
-
-      *    The sourceName on each Fault event is the NF Instance Name
-           (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
-           identifying this instance of the NF.
-
-      *    The eventId on Fault events is the same every time a given
-           fault is raised (including onset and re-raise)
-
-            1. The startEpochMicrosec value for the Fault event is the
-               timestamp for when the fault onset occurs. Subsequent
-               events for the same fault will keep the same startEpochMicrosec
-               value.
-
-            2. lastEpochMicrosec indicates the current event time. This value
-               will be updated for each subsequent event for a given fault.
-
-            3. The sequence number for each Fault event is set to 1 when the
-               fault is raised and increments each time the same
-               fault event is raised, until a clear is sent.
-
-      *    After the fault is cleared, a new eventId is used.
-
-   .. image:: Use-Case-1.png
-
-   b. **Alternative Scenario**: Network Function When Fault Event Status is Not
-      Maintained.
-
-      *    The sourceName on each Fault event is the NF Instance Name
-           (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
-           identifying this instance of the NF.
-
-      *    The eventId on Fault events is the same every time a given
-           fault is raised or cleared, even if it is re-raised after it
-           had previously cleared.  So, for example, if EMS loses
-           contact with a particular device then a Fault event might be
-           sent for a raise, re-raise (because EMS has re-tried and
-           still can’t contact the device), clear (because EMS has
-           re-tried and it can contact the device) and then raise again
-           (because EMS has lost contact with the device again).  The
-           same eventId is used for all 4 of those Fault events.
-
-      *    The startEpochMicrosec value for each Fault event is the
-           timestamp for when that event is generated, not when the
-           fault first occurred.  So all 4 of the Fault events in the
-           previous bullet point would have a different timestamp.
-
-      *    lastEpochMicrosec indicates the current event time.
-
-      *    The sequence number for each Fault event is currently set to
-           0 on a raise and 1 on a clear.  We could change that so that
-           each Fault event is given a new monotonically increasing
-           sequence number whether it is a raise or a clear if that is
-           helpful (which is reset to 0 if the VM restarts) but they
-           won’t be consecutive.
-
-      *    Normally, a clear is expected for each fault to be sent from a
-           network function. However a few fault notification types will never
-           be re-raised or cleared. In this case, general rules for VES events
-           shall be followed with a new eventId for each event and sequence
-           number set to 0.
-
-   .. image:: Use-Case-2.png
-
-Measurement Expansion Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When expansion fields are used, the goal is to avoid custom development
-by the service provider collecting the fields, since custom development
-adds obvious cost, delay and resource overhead. In the domain of
-measurements, it is expected that a high percentage (perhaps as high as
-90 percent) of use cases for extensible fields can be satisfied by using
-the additionalMeasurements arrayOfNamedHashMap data structure in
-combination with a YAML registration file (provided at design time). The
-YAML registration file conveys meta-information about the processing of
-additionalMeasurements. For more information, please see the VES Event
-Registration specification and in particular the aggregationRole, castTo
-and isHomogeneous keywords.
-
-Syslogs
-~~~~~~~~
-
-Syslog’s can be classified as either Control or Session/Traffic. They
-differ by message content and expected volume:
-
-- Control logs are generally free-form human-readable text used for
-  reporting errors or warnings supporting the operation and
-  troubleshooting of NFs.  The volume of these logs is typically less
-  than 2k per day.
-
-- Session logs use common structured fields to report normal NF
-  processing such as DNS lookups or firewall rules processed.  The
-  volume of these logs is typically greater than 1k per hour (and
-  sometimes as high as 10k per second).
-
-VES supports both classes of syslog, however VES is only recommended for
-control logs or for lower volume session logs, less than 60k per hour.
-High volume session logging should use a file-based transport solution.
-
-Support for Protocols Other Than HTTPS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This API specification describes an HTTPS RESTful interface using the
-JSON content-type.
-
-Alternative API specifications may be provided in future using Google
-Protobuf, websockets, or Apache Avro.
-
-Configuration Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-This section provides network function configuration requirements for
-connectivity to a VES Event Listener via a RESTful API, using a VES JSON event.
-
-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.
-
-* **VES Event Listener IP Addresses or FQDNs resolved via DNS**: Two FQDNs
-  and/or IP Addresses are required. NF shall select one of the 2 FQDNs/IP
-  Addresses for sending events and if the NF is unable to get an
-  acknowledgement within predefined configurable time interval
-  or unable to establish a TCP connection due inability to resolve DNS query or
-  if the VES Event Listener is unresponsive, then the NF shall attempt to use
-  the other FQDN/IP Address to connect to VES Event Listener to deliver the
-  VES Events. The events shall only be sent to one VES Event Listener at a time.
-  Please note: If a FQDN is used, the DNS query would return a single IP
-  address.
-* The active VES Event Listener (either the primary or secondary) will handle
-  all VES events regardless of domain.
-* **VES Credentials**: If the NF is using Basic Authentication, then the NF
-  must support the provisioning of security and authentication parameters
-  (HTTP username and password) in order to be able to authenticate with the
-  VES Event Listener. The Username and Password should be set unique per NF
-  instance and should be configured during the NF deployment through a
-  Controller or other means. The same password must also be configured into VES
-  Event Listener instance for successful handshake.
-* **VES Heartbeat Interval**: This must be a configurable parameter; current
-  default is 60 seconds. Note: the heartbeat interval should be greater than
-  the ack timeout value.
-* **Measurement Interval**: For measurement events, the measurement interval
-  must be configurable and a default of 300 seconds.
-* **ACK Timeout Interval**: Configurable, default 5 seconds.
-
-Event Domain Requirements/Expectations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* **Heartbeat**: Heartbeat events must be sent to VES Event Listener based on
-  configurable parameter.
-* **Faults**: Fault events must be sent to the VES Event Listener as soon as
-  they occur.
-* **Measurements**: All measurement events must be sent at the configured
-  measurementInterval. If the NF provides both application and GuestOS
-  metrics, then they must both use the same measurementInterval.
-* **Syslogs**: Syslog events should be sent to the VES Event Listener as soon as
-  created, unless the NF is in debug mode (verbose logging enabled to get
-  additional data to diagnose a problem), in which case the syslogs must be
-  stored locally in the NF, for later access and possible secure transfer.
-* **Pre-defined Events Formats (Domain: Mobile Flow, TCA, State Chang, etc)**:
-  Other events (State change, TCA, Mobile Flow, etc) may use other pre-defined
-  VES domains from the VES Common Event Format specification based on the role
-  of the NF.
-* **otherFields**: The otherFields Record defines fields for events belonging
-  to the otherFields domain of the Technology Independent domain enumeration.
-  This record provides a mechanism to convey a complex set of fields
-  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.
-
-Use of Collector FQDNs and/or IP Address
-++++++++++++++++++++++++++++++++++++++++
-
-* The NF must support two configurable endpoints for the VES Event Listener.
-  One will be the active, primary event listener endpoint.  The other
-  will be a standby event listener in the event the active endpoint is
-  unavailable.
-* When sending an event (FM, PM, Syslog, HB), the NF shall establish an HTTPS
-  connection to one VES Event Listener FQDN/IP Address (if not already
-  established) and send a VES event to it. Note that connections are not
-  persistent. The events shall only be sent to only one VES Event Listener at a
-  time.
-* The NF must be able to detect that a VES Event Listener endpoint is
-  unavailable, and trigger the fail-over to the backup endpoint. The mechanism
-  for detecting unavailability must be configurable by the Service Operator
-  (e.g. number of attempts, timeout value).
-* If the NF is sending events to the VES Event Listener backup endpoint, then
-  the NF must poll the primary endpoint on a configurable interval to check
-  if the primary endpoint is now available. The NF may use the Heartbeat
-  event or another mechanism to test availability.  If the primary endpoint
-  becomes available, then the NF must fallback to the primary endpoint.
-* A NF must only send a unique event to a single VES Event Listener endpoint
-  at a time.  In other words, the NF must not send a duplicate event to the
-  secondary endpoint unless the delivery to the primary endpoint failed.
-* If both Primary and Secondary endpoints are not available, then the NF shall
-  buffer the events locally. Refer to the Buffering of Events section for full
-  details.
-* If a NF is unable to establish a connection with a VES Event Listener or does
-  not get an acknowledgement within a specified time, then it should log this
-  failure and, optionally, send a fault event indicating
-  connection/acknowledgement failure via the alternate FQDN/IP Address. The
-  intent of this fault is to inform the Service Operator that the VES Event
-  Listener endpoint has become unreachable by the NF.
+VES Event Listener service.
 
+This document describes a RESTful, connectionless, push event listener
+that can receive single events or batches of events in the
+:ref:`ves_common_event_format_7_2`.
 
 Versioning
-~~~~~~~~~~~
+^^^^^^^^^^
 
 Three types of version numbers supported by this specification:
 
@@ -468,8 +113,46 @@ Three types of version numbers supported by this specification:
   to that block (e.g., a field name is added or text changes are made
   to the field descriptions) will increment only the minor number.
 
+Client Requirements
+^^^^^^^^^^^^^^^^^^^
+
+Any NF or client library that is responsible for delivering VES events
+to a VES Event Listener must comply with this specification to ensure events are
+received, accepted, and processed properly.
+
+Because the VES specification relies on clients to push events to the
+VES Event Listener, the client assumes certain responsibilities such as:
+
+- Providing configuration options supporting integration into a
+  Service Provider environment
+- Ensuring reliable delivery of events
+- Customization of default behaviors based on Service Provider needs
+
+While the documentation of these expectations are beyond the Event Listener
+specification, these requirements are documented in the ONAP VNF Requirements
+for :ref:`VES Monitoring Requirements <ves_monitoring_requirements>`.
+
+
+Compatibility with ONAP
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Unless otherwise stated, this version of the Event Listener specification is
+compatible with the release of ONAP the specification is released under.  In
+other words, if the specification is released under the Frankfurt ONAP release,
+then the VES Event Listeners provided by DCAE will also be compatible with
+this specification.
+
+Support for Protocols Other Than HTTPS
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This API specification describes an HTTPS RESTful interface using the
+JSON content-type.
+
+Alternative API specifications may be provided in future using Google
+Protocol Buffers, WebSockets, or Apache Avro.
+
 Field Block Versions
-+++++++++++++++++++++
+^^^^^^^^^^^^^^^^^^^^
 
 A summary of the latest field block version enums as of this version of
 the API spec is provided below:
@@ -508,115 +191,7 @@ the API spec is provided below:
 
 - voiceQualityFieldsVersion: 4.0
 
-Security
-^^^^^^^^
-
-Event sources must identify themselves to the VES Event Listener.
-
-There are 2 methods of HTTP authentication supported: Certificate Authentication
-and Basic Authentication.
-
-Basic authentication is supported in VES Event Listener for backward
-compatibility for existing NFs that are already managed by ONAP. New NFs should
-support Certificate Authentication. Because the security is better, NFs may
-choose to only support Certificate Authentication and not support Basic
-Authentication.
-
-Basic Authentication
-~~~~~~~~~~~~~~~~~~~~
-
-When using Basic Authentication, the event source must not pass credentials on
-the query string.  Credentials must be sent in an Authorization header as
-follows:
-
-1. The username and password are formed into one string as
-   ``username:password``
-2. The resulting string is Base64 encoded to produce the encoded credential.
-3. The encoded credential is communicated in the header after the string
-   ``Authorization: Basic``
-
-Because the credentials are merely encoded but not encrypted, HTTPS (rather
-than HTTP) should be used.  HTTPS will also encrypt and protect event contents.
-
-Sample Request and Response
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sample Request
-++++++++++++++
-
-.. code-block:: http
-
-    POST /eventListener/v7 HTTP/1.1
-    Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-    content-type: application/json
-    content-length: 12345
-    {
-        "event": {
-            "commonEventHeader": {
-                "version": "4.1",
-                "vesEventListenerVersion": "7.1.1",
-                "domain": "heartbeat",
-                "eventName": "Heartbeat_vIsbcMmc",
-                "eventId": "heartbeat0000249",
-                "sequence": 0,
-                "priority": "Normal",
-                "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
-                "reportingEntityName": "ibcx0001vm002oam001",
-                "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
-                "sourceName": "ibcx0001vm002ssc001",
-                "nfVendorName": "Ericsson",
-                "nfNamingCode": "ibcx",
-                "nfcNamingCode": "ssc",
-                "startEpochMicrosec": 1413378172000000,
-                "lastEpochMicrosec": 1413378172000000,
-                "timeZoneOffset": "UTC-05:30"
-            }
-        }
-    }
-
-
-Sample Success Response
-++++++++++++++++++++++++
-
-.. code-block:: http
-
-    HTTPS/1.1 202 Accepted
-    X-MinorVersion: 1
-    X-PatchVersion: 1
-    X-LatestVersion: 7.1
-
-
-Mutual TLS Certificate Authentication
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When using Certificate Authentication, the event source must initialize the
-HTTPS connection with TLS 1.2 or higher and execute mutual authentication
-procedures according to `RFC5246 <https://tools.ietf.org/html/rfc5246#section-7.4.6>`__.
-The event source must authenticate the VES Listener certificate and must
-provide its own X.509v3 end-entity certificate to the VES Listener for
-authentication. The Subject Name in the end-entity certificate must be used
-according to `RFC5280 <https://www.ietf.org/rfc/rfc5280.txt>`__. If a
-certificate is provided by the NF but it is invalid, the VES Listener is
-expected to reject the connection and not fall back to basic authentication.
-
-Resource Structure
-^^^^^^^^^^^^^^^^^^
-
-REST resources are defined with respect to a ServerRoot:
-
-ServerRoot = https://{Domain|IP}:{Port}/{optionalRoutingPath}
-
-The resource structure is provided below::
-
-    {ServerRoot}
-        |
-        |--- /eventListener/v{apiVersion}
-                 |
-                 |--- /eventBatch
-
-**Figure 1**: REST Resource Structure
-
-The {Port} above is typically 8443.
+.. _ves_common_event_format_7_2:
 
 Common Event Format
 ^^^^^^^^^^^^^^^^^^^^
@@ -624,7 +199,7 @@ Common Event Format
 A JSON schema describing the Common Event Format is provided below and
 is reproduced in the tables that follow.
 
-:download:`JSON <CommonEventFormat_30.1.1_ONAP.json>`
+:download:`JSON <CommonEventFormat_30.2_ONAP.json>`
 
 
 Note on optional fields:
@@ -891,6 +466,8 @@ information:
 Common Event Header Data Types
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. _ves_common_event_header_7_2:
+
 Datatype: commonEventHeader
 ++++++++++++++++++++++++++++
 
@@ -921,10 +498,13 @@ to all events:
 |           |          |           | cases, eventId must be the same as the  |
 |           |          |           | initial alarm (along with the same      |
 |           |          |           | startEpochMicrosec but with a different |
-|           |          |           | sequence number). Note: see section 1.3 |
-|           |          |           | for eventId use case examples.          |
+|           |          |           | sequence number).                       |
+|           |          |           | See :ref:`ves_eventid_usecases_7_2` for |
+|           |          |           | additional guidance on eventId usage.   |
 +-----------+----------+-----------+-----------------------------------------+
-| eventName | string   | Yes       |                                         |
+| eventName | string   | Yes       |  See :ref:`ves_eventname_guidelines_7_2`|
+|           |          |           |  for additional information on naming   |
+|           |          |           |  events                                 |
 +-----------+----------+-----------+-----------------------------------------+
 | eventType | string   | No        |                                         |
 +-----------+----------+-----------+-----------------------------------------+
@@ -1053,6 +633,201 @@ Listener service itself as part of an event enrichment process necessary
 for efficient internal processing of events received by the VES Event
 Listener.
 
+
+.. _ves_eventname_guidelines_7_2:
+
+Best Practices for eventName
+++++++++++++++++++++++++++++
+
+To prevent naming collisions, eventNames sent as part of the
+commonEventHeader, should conform to the following naming convention
+designed to summarize the purpose and type of the event, and to ensure
+the uniqueness of the eventName:
+
+    ``{DomainAbbreviation}_{PublisherName}_{Description}``
+
+Each underscore-separated subfield above should start with a capital
+letter and use camel-casing to separate words and acronyms. Acronyms
+should capitalize only the first letter of the acronym. Spaces and
+underscores should not appear within any subfield.
+
+The DomainAbbreviation subfield derives from the ‘domain’ field in the
+commonEventHeader, as specified below:
+
+-  ‘Fault’ for the fault domain
+
+-  ‘Heartbeat’ for the heartbeat domain
+
+-  ‘Measurement’ for the measurement domain
+
+-  ‘MobileFlow’ for the mobileFlow domain
+
+-  ‘Notification’ for the notification domain
+
+-  ‘Other’ for the other domain
+
+-  ‘Perf3gpp’ for the perf3gpp domain
+
+-  ‘PnfReg’ for the pnfRegistration domain
+
+-  ‘SipSignaling’ for the sipSignaling domain
+
+-  ‘StateChange’ for the stateChange domain
+
+-  ‘Syslog’ for the syslog domain
+
+-  ‘Tca’ for the thresholdCrossingAlert domain
+
+-  ‘VoiceQuality’ for the voiceQuality domain
+
+The PublisherName subfield describes the vendor product or application
+publishing the event. This subfield conforms to the following
+conventions:
+
+-   Vendor products are specified as: ``{productName}-{vendorName}``
+
+    For example: ``Visbc-Metaswitch`` or ``Vdbe-Juniper``, where a hyphen is
+    used to separate the ``productName`` and ``vendorName`` subfields. Note that
+    the ``productName`` and ``vendorName`` subfields must not include hyphens
+    themselves.
+
+    Organizing the information in this way will cause an alphabetical
+    listing of eventNames to sort similar network functions together,
+    rather than to sort them by vendor.
+
+    The ``productName`` subfield may describe a NF or a NFC. Where NFC names
+    may be reused across different NF’s, they should be specified as:
+
+    ``{NfName}:{NfcName}``
+
+    where a colon is used to separate the ``NfName`` and ``NfcName`` subfields.
+    Note that the ``NfName`` and ``NfcName`` subfields must not include colons
+    themselves.
+
+    The ``productName`` may also describe other types of vendor modules or
+    components such as a VM, application or hostname. As with NFs and
+    NFCs, parent:child relationships may be communicated using colon as
+    a subfield delimiter.
+
+-   Service providers who adopt the VES Common Event Format for internal
+    use, may provide PublisherName without the vendorName subfield. They
+    would typically identify an application, system, service or
+    microservice publishing the event (e.g., ‘Policy’, ‘So’,
+    ‘MobileCallRecording’ or ‘Dkat’). As with NFs and NFCs, parent:child
+    relationships may be communicated using colon as a subfield delimiter
+    (e.g., ApplicationName:ApplicationComponent).
+
+The final subfield of the eventName name should describe, in a compact
+camel case format the specific information being conveyed by the event.
+In some cases, this final subfield may not be required (e.g., in the
+case of certain heartbeats).
+
+Examples of event names following the naming standards are provided
+below:
+
+- ``Tca_Vdbe-Ericsson_CpuThresholdExceeded``
+
+- ``Heartbeat_Visbc:Mmc-Metaswitch``
+
+- ``Syslog_Vdbe-Ericsson``
+
+- ``Fault_MobileCallRecording_PilotNumberPoolExhaustion``
+
+- ``Other_So:WanBonding_InstantiationPart1Complete``
+
+.. _ves_eventid_usecases_7_2:
+
+EventId Use Cases Examples
+++++++++++++++++++++++++++
+
+``eventId`` Examples:
+
+**NOTE**: Please note, the following are only *examples*, and other formats
+can be used provided they meet the requirement that the ``eventId`` is unique
+for all events or unique fault occurrence.
+
+**Example 1**: assumes a unique key for each domain consisting of domain
+followed by an integer domain<n> or domainId<n>, where <n> is a positive integer,
+e.g. fault000001, heartbeat000001, measurement000005,
+notification3gppPerfFileReady0005
+
+**Example 2**: assumes a unique integer key for all events across all domains
+<n>: 000000001, 00000002, 000000003
+
+Rules:
+
+1. All domains except Fault: each time a subsequent event is sent the
+   integer part of eventId will increment by 1. Repeat of eventId
+   assumes duplicate event. Sequence number is set to 0 for all domains
+   except fault.
+
+2. eventId construction for Fault Events:
+
+   a. Most likely scenario
+
+      *    The sourceName on each Fault event is the NF Instance Name
+           (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
+           identifying this instance of the NF.
+
+      *    The eventId on Fault events is the same every time a given
+           fault is raised (including onset and re-raise)
+
+            1. The startEpochMicrosec value for the Fault event is the
+               timestamp for when the fault onset occurs. Subsequent
+               events for the same fault will keep the same startEpochMicrosec
+               value.
+
+            2. lastEpochMicrosec indicates the current event time. This value
+               will be updated for each subsequent event for a given fault.
+
+            3. The sequence number for each Fault event is set to 1 when the
+               fault is raised and increments each time the same
+               fault event is raised, until a clear is sent.
+
+      *    After the fault is cleared, a new eventId is used.
+
+   .. image:: Use-Case-1.png
+
+   b. **Alternative Scenario**: Network Function When Fault Event Status is Not
+      Maintained.
+
+      *    The sourceName on each Fault event is the NF Instance Name
+           (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
+           identifying this instance of the NF.
+
+      *    The eventId on Fault events is the same every time a given
+           fault is raised or cleared, even if it is re-raised after it
+           had previously cleared.  So, for example, if EMS loses
+           contact with a particular device then a Fault event might be
+           sent for a raise, re-raise (because EMS has re-tried and
+           still can’t contact the device), clear (because EMS has
+           re-tried and it can contact the device) and then raise again
+           (because EMS has lost contact with the device again).  The
+           same eventId is used for all 4 of those Fault events.
+
+      *    The startEpochMicrosec value for each Fault event is the
+           timestamp for when that event is generated, not when the
+           fault first occurred.  So all 4 of the Fault events in the
+           previous bullet point would have a different timestamp.
+
+      *    lastEpochMicrosec indicates the current event time.
+
+      *    The sequence number for each Fault event is currently set to
+           0 on a raise and 1 on a clear.  We could change that so that
+           each Fault event is given a new monotonically increasing
+           sequence number whether it is a raise or a clear if that is
+           helpful (which is reset to 0 if the VM restarts) but they
+           won’t be consecutive.
+
+      *    Normally, a clear is expected for each fault to be sent from a
+           network function. However a few fault notification types will never
+           be re-raised or cleared. In this case, general rules for VES events
+           shall be followed with a new eventId for each event and sequence
+           number set to 0.
+
+   .. image:: Use-Case-2.png
+
+
 Technology Independent Datatypes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1876,7 +1651,7 @@ it consists of the following fields:
 Datatype: measurementFields
 ****************************
 
-The measurementFields datatype consists of the following fields:
+The ``measurementFields`` datatype consists of the following fields:
 
 +-------------+--------------+----------+-------------------------------------+
 | Field       | Type         | Required?| Description                         |
@@ -1977,6 +1752,29 @@ The measurementFields datatype consists of the following fields:
 |             |              |          | measurementInterval                 |
 +-------------+--------------+----------+-------------------------------------+
 
+
+Note on Measurement Expansion Fields
+""""""""""""""""""""""""""""""""""""
+
+The ``measurementFields`` data type provides fields that can be used to
+pass additional data with the event. These fields are listed below and
+referred to as expansion fields:
+
+* ``additionalFields``
+* ``additionalObjects``
+* ``additionalMeasurements``
+
+When expansion fields are used, the goal is to avoid custom development
+by the service provider collecting the fields, since custom development
+adds obvious cost, delay and resource overhead. In the domain of
+measurements, it is expected that a high percentage of use cases for
+extensible fields can be satisfied by using the ``additionalMeasurements``
+``arrayOfNamedHashMap`` data structure in combination with a YAML registration
+file (provided at design time). The YAML registration file conveys
+metadata about the processing of ``additionalMeasurements``. For more
+information, please see the VES Event Registration specification and in
+particular the ``aggregationRole``, ``castTo``, and ``isHomogeneous`` keywords.
+
 Datatype: memoryUsage
 **********************
 
@@ -3450,11 +3248,123 @@ facing voice products; consists of the following fields:
 |              |             |          | to use.                             |
 +--------------+-------------+----------+-------------------------------------+
 
+
+RESTful Web Services Definition
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Security
+~~~~~~~~
+
+Event sources must identify themselves to the VES Event Listener.
+
+There are 2 methods of HTTP authentication supported: Certificate Authentication
+and Basic Authentication.
+
+Basic authentication is supported in VES Event Listener for backward
+compatibility for existing NFs that are already managed by ONAP. New NFs should
+support Certificate Authentication. Because the security is better, NFs may
+choose to only support Certificate Authentication and not support Basic
+Authentication.
+
+Basic Authentication
+++++++++++++++++++++
+
+When using Basic Authentication, the event source must not pass credentials on
+the query string.  Credentials must be sent in an Authorization header as
+follows:
+
+1. The username and password are formed into one string as
+   ``username:password``
+2. The resulting string is Base64 encoded to produce the encoded credential.
+3. The encoded credential is communicated in the header after the string
+   ``Authorization: Basic``
+
+Because the credentials are merely encoded but not encrypted, HTTPS (rather
+than HTTP) should be used.  HTTPS will also encrypt and protect event contents.
+
+Sample Request and Response
++++++++++++++++++++++++++++
+
+Sample Request
+**************
+
+.. code-block:: http
+
+    POST /eventListener/v7 HTTP/1.1
+    Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+    content-type: application/json
+    content-length: 12345
+    {
+        "event": {
+            "commonEventHeader": {
+                "version": "4.1",
+                "vesEventListenerVersion": "7.2",
+                "domain": "heartbeat",
+                "eventName": "Heartbeat_vIsbcMmc",
+                "eventId": "heartbeat0000249",
+                "sequence": 0,
+                "priority": "Normal",
+                "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
+                "reportingEntityName": "ibcx0001vm002oam001",
+                "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
+                "sourceName": "ibcx0001vm002ssc001",
+                "nfVendorName": "Ericsson",
+                "nfNamingCode": "ibcx",
+                "nfcNamingCode": "ssc",
+                "startEpochMicrosec": 1413378172000000,
+                "lastEpochMicrosec": 1413378172000000,
+                "timeZoneOffset": "UTC-05:30"
+            }
+        }
+    }
+
+
+Sample Success Response
+***********************
+
+.. code-block:: http
+
+    HTTPS/1.1 202 Accepted
+    X-MinorVersion: 2
+    X-PatchVersion: 0
+    X-LatestVersion: 7.2
+
+
+Mutual TLS Certificate Authentication
++++++++++++++++++++++++++++++++++++++
+
+When using Certificate Authentication, the event source must initialize the
+HTTPS connection with TLS 1.2 or higher and execute mutual authentication
+procedures according to `RFC5246 <https://tools.ietf.org/html/rfc5246#section-7.4.6>`__.
+The event source must authenticate the VES Listener certificate and must
+provide its own X.509v3 end-entity certificate to the VES Listener for
+authentication. The Subject Name in the end-entity certificate must be used
+according to `RFC5280 <https://www.ietf.org/rfc/rfc5280.txt>`__. If a
+certificate is provided by the NF but it is invalid, the VES Listener is
+expected to reject the connection and not fall back to basic authentication.
+
+Resource Structure
+~~~~~~~~~~~~~~~~~~
+
+REST resources are defined with respect to a ServerRoot:
+
+ServerRoot = https://{Domain|IP}:{Port}/{optionalRoutingPath}
+
+The resource structure is provided below::
+
+    {ServerRoot}
+        |
+        |--- /eventListener/v{apiVersion}
+                 |
+                 |--- /eventBatch
+
+**Figure 1**: REST Resource Structure
+
 Exceptions
-^^^^^^^^^^^
+~~~~~~~~~~
 
 RESTful Web Services Exceptions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++++++++
 
 RESTful services generate and send exceptions to clients in response to
 invocation errors. Exceptions send HTTP status codes (specified later in
@@ -3497,18 +3407,18 @@ exceptions may be defined: service exceptions and policy exceptions.
 +-----------+---------------+-------------+-----------------------------------+
 
 Service Exceptions
-~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++
 
-   When a service is not able to process a request, and retrying the
-   request with the same information will also result in a failure, and
-   the issue is not related to a service policy issue, then the service
-   will issue a fault using the service exception fault message.
-   Examples of service exceptions include invalid input, lack of
-   availability of a required resource or a processing error.
+When a service is not able to process a request, and retrying the
+request with the same information will also result in a failure, and
+the issue is not related to a service policy issue, then the service
+will issue a fault using the service exception fault message.
+Examples of service exceptions include invalid input, lack of
+availability of a required resource or a processing error.
 
-   A service exception uses the letters 'SVC' at the beginning of the
-   message identifier. ‘SVC’ service exceptions used by the VES Event
-   Listener API are defined below.
+A service exception uses the letters 'SVC' at the beginning of the
+message identifier. ‘SVC’ service exceptions used by the VES Event
+Listener API are defined below.
 
 +----------+--------------+-----------------------+----------------+----------+
 | MessageId| Description  | Text                  | Variables      | Parent   |
@@ -3533,25 +3443,25 @@ Service Exceptions
 |          |              |  Error code is %2.    | %2: error code |          |
 +----------+--------------+-----------------------+----------------+----------+
 
-    Table - Service Exceptions
+Table - Service Exceptions
 
 Policy Exceptions
-~~~~~~~~~~~~~~~~~~
++++++++++++++++++
 
-   When a service is not able to complete because the request fails to
-   meet a policy criteria, then the service will issue a fault using the
-   policy exception fault message. To clarify how a policy exception
-   differs from a service exception, consider that all the input to an
-   operation may be valid as meeting the required input for the
-   operation (thus no service exception), but using that input in the
-   execution of the service may result in conditions that require the
-   service not to complete. Examples of policy exceptions include
-   privacy violations, requests not permitted under a governing service
-   agreement or input content not acceptable to the service provider.
-
-   A Policy Exception uses the letters 'POL' at the beginning of the
-   message identifier. ‘POL’ policy exceptions used by the VES Event
-   Listener API are defined below.
+When a service is not able to complete because the request fails to
+meet a policy criteria, then the service will issue a fault using the
+policy exception fault message. To clarify how a policy exception
+differs from a service exception, consider that all the input to an
+operation may be valid as meeting the required input for the
+operation (thus no service exception), but using that input in the
+execution of the service may result in conditions that require the
+service not to complete. Examples of policy exceptions include
+privacy violations, requests not permitted under a governing service
+agreement or input content not acceptable to the service provider.
+
+A Policy Exception uses the letters 'POL' at the beginning of the
+message identifier. ‘POL’ policy exceptions used by the VES Event
+Listener API are defined below.
 
 +----------+---------------+-----------------------+---------------+----------+
 | MessageId| Description   |Text                   | Variables     | Parent   |
@@ -3580,10 +3490,7 @@ Policy Exceptions
 |          |               | limit                 |               |          |
 +----------+---------------+-----------------------+---------------+----------+
 
-    Table - Policy Exceptions
-
-RESTful Web Services Definition
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Table - Policy Exceptions
 
 REST Operation Overview
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -3617,11 +3524,11 @@ The Event Listener shall provide the following HTTP headers in response
 to all requests. Additionally, clients may populate these headers on
 requests to indicate the specific version they are interested in.
 
--  X-MinorVersion: 1
+-  X-MinorVersion: 2
 
--  X-PatchVersion: 1
+-  X-PatchVersion: 0
 
--  X-LatestVersion: 7.1
+-  X-LatestVersion: 7.2
 
 If a client requests major version 7 (per the REST resource URL) and
 does not specify the above headers, then they will be provided with the
@@ -3631,63 +3538,14 @@ the X-MinorVersion header with their request. For example, if they
 request major version 7 with X-MinorVersion: 1, they will get the latest
 patch version of 7.1, which is 7.1.1.
 
-Buffering of Events
-+++++++++++++++++++
-
-``{ServerRoot}`` is defined in section 3 of this document, which defines the
-REST resource URL.  One or more FQDNs may be provisioned in an event source
-when it is instantiated or updated.  If an event source is unable to reach any
-of the provisioned FQDNs, it should buffer the event data specified below, up
-to a maximum of 1 hour, and re-transmit them once a connection has been
-established.
-
-The following events should be buffered:
-
-* Faults with eventSeverity of ``MINOR``, ``MAJOR``, ``NORMAL``, or ``CRITICAL``
-  with following expected behavior:
-
-    * NF keeps a First-In-First-Out buffer.
-    * Until the collectors are working again, it is desired that the NF sends
-      the final state events only, and not intermediate ones. However, it is
-      acceptable to buffer all events and send them over to the collector in
-      the same order in which they were generated/received.
-
-* When one VES Event Listener connectivity is re-established, NF should first
-  send the buffered events and then start sending the new events.
-
-    * Syslog with syslogSev of ``Emergency``, ``Alert``, ``Critical``,
-      ``Error``, or ``Warning``
-
-* All measurements events
-
-publishEventBatch Requirements
-******************************
-
-Buffered events can be sent in batch using ``publishEventBatch``. However, a
-NF vendor must only include multiple events for the same domain in the
-``publishEventBatch``. The ``publishEventBatch`` event must also conform to
-event size limits.
-
-``publishEventBatch`` events are handled similarly to a single event. The
-acknowledgement from the VES Event Listener is for the ``publishEventBatch`` and
-not individual events within the ``publishEventBatch``.
-
-Debug Mode
-**********
-
-NFs acting as event sources should not send syslog events to the
-VES Event Listener during debug mode, but should store syslog events locally
-for access, and possible FTP transfer, via the NF console (e.g., command line
-interface).
-
-.. _msg-size:
+.. _ves_msg_size_7_2:
 
 Message Size
 ++++++++++++
 
 The maximum allowed message size is 2 megabytes of uncompressed text.
-However,messages of this size have been known to cause performance and data
-loss. It is strongly recommended,that messages not exceed 1 megabyte.
+However, messages of this size have been known to cause performance and data
+loss. It is strongly recommended, that messages not exceed 1 megabyte.
 In a future version of the specification, a 1 megabyte limit will become
 a mandatory requirement.
 
@@ -3753,7 +3611,8 @@ case-insensitive):
 |               |          |          | message shall be returned.            |
 +---------------+----------+----------+---------------------------------------+
 | Content-length| integer  | No       | Note that content length is limited to|
-|               |          |          | 2 Megabyte (see :ref:`msg-size`)      |
+|               |          |          | 2 Megabyte                            |
+|               |          |          | (see :ref:`ves_msg_size_7_2`)         |
 +---------------+----------+----------+---------------------------------------+
 | Content-type  | string   | Yes      | Must be set to one of the following   |
 |               |          |          | values:                               |
@@ -3868,7 +3727,7 @@ Sample Request
         "event": {
             "commonEventHeader": {
                 "version": "4.1",
-                "vesEventListenerVersion": "7.1.1",
+                "vesEventListenerVersion": "7.2",
                 "domain": "fault",
                 "eventName": "Fault_Vscf:Acs-Ericcson_PilotNumberPoolExhaustion",
                 "eventId": "fault0000245",
@@ -3907,9 +3766,9 @@ Sample Success Response
 .. code-block:: http
 
     HTTPS/1.1 202 Accepted
-    X-MinorVersion: 1
-    X-PatchVersion: 1
-    X-LatestVersion: 7.1.1
+    X-MinorVersion: 2
+    X-PatchVersion: 0
+    X-LatestVersion: 7.2
 
 Sample Error Responses
 ************************
@@ -3925,7 +3784,7 @@ Sample Policy Exception
     Date: Thu, 04 Jun 2009 02:51:59 GMT
     X-MinorVersion: 1
     X-PatchVersion: 1
-    X-LatestVersion: 7.1.1
+    X-LatestVersion: 7.2
 
     {
       "requestError": {
@@ -3948,7 +3807,7 @@ Sample Service Exception
     Date: Thu, 04 Jun 2009 02:51:59 GMT
     X-MinorVersion: 1
     X-PatchVersion: 1
-    X-LatestVersion: 7.1.1
+    X-LatestVersion: 7.2
 
     {
       "requestError": {
@@ -3981,6 +3840,10 @@ listener.
 - Provides HTTP response codes as well as Service and Policy error
   messages
 
+``publishEventBatch`` events are handled similarly to a single event. The
+acknowledgement from the VES Event Listener is for the ``publishEventBatch`` and
+not individual events within the ``publishEventBatch``.
+
 Call Flow
 +++++++++++
 
@@ -4025,7 +3888,8 @@ case-insensitive):
 |               |          |          | returned.                             |
 +---------------+----------+----------+---------------------------------------+
 | Content-length| integer  | No       | Note that content length is limited to|
-|               |          |          | 2 megabyte (see :ref:`msg-size`).     |
+|               |          |          | 2 megabyte                            |
+|               |          |          | (see :ref:`ves_msg_size_7_2`).        |
 +---------------+----------+----------+---------------------------------------+
 | Content-type  | string   | Yes      | Must be set to one of the following   |
 |               |          |          | values:                               |
@@ -4049,7 +3913,9 @@ Body Fields:
 | **Parameter**| **Data Type**| **Required?**| **Brief description**         |
 +--------------+--------------+--------------+-------------------------------+
 | eventList    | eventList    | Yes          | Array of events conforming to |
-|              |              |              | the common event format.      |
+|              |              |              | the common event format. All  |
+|              |              |              | events must belong to a       |
+|              |              |              | single domain.                |
 +--------------+--------------+--------------+-------------------------------+
 
 Output Parameters
@@ -4141,7 +4007,7 @@ Sample Request
           {
              "commonEventHeader": {
                 "version": "4.1",
-                "vesEventListenerVersion": "7.1.1",
+                "vesEventListenerVersion": "7.2",
                 "domain": "fault",
                 "eventName": "Fault_Vscf:Acs-Ericcson_PilotNumberPoolExhaustion",
                 "eventId": "fault0000250",
@@ -4173,7 +4039,7 @@ Sample Request
           {
              "commonEventHeader": {
                 "version": "4.1",
-                "vesEventListenerVersion": "7.1.1",
+                "vesEventListenerVersion": "7.2",
                 "domain": "fault",
                 "eventName": " Fault_Vscf:Acs-Ericcson_RecordingServerUnreachable",
                 "eventId": "fault0000251",
@@ -4208,9 +4074,9 @@ Sample Success Response
 .. code-block:: http
 
     HTTPS/1.1 202 Accepted
-    X-MinorVersion: 1
-    X-PatchVersion: 1
-    X-LatestVersion: 7.1.1
+    X-MinorVersion: 2
+    X-PatchVersion: 0
+    X-LatestVersion: 7.2
 
 Sample Error Responses
 ************************
@@ -4224,9 +4090,9 @@ Sample Policy Exception
     content-type: application/json
     content-length: 12345
     Date: Thu, 04 Jun 2009 02:51:59 GMT
-    X-MinorVersion: 1
-    X-PatchVersion: 1
-    X-LatestVersion: 7.1.1
+    X-MinorVersion: 2
+    X-PatchVersion: 0
+    X-LatestVersion: 7.2
 
     {
       "requestError": {
@@ -4248,9 +4114,9 @@ Sample Service Exception
     content-type: application/json
     content-length: 12345
     Date: Thu, 04 Jun 2009 02:51:59 GMT
-    X-MinorVersion: 1
-    X-PatchVersion: 1
-    X-LatestVersion: 7.1.1
+    X-MinorVersion: 2
+    X-PatchVersion: 0
+    X-LatestVersion: 7.2
 
     {
       "requestError": {
@@ -4281,9 +4147,6 @@ a trap name.
 **APPC (formerly APP-C)**. Application Controller. Handles the life
 cycle management of Virtual Network Functions (VNFs).
 
-**ASDC**. AT&T Service Design and Creation Platform: the original name
-for the SDC. Replaced by SDC.
-
 **Common Event Format**. A JSON schema describing events sent to the VES
 Event Listener.
 
@@ -4349,10 +4212,6 @@ all name-value pair structures were changed to hash maps (i.e., {‘name’:
 ‘keyName’, ‘value’: ‘keyValue’} was replaced with {‘keyName’:
 ‘keyValue’}).
 
-**ICE**. Incubation and Certification Environment. Facilitates vendors
-and third-party in developing virtual network functions using ONAP and a
-network cloud.
-
 **IPMI**. The `Intelligent Platform Management
 Interface <https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface>`__.
 
@@ -6181,7 +6040,7 @@ Contents.
 |           |         | -  Changed the location of the doc to VNF             |
 |           |         |    Requirements and changed the formatting            |
 +-----------+---------+-------------------------------------------------------+
-| 1/28/202  | v7.1.1  | -  Changed event sizes from 2Mb to 1Mb                |
+| 1/28/2020 | v7.1.1  | -  Changed event sizes from 2Mb to 1Mb                |
 |           |         | -  Configuration Requirement comments addressed       |
 |           |         | -  Changed DCAE Collector to VES Event Listener       |
 |           |         | -  Replaced VNF with NF where appropriate             |
@@ -6215,6 +6074,10 @@ Contents.
 |           |         | - Relaxed various requirements related to camel       |
 |           |         |   casing of values from 'must' to 'should'            |
 +-----------+---------+-------------------------------------------------------+
+| 5/27/2020 | v7.2    | -  Re-organized sections to flow more logically       |
+|           |         | -  Moved NF requirements to VNF Requirements          |
+|           |         | -  Changed DCAE Collector to VES Event Listener       |
++-----------+---------+-------------------------------------------------------+
 
 .. _time_zone_abbreviations: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
 .. _Common_definitions: http://technical.openmobilealliance.org/Technical/release_program/docs/REST_NetAPI_Common/V1_0-20120417-C/OMA-TS-REST_NetAPI_Common-V1_0-20120417-C.pdf
diff --git a/docs/release-notes.rst b/docs/release-notes.rst
index f63592c..5a5b703 100644
--- a/docs/release-notes.rst
+++ b/docs/release-notes.rst
@@ -33,7 +33,7 @@ changes can be found below.
     - 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>`
+    - Added :ref:`VES Event Listener Specification 5.4.1 <ves_event_listener_5_4_1>`
       as ONAP still supports this version
     - Updated Ansible Requirements in :ref:`vnf_configuration_management`
 
@@ -128,7 +128,7 @@ changes can be found below.
     - Added Release notes to higher level
     - Added CICD build to generate requirements and create traceability matrix
     - Added Traceability matrix with dynamic links
-    - Moved VES spec 
+    - Moved VES spec
     - Created RST Requirement generator in wiki
 
 **Bug Fixes**