> It is also possible to become out of sync with this if the sender of 
> requests do what is not recommend and aborts transmission
> 16 times. Then the sender and receiver will have there sequence number 
> windows out of sync. I don't think there is a significant issue here. 
> But a warning about this might with the SHOULD NOT abort sentence may 
> provide good motivation.

OK, I would propose adding the following sentence to the end of the Paragraph, 
which I believe is sufficient with the SHOULD NOT statement:

<new sentence>
   Note that there is a high chance that both the WTP and the AC's
   sequence numbers will become out of sync.
</new sentence>

> > Section 4.5.3:
> > 
> >    If an older Request message (with smaller
> >    Sequence Number modulo 32) is received, it MUST be ignored.
> >   
> >    Smaller is not super obvious here. I would interpret it as
> > (Last_nr-15)%32 to (Last_nr-1)%32. Saying something like that might 
> > be clearer on which sequence numbers that are okay.
> 


Got it. How about the following:

<modified text>
   Implementations MUST keep track of the Sequence Number of the last
   received Request message, and MUST cache the corresponding Response
   message.  If a retransmission with the same Sequence Number is
   received, the cached Response message MUST be retransmitted without
   re-processing the Request.  If an older Request message is received,
   meaning one where the sequence number is smaller, it MUST be ignored.
   A newer Request message, meaning one whose sequence number is larger,
   is processed as usual.

   Note: A sequence number is considered "smaller" when s1 is smaller
   than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2
   and (s1-s2)>128)
</modified text>