On Thu, 4 Jan 2001, Eric A. Hall wrote:

...

All of this stuff (global WHOIS included) really needs to go into LDAP, using standardized schemas for the relevant data.

I'm not sure this is a good idea, or even possible.

That's two arguments, and they need to be separated. As to the quality of the concept, standardized views of a partitioned database are required in order to facilitate improved levels of debugging and problem reporting. We already know this much: given that the Internet is a collection of independent networks, mechanisms for locating and identifying the operators of the networks are necessary in order for the network operators to manage their interconnections effectively. Every network operator with more than a year's experience under his belt will agree with this. Standardizing the information structure and supplementing the data with a standards-based referral mechanism to the downstream databases is the only real difference for this model versus the schema-free WHOIS/rWHOIS already tried. So if standardized views allow for more/better management of independent networks and their interconnections then its a good idea. The benefits of standardized schema are most apparent when you look at them in the context of a referral-based partitioned database. If every network has its own isolated partition with its own WHOIS service (requiring manual manipulation), standardized data is not necessary. But if the data sources are interconnected then standardized schema allow for higher degrees of automation, which does lead to "better". For example, an operator can provide an address in question as a search key, and then programmatically follow the referrals to locate the operator of the end-point network which owns the address in question. Faster is the "better" quality in this case. Programmatic access to distributed data can also allow for a limited amount of route-management automation, address-to-domain mapping (validation? DNS is very easy to lie to and with), and many other services. These are all positive benefits, so the idea is a good one. Whether the benefits are high enough to justify the effort is your second question.

Given the wide range of organizational approaches and privacy customs and/or laws worldwide, I'm not sure how you could approach this.

If the parties agree that it should be done, it will get done. It doesn't appear they agree with the premise, so there's no motivation to do it. Maybe from your perspective there is no requirement for it, but from the outside there is a strong desire for this kind of service. Our jobs as network operators are much harder than they should be.

Even within just the RIR's, there's the different philosophies regarding the contents of the data. For instance, ARIN maintains fairly tight-fisted control over it's database, which allows them the freedom to fix things that are broken. The RIPE database is owned and maintained by RIPE members, which allows members the freedom to update their information on their own, and use the amount of protection they feel appropriate. (Not to sure about the APNIC database, but the Asia-Pacific region has its own cultural mores and specific background as well.)

What if this happened from the top down? Surely the parties would do it if they were instructed to do so by the body that empowered them in the first place? Given that scenario, the parties also have the power to do it themselves once they are motivated. I am not reading motiviation from your post.

I get the impression that LDAP/X.500 was designed with a specific corporate and/or governmental organizational structure in mind. I don't necessarily think this maps very well on to the anarchy that is the Internet.

The referral mechanism is the key, since it allows for distributed management of autonomous partitions. The standardized schema is only important if the referrals work. LDAP is a well-documented protocol for querying, viewing, managing and navigating partitioned data so its a good solution to the problem.

Shane Kerr <shane@ripe.net> Database Software Engineer RIPE NCC +31 20 535 4427

-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/