Re: EPP host renames
Francisco Obispo <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
Hi Seth, Even if this is not used as often as it should, you're going to find yourself in a situation where you will need to support it in order to be RFC compliant. If you decide not to implement it, you risk getting yourself in an extended evaluation, which you may not want. Francisco On Dec 19, 2012, at 9:18 AM, Seth Goldman <[email protected]> wrote: > Hi all, > > For those who are not aware, Google is becoming a registry with the launch of the new gTLDs, and so we are currently building out our shared registry service. I had a technical question that I hoped that the members of this list could shed some light on. > > Do registrars generally use or depend on the being able to do host renames via EPP? That is, something like this: > > ... > <host:update ...> > <host:name>ns1.example.com</host:name> > <host:chg> > <host:name>ns2.example.com</host:name> > </host:chg> > </host:update> > ... > > I can see how this could be useful to a registrar if they were renaming their default nameserver, but it's a pain to implement if you're not using a fully normalized RDBMS (which we're not). It also prevents us from using the fully qualified host name as the primary key for host objects. > > Is it horrible to not support this particular scenario, and instead ask registrars to do a delete-add of the new host, and then individually update their referencing domains? From my reading of the RFC, registrars must be able to support this scenario anyway, since external hosts could be referenced by domains sponsored by a different registrar: > > Host name changes can have an impact on associated objects that refer to the host object. A host name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. The change can be provisioned by creating a new external host with a new name and any needed new attributes, and subsequently updating the other objects sponsored by the client. > > Seth > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo Director of Applications and Services - ISC email: [email protected] Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg