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

["Joel M. Halpern" <[e-mail]>]

Thank you Ted.  Those address my concerns.
Yours,
Joel

On 7/9/18 9:07 PM, Ted Lemon wrote:
> 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.
> 
>