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
