Last Call Review of draft-ietf-dnsop-5966bis-04

Request Review of draft-ietf-dnsop-5966bis
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-07
Requested 2015-11-29
Authors John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin, Duane Wessels
Draft last updated 2015-12-04
Completed reviews Genart Last Call review of -04 by Brian Carpenter (diff)
Genart Telechat review of -05 by Brian Carpenter (diff)
Opsdir Last Call review of -04 by Rick Casarez (diff)
Assignment Reviewer Rick Casarez 
State Completed
Review review-ietf-dnsop-5966bis-04-opsdir-lc-casarez-2015-12-04
Reviewed rev. 04 (document currently at 06)
Review result Has Nits
Review completed: 2015-12-04


Hello everyone,

I have reviewed draft-ietf-dnsop-5966bis-04 as part of the Operations Directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operation area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: I believe the document is 'Ready with Nits'.


Introduction, 1st paragraph, last sentence:

"It is now widely used in Response Rate Limiting [RRL]."

I looked and could not find any RFC or draft related to Response Rate Limiting and TCP. Is there any reference that can be placed in the document to help explain that sentence or allow one to go off and read into it? I did a Google search and found RRL references but not all implementations use TCP. So something needs to be added or the line removed I think.

Section 6.1, 1st paragraph after bullets:

There is a reference to HTTP/1.1 but why not reference HTTP/2.0 (RFC 7540) as well (Or in place of)?

Section 6.2.1, 2nd paragraph:

"When sending multiple queries over a TCP connection clients MUST take care to avoid Message ID collisions.  In other words, they MUST NOT re-use the DNS Message ID of an in-flight query on the same TCP connection."

Are both sentences needed? It seems like they are repeating the same thing using a different perspective. Something cleaner would seem to be in order: 

"When sending multiple queries over a TCP connection clients MUST NOT 
re-use the DNS Message ID of an in-flight query in order to avoid Message ID collisions."

Section, 4th paragraph:

I am a little bit confused about the third sentence here. I understand the two previous sentences and their 'SHOULD's. This third sentence though reads like you are saying a DNS server 'SHOULD process all queries' when it should be 'MUST process all queries'. I cannot imagine a scenario where we would want a DNS Server to not process all queries even if they come in fast over a pipeline but maybe I am misinterpreting.   

Section 6.2.3, 3rd paragraph:

"DNS messages delivered over TCP might arrive in multiple segments.  A DNS server that resets its idle timeout after receiving a single segment might be vulnerable to a "slow read attack". For this reason, servers SHOULD apply the idle timeout to the receipt of a full DNS message, rather than to receipt of any part of a DNS message."

I interpret the first part of this section as saying a server SHOULD NOT reset its idle timeout timer until it gets the full message. The last sentence does not seem to match that interpretation though and just mentioned idle timeout should only be applied on full message but nothing about resetting the timer. I also think a small editing change from 'to' to 'on' reads better. All proposed changed in italics below:

"For this reason, servers SHOULD 


 the idle timeout 


the receipt of
 a full DNS message, rather than 


receipt of any part of a DNS 

If "apply" means "resetting" please let me know. :)

Section 6.2.4:

Throughout the whole document you use 'DNS Server' and 'DNS Client'. For continuity I think this section needs an edit for this.

Section 8, 2nd paragraph:

Second paragraph is not clear to me. It discusses aborting connections due to a TCP Segment missing some information. Not sure I would confuse it with a reference to a section on idle timeout resets (or timer resets in general). The only relevant part of 6.2.3 would be about not taking any action until all segments are received. I am not sure why timeouts are referenced. 


Cheers, Rick

Experiences not things.