Last Call Review of draft-ietf-dnsop-session-signal-10
review-ietf-dnsop-session-signal-10-genart-lc-halpern-2018-06-15-00
Request | Review of | draft-ietf-dnsop-session-signal |
---|---|---|
Requested revision | No specific revision (document currently at 20) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2018-06-25 | |
Requested | 2018-06-11 | |
Authors | Ray Bellis , Stuart Cheshire , John Dickinson , Sara Dickinson , Ted Lemon , Tom Pusateri | |
I-D last updated | 2018-06-15 | |
Completed reviews |
Opsdir Last Call review of -10
by Shwetha Bhandari
(diff)
Genart Last Call review of -10 by Joel M. Halpern (diff) Genart Telechat review of -11 by Joel M. Halpern (diff) Genart Telechat review of -12 by Joel M. Halpern (diff) |
|
Assignment | Reviewer | Joel M. Halpern |
State | Completed | |
Request | Last Call review on draft-ietf-dnsop-session-signal by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 10 (document currently at 20) | |
Result | Ready w/issues | |
Completed | 2018-06-15 |
review-ietf-dnsop-session-signal-10-genart-lc-halpern-2018-06-15-00
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 treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-session-signal-10 Reviewer: Joel Halpern Review Date: 2018-06-15 IETF LC End Date: 2018-06-25 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard. Also, the document is well-written and clear. Major issues: 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. 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.) 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)? In section 7.1, the description of the Keepalive message seems to be missing the explicit sentence that a keepalive response MUST contain a Keepalive TLV. I realize this is implicit in much of the description, but it seems a good practice to be clear about the requriement, and we should establish that practice in this document. (This would seem to belong in the next-to-last paragraph of section 7.1.)