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


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
CC: ietf-provreg@cafax.se
From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Tue, 10 Apr 2001 09:24:55 +0200
Sender: owner-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.

> BTW (and I hate to open this can of worms), there is no current requirement
> to associate contact information with name servers.

This was for demonstration purposes only. CORE has the ability to associate a
contact in its SRS, but the feature is rarely used AFAIK. So for me, you can
keep the can closed ;-)

> 
> <Scott/>


regards,

Klaus Malorny


___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0

Home | Date list | Subject list