Last Call Review of draft-cheshire-sudn-ipv4only-dot-arpa-15

Request Review of draft-cheshire-sudn-ipv4only-dot-arpa
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-02-17
Requested 2020-01-20
Authors Stuart Cheshire, David Schinazi
Draft last updated 2020-02-17
Completed reviews Secdir Last Call review of -15 by Rich Salz (diff)
Genart Last Call review of -15 by Erik Kline (diff)
Opsdir Last Call review of -15 by Scott Bradner (diff)
Intdir Telechat review of -16 by Bernie Volz (diff)
Assignment Reviewer Erik Kline 
State Completed
Review review-cheshire-sudn-ipv4only-dot-arpa-15-genart-lc-kline-2020-02-17
Posted at
Reviewed rev. 15 (document currently at 17)
Review result Ready with Nits
Review completed: 2020-02-17


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


Document: draft-cheshire-sudn-ipv4only-dot-arpa-??
Reviewer: Erik Kline
Review Date: 2020-02-17
IETF LC End Date: 2020-02-17
IESG Telechat date: Not scheduled for a telechat


Are any of the recommendations for client resolvers in this document
covered the IPR ( claimed for:

(which has some similar/related recommendations, especially 7.3)?

Otherwise, I think this is basically ready, with just a few random nits
noted below (and ignoring the jeremiad-esque tone about the
design/implications of the middlebox protocol nature of RFC 7050 ;-).

Major issues:

Minor issues:

Nits/editorial comments:

[ abstract ]
* 3rd para could be removed for brevity (but keep same in the intro)

[ 4.1 ]

* Consider whether to including references to 1.1, 8.8, and 9.9
  services.  I think the following might suffice:

* s/is is/it is/

[ 6 ]
I'm not sure I follow the logic about whether/why
must not be a signed zone.  It seems to me that the concluding
paragraph beginning with 'Consequently, ...' actually lays out
the rationale in the most straightforward manner in this section.

It's a nice TL;DR, but I'm not sure how to formulate a useful
recommendation for reflowing text to better highlight this.

[ 8.1 ]
Consider referring to RFC 8499 for DNS terminology, if that improves
the descriptions of types of resolvers.