20 Jan 2000 - Tony Stoneley
Thanks to all who responded to The future of the IP address register. As might be expected, general reactions covered the spectrum between fulsome support for using Oracle and a preference for text files and CVS. On the whole I am minded to plough ahead with my proposed plan, but the adverse comments and divergent suggestions certainly deserve some response.
Ethos
Perhaps the most fundamental questions raised were the purpose of and the need for any register atall, suggesting that perhaps the answer was to give institutions bare networks, essentially just stocks of addresses to use as they wish without any central involvement whatever. This suggestion was sometimes moderated by the further notions that it could be on an optional basis per institution, and perhaps optionally using apparatus supplied by the CS, much as with the CS's managed web server service. Without embarking on a lengthy apologia, my responses would be along the lines of
- Our contract with our ISP (JANET) requires us to maintain a well run house, where problems and abuses can be quickly diagnosed and dealt with. Without the central availability of registration data this is essentially impossible. This is no idle requirement: problems and abuses certainly do occur, quite frequently, and the data are pivotal in their treatment.
- Whilst v6 addresses may be cheap, v4 addresses are in short supply. Only by maintaining a tight hold on them have we been able to avoid gross wastage. The future is unclear, but it hasn't arrived yet.
- An anarchic arrangement would require much more vigorous insulation between institutions. This would be expensive, both in equipment and personnel, restrict performance, and destroy flexibility. For the University to stay at the forefront of research generally, bleeding edge technology has to be exploited, and this is only possible in a world that is technically somewhat unstable. Administrative constraint is merely the alternative to sticking to mature technology.
Client expertise
Unsurprisingly the replies all came from people who understood the questions, the computer litterati, and a number of the suggestions made could work in a world where most (if not all) institutional computer officers were generally computer literate in the traditional sense. Sad to say, the world is not like that. It would be quite wrong to criticise COs when the fault usually lies with the employers not understanding the job, but it must be clearly understood that a significant number arrive in post, maybe part-time post, with precious little relevant expertise or knowledge. They may be nice, well-meaning, even intelligent people, but dropped into the deep end never having played in the shallows, let alone been taught to swim. I'm sorry, folks, but the apparatus has to be as robust and foolproof as a washing machine in a laundrette, and some of the proposals just don't measure up to that.
Database technologies
One school of thought is that database technology is indeed required, but that an object database would be far more appropriate than an RDB. There are two discussions to be had here, the religious and the practical. I don't feel up to arguing religion, but I do feel that object database technology is still sufficiently immature that it should be avoided in this case, by those of us who lack any experience in the field.
I did incidentally receive a comment from the author of Ganymede, friendly enough but understandably slightly put out that I had been so dismissive. In particular he was at pains to challenge my charge of parochialism, and perhaps he was right. Clearly a lot of the effort there has gone into the underlying general purpose object database, and if we did want to follow that faith then maybe this would be a good sect to join. It may also be that it is we who have the parochial requirements, not he. He did however point me to someone else who is wrestling with similar problems and apparently investing in the RDB faith. See http://staff.feldberg.brandeis.edu/~rcgraves/dhcp.html and http://staff.feldberg.brandeis.edu/~rcgraves/norm/, the former containing a useful survey of available address management technologies and implementations.
There were also a number of suggestions that PostgreSQL and sundry other RDBMs were worth a second look, but no counters to the fact that we already run the CS admin database on Oracle, affording the advantages of established expertise and ease of integration.
There was support for the quick & simple architecture that only copes with the common case, but as it happens I have meanwhile gained a little more confidence in the RDB world, and come to the conclusion that a little more structural complexity can actually make the job easier, mainly because required constraints on the data can then be encoded easily as standard SQL constraints, rather than as complex and error-prone executable front-end code. I am fortunate in having an experienced mentor to offset my own inexperience here.
IPV6 ethos
IPV6 addresses may possibly be two a penny, and not worth serious conservation. More seriously I was reminded that IPV6 contains provision for IP addresses whose local part is basically the interface MAC address, and that there is a whole ethos there of automatic self-registration, or non-registration if you like to view it that way. Certainly the notion of pre-constructed records for individual addresses in the database can't survive this, and a generative apparatus would be needed. More worryingly, this ethos could indeed drive a wedge into the manageability of the CUDN as we currently conceive it, not unlike the current pressures for NAT arising from off-the-shelf firewall products. At this point I duck, since it is all speculative and since something is clearly required anyway meanwhile and will continue so for the many cases where some registration certainly is inevitable. The only sure conclusion I do draw is that flexibility is of the essence.
Future discussions
A couple of people asked for a discussion forum such as a mailing list or local newsgroup. I'm not fundamentally opposed to the idea, but I think the time may not be quite ripe. At this stage it might raise expectations unrealistically, whereas precious little is going to happen for a while yet. A moribund or unresponsive forum seems a bad idea. Maybe when/if the pace picks up... Meanwhile, any comments can be sent to me, ajms@cam.ac.uk.
Other points
A range of other suggestions and comments were offered, and I am grateful for all of them, even though I don't propose to list every tiny detail here and now.