Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt

"Gould, James" <jgould@verisign.com> Fri, 18 November 2022 14:24 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11397C14CE35 for <regext@ietfa.amsl.com>; Fri, 18 Nov 2022 06:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.994
X-Spam-Level:
X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjkyKFR5GG-Q for <regext@ietfa.amsl.com>; Fri, 18 Nov 2022 06:24:21 -0800 (PST)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B9DC14CE20 for <regext@ietf.org>; Fri, 18 Nov 2022 06:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=36194; q=dns/txt; s=VRSN; t=1668781462; h=from:to:subject:date:message-id:mime-version; bh=A20UhLBFaX7a9ldse0rvA5j/A+xcKVLKwUYzx29yTek=; b=LNzzn4NwGyFOTrVqrhuLiOJX3RyZZkwaaJ7HEeVit4F8wQrvIRfgGYYO AmfMlrP7/9DD/uE8bzMlp/9jwd5vwboGd/2jw5zz8o1TrLxlJoQu4Eynw 05vrk0mms4o1y5dpDpwhXXKX0awVJunoOX/yA1HjgqccubAuDESCRPFhe vqYikhadY/QeKucnZOKLyqhNtrzR57aZieHSj2KdRakYAaptr4NV+Doqj ZpnbWDqnIN8xKCzhU1o+YPkkfNSjhXDhAubiFb4Q27dQAh5CDli9bl3Zx M40q4dJ7OrDDX9qSz8IqKlQakiYUY4vumjeVg+dNZ+3k7rfPEfXkja+rr A==;
IronPort-Data: A9a23:YBMsW6JvlU9wVHZ5FE+RCZQlxSXFcZb7ZxGr2PjLsTEN7Y4Qp2xan zVKWWmHJL/UNVJBSKl/O9i2phkEuJDczYVmGlM++SE3EH5EpZLIXtrAfhehbn7DcJzORRs5s ZtBYdObJpBkEHLWrRzxaOG4/HJ3hfzYLlaQ5I8oHwgoLeMzYHt40E4Ld5cFv7NVbfiF7yKlt d74rZWOYVSogWB+bGlN5ayP9E8/saj+tW0S4QVnbKwX5Q+PnHQrV59OfqvZw1kU4GV3NrXjG 7ucluHREkfxpUpF5gaNy+6jGqEyaueOe1LI0hK6YoD66jBavCs+z60nA/QVbEZTml2hkst4o Dl3ncXYpTwBY+udxozxbzECS3skZPQfqOedSZSCmZf7I3PuIiOEL8pGURle0b0woo5fHWxI/ PoEHzEBBjjrazWeme/TpkFE36zPHeGzVG8tkigIIQLxVJ7Kdav+r5Divre06h9r35wTQqyOD yYuQWEHgBzoO3WjM39JUM5uxL/AanPXK1W0o3rNzUY7DvS6IKWcH9EBPfKMEuFmS/m5kW6eu nLi+HqhXSpDd+y2mGuc2WmPvsn2yHaTtII6TNVU99ZAunvK+Uo+OEVPE0WwpuOhzEeyHcxFM EpS8S0rxUQw3BXzCICiBFvh/SXC4k50t9l4SoXW7CmPxa3J5wqxGGUeTyVAZ9pgv8gzLdAv/ gbWzoixXm0x2FGTYXSc9qzEvyH1AyU2Ik8QeXEjfVYKxuC29enfiTqKFL6PCpWdgdTrGDe2y SqNsy4WjLgVkdQC06O69hbMhDfEjoLEQQMl+i3WU36rqARja+aYi5eA40LdtOlGIZbBFxyao mJCnsmFqeoJS5uXknXLXv8WGvei4PPt3CDgvGOD1qIJr1yFk0NPt6gJiN2iDC+F6vo5RAI=
IronPort-HdrOrdr: A9a23:sxrl56nzP3NZLzV/kHLJFEp0OOzpDfIc3DAbv31ZSRFFG/Fwz/ re/8jzpiWE6gr5OUtQ4OxoV5PgfZqxz/RICOoqTM+ftWvd2FdARbsKheDfKlbbdxEWg9Qy6U 4WScdD4bPLYGSSxvyKhTVQW+xQpOVuusqT9IDjJllWPGdXV50=
X-IronPort-AV: E=Sophos;i="5.96,174,1665460800"; d="png'150?scan'150,208,217,150";a="17930396"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Fri, 18 Nov 2022 09:24:19 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2507.016; Fri, 18 Nov 2022 09:24:19 -0500
From: "Gould, James" <jgould@verisign.com>
To: "gavin.brown@centralnic.com" <gavin.brown@centralnic.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt
Thread-Index: AQHY+1lyd5Ar5cNn6kOAYHaMCiWmAQ==
Date: Fri, 18 Nov 2022 14:24:19 +0000
Message-ID: <3961C607-C4EA-4C4C-9269-FE55C98B4ECA@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.66.22101101
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_3961C607C4EA4C4C9269FE55C98B4ECAverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Zokv3x8AMKsvFrOdOUjbr8nUqoE>
Subject: Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2022 14:24:26 -0000

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
jgould@Verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <regext-bounces@ietf.org> on behalf of Gavin Brown <gavin.brown@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-drafts@ietf.org<mailto:internet-drafts@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.brown@centralnic.com<mailto:gavin.brown@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>