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

2020-03-11 Thread Alissa Cooper 
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

2020-02-18 Thread Erik Kline 
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

2020-02-18 Thread David Schinazi 
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

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

2020-02-17 Thread Erik Kline via Datatracker 
Reviewer: Erik Kline
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-cheshire-sudn-ipv4only-dot-arpa-??
Reviewer: Erik Kline
Review Date: 2020-02-17
IETF LC End Date: 2020-02-17
IESG Telechat date: Not scheduled for a telechat

Summary:

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)?

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:

[ abstract ]
* 3rd para could be removed for brevity (but keep same in the intro)

[ 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/

* s/is is/it is/

[ 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.

[ 8.1 ]
Consider referring to RFC 8499 for DNS terminology, if that improves
the descriptions of types of resolvers.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art