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 <hsalg...@nic.cl> > Date: Thursday, 2 March 2023 at 14:46 > 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 > 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
signature.asc
Description: PGP signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
