Text subsequently revised to allow for the possibility of directly incorporating
a security capability in D-mode as follows:

   D-mode uses UDP, as a suitable NAT-friendly encapsulation which does
   not require per-message shared state to be maintained between the
   peers.  It is currently an assumption that long-term evolution of
   GIST will preserve the simplicity of the current D-mode design.
   Extensions to the security or transport capabilities of D-mode can be
   provided equivalently by selecting a different protocol stack under
   the GIST messaging layer, which would then become another option
   within the overall C-mode framework.  This includes both the case of
   using existing protocols, and specific development of a message
   exchange and payload encapsulation to support GIST requirements.
   Alternatively, if any necessary parameters (e.g. a shared secret for
   use in integrity or confidentiality protection) can be negotiated
   out-of-band, then the additional functions can be added directly to
   D-mode by adding an optional object to the message (see
   Appendix A.2.1).  Note that downgrade attacks on such approach would
   need to be prevented by policy at the destination node, similar to
   the situation discussed in Section 8.6.

Revised text in 3.2:

   D-mode uses UDP, as this is the only encapsulation which does not
   require per-message shared state to be maintained between the peers.
   It is an assumption that long-term evolution of GIST will preserve
   the simplicity of the current D-mode design.  Any extension to the
   security or transport capabilities of D-mode can be considered as the
   selection of a different protocol stack under the GIST messaging
   layer (either using existing protocols or a some specification
   developed specifically to support GIST).  This would then become
   another option within the overall C-mode framework.

The question of extensibility of D-mode to more advanced functionality has been
raised multiple times. Latest from Lars Eggert:

> >Section 5.7.1., paragraph 1:
> >>    A key attribute of GIST is that it is flexible in its
> >ability to use
> >>    existing transport and security protocols.  Different transport
> >>    protocols may have performance attributes appropriate
> to different
> >>    environments; different security protocols may fit
> >appropriately with
> >>    different authentication infrastructures.
> >
> >  All protocols defined in the subsections of this section are for  
> > C-mode - what about D-mode?

D mode only uses UDP+nothing. No flexibility is intended; if 
you wanted to negotiate another protocol, one would do so with the C-mode
mechanisms. It is probably worth saying this explicitly.