UK Academic Community Directory Group Minutes of Meeting on 12th July, 1989 Paul Barker Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Fourth Meeting of the UK Academic Community Directory Group held at Rutherford Appleton Laboratory on Wednesday 12 July 1989. May 30, 1990 UK Academic Community Directory Group Minutes of Meeting on 12th July, 1989 Paul Barker Organisation: UCL Document Location: UCL Present: Paul Barker UCL (Secretary) Steve Benford Nottingham Graham Carpenter Surrey Shirleen Craig Heriot-Watt Jim Craigie JNT (Chair) Bob Day RAL Andrew Findlay Brunel Andrew Gosling Reading Karen Goswell RAL Julia Hill Heriot-Watt Steve Kille UCL Caroline Leary Sussex Chaoying Ma Cambridge Diane McDonald Strathclyde Andrew Mitchell Reading Bob Proctor Southampton Graham Rule Edinburgh Ken Warner Cambridge John Williams Aston Apologies for absence from: Adrian Barker UCL Chris Bayliss Birmingham Tony Chabot Birmingham Ron Chennells Newcastle Andrew Dand Bath Mick Kahn LNT Peter Mills Manchester Stella Page UCL Colin Robbins UCL Jamie Slee Open University - 2 - 1. Approval of the Agenda The following agenda was agreed upon: 1. Introductions 2. Review of minutes of the meeting held on 19 April 1989. 3. Matters arising. 4. THORN implementation status report 5. QUIPU implementation status report 6. Status of other known Directory implementations 7. Report on the RARE Working Group 3 and RARE Directory Project 8. UK Directory Pilot Project 9. Data Protection Act Model Registration 10. Letter to UK AC Sites on chosing their Directory Organisation Names (draft to be tabled). 11. Any other business. 12. Date of the next meeting. 2. Approval of minutes of previous meeting The minutes were approved nem con. 3. Matters Arising Actions from the last meeting other than those below were taken as having been completed. 3.1. Directory names for the UK academic institutions Jim Craigie was required to write to academic institutions to determine their preferred name forms. A draft was "half complete"! The points to be made in the letter were discussed under item ten of the meeting. 3.2. SUN X.25 X.25 for SUNs running OS.4 had recently become available and some sites were testing and evaluating the product. - 3 - 3.3. Storing NRS information in the Directory Steve Kille's note on the subject was to be circulated with this set of minutes. 4. THORN implementation status report The first delivery of the THORN system was made available to all the project partners at about the time of the last Directory Group meeting. The partners were still working towards a second release of the system. This release will be IS aligned and include DSP. The earliest date when such a release would be made available within the project was the end of August, 1989. While the official end of project date has now been passed, the partners will continue to work on the system. The project aims to demonstrate the system at the ESPRIT Conference Week in November. This requirement provides a focus for work up to that deadline. 4.1. Use of THORN implementation within a Pilot. There was growing pessimism about the feasibility of using the THORN system as part of a UK Academic Directory pilot. No work had yet been undertaken as to what work was necessary to make use of the THORN system in a service environment. In addition, the chances of a THORN continuation project under ESPRIT 2 were fading: this had obvious ramifications for the ability to support the system. It was noted that a Large Scale Pilot eXercise (LSPX) was a THORN deliverable. However the late delivery of the system had caused the LSPX emphasis to be adjusted from one of providing an implementation to interested sites to the new goal of interoperability with other X.500 systems. It was still too early to be certain how severe support and maintenance problems might be. 4.2. Public domain documents "The THORN Naming Architecture" was now available. The other documents were still not publicly available. 5. QUIPU Implementation status report ISODE-6.0 (and thus QUIPU-6.0) available late September. QUIPU was to be featured in a big demonstration at INTEROP '89. - 4 - 5.1. Technical matters At the previous meeting a substantial number of areas where QUIPU could be improved were outlined. There had been relatively slow progress with this work list. However the following areas had been or were being tackled. - Robustness was improved. - More closely aligned to the standard. - Resilience to flaky networks and error conditions was improved. - Now easy to add additional attribute syntaxes. A more general methodology also meant that processes were some 300k smaller! - Work on distributed operations. - The problem of merging sites which were, for example, Janet or Internet only, into a cohesive directory. - The DSA's scheduling of operations was being overhauled. - Modify operations were DAP only due to the security problem caused by having to trust DSAs. There wasn't the infrastructure for strong authentication. Protected simple authentication would be included in QUIPU-6.0 but this would only work with QUIPU DSAs. 5.2. QUIPU at large There were now at least 30 semi-connected DSAs in the world, mostly in the UK, the US and Scandinavia. Such feedback as there was suggested that thus far most usage was experimental. 6. Other Directory implementations 6.1. ICL No change in status to report. 6.2. INRIA A system will be ready soon. INRIA have accessed UCL's QUIPU DSAs using an INRIA developed LISP-based interface. The directory will be packaged with the Mailway system. 6.3. Sydney Sydney no longer exists - it has been replaced by - 5 - EAN/OSIWARE. The UBC implementation is expected in a month's time. It was not clear whether this implementation would be of any interest to the UK Directory Group's pilot. The focus of the work appeared to be towards replacing a nameserver and that the work was highly geared to optimising such performance. It was hard to judge the merits of the system as it had proved difficult to obtain documentation. 6.4. RETIX The system offered was rather limited, being a framework allowing a user to slot in his or her own database package and user interface. The system as seen supported 2 attribute types! 6.5. X/OPEN The X/OPEN group was in the process of defining an Application Programming Interface (API) for directories. 6.6. DEC DEC have developed DNANS for both VMS and ULTRIX systems. The system provides a basic string-formatted-name to value look-up. It wasn't an X.500 implementation although work was mooted to add an X.500 veneer to this system. Such a system was some way off yet. 6.7. IBM IBM have announced something X.500ish. It was pointed out that this was probably done for reasons of appearing to be OSI compliant, in order to assist in the procurement of Government contracts. 7. Report on RARE WG3 Since there had been a WG3 meeting on the day previous to the last meeting (18th April) there was little to report. However the WG3 European Co-ordinating Pilot had been approved in principle and the putative project had now entered the EEC's lengthy incubation phase. 8. UK Directory Pilot Project Twelve bids for hardware to run Directory Services had been received and all had been accepted. Only one supplier tendered for the contract to supply the equipment. Thus, by default, the project has the hardware that everyone wanted, namely SUN 4/330's, each with two 327 Mbyte disks. These machines would be delivered with neither keyboard nor screen to discourage certain modes of usage! The machines should be regarded as being on long term loan. Sites which failed to contribute appropriate effort to the project could have - 6 - their machines withdrawn. It might be expedient for relatively lightly loaded sites to run a DSA for another site without one. 8.1. Delivery schedule The delivery schedules were already slipping. The original schedule was for: - five by the end of June - remainder by end of August It was unclear at the time of the meeting when the systems could be delivered in full although it was apparent that part systems (without disks) could be delivered soon if such systems were of any use to anybody. The general feeling was that something was better than nothing. 8.2. Allocation of first machines The first two Directory Service machines would go to Brunel and Heriot-Watt. Brunel needed a machine for the purposes of their user interface development. Heriot-Watt were chosen as a good novice site, being reasonably well advanced in data gathering but not rich in UNIX experience. 8.3. System configuration The aim was to be able to determine the required components of a relatively standard "lowest common denominator" system configuration that the less UNIX and Directory literate sites could install relatively simply. The Directory machine had to be viable as a stand-alone system. However, more experienced sites might wish to configure their systems differently for various reasons. Machine support might be easier in an integrated environment. Also many experienced UNIX sites preferred to use the UNIX/NIFTP software rather than SUN's vanilla product. 8.3.1. Unix configuration Several areas were identified where experts had to make decisions: - Which components to included in the system at initialisation time (e.g. manual pages, mail) - X.25 configuration - The amount of swap space and temporary file space. This decision had to made with the view that the systems would also be used as mail gateways in 9-12 months - 7 - time. 8.3.2. QUIPU configuration. Some guide would need to be provided with respect to ISODE and QUIPU configuration and installation. While it would in many respects make life easier to be able to distribute binaries, this was impractical. It was pointed out that QUIPU-5.0 does not run on SUN-4 hardware without a patch! Brunel and UCL agreed to liaise to work towards an installation package. 8.4. Documentation For UNIX novices, SUN's UNIX manuals were regarded as being fairly good. Heriot-Watt, as the novice site, indicated that they had to have more documentation early on. It was pointed out that arrangements had already been made for John Dyer of the JNT to have copies made of two useful documents; "Volume 5 of the ISODE manual" and "The Design of Quipu". Marshall Rose, ISODE's progenitor, has recently been working on a white pages interface to the Directory for Nysernet and had produced a considerable volume of new documentation. The tutorial on dish had been enhanced over the last few months to make it more readable for the uninitiated. 8.5. Feedback 8.5.1. Initial feedback Initially learning from the experiences of novice sites was crucial to the production of an easy to install Directory Service package. Improvements to the documentation had to be fed back into the configuration package as quickly as possible. 8.5.2. Continuing feedback The onus was on participating sites to report their experiences to the group. The reporting to the group would be tied in with the meetings' cycle. Reporting requirements are as follows: - Each site should circulate by electronic mail a plain text copy of their report to the Directory Group. - Pretty printed reports should be given to the JNT for circulation. - 8 - - Participating sites were expected to attend the meetings The reports should contain at least the following: - List of what failed, smattering of what worked. (The exact nature of this would obviously change as the project evolved.) - Data acquisition - Data maintenance and management It was important that the reports delineated clearly between system and data aspects. In the short term at least, there would be no common format of report - this might be procrustean with regard to the richness of sites' experience! Two potential areas of useful feedback were identified: - Monitoring tools - as yet not provided - could be used to gather information about Directory usage. - Users could be asked for their comments. 8.6. State of readiness of sites This section summarises the current state of advancement of the sites represented at the meeting. Many issues were covered. They include "political" problems, data availability and accuracy, structuring the data, data management and maintenance, documentation, plus numerous other points. 8.6.1. UCL - Computer centre email data plus college phone data readily available although maintenance still to be tackled - Computer Science department - providers of data and software - Admin - some data available soon. Very interested in work of UGC Management and Administrative Computing Initiative. 8.6.2. Brunel - Already running QUIPU, currently 2000 entries, more data very soon. - Data structured by department under the Brunel entry. - 9 - Staff and students together. Saw no value in using intermediate levels of hierarchy. 8.6.3. Surrey - Admin didn't see X.500 as solution to all their problems as they already have a large Oracle database. - In the long term, might be interested in an X.500 front-end. - Admin worried about access control. University happier buying products from big companies rather than trusting some new toy. 8.6.4. Edinburgh - Data structure problem as students not in departments until their honours year. Admission is by faculty. - Saw major data merging problem. - Would only provide read access to data - Authorities unhappy about home addresses in the directory (and individuals concerned with advent of poll tax). - Problem uniquely identifying people as personnel dept re-cycle personnel numbers. - Haven't yet got box asking whether people wish to appear in the directory. Some people might wish not to appear in the Directory (e.g. politically active Chinese students). Could possibly use an identifier other than personal name in such instances. - Data would inevitably be patchy for some considerable time. 8.6.5. Heriot-Watt - Had tried QUIPU - got stuck very rapidly - documentation for novice users must be improved. - Would provide read access - date to be managed centrally - Inconsistencies in admin view of availability of data. - Had added a question on "diary form" about whether a person wished their entry to be in the Directory. - Would start with staff and post-graduates. - 10 - - Many of the problems described by Edinburgh 8.6.6. Southampton - Waiting on campus LAN and results of UGC Computing Initiative. 8.6.7. Cambridge - Admin might be said to be sympathetic and interested. But they don't really understand what is involved. - New admin system currently being procured. - Should be able to obtain data. Phone data is available on-line but is notably inaccurate. - An X.500 directory would not be the principal source of data for a long time. - Question of whether the data should be structured by course, by college, by both? - Responsibility for maintaining the data needs to be split into units smaller than the university as a whole. 8.6.8. Nottingham - Already ready running QUIPU experimentally - only CS data at present. - Getting data from admin still to be resolved. - No problem getting phone data - Interested in variety of attribute types: personal roles, meeting schedules, committee membership, publications, maps, pictures of the animals ... - Start with staff data - Keen to experiment in a variety of ways with Directory Services, saw benefit in having a diversity of approaches in the short term. 8.6.9. Aston - Only just getting started 8.6.10. Strathclyde - Only just getting started - 11 - 8.6.11. Rutherford - Problem of mail addressing on site. Mail tables currently on an IBM machine. Wouldn't go X.500 until IBM produced X.500 product! - A third of the staff at RAL use email. - Phone problems - desirable to emphasise which numbers were direct dial. - Rutherford traditionally structured by department and then sub-divided into units. There were some anomalies, such as the JNT! 8.6.12. Sussex - Didn't bid because of lack of staff resources. - Keen to follow experiment 8.6.13. Reading - No problem getting email and phone data. - Less certain about student registration data. - Interesting carrot to entice registration in the directory - make desirable software available only to those who register. - Could be used as an expertise database. - Consider storing data on old students - this would simplify the process of approaching old students for a "consideration" for their alma mater. - Home addresses are already publicly available in the university calendar. 9. Data Protection Act Model Registration The model registration was inadequate as it stood with regard to the section on data disclosure. The registration referred only to "staff and students in educational or research establishments" whereas the registration had to allow disclosure to all. It was suggested that reference to British Telecom's registration for the telephone directory might reveal an acceptable form of wording. It was noted that sites might wish to tailor this registration to suit their own needs. Reading's desire to store "which software a user was entitled to have access to" required data class categories not on the model - 12 - registration. 10. Letter to UK Academic sites on chosing Directory Organisation Names The letter, when written, would make the following points: - Each site would be asked to register more than 1 name. - The distinguished name should be the long name most commonly used. - Sites should avoid choosing legalistic, verbose name forms, not commonly used or known, as their distinguished name. (e.g. The Episcopalian Rutherford Appleton Laboratory of South Chilton). - The list should include NRS long and short names (the desirability of the short forms was questioned) There was the unresolved question for collegiate universities of which organisations should be at the level immediately below country in the Directory Information Tree. 11. Any other business 11.1. Brunel's work on User Interfaces There were still contractual problems due to the murky status of the JNT (Brunel weren't the first to cast aspersions on the JNT!). The work effort required two programmers. A first programmer had been hired but he was now unavailable for some time and so was now the second programmer. There was still a vacancy for a programmer. 11.2. Networked Information Services Project (NISP) A letter was received from Jill Foster of NISP pointing out the apparent commonality of interest of NISP and the Directory Group. This was certainly apparent from reading the NISP functional specification. It was decided that it would be useful for the next Group meeting to be addressed by a representative of NISP to see how the two groups might serve each other and minimise duplication of effort 12. Date of next meeting. Monday 23 October 1989 at UCL dept of Computer Science. - 13 - 13. Actions before the next meeting. JCraigie To write to academic institutions to determine their preferred name forms. SEK To provide note on storing NRS information in the Directory to be circulated with the minutes SEK/AF To produce a UNIX/QUIPU configuration guide JMH To make adjustments to the model Data Protection Act Registration PB Invite a representative from NISP to talk at the next Group meeting