CURRENT_MEETING_REPORT_ Reported by Judy Messing/MITRE OSI X.400 Minutes Agenda o Review of Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables o X.400 Deployment Issues o XNREN Discussion o Announcement of new Working Group o Operational Issues Discussion - PRMD Organization - Originator/Recipient Name Assignment - Address Mapping The meeting was convened by Robert Hagens, Working Group Chair. The revised ``Draft Proposal for the Use of the Internet DNS to Maintain RFC 987/RFC 1148 Address Mapping Tables'' (by Cole and Hagens) had been circulated on many mailing lists prior to the meeting. This proposal describes how the DNS could be used to store, retreive, and maintain the mappings between RFC 822 domain names and X.400 O/R addresses. The first order of business was the review of this draft proposal. The following issues were discussed and resoved during the review: 1. Placement of TO-X400 and TO-822 resource records in the DNS tree (Section 4). It was decided that both records should be placed under the same DNS root. This should be done in both the transitional and experimental phase of using the DNS for the mapping tables. A suggestion was made to demonstrate this placement more clearly in the document by a drawing of the domain name hierarchy. 1 Steve Kille noted that placing the two records under the same root provide a good facility for management of the mappings, distribution of zones of the DNS, and for zone transfers. Placing the records under the same root will result in a routing performance loss because it requires lookups in two trees. 2. Determination of name for T0-X400 and T0-822 root (Section 4). Hagens suggested the root name ORMAP.ORG. Steve Kille suggested a new top level domain .TABLE. Then the root name would be ORMAP.TABLE. The consensus was to request a new top level domain .TABLE. If this request was not granted, the records should be placed in ORMAP.ORG. 3. Structure of O/R Address in Domain Name Syntax (Section 4.1): Alf Hansen proposed three alternative solutions: o The syntax given in Appendix F of RFCs 987 and 1148. o An algorithmic, more human readable, syntax replacing blank attributes with a hyphen. o An algorithmic, more human readable, syntax dropping blank attributes. Steve Kille remarked that the text syntax of RFCs 987 and 1148 are now being used in other environments and strongly argued for remaining aligned with that syntax. This syntax is also used in the DNS standard. The consensus was to keep the syntax aligned with the RFCs and to refer to RFC 1148 in the draft standard when discussing the structure of the O/R addresses. The RARE printable format will be used in text examples. In section 4.3, Step 2 of the example, the wildcard count of 5 is a typo. This will be changed to 6. 4. Error Recovery (Section 4.4): A discussion on the appropriate action for the mapping algorithm based upon the DNS response code resulted in a recommendation that this section be rewritten. The new section on Error Recovery will reflect the way RFC 1148 handles the case where a hit is not found in the mapping lookup table. 5. RFC 1148 Issues: The draft will reference RFC 1148 as the primary address mapping document. RFC 987 will be referenced as a secondary document. 6. Proposed Resource Records (Section 3): Hagens reported that the types assigned to the new Resource Records defined in the document are incorrect, but that real values would be assigned when the draft is issued. 7. DNS Address Class (Section 6): Discussion was held on whether the new Resource Records should be assigned to the Internet address class, IN, or the ISO address class, ISO. Suggestions for the assigned address class were to omit it, use a wildcard, add a new class called ``mapping'', or use IN. The question was raised as to 2 whether the DNS implementations actually accepted an address class other than IN. The decision was that IN would be acceptable, but that Hagens would coordinate the address class assignment with Paul Mockapetris. 8. Transition Phase (Section 5.3.2): The consensus was to remove this section from the proposed draft and expand it into a separate document. The current proposed draft and the new transition document will reference each other. 9. Coordination and Administration (Section 5): The proposed draft spoke of the master copy of the mapping database as the copy stored in the DNS namespace. Steve Kille pointed out that there is a global use of the mapping database and that it could be stored in three forms: table form, DNS form, or X.500 form. At his suggestion, the Working Group agreed that the proposed draft should define a model on the global use of the mapping table and the proposed transition document define the details of how the model would be actualized. The model is based on country. As a national issue, each country decides whether its master copy of the mapping database is stored in the DNS, a table, or an X.500 directory. If a country changes from one master to another, it takes responsibility for moving from its original master to its new master. Procedures to follow when a country chooses to transition from one master to another must be developed. Currently the RARE project is mastered in tables. Each country maintains its own tables and the RARE Working Group maintains the global mapping table. The United States will be mastered in the DNS. At this time RARE is responsible for maintain the mapping tables and the University of Wisconsin is responsible for maintaining the DNS mapping records. Discussion of XNREN PRMD Alf Hansen gave a presentation on the XNREN, the Wisconsin Internet X.400 pilot project PRMD. He made the following points: o XNREN is experimental in nature. o XNREN is a production-quality service-oriented PRMD. o XNREN can be joined by any organization willing to operate a local X.400 service and contribute to a better understanding of operational issues. 3 The Wisconsin pilot project will offer ARGO X.400 code to non-commercial private organizations. Currently there are two X.400 implementations in XNREN: the University College London PP and Wisconsin ARGO X.400. The pilot project is focusing on short term operational problems. NSF has funded it for two years. Participating organizations must agree to the following: o Register their organizations and organizational units with the ad-hoc XNREN Naming authority. o Appoint a MHS site manager. o Operate any RFC987 gateway according to agreed upon rules. o Define X.400/RFC822 address mappings. o Use commonly agreed upon mappings. o Use locally defined mappings. o Route traffic external to XNREN according to specified rules. The XNREN pilot is a member of the International RD Service. It provides connectivity to Internet mail and, under the leadership of the Corporation for National Research Initiatives, plans to establish contact with the national ADMDs with the goal of negotiating interconnection agreements and experimental exchange of messages. The XNREN PRMD is also interested in exchanging experiences and establishing connectivity with other Internet PRMDs. XNREN will offer the following services: o Assist participants in the pilot in setting up their X.400 service. o Produce informational material about service developments. o Take an active role on X.400-related mailing lists. o Allow testing of new software and procedures in XNREN. o Incorporate X.400 technical innovations into experiments. o Use the X.400 infrastructure to experiment. Contact XNREN at: postmaster@cs.wisc.edu or X400-project-team@cs.wisc.edu. 4 MERIT is operating an X.400 gateway to Internet for SprintMail. Mark Knopper expressed interest in directly routing to XNREN. New Working Group Announced Rob Hagens announced the formation of the X.400 Operations Working Group. Its goal is to insure interoperability between Internet PRMDs. The first task of the group will be to draft a document that specifies requirement/conventions of Internet PRMDs. Membership in this Working Group will be limited to people with planning, deployment, and operational responsibilities. The Working Group will address the following issues: o Basic Assumptions o Connectivity - Stack Choice - Degree of interconnection o Routing - Necessity of well-known entry point - Policy on transit traffic - How to connect to ADMDs o Collective representation of PRMDs - Internationally - Interacting with public carriers o Forum for addressing mapping coordination o 1984/1988 issues o X.500 issues The group discussed the necessity of forming a new Working Group. Steve Kille wondered if the work was not within the scope of this Working Group. Hagens said that the new Working Group was operational and motivated toward concrete progress. He also said that if the current Working Group had completed its agenda, it could be dissolved. The first meeting of the X.400 Operations Working Group will be February 4-6, 1991 at NASA-Ames. Operational Issues Discussion: PRMD Organization Rob Hagens announced that a preliminary meeting of X.400 operational people had been held on November 28 at the University of Wisconsin. The following general assumptions had evolved for the Internet PRMDs: 5 o PRMDs can be directly connected to each other. o PRMDs will not all be directly interconnected. o PRMDs must have unique names in the US. o A PRMD can be a naming authority for its organizations. o A PRMD can be connected to 0 or more ADMDs. o X.400 addresses should reflect organizational structure. Address Mapping Alf Hansen presented two proposed methods of address mapping when a user of an X.400 system wants to send mail to a user of an RFC 822 system and vice versa. One solution consists of mapping the elements of the receiver's mail system address into elements of the sender mail system address structure. The receiver address then looks like a valid address of the sending mail system. In the second solution, the receiver's address is left in the syntax of his mail system. For the X.400 to RFC 822 case, the recipients address is placed in a Domain Defined Attribute and the Organization indicates the community the address refers to, e.g., Internet or RFC822. In the RFC 822 to X.400 case, the recipient address is placed in quotes in the left-hand side term of the domain name; the community it placed on the right-hand side of the @ sign. The group discussed the mapping issues, but no decision was made. Steve Kille warned that if the chosen solution generates X.400 addresses than messages with those addresses must be able to be delivered. 1988 X.400 Steve Kille suggested that the Working Group name 1988 X.400 as the Internet supported standard. He pointed out that 1988 X.400 supported directory, security, distribution lists and the message store. Kille said one defect of 1988 X.400 was that it did not allow a 1984 X.400 user to address an arbitrary 1988 user. However, he said he had a simple proposal that he intended to specify to correct this problem. In the discussion, it was pointed out that GOSIP does not specify 1988 X.400 until GOSIP Version 3, which is two years away. The final discussion of the meeting centered on determining if there was any interest in writing a MIB for X.400 and X.500. Attendees David Brent brent@CDNnet.ca Lida Carrier lida@apple.com 6 Robert Cooney cooney@wnyose.nardac-dc.navy.mil Curtis Cox zk0001@nhis.navy.mil Robert Hagens hagens@cs.wisc.edu Alf Hansen Alf.Hansen@pilot.cs.wisc.edu Steve Kille S.Kille@cs.ucl.ac.uk Mark Knopper mak@merit.edu Walter Lazear lazear@gateway.mitre.org John Linn linn@zendia.enet.dec.com Judy Messing messing@gateway.mitre.org Tim Seaver tas@mcnc.org Theresa Senn tcs@cray.com Harvey Shapiro shapiro@wnyose.nardac-dc.navy.mil Linda Winkler b32357@anlvm.ctd.anl.gov Dan Wintringham danw@osc.edu Russ Wright wright@lbl.gov Peter Yee yee@ames.arc.nasa.gov 7