Note there there is also a very simple TLV definition in appendix A and
amendment to the IANA section on object types:

A.3.8.  Hello-ID

   Type:  Hello-ID

   Length:  Fixed (1 32-bit word)

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Hello-ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents are implementation defined.  See Section 5.2.2 for
   further discussion.

After some discussion on the mailing list, the text updates below are updated as
follows:

In 5.1:

   MA-Hello: This message MUST be sent only in C-mode.  It contains the
   common header, with a NSLPID of zero, and a message identifier, the
   Hello-ID.  If sent with R=0 and null Hello-ID, it indicates that a
   node wishes to keep a messaging association open.  A node MAY also
   invoke a diagnostic request/response exchange by setting R=1and
   providing a non-zero Hello-ID; if this case, the peer MUST send
   another MA-Hello back along the messaging association echoing the
   same Hello-ID and with R=0.  Use of this diagnostic is entirely at
   the discretion of the initiating node.

In 5.2.2:

   Hello-ID:  The Hello-ID is a 32-bit quantity that is used to
      correlate messages in an MA-Hello request/response exchange.  A
      non-zero value MUST be used in a request (messages sent with R=1)
      and the same value must be returned in the response (which has
      R=0).  The value zero MUST be used for all other messages; if a
      message is received with R=1 and Hello-ID=0, an "Object Value
      Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not
      Supported") MUST be returned and the message dropped.  Nodes MAY
      use any algorithm to generate the Hello-ID; a suitable approach is
      a local sequence number with a random starting point.

and in 6.4:

   At any time in the Connected or Idle states, a node MAY test the
   connectivity to its peer and the liveness of the GIST instance at
   that peer by sending a MA-Hello request with R=1.  Failure to receive
   a response with a matching Hello-ID within a timeout MAY be taken as
   a reason to trigger er_MAFailure.  Initiation of such a test and the
   timeout setting are left to the discretion of the implementaion.
   Note that er_MAFailure may also be signalled by indications from the
   underlying messaging association protocols.

The syntax of the MA-Hello message is extended as follows (5.1):

   MA-Hello: This message MUST be sent only in C-mode to indicate that a
   node wishes to keep a messaging association open.  It contains the
   common header, with a NSLPID of zero, and a message identifier, the
   Hello-ID.  The R flag MAY be set (R=1); if so, the peer MUST send
   another MA-Hello back along the messaging association echoing the
   same Hello-ID and with R=0.  This allows a node to test the liveness
   of the peer.

       MA-Hello = Common-Header
                  Hello-ID

The Hello-ID itself is described in section 5.2.2:

   Hello-ID:  The Hello-ID is a 32-bit quantity that is used to
      correlate messages in an MA-Hello request/response exchange.  A
      non-zero value MUST be used in a request (messages sent with R=1)
      and the same value must be returned in the response (which has
      R=0).  The value zero MUST be used for all other messages.  Nodes
      MAY use any algorithm to generate the Hello-ID; a suitable
      approach is a local sequence number with a random starting point.

The request/response exchange is essentially a diagnostic, which a node may
invoke whenever it wants (including never). It is up to the node to decide when
to invoke it and how, and what to do with the result. This is indicated in the
text of section 6.4:

   At any time in the Connected or Idle states, a node MAY test the
   connectivity to its peer and the liveness of the GIST instance at
   that peer by sending a MA-Hello request (with R=1).  Failure to
   receive a response (detected by matching the Hello-ID in the message)
   MAY be taken as a reason to trigger er_MAFailure.  Note that
   er_MAFailure may also be signalled by indications from the underlying
   messaging association protocols.

Proposed solution:

- add an ID field to the Hello message to aid this request/response processing

- indicate that failure to receive a response can be taken as evidence of an
er_MAFailure event

As part of this, need to specify that a response MUST NOT have R=1.

At the moment, there is no way to correlate MA-Hello responses with requests.
Nor is there any defined action to take when a response does not arrive.