Hi Gavin,
On 18.11.2022 12:42, Gavin Brown wrote:
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.
some minor editorial comments.
* In Section 1 there is a dangling bracket "However, in
some circumstances it may be] desirable"
* In Section 2 the "a" should be removed "This specification defines a
two new elements"
Other comments:
* In Section 4.2 you write "However, if no TTL value is configured for a
subordinate host object, but a TTL value is configured for the
superordinate domain object, then the domain object's TTL value
SHOULD be used for the host object instead of the default TTL value."
I'm not so knowledgeable in resolver caching details, but this makes me
wonder, whether you could influence other domains in this way.
Say domain
a.example defines a TTL of 604800 (7 days) and
b.example defines a TTL of 600 (10 minutes).
Both domains use a name server ns1.c.example
Then, depending on whether I ask for a.example or b.example I get
different TTLs for the same A/AAAA record of ns1.c.example. I don't know
whether this actually could cause issues, but at least it looks strange
to me. Wouldn't it be better to only allow the sponsor of the host
ns1.c.example be able to define the TTL of its address records? After
all only that sponsor is actually able to change the IP and might
therefore be interested in adjusting the TTL for all domains using the
name server.
* In Section 4.3 you talk about IDN variants. There a different ways to
deal with variants in TLDs. In our registry software TANGO, there is the
possibility to have variants-as-attributes (in which case you suggestion
makes sense). However, it's also possible to have variants-as-objects,
in which case every variant (though to some extent linked to all other
variants) is separate first-class domain object with an independent
life-cycle. In that case it might also make sense for those variants to
define different TTLs, in particular if they were allowed to have
different name server hosts (which currently is not the case for TLDs
run by TANGO, but is theoretically possible).
I would therefore prefer a SHOULD rather than a MUST.
* In Section 6.1 you suggest to have a maximum duration of TTL values
depending on the TTL value itself, e.g., a 2 minute TTL can only be set
for at most one hour. While the idea is understandable (not to have very
short TTLs for a long duration), it's not really prohibiting it. On the
contrary, if someone really wants to keep the low TTL "forever", it
means they have to send an EPP update command every hour for each of
their domains in order to reset the value to their liking.
Cheers,
Michael
--
____________________________________________________________________
| |
| knipp | Knipp Medien und Kommunikation GmbH
------- Technologiepark
Martin-Schmeisser-Weg 9
44227 Dortmund
Germany
Dipl.-Informatiker Fon: +49 231 9703-0
Fax: +49 231 9703-200
Dr. Michael Bauland SIP: [email protected]
Software Development E-mail: [email protected]
Register Court:
Amtsgericht Dortmund, HRB 13728
Chief Executive Officers:
Dietmar Knipp, Elmar Knipp
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
