UK Academic Community Directory Group Minutes of Inaugural Meeting: P. Barker Date: Oct 19, 1988 Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Inaugural Meeting of the UK Academic Community Directory Group held at the Computer Science department of University College London on Friday 7 October 1988. May 30, 1990 UK Academic Community Directory Group Minutes of Inaugural Meeting: P. Barker Date: Oct 19, 1988 Organisation: UCL Document Location: UCL Present: Paul Barker UCL (Secretary) Chris Bayliss Birmingham Max Caines Wolverhampton Poly Alan Cox NERC Jim Craigie JNT (Chair) Andrew Dand SWURCC Neil Davies Bristol John Dyer JNT Andrew Findlay Brunel Steve Goddard IC Mike Guy Cambridge Julia Hill Heriot-Watt Jeremy Isserlis RAL Phil Jones JNT Mick Kahn LNT Steve Kille UCL Caroline Leary Sussex Andy Linton Newcastle Peter Mills UMRCC Stella Page UCL Bob Proctor Southampton Colin Robbins UCL Graham Rule Edinburgh Jamie Slee Open U. Peter Stone Sussex Alan Turland UCL 1. Appointment of Secretary In the absence of any other offers to act as Secretary, the group reluctantly agreed that Paul Barker should perform - 2 - this function. 2. Approval of the Agenda The following agenda was agreed upon: 1. Objectives of the Group. 2. Status of Directory Standardisation. 3. Review of Functionality available in initial QUIPU and THORN implementations. 4. Construction of pilot Directory Services. 5. Requirements (longer-term) for Directories in the UK AC. 6. Date of the next meeting. 3. Objectives of the group. This was, predictably, a very wide ranging discussion! This is intended to represent the flavour of what was said. 3.1. Reaching the right community It was clearly realised from the outset that a large part of the problem of establishing an X.500 Directory Service lay in persuading senior administrative people that X.500 offered them something that was needed. A top-down approach was required just as much as a bottom-up approach. Enthusiasm thus far had come from the bottom up. Those at the meeting were almost exclusively from the Computer Science and networking community. To this end, several organisations or levels of organisation were cited as meriting approach. - IUCC (Club for Computer Centre directors). Computer centres were a "natural" organisation to run DSAs - IUNC (Inter-University Networking Committee) - IUSC (Inter-University Software Committee) - NIS (Network Information Services) - CVCP (Committee of Vice-Chancellors and Principals). University administrations need to be lent on from above to be co-erced into providing information. It was suggested that an approach might be made to see if a speaker could address this community at an annual meeting. - 3 - 3.2. Promoting Directory Services The need was seen to present a clear view of what Directory Services could offer people. People would not be interested in providing data unless they could see what the service offered them. The following points were made: - Selling the system was hard while so few senior university staff made use of electronic mail, file transfer facilities etc. - The issue of confidentiality frightens a lot of people. The service would initially have to focus upon telephone numbers and addresses, both email and paper. Providing email addresses was seen as the principal virtue of the Directory Service. - There was seen to be a need for a list of carrots to dangle in front of the unconvinced. One (about the only one) suggestion was that Directory Services might lead to more direct dialling and that this might imply a saving on operators. - A characteristic of the directory was that compliance with the Data Protection Act came for free. Making information available to the data subject, as well as others, fell within the scope of Directory Services! 3.3. The Initial Pilot It was agreed that it was essential to mount some sort of service quickly, if only to establish what was wrong with what was offered. This would be at a limited number of sites. In the longer term it was envisaged that there would need to be at least one DSA per site. However limited an initial pilot exercise was, there were many other groups interested in this area and their data would be available. RARE were trying to coordinate a European pilot and IDEM were also interested in using X.500. 4. Status of Directory Standardisation - The X.500 standard is now very close to a final 1988 version. The most up to date currently available version is the output from the March 1988 Geneva meeting. - Since it is obviously desirable that all concerned have access to recent to a recent copy of the standards, Bristol agreed to produce in sufficient numbers a "yuppy" A5 version of the X.500 standards. - 4 - - X.500 1988 is a far from all-embracing Directory Services standard. While nothing fundamental (whatever that means) is missing from the new standards, the following areas are outside the current scope or are not fully dealt with: access control, replication, schemas, distributed operations. 5. Review of THORN and QUIPU implementations UCL has been funded by two separate ESPRIT projects to work on Directory Services. These projects have produced and are producing Directory Service implementations aligned to the current standards, X.500/IS9594. These implementations are and will be made available to the UK academic community. The JNT has agreed to provide funding for the development and support of the QUIPU system, and it has agreed to provide support for the THORN system. 5.1. THORN THORN (THe Obviously Required Nameserver) is a project funded under ESPRIT 1. It is a multi-national project with both industrial and academic partners. The project's main brief has been to track emerging international standards and to produce conformant software. Two distinct phases can be identified in the project's work. 1) A Directory Service implementation was produced conformant to the ECMA TR32 protocol. 2) The second phase has two principal aspects. - An X.500 Directory Service implementation is being produced. This should be reasonably stable by March 1989 and available to the UK Academic community shortly afterwards. - A Large Scale Pilot eXercise (LSPX) has been running in an attempt to establish a "real" Directory Service with "real" users. A major point of interest in the exercise has been the tackling of the problems of data gathering and data management. Participants include academic sites not directly connected with THORN. This service is currently based on the ECMA TR32 protocol. There will be a transition to an X.500 based LSPX as soon as the X.500 software becomes sufficiently stable. 5.2. QUIPU The QUIPU directory software has been developed under the - 5 - INCA (Integrated Network Communications Architecture) project also funded under ESPRIT 1. The implementation is now widely available as part of the ISODE package. The INCA project required a Directory Service to support MHS, OSI applications in general as well as a stand-alone directory. The status of the software can be considered now in terms of ISODE releases. - ISODE-4.0 (available since July 1988) provides a full Directory Abstract Service and Directory Access Protocol. Its Directory System Protocol is non- standard. - ISODE-5.0 (expected December 1988) will support the standard Directory System Protocol. There will be support for common X.400 attributes and object classes. 5.3. THORN vs QUIPU A comparison of the two implementations follows: THORN QUIPU Design Large team working Lightweight approach with towards full implem- view to getting a system entation. working as quickly as possible. Performance criterion important for Directory use as nameserver. Database Special purpose Data in main memory, highly extensible loaded on start-up, fast, DSA database size limited by swap space Interfaces curses based command Directory Shell, driven, widgets X-windows, widgets Code Possibly binary only source code, comes with availability ISODE package. Hardware/ Variety of obscure any UNIX machine running OS/stack Euro-hardware + SUNs ISODE & Vaxen running UNIX with ISODE Evolution Possible inclusion in Experimental system, commercial products freely and widely available 5.4. Interworking THORN and QUIPU necessarily tackle issues such as Access Control and Schemas in their separate ways. There needs to - 6 - be discussion on where such disparities cause interworking problems. 6. Construction of a Pilot Directory Service 6.1. The number of players There was some discussion on how many institutions were needed initially to get a Pilot service established. It was felt that at least six volunteer organisations were needed, possibly three using the THORN software and three using QUIPU. Shaking out the systems and promoting interconnectivity was best served by porting more than one flavour of X.500 system. It appeared at the meeting that there would be no difficulty finding that number of volunteers. However such volunteers would have to get clearance from their organisations for the allocation of time and resources. It was also hoped that the Pilot would rapidly expand to include 40 institutions by later next year. To try and achieve greater coverage as quickly as possible, two other possibilities could be considered. - Sites with DSAs providing a service to neighbouring sites without DSAs - Some sort of centralised DSA to include data not available in locally distributed DSAs. It was also recognised that such a Pilot would not be experimenting in isolation. - RARE were trying to coordinate a European-wide Directory Service. - There would also be the partners currently involved in the THORN LSPX. - In addition UBC was producing an implementation which presumably implies a further contingent of DSAs. 6.2. Charging There would be (initially at least) no problems here! - The software would be freely available (although use of the THORN code would have to be licensed) - The pilot would receive central funding - DSA referral rather than DSA chaining simplifies charging issues. - 7 - 6.3. Commitment to the Pilot Directory Service The following areas were identified where commitement and resources were required in participating in the pilot Directory Service: - Effort was required to mount the software. This obviously implies making available appropriate hardware running UNIX and ISODE. Appropriate hardware currently means: SUNs with SUNLINK X.25 Vaxen with Camtec boards or DMF 32 - Data acquisition would be a major task. Persuading administrators to part with their data was a major political exercise. Having obtained the data, there was then the problem of transforming the data into a suitable load format. The possibility was recognised that there were a number of similar database systems currently employed to store data. These systems had to be investigated to avoid unnecessary duplication of effort. The following sources of data were suggested: University administrative records - usually quite accurate, but lacking phone numbers. Phone directories - maybe the best line of initial attack UCCA tapes - maybe not much usable, useful information - Maintaining the data would require substantial effort. Until the day when the directory was considered as mastering data, there would be a range of problems associated with keeping up to date shadow copies from the principal sources. 7. Longer term requirements for Directories in UK AC - The scope of the information should be broadened. - It was suggested that the NRS be replaced by X.500 Directory Services. In the shorter term the OSI information in the NRS could be down-loaded into X.500 DSAs but with the NRS still maintaining the master copy. This was a complex issue - e.g. how to handle the ageing of caches - which needed to be discussed at greater length. - 8 - 8. Date of next meeting. Tuesday 31 January 1989 at UCL dept of Computer Science. 9. Actions before the next meeting. all To discover how the various sites currently store their telephone directory information. all To find out which databases (or other methods) are used to store information and what information retrieval methods were used. all To seek reassurance that there were no problems with regard to the Data Protection Act. SEK To circulate a sample of QUIPU bulk load data. SEK To investigate the possibility of a format checker for the QUIPU bulk load data format. SEK Enquire whether THORN Procedural interface can be released to the group. PB To send latest versions of QUIPU design docs and user manual to John Dyer at Rutherford for copying and dispersal to interested parties. J.Dyer To determine who requires copies of X.500 and ISODE documentation.