UK Academic Community Directory Group Minutes of Meeting on 2nd May, 1990 Paul Barker Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Seventh Meeting of the UK Academic Community Directory Group held at University College London on Wednesday, 2nd May, 1990. May 29, 1990 UK Academic Community Directory Group Minutes of Meeting on 2nd May, 1990 Paul Barker Organisation: UCL Document Location: UCL Present: Adrian Barker Bloomsbury Paul Barker UCL (Secretary) Steve Benford Nottingham Chris Bayliss Birmingham Jill Bell Bradford Asif Bhatti Reading Syngen Brown Kingston Poly Brian Bullen Stirling Dave Chadwick Salford Tim Clark Warwick Julie Cook Oxford Jonathan Couzens Imperial Shirleen Craig Heriot-Watt Jim Craigie JNT (Chair) Chris Elvin Surrey Andrew Findlay Brunel Karen Goswell RAL Mike Guy Cambridge Julia Hill Heriot-Watt Robert Hogg Bradford Peter Houlder Kent Catherine Kelleher LNT Steve Kille UCL Caroline Leary Sussex Chaoying Ma Cambridge Damanjit Mahl Brunel Diane McDonald Strathclyde Peter Morton Exeter Stefan Nahajski Brunel Julian Onions Nottingham Andy Powell Bath Colin Robbins UCL Graham Rule Edinburgh Linda Skordellis ULCC - 2 - Peter Stone Sussex Robert Stroud Newcastle Rodney Tillotson RAL Steve Titcombe UCL Bill Tuck UCL Alan Turland Edinburgh John Williams Aston Apologies for absence from: Bob Day RAL 1. Approval of the Agenda The following agenda was agreed upon: 1. Introductions 2. Review of minutes of the meeting held on 24th January 1990. 3. Matters arising. 4. Quipu implementation status report 5. Report on Pilot support activities 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. COSINE Project 11. DSA + Directory monitoring 12. Statistics 13. Use of the Directory to hold "external" information 14. Use of the Directory for Library Catalogues 15. Any other business - 3 - 16. Date of next meeting 17. Workshop on SUNOS, Quipu and X.25 for sites in the startup phase. 2. Approval of minutes of previous meeting The sentence in section 4.2 reading "A joint Quipu development proposal from UCL and Edinburgh had been accepted by the JNT." should be corrected to read "A Quipu development proposal from UCL had been accepted by the JNT. Some of the work would be sub-contracted out to Edinburgh." Additional to the comments made in section 8 about SUN responding to email requests for help, it was noted that suspected bugs should be reported to answer.centre@uk.co.sun. 3. Matters Arising Actions from the last meeting other than those below were taken as having been completed or dropped. Jim Craigie was required to write to academic institutions to determine their preferred name forms. This had still not been done. This action has now remained live for five meetings. The JNT had funded the Pilot so that each site could have a paper copy of the ISODE, and thus Quipu, manual. Thus far 19 had been delivered and more would be ordered for sites now joining the Pilot. The call for tenders for the Pilot support contract had still not been done, but would be issued the following day! Responses had to be with the JNT by the 18th May, 1990 The SUN which was used at Networkshop had still not been delivered to UCL to allow further testing of the installation scripts. It was noted that guidance would have to be given to those sites who had configured their systems using the original configuration scripts as to how to bring their systems in line with the revised configuration. This allows for a separate /var partition, adequate for the installation of SUN's coloured book software. An archive was required to make available a variety of documentation required to support the Pilot. These documents would soon be available from the UCL-CS info- server. - 4 - 4. Quipu implementation status report It was reported that UCL held a 3 month Quipu support contract which covered the period up to the end of June 1990. Sites were advised that they should have applied the patches which were circulated recently and thus be running ISODE- 6.1. This resolves a serious security loophole in ISODE- 6.0. 4.1. Long term developments UCL holds a development contract for Quipu. The following were some of the areas being or to be tackled: o Integration with MHS: start with distribution lists o OSI support: integrating NRS information into the Directory and providing OSI access to this information. A document discussing these issues would be produced shortly. o Management: tools were being produced to verify the integrity of the Directory; a probe had been written which could be used to "ping" a set of DSAs and report on their availability and time taken to connect. 5. Report on Pilot support activities Apart from attempting to provide telephone and email support to sites trying to run the Quipu software, a number of other activities had been undertaken under the aegis of the support contract. It was realised that there was a dearth of introductory material which would help a novice site to understand how to structure their data within an X.500 directory. Furthermore, advice was required on what object classes and attribute types were required and which were desirable. A document titled "Preparing data for inclusion an X.500 Directory" had been made available to the directory group, and would soon be available from the info server. A note on tailoring Quipu's logging was almost ready and would be circulated to the group within the next few days. These recommendations should be followed as they allow for the use of a DSA statistics tool which was ready for beta- testing. An ultra-naive users interface was ready for beta test. It was packaged as an interface for pad access to the directory. Currently this only allowed for querying within a single organisation, but it could be modified for more - 5 - general usage. Some other user interfaces written at UCL for use in the CS department could be made available to the directory group. These were not finished products, but represented useful bases for further honing. These would be advertised to the directory-pilot list. A data bulk-loading / data-merging tool was almost ready for testing. It operated on data which was essentially EDB format with minor extensions. It would be alpha tested at UCL for a short period and then made available for beta testing. An announcement would be made. The configuration scripts and companion document would be tested and revised as necessary when the JNT machine arrived from Newcastle. An archive of directory documents would soon be available from the UCL CS info-server. 6. Brunel user interface implementation status report 6.1. Networkshop Networkshop had provided a sharp focus for much of the recent work. Brunel took their "sd" interface plus 3 special X-based interfaces to Networkshop. One of the X interfaces had subsequently been dropped. The demonstrations and interfaces seem to have been well received at Networkshop. The interfaces all shared the following characteristics: o Read-only o Navigational o Designed to help people to find people The interfaces were available by file transfer. Either: FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) The files to be copied are named pod.tar.Z, sd.tar.Z and xd.tar.Z Thus far, 11 sites (in the U.K., U.S. and Australia) had taken the software. - 6 - 6.2. Other developments The concentration of activity in readiness for Networkshop meant that some other things had slipped a bit. In particular, Brunel were now behind schedule with the design document. There was no concrete progress with the PC version, although there had been some developments. The PC SIG had finally decided that a "PC" was a 286 or 386 machine with 2 Mbytes of memory capable of running Windows-2 under MS-DOS. A protocol stack had now been procured by the JNT. It looked quite different to ISODE, but there was insufficient documentation to make sound judgements as yet. It was anticipated that an MS-DOS product was not going to be available for some time to come. It was noted that there are 2 basic flavours of PC. The basic 640k machines would only be able to gain access to the Directory by means of communicating with an OSI server on a LAN. Salford noted that both the user interface could be run on the same PC if the interface code and the OSI code were separated. However this model relied on the formation of accurate queries, whereas the brunel interfaces were highly interactive. At least 2 sites queried the emphasis being placed on X interfaces. Since X was not yet widely available amongst the user population, it seemed to suggest that the pilot was more experimental rather than service oriented. 7. Other Directory implementations Marshall Rose had produced an X interface, which had been announced on the quipu mail list. The documentation for this interface would be made available in the document archive. Rutherford said that their "ibrowse" interface was potentially available, although it was not packaged into a distribution version. This runs under either X or suntools. Contact Karen Goswell at Rutherford if interested. An interface for a Macintosh was available, although Nottingham had failed to port it when they had tried briefly. Several sites indicated that they were interested in this interface. Steve Kille promised to find out details on how to obtain the interface. Several manufacturers (Siemens, ICL and Nixdorf) had demonstrated X.500 at CEBIT. - 7 - Prime say that they are working on an X.500 product. Xtel are also working on a DUA, but this was not yet available. This would run on UNIX systems with X. There was no further news of INRIA's Pizarro system. 8. Reports from Directory Pilot sites 8.1. New sites The Chair noted that one new site, Kent, had had their bid approved. Seven other sites had indicated that they wished to bid: Dundee, Glasgow, Imperial, Newcastle, Salford, Southampton and Warwick. 8.2. Support for new (and existing sites) There was then a lengthy discussion on the steps that should be taken to make life easier for new sites. It was recognised that several sites had expended too much effort on solving UNIX bootstrap problems. It had become clear that the boot script approach could never be made to work entirely satisfactorily as the machines started in an uncertain state. Two particular solutions were discussed: o The machines should all be delivered to one support site, and the machines configured there with UNIX, X.25, ISODE and Quipu. The support site would then forward the machines on to their final destinations, with possibly only network addresses to be configured. o The machines should be delivered to their destination sites. An expert would then go to the site and install the system under the gaze of those who would take over the running of the system. While these approaches to bootstrapping would help sites get involved in the Pilot much more quickly than before, the problem persisted that a number of sites, and particularly those late joining the Pilot, would continue to struggle for lack of UNIX knowledge. Kent said that they already ran UNIX courses for systems administrators which would probably be suitable, with modest tailoring, for the Directory Group. They would investigate the possibility of running a course for the group. In addition, Quipu training days were required. These could possibly be tacked onto the end of the UNIX course, or held separately. It was also noted that existing sites needed help with upgrading their systems in line with more recently installed systems. - 8 - 8.3. Discussion on main points in site reports The original wiring diagrams for connecting the SUNs to Camtec switchpads were found to be slightly wrong. A corrected version would be made available in the document archive. Problems with DSA relaying were noted. Due to lack of network connectivity, some parts of the DIT were cut off from many sites. This problem could be circumvented with DSA relaying. This is a very complex area but UCL promised to investigate and see if a simple but workable fix could be found. If such a fix proved feasible, this could be made available as a patch. Edinburgh noted that they had experienced problems where the software didn't report that an X.25 listen had failed to be established. They also suspected that temporary network failures caused listens to be lost, which were then not re- established when the network returned. Nottingham and Brunel said that they would investigate the problem. Edinburgh provided a very gloomy report which described how they had discussed obtaining data on their students from their university's administration, and been told that the university rules did not allow for this. Individuals would have to indicate that they were happy for their information to appear in the directory. The procedures for trying to elicit this confirmation would not be folded in with other existing administrative procedures. The Chair, while sympathising with their problems, indicated that this problem would have to be dealt with by an approach to the university's senate. If the university rules could not be amended to accommodate the Directory, the JNT would have to consider removing the machine from Edinburgh. While discussing Edinburgh's problems, it was noted that there was still no document which described the benefits to an institution of running an X.500 Directory. Heriot-Watt were cajoled into agreeing to produce such a document. Heriot-Watt reported that they had had a lot of configuration problems. It was hoped that some sort of machine pre-configuration, or provision of an expert, would help to ease these problems in the future. The issue of DSA names was raised. Some felt that naming the DSAs after South American wildlife gave the Pilot a rather frivolous aspect, which made selling the Pilot to the sombre-faced, besuited types in university administrations rather difficult. Others pointed out that these DSA names were not meant for public consumption, and that the problem was again one of not having suitable material for administrative people to peruse. It was further noted that - 9 - it was wrong to try to bind the name of a DSA to the name of an institution as this one-to-one mapping was not fully general. More than one site remarked that the SUN had to have a console connected to it: more specifically there was a problem disconnecting and reconnecting a terminal as this tended to cause the machine to hang. In fact, the requirement is that there is something continuously connected to the console port, but that this could be a suitably wired, special plug. The question was raised of whether sites replicating each others' data compromised their Data Protection Act registrations. Heriot-Watt said that they would consult the Data Protection Registrar for clarification of this point. A comment was made about the occasional poor performance of a DSA when the machine was apparently idle. It appeared that the process was wrongly being swapped out. A suggestion was made that the DSA process should be "niced" in the rc.local file. Rutherford said that it would nice to have more information on what the effective time-outs were in Quipu. Strathclyde, Heriot-Watt and Bloomsbury had all produced short articles on X.500 for site newsletters. These should be made available to the group. There was some discussion about the availability of a DUA for VMS machines. Various people had done work on porting ISODE onto VMS, but such systems were currently not freely available. A query was made about whether the sites' reports should be collated and turned into a report. Cambridge noted that these reports were mostly ephemera and thus such an exercise was not useful. The secretary pointed out that the reports, taken as a whole, contained a number of interesting points, the summarising of which would be of use to posterity. He doubted, though, that an individual could be found to undertake this task. But, in an act of monumental generosity, made all the more suspicious by the absence of the volunteer, Rutherford indicated that Bob Day was prepared to perform this task. 9. Report on RARE WG3 There had been a meeting of WG3 at the beginning of April. The meeting had discussed the status of X.500 activities in Europe. There was a considerable amount of Pilot activity in Europe, based on Quipu and Pizarro systems. The COSINE proposal was discussed (see next section). The Y-NET - 10 - project was considered. This was mostly concerned with making X.400 services available throughout Europe through a limited number of access points. It was possible that Y-NET might include some X.500 activity, but this was not yet clear. 10. The COSINE project A substantial proposal with UCL, ULCC, Xtel and the Dutch PTT as funded partners, and the JNT, as one of a number of unfunded partners, had been submitted. The focus of the project was to coordinate Directory pilot services in Europe. A system at ULCC would be used to connect together the national pilots and manage Directory knowledge. 11. DSA + Directory monitoring Some sample output from the monitoring tools was shown to the meeting. A report showed probing statistics for both root-level and GB-level DSAs. These reports demonstrated how much work needed to be done in the Pilot to improve reliability. The root level DSAs were contactable from UCL on average about 60% of the time. The figures for the GB DSAs was worse than this. More sites needed to run the monitoring tools in an attempt to identify problem areas. 12. Statistics A report was circulated which indicated the size of the DIT. Quipu DSAs keep a tally of how many entries they master, which makes production of such reports trivial for Quipu DSAs, but very difficult for non-Quipu DSAs. The reports shown contained the names of the DSAs, which some found counter-productive. It was generally felt that the reports would be perfectly acceptable with these names omitted, notwithstanding the remarks made earlier about binding DSAs to organisations. 13. Use of the Directory to hold "external" information Phil Jones had initiated a debate about whether the Directory could be used for storing information which was of general use to an institution, but did not yet appear in the Directory in the conventional manner. The problem was essentially one of how to integrate private directory information with public directory information, and whether the X.500 directory was an appropriate framework for achieving this. There was some measure of agreement that such institutional directory information should be stored in the X.500 Directory. The discussion ended rather inconclusively though, with no-one promising to investigate the problem more thoroughly. - 11 - 14. Use of the Directory for Library Catalogues A brief note, by Peter Stone of Sussex, on a library initiative to use X.500, was circulated at the previous meeting. Peter Stone gave a progress report to the meeting on activities since the last Directory Group meeting. There had been a couple of meetings, involving both X.500 and library specialists, where the ideas of storing library information had been discussed. Bill Tuck of UCL was writing a proposal for a demonstrator, which it was hoped would show the feasibility of distributed library information. Initially this information would comprise information on doctoral theses, both recently published and in progress. The idea of using the Directory as an interface to other databases would also be explored, but it was recognised that this was a much bigger problem. However, it was desirable to tackle this problem as currently each catalogue had its own interface. The proposal was due to be ready in two to three weeks. 15. Any other business None. 16. Date (and place) of next meeting. Wednesday 5th September 1990 in Edinburgh, University Staff Club, 9-15 Chambers Street. 17. Actions before the next meeting. JC To write to academic institutions to determine their preferred name forms. JMH To provide a document on the benefits of X.500, suitable for (but not liable to cause!) consumption by administrative people. JMH To check with the Data Protection Registrar that the registrations were adequate to cater for replicating data between institutions. JC To issue a call for tenders for the Pilot support contract. BDay To produce a summary of the directory pilot reports, containing all the nuggets of information of more than ephemeral interest. PH To investigate the possibility of Kent running an introductory course on UNIX - 12 - AF JPO Investigate the problems caused by X.25 not being there when Quipu is started, and the consequences of X.25 going away for short periods after Quipu has started successfully. developers Investigate whether a simple fix can be made to implement DSA relaying to prevent large parts of the DIT being cut off from DUAs in the JANET community. support Provide guidance to sites who configured their systems using the first version of the configuration scripts in order that they may align their disk partioning with the layout subsequently adopted. PB To create a Directory Pilot document archive SEK To discover how to get hold of the Directory interface for the Macintosh