Re: RE: Standards Track Advancement Request for EPP RFCs

On 3 apr 2009, at 15.30, James Gould wrote:

> Interesting that there is another model that you're taking for  
> external
> hosts.  So to summarize, the following models exist for the  
> management of
> external hosts:
>
> 1. External hosts don’t have a sponsoring client, meaning once they  
> are
> created they can’t be modified.  This sounds like the model taken  
> by .se.

We should at the same time remember that they do not have to be  
modified.

> 2. Each Registrar has its own set of external hosts that can be
> independently managed by the Registrar.  This is what was defined in  
> an
> earlier version of the EPP, which was implemented by .name.

Ok

> 3. There is one set of external hosts for the Registry with the  
> client that
> created them as the sponsoring client.   The sponsoring client can  
> update
> the external host independent references to the host by domains.  The
> external host can not be deleted if it’s being used as a delegating  
> name
> server of a domain.  This is what is implemented in .com  and .net.
>
> Are there any other models implemented by Registries?

I can also envision you do not need host objects for external hosts.

> RFC 4932 sort of indicates that external hosts do have a sponsoring  
> client,
> so that could be a conflict with model #1.  RFC 4932 does not  
> prohibit model
> #2, but model #2 does not seem to be very popular with the  
> Registrars.  RFC
> 4932 has the verbiage “changing an external host object that has
> associations with objects that are sponsored by a different client.  
> 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 needed new attributes and  
> subsequently
> updating the other objects sponsored by the client.  This verbiage  
> really
> applies to model #3, but it doesn’t sound like any Registries  
> implementing
> model #3 have implemented to this verbiage.  Changing to this model  
> for .com
> and .net would have major issues with Registrars, since they don’t  
> seem to
> be a big fan of model #2 and a modified model #3 according to RFC 4932
> represents a huge management burden for changing external hosts.
>
> If there is an opportunity to change the wording, I would prefer to  
> change
> the MUST to a SHOULD in the RFC 4932 paragraph as shown below to  
> support
> existing implementations and to not require this behavior.
>
>> changing an external host object that has associations with objects  
>> that are
>> sponsored by a different client. Attempts to update such hosts  
>> directly SHOULD
>> fail with EPP error code 2305. The change can be provisioned by  
>> creating a new
>> external host with a new name and needed new attributes and  
>> subsequently
>> updating the other objects sponsored by the client.

    Patrik