Hi Matthijs,
On 7/1/25 10:23, Matthijs Mekking wrote:
I do have an issue with the flow of the document. I have to switch back and
forward for the recommendations in section 2 and the rationale in section 3.
Personally I think it makes the document hard to access.
Yes, we've thought about this, too. We ended up with this flow because one can
imagine that implementers would want the recommendations to be listed in one
place, so you can go gloss over them quickly to get an overview of what you'd
have to implement (if you wanted) etc.
I am an implementer ;)
:-) I know. I meant implementers that mainly want to implement the
recommendations, once published (as opposed to participating in the development
of the recommendations).
But ...
I would like to know the rationale for a given recommendation. Understanding
why usually makes things easier to do.
... I get it. I've shuffled things around as you suggested.
If you want the recommendations in one place you could also do that by
summarizing them in a separate section at the end.
I added a placeholder "Appendix B: Recommendations Overview" for that.
The same condition should not be reported unnecessarily frequently to
the same recipient (e.g., no more than twice in a row). For example,
when CDS and CDNSKEY records are inconsistent and prevent DS
initialization, the registrant may be notified twice. Additional
notifications may be sent with some back-off mechanism (in increasing
intervals).
The history of DS updates should be kept and, together with the
currently active configuration, be made accessible to the registrant
(or their designated party) through the customer portal available for
domain management.
This looks like two recommendations that are in the wrong section (although I
think it is better to group the rationale and recommendation together per
subject).
The first one describes a general property of the reporting mechanism, so where should it
go if not into the "Reporting" section?
As for the second, it's not really reporting (so, indeed a bad fit), but I'm not sure
where else it would fit. I'll rename the section to "Reporting and
Transparency".
I thought one of your goals was to list all recommendations in one place? These are
outside the "Overview of Recommendations" section.
So at least the flow of the document (listing recommendations together vs
grouping rationale with recommendation) is inconsistent.
The bug here (in my view) is not the order of things, but the fact that the analysis section
contains something that looks like a new recommendation. They should mainly contain justification,
which may read like "and for this reason, one should do it this way". (That's why the
"should"s there were lowercase.)
The content of these "should"s, however, was intended to be re-stated in the
recommendations themselves, so that the analysis sections add no additional
recommendations.
Apparently, that didn't work out as intended. Let's see how people will
perceive it with the new flow.
Diff:
https://github.com/desec-io/draft-shetho-dnsop-ds-automation/commit/836962b601b3aa101ab42c0986d568a5da221f72
Best,
Peter
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
