Hi Jari, thanks for spending the time and doing this review. in response to the points you raise: 1. Jargon is just a constant factor in this space, and yes, the use of “CD bit” snuck in with either a reference to an explanation. I’ll uzse a reference to section 3.2.2 of RFC4035 2. your second point is because of an inadvertent admission of “or AAAA” in the second part - i.e. the responses are all the same as you had expected. the minor points are: the label in the table should probably use ‘Y’ and explain that means a “A or AAAA RRSET response” yes, “resolver_s_”! The final point I am not so convinced about. The reason is scope of the document. This document is an instruction to folk who write DNS recursive resolvers. It is not an instruction to folk who want to set up zones that could be used to test KSK trust status. I would rather avoid adding text about the latter topic in this document, as I strongly prefer to leave it to others who may be sufficiently motivated to write a document about how to set up a measurement zone. thanks, Geoff > On 30 Aug 2018, at 3:46 pm, Jari Arkko <jari.arkko@xxxxxxxxx> wrote: > > Reviewer: Jari Arkko > Review result: Ready with Issues > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dnsop-kskroll-sentinel-?? > Reviewer: Jari Arkko > Review Date: 2018-08-29 > IETF LC End Date: 2018-09-06 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document was easy to read, and I had no issues to raise. I believe the > test that it describes is useful and important for the DNSSEC operational > processes in the Internet. > > I did, however, have one question and one minor issue discussed below, and > several editorial observations. > > Major issues: > > Minor issues: > > The document says: > > If the validating resolver has a forwarding configuration, and uses > the CD bit on all forwarded queries, then this resolver is acting in > a manner that is identical to a standalone resolver. > > What does "using the CD bit" mean? Do you expect the bit to be set or not set? > Please clarify the language. > > The document says: > > nonV: A non-security-aware DNS resolver will respond with an A or > AAAA record response for "root-key-sentinel-is-ta", an A record > response for "root-key-sentinel-not-ta" and an A or AAAA RRset > response for the name that returns "bogus" validation status. > > I do not understand why an old, non-DNSSEC aware resolver would respond in > different ways to the -is-ta and -not-ta queries. But here you say an A record > response is returned for -not-ta but A or AAAA RRset response is returned for > -is-ta. What am I missing? > > Nits/editorial comments: > > Section 3 table lists "A" as responses, while the text talks about "A or RRset > response". Perhaps this could be aligned to avoid confusion. > > Section 4 title is "Sentinel Tests from Hosts with More than One Configured > Resolve". Shouldn't that be "... Resolvers"? > > The document did not clearly specify whether the names queried (including the > -is-ta and not-ta label) need to exist in the used domain, or if it is enough > for the domain itself to exist. Perhaps this could be clarified. > >
