The maximum amount of data allowed is determined by the maximum
packet size for the channel, and the current window size, whichever
is smaller. The window size is decremented by the amount of data
sent. Both parties MAY ignore all extra data sent after the allowed
window is empty.

It should say:

The maximum amount of data allowed is determined by the maximum
packet size for the channel, and the current window size, whichever
is smaller. The window size is decremented by the length of the data
sent, length field included. Both parties MAY ignore all extra data
sent after the allowed window is empty.

Notes:

This is the data transfer packet:

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data

Since string's are defined by RFC4251 as being "stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string" it's unclear weather or not the uint32 length field contributes to the total or not. In my interoperability testing it seems that it does but it doesn't seem that this is all that clear from this RFC.

It is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. A strict interpretation would suggest it does not since the RFC makes no mention of it.

6.10. Returning Exit Status
When the command running at the other end terminates, the following
message can be sent to return the exit status of the command.
Returning the status is RECOMMENDED. No acknowledgement is sent for
this message. The channel needs to be closed with
SSH_MSG_CHANNEL_CLOSE after this message.
The client MAY ignore these messages.

It should say:

6.10. Returning Exit Status
When the command running at the other end terminates, the following
message can be sent to return the exit status of the command.
Returning the status is RECOMMENDED. No acknowledgement is sent for
this message. The channel needs to be closed by the server with
SSH_MSG_CHANNEL_CLOSE after this message.
The client MAY ignore these messages.

Notes:

Even though it can arguably be inferred from the text as written I think it'd make it more clear if the RFC explicitly said that the server is the one that should be sending the SSH_MSG_CHANNEL_CLOSE message.