Gavin, How about providing the feature for the client to unset the custom TTL via an empty <ttl:secs/> element instead of adding a new <ttl:util> element that would require the server to manage the expiry? This way the client is in complete control over exactly when the custom TTL value is in place. The ability to set and unset a temporary value with a client-managed timer would follow the pattern followed with the Secure Authorization Information for Transfer RFC. Additionally, if there is the concept of a default TTL defined by the server and a custom TTL that can be set and unset by the client, then it could be covered in the draft and be explicitly defined in the protocol. For example, in the info response, does how does the server indicate that the default TTL is being used? The Registry Fee Extension RFC had a similar use case of identifying standard fees versus non-standard fees, where an optional “standard” attribute was used with a default value of “0” (or “false”). My recommendation is to follow a similar pattern for the TTL. The result would be formally defining the concept of a default TTL and a custom TTL that can be set and unset by the client using the extension, which can be indicated explicitly by both the client and the server. The <ttl:secs> element could include the “standard” attribute for the create and update with a default value of “0” (or “false”), since unsetting would be handled only via the use of an empty <ttl:secs standard=”true”/> value and setting a custom value would be either <ttl:sec standard=”false”>3600</ttl:sec> or <ttl:sec>3600</ttl:sec>. Now the question is what the server does when the custom TTL matches the standard TTL, should it accept it and keep the standard setting to “false”, since in theory the server default could change. My recommendation is to have the server accept it and identify it as a client set custom TTL. The <ttl:secs> element can also include a “standard” attribute for the info response to explicit indicate whether the standard TTL or the custom TTL is being used, where most of the cases the “standard” attribute would be set to “1” (or “true”).
-- JG [cid:image001.png@01D8FB2F.88941370] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Gavin Brown <gavin.br...@centralnic.com> Date: Friday, November 18, 2022 at 6:43 AM To: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt Hi all, A couple of days ago I uploaded a new version draft-regext-brown-epp-ttl. This version adds a new extension element, <ttl:until>, which specifies the date and time after which a "custom" TTL should revert to the default. Feedback welcome - I am hoping the WG will be able to pick this document up in the near future. Gavin. Begin forwarded message: From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Subject: New Version Notification for draft-regext-brown-epp-ttl-03.txt Date: 16 November 2022 at 16:12:04 GMT To: "Gavin Brown" <gavin.br...@centralnic.com<mailto:gavin.br...@centralnic.com>> A new version of I-D, draft-regext-brown-epp-ttl-03.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-regext-brown-epp-ttl Revision: 03 Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values Document date: 2022-11-16 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-regext-brown-epp-ttl-03.txt<https://secure-web.cisco.com/1jqSy98z4kS3VYmlytob1HAwtnkOBsBLsgf6eN-kGqXI9eH08degKAZe1nArjPioeD1jMZLp1suYI8D2N71AyHm1lS5hRQ2zWgJWhQh4nIFh8_IrrlWvus2P9SSyniE5rMwRJ844n2nzfeBqZ1tUAQgnJ7OTUKFISJYUvjP_Ywf52OP9vIMdrHjONbNrfNh2vUMur0fIPi3zpUVlbjYO5itCF61ldvp5vWldp0UXeTHPL97AaZ_l65bhmN2xbpIvPWH4NZ6QhMEIkow6FKM53V5bLfIhOoapBni18riST34g/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-regext-brown-epp-ttl-03.txt> Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/<https://secure-web.cisco.com/1EDp86Ikg8aUbBIpfPFOWABruowJig5QE6ZV5sGI7DmsuB8TW-Z0G83miDY50o4K_ZL_YFwl-SAaAL409VtdE9u2YCliPWlJxPGELJQdnh9PwKDoZZiPXqGvs4HRmCJ5D_dFbpucUXSqbDyYzGL7yP7ZWEtFpZfpfh5Or0mnCotccjtnFu_xXrkWalS4ny9fq7-crOrO5uR1xnNfQ1sqPcU7W_crWfoW7g3QHdDcpflGifU0biCRAYdZwmq0xdzRU9VKy4kH2U-sShnWVsczp3_kRHQ_YSNeCXQ80BktsXVY/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-regext-brown-epp-ttl%2F> Htmlized: https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl<https://secure-web.cisco.com/1PJtQEmrQ_87mt0Mkd1Qxa6sM2HcbwI518nafy4bzfQeKyZ8hMN1seVnNQK-mo496ztm6w65IKx1Yy8L7bixhHqNqZp1EaUNlNNnMGAVm5o5v9nKN3mOCWyZawo0rLoT3ZdKx87TPCbUSTv2lUWzits_VXnlI4_vMPA_eOPJYwYvTPL3s7Wg3USMtXIaMVYN2El7iCiePUGR3zEcd74Orr4Yi9cj2ldTSDtU0FQ0V-4Wr2Vzwr2ngEH7JFlAolf_EULyiOdiLB04eciuYWQu_JlnTTxeKhUZh87aI9H0sdis/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-regext-brown-epp-ttl> Diff: https://www.ietf.org/rfcdiff?url2=draft-regext-brown-epp-ttl-03<https://secure-web.cisco.com/1Nv-2RuSsDuE04kJv4zuz4ZOMRE7wbXoBnQ-na1mmpHlYcGwWVu7xJR4p0-NU4ctWFqYxuXg97W47QCcUJJJKoyIA1AcKcBJDBsK7uJN2HW_axhqEXJ0iFO7AxKlXd0E0drQzPqi6enyxJltFhcQhj8KtjRT_os-7mKAH0c1PK9aBW5-yDUnvg3mSWLvtqiMPpL5xTKKrdSjG4II_mgtq09qkiZoZ8W8mtbfSKaZX1meiumxZonNHlWZ4M-jEBpERrKqc3Nn9_Ubq8fz9qkjUcqU0DbHyC8xnpNdMlpVeW1s/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-regext-brown-epp-ttl-03> Abstract: This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. The IETF Secretariat -- Gavin Brown CentralNic Group plc (LSE:CNIC) https://centralnicregistry.com<https://secure-web.cisco.com/1h1fX0Yzmctf2PzS4yddC5HtluaeiPnpIwfZdKAo_6eEjv8-344t_CoirUzwfGpJESLQP66dc7Al6k5fnLDojuKBsfuk4fyeHOyEbSUHQ_VisOW841AdhMl93_hfxhPLzN6LKMh36Pbq6JeNCvSswJpoQs90MopC09C2e7Nn56UQ4OEn12pEFf0iG6pfbGoPFXUX_7TpryjMly4EBYXS5gxyc-gQmX5vBDNKWbcuNYky1jghdAjA8xyu0f07v-oKCqnTwSMCJHvWl-fOWm0FEWWOh4zdyKFo2jnVeLI0MMJg/https%3A%2F%2Fcentralnicregistry.com> Cal: https://cnic.link/gbcalendar CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR. https://www.centralnic.com<https://secure-web.cisco.com/1f10jMAYeOiE7w6D6atOlC13nvsTZrHMmbh4H_dNtTg1Hi0nVEPHjwZwTW6_qQ0zj85C7qVybmuW-5lqWbiYvlqPGIAvJPSh9bBrjmM8jHkSI9Eb7soR5TheWwZLs2PV376nSPDGdwr9kCr59A_a6Y4IWYMZ49jCEOxyfkSODO37LG_fuWb_ymbAcs_N-SQRmr32rUjkEs4ufGl7hzpQxvcfpTGtUZnvQdQILDrbRKjplNlVaCde5vPBwTRxSN6_PWOkQ5ngtVhOEBpVI0LnINm80fykOcUa2x34rUqg2CgU/https%3A%2F%2Fwww.centralnic.com>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
