Hello Peter and Matt, eventually, I found the time to take a closer look at the latest version of your Resolver Priming I-D, draft-ietf-dnsop-resolver-priming-01, and again would like to submit a few comments, most of which are editorial in nature.
Items (4) and (7) ff. should be of interest for the WG discussion. (The message is copied to the list therefore.) (1) Section 1, 2nd text paragraph -- typo | Today's practice generally seperates serving and resolving ... --- ^ | Today's practice generally separates serving and resolving ... ^ (2) Section 2.1 -- nit For clarity, I suggest to add a comma in the last sentence: v | [...] For resending the priming query to a different server, the random selection SHOULD also be used. (3) General (in particular Sections 3, 3.2, and 4) -- terminology/case I suggest to spell the established terms for the parts of DNS messages in headline case: Answer Section / Authority Section / Additional Section ^ ^ ^ ^ ^ ^ (4) Section 3.1 "Use of the Priming Response" The draft simply says: A resolver MAY use the priming response as it would use any other data fed to its cache. However, it SHOULD NOT use the SBELT information directly in any responses it hands out. After some consideration, this perhaps also means that the priming response SHOULD NOT be fed back into the SBELT -- which otherwise would be a possible option for use of the priming response. For clarity, I suggest to make that explicit in the text. Further, it might be useful to recommend [rate limited] logging of (or sending notifications to the resolver operator) the occurrence of changes in the priming response vs. the SBELT information, to give the resolver operator a trigger/opportunity to verify the changes and, if approved, update the SBELT configuration information (or the code of the resolver if it is compiled in) accordingly, for improved resilience in the future. (5) Section 3.2, 1st paragraph -- nit Again, for clarity, I suggest to add a comma in the 3rd sentence: [...]. To ensure equal | availability, the A and AAAA RRSets should have identical TTL values ^ at the authoritative source. [...] (6) Section 4, 2nd paragraph -- nit I recommend to insert "be" in the second sentence: vvvv | [...]. This can easily be achieved by making all root name servers authoritative for the zone containing the servers' names. (7) Section 4, 3rd paragraph -- ATTENTION to ROOT SERVER OPERATORS ! The draft says: [[At the time of writing, all but one root name server were authoritative for ROOT-SERVERS.NET., even though only a subset received an official delegation.]] For clarity: a) L.ROOT-SERVERS.NET is the single "one" root server not pretending to be authoritative for ROOT-SERVERS.NET. b) The subset that has received an official delegation consists of {A,F.J.K}.ROOT-SERVERS.NET. At the DNSOP session in Dublin (IETF 72), root server operators have indicated that in fact *all* root servers should be authoritative, via official delegation, for ROOT-SERVERS.NET., and they have indicated their intend to perform the necessary updates as soon as feasible; but these changes have not happened yet. I suggest to update the draft text accordingly and keep track of the changes to happen. (8) Section 4, 5th paragraph The draft says: [[Do the TTLs for the root NS RRSet and address RRSets in the root and the ROOT-SERVERS.NET. zones need to be aligned? In real life responses, the address RRSet's TTL values vary by implementation.]] Again, at IETF72 root server operators have indicated that indeed these TTL values SHOULD be aligned, and promised to take the necessary operational measures to ensure that in the future. I suggest to update the draft text accordingly. (9) Section 6 I recommend that the consensus of the root server operators indicated at IETF72 on the discussion items (7) and (8) above be submitted to the IANA for incorporation in their root server policy and guidelines. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: [EMAIL PROTECTED] | +------------------------+--------------------------------------------+ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop