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 <[email protected]> on behalf of Gould, James
<[email protected]>
Date: Friday, November 18, 2022 at 2:24 PM
To: [email protected] <[email protected]>, [email protected]
<[email protected]>
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:[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<https://protect-us.mimecast.com/s/CJ7IC31PzwsXlvoCg7vsD?domain=verisigninc.com/>
From: regext <[email protected]> on behalf of Gavin Brown
<[email protected]>
Date: Friday, November 18, 2022 at 6:43 AM
To: "[email protected]" <[email protected]>
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: [email protected]<mailto:[email protected]>
Subject: New Version Notification for draft-regext-brown-epp-ttl-03.txt
Date: 16 November 2022 at 16:12:04 GMT
To: "Gavin Brown"
<[email protected]<mailto:[email protected]>>
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>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
