UK Academic Community Directory Group Minutes of Meeting on 21st March, 1991 Paul Barker Organisation: UCL Document Location: UCL _A_B_S_T_R_A_C_T Minutes of the Tenth Meeting of the UK Academic Community Directory Group held at University College London on Thursday, 21st March, 1991. April 26, 1991 UK Academic Community Directory Group Minutes of Meeting on 21st March, 1991 Paul Barker Organisation: UCL Document Location: UCL Present: Shafiq Ahmed Nottingham Robert Ash Aberystwyth Adrian Barker Bloomsbury Paul Barker UCL (Secretary) Chris Bayliss Birmingham Colin Cooper Glasgow Jim Craigie JNT (Chair) Ian Dallas Kent John Dardis ULCC Ian Dickinson Warwick Susan Feng Imperial Andrew Findlay Brunel Karen Goswell RAL Fred Greyer Queen Mary & Westfield Mike Guy Cambridge Allan Hawdon Kings Andrew Hillborne Newcastle Robert Hogg Bradford Peter Houlder Kent Stuart Keir Sussex Steve Kille UCL Max Lang Southampton Kevin Large UMCC Christina Lau Kent Caroline Leary Sussex Richard Letts Salford Ravinder Lyall Southampton Jinong Ma Salford Peter Morton Exeter Pava Pavanantham Surrey Darrell Plant UCL Andy Powell Bath Colin Robbins X-Tel Kel Shorey Strathclyde - 2 - Linda Skordellis ULCC Rodney Tillotson RAL Steve Titcombe UCL Alan Turland Edinburgh John Williams Aston Peter Williams UCL Apologies for absence from: Bob Day RAL Julia Hill Heriot-Watt _1. _A_p_p_r_o_v_a_l _o_f _t_h_e _A_g_e_n_d_a The following agenda was agreed upon: 1. Introductions 2. Review of minutes of the meeting held on 10th December 1990. 3. Matters arising. 4. Quipu implementation status report 5. Quipu support status report 6. Brunel's user interface implementation status report 7. Status of other known Directory implementations 8. Directory pilot sites status reports 9. Report on the RARE Working Group 3 and RARE Directory Project 10. Report on COSINE Project 11. Report on IETF Directory Group 12. Deletion of unavailable DSAs 13. Upgrading to ISODE-6.8 14. Any other business 15. Date of next meeting - 3 - _2. _A_p_p_r_o_v_a_l _o_f _m_i_n_u_t_e_s _o_f _p_r_e_v_i_o_u_s _m_e_e_t_i_n_g To inhibit tampering with his minutes, the secretary devised a cunning scheme whereby he failed to pass on the printed minutes to the chairman, who colluded by failing to notice their absence. All unanimously then agreed that the minutes which they did not have in front of them were correct. _3. _M_a_t_t_e_r_s _A_r_i_s_i_n_g X-Tel now had a copy of the Directory Group mail list, of which two-thirds were directory distinguished names. It was noted that some mail addresses were still in the wrong domain order, and this hampered transition to a directory based distribution list. Using the directory for the list meant that the list could be held anywhere, and it was thought that it would be a good idea to use the JNT Directory machine for a transitional experiment. Some problems were noted with compatibility between versions of ISODE and PP - the latest PP (version 5.2) relied on ISODE- 6.0, whereas it was suggested that sites might consider upgrading to ISODE-6.8 as the Directory functionality had been considerably enhanced. Version 5.3 of PP would be compatible with ISODE-6.8. Steve Brabner from British Telecom had been invited to come to the meeting to talk about COHORT 500, and X.500 and British Telecom in general. He had accepted the invitation but had had to cancel at a late juncture. He would be invited to the next meeting. Jim Craigie had not pursued further details about the OSIWare implementation. UBC did not appear to be ready a product yet, (although Paul Barker reported that he had seen evidence of the OSIWare implementation being tested in some Quipu logs) and it seemed prudent that further enquiries should await the product's release. It was noted that the use of another implementation in the UK pilot had considerable implications for human resources. Rodney Tillotson had received one reply on codes of conduct. Sites were again urged to provide Rodney with examples of existing codes of conduct. Rodney Tillotson had not sent Rutherford's Directory mail responder to X-Tel for distribution. Rodney Tillotson noted that he had had problems with his DSA checker due to binds not timing out. The problem appeared to be remedied with ISODE-6.8. He would send the software to X-tel for quality assurance. Colin Robbins said that, on the basis of the DSA version number, 7 sites still appeared to be running ISODE-6.0, - 4 - despite many warnings to upgrade to ISODE-6.1. In fact, it appeared that 4 sites were really running 6.0. They should upgrade immediately, it making more sense now for such sites to upgrade straight to ISODE-6.8. Jim Craigie had not yet written the letter explaining sites' responsibilities with regard to hardware and software maintenance on the Directory machines. In a moment of weakness, Jim suggested that we might get more aggressive with him if he didn't complete this task soon! X-Tel reported there was now a scheme for handling patches, and also that there was now a bugs' database. Colin Robbins reported that X-Tel advised sites to ask for best effort software support and 8 hour hardware support. Some sites felt that they would prefer to have the exact wording and needed to know what the above words meant in terms of "stars". X-Tel reported that SUN were fully aware of the situation whereby SUNs were delivered to sites via X-Tel. Andrew Findlay did not yet have details about which subset of ISODE was required to build and run DUAs. It was noted that sites could contribute useful information by reporting their success or failure in porting ISODE onto hardware other than the SUN 4's used in the UK pilot. There were currently no takers for the development of an interface for a Macintosh, although it seemed something that it might be appropriate for Brunel to undertake eventually. _4. _Q_u_i_p_u _i_m_p_l_e_m_e_n_t_a_t_i_o_n _s_t_a_t_u_s _r_e_p_o_r_t ISODE-6.8 had been released since the last meeting. Most of the differences between ISODE-6.0 and ISODE-6.8 were developments of the directory software. It is hoped that 6.8 is a reasonably stable version of the system, and it is fully supported. The main reason for this interim version is that the developers want to be sure that the next MAJOR release (ISODE-7.0) is as robust as possible. There were a large number of changes between 6.0 and 6.8 (too many to list here). The work done reflected a mixture of the work under the original contract, and work which had been done in response to user requirements. Some future work areas were described briefly: o Parameterisation of caching - to allow for the holding of, say, country and DSA entries for longer than personal and organisational entries. o Quality of service - providing a way of knowing whether - 5 - a DSA is service orientated or experimental, and what the data quality is for particular sub-trees. o Access control - the ability to allow full generality for local searches, but a restricted form of search for external access. Following a discussion on Quipu and PP version numbers (the essential details of which are reported in Matters Arising), an open invitation was made by Steve Kille for sites to act as PP beta sites. Sites considering this offer should be fully aware of the distinction between major releases of the code and beta versions, with the implication that running the beta software might entail more work. _5. _Q_u_i_p_u _s_u_p_p_o_r_t _s_t_a_t_u_s _r_e_p_o_r_t It was reported by Colin Robbins that a month's effort had gone just into checking out version 6.8 ready for release. Some scripts had been provided for updating from ISODE-6.0 to ISODE-6.8. Some problems discovered in an initial release of the scripts had now been fixed - sites which had taken a copy of the original scripts, and not yet run them, should take an updated copy. The DSA Giant Tortoise, which holds the master of the root and of GB, had been transferred from UCL to ULCC. The DSA was now running on a machine funded by the COSINE PARADISE project. This DSA was now very heavily used, and it seemed likely that some of the functions now performed by this DSA would soon have to be split off onto other DSAs and other machines - the GB EDB in particular needed a proper home. As an example of the problem, it was noted that all relaying (providing connectivity between heterogeneous network communities) went through Giant Tortoise. It was pointed out that traffic could be releaved to some extent by sites making use of IXI, as this allowed for direct connectivity to parts of Europe. The bugs' database was now in place, and had been advertised to the list. A request was made that email queries should be sent to the appropriate lists, rather than to individuals. The problem of disk layouts was raised by Mike Guy. The first few machines installed in the pilot have a different disk layout to that now used. This problem could probably be sorted out fairly quickly between X-Tel and Cambridge, and it was agreed that they would bring effort to bear upon the problems as soon as possible. It was also noted that SUNOS upgrades meant that ISODE systems needed rebuilding - 6 - from scratch, and thus scripts to facilitate this as well as the upgrade scripts would be useful. Mike Guy also requested that the pilot supporters should indicate preferred versions of SUNOS. It was noted that SUN's response to software problems was often to tell the site to upgrade to the latest version of SUNOS. Adrian Barker asked that X-Tel provide a specification of the current kit being purchased for each site. Bloomsbury intended to buy another SUN to run PP and were anxious that they bought a machine which would be covered by the PP support arrangements. In fact, there had been no change in the equipment being bought for the pilot other than that the later machines had a single 600 Mbyte disk as opposed to two smaller 300 Mbyte disks. An equipment list could be obtained from the UCL-CS and X-Tel document stores. The myth about the existence of Sunlink-7.0 and CONS persisted, and there were some strange tales about CUDF problems. It was even alleged that some sites actually had some code on beta test. X-Tel would provide a report on Sunlink-7.0 at the next meeting. _6. _B_r_u_n_e_l _u_s_e_r _i_n_t_e_r_f_a_c_e _i_m_p_l_e_m_e_n_t_a_t_i_o_n _s_t_a_t_u_s _r_e_p_o_r_t Stef had left since the last meeting. Damy would take over work on the PC MS-DOS interface as well as working on the UNIX interfaces. Timescales were unclear as not all the components were yet available, and the developers would have to gain familiarity with the new tools. Pod and sd were now available as part of ISODE-6.8. There had been some work on the query engine to use the new asynchronous interface, although asynchronous bind had still not been incorporated. A new interface "doog" had been produced, using something akin to user-friendly naming. This interface was now available as by calling brunel.dir. Initial responses had been favourable. A form-filling interface was being produced, hopefully in time for Networkshop (it was, and very nice it was too!). _7. _O_t_h_e_r _D_i_r_e_c_t_o_r_y _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s The Pizarro system was being used at 5 sites in the French pilot. Some interworking testing between Pizarro and Quipu was already underway. A MAC interface would soon be available, either as a PSI product, or as shareware (cost approximately 35 dollars, with the usual shareware rules applying). - 7 - _8. _R_e_p_o_r_t_s _f_r_o_m _D_i_r_e_c_t_o_r_y _P_i_l_o_t _s_i_t_e_s This discussion again followed the framework of the summary of site reports, collated into a gripping read by Bob Day. The report is included in these minutes as Appendix A. Only additional points or those substantially amplified at the meeting are described further here. Leeds had failed to produce a report for the second successive meeting. Liverpool had also failed to report, but they had been caught napping by the speedy delivery of the hardware. In discussing X.25 problems, it was noted that probing had indicated worse reliability from IXI than JANET. There was speculation as to whether this was caused by lack of bandwidth or lack of virtual circuits or whatever. The question of operating system releases only being available on CD-ROM was of vital importance. The JNT would talk to SUN about this in order to ascertain that all sites would continue to be able to receive the SUNOS upgrades. Colin Robbins and Paul Barker said that they would review the status of the Quipu course slides, and see what needed to be done to make this material available to new sites. The probing was discussed at some length, and it was agreed that this was a much harder problem than that initially envisaged. It was also felt that the latest probe figures gave a reasonable reflection of perceived availability. It was critical to make headway with the problem of factoring out X.25 problems as opposed to DSA problems. More probe sites were still needed: Warwick indicated that intended to have a probe running shortly. _9. _R_e_p_o_r_t _o_n _R_A_R_E _W_G_3 WG3 were looking at the problems of supporting different character sets. There had been some liaison with the Australian pilot, who did not want their geographical remoteness to cause them to be ignored when piloting issues and coordination were being considered. There was little else of great significance to report. _1_0. _T_h_e _C_O_S_I_N_E _p_r_o_j_e_c_t The COSINE P-2.1 project now had a name - PARADISE (Piloting A ReseArchers DIrectory Service for Europe). The project was now running the root DSA on a machine at - 8 - ULCC. A central DUA would be provided in due course. The project would be running two machines, providing a measure of back-up against hardware failure. A meeting had been held attended by the commercial concerns in the UK Pilot. It was important that UK piloting was not just an academic club. UKUUG were a good initial contact point for spreading the word about the role of PARADISE in coordinating pilot activities. _1_1. _R_e_p_o_r_t _o_n _I_E_T_F _D_i_r_e_c_t_o_r_y _G_r_o_u_p A number of documents, described in the previous minutes, were on the standards track and would become Internet RFCs in due course. Other documents existed as drafts and it was likely that some of these would also go forward eventually as RFCs. A video conference had been booked for the 11th April between 5 and 9 pm, which would link representatives of the PARADISE project and the UK pilot at UCL, with representatives of FOX and the Internet at three sites in the US. _1_2. _D_e_l_e_t_i_o_n _o_f _u_n_a_v_a_i_l_a_b_l_e _D_S_A_s X-Tel wanted this matter discussed, as a policy of trying to improve the quality of the Directory had been instituted since the last meeting. There had been the feeling that the splendour of the Directory was vitiated by a considerable proportion of the DSAs not being available for months at a time. X-Tel had tried a policy of notifying sites about their continued absence, and warning them that they would be removed if they did not get their DSA working shortly. It was claimed that this heavy-handed method had already succeeded in two instances. Despite this success, Colin Robbins thought that the group should pronounce upon the policy, as X-Tel were not employed as the Pilot Police. Did sites think the approach was reasonable? If so, how poor did a site's availability have to be, or how sparse their data, before temporary removal of the site was considered? It was acknowledged that this was only a pilot service, and thus there were limits as to how aggressive policing should be. Furthermore, Colin indicated that removing a site from the Directory actually made it harder in some ways for that site to get back into the pilot again. There was a substantial amount of discussion about the use of some quality of service attributes which have been specified recently by Steve Kille. A major problem with this approach was that sites which had failed to run a DSA - 9 - consistently, or had put no data within it, were those least likely to set up the quality of service attributes. _1_3. _U_p_g_r_a_d_i_n_g _t_o _I_S_O_D_E-_6._8 X-Tel had produced a note on upgrading systems from ISODE- 6.1 to ISODE-6.8. The upgrade was optional as both versions would be supported, although it was pointed out that ISODE- 6.8 offered more functionality and better performance. Scripts had been written to simplify the upgrade process, and Peter Morton and the author of this note reported that the scripts had proved to be very useful. A bugs database was also now in operation. Messages about the upgrade script and the bugs database had been sent to the directory-pilot list on the 12th March. The upgrade script and bug reports could be FTAM'ed or FTP'ed from X-Tel. _1_4. _A_n_y _o_t_h_e_r _b_u_s_i_n_e_s_s Paul Barker briefly described a package of software which had been produced at UCL, enabling the printing of an institution's telephone book from data in the X.500 Directory. A note describing the software would be made available from the UCL-CS info-server. _1_5. _D_a_t_e (_a_n_d _p_l_a_c_e) _o_f _n_e_x_t _m_e_e_t_i_n_g. Thursday, 13th June, 1991, in the Council Chamber, Wilfred Brown Building, Brunel University, Cleveland Road, Uxbridge, Middlesex. (About 10 minutes drive from the M4 Heathrow turning, or 20 minutes walk/10 minutes bus from Uxbridge tube (Metropolitan line)) _1_6. _A_c_t_i_o_n_s _b_e_f_o_r_e _t_h_e _n_e_x_t _m_e_e_t_i_n_g. JC To invite Steve Brabner of British Telecom to talk about COHORT 500 JMH To provide a (no more than) 2-page guide to X.500 for administrators all To provide Rodney Tillotson suitable examples of codes of conduct RT To collate existing material on codes of conduct to help the group to formulate a Directory usage code of conduct. RT & X-TelRodney Tillotson to send Rutherford's Directory mail responder to X-Tel for distribution. RT To send Rutherford's DSA-checker to X-Tel for QA. JC Letter explaining sites' responsibilities with - 10 - regard to hardware and software maintenance on the Directory machines. JC To talk to SUN about the ramifications of the move to providing SUNOS upgrades on CD-ROM rather than tape. X-Tel To provide more precise details on the recommended maintenance options, with particular reference to SUN's "stars" system. X-Tel Report on the status of sunlink-7.0 to next meeting AF To provide details of what subset of ISODE was required to support the building and running of DUAs. all To report on their successes and failures at trying to build (parts of) ISODE on platforms other than SUNOS on a 4/330. all To get their DSAs listening on an IXI address CJR & PB To review the status of the Quipu course slides in order to decide what needed to be done to make them available as a "starter kit" for new sites all More probe sites required - volunteers please PB To make the note on producing a printed directory available from the UCL-CS info-server - 11 - _A_p_p_e_n_d_i_x _A Summary of Directory Pilot Site Reports March 1991 Bob Day (Informatics Department, RAL) 1. Introduction This paper summarises the Pilot Site reports produced for the UK.AC Directory Group meeting held on 21 March 1991. At the time of writing (20 March 1991) 27 of the 31 sites in the Pilot had distributed their reports, and consequently are included in this summary. This is a considerable improvement in coverage than was possible for the December 1990 summary (where only 16 reports out of a potential 28 were available). The summary brings out issues of note under the following headings: o Hardware and communications; o Basic system software (i.e. as supplied by Sun); o ISODE/QUIPU software, plus DUA software; o Provision of data; o Operational availability statistics. In general only the reported problems are summarised here, not reports of trouble-free running (which should be the norm). 2. Hardware and Communications Most sites reported trouble-free operation of the Sun 4/330 systems, with a few exceptions. Cambridge The disc is currently broken, and awaiting Sun to repair it. Glasgow There have been memory parity errors, the cause of which is unresolved. They have also had difficul- ties in running the console at 9.6 Kbit/s and the MCP at 64 Kbit/s. (As these speeds are well within specification, it would appear that there is some sort of hardware fault involved here as well.) - 12 - Nottingham There was a fault on the cartridge tape drive - this has now been fixed. Salford The CPU is currently down, and awaiting repair. A number of sites have reported outages on their X.25 con- nections, although not attributing these to the 4/330s. These include Aston, Bradford, and Strathclyde. Other sites have yet to connect to X.25 due to a variety of resource problems: Aberystwyth are awaiting a CPSE port and Southamp- ton have also yet to connect. Kent's long-running saga of (non-)connection to their home-grown X.25 switch continues, which is probably a lesson to us all. A potential major point for the Pilot to consider was raised by Edinburgh (and also implied by Cambridge). Sun are now switching their Operating System deliveries to CD-ROM rather than cartridge tape. The Pilot should decide whether there is a requirement to equip the current (and future) systems with a CD-ROM drive to accommodate this. Meanwhile, Brunel's cartridge tape drive has (apparently) still not been delivered! 3. Basic System Software Again, most sites reported trouble-free running. The excep- tions were as follows. Cambridge Difficulty has been experienced in getting SunOS 4.1 on a working medium. This is an ongoing saga (interrupted by the failure of their disc, reported above). Salford The Sunlink X.25 has developed a habit of corrupting the Call User Data Field on incoming calls, which affects Coloured Books (but not ISODE). A patch is known about. There seems to be a gradual migration to SunOS 4.1.1. No problems with the resulting system performance or func- tionality were reported. 4. ISODE/QUIPU and DUA Software Some sites have migrated to QUIPU 6.7 and/or are contemplat- ing 6.8. Brunel reported that the performance of version 6.7 is much better than that of version 6.1. Brunel have also experimented with the new indexing facilities, and warn against trying to index large entities (when they indexed their entire organisation they ended up with a 42 Mbyte pro- cess image and - not surprisingly - very poor performance). Brunel have also experimented with the RelayDSA feature of - 13 - the new QUIPU, allowing their users access to DSAs on PSS and the Internet. Two sites reported problems with QUIPU. Heriot-Watt The DSA was inaccessible for a considerable part of the period. The reason for this has not been resolved, and the problem is still not completely fixed. Oxford There have been occasional hangups of the DSA. Support from X-Tel has continued to be good. Glasgow sug- gested that it would be useful (based on their own experi- ence) if the QUIPU course notes prepared by Paul Barker could be included as a matter of course with future deliveries of machines. These give a good overview of the system, useful for novices. Brunel reported that they have now released a DUA for MS- Windows-3 on a PC. This uses a serial link to communicate with a Unix server, pending OSI support on the PC. The latter code is now beginning to arrive from Edinburgh. A potential problem is that the associated ASN.1 tools are expensive, and this cost was not allowed for in the original contract. The JNT's assistance is being sought. Brunel have also made progress on the ``query engine'', and have included User Friendly Naming largely according to Steve Kille's specification. The visual interface is being cou- pled to this. Brunel have also released a read-only line- mode interface which includes User Friendly Naming. There will be a demonstration of the latest developments in DUAs at Networkshop in Aberdeen. Andrew Findlay also gave a presentation on the Pilot to the IEE in February. 5. Provision of Data Interpreting the information contained in the reports, the following summary can be made. (The sites not reporting were Leeds, Liverpool, Reading and Surrey. Salford reported, but it was not clear what the status was.) Data provision procedures up and running: Aston, Bloomsbury (still to add e-mail addresses), Brunel, Nottingham, RAL, Sussex. Technical work underway: Birmingham, Cambridge (doing a temporary collection of information pending ``real'' data from administration), Imperial College, Heriot-Watt, Stirling, MCC, Strath- clyde, Warwick. - 14 - Awaiting delivery of data: Bradford, Bath, Cambridge. Negotiations with administration departments underway: Glasgow. Negotiations in difficulty and/or stalled: ULCC, Edinburgh. Still to start data provision seriously: Aberystwyth, Exeter, KCL, Open University, Oxford (com- puting staff only so far), Kent, Southampton. By far the most popular source of information still seems to be the telephone directory. This tends to mean that the information does not contain e-mail addresses, unless an extra source can be merged in. It also often means that data is available for staff only, not students. Edinburgh reported continuing deadlock on the issue of members of the University having to opt in rather than opt out. There seems to be no immediate hope of progress. Heriot-Watt reported that their management had decreed that given names and titles are not to be included, on the grounds of a potential for harassment of female members of the University. Salford appear to have registered a ``Habits'' under the DPA, to cope with the FavouriteDrink attribute! A number of sites reported that staffing resource difficul- ties have prevented progress on data collection, which is obviously a time-consuming job even when ``automated''. 6. Operational Availability Statistics Statistics for DSA availability have been compiled, based upon the weekly(ish) summaries distributed by UCL. These have been grouped to give an idea of the general state of health of the Pilot and are shown in Table 1. This shows the numbers of DSAs available in each of a series of ``per- centage availability'' bands. All DSAs that claim to be connected to JANET or Int-X25 have been included. Note that some sites have more than one DSA running. (Note also that at UCL a ``week'' apparently runs from Friday to Friday!). In general the summaries were compiled from probe results from STC, UCL and Brunel, with a brief appearance from ULCC (week ending 1 February). Other sites have volunteered to run the probe, in the interest of better coverage, but there have been problems with the scripts. These require debug- - 15 - ging, which has not been a high-priority item. Because of the use of several probes, there are often dif- ferent results given for a single DSA from different probes. Where this has been the case the highest figure has been taken, on the basis that the lower figures might indicate a problem with the probe (although this cannot be certain - see below). Availability (%) Week | 100 90-99 80-89 70-79 60-69 50-59 25-49 1-24 0 ending | 7/12/90 | 13 4 1 0 1 0 1 0 6 14/12/90 | 1 1 9 5 0 1 4 0 5 6/1/91 | 9 7 2 0 1 1 0 3 6 11/1/91 | 8 7 1 1 0 2 0 3 7 25/1/91 | 3 8 2 0 2 0 5 1 9 1/2/91 | 7 6 4 1 1 3 0 2 5 8/2/91 | 2 16 1 1 1 2 0 1 6 15/2/91 | 1 2 13 4 2 1 2 0 5 22/2/91 | 9 8 2 2 1 1 2 1 5 1/3/91 | 13 4 3 2 1 1 0 1 5 8/3/91 | 10 10 2 0 2 2 0 1 3 15/3/91 | 6 11 1 1 3 0 1 2 4 Table 1: Percentage Availability of DSAs Connected to JANET The general impression is that availability has not changed significantly since the last period ie it is not yet up to a good service level. Clearly it must be established whether the probe summaries are accurate or not before launching any investigation into whether the DSAs and associated software is working properly (although it should be noted that there are still some reports of unexplained DSA hangups). The fact that reports from different probes vary consider- ably casts extra ambiguity. This may indicate that the probes themselves are not totally reliable. However, it may also indicate a lack of statistical significance. Each probe attempts to bind to each DSA only about 30 times per week, and it is perfectly possible that a second probe will just happen to make its attempts at a period when the DSA is genuinely unavailable, albeit this unavailability was unno- ticed by the first probe. As an editorial note, the following is a suggestion as to some investigative steps that might be taken: o increase the probe rate significantly (and fix the scripts so that more sites can run them) to see if more statistically significant results can be obtained; - 16 - o devise a test to probe the basic X.25 connectivity to the machine hosting the DSA at the same time as the bind is made - this might shed light on whether there is an X.25 or higher level problem; o ask sites to record (and date) incidents whereby they have to reload the DSA or associated software due to a software problem, and to provide this information in their site reports. No attempt has been made to analyse the 0% availability column of Table 1. This is due partially to the lack of confidence in the probe results, but mainly because the for- mat of most of the summaries in this period, which identify sites by DSA (ie cute wildlife) name rather than site name, is impossibly tedious to analyse in order to produce a mean- ingful report. (The editor is not prepared to commit the requisite mapping table to memory!). Therefore the recent change to the scripts, that allow site names rather than DSA names to be used, is most welcome.