re: Last Call: <draft-ietf-tcpm-urgent-data-06.txt> (On the implementation of the TCP urgent mechanism) to Proposed Standard

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf