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: Monday, April 09, 2001 9:43 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se
>Subject: Re: Issues on 3.4.9 Object Information Query
>
>
>"Hollenbeck, Scott" wrote:
>> 
>>> [...]
>> 
>> Good suggestions, but I'm not sure I understand the 
>distinction between the
>> suggested new requirements.  What does [0] say that [5] doesn't?  I'm
>> inclined to add [5], but I'm not sure I see the need for [0] 
>if we add [5].
>> 
>> <Scott/>
>
>
>Hi Scott,
>
>let me explain: we have a domain that references name servers 
>and contacts.
>Name servers eventually reference contacts, too. But name 
>servers may also
>contain implicit references to the domain they belong to.
>
>e.g.
>
>  domain X.COM    ->  owner A
>                  ->  admin B
>                  ->  tech  C
>                  ->  ns1 NS.Y.DE     ->  tech C
>                  ->  ns2 NS.Z.COM    ->  tech D
>                                     (->) domain Z.COM
>
>
>
>In 3.4.9[1], the registry will surely report the contacts and name servers,
>and in 3.4.9[2] the registry will report the contacts, if any.
>
>Subsection [0] was thought to generalize that a bit. In the case of ns2,
not
>only tech "D" should be reported, but also domain "Z.COM". This may be
trivial
>for humans, but not necessarily for machines (esp. in a more complex domain
>structure, e.g. in the anticipated .name TLD or those with different
>registration levels, e.g. .fr).

I still don't get it.  As far as I know DNS machines do not have any trouble
understanding that "ns.z.com" and "z.com" are related.

>With "reverse references" I mean the ability to detected the uses of a
certain
>object. In the given example, the service would report "NS.Y.DE" and
"X.COM"
>as objects referencing contact "D". Similar to that, a request to domain
>"Z.COM" would report "NS.Z.COM". This function is important to detect
>"orphaned" objects or to analyse a failed deletion request.
>
>Implicit references are important to be reported if the outcome of
operations
>depends on it. If the domain "Z.COM" can be removed while keeping the name
>server "NS.Z.COM" in the database, I don't have any problems if the
reference
>is not reported -- but not in the case that it can't be removed.

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 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.  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).

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

<Scott/>