Code change:
It is spelled as Acknowledgments in every RFC. Fix the one inconsistent case instead.
FWIW, I checked the style guide. Will check again. That doesn't support what you say. The current text uses the slightly minority spelling which is also the one used in the RFC Styled Guide. Feel free to flip to the other spelling if you have a strong preference.
Well, FFS, the style guide also says to use either US spelling or British spelling, but not both. It is spelled Acknowledgments in the US and all RFCs prior to that style guide. The RFC editor deliberately changed my text to Acknowledgments the last time this came up. I don't care which way it is spelled.
[x] Section 9.1. , paragraph 2, comment: I'm not sure I understand what is meant by "transport link" and how connections would "apply" to one. Editors: URL
[x] Section 9.4. , paragraph 4, comment: Using larger number of multiple connections can even cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. Editors: URL
[x] Section 13.1. , paragraph 14, comment: This can become an informative reference, so to not create a DOWNREF, since it's only used in the description of an IANA codepoint. Editors: URL
[X] Section 13.2. , paragraph 12, comment: I think it is common practice to normatively cite an RFC that is being obsoleted. Editors: URL
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
[X] Section 9.3. , paragraph 3, nit: This got garbled, the suggestion was to rephrase to: A recipient determines whether a connection is persistent or not based on the protocol version and Connection header field in the most recently received message (Section 7.6.1 of [Semantics]), if any: Editors: URL
[X] Section 11.2. , paragraph 2, nit:[X] Section 12.3. , paragraph 3, nit: Editors: this is intentional. Leave it to the RFC Editor?
[X] Section 7.1.1. , paragraph 6, nit: Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Editors: URL
[x] Section 9.5. , paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] Section 9.8. , paragraph 2, nit: The abbreviation is missing a period after the last letter. Editors: URL
[X] Section 10.2. , paragraph 17, nit: Consider using "many". Editors: this is in 11.4. URL
[x] "Appendix B. ", paragraph 2, nit: Did you mean "ought to stop"? Editors: URL
[x] "B.3. ", paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. [x] "B.4. ", paragraph 1, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] "C.2.2. ", paragraph 4, nit: This abbreviation for "identification" is spelled all-uppercase. Editors: URL
[x] Uncited references: [RFC7231]. Editors: URL
[x] Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose). Editors: this is indeed intended, as we're citing something that is in 2068 but not 2616
[x] These URLs point to URL, which is being deprecated: URL URL Editors: these are added by xml2rfc; you may want to open a ticket for that tool :-)
[x] These URLs in the document can probably be converted to HTTPS: URL Editors: URL
It is used normatively for the definition of the "compress" coding. (also, this is no change from RFC 723x).
Sorry? We are obsoleting that spec, thus we will not have a normative dependency on it.
would "apply" to one. Suggest:
otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. With some light editing, I think this would be useful to add.
I think we should commit this now and let the RFC editor decide on spelling.

Related discussion:
text: 11.1. <del> Response splitting (a.k.a, CRLF injection) is a common technique, </del> <ins> Response splitting (a.k.a., CRLF injection) is a common technique, </ins> used in various attacks on Web usage, that exploits the line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections Klein.  This