Re: EPP host renames

Seth,

If you're going to support host objects versus host attributes, I believe you should support the ability to rename a host.  With host objects you would need to use a surrogate key instead of a natural key.  You could opt for using the host attribute approach defined in RFC 5731 if you don't want to treat hosts as true objects.

--

JG

[cid:3FCD7C20-5001-4760-9319-D2E3F24263E9]

James Gould
Principal Software Engineer
[email protected]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



From: Seth Goldman <[email protected]<mailto:[email protected]>>
Date: Wednesday, December 19, 2012 12:18 PM
To: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: [provreg] EPP host renames

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<http://ns1.example.com></host:name>
  <host:chg>
    <host:name>ns2.example.com<http://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<http://tools.ietf.org/html/rfc5732#page-15>, 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