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

[Leslie Daigle]

To go back to Eric's original question, it is my understanding
that "the protocol" in the requirements document refers to the
interaction with a single server and its own managed database.

We have not yet discussed the conditions under which a given
server might make assertions about potential contents of other
servers (referrals).  We would need to nail that down in order to have
a referral-based service that works.

There are various proposals on the table about how to
drive queries up & down a managed tree (e.g., following
the chain "up" the domain tree to find the CRISP server
associated with a given domain); that's not currently
in the requirements, and is one of the things that we
(for some value of "we" that might be the WG) have said
IRIS should take on from the ldap-whois proposal.

If I understand Eric's point here, the suggestion is
to say that, even if you find an "authoritative" CRISP
server for (say) thinkingcat.com, if it doesn't have contact 
info for LLD02 (the contact handle for thinkingcat.com), then you 
should find & query the CRISP server for .com.

I think that would be a service-level requirement; it's an
assertion of how we think CRISP servers should be organized
in order to provide an effective service.


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

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.

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


-- 

-------------------------------------------------------------------
"Reality:
     Yours to discover."
                                -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------