Re: problems with info command

["Jordyn A. Buchanan" <jordyn@register.com>]

At 4:43 PM -0400 8/7/01, Sheer El-Showk wrote:
>First, the mandatory inclusion of sub-ordinate hosts, on which there is
>no specified limit for a domain, means that a domain query will be that
>much more expensive of a command.  Each info command will now have to
>determine a second set of relations and return an arbitrarily large
>data set.  From an implementation perspective it seems like a much better
>idea to provide an option (as in the transfer command) specifying which
>kind of nameserver's should be displayed along with the domain -- subordinate
>or delegate.

This isn't a bad idea.

>Second, the ability of non-owning registrars to query each others registry
>objects strikes me as a very serious performance concern.  Registrars can
>now start treating the registry database like a whois database and data
>mining it.  I've heard arguments that this is a good thing since the
>registrars are a controlled community with controlled access, but I don't
>think this is valid.  First, registrars allow resellers automated access
>to their systems and resellers are not a controlled community.  Second, this
>offloads whois work onto the core registry database and attempts to make
>the latter serve as the former.  However, the two systems exist in in very
>different operating environments.  The whois systems have the luxury of lazy
>sychronization, simplistic load-balancing, and are primarily read-only.
>The core registry database, however is very expensive/difficult to
>load-balance and must bear the burden of write and read locking (I'm not
>being database specific -- this is a operational limitation of any kind of
>database serving as a registry canonical store).  Essentially there can be
>at most a few instances of a registry database and it is extremely
>expensive to synchronize them, while it is trivial to replicate whois
>databases.

Technically, there's nothing to prevent a registry from offloading 
info commands into a separate database that is well-optimized for 
that purpose instead of taxing the central read-write database.  A 
bit of added intelligence to your EPP servers to select the 
appropriate database for the appropriate instance, some one-way data 
synchronization, and voila!

I'm not sure what the alternative is to the info command.  As Scott 
mentioned, registry policy will dictate whether or not other 
registrars will be able to use the info command for objects they 
don't sponsor.  Another idea would be for registries to change the 
set of information that is returned by the infor command for 
non-sponsoring registrars.  For example, it might be desirable to 
return the 'delegate' name servers for a domain and its sponsoring 
registrar.  I agree that we don't want this command to become a 
replacement for Whois, but I think it's complicated enough for 
registrars to put together comparable data to Whois output that 
they'll just use Whois instead.

Jordyn