Apologies for the delay in responding Gavin, I was sure I had already sent this (but have been proven very wrong): > That was not discussed explicitly. The document describes a policy > discovery mechanism (see Section 2.1.1.2) which allows clients to learnt > the min/default/max values, but it does not provide a way to discover > if/when a server might reset a non-default value. > > EPP would not be particularly well-suited to provide this information, as > the audience for such information would be much wider than just EPP client > operators. However, the RDAP extension (see draft-brown-rdap-ttl-extension, > which I plan to bring to regext once this document is published) does > provide a way for a registry to publish its policy in a way that is > discoverable for all interested parties, not just those who can connect to > its EPP server. I suspect that's the best you're going to do, yes. I do think it would be important for some sort of policy to be published to avoid surprises, but I understand (and agree) that EPP may not be the right place to return policy statements. > Policy changes will almost certainly only happen infrequently, and the > omission was intentional on my point. Do you feel it warrants some > discussion in the document? I think inserting a warning note would be helpful to the reader. Something along the lines of "Although a client is requesting a particular TTL value that is within the current acceptable range, registries are not obligated to maintain that value indefinitely and may change the value when, for example, they update their acceptable TTL value ranges." I think the rest of the discussion is resolved, so I won't re-quote that here. -- Wes Hardaker USC/ISI -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
