On Fri, Jan 05, 2018 at 03:46:28PM +0000, Gould, James <jgo...@verisign.com> wrote a message of 72 lines which said:
> Thanks for posting the draft for review. And thanks for the detailed review. > The following is my initial feedback: Most of it has been incorporated <https://framagit.org/bortzmeyer/ietf-epp-dname/commit/4be3162973bc5d64ad78a38e38a08d31d31bc4c4> and will appear in -01. However: > 1. If the registry starts accepting more resource record types in > addition to or as an alternative to the existing record types, why > not define a more generic RR extension that allows for the CRUD of > the RR associated with a domain name? Clearly, this is out-of-scope for me. The goal of this document is not to allow arbitrary DNS Resource record types (such as TXT or LOC). Such a mapping would allow the EPP server to implement a "delegation-less" registry, letting the client add A, AAAA, etc records. It would require more complexity, with the various RR formats, and the ability to add, update and remove individual records (RFC 5910 style) Instead, I keep the idea that the EPP server registers only delegations, either through NS records or, as here, a DNAME record. This keeps the mapping much simpler. > a. DNAME could be one of the supported RR types. DNAME, like NS, is special. It cannot coexist with other records, for instance. > c. It would be up to server policy which RR types are supported. A > RR policy extension of the Registry Mapping could be leveraged to > define the RR types supported by the server along with any RR > restrictions. Nice idea but clearly much more work. For someone braver than me :-) > 2. It would be best to reference eppcom:labelType for the > dnameTarget element instead of a string. Great. Done. > 3. It may be best to make the setting or removing of the dname explicit in > the extension to the update command, as in the following > <dnameDeleg:update> > <dnameDeleg:set>foo.bar.example</dnameDeleg> > </dnameDeleg:update> I hesitate. More advices welcome (see <https://framagit.org/bortzmeyer/ietf-epp-dname/issues/5>) > 4. I assume that return of the dnameDeleg extension in the info > response would be based on the existence of the dnameDeleg data, > server policy, and support of the client for dnameDeleg based on the > EPP login services provided by the client. Yes (-00 did not mention the EPP login services. Added.) > a. An alternative to leveraging the EPP login services of the > client, is to extend the EPP info command with an empty element like > <dnameDeleg:info/> to explicitly specify the inclusion of the > dnameDeleg extension in the response. https://framagit.org/bortzmeyer/ietf-epp-dname/issues/6 > 5. For issue #3 listed at > https://framagit.org/bortzmeyer/ietf-epp-dname/issues, I believe the > client can determine support for DNAME via the services returned in > the EPP greeting by the server. No, because it is only the general support by the server, not the fact it is accepted for all domain names. 1) A server may handle two TLD, with different policies 2) A server may allow DNAME for a given subdomain (say, gov.example) but not for other names. So, the EPP greeting is necessary but not sufficient. > 6. One additional complexity is how to handle transfers when the > gaining registrar does not support dnameDeleg. There are other > mechanisms to determine the state of the transferred domain (e.g., > DNS, reports), but the gaining registrar will simply not be able to > get or set the dname via EPP until they support dnameDeleg. Documented. (The obvious solution is for the transfer to fail. Note that RFC 5910 is silent about that.) _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
