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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
