In telechat preparation, the side-by-side diff from -09 is here: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-dnsop-cds-consistency-09&url_2=https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/draft-ietf-dnsop-cds-consistency-10.txt
Hi Andy, Thank you very much for your review, and discuss points! Please see below. On 11/18/25 21:23, Andy Newton via Datatracker wrote:
Andy Newton has entered the following ballot position for draft-ietf-dnsop-cds-consistency-09: Discuss
[...]> ----------------------------------------------------------------------
DISCUSS: ----------------------------------------------------------------------
[...]> ### BCP 14 Language
See the [IESG statement on BCP14 language](https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/). Would these RECOMMENDS be better with explanations? Or if there is no further advice to give, would making these non-normative be a good solution? 204 .. A configurable retry schedule with 205 exponential back-off is RECOMMENDED (e.g., after 5, 10, 20, 40, ... 206 minutes). ... 218 ... A 219 schedule with exponential back-off is RECOMMENDED.
My impression is that this recommendation has (obvious) technical merit. Not following it typically will not be technically justified; rather, implementing a back-off scheme requires introducing state, which may cost a few days of work (depending on a system's architecture), and thus is a cost. In other words, I think that a the main reason to not follow this will be a business consideration. OTOH, I think we can hardly write "... is RECOMMENDED unless your boss thinks it's too expensive." OTOH, I have a hard time seeing how the situation is improved by getting rid of the RECOMMENDation. So, I'm at a loss here, and will be happy to follow any guidance. My personal view though it that it's OK as is.
In this case, what happens if queries are not continued? Is this a lowercase "may" or should an explanation be provided about what happens if an implementation does not follow the advice. 225 in which case nothing needs to happen. Queries MAY be continued 226 across all nameservers for reporting purposes.
You are correct, this is better lowercased. I've made the change locally, for upload after the telechat.
In the paragraph below, "(reachable) nameservers" in a MUST sentence appears to be softening the requirement to the level of RECOMMENDED. If there is a firm requirement that nameservers be reachable, then that should be stated clearly. "(reachable)" is again used on lines 244, 268, and 283. 234 To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust 235 maintenance, the Parental Agent, knowing both the Child zone name and 236 its NS hostnames, MUST ascertain that queries are made against all 237 (reachable) nameservers listed in the Child's delegation from the 238 Parent, and ensure that each key referenced in any of the received 239 answers is also referenced in all other received responses, or that 240 responses consistently indicate a request for removal of the entire 241 DS RRset ([RFC8078], Section 6). I see that the paragraph at line 201 discusses reachability, but IMO it is still not clear that an implementation MUST accomodate for it as consideration of reachability is a SHOULD: 201 When a response cannot be obtained from a given nameserver, the 202 Parental Agent SHOULD attempt to obtain it at a later time, before 203 concluding that the nameserver is permanently unreachable and 204 removing it from consideration. ... If reachability is implementation dependent, should that not be stated?
Yes and no. Queries are actually made against all nameservers, also the unreachable ones, because that's how you learn about reachability in the first place. This is what you MUST do. The SHOULD is about attempting retries, not about the requirement to query all servers. The "(reachable)" was intended to improve readability, as one might wonder "why does it say all? Didn't it say elsewhere one can ignore unreachable servers?". But indeed, it is imprecise. I now realized that the notion that unreachable servers don't matter is already captured by the text, as the consistency requirement is specified across "received responses" only. It's thus fine to remove the "(reachable)" from the sentences about CDS/CDNSKEY/CSYNC queries. I've made the corresponding changes, and also the following related fix (for upload after the telechat): OLD Further, when retrieving the data record sets as indicated in the CSYNC record (such as NS or A/AAAA records), the Parental Agent MUST ascertain that all queries are made against all (reachable) nameservers listed in the delegation, and ensure that all return responses with equal rdata sets (including all empty). NEW Further, when retrieving the data record sets as indicated in the CSYNC record (such as NS or A/AAAA records), the Parental Agent MUST ascertain that all queries are made against all nameservers from which a CSYNC record was received, and ensure that all return responses with equal rdata sets (including all empty).
---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ## Nits ### Network Vantage Point Maybe this is minor, but "network vantage point" is more specificly descriptive. 206 ... To sidestep localized routing issues, the Parental Agent 207 MAY also attempt contacting the nameserver from another vantage 208 point.
Good point; I've made the change locally, for upload after the telechat. The diff with the changes from this message is here: https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/commit/e239d01a0aa077e4aa1f20b2455d81e1c0412dc6#diff-d3398566f77572362e657e31e035a0effbe92148ba122be28de37a177732f318 Best, Peter _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
