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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
