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

[Rick Wilhelm <[e-mail]>]

Gavin,

Sorry it’s taken me a while to get to this, but I wanted to actually read the new version of the draft rather than just make comments based on email traffic, heh.

Regarding the notion of the client providing a <ttl:until>, I’d echo Jim’s comment below regarding a preference to having the values be fully in client control.  (I think that the mechanism he suggested is reasonable, fwiw.)  That is, I would prefer that this mechanism be dropped or at least made optional.

Here’s the rationale for my position:

At the heart of it, given the extension, the TTL can now be considered client-controlled data (albeit with a default value).  And in EPP, the server (to my knowledge) doesn’t change client-controlled data without it being a result of a direct client command.

The <ttl:until> “timer” would do that.

I think that the rationale for avoiding this mechanism is that it

  *   Simplifies server implementation
     *   No need for timers, scheduling, retry of failed timer firing, failed TTL update, etc.
  *   Insulates clients from server-side changes that induce indeterminacy as to state (aka “action at a distance”)
     *   Avoids the need to include a poll mechanism for either successful or failed time expiry
  *   Avoids a number of challenging future situations regarding inter-registrar transfers (when one registrar implements the extension and another doesn’t)
  *   Avoids challenging operational situations when the registry goes under maintenance (what happens to the timers that would fire during maintenance?)

Net-net, when I was a registrar, maintaining the accuracy of my (client-side) view of the registry (server-side) objects was paramount to the registrar system’s sanity.  Having a situation where the server may or may not follow through on its (alleged) promise to change a TTL would seem to me like just asking for an invocation of Murphy’s Law.

Rather:  If we are to do this, it seems better to let the client be fully in control of any departure from default TTL.  Better than splitting control between the client and the server.

For what it’s worth, I had originally thought that an approach like this (I called it a “spring-loaded TTL”) was something worth pursuing.  But after considering the failure (aka “rainy day”) scenarios and the way that it subtly breaks the client-server agreement by changing client data outside of a direct command, I changed my mind.

Maybe there’s another angle I’m missing…

Thanks
Rick



From: regext <[e-mail]> on behalf of Gould, James <jgould=[e-mail]>
Date: Friday, November 18, 2022 at 2:24 PM
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt
CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.
________________________________
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
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com<https://protect-us.mimecast.com/s/CJ7IC31PzwsXlvoCg7vsD?domain=verisigninc.com/>

From: regext <[e-mail]> on behalf of Gavin Brown <[e-mail]>
Date: Friday, November 18, 2022 at 6:43 AM
To: "[e-mail]" <[e-mail]>
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: [e-mail]<mailto:[e-mail]>
Subject: New Version Notification for draft-regext-brown-epp-ttl-03.txt
Date: 16 November 2022 at 16:12:04 GMT
To: "Gavin Brown" <[e-mail]<mailto:[e-mail]>>


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://protect-us.mimecast.com/s/FPGyC5yXBLFM713UyPanh?domain=secure-web.cisco.com>
Status:         https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/<https://protect-us.mimecast.com/s/gq4dC732EXizKY2cq-1br?domain=secure-web.cisco.com>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl<https://protect-us.mimecast.com/s/amcEC9rPJgHzXjAc0rMPk?domain=secure-web.cisco.com>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-regext-brown-epp-ttl-03<https://protect-us.mimecast.com/s/omJgCgJNR2fqRJKCyL8-D?domain=secure-web.cisco.com>

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://protect-us.mimecast.com/s/kOWnCkRNY7ikjvAUyB3gX?domain=secure-web.cisco.com>

Cal: https://cnic.link/gbcalendar<https://protect-us.mimecast.com/s/gpTfClYNZ7C18lmfD5B4R?domain=cnic.link>

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://protect-us.mimecast.com/s/l-dGCn5j2OfX2VgC1XKG6?domain=secure-web.cisco.com>