[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Klaus Malorny'" <Klaus.Malorny@knipp.de>
Cc: ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tue, 10 Apr 2001 08:43:06 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Issues on 3.4.9 Object Information Query

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Tuesday, April 10, 2001 3:25 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se
>Subject: Re: Issues on 3.4.9 Object Information Query
>
>
>"Hollenbeck, Scott" wrote:
>> 
>> OK, now I think I understand, and I think this is something that the WG
>> needs to chew on for a bit because it gets close to a topic that I raised
in
>> the protocol design team report: does it make sense for a provisioning
>> protocol to provide abstract relationship reporting services?
>
>I think it does.
>> 
>> I submit that it's not a good idea for a _provisioning_ protocol to
provide
>> a query service to (as an example) list all of the domains delegated to a
>> particular name server, or all of the domains for which I happen to be a
>> contact.
>
>This function is very useful for maintenance, database synchronisation,
error
>detection etc. as I mentioned earlier. I agree that this function should
not
>be a "standard" function, i.e., the normal query should not report the
reverse
>references, as a name server may be used by thousands of domains and this
>would increase processing time and message size. It should be done either
as
>an option or as a separate request.
>
>> We already have requirements to identify object associations
>> (3.4.9-[1], for example, says that contacts and subordinate "child" name
>> servers have to be reported when retrieving information about a domain).
>> 
>
>Yes, but let us distinguish the directions of the references (compare to
the
>directions of the arrows in the example). Normal queries would only report
>references that point away. On special request, also those references are
>reported that point to the object itself.

Another way to deal with the maintenance etc. issues is via offline
reporting, which may provide a more flexible and DB-friendly way to extract
the potentially large volumes of information that may be involved in these
object relationships.

<Scott/>

Home | Date list | Subject list