On 11/19/25 11:01 AM, Peter Thomassen wrote: > 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.
That works for me. Thanks for your patience, Peter. Much appreciated. -andy _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
