[DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Ines Robles via Datatracker]

Reviewer: Ines Robles
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-ietf-dnsop-7706bis-07
Reviewer: Ines Robles
Review Date: 2020-02-28
IETF LC End Date: 2020-02-28
IESG Telechat date: Not scheduled for a telechat

Summary:

The document is well written,  it supplies appendixes with examples.

This document describes a method for the operator of a recursive resolver to
have a complete root zone locally, and to hide queries for the root zone from
outsiders, at the cost of adding some operational fragility for the operator.

I have some minor questions.

Major issues: None

Minor issues: None.

Nits/editorial comments:

1- Appendix B.5: it seems that the link is not valid: 

  This link worked for me:
  https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.

Questions:

1- It seems that this document replaces RFC7706, but the document states that
it updates RFC7706, is that correct?

2- Abstract: "The cost of adding some operational fragility for the operator",
Does it introduce security considerations that have to be mentioned?

3- Section 1: "Research shows that the vast majority of queries going to the
root are for names that do not exist in the
   root zone." - Do you have some references to that research that can be added
   to the draft?

4- I would expand KSK to Key signing key (KSK).

5- Should this draft add a reference to rfc8499?

Thank you for this document,

Ines.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Vladimír Čunát]

On 2/28/20 2:02 PM, Ines Robles via Datatracker wrote:
> 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
>7706>
>
>   This link worked for me:
>   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.

Yes, thank you.  We did some restructuring in the documentation that
changed links to the "rolling" versions.  If stability of the links is
preferred to being up to date, it's possible to switch to e.g.
https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html
We expect such links to remain alive for veeery long time (unless the
ReadTheDocs service prevents that in future in some way).

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Barry Leiba]

Thanks for the review, Ines.

Barry

On Fri, Feb 28, 2020 at 5:02 AM Ines Robles via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Ines Robles
> 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-ietf-dnsop-7706bis-07
> Reviewer: Ines Robles
> Review Date: 2020-02-28
> IETF LC End Date: 2020-02-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> The document is well written,  it supplies appendixes with examples.
>
> This document describes a method for the operator of a recursive resolver
> to
> have a complete root zone locally, and to hide queries for the root zone
> from
> outsiders, at the cost of adding some operational fragility for the
> operator.
>
> I have some minor questions.
>
> Major issues: None
>
> Minor issues: None.
>
> Nits/editorial comments:
>
> 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
>7706>
>
>   This link worked for me:
>   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.
>
> Questions:
>
> 1- It seems that this document replaces RFC7706, but the document states
> that
> it updates RFC7706, is that correct?
>
> 2- Abstract: "The cost of adding some operational fragility for the
> operator",
> Does it introduce security considerations that have to be mentioned?
>
> 3- Section 1: "Research shows that the vast majority of queries going to
> the
> root are for names that do not exist in the
>root zone." - Do you have some references to that research that can be
> added
>to the draft?
>
> 4- I would expand KSK to Key signing key (KSK).
>
> 5- Should this draft add a reference to rfc8499?
>
> Thank you for this document,
>
> Ines.
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Ines Robles]

Thank you for the fast response and clarification.

Best,

Ines.

On Fri, Feb 28, 2020 at 3:15 PM Vladimír Čunát 
wrote:

> On 2/28/20 2:02 PM, Ines Robles via Datatracker wrote:
> > 1- Appendix B.5: it seems that the link is not valid:  >resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
> >7706>
> >
> >   This link worked for me:
> >   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.
>
> Yes, thank you.  We did some restructuring in the documentation that
> changed links to the "rolling" versions.  If stability of the links is
> preferred to being up to date, it's possible to switch to e.g.
> https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html
> We expect such links to remain alive for veeery long time (unless the
> ReadTheDocs service prevents that in future in some way).
>
> --Vladimir
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Warren Kumari]

On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker
 wrote:
>
> Reviewer: Ines Robles
> 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-ietf-dnsop-7706bis-07
> Reviewer: Ines Robles
> Review Date: 2020-02-28
> IETF LC End Date: 2020-02-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> The document is well written,  it supplies appendixes with examples.
>
> This document describes a method for the operator of a recursive resolver to
> have a complete root zone locally, and to hide queries for the root zone from
> outsiders, at the cost of adding some operational fragility for the operator.
>
> I have some minor questions.
>
> Major issues: None
>
> Minor issues: None.
>
> Nits/editorial comments:
>

Thank you for the review!

> 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
>7706>
>
>   This link worked for me:
>   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.

Thanks - not just for pointing out the issue, but also finding a
better version - as suggested, I am changing this (in a git branch
where I am collecting updates) to
https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html -
I believe that stability is the most important attribute. AD, please
let us know if you disagree.

>
> Questions:
>
> 1- It seems that this document replaces RFC7706, but the document states that
> it updates RFC7706, is that correct?

Oh, good point - once this is published, it does replace 7706 (it is a
bis, and contains all of the content from 7706), so Obsoletes is
better.
Thank you, changed.

>
> 2- Abstract: "The cost of adding some operational fragility for the operator",
> Does it introduce security considerations that have to be mentioned?
>
> 3- Section 1: "Research shows that the vast majority of queries going to the
> root are for names that do not exist in the
>root zone." - Do you have some references to that research that can be 
> added
>to the draft?

H... I think that we missed this because, within the DNS community
this is sufficiently well known that we don't even think about /
question it.
There is quite a lot of research on this, but much if it is behind
paywalls - while almost 20 years old now (Gods, I feel old!), I think
that the best one to cite is still:
https://www.caida.org/publications/papers/2001/DNSMeasRoot/dmr.pdf (
DNS Measurements at a Root Server ) -- I will add this.

>
> 4- I would expand KSK to Key signing key (KSK).

Thanks! Done!

>
> 5- Should this draft add a reference to rfc8499?

Seems like a good idea, thanks! I'm adding:
"Readers are expected to be familiar with ."

>
> Thank you for this document,

 and thank you for the review.

W

>
> Ines.
>
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Barry Leiba]

Thanks, Ace, and post the update whenever you’re ready.

Barry

On Fri, Feb 28, 2020 at 10:18 AM Warren Kumari  wrote:

> On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker
>  wrote:
> >
> > Reviewer: Ines Robles
> > 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-ietf-dnsop-7706bis-07
> > Reviewer: Ines Robles
> > Review Date: 2020-02-28
> > IETF LC End Date: 2020-02-28
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > The document is well written,  it supplies appendixes with examples.
> >
> > This document describes a method for the operator of a recursive
> resolver to
> > have a complete root zone locally, and to hide queries for the root zone
> from
> > outsiders, at the cost of adding some operational fragility for the
> operator.
> >
> > I have some minor questions.
> >
> > Major issues: None
> >
> > Minor issues: None.
> >
> > Nits/editorial comments:
> >
>
> Thank you for the review!
>
> > 1- Appendix B.5: it seems that the link is not valid:  >resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
> >7706>
> >
> >   This link worked for me:
> >   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.
>
> Thanks - not just for pointing out the issue, but also finding a
> better version - as suggested, I am changing this (in a git branch
> where I am collecting updates) to
> https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html -
> I believe that stability is the most important attribute. AD, please
> let us know if you disagree.
>
> >
> > Questions:
> >
> > 1- It seems that this document replaces RFC7706, but the document states
> that
> > it updates RFC7706, is that correct?
>
> Oh, good point - once this is published, it does replace 7706 (it is a
> bis, and contains all of the content from 7706), so Obsoletes is
> better.
> Thank you, changed.
>
> >
> > 2- Abstract: "The cost of adding some operational fragility for the
> operator",
> > Does it introduce security considerations that have to be mentioned?
> >
> > 3- Section 1: "Research shows that the vast majority of queries going to
> the
> > root are for names that do not exist in the
> >root zone." - Do you have some references to that research that can
> be added
> >to the draft?
>
> H... I think that we missed this because, within the DNS community
> this is sufficiently well known that we don't even think about /
> question it.
> There is quite a lot of research on this, but much if it is behind
> paywalls - while almost 20 years old now (Gods, I feel old!), I think
> that the best one to cite is still:
> https://www.caida.org/publications/papers/2001/DNSMeasRoot/dmr.pdf (
> DNS Measurements at a Root Server ) -- I will add this.
>
> >
> > 4- I would expand KSK to Key signing key (KSK).
>
> Thanks! Done!
>
> >
> > 5- Should this draft add a reference to rfc8499?
>
> Seems like a good idea, thanks! I'm adding:
> "Readers are expected to be familiar with ."
>
> >
> > Thank you for this document,
>
> ... and thank you for the review.
>
> W
>
> >
> > Ines.
> >
> >
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Ines Robles]

Hi Warren,

Thank you very much for your reply,

Best wishes,

Ines.

On Fri, Feb 28, 2020 at 8:18 PM Warren Kumari  wrote:

> On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker
>  wrote:
> >
> > Reviewer: Ines Robles
> > 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-ietf-dnsop-7706bis-07
> > Reviewer: Ines Robles
> > Review Date: 2020-02-28
> > IETF LC End Date: 2020-02-28
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > The document is well written,  it supplies appendixes with examples.
> >
> > This document describes a method for the operator of a recursive
> resolver to
> > have a complete root zone locally, and to hide queries for the root zone
> from
> > outsiders, at the cost of adding some operational fragility for the
> operator.
> >
> > I have some minor questions.
> >
> > Major issues: None
> >
> > Minor issues: None.
> >
> > Nits/editorial comments:
> >
>
> Thank you for the review!
>
> > 1- Appendix B.5: it seems that the link is not valid:  >resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
> >7706>
> >
> >   This link worked for me:
> >   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.
>
> Thanks - not just for pointing out the issue, but also finding a
> better version - as suggested, I am changing this (in a git branch
> where I am collecting updates) to
> https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html -
> I believe that stability is the most important attribute. AD, please
> let us know if you disagree.
>
> >
> > Questions:
> >
> > 1- It seems that this document replaces RFC7706, but the document states
> that
> > it updates RFC7706, is that correct?
>
> Oh, good point - once this is published, it does replace 7706 (it is a
> bis, and contains all of the content from 7706), so Obsoletes is
> better.
> Thank you, changed.
>
> >
> > 2- Abstract: "The cost of adding some operational fragility for the
> operator",
> > Does it introduce security considerations that have to be mentioned?
> >
> > 3- Section 1: "Research shows that the vast majority of queries going to
> the
> > root are for names that do not exist in the
> >root zone." - Do you have some references to that research that can
> be added
> >to the draft?
>
> H... I think that we missed this because, within the DNS community
> this is sufficiently well known that we don't even think about /
> question it.
> There is quite a lot of research on this, but much if it is behind
> paywalls - while almost 20 years old now (Gods, I feel old!), I think
> that the best one to cite is still:
> https://www.caida.org/publications/papers/2001/DNSMeasRoot/dmr.pdf (
> DNS Measurements at a Root Server ) -- I will add this.
>
> >
> > 4- I would expand KSK to Key signing key (KSK).
>
> Thanks! Done!
>
> >
> > 5- Should this draft add a reference to rfc8499?
>
> Seems like a good idea, thanks! I'm adding:
> "Readers are expected to be familiar with ."
>
> >
> > Thank you for this document,
>
> ... and thank you for the review.
>
> W
>
> >
> > Ines.
> >
> >
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop