"Metering" Database Access on the Web -Reply

[jqj at darkwing.uoregon.edu]

Don Lester argues the superiority of site licensing based on IP address
(normally, IP network number) as a solution to the database licensing
problem.  I concur with him that given current technology it's the best
existing approach.  However, it has a number of notable limitations:

1/ it's quite hard to administer the space of licensed subnets in a complex
environment. Some vendors insist on a contract that offers unlimited access
only to subnets where there are not substantial numbers of unsecured
machines (e.g. if the site license is only for university students and
staff, then a workstation cluster in the library that allowed community
patron access might be disallowed).  On a typical campus these days the set
of networks may be changing fairly rapidly, and it's hard to keep the vendor
updated as to which networks are covered by the site license.  Most vendors
who were willing to consider site licenses in the past were also willing to
be fairly casual about this sort of thing, but that seems to be changing.

2/ it is particularly problematic given the growing tendency of academic
institutions to outsource remote network access.

4/ high quality vendors are understandably loathe to license access on an
"all you can eat" basis, just as restaurants are loathe to offer all you can
eat buffets, and software vendors are loathe to site license major PC
software (how many of our institutions have a site license for their most
popular word processor?  1%?).  Part of this may be lack of trust that the
institution will limit access effectively, or lack of agreement on what
constitutes a legitimate "site" (more of a problem for public libraries than
for single-campus universities, perhaps).  Part of this is insecurity about
expected volume of transactions -- the vendor doesn't know enough about the
potential market to be able to price a site license.  Part of it may be an
expectation that good pay per view solutions are just around the technology
corner, making it unattractive to lock oneself into approaches that are
diametrically opposed to ppv.  Part of it is culture.  But it's a fact of
life.

Don notes that proxy web servers go a long way to addressing problems 1 and
2.  I agree, but the problem with application-level proxies is that the set
of application-level protocols keeps changing.  Pre-web we had lots of
protocols, too many to do a good job of proxying (how many of us had
transparent proxy telnet servers?).  HTTP 1.0 didn't have the facilities to
really allow effective proxy servers.  We may finally (with HTTP 1.1) have a
protocol that allows good proxy web service for non-interactive web
applications -- when clients that understand 1.1 become widespread.  By that
time, it wouldn't be surprising if a different protocol (perhaps something
built on reliable multicast) were becoming popular, requiring us to
completely reengineer our proxy setup.