RE: Issues on 3.4.9 Object Information Query

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

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Thursday, April 12, 2001 5:36 AM
>To: Hollenbeck, Scott
>Cc: Jordyn A. Buchanan; ietf-provreg@cafax.se
>Subject: Re: Issues on 3.4.9 Object Information Query
>
>
>"Hollenbeck, Scott" 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?
>> 
>> Ahh, but the problem will be immediately obvious given the requirement to
>> explicitly identify the *.blabla.tld name servers in the response to a
>> general object information query.  The client who wants to delete the
domain
>> can determine exactly which other objects are involved by doing an info
>> query on the domain object.
>> 
>> <Scott/>
>
>Yes, exactly. This is all I want. But not only for domains, but for other
>object types, too. I assume that a contact or a name server cannot be
deleted
>if it is used by a domain. So the domains need to be reported.

I understand, and I am not disputing that there is a need for this
information.  We are disagreeing on the reporting/delivery method.

VeriSign (then NSI Registry) actually implemented this sort of
reverse-relationship query service via the NSI RRP in the early days of the
SRS test bed.  Requesting information about a name server would include a
list of all domains delegated to the server.  It quickly became clear to us
(with only six registrars) that this service was unworkable via the protocol
due to serious server-side memory management and DB performance
requirements, and we were working with the best commercial hardware and
software available at the time.

I still believe that a different query protocol or offline reporting
services is the most efficient way to provide the potentially large volume
of information associated with contact and name server relational queries.
However, if part of the problem is that it's not obvious when object
relationships exist, would it be an acceptable compromise to make it
completely obvious that there are existing object relationships?  For
example, if a name server query returned the number of domain delegations,
or a contact query returned the number of object associations, or if each
had some kind of status value that indicated active associations?  Each
option would provide explicit notice that there are relationships to be
undone, eliminating the uncertainty before attempting a delete operation.

<Scott/>