Subject: [Last-Call] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15

From: Erik Kline via Datatracker <[email-masked]>
Date: Mon, 17 Feb 2020 16:38:36 -0800

Reviewer: Erik Kline
Review result: Ready with Nits

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.

---

From: David Schinazi <[email-masked]>
Date: Tue, 18 Feb 2020 12:42:42 -0800

Hi Erik,

Thank you for your review. Responses inline.

Thanks,
David

On Mon, Feb 17, 2020 at 4:38 PM Erik Kline via Datatracker <[email-masked]>
wrote:
[snip]

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

I was also an author on RFC 8305 and IPR claim 3077, but I am not a lawyer.
Speaking as an individual, I am not aware of any IPR related to
draft-cheshire-sudn-ipv4only-dot-arpa-15.
Apologies for the disclaimer, but if you're trying to ascertain whether a
specification is covered by a patent, I would suggest contacting a lawyer.

> design/implications of the middlebox protocol nature of RFC 7050 ;-).

I have a PR that attempts to address these editorial comments here:
https://github.com/StuartCheshire/draft-cheshire-sudn-ipv4only-dot-arpa/pull/1/files

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

Done

[ 4.1 ]
>     9.9.9.9  https://quad9.net/

Done

* s/is is/it is/

Done

> recommendation for reflowing text to better highlight this.

I'm not sure how to act on this comment. Can you suggest text?

> the descriptions of types of resolvers.

Added a reference to 8499.

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Feb 2020 12:50:30 -0800

On Tue, 18 Feb 2020 at 12:43, David Schinazi <[email-masked]> wrote:
> On Mon, Feb 17, 2020 at 4:38 PM Erik Kline via Datatracker <[email-masked]> wrote:
> [snip]
>>

I believe you, as an author, will have to assert that all applicable
IPR declarations of which you are aware (here you're saying, "there
are none") have been declared.  I was just reminded of this one, in
case you'd not thought about it in a while.  I haven't read it, but I
had presumed you had.

>>     8.8.8.8  https://developers.google..com/speed/public-dns/

I could not.  I was just noting that it took me several readings of
this section to grok what I thought was the point, and that the nice
TL;DR was here at the bottom of the section.

I don't think it needs any fixing, though.

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art