[Ietf-not43] contact lookups: the elephant in my room

[william at elan.net]

I like to see unified search architecture, but as you say its not very 
practical at this point. But I do not want to see this eliminated as an 
option, what I'd like is to have minimum set of what needs to be implemented
(which would mean search only in one database being queried) by whois 
service but allow for extensions for these unified queries.

On this topic, the only easy way to do distributed search is to have 
unified index server. Potentially we could say that certain resources are 
"searchable" and provide for way have all referrals "share" their 
indices with upstream referrer, that means we have to have means to 
do something more as far as what referrer is then what is currently done, 
in particular when one server is putting referral to another it does not 
already know, it would need to "notify it" (potentially as part of "bag" 
on first referral) and they would need to "negotiate" index sharing. But 
we do also here get into some non-technical issues like "privacy" as well 
as many technical details. 
  The other way is to do distribute search is to potentially have each 
request spawn parallel queries in all servers that are known as referral 
to the one being queried. This may potentially mean quite a bit longer 
processing time and resources used for any query (resources not otherwise 
local to server originally queried). 
 If people are interested, I'd like to see if we can do it as some kind 
of extension to CRISP do distributed search (I like unified index 
architecture more), but I do not think this should be part of "Requirement".

> I'm trying to figure out exactly what kind of search-by-email needs to be
> supported in the LDAP-WHOIS spec. draft-ietf-crisp-requirements-04.txt
> requires the following:
> 
>  | 3.2.1.1 Protocol Requirement
>  |
>  |    The protocol MUST contain the following lookup functions:
>  |
>  |    1.  Contact lookup given a unique reference to a contact of a
>  |        resource.
> 
> This can mean several different things. As two examples of this, it can
> mean that the globally distributed database of "domains" must be
> searchable by some kind of contact identifier, or it can mean that some
> other [different] globally distributed database of "contacts" must be
> searchable by some kind of contact identifier. It can also mean both, and
> it can also mean a whole lot more databases will eventually need to be
> searchable as well (substitute IPV4/IPV6/ASN databases for the "domain"
> database and you see that we are talking about a lot of databases).
> 
> Both of those interpretations have different ramifications.
> 
> On the one hand, searching a distributed database (domains in this case)
> by attribute value isn't pretty. It isn't something that's done with any
> other protocol in the IETF space (the closest we came was IQUERY in DNS,
> which was deprecated last year). We've kind of bounced off this topic a
> few times, but frankly, at this point the technology is more appropriate
> for doctoral thesis papers than practical application. Exactly how is a
> server supposed to say "I don't have any matches, go try some infinitely
> and recursively large array of other servers". If this interpretation is
> scaled back some -- just query a specific server for the attribute values,
> effectively reinvinting IQUERY with all of its limitations -- that is
> certainly doable but it is kind of a metaphorical change from other
> searches that we are already doing. We have to ask for the identifier
> (presumably a name and/or an email address) along with the scope they want
> to search within (ask the .com servers only), and not do referrals. This
> is tantamount to being an ugly hack and one which doesn't actually solve
> the canonical problem of finding contacts.
> 
> The other interpretation does solve the problem, but it introduces a
> management issue, which is that we aren't claiming authority over contact
> information. If we say "okay there is also some amorphous table of contact
> data in the system, go search that", then we are all of a sudden outside
> the domain space, which is all we are "authorized" for.
> 
> I can do both of these approaches, and although I'd rather just do one
> (the latter in particular), that's not really the problem I'm asking
> about. What I'm asking about is, which interpretation exactly do we want
> to use as a group?