Hi, Keith, Thanks so much for your feedback! Please find my comments inline... > The document revises the specifications for sender and receiver handling > of TCP urgent data, presumably in order to improve interoperability. Actually, it resolves a disconnect between the specifications and virtually all implementations of the urgent mechanism. > In > particular, sections 5 and 6 of this document impose RFC 2119 > requirements (SHOULD NOT / MUST) on applications. > > However, > > * No requirements are imposed on TCP implementations. The "requirement" on TCP implementations is in Section 4 (page 7). However, it doesn't use RFC 2119 language as the text that it is updating (RFC 793, RFC 1122) doesn't use RFC-2119, either. > This document > claims to "update" RFCs 793, 1011, and 1122. TWhat the document > should be doing, primarily, is specifying (new) correct behavior. > It's fine to describe how the new behavior varies from that > described in previous RFCs, and also how the new behavior varies > from that observed in popular TCP implementations. But these > should be non-normative, descriptive sections of the document. > The primary job of a standards-track specification is to specify > the behavior. Please see above. > * This document also does not place any constraints on > intermediaries, even though the document itself acknowledges that > intermediaries interfere with operation of the TCP urgent facility. No TCP specs that I know of accommodate packet scrubbers or firewalls that simply decide to clear a bit, etc (except for NATs, which are a completely different issue). When they do (e.g., ECN), it's to discourage such behavior. > I also note that section 6 imposes a MUST requirement on applications > that depends on a non-standard TCP sockets API feature (SO_OOBINLINE) I guess this could be rephrased as "applications that still decide to employ it MUST process the "urgent data" in-line, as intended by the ETF specifications (e.g., by setting the SO_OOBINLINE socket option)"? > Recommendations: > > 1. Label the descriptive sections of this document as non-normative, or > otherwise make clear the distinction between the informative/descriptive > portions of the document and the prescriptive portions of the document. My take (probably biased, since I'm a co-author of the I-D), is that Sections 4 through 6 contain all the requirements, and are clear in this respect. I agree that some text could be moved out of Section 4, though. What do others think? > 2. Add a normative section describing new requirements on TCP > implementations, even if the new requirements are very similar to what > popular implementations already do. Isn't this reflected in Section 4, already? > 3. Consider defining (perhaps in a informative appendix) a uniform > mechanism for socket-based applications to use to put OOB data inline. > 4. Reword section 6 so that it's not specific to the socket API or > particular implementations. See my counter-proposal for Section 6. > 5. Add a informative section discussing the pros/cons of IP-level > intermediaries altering the URG bit. > 6. Add a normative section which states that IP-level intermediaries > SHOULD NOT alter the URG bit. I don't think that tcpm is going to get consensus on "pros" of altering the URG bit. I guess that the idea is that no firewall or packet scrubber should modify TCP header fields. But, again, I'd like to know what others think. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf