linux-ipsec: organizational lessons from Raleigh

Well, we learned a few things about how *not* to do bakeoff participation this time... Here's my take on them; Hugh may have a slightly different viewpoint. These are in random order.

Most prominently, we can't rely on being able to borrow hardware. We have to bring the full configuration we want to use, and it has to be put together and tested ahead of time. Far, far too much time was wasted just getting us to the point where we could actually run interop tests. The various little hardware and software problems which caused it are unlikely to repeat, but others like them might.

In the same vein, the software we're going to test likewise should be set up and checked out ahead of time. Again, we spent a lot of time chasing down setup problems and figuring out how to run newly-changed software with sketchy documentation, and all of that should have been done ahead of time. This preparation effort should include putting together suitable test scripts, if they aren't part of the software already (which they probably should be, but maybe you'd want to customize them some for bakeoff use). Doing this ahead of time would also avoid the problem of having developed useful scripts which now have to be thrown away and reinvented (because they were developed within the US).

A secondary issue there is that a bit of advance interop testing against a different implementation -- preferably a *completely* different one, not just another JI/AK-derived one like the OpenBSD one -- would have exposed the problem that eventually killed our kernel-level interop testing altogether (incompatible key-setup conventions that we couldn't figure out how to reconcile). Hugh is going to investigate providing for routine dissimilar-implementation testing as part of our development setup, but if that doesn't pan out, we need to make a special effort to do at least one quick test this way during bakeoff preparations. Again, the intention is not so much to avoid repeating this particular disaster -- which shouldn't recur if we're careful -- but to head off analogous disasters.

The hardware configuration needs to include one keyboard (screen, CPU, etc.) per person, over and above any keyboards which aren't expected to be routinely usable. This time we had two people and one keyboard, and if I hadn't had several hundred pages of IETF drafts and related material along to read, my time would have been largely wasted. Also, the keyboards need to be configured to match the preferences of the intended users; when I did get keyboard time in Raleigh, sometimes there was substantial overhead involved because I had to figure out how Hugh's user interface did things. (Planning for this needs to remember that a laptop which is leaving the US afterward can't have any crypto stuff on it then.)

One thing which *did* go right, but could easily have been problematic -- especially if the above-mentioned problems hadn't delayed serious interop testing until mid-week -- is coordination with the non-attending members of the team. Quite apart from the fact that the off-site folks may have expertise that the on-site people lack, when the bakeoff is in the US, on-site fixes are awkward because the code can't go back across the border. It seems to me that in such situations, we need to think of the folks back home as an active part of the bakeoff team, despite the geographic separation.

Ideally we'd have continuously-live audio/video links, so the off-site people would be in the same virtual room even though they're not at the bakeoff site in person. That would be overkill, but I believe we do need to think of the situation that way, *not* in terms of the on-site team doing all the work and occasionally sending email about details; the off-site people are bakeoff participants, not off-line consultants, and are not physically present only because of some irrelevant constraints. We need to think about what to do to improve communication (in particular, do we need some sort of organized, convenient voice link, even if it's not continuously live?), and all parties need to know the others' schedules in detail ahead of time and be informed promptly about any changes.

All in all, this was an educational experience, but mostly in directions which we hadn't expected and would have preferred to avoid. Close attention to the problems we had should go a long way toward making future bakeoffs more productive.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

Henry Received on Fri Mar 6 15:42:14 1998