UK Academic Community Directory Group Minutes of Meeting on 24th January, 1990 Paul Barker Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Sixth Meeting of the UK Academic Community Directory Group held at University College London on Wednesday, 24th January, 1990. May 30, 1990 UK Academic Community Directory Group Minutes of Meeting on 24th January, 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 Syngen Brown Kingston Poly Graham Carpenter Surrey Mike Collett Nottingham Shirleen Craig Heriot-Watt Jim Craigie JNT (Chair) William Craven Sussex Bob Day RAL Brian Elloway Aston Andrew Findlay Brunel Mike Guy Cambridge Julia Hill Heriot-Watt Chris Horsburgh ULCC Peter Houlder Kent Catherine Kelleher LNT Steve Kille UCL Caroline Leary Sussex Chaoying Ma Cambridge Damanjit Mahl Brunel Diane McDonald Strathclyde Peter Mills Manchester Andrew Mitchell Reading Stefan Nahajski Brunel Julian Onions Nottingham Colin Robbins UCL Graham Rule Edinburgh Steve Titcombe UCL Alan Turland Edinburgh John Williams Aston - 2 - Apologies for absence from: Jill Foster Newcastle Andy Powell Bath 1. Approval of the Agenda The following agenda was agreed upon: 1. Introductions 2. Review of minutes of the meeting held on 23rd October 1989. 3. Matters arising. 4. Quipu implementation status report 5. THORN implementation 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. Networkshop demonstration 11. Comments on Directory Pilot Configuration Guide 12. Managing and bulk loading data 13. Directory Pilot support requirements 14. NRS Naming and X.500 15. Provision of remote interfaces to the DUA analogous to NLP 16. Transition issue: X.25(80) to CONS 17. Addressing: Use of NRS 18. Extending the data model 19. Use of the Directory for Library Catalogues - 3 - 20. Any other business 21. Date of 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 or dropped. 3.1. Directory names for the UK academic institutions Jim Craigie was required to write to academic institutions to determine their preferred name forms. This had still not been done. 3.2. Support money Jim Craigie was required to write such letters as appropriate to release money for hardware and systems support. 4. Quipu implementation status report ISODE-6.0 (and thus Quipu-6.0) became officially available on the day of the meeting. Quipu-6.0 showed the following enhancements over the previous major release: o Better performance: special malloc routine; data stored more compactly. o Generalised attribute handling o IS aligned o Better documentation o Distributed operations improved: QuipuDSP used over associations between 2 Quipu DSAs - X.500 syntax with enhanced semantics; DSAs use of asynchronous operations; DSA relaying; choice of which DSA to access for replicated data. o Authentication and access control: added protected simple and strong authentication. (UCL has a RSA package which has, for licensing reasons, to be distributed separately. An announcement on this will be made in due course.) o More interfaces: fred and widget2 - 4 - 4.1. Note on security The Chair noted that the Computer Board were funding two studies on security: one at Newcastle on lower layer issues; one at UCL on the upper layers. It was expected that implementations would follow on from this work. 4.2. Quipu development proposal A joint Quipu development proposal from UCL and Edinburgh had been accepted by the JNT. This was to cover work in the following areas: 4.2.1. Interoperability o Interworking o Distributed operations o Improved caching: for example, of directory configuration information. 4.2.2. Management o Checking the coherence of the Directory structure. o Authorisation: for example, to restrict access for some users to parts of the tree which require IPSS calls. 4.2.3. Applications o Integration of PP and Quipu: for example, PP to use Quipu for routing tables. o Support of OSI: integrate NRS information into Directory; tools to map both ways between NRS and DIT - Directory could be used to manage NRS information; similar approach for DNS. o Provide asynchronous interface for DUA - it appeared that there wasn't a very pressing need for this at the moment. 4.2.4. Study on improving service offered o Searching: better matching algorithms. o Attribute classes: for example attribute class telephoneNumber, with sub-classes homePhoneNumber and workPhoneNumber. o Attribute inheritance to allow entries to share attribute values. - 5 - o Storage of the schema in the Directory. o Work on "softening" the hierarchical nature of the Directory. o Naming: entries currently only having one distinguished name. This has led many usrs to use aliasing in a non- approved fashion. o Distributed entries: to facilitate attribute management. o Difficult queries: allow a DSA to pass back information to the DUA about what it is doing, or intending to do. 4.2.5. Not covered in the proposal o Support o Tools for user data o Generation of printed Directory o Security 4.2.6. Comments on study proposed It was pointed out that most of the work in the study was to investigate facilities that were usually provided in conventional databases. Didn't this demonstrate that the standards' people had got it wrong when they decided not to base the Directory on existing database technology? Not really. Existing database technology did not cope well with the degree of distribution implied by the Directory. Two points were noted about the list of study items. First, the above list is fairly closely aligned to the work being undertaken by the standards community. Second, many of the study items were originally intended as work areas, but had to be trimmed from the proposal because of limitations on funding. 5. THORN implementation status report Release 2 of the THORN X.500 system was available for porting by the project partners in October 1989. The system was demonstrated at ESPRIT Conference Week in November 1989. Some interworking between the THORN, Quipu and Pizarro systems was demonstrated. Testing the system had revealed a lot of protocol stack problems. Addressing problems meant that interworking between THORN and Quipu was only possible by chaining, and not be referral. - 6 - The THORN project officially ended in December 1989. Project reports were now being completed. There was no continuation funding for the project. No THORN product as such had come out of the project. However, some of the organisations involved would be using either THORN-based components, or at least the experience gained in THORN as the basis for their own products. Plans to develop products were as follows: Siemens Had developed management tools within the THORN project. Now had an X.500 system available. ICL Developed THORN database. Were working on a combined X.400 and X.500 product. Bull Have a group working on Directories SW The company most likely to produce a system heavily derived from the THORN implementation. INRIA Had developed THORN protocol tools. Had produced Pizarro system, which had now been delivered to another French test site. 6. Brunel user interface implementation status report Andrew Findlay introduced Stefan Nahajski to the meeting. This meant that the team at Brunel was now at full strength. 6.1. Development so far A full-screen interface, based on the original widget interface, was now available by pad to brunel.dir, or 000041131503 for those who operate in mnemonic-free zones. The interface, now called "sd" (screen directory), had evolved considerably from the original widget. There was some consternation at the current version as the list operation had now been removed. This slightly provocative step had been made deliberately. First, large fan-outs of the tree render list operation almost useless. Second, it is deliberate attempt to see if people can use the Directory without a list operation. Having said that, in fact the interface can be made to list by specifying an empty search string. The interface tried to hide X.500 details by referring to keywords such as "place" and "person". Place might be mapped onto locality, country or room. Similarly, person might be mapped onto combinations of common name, title and surname. - 7 - The aim of the interface was not to replace dish, but to meet the major requirement of making the Directory usable by non-technical people. 6.2. Planned work The X-based user interface for the PP X.400 system was being examined. Since X.400 and X.500 would inevitably be closely linked, some consistent interface approach was probably desirable. For PCs, it was intended that the interface should have the look and feel of other widely available, commonly used interfaces; for example MS-Windows. The OSI stack remained a problem for the PCs. The conclusion of the PC-comms group was that if a PC was able to run an OSI stack, then it wasn't really a PC! 7. Other Directory implementations There was nothing very definite to report. 7.1. INRIA The Pizarro system had been shipped to another test site. 7.2. UBC Not yet available 7.3. Wollongong Based on an earlier version (don't know which one) of Quipu 7.4. TOUCH Sounded good, but not seen. Worth investigating. 8. Directory pilot sites status reports Since sites now produce printed reports which are circulated to the meeting attendees in advance, this section now focuses mainly on problems that sites had experienced. Brunel and Cambridge both reported the problem where it was impossible to have a non-leaf node without children. This had led to a variety of odd work-arounds being implemented, including the use of dummy entries. This would be fixed in Quipu-7.0. Cambridge reported that they had experienced some odd behaviour with time limits expiring seemingly spuriously. It was not clear how the limits were being applied. The - 8 - problem needed investigation. Cambridge reported problems using SUN coloured book software, given the partitions set up by the configuration script. It was agreed that the scripts would have to be modified. Cambridge reported problems with producing the documentation, a point everyone concurred with. It was agreed that UCL would produce a documentation set and that Rutherford would print it, ready for distribution by the JNT. Cambridge reported problems with setting up the logging. A certain default level of logging should be suggested to sites, along with guidance on when the logs should be zeroised. The configuration guide should have a section on this topic. Heriot-Watt said that they had found SUN's hot-line to be useless. Sun appeared to be inadequately resourced to cope with the volume of calls. It was pointed out that SUN often respond better to requests by email. Messages should be sent to forename.surname@uk.co.sun. Rutherford and Surrey noted that money had not yet been released for maintenance and that their machines were now beyond their warranty period and no longer covered. Rutherford asked other sites to take their "ibrowse" interface for usage and comment. UCL asked that sites should mention usage by "real users" in their reports. UCL were asked to investigate what the logging requirements were for producing simple statistics of usage, and to produce a modest tool to process the logs to produce such statistics. A method for distributing Brunel's "sd" interface had to be agreed upon. 9. Report on RARE WG3 A meeting had taken place where national activities were discussed. A number of countries were experimenting with Quipu. There was much talk of putting user agents onto Macintosh and VMS machines. The COSINE proposal was reviewed. There would be a call for tender. This would include work on European-wide - 9 - coordination and the building of a centralised service. These calls for tender would be made some time this year. 10. Networkshop demonstration A session on X.500 had belatedly been added to the agenda of Networkshop '90, and there was also a requirement that the work of the Pilot be demonstrated. The demonstration would be on Tuesday, 27th March, 1990. There was a discussion of what sort of demonstration could be given. There were problems with lack of suitable infrastructure (X.25 lines, ethernets running I-word protocols, etc). The following was agreed as the tentative basis of the demonstration, with Brunel and Edinburgh getting rather lumbered with taking responsibility for it. Edinburgh were already taking a SUN to Networkshop in connection with an X-windows demonstration. This machine could also be set up with a preconfigured DSA with a small amount of data but a lot of knowledge. At the very least a terminal could be attached by serial line to the SUN. It was also hoped to be able to get an X terminal to demonstrate an X interface. An X.25 line was essential. The demonstration could show access to a local DSA to indicate the speed of local access, and access other DSAs in the Pilot over JANET. It was requested that pilot sites had a non-trivial amount of data in their DSAs by the day of the demonstration. 11. Comments on Directory Pilot Configuration Guide There was a long discussion on whether it was sensible to continue with the current strategy of getting SUN to do a basic installation and then relying on sites being able to configure their system using the pilot configuration guide. The general feeling (particularly of the people who have put substantial effort into producing the guide) was that in future the Pilot should consider giving sites pre-configured machines. It appeared that no-one had yet succeeded in following the instructions from start to finish with complete success. 12. Managing and bulk loading data 12.1. Multiple data sources Sites were beginning to discover that there was a significant problem in managing the data they wished to store in the Directory. For some time, the X.500 Directory would "shadow" other "master" data sources and there would have to be mechanisms for keeping the Directory up-to-date. The Directory could potentially be shadowing a considerable - 10 - number of data sources. For example, at UCL, (at least) the following data sources are being considered: o Telephone database o Electronic mail lists o Payroll database o Personnel database o Library registration database o UCCA information o Departmental databases In addition, users would be allowed to add some information about themselves if they wished. 12.2. The merging problem Since there were relatively few organisational units, it seemed reasonable to assume that managing their naming could be done by ad hoc means. However, there were so many entries for people that procedures had to be automated as much as possible. Some level of operator intervention was inevitable though. One of the principal merging problems stems from the lack of unique identifying keys which associate entries in different databases. People would be named differently in different sources: o Source 1 might refer to "John Smith" o Source 2 might refer to "J Smith", where "J Smith" referred to the same person as "John Smith" in source 1. Different people might be named similarly o In source 3, "J Smith" might refer to "Jane Smith" Sources might overlap in the attributes they master and the same attribute value might be represented differently in 2 sources: o Source 1: phone=1234 & 5678 o Source 2: phone=+44-1-380-5678 - 11 - 12.3. Updating the Directory Past experience, gained from the THORN Pilot Exercise, showed the following: o Adding data was fairly simple - bulk load the data, adding entries not present, adding attributes not present, modifying attributes which were present. o Deleting data was difficult - data not present in bulk load files might be mastered from another source. Ideally each attribute value could be tagged with an indication of the source it was loaded from. 12.4. A possible approach to data management An approach was sketched out which had the following main characteristics: o Use of a sophisticated bulk loading tool using data files with a similar format to Quipu's EDBs, but with some extensions o Make extensive use of differences between successive sets of data between a source - makes it easy to apply deletions o Would only create an entry in the Directory if sure that no existing entries might refer to same person. o Ambiguities written to an operator intervention file - operator could then create mappings between names in source data and names in the Directory, which would be accessed on subsequent loading from that source. o The notion of precedence existed which allowed one source to be regarded as a preferred source of data for a set of attributes. The design was still fluid. When it was more closely thought through, a design would be circulated to interested parties. Such a tool was urgently required and there was currently no source of funding for this work. 13. Directory Pilot support requirements In the early stages of experimenting with X.500 Directory Services, it was both practical and desirable that support was provided to sites by the system implementors. As the scale of the Directory grew, it was essential, both for Directory Pilot sites and for the software developers, that there was adequate support for the Pilot. The current contract with UCL expires at the end of March - 12 - 1990. Interested groups would soon be invited to tender for the follow-up support contract. 13.1. Review of current and anticipated support requirements The following is based on the experience of those at UCL who have supported the Quipu software and the Pilot. 13.1.1. UK Pilot Support - Administration of the Directory root and the U.K. Directory tree. o Assigning DSA names o Managing the root and U.K. EDBs - General administrative support. o Can I come to the next meeting, and when is it? o Is there a document which summarises exactly what I need to know? o What is the Directory Groups view on ...? o Can you make me a tape with ...? 13.1.2. Individual site support Some of this work was fleshing out the area covered by the Pilot configuration guide. - Helping sites to get an initial system working. - Helping sites who have subsequently stumbled, possibly due to UNIX inexperience - ISODE/Quipu support. [There is almost certainly a need for a further guide, aimed at sites with little directory experience, to help them with the sort of questions posed below.] o Why don't my EDB files load? o I can't understand the access control syntax/semantics. o How do I configure my system to run 2 DSAs. o How do I replicate subtree ABC on a daily basis? o Help to get ftam going (useful for subsequent - 13 - distributions of the system). o Network service configuration (configuring IPSS, JANET, Internet, local ethernets). o Tailoring of logging 13.1.3. Software support This was currently given through the quipu-support list. All quipu support queries came to this address. There was probably a need for specific U.K. academic support. - Bug fixing - Interworking problems with non-Quipu systems - Porting to other hardware? - I need to be able to do ... how can I achieve this with the software? 13.1.4. Development - Urgent requirement for tools to handle management and merging of data - Monitoring quipu-support list gives a good indication of what users and service providers see as essential requirements. 13.2. What people thought was necessary It was noted that as the Pilot was extended to additional sites, the level of interest in Directories would probably be lower than for the initial group of sites. This implied more support. The conviction about the need for pre-configured hardware was again expressed. Rutherford thought that in the first year there was probably a need for 2-3 person-years support. The Chair doubted whether he could obtain that level of funding. It was suggested that possibly there should be some initial funding to get sites started, and that if they then required further support, they could then pay for it from a support team. The idea was mooted that the support team could possibly do some work on the data management tools, when they weren't active supporting. - 14 - 13.3. Obtaining the pilot software It was hoped that most people could obtain the pilot software by FTAM or Blue Book. However, it was recognised that some sites might have a bootstrapping problem. These sites could request a copy of the software release from p.barker@uk.ac.ucl.cs. 14. NRS Naming and X.500 A paper had been circulated to the group, written by Dave Chadwick, which suggested that there should be an algorithmic mapping between the NRS names and the names used in the X.500 Directory. Unfortunately, the author was not at the meeting to defend his paper. The consensus was that, in the short term at least, people wanted to experiment with their own naming structures. A number of people disliked the notion of the universities being shunted off into an academic domain, although it was realised that in the long run the naming structure would be taken out of the meeting's hands. There was some sympathy, but little support for the paper's proposals. 15. Provision of remote interfaces to the DUA analogous to NLP A request was made for a procedural interface for NLP-like querying of the Directory. This would be built on top of the procedural interface to the Directory. However, it was noted that this was essentially a DUA interface issue and outside of the scope of the Quipu development contract. 16. Transition issue: X.25(80) to CONS It was not clear what was stated at the meeting. The following statement from Steve Kille should make clear the position with respect to Quipu and ISODE. 1 If SUN provide an X.25(84) interface prior to a CONS interface, this will be integrated into ISODE. The Network Address usage scheme outlined in UCL/RN/89/13 "An interim approach to use of Network Addresses" will be used. This approach, which algorithmically derives the SNPA from the Network Address, will allow the protocol components to be evaluated at the earliest possible point. 2 When SUN provide CONS, this will be integrated into ISODE and Quipu. The changes to 1. will be minimal. Essentially, no subnetwork specific information will be given. Because of this, the restrictions of 1. on network address form can be lifted. This implies the - 15 - following: o The SUN CONS system must provied NSAP/SNPA binding (I imagine that this is taken as read) o There will be a need for (NRS) tools to manage this binding. This is definitely beyond the Quipu contract, and the provider of this component should be identified. ,RE 17. Addressing: Use of NRS It was noted that DTE numbers were currently stored for JANET addresses. A suggestion was made that it would be preferable to use mnemonics and to use the NRS information to resolve these names into addresses. It was countered that this binding of the Directory to usage of the NRS was undesirable and that there were a lot of complex issues involved here. UCL and Cambridge agreed to continue the discussion off-line. 18. Extending the data model There was a discussion about extending the data model to allow for additional attributes and object classes. The following was agreed as a good model for such development. Sites could initially experiment privately with new attributes and object classes. If the extensions were deemed useful for all, they could then be adopted by the wider community. It was noted that a document existed, The RARE Naming Architecture, (currently being updated) which specified a considerable number of attributes and object classes. A request was made that some hint be given as to their likely use. 19. 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 meeting. The paper noted that several groups were interested in using X.500 technology for storing information other than personal data. In particular, it was proposed that the library community might use X.500 to store information on doctoral theses, both recently published and in progress. A meeting was proposed around the end of February when interested parties from the Directory Pilot and the library community could meet to discuss the feasibility of a Library Pilot. - 16 - 20. Any other business 20.1. Time synchronisation There is an optional parameter in Directory System Protocol which allows the time-stamping of an operation with some notion of absolute time. While this may possibly be an undesirable feature, it was noted that tools were available which allowed for adequately good time synchronisation between hosts. These tools use an OSI connection oriented version of the Network Time Protocol (NTP), described in RFC958. Sites using the protocol are organised hierarchically. Level 1 sites have radio clocks. Level 2 sites maintain connections with one or more level 1 sites and attempt to synchronise with them. Level 3 sites connect to one or more level 2 sites and synchronise with them. The protocol performs well so long as there is low variance in the round-trip time between a pair of sites. When a site has connections to more than one higher level site, it prefers the site with the lowest variance in round-trip time. Typically a pair of sites communicate with each other once a minute. There is a back-off strategy which reduces this frequency on connections which are behaving less reliably than alternatives. A similar back-off is applied to connection attempts which persistently fail. The present test configuration was as follows: the University of Maryland was a level 1 site; UCL was a level 2 site; Nottingham was a level 3 site. It was proposed that this experiment be enlarged slightly to include a few more interested sites for a trial period. Cambridge indicated that they have a radio clock and could investigate making it available for an experiment. 21. Date of next meeting. Wednesday 2nd May 1990 at UCL, room TBA. 22. Actions before the next meeting. JC To write to academic institutions to determine their preferred name forms. JC To update the directory-pilot distribution list as requested JC To provide Pilot sites with a list of equipment that they should receive / have received. - 17 - JC To take sufficient steps to enable the release of monies for hardware and system support. JC To issue a call for tenders for the Pilot support contract. CJR To produce a set of Quipu documentation BDay To print the afore-mentioned documentation, and pass it to the JNT for distribution. pilot-sites To arrange software and hardware maintenance pilot-sites To make available a reasonable amount of data in their DSAs in time for the demonstration at Networkshop on 27th March 1990 pilot-sites To specifically mention the level of real usage of their DSA in their pilot report. PB To give advice on required logging levels, and to provide simple tools for the processing of statistics on levels of usage. CJR/AF To discuss a method of making the "sd" interface available to all pilot sites. SEK To clarify anticipated usage of attributes described in "The RARE naming Architecture" pilot-sites Sites interested in running NTP should join the limited experiment