Subject: [Gen-art] Gen-ART review of draft-ietf-dnsop-negative-trust-anchors-10

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Jun 2015 11:43:43 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Document:                                   draft-ietf-dnsop-negative-trust-anchors-10
Reviewer:                                     Christer Holmberg
Review Date:                               13 June 2015
IETF LC End Date:                       23 June 2015
IETF Telechat Date:                   N/A
Summary:         The document is well written, but I have some editorial comments that I'd like the authors to address.
Major Issues: None
Minor Issues: None
Editorial Issues:

General
----------

QG_1:

In the document text, you sometimes say "Negative Trust Anchor" and sometimes "NTA". I would suggest to say "Negative Trust Anchor (NTA)" on the first occurrence (in the Abstract and the Introduction), and then "NTA". In section titles you can use "Negative Trust Anchor", though, if you want.

Abstract
-----------

QA_1:

The abstract text should be more clear about what the draft does. I suggest to re-write the last sentence, and begin the sentence with "This document defines...", similar to the Introduction.

Introduction:
-----------------

QI_1:

I suggest switching order of the first and second paragraph. It's good to begin with the background and justification, and then describe what the document does.

Q1_2:

It is really difficult to understand what a Negative Trust Anchor is when reading section 1. In section 1.1 you talk about Trust Anchors, but if a Negative Trust Anchor is related to a Trust Anchor I think it would be good to mention that already in section 1. Then, in section 1.1, you can focus on the differences between a Trust Anchor and a Negative Trust Anchor.

Q1_3:

I assume sections 1.2, 1.3 and 1.4 contain the motivation? If so, I think it should be more clear.

Q1_4:

The section titles of 1.3 and 1.4 seem half-finished. Reaction to what? Not recommended by whom?

Section 2:
------------

Q2_1:

I wonder whether the two last paragraphs belong to an "Applicability" section?

Q2_2:

The text starts by talking about failure and breakage, but it's unclear what failure/breakage. If that is described elsewhere, please provide a reference.

Section 8:
------------

Q8_1: I suggest to remove the "Other considerations" section title, and define separate main sections for the Security, Privacy and IANA considerations.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 14 Jun 2015 16:11:36 -0400

On Sat, Jun 13, 2015 at 7:43 AM, Christer Holmberg
<[email-masked]> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

First off, thank you for your review. I have integrated all of your
changes, and think that document is substantially better for it.

More inline.

>
> Document:
> draft-ietf-dnsop-negative-trust-anchors-10
>
> Summary:         The document is well written, but I have some editorial
> comments that I’d like the authors to address.
>
> Major Issues: None
>
> Minor Issues: None
>
> Editorial Issues:
>
>
>
> General
>
> ----------
>
>
>
> QG_1:
>
>
>
> In the document text, you sometimes say “Negative Trust Anchor” and
> sometimes “NTA”. I would suggest to say “Negative Trust Anchor (NTA)” on the
> first occurrence (in the Abstract and the Introduction), and then “NTA”. In
> section titles you can use “Negative Trust Anchor”, though, if you want.

Done (in https://github.com/wkumari/draft-livingood-dnsop-negative-trust-anchors
)
I didn't want to cut a new rev during IETF LC.

>
>
> Abstract
>
> -----------
>
>
> QA_1:
>
>
> The abstract text should be more clear about what the draft does. I suggest
> to re-write the last sentence, and begin the sentence with “This document
> defines…”, similar to the Introduction.
>

Done.

>
>
>
> Introduction:
>
> -----------------
>
>
>
> QI_1:
>
>
>
> I suggest switching order of the first and second paragraph. It’s good to
> begin with the background and justification, and then describe what the
> document does.

Done. I ended up splitting the 2nd paragraph before swapping them,
because this makes it flow better.

>
>
>
> Q1_2:
>
>
>
> It is really difficult to understand what a Negative Trust Anchor is when
> reading section 1. In section 1.1 you talk about Trust Anchors, but if a
> Negative Trust Anchor is related to a Trust Anchor I think it would be good
> to mention that already in section 1. Then, in section 1.1, you can focus on
> the differences between a Trust Anchor and a Negative Trust Anchor.
>

Now that I've shuffled the paragraphs around, and moved some
additional text further down, I *think* I have made this OK (section 1
is shorter and flows better, so I think it is fine). Please let me
know if you disagree...

> I assume sections 1.2, 1.3 and 1.4 contain the motivation? If so, I think it

Done - I have created a "Motivations for Negative Trust Anchors"
section and moved these sections into it.

> The section titles of 1.3 and 1.4 seem half-finished. Reaction to what? Not

As I have moved the sections into a "Motivations" section I was able
to reword the section titles for 1.2, 1.3, 1.4
I think that this makes them more readable. Please let me know if you
think they need additional changes.

>
>
>
> Section 2:
>
> ------------
>
>
>
> Q2_1:
>
>
>
> I wonder whether the two last paragraphs belong to an “Applicability”
> section?
>

Not sure. I made the change, I think is it better, but not sure. I
generally prefer documents that do not have this many sections (and
subsections) - I generally worry that people will see the Table of
Contents, become intimidated and not read the doc. But, a: that might
just be me and b: the people who need to read this document will be
doing it because they *really* need the doc, and so will be willing to
put in the time and effort.

>
>
> Q2_2:
>
>
>
> The text starts by talking about failure and breakage, but it’s unclear what
> failure/breakage. If that is described elsewhere, please provide a
> reference.

Fair -- I added "a DNSSEC validation failure"

>
>
>
>
>
> Section 8:
>
> ------------
>
>
>
> Q8_1: I suggest to remove the “Other considerations” section title, and
> define separate main sections for the Security, Privacy and IANA
> considerations.
>

Thanks, this looks much better (I'm not actually sure why we ended up
with the one big “Other considerations” section...

Thank you again for your review,
W

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jun 2015 12:51:52 +0000

Hi Warren,

Thanks for addressing my comments! Most look ok now, but I still have comments on a couple of the issues.

General

-----------

QG_1:

>> sometimes “NTA”. I would suggest to say “Negative Trust Anchor (NTA)” 
>> on the first occurrence (in the Abstract and the Introduction), and 
>> then “NTA”. In section titles you can use “Negative Trust Anchor”, though, if you want.
>
>Done (in https://github.com/wkumari/draft-livingood-dnsop-negative-trust-anchors)

In general the text looks good, but I see that you still use "NTA" in the 2.1 and 3.1 section names.

Abstract
 -----------

QA_1:

>>The abstract text should be more clear about what the draft does. I 
>>suggest to re-write the last sentence, and begin the sentence with 
>>“This document defines…”, similar to the Introduction.
>
> Done.

Looks good.

Introduction:
-----------------

QI_1:

>> I suggest switching order of the first and second paragraph. It’s good 
>> to begin with the background and justification, and then describe what 
>> the document does.
>
> Done. I ended up splitting the 2nd paragraph before swapping them, because this makes it flow better.

See below.

Q1_2:

>> It is really difficult to understand what a Negative Trust Anchor is 
>> when reading section 1. In section 1.1 you talk about Trust Anchors, 
>> but if a Negative Trust Anchor is related to a Trust Anchor I think it 
>> would be good to mention that already in section 1. Then, in section 
>> 1.1, you can focus on the differences between a Trust Anchor and a Negative Trust Anchor.
>
> Now that I've shuffled the paragraphs around, and moved some additional text further down, I *think* I have made this 
> OK (section 1 is shorter and flows better, so I think it is fine). Please let me know if you disagree...

You have the following sentences:

"This document defines the Negative Trust Anchor (NTA), which can be used during the transition to ubiquitous DNSSEC deployment."

...followed by:

"NTAs are configured locally on a validating DNS recursive resolver to shield
end users from DNSSEC-related authoritative name server operational
errors."

Between those sentences, it would be nice to get some kind of idea what an NTA is. Is it a box, is it a function within an existing box, etc etc? :)

> section and moved these sections into it.

See below.

Q1_4:

> As I have moved the sections into a "Motivations" section I was able to reword the section titles for 1.2, 1.3, 1.4 I think that this makes them more readable. Please let me know if you think they need additional changes.

Looks good.

Section 2:
------------

Q2_1:

> Not sure. I made the change, I think is it better, but not sure. I generally prefer documents that do not have this many sections (and
> subsections) - I generally worry that people will see the Table of Contents, become intimidated and not read the doc. But, a: that might
> just be me and b: the people who need to read this document will be doing it because they *really* need the doc, and so will be willing 
> to put in the time and effort.

In general I agree. But, I also think it is good if it is clear where the reader can look for limitations in usability, scope etc.

I think what you have done otherwise looks good, but I think it would be good to have applicability as a separate main section, and place it in front of the usage section.

E.g.

	2. Applicability
	3. Use of a Negative Trust Anchor
	...

However, if you think that the reader must read the "Use of" section in order to understand the "Applicability" section, then you can keep the current order.

Q2_2:

>> The text starts by talking about failure and breakage, but it’s 
>> unclear what failure/breakage. If that is described elsewhere, please 
>> provide a reference.
>

Looks good.

Section 8:
------------

>> Q8_1: I suggest to remove the “Other considerations” section title, 
>> and define separate main sections for the Security, Privacy and IANA 
>> considerations.
>
>Thanks, this looks much better (I'm not actually sure why we ended up with the one big “Other considerations” section...

Looks good.

Thanks!

Regards,

Christer

---

From: Warren Kumari <[email-masked]>
Date: Fri, 19 Jun 2015 10:26:12 -0400

> Thanks for addressing my comments! Most look ok now, but I still have comments on a couple of the issues.

I did not make any changes here. An NTA is a configuration on a DNS
recursive resolver, to answer your question -- and the sentence you
quoted says that... I'm not sure that there's anything else that would
further clarify, but you're welcome to suggest specific text if you
believe otherwise.

>> As I have moved the sections into a "Motivations" section I was able to reword the section titles for 1.2, 1.3, 1.4 I think that this makes them more readable. Please let me know if you think they…

Keeping as is; the reader should read the "Use of" section.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jun 2015 07:54:53 +0000

Hi Warren,

Q1_2:

>>>> but if a Negative Trust Anchor is related to a Trust Anchor I think 
>>>> it would be good to mention that already in section 1. Then, in 
>>>> section 1.1, you can focus on the differences between a Trust Anchor and a Negative Trust Anchor.
>>>
>>> additional text further down, I *think* I have made this OK (section 1 is shorter and 
>>> flows better, so I think it is fine). Please let me know if you disagree...
>>
>> "NTAs are configured locally on a validating DNS recursive resolver to 
>> shield end users from DNSSEC-related authoritative name server 
>> operational errors."
>>
>> Between those sentences, it would be nice to get some kind of idea 
>> what an NTA is. Is it a box, is it a function within an existing box, 
>> etc etc? :)
>
> I did not make any changes here. An NTA is a configuration on a DNS recursive resolver, to answer 
> your question -- and the sentence you quoted says that... I'm not sure that there's anything else that 
> would further clarify, but you're welcome to suggest specific text if you believe otherwise.

I'm happy with your explanation :)

Thanks!

Regards,

Christer