Update text in 4.3.3 to include first-hop MTU in the tests:

   o  message size: a message whose size (including the GIST header,
      GIST objects and any NSLP payload, and an allowance for the IP and
      transport layer encapsulation required by D-mode) exceeds a
      fragmentation-related threshold MUST be sent over C-mode, using a
      messaging association that supports fragmentation and reassembly
      internally.  The allowance for IP and transport layer
      encapsulation is 64 bytes.  The message size MUST NOT exceed the
      least of the following three quantities: the Path MTU to the next
      peer (if known), the first-hop MTU, and 576 bytes.  The same limit
      applies to IPv4 and IPv6.

re-assign to v12

Updated text:

   The main decision is whether the message must be sent in C-mode or
   D-mode.  Reasons for using C-mode are:

[snip]

   o  message size: a message whose size (including the GIST header,
      GIST objects and any NSLP payload, and an allowance for the IP and
      transport layer encapsulation required by D-mode) exceeds a
      fragmentation-related threshold MUST be sent over C-mode, using a
      messaging association that supports fragmentation and reassembly
      internally.  The allowance for IP and transport layer
      encapsulation is 64 bytes.  If the Path MTU to the next peer is
      known, the message size MUST NOT exceed that Path MTU; if the Path
      MTU is not known, the message size MUST NOT exceed 576 bytes.  The
      same limit applies to IPv4 and IPv6.

[raised by Roland Bless on the mailing list]

Add a note that the same limit applies to IPv4 and IPv6. [If you are in a
homogeneous IPv6 network, you know the larger PMTU of 1280 bytes; if you do not,
using 1280 is dangerous because transition e.g. over v4 tunnels might still
cause fragementation which is not undone at the tunnel exit.]

[NB 'here' in the note below = '4.3.3']

Add a note here that GIST does not perform the fragmentation itself, but relies
on the underlying transport protocol to do so.

New text in 4.3.3:

   The main decision is whether the message must be sent in C-mode or
   D-mode.  Reasons for using C-mode are:

[snip]

   o  message size: a message whose size (including the GIST header,
      GIST objects and any NSLP payload, and an allowance for the IP and
      transport layer encapsulation required by D-mode) exceeds a
      fragmentation-related threshold MUST be sent over C-mode.  The
      allowance for IP and transport layer encapsulation is 64 bytes.
      If the Path MTU to the next peer is known, the message size MUST
      NOT exceed that Path MTU; if the Path MTU is not known, the
      message size MUST NOT exceed 576 bytes.


Other minor changes also made as described below.

A related comment on section 5.4:

> >>    It can be seen that all of these transport protocol
> options can be
> >>    supported by the basic GIST message format already
> >presented.  GIST
> >>    messages requiring fragmentation must be carried using
> a reliable
> >>    transport protocol, TCP or SCTP.  This specification
> >defines only the
> >>    use of TCP, but other possibilities could be included without
> >>    additional work on message formatting.


> >
> >  Also, s/must/MUST/.

OK.

In the end, the best approach is to update the text in 4.3.3 (which describes
mode selection on the transmit side) to prescribe that C mode must be used for
large messages and to define what 'large' means. The text in section 5.8.1.2/3
and 5.8.2 then just needs tidying up.

DISCUSS comments on MTU setting from Lars Eggert:

> >  DISCUSS: For anything sent over UDP, i.e., D- and Q-mode,
> it must be
> >  made clear that messages must have payloads smaller than the PMTU
> >  (minus headers) or 512 bytes if the PMTU is unknown, to avoid
> >  fragmentation. (Section 5.4.1 and 5.8.1.2 do so, but other
> >sections do
> >  not.) Because some messages MUST be transmitted in D- or 
> Q-mode, are
> >  such messages guaranteed to be less than this limit in all cases?

on the MTU front: fair point. Probably the note in 5.8.1.2 should really be in
5.3 (where it applies to all cases of D mode). See below on actual message sizes.

and later:

> >>>  Additionally, because some
> >>>  messages MUST be carried in D- or Q-mode - is it guaranteed  that 
> >>> their payloads are always less than 512 bytes?
> >
> > In theory no, because things like the cookies and peer identity are 
> > variable length strings. But I just did a quick count, and with a 
> > worst case for the other fields (e.g. using v6 addresses, and a 
> > couple of possible stack proposals) adds up to about 150 bytes. So I 
> > think we are safe.
> 
> Since you were going to add MTU-related text anyway, it may be good
> to point out that if payloads grow past the MTU, C-mode SHOULD be  
> used if possible.

OK.