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

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Tue, 18 Feb 2020 at 12:43, David Schinazi <[e-mail]> 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 <[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.
> 
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gen-art
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art