I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dnsop-session-signal-11 Reviewer: Joel Halpern Review Date: 2018-07-05 IETF LC End Date: 2018-06-25 IESG Telechat date: 2018-08-02 Summary: This document is ready for publication as a Proposed Standard RFC Some of my earlier comments have been addressed. It appears that an effort was made to address more, but I was apparently unclear. I have copied the comments that seem to still apply, with elaboration. If I am still unclear, please contact me. Major issues: N/A Minor issues: Section 5.1.3 places some requirements on application level middleboxes, and includes a very clear explanation of why it places these requirements. While it may be "obvious" to one who lives and breathes DNS, I think it would help to explain why the usual operation of an existing middlebox will (typically? always? inherently?) meet this requirement. To rephrase, the text says things like "the middlebox MUST NOT blindly forward DSO messages in either direction." Apparently, somehow, the existing world middleboxes will do comply with this. How? The third and fourth paragraphs of section 5.2.2 do not talk about optional additional TLVs. It would be helpful if the document stated that in addition to those additional TLVs required by the primary TLV, other TLVs may be included based on their individual definition, independent of the definition of the primary TLV. (Both the Encryption padding and the delay retry TLVs may be included in suitable messages without being called out in the definition of the primary TLVs.) An effort appears to have been made to address this, which suggests I was unclear. The text says: 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. The definition of the specific response messages does not discuss the encryption padding or delay response TLVs. They are clearly intended to be allowed. So can we tune the text to make that clear. I think the intention is that the specification of the response message indicates which TVLs are required, and that others are allowed. So say that. Nits/editorial comments: Section 5.4 talks about by default the TCP data ack and the DSO reply message being combined. Doesn't this depend upon the responsiveness of the DSO engine? Is there an implicit assumption about such timeliness (sub 200 ms)? I suspect from the lack of comment on this that I am missing something obvious?