RE: problems with info command

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Sheer,

Both of the points you raised below have been discussed on the list in the
past, though the option you mentioned in your first point is new.  Adding
such options appears to be a good idea.

The second point touches on something that is _not_ currently a required
feature of the protocol.  There are already words in the base spec that say
something like "queries SHOULD be limited to the sponsoring client", and
those words are there because some folks thought that we should let
registries decide how they wish to deal with cross-client info queries.

If folks think we should instead explicitly prohibit cross-client queries
again (as the initial versions of the specs did), please voice your support
for Sheer's suggestion.

<Scott/>

>-----Original Message-----
>From: Sheer El-Showk [mailto:sheer@saraf.com]
>Sent: Tuesday, August 07, 2001 4:43 PM
>To: ietf-provreg@cafax.se
>Subject: problems with info command
>
>
>Hi,
>
>I think the current EPP "info" command has several 
>shortcomings that will
>have significant bearing on performance (especially considering it is
>likeley to be the second most popular command after "check").
>
>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.
>
>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.
>
>regards,
>Sheer
>