[DNSOP] Re: Andy Newton's Discuss on draft-ietf-dnsop-cds-consistency-09: (with DISCUSS and COMMENT)

[Andy Newton <[e-mail]>]

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