The agreement was to keep the Fragment ID field untouched to ensure we 
maintain backward compatibility, but include text to point out the possible 
issues. The resulting text is:

<proposed text>
3.4.  Fragmentation/Reassembly
[...]
   It is important to note that the fragmentation mechanism employed by
   CAPWAP has known limitations and deficiencies, which are similar to
   those described in [RFC4963].  The limited size of the Fragment ID
   field (see Section 4.3 can cause wrapping of the field, and hence
   cause fragments from different datagrams to be incorrectly spliced
   together (known as "mis-associated").  For example, a 100Mpbs link
   with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause
   the Fragment ID field wrap in 8 seconds.  Consequently, CAPWAP
   implementors are warned to properly size their buffers for reassembly
   purposes based on the expected wireless technology throughput.

   CAPWAP implementations SHOULD perform MTU Discovery (see
   Section 3.5), which can avoid the need for fragmentation.  At the
   time of writing of this specification, most enterprise switching and
   routing infrastructure were capable of supporting "mini-jumbo" frames
   (1800 bytes), which eliminates the need for fragmentation (assuming
   the station's MTU is 1500 bytes).  The need for fragmentation
   typically continues to exist when the WTP communicates with the AC
   over a Wide Area Network (WAN).  Therefore, future versions of the
   CAPWAP protocol SHOULD either consider increasing the size of the
   Fragment ID field, or provide alternatives extensions.

12.1.6.  CAPWAP Fragmentation

   RFC 4963 [RFC4963] describes a possible security vulnerability where
   a malicious entity can "corrupt" a flow by injecting fragments.  By
   sending "high" fragments (those with offset greater than zero) with a
   forged source address, the attacker can deliberately cause
   corruption.  The use of DTLS on the CAPWAP Data channel can be used
   to avoid this possible vulnerability.
</proposed text>

> I think the text does not make it clear if the fragment ID space is per
> direction and AC/WTP pair. I am also worried about the size of this
> field. It seems that if a large quantity of the packets needs
> fragmentation then this field will wrap within a segments lifetime
> resulting in the same type of missassociation issues that has been
> identified with the IP-ID field and fragmentation.
> 
> A simple example shows that if one sends predominately packets that just
> gets fragmented and assume a IP uplink MTU of 1500 then wirless payloads
> of 1450 bytes will be fragmented. If the source sends only this size
> packets not uncommon for long lived TCP transfers then this field will
> wrap every second at data rates below 1 Gbit. At 100 mbit you will wrap
> in around 8 seconds.