[Ietf-not43] extensibility

[Eric A. Hall]

on 7/30/2003 9:15 PM Edward Lewis wrote:

> Regarding Ted's note - I do feel a bit guilty about making this 
> thread seem antagonistic.

It isn't antagonistic; it's adversarial, as it should be. Let's not be
afraid to question each other's assumptions.

For the record, FIRS would not be on the table without the support and
effort of Andy Newton and Mark Kosters in particular.

> I'm asking out of my pure ignorance.  Why would a client-side user 
> want to integrate the responses from the CRISP protocol in a 
> something that's built on LDAP?

I'm actually thinking about more than that, where users would not limit
themselves to reusing the data but would want to provide their own CRISP
servers, services and data. I'll get back to this in a moment, but let me
diverge first.

CRISP is about providing a directory service, by definition and by
operational character. It's a read-mostly distributed database service,
providing lookup-by-name and search-by-value functions, structured answer
sets, and so forth. WHOIS was intended as a directory, the IRIS specs use
the term freely, and LDAP is what it is, so by every interpretation we're
building a directory service of Internet resources, regardless of how
comfortable anybody actually is with that. We've avoided focusing on this
point and that was a good thing, imo, since we've also avoided a lot of
undesirable participants, but we're at the point where we need to realize
what it means and deal with it.

The central issue is scope. Do we just want it to be a WHOIS replacement
for the same providers, or do we want to want to encourage broad and deep
usage within the Internet community. In my opinion, the latter is
unavoidable in the absence of purposeful design limitations being
architected into the system, which is something we probably aren't going
to do. This leads to the conclusion that failing to encourage the
inevitable is a fundamental error, since we're only going to be
guaranteeing eventual frustration.

As proof of this point -- and to answer your question -- look at how WHOIS
data is already being used today, for starters. Anti-spam tools, network
management tools, logfile analyzers, and a slew of other products are
already tapping into WHOIS data even in it's brutal current form. We can
guarantee that this same level of usage willl be picked up for the new
system, at the very least. What's even more likely is that the technology
will get pulled into a bunch more products, either along similar lines or
by extending other tools. I mean, it's not that hard to imagine that
traceroute programs are going to start using the baseline data, or that
(God help us) automated complaint generators are going to use it, etc.

What will follow is also fairly predictable, since it also happened with
WHOIS, which is that people will want to start building layered services
on top of the baseline data. We saw this not only with the long-ago
expansion into data for non-human resources, but also with the more-recent
expansion into RPSL. It seems obvious to me that once people discover a
federated namespace with ACLs, structured queries and answers, and all,
that this expansion will accelerate, with people wanting to provide all
kinds of resources.

For an idea of the kinds of data that I'm talking about, think about the
types of data that have been proposed for DNS but which are rejected due
to incompatibilies or concerns with DNS. Certificate stores, public keys
for applications and services, whitelists, email filters, personal contact
data, etc. There is already a demonstrated desire for this stuff but
nowhere to put it, and what we are providing is indistinguishable from a
perfect place to put it (unless it is designed not to, as mentioned). For
years we've been telling people "use something else" and by golly, this
*is* that something else. The fact that the initial database will be
populated with the most useful resources -- domains, IP addressing blocks,
and contacts -- is going to be bacon on the bait.

This is why I'm saying that the registry data is just a part of the big
picture. It's arguably the most important part of the picture, but in the
end I don't think it will represent the majority of the data in the total
system. And since I think this balance is unavoidable, I think we should
be focusing on making sure it goes well.

> I coming from a long term relationship with DNSSEC. (;()  There are 
> quite a few RFCs on that subject, but to date it is not useable.  I 
> don't think that the number of RFCs is a measure of anything quite 
> frankly.  My point is that a lot of work has gone into LDAP and I 
> know of the work, but I am ignorant of where LDAP is applied in spite 
> of all the work.

I agree with this indictment, but I don't think there is much in the LDAP
RFC series that equates with that. Most of the specifications are schema
definitions and protocol extensions, and is used to illustrate the point
that this same level of crack-filling will also be necessary.

> (Much to the same extent of PKIX work - a lot of energy and still a 
> lot of frustration in seeing it adopted.)

Nowhere to put it. Yet.

What's been missing is the mesh of servers. Once the domain and IP
addressing delegation data goes into CRISP, these problems will at least
be partially resolved (depending on the degree that the providers
recognize that they are already in the directory business and begin
offering the layered data as a value-add to their customers, or if it gets
left to third-party providers to plug in as layered services).

> I have been known to be someone who switches sides in arguments of 
> this (IRIS v FIRS) nature based on what I learn.  Right now I see 
> advantages favoring IRIS but this may only be because I am stupid 
> about FIRS or LDAP.  So, to this end I would appreciate hearing how 
> FIRS is more extensible for the client (and/or server) side - not 
> just that it is because of the LDAP legacy.

The candidates are relatively equal as far as the technology parts go,
Andy and I already privately agreed to that.

The advantage to FIRS is in time-to-deployment, especially as you get
towards the edge of the service. LDAP servers are bundled into Win2k,
Solaris, Linux, NetWare, and several other common operating systems. LDAP
clients are already provided with authentication systems, email clients,
web engines (eg, PHP and ColdFusion), and bundled as libraries for most
development languages. The LDAP technology already provides integated
database, protocol, authentication, and ACL technologies. The service is
understood and supported by a large number of vendors, and is provent to
be extremely scalable. Simply put, if I want to write a client agent that
does CRISP lookups (or does some layered service lookup) then FIRS is
easier. Likewise, if I want to provide a new layered service as a
leaf-node in the Internet directory, then FIRS is easier there too, and
has the known properties of scalability, reliability and support.

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