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: >> 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. 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? :) Q1_3: >> I assume sections 1.2, 1.3 and 1.4 contain the motivation? If so, I >> think it should be more clear. > >Done - I have created a "Motivations for Negative Trust Anchors" > section and moved these sections into it. See below. Q1_4: >> The section titles of 1.3 and 1.4 seem half-finished. Reaction to >> what? Not recommended by whom? > > 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: >> 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. 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. > > Fair -- I added "a DNSSEC validation failure" 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
