Hi Andy,
On 11/19/25 16:21, Andy Newton wrote:
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.
This indeed captures the intent well. I've made the following adjustment (also
reflected in the author-tools diff circulated earlier):
OLD
removing it from consideration. A configurable retry schedule with
exponential back-off is RECOMMENDED (e.g., after 5, 10, 20, 40, ...
minutes). To sidestep localized ...
NEW
removing it from consideration. A configurable retry schedule is
RECOMMENDED to increase the likelihood of collecting data from all
nameservers. An exponential back-off schedule (e.g., 5, 10, 20, 40,
... minutes) provides a balance between faster task completion while
accommodating transient unreachability. To sidestep ...
OLD
process, repeating all queries (suggested default: enabled). A
schedule with exponential back-off is RECOMMENDED.
NEW
process, repeating all queries (suggested default: enabled with
exponential back-off).
I believe this addresses all open issues.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
