Telechat Review of draft-ietf-dnsop-session-signal-11

Request Review of draft-ietf-dnsop-session-signal
Requested rev. no specific revision (document currently at 20)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-07-31
Requested 2018-07-03
Draft last updated 2018-07-05
Completed reviews Opsdir Last Call review of -10 by Shwetha Bhandari (diff)
Genart Last Call review of -10 by Joel Halpern (diff)
Genart Telechat review of -11 by Joel Halpern (diff)
Genart Telechat review of -12 by Joel Halpern (diff)
Assignment Reviewer Joel Halpern
State Completed
Review review-ietf-dnsop-session-signal-11-genart-telechat-halpern-2018-07-05
Reviewed rev. 11 (document currently at 20)
Review result Ready with Nits
Review completed: 2018-07-05


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 
    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
    I suspect from the lack of comment on this that I am missing something obvious?