The hop count processing rules have been clarified in multiple places, to follow
the rules on validation and decrementing through the processing chain; some text
has just been moved, but there are also protocol differences.

In 4.3.1 (receive):

   Immediately after reception, the GIST hop count is checked.  Any
   message with a GIST hop count of zero MUST be rejected with a "Hop
   Limit Exceeded" error message (Appendix A.4.4.2), following which the
   GIST hop count MUST be decremented by one.

In 4.3.2 (process):

   In the case of a Query, there is an interaction with the signalling
   application to determine which of two courses to follow.  The first
   option (peering) MUST be chosen if the node is the endpoint of the
   flow being signalled for, or if the GIST hop count has reached zero.

(and some old text deleted)

In 4.3.3 (transmission):

   Signalling applications may specify a value to be used for the GIST
   hop count; otherwise, GIST selects a value itself.  GIST MUST reject
   messages for which the signalling application has specified a value
   of zero.  Although the GIST hop count is only intended to control
   message looping at the GIST level, the GIST API (Appendix B) provides
   the incoming hop count to the NSLPs, which can preserve it on
   outgoing messages as they are forwarded further along the path.  This
   provides a lightweight loop-control mechanism for NSLPs which do not
   define anything more sophisticated.  Note that the count will be
   decremented on forwarding through every GIST-aware node.  Initial
   values for the GIST hop count are an implementation matter; one
   suitable approach is to use the same algorithm as for IP TTL setting
   [1].

In 4.3.4 (forward):

some text deleted.

In other sections, some minor changes to fix semantics about what the GHC means
and how it is interpreted.