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

[Peter Gietz]

Leslie Daigle wrote:
> 
> Quite apart from which, I believe the discussion of using common 
> indexing protocol (or not) is *independent* of the
> query protocol requirements we are discussing now.  

Yes. I only put it into discussion to say that, e.g. by using CIP more 
complex requirements for distributed searches could be fulfilled.

> CIP is
> a back-end index-creating protocol; it is not a query protocol.
> And note that the actual queries you might use against an
> index could be quite different than those you use to access
> the specific information; 

The index server to which a client connects to, could and IMO should 
provide the same query interface using the same protocol than the one 
used for retrieving the actual data.

 > there is not sufficient information
> in the index to be able to answer the granularity of query
> you want to ask the final leaf server; you wind up having
> to pull apart the query to look for hints in it anyway.

This is dependant on the actual index implementation; the granularity 
could well be the same, especially in a partly hierarchical index mesh.

> 
> As I said last July,
> 
> http://lists.verisignlabs.com/pipermail/ietf-not43/2002-July/000157.html
> 
> there are projects that have implemented the whole index
> as a service independently of the individual information
> servers themselves.  We can (and probably should) do something
> like that here.

agreed. This could well be a simpler approach than TISDAG that had the 
support of a variety of directory protocols as a requirement, which 
wouldn't be the case here.

Cheers,

Peter

> 
> Leslie.
> 
> 
> 
> 
> Eric A. Hall wrote:
> 
>> on 4/1/2003 12:16 PM Peter Gietz wrote:
>>
>>
>>> requirements on distributed search to something like:
>>>
>>> "Contact lookup given a fully-qualified domain name or IP address"
>>>
>>> where the server with the appropriate contact data of that domain 
>>> could be looked up via DNS SRV. That seems better to me than getting 
>>> rid of a MUST on contact lookup.
>>
>>
>>
>> That's definitely the approach I favor, but like I said there are some
>> issues with this approach (despite these problems, I still favor this
>> approach however)
>>
>> First of all, there is no global delegation body for contact identifiers.
>> This is in contrast to global delegations for resources such as DNS
>> domains, IP addresses, and ASNs. Since there is no global delegation 
>> body,
>> there is no existing delegation body which can be queried. As a result,
>> you either have to query a specific organization (the servers for .com or
>> .in-addr.arpa), or you have to query the end-nodes directly (asking the
>> servers for example.com for information about user at example.com).
>>
>> Both of those approaches have the potential to result in incomplete 
>> answer
>> sets. In the case of asking the .com servers, you won't get information
>> about any delegations that user at example.com may have made under something
>> like .co.uk, and that database may also contain out-of-date or misleading
>> information (using user at example.com for some domains, goaway at example.com
>> for others, misdirection at hotmail.com for more, and so forth). Asking the
>> example.com servers may fail because the admin can choose not to provide
>> the information, or they may not even have any servers (in the latter
>> case, you would end up falling back to .com servers, and facing those
>> problems). So no matter what path you choose you are only going to get 
>> the
>> information that people want you to have; asking their servers 
>> directly at
>> least gives you a mechanism to aks for the information that they *want*
>> you to have, with a fallback to limited information. A catalog server 
>> will
>> be able to collate information from various pools, but again, this will
>> only work to the point where the data is timely and accurate, and there
>> are too many hurdles to deploy a catalog approach as the standard.
>>
>> Probably the ultimate solution here is to have some kind of global body
>> delegate global contact identifiers, with other delegation bodies
>> requiring an identifier before any delegations can be made, and with the
>> identifier database being updated whenever a delegation is made. It would
>> be easy to stick a WHOIS-like front-end on that. I don't think anybody
>> expects that this would happen any time soon though, and I hesitate to
>> even suggest this because I don't want folks to think I'm advocating it
>> (to be clear, I'm not).
>>
>> My preference would be to use a bottom-up query against an email address
>> as the "standard" method, with the assumption that ad-hoc catalog servers
>> will emerge to provide "global" interfaces which address the actual need.
>>
> 
> 

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: peter.gietz at daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________