Subject: [tcpm] 793bis update

From: Wesley Eddy <[email-masked]>
Date: Wed, 5 Dec 2018 09:47:59 -0500

Hello, I've posted an update to the 793bis draft, with diffs available at:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-12.txt

Some changes worth commenting on and raising awareness of are:

1) There was some content missing on the proper PUSH behavior. It turned 
out that I hadn't previously brought this in correctly from RFC 1122.

2) I found an inconsistency between the description of "Asynchronous 
Reports" (from RFC 1122) and the description of error notifications to 
the application for incoming ICMP messages and excessive 
retransmissions.  In the specific sections that describe those, there 
are SHOULD statements about providing notification, but the Asynchronous 
Reports sections says "MUST". I think the MUST should be changed to a 
SHOULD in this section on page 54.  Your thoughts would be very helpful.

3) In section 3.9.2.3 I think there was a "must" that needed to become a 
"MUST".  The sentence in question is:

       An incoming SYN with an invalid source address MUST be ignored
       either by TCP or by the IP layer (MUST-63) (see Section 3.2.1.3 of
       [14]).

4) Similarly, in 3.10 I think there was a "should" that needs to be a 
"SHOULD":

       Segments with higher beginning sequence numbers SHOULD be held for later
       processing (SHLD-31).

5) In the RFC 1122 table of requirements, I think there was 1 spurious 
one that does not seem to relate to any actual sentence/requirement and 
seems to be a "MUST NOT" that would have been just a rephrasing of the 
MUST in MUST-37.  The item in the list just says: "Sender timeout OK 
conn with zero wind" with a checkmark in the "MUST NOT" column.  I 
believe this is the same as what we already have in MUST-37:

    As long as the receiving TCP continues to send acknowledgments
    in response to the probe segments, the sending TCP MUST allow the
    connection to stay open (MUST-37).

Again, your thoughts on this would be helpful.

I think altogether, the document is getting into pretty decent shape, so 
it would be good to hear some thoughts from the working group about it.

(Note on page 7 there is an XML2RFC reference I'm trying to correct to 
not resolve to "Paragraph 5", so please don't beat me up on that for now).