North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Operational Issues with 184.108.40.206/8...
- From: Michael.Dillon
- Date: Tue Dec 10 05:49:40 2002
> > I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP
> > directories for unallocated IP space at the largest aggregate level.
> > also like to see them all dump the quirky and antiquated whois
> > and move to LDAP as the standard way of querying their directories.
> Insisting on LDAP is likely to kill your proposal before it gets off the
> ground. RPSL works fine. If you want LDAP, you can certainly mirror
> via the IRRD mirroring protocol, and store however is most useful
> to you.
I disagree. LDAP is a widespread technology and RPSL/IRRD/RADB is not. The
registries can hire people with LDAP experience or send people on LDAP
training courses. They can get advice and support from LDAP consultants.
And if the registries tell their staff to learn LDAP, then the staff will
be motivated to do it well since LDAP knowledge is a marketable skill.
The RIRs should be looking at LDAP as the core technology for offering
their directory services.
We've already tried the RADB/RPSL/IRRD/whois/rwhois route for years and it
has failed. Only a few people have bothered to learn most of these
technologies and many network operators don't use any of it in an
automated fashion. Just recently there was a lot of discussion about the
new ARIN whois format and a lot of this revolved around how to make it
easier to parse for automated systems. That's like running a mailing list
by typing in messages, printing them out, faxing them to UMich where they
are scanned and run through OCR, and then emailed to you.
Here's how an LDAP directory works. There is a SWIP template form on an
ARIN web page. You type the appropriate bits of info into the appropriate
boxes and press the submit button. An ARIN CGI or webapp places each field
into a relational database. Once a day, they dump any database changes
into their LDAP directory.
Now when you or your admin scripts query the LDAP directory, each bit of
data is received as a separate identifiable field. No more parsing. In
fact, you can tell the LDAP server to only send the bits of data that you
are interested in. Rather than trying to reinvent LDAP by ourselves it
makes an awful lot more sense to leverage the efforts of the hundreds of
people at Netscape, SUN, IBM and many universities who have worked over
many years to make LDAP version 3 into a very usable tool. LDAP
directories are already integral parts of running many large networks in
universities and corporations. We should use it in the global Internet as
-- Michael Dillon