RE: Object associations.

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

Roger,

The general topic of a query mechanism to do reverse-association lookups has
indeed been covered in the past.  I'd provide a pointer to archived messages
but I didn't see anything obvious with a quick glance.

I've argued that broad query mechanisms are out of place in a provisioning
protocol.  The kind of query that you've described below, when used (for
example) to return all of the delegations to a name server or all of the
domains associated with a contact, can literally return millions of records.
There are other ways to provide this info, such as via offline reporting
services, without adding search and lookup facilities to a provisioning
protocol.

More below...

-Scott- 

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:castillo@nic.mx]
> Sent: Monday, February 18, 2002 7:39 PM
> To: ietf-provreg@cafax.se
> Subject: Object associations.
> 
> 
> I don't know if this has been issued before, but I checked in 
> the cafax history
> and I couldn't find anything about it.
> 
> In the reqs. document
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-re
> qs-05.txt
> we can read as folows:
> 
> 3.4.9 Object Information Query
> 
>    [4] The protocol MUST provide services to identify all associated
>    object references, such as name servers associated with domains
>    (including delegations and hierarchical relationships) and contacts
>    associated with domains.  This information MUST be visible if the
>    object associations have an impact on the success or failure of
>    protocol operations.
> 
> Now, as we can read in the host mappings.
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
> we can find this:
> 
> 2.3 Status Values
> 
> linked
> 
>    The host object has at least one active association with another
>    object, such as a domain object.  Servers SHOULD provide 
> services to
>    determine existing object associations.
> 
> 3.2.2 EPP <delete> Command
> 
>    A host name object MUST NOT be deleted if the host object is
>    associated with any other object.  For example, if the 
> host object is
>    associated with a domain object, the host object MUST NOT 
> be deleted
>    until the existing association has been broken.
> 
> 
> ..............................
> 
> The service for identifying all associated object references 
> is a MUST in 
> the protocol reqs.
> 
> There isn't  any problem with the domain object as pointed in 
> 3.4.9 [4].
> The information about object associations for a domain object 
> MUST be given 
> to authorized clients,
> and that's how it's described in the domain object mappings.
> 
> This service is NOT described in the host mappings.
> How can a client query the registry to look for all the 
> object associations 
> for one of his sponsored host objects ?
> Looks like the protocol spec is not fulfilling the 
> requirements for this 
> service.

As you noted, one can determine the contact and host objects associated with
a domain object by doing an <info> command on the domain.  One can also find
out that a contact or host object is linked to a domain object (but they
can't get a list of specific domain object(s)) by doing an <info> command on
the contact or host object.  I wrote the requirement and interpret it to
mean that the protocol MUST provide information describing attribute
associations, as in "this is an object and these are the attributes of that
object".  The "linked" status flag in the host and contact mappings lets the
client know that an association exists (which in my interpretation meets the
requirement as it identifies a reference) without introducing the
possibility of having to return a potentially very large result set.  As
described above, this sort of reverse-lookup service is best provided by
som3ething other than a provisioning protocol.

> Now, let's assume we offer the service to the clients.
> The number of associations for a host object could be a few 
> hundreds, and 
> in some cases a few hundreds of thousands.

In at least one name space I'm familiar with the number would be much higher
in some common cases.  Some registrars offer hosting services where their
servers and contacts are used for EVERY domain they register.

> Has anyone given a little tough about this ? Maybe those who 
> are working on 
> implementations.
> How can we interpret and apply this considerations of de reqs. to the 
> object mappings for hosts ?
> 
> Perhaps we can add an <host:assoc> child element to the 
> server response to 
> the <info> command
> to show the number of active associations for the host object.
> 
> 
> The same considerations can be made for the contact objetc and its 
> associations with domain objetcts.
> 
> In the contact object mappings, we can read in 3.2.2 EPP 
> <delete> Command, 
> that a server SHOULD notify
> clients of object relationships when a <delete> command is 
> attempted and 
> fails due to existing object relationships.
> 
> How can a client verify that the contact object he wants to delete no 
> longer has any active relationship ?

Yep, it's been thought about, it's in the archives somewhere.

One possibility: when a <delete> command fails due to an existing
association, the client should receive an error message explaining that the
delete fails because of an existing association.  A service message should
also be created and enqueued as described in the specs.  It's quite possible
for the server to create a service message that lists the active
associations rather than including them in every <info> response.  In many
cases the number of associations might be small enough to "fit" in the
message, and where size becomes an issue the service message could point the
client to an offline reporting service where the associations can be
determined.

-Scott-