CURRENT_MEETING_REPORT_ Reported by Richard Colella/NIST, Steve Kille/UCL and Peter Whittaker/BNR OSIDS Minutes Agenda Introduction The meeting was opened by the Chair, Steve Kille (UCL). Introductions were made and minute-takers were solicited. The proposed agenda was approved and the meeting proceeded accordingly. Minutes of Previous Meeting The minutes of the San Jose meeting were approved with minor changes. Document Distribution A number of attendees had problems with document distribution. 1. ASCII documents were formatted for A4 size paper, which is inconvenient for those in the U.S. 2. ASCII versions of the documents were somewhat idiosyncratic in format -- Steve pointed out that the primary form of documents he generates is PostScript and he was not intending to spend significant amounts of time reworking the ASCII versions, 3. A number of people could not print the PostScript versions of the papers retrieved from CNRI -- Steve said that this problem was easily correctable and he would take care of it. 4. A few people remarked about late distribution of documents and a consequent lack of time to obtain and review them prior to the meeting. Statement of Objectives/Scope/History Steve spent a few minutes reviewing the objectives, scope, and history 1 of the group for those who were not at San Jose. He emphasized that the DSWG was chartered to develop a technical framework for an X.500 deployment, but was not intent on being the instrument for deployment. Introduction of Documents Steve briefly introduced each of the documents that were input to the meeting: o ``Replication Requirement to Provide an Internet Directory Using X.500.'' S.E.Kille. o ``Replication to Provide an Internet Directory Using X.500: A Proposed Solution.'' S.E.Kille. o ``IETF Directory Working Group Scope (Version 3).'' S.E.Kille. o ``The COSINE and Internet X.500 Naming Architecture.'' P.Barker and S.E.Kille. o ``Building an Internet Directory Using X.500.'' S.E.Kille. o ``An Interim Approach to Use of Network Addresses.'' S.E.Kille. o ``A String Encoding of Presentation Addresses.'' S.E.Kille. o Using the OSI Directory to Achieve User Friendly Naming.'' S.E.Kille. Liaisons NADF -- Marshall Rose (PSI) The North American Directory Forum (NADF) is a consortium of service providers and potential service providers of public X.400 and X.500 services. The NADF has as its focus the North American market. However, they realize the need for international connections, possibly through multi-lateral agreements. Their raison d'etre is to figure out how to share proprietary information, required to provide a seamless service, without compromising their business interests. The NADF has had four meetings to date. Their next meeting is in March, 1991. Stable technical proposals addressing some of the NADF members' concerns will probably be made in March, but the consensus process makes actual timeliness for agreements uncertain. The primary contact for the NADF is Don Casey (Western Union). To provide continuity, a standing Chair, Ted Meyer (Rapport), has been retained. OIW Dir SIG -- You-Bong Weon-Yoon (ATT) 2 The OSI Implementors' Workshop (OIW) produces multi-vendor agreements based on OSI standards. The Directory Special Interest Group (Dir SIG) produces agreements on the X.500/ISO 9594 standard. Current work in the SIG is in developing international standard profiles (ISPs) through coordination with the two other regional OSI workshops, EWOS in Europe and AOW in the Pacific rim area. Beginning in the December, 1990 meeting, the SIG will begin developing multi-vendor implementation agreements on replication, access control, and distributed operations (the latter will be coordinated with the OSINET work on interoperability test development). RARE WG3 -- Steve Kille (UCL) RARE WG3 has two subgroups of interest: a user information area and a group working on directories. The Directory group has an analogous function in Europe to this Working Group of the IETF. The next meeting of RARE WG3 is January 17-18 in Brussels. ISO/CCITT Meeting in Ottawa -- Steve Kille (UCL) Steve summarized the current work in Directory standardization as it stood after the Ottawa meeting. The main areas of interest were in: o Extensions to the information model in the areas of schema (e.g., publication) and operational attributes (i.e., those associated with a subtree, such as access control defaults). o Abstract services -- e.g., paged results (does not deal with collating). o Matching rules -- will be user-extensible, rather more formally defined than today, and bound to attribute syntax. o Replication -- now a CD (Committee Draft -- what used to be a DP); defines incremental shadowing, among other paradigms. o Distributed entries -- large and complex document, not well organized and difficult to comprehend. CCITT is intent on seeing this in 1992, but it is not believed to even be a Work Item in IEC. o Short-form names -- some support is expected in 1992, though not necessarily a good technical solution. o Migration from '88 to '92 X.500 -- a document is available on this. o Access control -- work is progressing, but the editor recently resigned. A new editor has taken over and the access control documents have been reissued on a second PDAM ballot (Proposed Draft Amendment -- used to be PDAD). PSI White Pages Pilot Presentation -- Marshall Rose (PSI) 3 Information is available as PSI TR 90-05-10-1 and PSI TR 90-09-10-1 from info@psi.com. Marshall provided an overview of the PSI WP Pilot. As a digression, he described an alternative name registration scheme based on the existing civilian naming infrastructure for states, counties, cites, etc. Some questions remain. This will likely come onto the agenda at the next meeting. FOX -- Paul Mockapetris (DARPA) Paul briefly discussed the Field Operational X.500 (FOX) project that DARPA is funding. It is based on a pair of meetings that occurred two years ago which resulted in RFC 1107. There are four participants: 1. ISI -- main contractor and responsible for project oversight. 2. NYSERNet/PSI. 3. Merit. 4. SRI. The objectives are twofold: 1. Get X.500 closer to operational status. 2. Demonstrate interoperability among multiple X.500 implementations. SRI will use the NIST implementation and investigate supporting some of their traditional roles, such as registration. Merit is considering using X.500 to publish network numbers. PSI will be cooperating in interoperability testing with the NIST implementation and another implementation (as yet undecided). Cosine Pilot Directory Service -- Steve Kille (UCL) The slides of this talk are available from UCL. Mail to info-server@cs.ucl.ac.uk. Scope of Group and Review of Charter Fundamentally, there were no significant disagreements about what the scope and charter documents say. There were two specific decisions made: 4 1. The scope should specifically state that the aim of the group is to align with the base standards and profiles on the extensions when these become available, and, 2. The charter will be collapsed into the scope document. Infrastructure Strategy The document ``Building an Internet Directory Using X.500'' was discussed. The substance of the discussions was: o The document needs a caveat that this approach will not necessarily address everyone's X.500 needs. o Need to address the issue of name allocation at the top levels of the naming tree. o Need to do a better job of naming DSAs, rather than just having them named high up in the tree (which is awkward). o Under the section on replication of knowledge and data, add that an intercept strategy could be defined by others (e.g., the OIW Dir SIG), not necessarily by this Working Group. o In Section 3.3, the sentence that begins, ``There is a requirement to extend...'' will be amended to read, ``There may be a requirement to extend...''. There was general agreement on the contents of the document and folks felt that it should move forward. Steve proposed that the target should be to have it become an RFC in one to six months. Replication Requirements and Scheme A number of issues arose during the discussion of replication: o Lower-layer stacks -- combinations of LL stacks should be allowed even thought this results in less-than full interconnectivity of DSAs. However, guidance should be given on the desirability of having increasingly richer connectivity as one moves higher up in the tree. o Remove Section 3 of requirements document -- this is either a trivial or intractable problem; in either case, no statement is needed. o Section 5 of requirements -- there was some confusion about what this section meant. Steve agreed to rewrite it in words similar to those he used in explaining it. o Section 6 of requirements -- the new scaling target will be 100,000 non-leaf entries, given that this is at least an order of magnitude 5 greater than what we think is really required. o Replication approach -- after some discussion of the appropriate approach to take to replication --- a non-standard scheme such as that in QUIPU, an intercept strategy, or wait for the standard. The general discussion was inconclusive. A subgroup, consisting of those most active in the overall disucssions was formed (DO, PM, PK, GM, SK) to look at the problems, and in particular the issues of migration. The consensus of the off-line discussion was that the best approach, all things considered, was to use a scheme based on that described in the replication proposed solution document. This was agreed to by the rest of the Working Group. Also agreed was that a replication scheme based on the standards work will be adopted when available. The interim nature of the solution should be emphasized. It was noted that DUA/DSA interaction is not affected. Domains and X.500 There was some discussion on how to represent Domain Names (DN) (i.e., the attributes) in the X.500 DIT: octet strings or IA5 strings. There seemed to be some confusion about what the implications of this are. Steve said that he would talk to Paul Mockapetris off-line and figure out what the issues really are. There was some lengthy discussion on the utility of storing DNS information in the DIT. Steve agreed to make the minor changes to the document suggested by the discussion. Otherwise, he will progress the document as an RFC pretty much as is. Day 2 Gita Gopal of Bellcore gave a presentation on a Bellcore research project studying methods of providing support for distributed entries in a heterogeneous multi-server, multi-protocol, multi-media, multi-context environment. The Bellcore method is based on a central Linking Data Base, (LDB) which contains one entry per person keyed on a unique Personal Identifier (PID). Each entry contains references to all known Databases (DB) holding information about the particular individual, as well as the protocol information necessary to access those DBs (i.e., J. Foobar, Widget Inc, X.500 DSA, RFC1006 address, etc...). The chief goal of this project is to allow users to access any and all 6 information about individuals maintained by various DBs using only information from a particular DB. For example, given a DN for a person's business entry (i.e., an organizationalPerson), a user would be able to send mail to that person's home by telling a UA to check the LDB and use the business DN to find a residential OR address. The use of aliases in an X.500 DIB was suggested as an alternative method of achieving the same results, but was rejected as being inapplicable to distributed entries. The LDB solves the distributed entry problem by considering the person as the essential element rather then focusing on the entries themselves. Contexts are supported using a dynamic schema. Users are expected to have some knowledge of the context from which they are searching (the example of having to know what a telephone number is, and what equipment it can be used with, before being able to make use of it, was raised as analogous to the LDB scheme). There are several outstanding issues that require further research: the LDB only links entries for people - certain simplifying assumptions have been made based on this - the capability for handling the more complex interactions and interlinkages that might arise when linking information about machines, applications, or organizations; security has not been thoroughly explored, nor have access controls; the ``publishability'' of PIDs needs further investigation - are these to be used exclusively as internal pointers, or has more general ``personal access (i.e., phone) numbers''?; management and generation of unique PIDs, and the administrative problems involved. User Friendly Naming Discussion then turned to Steve Kille's paper on User Friendly Naming. The goals of this paper are the provision of: an improved method of transmitting names, and better handling of purported name lookup. The result of the discussion was that Steve would revise the paper to reflect the issues and concerns raised by the Working Group, and present it again at the next meeting. Among the issues raised were: o Tuning the algorithm to handle changes in DNs; at the moment, a change to a previously resolved DN makes that earlier resolution useless (the user would have to go through the process of resolving a purported name each time a DN changed). o The addition of ``yet another'' syntax, and the related issue of 7 other work in the field, specifically the OSF work. It was decided that the paper would reference and track the OSF work. Yew-Bong referred to the work of Al Grimstad of Bellcore, which was submitted to CCITT SG VII as a corporate position on User Friendly Naming. Current SG work should also be tracked. The X.500 SG is unlikely to provide a standard until 1996: should this method be submitted for SG VII consideration? Moving from one machine to another: is it reasonable to expect the same syntax to work under different architectures (i.e., VM and Unix, where, for example, the meaning of ```' to the command line interpreter is vastly different (quote on Unix, escape character on VM). The related issue of allowing a user to ``tune'' his environment: different machines (under the control of different organizations) might have different ``correct'' behaviour. User customization might hide or expose these differences, and make searching more difficult. Vinton Cerf and Peter Mierswa suggested that User Friendly Names are inappropriate as an ``exchange format'': only DNs should be relied upon, and communicated between users. In addition, Vint suggested that ``guessability'' was less important than exactness. Paul Mockapetris raised the question of the ``Monte Carlo'' method of name resolution: users guess at a name and receive a list of possibilities; they continue guessing until they get the DN they want or need. The user interface should allow this behaviour. The current model does not handle deep DITs very well; more work is needed in this area. It would help if the top two or three levels had ``non-obscure'' names. Wild Card searches (especially leading Wild Cards) need further investigation. Multiple occurrences of the same string in a DN (i.e., as both a county and a city) must be underlined to the user. DNs should always be returned when resolved - should users be able to build dependencies on purported names? Care must be taken when stripping RDNs for ``displayability''. Replication Solutions Steve introduced this section by noting that several documents bear directly on this subject, notably the proposed RFCs on Presentation Address Representation and Network Address Representation. It was 8 decided that these would be dealt with first. Network Addressing Steve's summary of the problem, and the solution offered in his paper: If you look at an OSI address from a DIT, you get a presentation address, which works fine with an OSI network service, but does not work with RFC1006 or X.25( 80) addresses, owing to the lack of an OSI network server for these address formats. This document provides a method, using Telex addresses, to map non-OSI addresses onto OSI addresses. It is ugly, but it is functional, and requires no extensions to current protocol. The OSF Towers solution allows you to slice different protocols in and out at any particular layer, allowing you a choice of transport and network addresses. It is a better and more elegant solution, but it requires extension to X.500(88). This is unacceptable, in Steve's view. Ideally, Steve would like to push OSI/CCITT into adopting OSF Towers for 1992; we could move to it at that time. Until then, however, it would be better to go with an interim solution that does not require protocol extensions, but that allows full inter-connectivity. After a brief discussion to clarify the reasons for adopting this method over the Towers method, it was agreed that this would be accepted as the OSI-DS WG official recommendation on network addressing, but that it would be explicitly noted as an interim solution only. Among the concerns raised were: OSF Towers and this method are both ``hacks'', the former as it requires extensions, the latter as it uses the UCL Telex number as the basis of network addresses. Steve's method is less of a hack, though. This method does not guarantee 100interpret the Telex number, then it will not be able to contact the specified entity. Steve admits that this method does not give 100success, but since it uses current protocols rather than extensions, it will offer a better success rate than Towers. Presentation Addresses Steve believes this document must be taken in concurrence with the Network Addressing document because it provides for better handling of dotted decimal encodings, and provides an extension to presentation address handling (`/' changed to `+') to bring our work in line with ISO 9 8348 (X.213). QUESTION: This is an extension to the standard? RESPONSE: Steve. Yes. QUESTION: Is there a need to represent a presentation address that specifies an IP address that is not an RFC1006 address? RESPONSE: Steve. I hope not, but we need to be able to specify IP addresses that are not on the Internet, such as local LANs. After minimal discussion, it was agreed that this document should proceed in parallel with the Network Addressing paper. Replication Solutions Steve provided an overview of the current proposal: Sec. 1: Benefits of the approach: it has been proven in operation; owing to its current use, there will be minimal effort involved in moving to it as a pilot standard; the approach is simpler and easier to implement than the current standards approach. Sec. 2: Enhancement of Distributed Operations to provide better handling of referrals and chaining (an extension to the standard). This approach is closely tied to the previously reviewed papers on network and presentation addresses. It uses the concept of a ``community'' (coded into the presentation address) to allow a DSA to decide if a DUA and another DSA can in fact communicate directly. Sec. 3: Extend the semantics of X.500 so that DSAs can deal more intelligently with Subordinate, Cross, and Non-Specific Subordinate, References. Sec. 4: The replication data model: replication of all sibling entries rather than subtrees, or specific entries. Sec. 5: Improved DSA naming: placing DSA names in a well known DSA with root knowledge; placing DSA names in the higher (closer to the root) portions of the DIT. Sec. 6: Definitions of objects necessary to represent knowledge information in the DIT (rather than having DSAs maintain it as a ``local matter''). Sec. 7: Definition of a simple replication protocol: data propagation 10 in a star-like fashion. Sec. 8: Definition of the ``Internet DSP'' Application Context to allow for easier identification of Internet extensions. Sec. 9: Scaling limits and migration strategy. Sec. 10: Reserved for future definitions of application contexts, object classes, and attributes necessary for replication The result of the discussion was that Steve would revise the paper to reflect replicated EDBs in pieces, rather than single units. This extension will be available in the next release. In addition, Steve introduced the ASN.1 required to allow QUIPU to transfers replicated EDBs in pieces, rather than single units. This extension will be available in the next release. Steve also suggested that it would be appropriate to write a paper on how to structure the DIT to achieve high performance and high reliability using current replication methodologies. He took this as an action item for himself. This document could then be put forward as a statement of administrative guidelines on DSA naming, and DIT structure. Issues raised: Scaling: the paper quotes 10000 units as the upper level of scalability. Steve noted that this refers to fan-out, not number of entries, as the unit of replication is a single level, and not an entry or subtree. Steve also noted that QUIPU would be extended to allow incremental updates of replicated data using an MHS. Since the master DSA would always be reachable, there would be no problem in using MHS to transfer EDBs while using replicated data to lookup the appropriate MHS address. DSA-DUA communities. The paper as presented did not properly described how a DSA decides whether or not a DUA and another DSA can communicate directly. Steve indicated that he would rephrase Section 2 to reflect the fact that PSAP communities are used to make this decision, not actual physical connections. Vint asked whether access controls were replicated. Steve answered that private agreements must be used to maintain ACLs on replicated data, and that an open environment would be publicly readable. ACs are stripped during replication as they are a private matter: only published schema get transferred. 11 Paul questioned the Section 3 use of NSSRs: the changing of NSSR semantics from AND to OR would mean that multiple DSAs could not hold different ``chunks'' of superior entries. Steve indicated that he would place a clear warning about this in the document. Expiration dates on information: Two separate issues were identified: caching and replication. It was determined that caching requires a TTL mechanism, but that replication can use a simpler approach, such as having a slave make regular ``pulls'' from the master. Paul noted that applications must be built to expect stale data (X.500 makes no guarantees about data freshness), and that obtaining authoritative data is an application problem. It was decided that the unit of replication would be delivered with an advisory refresh date. Naming Architecture Registration Steve: In order to build useful applications, we need to extend the Naming Architecture as supplied in the standard. This paper describes the formal administrative support for the creation of new elements in the architecture. The aim of this session is to discuss and define the registration and maintenance methodologies (currently UCL maintains pilot architecture for both the Internet and COSINE). UCL would maintain ownership of this document until the end of the COSINE project in December of 1992. It is hoped that this work will have been incorporated by the standards bodies by that time. The document defines an arbitration method for deciding what does and does not become part of the naming architecture: the editor has discretionary powers to include, exclude, or modify, as needed, subject to appeals to the OSI-DS Working Group mailing list, or arbitration from RARE and the OSI-DS Working Group. After a brief discussion, it was agreed that this document could be issued (with minor revisions) as the first RFC of the DS series, and that it would be updated every 3-6 months. Issues raised: Size of entries in a DIT: concern focused primarily on the size of the photo attribute. After some discussion, Steve indicated that he would reword the document to indicate that participating DSAs can store entries at their discretion, but that if they choose to store entries of a given type, they must agree to store the published attribute maximum sizes. Several individuals mentioned concerns with certain object classes and attribute types listed in the paper. After gentle chiding from Steve, they agreed to test the procedure by submitting complete ASN.1 proformas for the additions they were concerned with. 12 Steve indicated that he would make an arbitrary decision whether or not to include the appendices Unix shells for Naming Architecture Maintenance. They were considered useful, but not for everyone. Security Considerations Peter Yee: this paper identifies some of the security issues that must be addressed when planning a security policy for the Internet pilot. Steve Kille: We must distinguish between X.500 as a user and as a provider of security for the pilot. As a provider, we can use X.509 in a very straightforward fashion. As a user of security services, we have a more interesting issue. Unlike replication, we can work entirely within the standards. We need to prepare notes identifying the organizational issues involved, and documenting methods addressing these issues. There are three main areas of concern: authentication, access control, and remote updates. After considerable discussion, it was agreed that Peter Yee should revise and resubmit his document for consideration at the next meeting. Steve Kille asked for volunteers to do the ``voluminous legwork'' required to research and resolve the open items in this area, but there were no volunteers. Issues raised: Remote management. There was considerable disagreement over the issue of simple authentication as adequate security for remote management. PEM representatatives and proponents of strong authentication felt that simple authentication was not appropriate, as it would be too easy for an outsider to remove or modify certificates, or keys. One proposed solution that was partially acceptable is the requirement that DSAs be able to store X.509 information (certificate lists, public and private keys, certificates), and that DSAs using simple authentication or no authentication would not allow remote updates. Searchability. Several participants indicated that without some form of access control, they would not open their DSAs to the Internet, as they did not want to allow ``DSA dumping''. It was generally accepted that authentication (simple or strong) or ``skinny pipes'' on searches would be acceptable. Steve Kille has since proposed a method of limiting searches and lists to the OSI-DS Working Group mailing list. 13 Applications that require X.509. There was some debate over whether or not the number of applications requiring strong authentication would actually increase if it were provided. More research is needed, as this is a ``chicken or egg'' situation: do the applications cry out for X.509, or does X.509 invite new applications? The relationship between the OSI-DS Working Group and RSADSI/PKP. It was suggested that perhaps the IETF or the IAB could negotiate an Internet-wide RSA license with the relevant bodies. More liason work and research is needed. Next Meeting SRI offered to host the next meeting in California, Feb. 12-13. Steve will issue a preliminary agenda in the near future. AOB Standard APIs. It was agreed that the IETF should adopt a standard API for the pilot. X/OPEN and XDS were mentioned. This item will be discussed further at the next meeting. The Canadian X.500/Library Project. Dave Brent asked if the Working Group should look into this. Steve asked for volunteers to propose an RFC on the subject. This will be discussed at the next meeting. Attendees Karl Auerbach karl@eng.sun.com David Brent brent@CDNnet.ca Ross Callon callon@bigfut.enet.dec.com Lida Carrier lida@apple.com Vinton Cerf vcerf@NRI.Reston.VA.US Richard Colella colella@osi3.ncsl.nist.gov Curtis Cox zk0001@nhis.navy.mil Tom Easterday tom@nisca.ircc.ohio-state.edu Karen Frisa karen.frisa@andrew.cmu.edu J. Joaquin Garcia-Luna garcia@sri.com Gita Gopal gita@bellcore.com Martin Gross gross@polaris.dca.mil Ian Hamilton ianh@bnr.ca Alf Hansen Alf.Hansen@pilot.cs.wisc.edu Juha Heinanen jh@funet.fi Harold Jones hjones@nac.dec.com Steve Kille S.Kille@cs.ucl.ac.uk Mark Knopper mak@merit.edu Paul Koski koski@hpindeg.cup.hp.com 14 Marilyn Martin martin@netcom.ubc.ca Judy Messing messing@gateway.mitre.org Peter Mierswa mierswa@smaug.enet.dec.com Greg Minshall minshall@wc.novell.com Paul Mockapetris pvm@darpa.mil Daniel Molinelli moline@trw.com James Mostek mostek@cray.com David Oran oran@sneezy.enet.dec.com Marshall Rose mrose@psi.com Theresa Senn tcs@cray.com Harvey Shapiro shapiro@wnyose.nardac-dc.navy.mil Karen Sollins sollins@lcs.mit.edu You-Bong Weon-Yoon youbong@arch2.att.com Peter Whittaker pww@bnr.ca Linda Winkler b32357@anlvm.ctd.anl.gov Dan Wintringham danw@osc.edu Russ Wright wright@lbl.gov Sze-Ying Wuu syww@thumper.bellcore.com Peter Yee yee@ames.arc.nasa.gov David Zimmerman dpz@dimacs.rutgers.edu 15