RE: Handling of External Host Objects (in the context of domain t ransfer)

["Gould, James" <JGould@verisign.com>]

Hong,

	I've dealt with this issue, it is more straight forward than what
you have described.  To address your question of  "why registrar A can avoid
> massive update on all 1267 domains at the EPP protocol level", is because
> the host name should not be the foreign key from the domains in the
> Registry database.  Changing a host name (external to external, external
> to internal, internal to external) should not change the database
> relationships.  The changing of name servers in RRP does not require
> explicit or implicit updates to the delegating domains, and this is also
> the case with EPP.  This is truly an implementation issue and not a
> protocol issue.  Implementation of the registry database and associated
> business rules can accomplish the intent of the protocol without impacting
> registrars.  
> 
As far as domain transfers are related to external hosts, additional
validation checks can be built into the registry to ensure that the
requesting registrar has the appropriate external hosts on a transfer
request, transfer approve, or transfer auto-approve.  If the appropriate
external hosts exist at the time of a transfer approve or transfer
auto-approve, than the registry can update the external host references from
the domain at the same time the pendingTransfer status is removed and the
sponsoring registrar is changed.   If the appropriate external hosts do not
exist, than the transfer request, transfer approve or transfer auto-approve
will fail.  The EPP poll messages can be used to keep both the sponsoring
and requesting registrars informed throughout the transfer process.  

Jim

> ----------
> From: 	Liu, Hong
> Sent: 	Tuesday, October 29, 2002 8:09 PM
> To: 	'ietf-provreg@cafax.se'
> Subject: 	Re: Handling of External Host Objects (in the context of
> domain t ransfer) 
> 
> Hi, Asbjorn,
> 
> Thanks for discussing this topic. This is my response to your posting [1].
> For some reason, I did not get the posting directly from the mailer. I
> just
> found that out by looking throught the mail archive. The following
> presenation is somewhat awkward since I have to quote your email.
> 
> Quote:
> "I don't understand the first part here, why would the losing registrar
> need
> to delete the link to the external host before transfer? He would only
> need
> to go to the new registrar and create the external host there (if it is
> not
> already there), request the transfer, and the domain would automagically
> swap to "using" the newly created external host when the transfer is
> completed. The domain will resolve during the whole process."
> Answer:
> The paragraph I quoted from epp domain mapping is the following:
> "DNS domains can be delegated to external hosts. If a domain has been
> delegated to an external host, a client MUST have created a host object
> for
> each delegation to an external host before requesting a domain transfer. A
> transfer request or approval MUST fail with EPP error code 2305 if host
> objects representing the external hosts are not managed by the requesting
> client at the time a transfer request is made and at the time the transfer
> request is approved."
> So in my previous email, 2(a) is the result of the last sentence, while
> 2(b)
> is the restatement of the second sentence. The main problem is with 2(a).
> What is your read on the last sentence above?
> Quote:
> "The problem with this is that when registrar A in the (for example)
> dotInfo
> registry later wants to rename his host ns1.example.com to for example
> ns1.example.info (i.e., moving it into the zone), he would have to first
> create the new host, and then update all the 1267 domains using
> ns1.example.com to use the new host. This is not a problem in the current
> solution. "
> Answer:
> Yes, this can be inconvenient, but with good reasons. If this is the only
> problem, then I believe the benefits of the single copy solution far
> outweights the multi-copy one.
>  First and foremost, I would like you to explain why registrar A can avoid
> massive update on all 1267 domains at the EPP protocol level  (not at the
> registry DB level). Host objects are associated with domains via the <ns>
> element, and the value of that element is the host name. Are you saying
> that
> the 1267 domains using ns1.example.com as a nameserver do not need to be
> changed to ns1.example.info in the corresponding <ns> field, while the
> host
> object ns1.example.com is renamed to ns1.example.info? 
> Note that we are talking about explicit client-initiated operations, not
> implicit registry server operations. Scott has said many times on this
> list
> that implicit server operations are bad, and I agree. I don't think that
> renaming an external host should implicitly trigger the registry server to
> update all the domains using that host as nameserver.
> Most importantly, renaming a host object (internal or external) while it
> is
> linked with other domains is a _very bad_ idea since doing so creates all
> sorts of inconsistency problems for domains that reference the host
> object.
> Host objects are identified externally by hostnames in EPP. Changing a
> hostname is equivalent to creating another object, since the external
> handle
> of the object has changed. 
> I would not go as far to ban such operation in EPP, but the best common
> practice should RECOMMEND NOT DOING SO.
> --Hong
> 
> [1] http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00102.html
> 
>