Re: [Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15
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 wrote: > > On Tue, 18 Feb 2020 at 12:43, David Schinazi 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 >> 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@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > > ___ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15
On Tue, 18 Feb 2020 at 12:43, David Schinazi 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 > 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@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15
Hi Erik, Thank you for your review. Responses inline. Thanks, David On Mon, Feb 17, 2020 at 4:38 PM Erik Kline via Datatracker 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. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
