Skip to main content

Last Call Review of draft-cheshire-sudn-ipv4only-dot-arpa-15
review-cheshire-sudn-ipv4only-dot-arpa-15-genart-lc-kline-2020-02-17-00

Request Review of draft-cheshire-sudn-ipv4only-dot-arpa
Requested revision 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
I-D 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 O. Bradner (diff)
Intdir Telechat review of -16 by Bernie Volz (diff)
Assignment Reviewer Erik Kline
State Completed
Request Last Call review on draft-cheshire-sudn-ipv4only-dot-arpa by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/yD4XE_JUDFVWUKQsMNCv_YMCfCw
Reviewed revision 15 (document currently at 17)
Result Ready w/nits
Completed 2020-02-17
review-cheshire-sudn-ipv4only-dot-arpa-15-genart-lc-kline-2020-02-17-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-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

Summary:

Are any of the recommendations for client resolvers in this document
covered the IPR (https://datatracker.ietf.org/ipr/3077/) claimed for:

    https://tools.ietf.org/html/rfc8305#section-7

(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:

    1.1.1.1  https://1.1.1.1
    8.8.8.8  https://developers.google.com/speed/public-dns/
    9.9.9.9  https://quad9.net/

* s/is is/it is/

[ 6 ]
I'm not sure I follow the logic about whether/why ipv4only.arpa
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.