UK Academic Community Directory Group Minutes of Meeting on 13th June, 1991 Paul Barker Organisation: UCL Document Location: UCL _A_B_S_T_R_A_C_T Minutes of the Eleventh Meeting of the UK Academic Community Directory Group held at Brunel University on Thursday, 13th June, 1991. August 9, 1991 UK Academic Community Directory Group Minutes of Meeting on 13th June, 1991 Paul Barker Organisation: UCL Document Location: UCL Present: Shafiq Ahmed Nottingham Robert Ash Aberystwyth Brian Bailey Brighton Poly Adrian Barker Bloomsbury Paul Barker UCL (Secretary) Chris Bayliss Birmingham Steve Brabner British Telecom (guest) Syngen Brown Kingston Poly David Chadwick Salford Jim Craigie JNT (Chair) John Cullen RAL Ian Dallas Kent John Dardis ULCC Ian Dickinson Warwick Susan Feng Imperial Andrew Findlay Brunel David Goodman UCL Karen Goswell RAL Fred Greyer Queen Mary & Westfield Mike Guy Cambridge Steve Hardcastle-Kille UCL Allan Hawdon Kings Julia Hill Heriot-Watt Stuart Keir Sussex Kathy Kelleher LNT Kevin Large UMCC Christina Lau Kent Ravinder Lyall Southampton Damanjit Mahl Brunel Peter Mills UMCC Roger Gander OU Dhiru Patel RAL Pava Pavanantham Surrey Colin Robbins X-Tel - 2 - Graham Rule Edinburgh Kel Shorey Strathclyde Rodney Tillotson JNT John Williams Aston Apologies for absence from: Jill Bell Bradford Julie Cook Oxford Colin Cooper Glasgow Andrew Hillborne Newcastle Richard Letts Salford John Linn Aberdeen Julian Onions X-Tel Ray Powell Leeds Steve Titcombe UCL Chris Wooff Liverpool _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 21st March 1991. 3. Matters arising. 4. Quipu implementation status report 5. Quipu support status report 6. Brunel's user interface implementation status report 7. PARADISE DUA Development 8. Status of other known Directory implementations 9. Directory pilot sites status reports 10. Report on the RARE Working Group 3 and RARE Directory Project 11. Report on PARADISE project 12. Report on IETF Directory Group - 3 - 13. Public access DUAs 14. Proposed project to provide DUAs on VMS. 15. Generation of mhs-or-address attribute 16. SunNet X.25 version 7.0 17. Document on Explanation of the Directory for Administrators 18. DSA Probe 19. Internet ts-community 20. Presentation of BT's COHORT 500 system by Steve Brabner 21. Any other business 22. Date of future meetings _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 The minutes were approved. _3. _M_a_t_t_e_r_s _A_r_i_s_i_n_g A PostScript version of Julia Hill's guide for administrators would be made available from the UCL-CS and X-Tel document stores, once John Dyer had dealt with some PostScript problems. Rodney Tillotson had received material from 3 people on codes of conduct. These contained rather general wording about "reasonable usage" of systems, and usage being "for academic purposes only". A number of comments were made. Care would be required with the wording as the Directory wasn't just restricted to the academic community. We were in the fortunate position at the moment of not having to pay for the service - it should be borne in mind that the introduction of charging might require rules to be rewritten. The code should say something about junk mail (it seems nobody wants to receive Reader's Digest). The code should say something about the use of the Directory to make lists, although the use of the Directory to verify the accuracy of lists was another matter. The code should comment on exhaustive searches. Rodney Tillotson would prepare a draft for consideration at the next meeting. The action on Rodney Tillotson to package the Rutherford mail responder and DSA checker, and send them to X-Tel, had been transferred to John Cullen. - 4 - The letter explaining sites' responsibilities with regard to hardware and software maintenance on the Directory machines had not yet been written. This came as no surprise! There were conflicting reports on the continuing availability of SUN's software upgrades on tape. Jim Craigie had been told that the default distribution was to be on CD-ROM, but that sites without CD-ROMs would still get upgrades on tape. SUN might consider supplying CD-ROM drives for those machines delivered without them. However, both Edinburgh and X-Tel had been told that SUN would not be making upgrades available on tape beyond the end of this year. Clarification was needed. Colin Robbins confirmed that sites should ask for "three star" maintenance from SUN - this translates to 8 working hours response time for hardware and best effort for software. A note on this would be made available from the document stores. Andrew Findlay had not provided details of what subset of ISODE was required to support the building and running of DUAs. It appeared as though no-one had tried to build ISODE on different platforms. An impromptu survey revealed that ports for the RS-6000, Sequent, MIPs and Orions (and possibly some others) were required. Reporting of porting efforts was vital to prevent the repetition of hard work. Any portability problems discovered should be sent to bug- isode@uk.co.xtel. Colin Robbins reported that more DSAs (10-15) were now listening on IXI. Was there a note on how to set this up? Yes, there had been a message, and this would be resent to the list. It would also be placed in the document archive. The latest distributed version of the probe was found to cause problems (machine crashes) and this had to be fixed before more sites could run the software. Warwick volunteered again to run a probe when the problems had been resolved. _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 A lot of effort that would normally be expended on development had been used in deploying and debugging ISODE- 6.8. Progress was also hampered by staff illness. Quipu had been ported to SVR4. A new user interface, de, had been developed for the PARADISE project. - 5 - Most of the work on interoperability had now been done. The next phase would see work on subtree replication and cache parameterisation. Internet DSP had been added to Quipu. This offers a more flexible and scalable approach to replication. Work on the management tools was progressing, albeit slowly. More work had been done on the probe: it was a much harder problem than originally envisaged. Some more work had been done on the statistics tool, which could now produce more concise summaries. There was now support for Quality of Service attributes, but these were not as yet used by current DUAs. _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 Colin Robbins noted that some sites had reported problems in their site reports, but had not contacted X-Tel regarding these problems. In most cases, fixes were available for the problems reported. Documentation bugs should also be reported to X-Tel. Problems with configuration of the X.25 set-up at the sites had hindered progress in a number of instances. The ability to get an X.25 PAD connection to a site's machine was a _s_i_n_e _q_u_a _n_o_n for further progress with any Directory related problems. It was recognised that Quipu's error messages were not always as clear as they might be. Work was going into improving them, in particular to make it clear when a message was just a warning, and when it indicated something serious. Janet's X.25 had been very poor recently, with floods of resets making the network unusable for periods. There was known to be a problem with 2Mbit lines and NetComm switches. It seemed as though sometimes a reset would then cause a cascade of resets. David Goodman of the PARADISE project was putting together a report on this to go to the Network Executive. The problem of "watchdogs" (ISODE getting into a pathological tangle in its lower layers) was just about fixed. A presentation layer problem had been found in the course of interworking tests with the Pizarro implementation. A method of fixing the problem had been thought through (preserving backwards compatibility) but awaited implementation and testing. - 6 - Very little use was being made of the bug database. This contained bug reports (and some fixes!) for ISODE, Quipu and PP. It was agreed that it would beneficial if the bug list was circulated to the pilot list periodically (once a month?) to serve as information, and as a reminder that the facility existed. People were asked to note though that it wasn't essential that every fix be applied: fixes that were vitally important would be signalled to the list. An era had ended! The big man (Marshall T. Rose) had stepped aside and the ISODE source tree was now managed by X-Tel. There is an ongoing attempt to set up a consortium, following the model used by the developers of X. This would see early releases of the software being made available to commercial organisations, and better documentation. ISODE would remain openly available. Graham Rule asked for a separate, documentation free, version of the source tree to be made available. This would produce a substantially smaller distribution. Ways of splitting the release into more manageable lumps were already under consideration. _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 A small amount of maintenance work had continued on the interfaces sd, xd and pod. A test interface, doog, had been used to test the _q_u_e_r_y _e_n_g_i_n_e. Following testing, the query engine was now quite closely aligned to the user-friendly-naming rules. It was possible that doog might be developed more fully: doog had been made available as the Brunel public access interface and comments were broadly favourable. Doog was available from Brunel via NIFTP - doog requires the ISODE-6.8 libraries to compile it. Doog would also be included in ISODE-7.0 if Damy could wrap it up quickly enough (final date was the following day!). Most of the recent work had been on the PC DUA. Integration of the interface with the protocol stack awaited testing of the "WhiteStack" against the ISODE stack. It was hoped to have a beta version of the PC interface available in October or November this year - it has hard to be precise as so many "new" areas had to be tackled by the developers. The windows-3 version would be the first available. There had been a meeting on address books (attended by representatives from Brunel, UCL, Nottingham and Edinburgh) and the use made of them by mail and directory user agents discussed. Consideration had been given to how address books should be stored, and the need for an address book transfer format. - 7 - In response to a question, a summary of the status of existing user interfaces was given. (A couple of these weren't listed at the meeting, but I have added them into the table here for completeness.) 8 __________________________________ 8 __________________________________ Style Extant Retired 8 ____________________________________________________________________ X pod xd Xlookup xdsm 8 __________________________________ suntools sunint 8 __________________________________ scrolling doog ufn de dsc fred 8 __________________________________ full screen sd 8 __________________________________ management dish 8 __________________________________ 7 |7|7|7|7|7|7|7|7|7|7|7|7|7|7| |7|7|7|7|7|7|7|7|7|7|7|7|7|7| |7|7|7|7|7|7|7|7|7|7|7|7|7|7| |7|7|7|7|7|7|7|7|7|7|7|7|7|7| _7. _P_A_R_A_D_I_S_E _D_U_A A user interface called de had been produced for the PARADISE project. This interface was designed specifically for use as a public access dua, although it could be tailored sufficiently that it might work well in other environmnents. The interface was available for testing on JANET and IXI - the address had been advertised to the group. Comments on the interface were welcome, and should be sent to Paul Barker. _8. _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 It was noted that there had been a survey of existing DUAs/DSAs. This would be made available from the UCL-CS and X-Tel document archives. As there was such a large choice of Quipu compatible user interfaces, it would be useful if sites could experiment with a number of interfaces and provide evaluation reports to the group. _9. _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 Thanks were due on this occasion to Rodney Tillotson for collating the site reports into a manageable summary: there were now 32 sites listed. Birmingham, the Open University and Reading had failed to provide a report, as had Bradford (who apologised for not providing one). - 8 - Exeter, Kings and Ulster were awarded gold stars for the fullness and clarity of their reports. Following comments on the confusion resulting from the myriad ISODE daemons, Colin Robbins will provide a tutorial at the next DG meeting. There was a lengthy discussion on data management tools. Crude tools obviously existed as the Directory was populated with some data. It was pointed out that there were two separate issues. First, sites had to have enough expertise to process their data into EDB files or some bulk loading format. There was almost no commonality of source data formats - maybe there would be one day following the UGC initiative? Second, the problem of merging data from more than one source had barely been tackled. A few sites had some crude tools. There was a suggestion that pilot sites should send their management tools to X-Tel, who would hold the collection. At least half the sites indicated that they would find a course on data preparation / management useful, and Andrew Findlay and Paul Barker agreed to try and set something up. Existing tools, course requirements, etc, should be sent to Paul Barker. NRS names were used inconsistently, with some people using .dir, or .directory, as a login and others using it as the access point to the directory. Since these machines were not intended as login servers, an NRS registration for this purpose seemed inappropriate. Thus, the NRS name should be the name of the directory access point. It was reasonable to have a public access point per site, as the interface could be tailored for local use. Details were requested on setting up X.29 listeners. These would be sent to the mail lists and put in the document archives. The "glossy" documents for administrators were due any day. Printed manuals for ISODE-7.0 would be available from UCL and X-Tel. This substantial tome was the only relevant manual. Steve Kille has a forthcoming book which, amongst other things, packages the Quipu and PP documentation. Information about the book would be circulated to the list. (Note also that the Quipu course notes can be obtained from X-Tel at a cost of 15 pounds per set.) _1_0. _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. They were also looking into establishing a series of documents, in the style of the Internet RFCs, - 9 - setting out guidelines and policy on a number of Directory issues. _1_1. _T_h_e _P_A_R_A_D_I_S_E _p_r_o_j_e_c_t The PARADISE project had established a central DSA on a machine at ULCC in February 1991. This held the root of the world and the GB data. A central DUA was due to become available at the time of the meeting. The size of the DIT (best guess) was currently 322k entries. There were 101k entries in Europe, of which 66k were GB data. Copies of the PARADISE international report were circulated at the meeting. The next report was due in November. It was hoped that this next report would have sections on: o User surveys o The sort of use being made of the Directory o Data management problems A number of mail lists had been set up which were intended to focus discussions on particular topics such as user interfaces and data management. _1_2. _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 There had been an experimental meeting of the this group by way of video conference. Seven of the Internet drafts were being submitted for formal adoption as RFCs, and some other documents were being worked on. Another group had been set up called DISI (Directory Information Services Infrastructure). This group would concentrate on support for sites and users, whereas the focus of the IETF was more technical. _1_3. _P_u_b_l_i_c _A_c_c_e_s_s _D_U_A_s Dave Chadwick had recently tried to demonstrate the Directory in a practical to a group of students at Salford. He and the students had had mixed success. They had contacted a number of public access duas. It was apparent from his comments (in a written report) that these had a variety of versions of the software installed. The relatively poor results of the experiment appear to be have been caused to some extent by the X.25 reset problem, and not using a transport protocol which can perform basic error recovery. Another problem (sd only taking the first digit of a sequence of digits) may well have been due to an X.29 parameter problem. - 10 - Dave Chadwick suggested that students make better guinea- pigs than staff for testing the Directory, being critical and meddlesome. They also usually leave after a short stay! On the other hand, if staff were put off now, it might be hard to win them back later, when the quality of the service had improved. Complaints about DSA names being displayed by user interfaces was again raised. In fact, this mis-represents those who complained. The nub of the complaint is that the DSA names displayed are animals, and this is makes the Directory appear frivolous, hard to promote, etc. One of the causes of the problem was that DSA entries were high up in the DIT hierarchy, mixed in with the organisational data. Steve Kille had a note which proposed a revised solution to the storing of knowledge. The secretary expressed the view that no right-minded user interface should show DSA names. If system administrators needed tools to help them discover why queries were failing, they should have special tools for this purpose, which did appropriate mappings between DSA names, institution names and DSA managers' names, and whatever else was needed. There was some discussion on the frustration caused by time limits curtailing searches which were often just about to bear fruit. The secretary outlined the approach taken the the de interface: no time limits, but a message being displayed suggesting that there may be problems if an operation takes a long time, and offering the user the opportunity to cancel the operation. _1_4. _D_U_A _f_o_r _V_M_S _s_y_s_t_e_m_s There were a lot of users in the academic community who used VMS systems, and it seemed a matter of urgency to provide a native DUA for these users. A request for bids to produce such a DUA had received a limited response. It was noted that a group in Spain were tracking ISODE and porting to VMS. However, they hadn't ported any of the user interfaces other than dish. The discussion was rather negative as to the needs of the VMS community. It was suggested that such a community could be served by various front-ends. One possibility was to use the Directory Assistance Daemon model (described in the previous set of minutes), but this requires a non-OSI protocol between the user interface part and the DUA protocol engine running on another (presumably UNIX) host. Another possibility was to provide a skeleton interface which made a pad call to UNIX systems running an existing interface. It was queried how effectively such an interface could be made to look like the normal VMS fare. The Chair was aghast at this discussion. Why should VMS users be treated so shabbily? Why did MAC users deserve a native - 11 - interface whereas VMS users didn't? It was pointed out that the VMS and MAC environments were rather different: MAC users loved clicking their mouse button(s), whereas VMS users were a more primitive bunch - high energy physicists to a (wo)man!! Kathy Kelleher was going to raise the matter of VMS DUA requirements at a forthcoming Network Users Group meeting. _1_5. _M_H_S-_O_R-_A_D_D_R_E_S_S _a_t_t_r_i_b_u_t_e_s X-Tel reported that a tool had been produced. It required dish to be compiled with PP. It was then possible to enter the mhs-or-address attribute as an rfc822 address and the dua would convert it to an mhs-or-address. However the tool was unsuitable for distribution as a stand-alone package, since it required the PP tables. Steve Kille expressed the view that there was currently no pressing need for this tool. When there was, installation of PP and Quipu would have reached the stage where the provison of such a tool would "fall out". _1_6. _S_u_n_N_e_t _X._2_5 _v_e_r_s_i_o_n _7._0 Jim Craigie had provided X-Tel with a list of questions on SunNet-7.0 which he wanted answering. There was as yet no pressing need to install this software. No applications can make use of the X.25(84) facilities until the routing tables have been loaded with the SNPA to NSAP binding. Work is underway to get these bindings from DERFIL3 but will not be ready until the autumn. The software can be obtained either by direct purchase from SUN or automatically under an X.25 software maintenance contract with SUN. There was a need for a limited experiment of running Quipu over CONS, and volunteers were required. When it all worked, this would become the preferred stack. Volunteer sites will need to have a NSAP allocation policy, some way of deriving new NSAPs, and to register them in the NRS. ISODE was likely to be ported onto version SunNet-7.0's X.25(84) by mid-July. Pink-book had already been demonstrated to work, although it required a substantial amount of fiddling around with tables. It was not clear when all the other coloured book software would run over CONS. Greybook should work using SUNs CONS, but PP will need some extra code for the NSAP addressing, and there is no active PP development in this area. The X400(88) PP channel is currently in beta test and should workover CONS once the - 12 - CONS routing tables are in place. _1_7. _D_o_c_u_m_e_n_t _o_n _t_h_e _D_i_r_e_c_t_o_r_y _f_o_r _A_d_m_i_n_i_s_t_r_a_t_o_r_s. The document was almost ready for distribution. There was no further discussion. _1_8. _T_h_e _D_S_A _p_r_o_b_e Jim Craigie pointed out that the probe's figures were inconsistent. In some cases, the "best" connect time was worse than the "worst", and vice versa. It was possible that the shell script approach would be reconsidered, and the tool rewritten in C. _1_9. _I_n_t_e_r_n_e_t _t_s-_c_o_m_m_u_n_i_t_y Jim Craigie had sent a message to the group saying that it was inappropriate for Janet sites to include Internet in their list of ts-communities, even as a last resort. The relay DSA approach could be used to maintain stack purity on Janet. It was noted that this approach meant that there was a single point of failure at the relay DSA, and that this DSA was already very heavily loaded at times. Dark looks abounded as some of those present took fixes of being religious, or irreligious, about protocols. _2_0. _P_r_e_s_e_n_t_a_t_i_o_n _o_n _B_T'_s _C_O_H_O_R_T _5_0_0 Steve Brabner from British Telecom came to talk to the group about the vaunted COHORT 500. His message was something along the lines of: "I've seen it, and it works!". The background to COHORT was that of a picture of chaos in the field of directories. Interest in directories in organisations was primarily as support for telephone operators and for producing printed directories. Support for email came a distant third. COHORT was a corporate directory aimed a solving the directory needs of a single organisation. Asked about where COHORT fitted in with X.500 and the global Directory, SB said that there was only a limited demand for access to other organisations' data. In any case, organisations would not make much of their data publicly accessible by X.500, probably no more than they currently revealed in the current phone directories. Organisations would worry about staff poaching if names and corresponding roles were displayed to the world. Most organisations still placed great store in printed directories: COHORT could be used to produce input for a typesetting package. - 13 - A fundamental characteristic of directories used by telephone operators was that response times had to be sub- second. COHORT could achieve a response time of 300ms on substantial volumes of data. The COHORT system seems well suited to organisations with a strong sense of hierarchy, and it is possible to examine up and down the hierarchy by role. There were practical limits on how much detail about organisational structure one could represent, as complex structures required considerable effort to maintain the data quality. There were currently about 12 large systems in place, some of which were in BT itself. Where did this fit in with X.500? The underlying data model followed the X.500 schema. Some large organisations (and in particular government) were very much in favour of procuring systems which were standards aligned. Furthermore, other organisations were interested in standards, as it was beneficial to invest in technology which was likely to be widely used and long-lasting. X.500 access from the pilot to a BT test system would soon be available. _2_1. _A_n_y _o_t_h_e_r _b_u_s_i_n_e_s_s There was a brief discussion about the incorporation of the uumap data into the X.500 Directory. In fact the data was already in the Directory, but rather hidden away under c=gb@l=uumap. The data contained about 800 entries and provided contact names, addresses and telephone numbers for UK uucp sites. It was suggested that it might be useful to use the uumap data when there was no other data available for an organisation from other sources. It might be possible to coordinate with the managers of the uumap data, so that the data could be annotated in such a way that its inclusion in the X.500 Directory could be readily automated. The idea lost favour when it was pointed out that the contact information for most of the organisations was for an individual with responsibilities for networking, rather than being a contact information for the organisation as a whole. _2_2. _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_s. Thursday, 3rd October, 1991, at 10.30, 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)). The meeting after that was scheduled to be at Birmingham on - 14 - thursday, 16th January, 1992. _2_3. _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. J Dyer To make available the PostScript of the administrator's guide so that it can be placed in the document archives. J Cullen John Cullen to send Rutherford's Directory mail responder to X-Tel for distribution. J Cullen To send Rutherford's DSA-checker to X-Tel for QA. RT Rodney Tillotson to prepare draft code of conduct. JC Letter explaining sites' responsibilities with 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 - further clarification required. CJR To give a tutorial on the ISODE daemons at the 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 test and evaluate some of the plethora of user interfaces described in the "X.500 Product and Public Domain Implementation Survey". SEH-K To send details of his forthcoming book to the list. X-Tel To put the note on recommendations for maintenance with SUN in the document archive. X-Tel Periodically send index of bug reports / fixes to the pilot list. PB & AF To try to arrange a course on data preparation and data managing. all To send requests for the aforementioned course, - 15 - and any useful data preparation scripts to Paul Barker CJR Circulate to list (and archive) message on how to get a DSA listening on IXI all To get their DSAs listening on an IXI address ST Steve Titcombe to examine irregularities in probe figures K Kelleher Kathy Kelleher to raise the matter of VMS DUA requirements at a forthcoming Network Users Group meeting. - 16 - _A_p_p_e_n_d_i_x _A Summary of Directory Pilot Site Reports, June 1991 Rodney Tillotson (Joint Network Team) 1. Introduction This paper summarizes the Pilot Site reports produced for the JNT Directory Pilot meeting on 13th June 1991. By Friday 7th June 22 of the sites had sent a report. 2. Hardware and communications The only site to report trouble with their Sun was Rutherford, who had had two disk replacements. A few people had not found it straightforward to establish an X.25 connection. Oxford discovered some odd X.25 behaviour which no longer has an impact on service. 3. Basic system software No problems are reported with any release of SunOS, nor with upgrades between them, although some sites seem cautious about the effort involved in an upgrade. Several sites are planning to move to 4.1.1 over the summer. Sun are moving to CD, and will no longer routinely distribute SunOS upgrades on tape. 4. ISODE and DSA software Several sites are planning to move to 6.8 over the summer; well over half should by then be running this release. The upgrade scripts from X-Tel seem successful. Faults reported are: DSA invisible to local DUAs (Aston); "Watchdog activated" (Exeter); DSA stops (Heriot-Watt); DSA stops (Imperial); DSA stops in edb-update (Rutherford); Unix-niftp 5.6.0.2 bug (Salford); Multiple users of public-access DUAs cripple performance (Salford); Probe made DSA unreliable (Warwick). 5. DUA software No clear picture of DUA deployment emerges; most sites are now offering something more friendly than dish and looking for something better still for - 17 - their local users; the PARADISE DUA and the psiwp Mac DUA are each praised. Some sites are setting up public access DUAs, and for some of those the access is through JANET - they are concerned about NRS registration. Experience of Directory-naive users at Salford gave a mixed assessment of the DUAs at present used for public access. 6. Provision of data Again, a lot is expected to happen over the summer. There are more reports of technical work going on to install data, and fewer of Administration departments making it difficult or impossible to start. At Aston and Stirling there is interest in using the Directory as the source for certain administrative databases, rather than shadowing a more traditional source. Little detail is given about data maintenance. The most specific comments mention bulk loading from external databases, and there are one or two questions about letting users modify their own entries. Data in place: Rutherford, Stirling, ULCC, Liverpool (data not complete), Bath, KCL, Warwick (no regular updates), Sussex (data provided by Admin). Held up technically Aberystwyth, Heriot-Watt, Southampton, Strathclyde, or for effort: Aston (Admin keen), Bloomsbury (no e-mail addresses), Exeter (political discussion also continuing), Oxford, Salford (little data). Held up politically: Edinburgh (though no longer hopeless), Glasgow (opt-in), Imperial (update delayed), Kent (outline permission only). Still to start: Ulster. 7. Real users Most sites link the promotion of a service to real users with the provision of their own data, which is reasonable enough; most expect it to be "in a few months" or "next term". 8. Operational availability (%) 100 90+ 80+ 70+ 60+ 50+ 25+ >0 0 week to 22 Mar 8 7 1 1 2 2 1 2 4 29 Mar (results combined with the following week) 5 Apr 7 9 4 0 1 2 1 3 1 12 Apr 5 12 4 1 1 1 1 1 2 19 Apr 9 4 5 3 1 1 1 0 4 26 Apr 3 May 6 9 4 0 1 1 2 2 3 - 18 - 10 May 10 5 4 1 0 1 2 1 4 17 May 11 8 3 1 1 0 3 1 6 24 May 0 7 7 4 1 5 2 2 5 31 May 5 15 4 0 0 0 4 3 2 7 Jun 0 2 7 7 5 2 3 2 4 Availability distribution of DSAs as seen from JANET Most weeks about half the JANET addressed DSAs were found by the probes at least 90% of the time. Something awful seems to have gone wrong the last week. As in previous summaries, the interpretation of the probe results is uncertain; we should consider to what questions it is trying to supply the answers. The recent "dsa_available" heading helpfully shows the level of achievement of DSA operators, but gives less idea of how complete the DIT will appear to a user, to whom the separate JANET and IXI ratings are more relevant.