Please see attached review.
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tcpm-persist-04.txt Reviewer: Brian Carpenter Review Date: 2011-05-30 IETF LC End Date: 2011-06-03 IESG Telechat date: Summary: Almost ready, but... -------- Comment: -------- I have no problem with the message of this draft, but there are problems in the way the message is delivered. Major issues: ------------- Why is this Informational? If it matters, it should be a Standards Track document updating RFC 1122. If it's not a Standards Track document, why is it using RFC 2119 language? " The problem is applicable to TCP and TCP derived flow-controlled transport protocols like SCTP." This statement is not much use on its own. Does this draft apply to SCTP? If it does, which text in the SCTP spec is affected? Important editorial issues: --------------------------- The draft says: (begin quote from draft-ietf-tcpm-persist-04) 1. Introduction Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says: "A TCP MAY keep its offered receive window closed indefinitely. 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." DISCUSSION: It is extremely important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP. (end quote from draft-ietf-tcpm-persist-04) The closing quotation mark is incorrectly placed - it belongs after 'TCP.' not after 'open.'. The reader will be misled by this. You might consider even clearer flags for the extract, as I have used above. (begin quote from draft-ietf-tcpm-persist-04) 5. Clarification Regarding RFC 1122 Requirements As stated in Requirements for Internet Hosts [RFC1122], a TCP implementation MUST NOT close a connection merely because it seems to be stuck in the ZWP or persist condition. Unstated in RFC 1122, but implicit for system robustness, a TCP implementation MUST allow connections in the ZWP or persist condition to be closed or aborted by their applications or other resource management routines in the operating system. (end quote from draft-ietf-tcpm-persist-04) Both these sentences seem to assert things about RFC 1122, and about the state of mind of its editor, that I have no reason to believe. RFC 1122 doesn't say anything about the MUST NOT being "merely because" anything - the statement in section 4.2.2.17 is completely unambiguous. And I don't see any grounds for asserting that the second sentence is any way implicit in RFC 1122. Quite the opposite - you are documenting an oversight. I think you should say so. For example: 5. Update to RFC 1122 Requirements Requirements for Internet Hosts [RFC1122] states that a TCP implementation MUST NOT close a connection if it seems to be stuck in the ZWP or persist condition, as long as ackowledgements are being received. The present document updates this requirement by adding that a TCP implementation MUST allow connections in the ZWP or persist condition to be closed or aborted by their applications or other resource management routines in the operating system. Minor editorial --------------- These are examples - I think the English needs a general tidy-up: " Per Requirements for Internet Hosts [RFC1122] as long as the ACK's are being received for window probes, a connection can continue to stay in the persist condition." The use of "Per" like this is, well, sloppy. "According to..." would be better. There is a missing comma after "[RFC1122]". "ACK's" should be "ACKs". " Systems that adhere too strictly to the above verbiage of Requirements for Internet Hosts [RFC1122]..." It isn't "verbiage", which means "The use of many words without necessity, or with little sense; a superabundance of words; verbosity; wordiness" according to my favourite on-line dictionary. It is just "wording".
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
