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

[Patrik Fältström <paf@cisco.com>]

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

This is a digitally signed message part