Re: [Gen-art] Genart telechat review of draft-ietf-dnsop-session-signal-11

[Ted Lemon <[e-mail]>]

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.