A VES event could fail delivery for a variety of reasons. Today, the document assumes that reason is related to connectivity and requires buffering and resending. Better definition is required of how to handle the various scenarios that could occur beyond connectivity failure.

This was attempted, but the language could not be aligned upon in time for the Frankfurt/7.1.1 update.

Prior language:

Need better definition of what the NF should do based on the various types of failure (connectivity, schema violation, credentials, etc.)?
Original text:

• *Event Handling Requirements/Expectations*

• Every Event is acknowledged by the VES Event Listener.
• For 2xx (success) acknowledgement the NF must not resend the event to
  VES Event Listener.
• For all other 4xx/5xx acknowledgements (failure), the NF must create an
  internal flag/notification to ensure issue is corrected (since these
  events have failed and they need to fix by Vendor), so the event can be
  successfully sent to VES Event Collector for life cycle maintenance of
  the NF.