Hi Murray, responses below. > On 19 Dec 2024, at 07:03, Murray Kucherawy via Datatracker <nore...@ietf.org> > wrote: > > [snip] > > I believe the SHOULD in Section 3.1 is misused. What interoperability concern > is it addressing? It also appears to be a normative constraint while > simultaneously specifying nothing at all. But maybe I'm missing something > here, and I'm happy to be set straight.
The SHOULD here establishes the need for server operators to decide on a policy. Without it, implementers may feel that they have to accept whatever the client sends them, which could cause security and stability issues, such as those discussed in Sections 5 & 6. > For the SHOULDs in Section 3.2, what are the implications of deviating from > this advice? Is there ever a legitimate reason to do so? A server may need to disregard the provided TTL values in order to address security and stability issues. So "MUST" is not appropriate, because (to quote RFC 2119) there may exist valid reasons in particular circumstances to ignore those values. But a normative keyword is needed to establish the expectation that client-provided TTLs will be honoured by the server. "SHOULD" seems appropriate because it's stronger than "MAY" but weaker than "MUST". G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
