Modified some of the text in Section 1 about the meaning of the term
"path-coupled", and also noted in Section 3.3 the future flexibility about
defining alternative probe methods. 

Revised text in 3.3:

   o  A specification of the IP-level encapsulation of the messages
      which probe the network to discover the adjacent peers.  A
      downstream encapsulation must be defined; an upstream
      encapsulation is optional.  For the path-coupled MRM, this
      information is given inSection 5.8.1.2 and Section 5.8.1.3.
      Current MRMs rely on the interception of probe messages in the
      data plane, but other mechanisms are also possible within the
      overall GIST design and would be appropriate for other types of
      signalling pattern.

And a more extended followup discussion:

>> ---- 
>> Non-path-coupled signaling - Section 1 para 2
>> "concentrates mainly on path-coupled signaling". You raised
>> my hopes :-) But I think the document concentrates entirely
>> on path-coupled signaling.
>> We could note that there are only a few places where this
>> is actually enforced. For example, the Query, Response and
>> Confirm could easily be allowed to use an existing MA
>> (possibly set up on demand by a D-mode Query) and so out-
>> of-band signaling would be supported.
>
> I would be interested to know what your hopes actually were ;-)

I am a bit obsessive about out-of-band signaling for architectural and
operational reasons. And, of course, it is hard to use in-band signaling
when the data medium is not aware of packet boundaries.

> However: the phrase about 'concentrating mainly on path-coupled'
> is actually a reference to the fact that there can be multiple
> MRMs, one of which is the path-coupled one, but that others
> exist.

That's fine. Probably enough to say that rather than the quoted text. In
fact, the I-D discusses two MRMs both of which are path coupled and in-band.

> Technically, it isn't possible to send the Query over an MA.

Hmmm?
If I know (for a flow) what my next GIST-capable node is, and if I know that
I have an MA with that node, why could I not send my Query over the MA?

> There is an individual submission (which you [Adrian] have
> also looked at) which considers out-of-band signalling, but
> we see that as a deployment mode for standard GIST, not a
> GIST extension.

I think out-of-band GIST will be just fine.
A lot hangs on what you mean by "path-coupled".
- Where it means that the GIST-capable nodes allow signaling
   protocols to control resources of nodes that lie on the data
   path, I have no objection.
- Where it means that the GIST-capable nodes MUST themselves
   lie on the data path, I am a little worried (but only for the future
   usefulness of GIST). Why is a protocol like GSMP not suitable
   for controlling the data plane entity?
- Where it means that the GIST-capable nodes MUST be
   discovered through the data plane then I am a bit disappointed
   (but again, only for the future usefulness of GIST). This seems
   to be stuck in the mode of thought that was prevalent 10+ years
   ago when RSVP was documented.

BTW. Probably all that you need to have to support out-of-band GIST is to
allow the Query to be targeted with the Router Alert option NOT set.

From Adrian Farrel:

Non-path-coupled signaling - Section 1 para 2 
"concentrates mainly on path-coupled signaling". You raised 
my hopes :-) But I think the document concentrates entirely 
on path-coupled signaling.