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/>