Original text:
11.  The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,

Reviewer comments:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Revised text:
11. <ins> The offset of an upload resource is the number of bytes that have been appended to the upload resource.  Appended data cannot be removed from an upload and, therefore, the upload offset MUST NOT decrease.  A server MUST NOT generate responses containing an "Upload-Offset" header field with a value that is smaller than was included in previous responses for the same upload resource.  This includes informational and final responses for upload creation (upload-creation), upload appending (upload-appending), and offset retrieval (offset-retrieving). If a server loses data that has been appended to an upload, it MUST consider the upload resource invalid and reject further use of the upload resource.  The "Upload-Offset" header field in responses serves as an acknowledgement of the append operation and as a guarantee that no retransmission of the data will be necessary. Client can use this guarantee to free resources associated to already uploaded data while the upload is still ongoing. 12. </ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,