Hi Gavin, Am 20.10.23 um 14:23 schrieb Gavin Brown:
[PK2] in this particular example not, however feasibility of EPP implementation would require indeed an extension to set such RRs. This is not a point however. My point is more about NS, which would in this setup be not existing - utilizing what is already in RFC5731 that domain:ns is optional. I think this specification should not imply ns mandatory narrowing down the usage of RFC5731.Hi Pawel,On 19 Oct 2023, at 06:04, Pawel Kowalik<kowa...@denic.de> wrote: Hi Gavin, Am 18.10.23 um 13:57 schrieb Gavin Brown:Question on 2.2 <ttl:NS> element. Why is this element not OPTIONAL? What am I overseeing by thinking it should be optional, as is with the other elements within de domain object?Because a delegation doesn't exist if no NS records are present. If no NS records are present then no other record types will be present. Therefore, the NS element is mandatory.[PK] There are registries allowing creation of RRs directly in the TLD zone without delegation, so this extension should not limit such usage. The rules as you mentioned should be or are already implied by the registries based on their policies and implementation out of different reason than this ttl specification imho.Are such registries using RFCs 5731 and 5732, which are the object mappings that this specification extends? If not, I think it is therefore unlikely to be of much use to them anyway, and is not a use case that needs to be considered.
The logical consequence of not restricting the RR types that TTL values can be set for is (a) a more complex specification, since it would need a normative reference to RFC6895 and revised XML syntax so that the RRtype becomes an element or attribute value, and (b) more complex server implementation, which would be redundant for the vast majority of implementers.
[PK2] I don't mind leaving specification of RRs TTLs which are outside of RFC5731 to be a part of the extension, so no request to assure such provisions in this draft. The only concern is the mandatory NSwhich should be rather optional.
Kind Regards, Pawel
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
