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 <dschinazi.ietf@gmail.com> 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@ietf.org> 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