Hi Stéphane, James beats me for an extensive review of your draft.
Here are some of my points however: * I agree on your specific goal of just DNAME and its specific semantic (however you can have other records besides DNAME for a specific QNAME, like RRSIG. RFC6672 §6.1 has a clear example of DNAME+MX) but of course as soon as we add one RR through EPP, as James stated there is the question about all others. There is even already an extension for that. It had URN http://www.verisign.com/epp/zoneMgt-1.0 and I have the code implementing it in my client, but I do not find it anymore on Verisign website. * I would like to see more explanations on what happens if a registrar adds a DNAME on an existing domain name that have in-bailiwick nameservers and hence glues in registry zonefile. Should the change be forbidden (until the registrar removes the nameserver objects) or just the glues just be removed? Then should the nameserver object be deleted too automatically? * Also what happens if the DNAME target is internal to the registry (same TLD)? Should the registry check the domain exists? What if the target has a DNAME record too? * about transfers: you say in your new revision that the transfer may fail if the new registrar does not support DNAME delegation. How would the registry know that beforehand? Clearly outside of the protocol definition, but does that mean there will be a need of specific list of registrars supporting that or not, and a specific "accreditation" I fear this can very soon go into the same rabbit-hole as the case of DNSSEC enabled transfers, and then you have only answers like the keepDS solution in frnic extension, or something along the standard keyRelay extension. * I have mixed feelings about section 10. Specifically you state: A trust relationship MUST exist between the EPP client and server, and provisioning of DNAME delegation MUST only be done after the identities of both parties have been confirmed using a strong authentication mechanism. Does that mean that provisions in RFC5734 (specifically section 8) are not enough to provide that? Otherwise why restating that here? * On issue #3 and the issue of feature discoverability per domain, I do not think the EPP check command is appropriate for that. The DNAME record is not an object per se in the registry data model and hence no operations would apply to it. It would seem wrong to update the domain:check to signal this. I fear right now the best way is for a registrar to just try its create/update and mandate that the registry has a clear error essage in its answer if DNAME is not supported (unfortunately there is no way to extend the protool in that direction -- coincidently I was about to send a draft related to handling of error codes). It could however be a separate and specific other endeavour (auto-discovery of features/capabilities on a fine grained level, per registry object). * On issue #5 I would prefer it stays with EPP terminology, so update+chg (not set) nodes. * On issue #6 I feel it not necessary for the client to explicitely signal it wants the info back for the following reasons: - I expect the use of this feature to be very low, both per registry and per domain inside a registry (but would love to have more data points or wishlists expressed by actors if you have some - you give only RFC7535 as an example and I doubt that AS112 project would hany kind of public domain nam registry attached to it soon) - if this element is present, it is minor in the reply and do not create parsing problems (specifically since its presence is dependant on the login being done with the extension) - I can not really imagine multiple versions of your extension in the wild at the same time (James/you speak about -01 vs -02), do you have a specific idea in mind? If you really want to signal no data in all cases, you can also reply with an empty dNameTarget (but I am not sure it is useful: in the same way for a DNSSEC enabled domain, if there as no DS/DNSKEY records attached to it then you do not get the extension in the domain:info and everything is fine, and the client does not specify anything in its domain:info command) HTH, -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
