... and back to v11 (wrong issue!)

re-assign to v12

New text for 4.3.3:

   In principle, as well as determining that some messaging association
   must be used, GIST MAY select between a set of alternatives, e.g. for
   load sharing or because different messaging associations provide
   different transport or security attributes.  For the case of reliable
   delivery, GIST MUST NOT distribute messages for the same session over
   multiple messaging associations in parallel, but MUST use a single
   association at any given time.  The case of moving over to a new
   association is covered in Section 4.4.3.

Revised text for 4.4.3:

                                           ...To
   maintain the transport semantics described in Section 4.1, GIST MUST
   close transport connections carrying reliable messages gracefully or
   report an error condition, and MUST NOT open a new association to be
   used for given session and peer while messages on a previous
   association could still be outstanding.  GIST MAY use an MA-Hello
   request/response exchange on an existing association to verify that
   messages sent on it have reached the peer.

A related comment on in-order delivery:

> >Section 4.1.2., paragraph 3:
> >>       TCP is considered in Section 5.7.2.  Messages with the
> >same SID to
> >>       the same peer MUST be delivered in order.
> >
> >  ...unless they are not delivered at all.

Sections 3.5 and 4.1.2 state that in-order delivery is required for reliable
messages with the same SID. 

Section 4.4.3 already handles the case that GIST stops using one MA and starts
using another, but can be extended to include the possibility of flushing the MA
with a Hello as well as gracefully closing the MA.

Section 4.3.3 should be extended to note that messages should not be distributed
in parallel over multiple MAs.