Erik, thanks for the review. David, thanks for the response. I entered a No Objection ballot. Alissa > On Feb 18, 2020, at 3:50 PM, Erik Kline <ek@xxxxxxxx> wrote: > > On Tue, 18 Feb 2020 at 12:43, David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote: >> >> Hi Erik, >> >> Thank you for your review. Responses inline. >> >> Thanks, >> David >> >> >> On Mon, Feb 17, 2020 at 4:38 PM Erik Kline via Datatracker <noreply@xxxxxxxx> 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. > > 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. > >>> 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? > > 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. > >>> [ 8.1 ] >>> Consider referring to RFC 8499 for DNS terminology, if that improves >>> the descriptions of types of resolvers. >> >> >> Added a reference to 8499. >> _______________________________________________ >> Gen-art mailing list >> Gen-art@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
