Perfect. My DISCUSS is cleared. -MSK
On Tue, Jan 7, 2025 at 5:52 AM Gavin Brown <gavin.br...@icann.org> wrote: > Hi Murray, > > > On 19 Dec 2024, at 22:25, Murray S. Kucherawy <superu...@gmail.com> > wrote: > > > > On Thu, Dec 19, 2024 at 5:02 AM Gavin Brown <gavin.br...@icann.org> > wrote: > > 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". > > > > I think that's a fine use of SHOULD. What I'm suggesting is that we > might want to add a phrase or sentence that gives an example of when you > might anticipate one might knowingly disregard a TTL. > > > > BCP 14 says basically "SHOULD means MUST unless you really know what > you're doing", and it's often helpful to include a bit of prose to help the > implementer meet that bar. > > I will add a sentence at the end of the paragraph as follows: > > EPP servers which implement this extension SHOULD use the values provided > by EPP clients for the TTL values of records published in the DNS for > domain and (if supported) host objects. ***Servers MAY disregard these > values in order to address security and stability issues, as described in > Section 5 and Section 6.*** > > This will be in the version that will be published momentarily. > > 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
