Re: [Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15

[David Schinazi <[e-mail]>]

Hi Erik,

Thank you for your review. Responses inline.

Thanks,
David


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

> 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)?
>

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.

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

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


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

Done

[ 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/


Done

* s/is is/it is/
>

Done


> [ 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.
>

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


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

Added a reference to 8499.