Stephane, Thanks for posting the draft for review. The following is my initial feedback:
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? a. DNAME could be one of the supported RR types. b. If new resource record types can be managed by the registry, do we need to create an EPP extension for each one? 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. 2. It would be best to reference eppcom:labelType for the dnameTarget element instead of a string. One issue with the eppcom:labelType is that it has a minimum length of 1, so an empty element cannot be used to remove it. The dnameDeleg schema could define its own labelType that sets the minimum length to 0. 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> or <dnameDeleg:update> <dnameDeleg:delete/> </dnameDelete:update> 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. 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. If it were explicit, then the case of no data would need to be handled. One option is to support a <dnameDeleg:infData> element in the extension of the info response that includes the <dnameDeleg:dnameTarget> element if it’s set. i. One advantage to the explicit approach is that it’s clear which version of dnameDeleg is desired if there are multiple supported versions (e.g., urn:ietf:params:xml:ns:dnameDeleg-0.1, urn:ietf:params:xml:ns:dnameDeleg-0.2); otherwise the server would need to choose the highest version supported by the client based on the client’s login services. 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. 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. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/5/18, 6:10 AM, "regext on behalf of Stephane Bortzmeyer" <regext-boun...@ietf.org on behalf of bortzme...@nic.fr> wrote: On Sun, Nov 12, 2017 at 09:00:06PM +0800, Stephane Bortzmeyer <bortzme...@nic.fr> wrote a message of 19 lines which said: > we could imagine a registry accepting registrations implemented as a > DNAME record, not NS records. > > Would it make sense to create an extension (may be an addition to RFC > 5731) to allow these "DNAME registrations"? > > I'll be at the meeting tomorrow, if you prefer to discuss it AFK. After the discussion in Singapore, here is the draft. Comments and criticisms are welcome. https://datatracker.ietf.org/doc/draft-bortzmeyer-regext-epp-dname/ _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
