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(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf