Re: [ietf-provreg] RE: Standards Track Advancement Request for EPPRFCs

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs

Patrik,

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.  
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.  
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?  

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.


-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.


> From: Patrik Fältström <paf@cisco.com>
> Date: Thu, 2 Apr 2009 14:31:52 -0400
> To: James Gould <jgould@verisign.com>
> Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chris.Newman@Sun.COM>, 
> EPP Provreg <ietf-provreg@cafax.se>
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP 
> RFCs
> 
> On 2 apr 2009, at 19.30, James Gould wrote:
> 
>> JG – You are referring to internal hosts that are subordinate to a  
>> domain in
>> the case of the host ns.foo.se and domain foo.se, but how do you  
>> handle
>> external hosts like ns.bar.net that is not subordinate to any domain  
>> in .se?
>> In our Registries, child hosts of a domain (ns.foo.se for foo.se)  
>> are also
>> transferred along with the domain and the sponsoring client must be  
>> the
>> same.  Since there is no parent domain for an external host  
>> (ns.bar.net in
>> .se) you can’t include the same type of validation.  The  
>> specification says
>> that “changing an external host object that has associations with  
>> objects
>> that are sponsored by a different client should result in a EPP  
>> error code
>> 2305”, which means that if one client references an external host  
>> sponsored
>> by a different client, that the host can not be changed.  Does this  
>> apply to
>> any change or just a change like changing the host name?  This  
>> statement
>> means for a Registry with many domains and external hosts, that  
>> there is
>> much more work required by the sponsoring client to create a new  
>> host and
>> update all of their domains that link to the host to reference the  
>> new host.
>> Implementing this represents a substantial change to the way that  
>> Registrars
>> manage external hosts, at least in our Registries, unless the first  
>> approach
>> is implemented where each client has it’s own list of external  
>> hosts.  The
>> .name Registry implements the first option.
> 
> .SE transfer the host object together with the domain it belongs to.  
> host objects outside of .se have no sponsoring clients.
> 
> That is the explanation (and there are no more words), and when  
> reverse engineering what has actually been implemented, I found that  
> the best I can do is to always try to create the host object when I  
> have some operation to do on a domain object, and more or less ignore  
> the error code...
> 
> Not fun, but there are tons of similar situations (regarding  
> validation of attribute values) that also lack documentation (and lack  
> of specification in the epp spec), so "to make things work", there is  
> a lot of "trial and error" in the actual algorithm implemented on top  
> of the epp protocol.
> 
>>> So what I call "cloning" is then something the gaining registrar have
>>> to do manually? Do you separate those changes of holder from a
>>> "normal" change of holder, i.e. restart the payment cycle etc? Do you
>>> keep track of the now two contact records be the "same" contact be
>>> represented by two records? You as registry that is.
>> 
>> JG -  Yes, if the Registrar wants to update the contact information  
>> linked
>> by the domain than they have to either request a transfer of the  
>> contacts or
>> manually create or reuse an existing contact record to link to the  
>> domain.
>> Updating the transferred domain to reference new contact data is  
>> handled in
>> the same way as any domain update.  There is no side effects  
>> associated with
>> billing, since the billable action was transferring the domain and the
>> contact information can be changed at any time.
> 
> In .SE there is a difference. Changing the holder do have legal  
> impact, and the registry require paperwork etc. So changing that  
> attribute value is a "special" operation. What is interesting though  
> is that .SE is themselves as registry cloning the holder and updates  
> the holderid when a transfer happens. That implies that if you track  
> domains in .SE, you will see a change of holder(-id) when a transfer  
> happens even though there was no change in holder. Yes, that implies  
> creation of many many many contact objects over time. Contacts have to  
> be deleted manually by the registrar.
> 
> I do not like it, but that is how they have implemented contacts.
> 
>     Patrik
>