Thanks Hugo – I appreciate the wording suggestion, and will incorporate it (and
an acknowledgement) into the next version.
One comment on the idea of separate TTLs: this would probably require that the
extension support multiple <ttl> elements, something like this:
<ttl:infData>
<ttl:secs for=”NS”>3600</ttl:secs>
<ttl:secs for=”DS”>3600</ttl:secs>
</ttl:infData>
This is because using syntax like <ttl:secs rrtype=”NS|A|AAAA”> would make the
TTL ambiguous for the RR types not listed: it would be better to explicitly
list the TTL values for each RR type.
G.
From: Hugo Salgado <hsalg...@nic.cl>
Date: Thursday, 9 March 2023 at 16:54
To: Gavin Brown <gavin.br...@centralnic.com>
Cc: regext@ietf.org <regext@ietf.org>
Subject: Re: [regext] FW: New Version Notification for
draft-regext-brown-epp-ttl-04.txt
Thank you very much Gavin. I understand your point. I know that we are very few
ccTLDs that use attributes for hosts, and we could live with the restriction
that prevents the use of distinct TTLs (in fact, I am not sure if we could, we
would!) ;) However, the same technique I'm proposing to glues-as-attribute
could also be used for decoupling the NS and DS records. In the case of a
rollover it is not necessary to reduce the TTL of the NS, only of the DS. One
might want different values for the two. And using a technique like an rrtype
attribute on the ttl:infData element would allow it. But anyway, if that's the
group decision (once adopted), I think that we should still include that
reasoning in the document for "protocol completeness". Something like: 4.1. Use
of TTL values in delegation records EPP servers which implement this extension
SHOULD use the values provided by EPP clients for the TTL values of NS and DS
records published in the DNS for domain objects, and A and AAAA records
published in the DNS for host objects. *In case of a registry that utilizes
hosts as attributes of a domain object (section 1.1 of RFC5731), the A and AAAA
records can't be individually defined and SHOULD use the same TTL of the domain
object that contains them.* Thanks! Hugo On 16:59 08/03, Gavin Brown wrote: >
Hi Hugo, > > I’ll be honest and admit that I hadn’t considered servers that use
the host attribute model, so I appreciate your feedback. > > My (probably quite
prejudiced) view is that if an EPP server uses the host attribute model, then a
TTL value set for a domain should also apply to in-bailiwick hosts that are
attributes of that object. Almost by definition, if a host is merely an
attribute of a domain, then it should not have additional properties that can
be specified: if that is needed, it should be an object instead. > > I’m not
clear on what proportion of EPP servers use the host attribute model (my
anecdata is that the object model is nearly universal in the gTLD world but the
attribute/nsset models are more common in ccTLDs), so I’m also unclear on
whether the extra work to support the host attribute model is justified. > >
I’d welcome some raising of hands for operators of host attribute servers who
would implement this extension if it was modified to accommodate them! > > G. >
> From: Hugo Salgado > Date: Thursday, 2 March 2023 at 14:46 > To: Gavin Brown
> Cc: regext@ietf.org > Subject: Re: [regext] FW: New Version Notification for
draft-regext-brown-epp-ttl-04.txt > Hi Gavin! It seems to me that there is a
case of use that is not being considered, when the NS and their glues are
defined as an attribute of the domain object, without having a host object. If
we consider a create command with a domain object like the example 1.1 in
RFC5731: ns1.example.net 192.0.2.2 1080:0:0:0:8:800:200C:417A ns2.example.net
then the ttl extension can't differentiate between a TTL for the NS RRset and
TTLs for the A/AAAA RR glue records. If we want to allow different TTLs to be
delivered for nameservers and glues, an attribute could be added for the
ttl:infData element such as "rrtype=NS|A|AAAA". Thanks, Hugo >
_______________________________________________ > regext mailing list >
regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
