Hi Wes, On 2/9/26 23:24, Wes Hardaker wrote:
So this is "too late" and thus can be disregarded if desired, but here's some comments you may or may want to consider while still working on it:
Thanks a lot for your thorough review! Much appreciated, and still time to take it into account. The below changes have been committed in https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/231650c18a175ccdf0bd30c23162d05b25eeec97, and will be uploaded as a new revision on Friday unless you have additional feedback.
- Overall, this is a well crafted document. Nice work!
Thanks.
- intro: "not egation" is a type -- you probably have caught this by now
Right.
- intro: suggest: s/questions arise/questions arise which this document addresses/
The next paragraph continues with the problem statement, and it seems premature here to close this train of thought by announcing answers in the midst of the problem statement. However, I understand that "questions" beg for answers, so the current phrasing is not good. I've updated as follows: OLD [...] Additionally, when using the RRR model (as is common amongst top-level domains), both the registrar and the registry can effect parent-side changes to the delegation. In such a situation, additional questions arise. NEW [...] Additionally, when using the RRR model (as is common amongst top-level domains), both the registrar and the registry can effect parent-side changes to the delegation. In such a situation, additional opportunities for implementation differences arise.
- intro: I think the document is doing more than "minimiz[ing] user surprise". It's preventing problems if the advice is followed too.
Good point, addressed as follows. OLD New deployments of DS automation therefore SHOULD follow the recommendations set out in this document, to achieve a more uniform treatment across suffixes and to minimize user surprise. [...] NEW New deployments of DS automation therefore SHOULD follow the recommendations set out in this document, both to achieve a more uniform treatment across suffixes — minimizing user surprise — and to prevent disruption of DNS and DNSSEC functionality. [...]
- 2.2 but also in general: an example diagram and scenario might be helpful for the reader to better understand the somewhat complex timing of potential events.
Hmm, I'm not sure which timing of events you mean. If you'd like to, feel free to elaborate further. Otherwise, as this suggestion hasn't been raised before by anyone, my impression is that it's probably fine as is.
- 3.1, bullet 1: In general most of your bullets don't require reading the analysis -- this is an exception. Why not list the DS updates specifically here rather than (normatively) require reading the follow on section?
There are multiple reasons that's not spelled out explicitly in the recommendation itself. One is that who should receive reports is highly circumstantial (for example, success reports go to the registrar *if* the registry does the automation, but error reports go to the child DNS operator etc -- it would be very long and complex to include this in the recommendation). For ccTLDs, communication preferences depend on the agreements that the parent has with the registrant (a point requested explicitly during document development), and so on and so forth. Several other recommendations are not self-contained either, as they reference other documents for details. I think it's fine in this case to reference that section for details.
- 3.1, bullet 2: s/first notified/notified first/ (slightly more normal phrasing)
Fixed.
- 5.1, bullet 3: s/SHOULD be suspended,/SHOULD be suspended until a non-empty DS record set has been provisioned/ (they may get this from the next bullet, but it's better to be clear here (IMHO))
Fair; fixed.
- 5.2.3: I wonder if there is a case (IE, I haven't plotted all the cases out on my whiteboard yet) where a resolver switches to an old DS because of a disconnected authoritative server causes it to, then the primary removes the old key and the resolver can no longer switch back to the properly administrated authoritative server? I'm not sure you can follow that, and I'm not yet sure it's a real problem :-/ Documenting my brain storming though...
I think that can happen; it's an example of a misstep due to replication issues during rollover. There are many flavors of that (even independently of the particular concurrency issue described in 5.2.3). For example, the section on error reporting originally had the following text: OLD A delegation can break even without an update request to the DS record set. This may occur during key rollovers ([RFC6781], Section 4.1) when the Child DNS operator proceeds to the next step early, without verifying that the delegation's DS RRset is in the expected state. For example, when an algorithm rollover is performed and the old signing algorithm is removed from the Child zone before the new DS record is added, validation errors may result. This paragraph was removed in response to the following feedback: ------ earlier feedback ------ This feels a bit hypothetical, perhaps even a bit fearmongering. The key rollover processes described in RFC 6781 clearly say that the child have to wait until the DS RRset has been updated before continuing. So I don't understand why this is used as an example here. You might as well say "this may occur because there was a bug". ------ /earlier feedback ------ (from https://mailarchive.ietf.org/arch/msg/dnsop/5jVEyldeIuPOFu917_2A9V2jnuE/) Including your example could be equally criticized, so I'm unsure what consensus text to put in. The sentence "No disruptive consequences are expected" is trying to cover the uncertainty (because expectations may be violated), but I agree that it might be too ambiguous/implicit. If you have an idea how to improve this, I'd appreciate your text suggestion; otherwise I'll assume you're OK as is, and will submit a new revision with the other changes on Friday.
- 5.2.3, last sentence: I wouldn't say that only the parent view is within scope of the document. Certainly you're considering the child timing in this, and it's been crafted to minimize the impact as much as possible. So I'd say something like "and thus cannot be handled with only parent-side changes" rather saying "it's out of scope". Mostly a tone issue.
Done! Best, Peter _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
