Re: EPP host renames

Hi,

When we implemented Info and subsequent TLDs we used host objects but did not support the rename. We expected registrars to do create a new host object and update individual domains. We had many admonishments for this from registrars and did implement it for internal hosts later on.

Note more specifically, host objects were subordinate to the parent domain object  which was key to our approach for disallowing orphaned glue records. I'm not a big fan of the attribute approach.

Also, given the need to identify unique lifespans for the same domain string and hostnames ( a domain can have multiple lives) I would always use a permanently unique identifier as a primary key versus a fqdn or hostname.

Hope that helps!

Michael Young

M:647-289-1220

On 2012-12-19, at 13:18, "Gould, James" <[email protected]> wrote:

> 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
>  
> <82F8FEBC-E856-4D62-9857-D12B446CEFE8[53].png>
>  
> James Gould
> Principal Software Engineer
> [email protected]
>  
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
> 
> 
> 
> From: Seth Goldman <[email protected]>
> Date: Wednesday, December 19, 2012 12:18 PM
> To: EPP Provreg <[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</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

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg