On 19-11-2025 9:17 AM, Peter Thomassen wrote:
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.
Is a retry policy fundamental to this specification? And if so, is exponential
back-off the only type of retry policy that works? Neither is obvious to me.
If you want to leave it as RECOMMENDED, then there should be an explanation
about what happens if no retry policy or a different retry policy is
implemented.
This is just my opinion, but maybe some language such as:
A configurable retry schedule is RECOMMENDED to increase the likelihood of
collecting data from all nameservers. An exponential back-off schedule
provides the balance between faster task completion while accommodating less
transient operational problems.
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.
+1
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).
+1
----------------------------------------------------------------------
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.
+1
-andy, ART AD
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
