Re: Issues on 3.4.9 Object Information Query

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

At 10:02 AM +0200 4/11/01, Klaus Malorny wrote:
>Just think of the following "conversation":
>
>   Client: delete domain blabla.tld
>   Server: deletion denied. Object still in use.
>
>and now? What are you doing now in the case that *you* think that the domain
>is *not* in use? Do you want to pay for the domain until you get a database
>dump end of next month or quarter revealing the problem?
>
>I don't know whether it is possible for a different registrar to register a
>name server below a certain domain (I know it's not possible under NSI's
>system, and it is always a pain -- sorry Scott). If so, situations with
>unknown references could easily appear.

As Scott has pointed out, this particular situation is handled by EPP 
already.  That's a protocol discussion as opposed to a requirements 
discussion, however, so I'll make a different argument.

There's no doubt that when you get such a result, you need a way to 
find the relationships.  We all agree to that.  However, given the 
high transactional volumes that we may see in provreg environments, 
it is inappropriate to try to deliver potentially large relationship 
reports through the same channel actually used for provisioning.

An analogy, albeit somewhat strained:  you work for a large company 
with 5000 phone lines.  If you want to add a new phone line or change 
the services associated with a particular line, you probably call 
them on the phone and explain their needs to one of their 
representatives.  That's provisioning.  If you want a list of all 
your phone lines and what services are associated with each, you 
don't want them to read you a list, but you would like them to fax or 
mail you a report.  That's reporting.  These two functions *could* 
technically be handled over the same channel, but it's better if you 
have well-optimized ways to handle the different needs.

>
>  > I think you may under-appreciate just how much this functionality may
>>  increase processing time and message size.  We (register.com) have
>>  about three million domain names on our name servers.  Right now,
>>  there's only a few hundred thousand on any given name server, but our
>>  goal is to get them all on the same set of name servers.  I know that
>>  other organizations have very large numbers of domain names
>>  associated with individual name servers; likewise, there are some
>>  contacts associated with many domains.  Do we really want to be
>>  returning data sets of this size through a provisioning protocol?  We
>>  need a way to get information on object associations, but it doesn't
>>  belong in provreg.
>>
>
>As I mentioned above, I don't underestimate it. Although it is not a nice way
>to solve the problem, there is still the possibility to truncate the output to
>a reasonable size. Some databases even have extensions to SQL to limit the
>number of reported rows. So there is always a solution.

I was actually going to use the line of argument above to prove my 
point in my first e-mail, but I knew that someone would make it for 
me if I waited.

If you're conceding that sometimes the data set is too large to be 
reasonably transmitted through provreg, then you're conceding the 
need for a separate reporting mechanism.  If we need a separate 
reporting mechanism anyway, why not just use that for reporting 
functions and not clutter up the provreg protocol and implementations 
with this extra clutter?

Jordyn