Overall, I think this document is fine. However I think it needs a couple of
tweaks.
The document revises the specifications for sender and receiver handling of TCP
urgent data, presumably in order to improve interoperability. 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. 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.
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.
I also note that section 6 imposes a MUST requirement on applications that
depends on a non-standard TCP sockets API feature (SO_OOBINLINE)
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.
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.
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.
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.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf