I got a bit wound up about not making the three changes that Joel called out in the updated session signal comment, and insisted on not making the changes because they didn't seem that important. I had a bit more private conversation with Joel about it, and after some reflection decided that it might be worth suggesting some changes after all based on Joel's comments.
What I would propose to fix these three issues are the following three changes. In 5.1.3: OLD: Where an application-layer middlebox (e.g., a DNS proxy, forwarder, or session multiplexer) is in the path, the middlebox MUST NOT blindly forward DSO messages in either direction, and MUST treat the inbound and outbound connections as separate sessions. This does not preclude the use of DSO messages in the presence of an IP-layer middlebox, such as a NAT that rewrites IP-layer and/or transport- layer headers but otherwise preserves the effect of a single session between the client and the server. NEW: Where an application-layer middlebox (e.g., a DNS proxy, forwarder, or session multiplexer) is in the path, care must be taken to avoid inappropriately passing session signaling through the middlebox. In cases where a DSO session is terminated on one side of a middlebox, and then some session is opened on the other side of the middlebox in order to satisfy requests sent over the first DSO session, any such session MUST be treated as a separate session. This does not preclude the use of DSO messages in the presence of an IP-layer middlebox, such as a NAT that rewrites IP-layer and/or transport- layer headers but otherwise preserves the effect of a single session between the client and the server. And of course it does not apply to middleboxes that do not implement DNS Stateless Operations. These restrictions do not apply to middleboxes that do not implement DSO: since they have no way to understand a DSO message, a pass-through middlebox like the one described in the previous paragraph will pass DSO messages unchanged or drop them (or possibly drop the connection). A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly. In 5.2.2: OLD: A DSO response message may contain no TLVs, or it may be specified to contain one or more TLVs appropriate to the information being communicated. This includes "Primary TLVs" and "Additional TLVs" defined in this document as well as in future TLV definitions. NEW: A DSO response message may contain no TLVs, or it may be specified to contain one or more TLVs appropriate to the information being communicated. This includes "Primary TLVs" and "Additional TLVs" defined in this document as well as in future TLV definitions. It may be permissible for an additional TLV to appear in a response to a primary TLV even though the specification of that primary TLV does not specify it explicitly. See section 8.2 for more information. In 5.4: OLD: With most TCP implementations, for DSO requests that generate a response, the TCP data acknowledgement (generated because data has been received by TCP), the TCP window update (generated because TCP has delivered that data to the receiving software), and the DSO response (generated by the receiving application-layer software itself) are all combined into a single IP packet. Combining these three elements into a single IP packet can give a significant improvement in network efficiency. NEW: With most TCP implementations, for DSO requests that generate a response, the TCP data acknowledgement (generated because data has been received by TCP), the TCP window update (generated because TCP has delivered that data to the receiving software), and the DSO response (generated by the receiving application-layer software itself) are all combined into a single IP packet. Combining these three elements into a single IP packet can give a significant improvement in network efficiency, assuming that the DSO response is sent before the TCP Delayed Acknowledgement timer goes off.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
