CURRENT_MEETING_REPORT_ Reported by Kevin Jordan/CDC Minutes of the X.400 Operations Working Group (x400ops) The section numbers in these Minutes follow the Agenda item numbers in Alf's proposed Agenda for the Santa Fe meeting. 1. Welcome The meeting was chaired by Alf Hansen, and Kevin Jordan volunteered as secretary. There were no additional comments against the Atlanta meeting minutes. Action List from Atlanta meeting 1. Hagens/Hansen to revise draft RFC and distribute to the Working Group. Status: done. NOTE: At the Atlanta meeting, we discussed the need for a separate document which would describe the strategy for X.400 Operations in the international X.400 internet. In Santa Fe, we decided that this document is not needed. 2. Jordan to update white paper on use of X.500 for support of X.400 routing and address mapping and distribute to the Working Group. Status: done. 3. Allocchio/Eppenberger to write a white paper on use of DNS for support of X.400 routing and address mapping. Status: not done. They wrote software instead! The software will be made available to the RARE/COSINE and XNREN communities. 4. Hardcastle-Kille to update 88->84 downgrading draft RFC and work with EWOS to make support of DD.COMMON well defined and mandatory. Status: draft RFC updated. 5. Yee to do some research into North American groups such as EMA and NADF and make recommendations for liaison with these groups. Status: Yee was unable to attend the Santa Fe meeting. Peter plans to email his findings to the Working Group. 2. IETF X.400 Operations Working Group Business 1 o Review of new charter. It was decided that the following changes should be made to the charter: 1. The charter should be updated to include references to other documents in progress, e.g. the Routing and Mapping documents. 2. The charter should reflect that our work on X.400 operations and deployment will not be complete by 12/92. 3. The charter will probably be updated occasionally as X.400 operational requirements evolve and as real experience in X.400 operations becomes more broad. o Relations to other groups. Significant changes were made to the draft RFC as a result of comments made against it at the RARE WG1 meeting which took place shortly before the Santa Fe meeting. While most of these changes were technically justified, and the authors were given authorization to make such changes at the Atlanta meeting, it was strongly recommended that this sort of change not be undertaken in the future without the review and consensus of the IETF Working Group. The RFC is supposed to be the product of the IETF Working Group. The IETF Working Group respects and welcomes contributions from RARE WG1, but North American members of IETF are not eligible to be members of RARE WG1, so they are unable to express their views through votes at RARE WG1 meetings. Therefore, significant changes to the draft should not be made without review and approval of the IETF Working Group membership. 3. Nil (Alf's Agenda lacked an item numbered 3) 4. X.400 Service Milestones Each member of the Working Group presented highlights and milestones of X.400 service provided at his/her home site. XNREN Project. More and more sites are joining the XNREN Project. However, X.400 traffic continues to be relatively light. Very little progress has been made on establishing connections to public ADMD service providers. The University of Wisconsin has established an experimental and publicly available X.400-based fax service. The fax service imposes some constraints and limitations. Contact Rob Hagens and/or Allan Cargille for details. Norway. The Norwegian R&D X.400 network currently serves over 5000 active users. The principal Norwegian WEP carries between 20,000 and 40,000 X.400 messages per month. 2 COS. The Corporation for Open Systems has installed PP and SunLink/MHS internally. COS is planning to connect its X.400 service to the Internet and wants to use OSI CLNS in addition to RFC1006. Navy. The U.S. Navy is aggressively pushing X.400 internally. It is deploying various types of X.400 gateways. Transport/network services provided include X.25 and CLNS. MERIT. MERIT drove the OSI infrastructure demonstration at Interop '91. For Interop '91, MERIT managed to use CLNS to interconnect virtually every regional network of the U.S. Internet successfully. Sites in Europe (especially Finland) were also interconnected using CLNS. X.400 mail was successfully exchanged between a variety of sites over Internet using CLNS. MERIT also provides a gateway between NSFNet and SprintMail. ESNet. ESNet continues to implement and deploy X.400 internally. ESNet plans to make X.400 mail a production oriented service by January 1, 1992. CDNNet. X.400 traffic levels continue to grow. The primary CDNNet MTA currently exchanges between 10,000 and 15,000 X.400 messages per day. CDNNet is subscribed as a PRMD to ADMD Telecom Canada. CDNNet is seeking approval to become an ADMD itself. CDNNet maintains the EAN X.400 mail software and has recently developed an X Window System based X.400 user agent. Slovenia. The X.400 R&D network in Slovenia currently serves over 2000 active users. GARR. X.400 traffic continues to increase. GARR is connected to the public X.400 networks in Italy. GARR provides a centralized gateway service to a variety of other email networks including HEPNet, SPAN, EARN, and Internet. GARR supports multiple protocol stacks including X.25, RFC1006, DDCMP, and CLNS. NORDUNet. NORDUNet has initiated a project to improve the reliability of the email services in the Nordic countries. Alf has been appointed as the official NORDUNet Mail Inspector. 5. Review of ``Requirements for X.400 Management Domains (MDs) operating in the Global R&D X.400 Service.''. 5.1 The Document Itself 3 The following revisions will be made to the draft RFC: 1. The title of the RFC will be changed to: ``Operational Requirements for X.400 Management Domains'' 2. References to ``Global R&D X.400 Service'' will be changed to ``International X.400 Service'' throughout the document. 3. Paragraph 3 of ``Status of this Memo'' will be removed prior to publication. 4. Clarify that ADMD's are invited to join The Service and comply with the operational requirements set forth by the RFC. 5. Section 1.1 - Indicate that conformance to U.S. GOSIP and European ENV is required, plus additional requirements as specified in this RFC, e.g. support for DD.RFC-822 is required. 6. Section 1.2 Terminology should occur before section 1.1. 7. Section 2.2 - Remove the editor's note. 8. Section 2.3 - Rewrite this section to state the general multistack, multinetwork problem and refer to the companion routing documents for detailed solutions. 9. Section 3.1 - The editors will review this whole section, rewrite it, and distribute the revision to the Working Group for review and comment. 10. Section 3.1.6 - Revise the naming recommendations to reference relevant RFC's and Implementor's Agreements. Also, include a succinct recommendation (a sentence or two) in the RFC. 11. Section 3.2 - Remove this section because this RFC applies to '84 implementations of X.400 only. 12. Section 3.3.1 - References to section 4.1 should be changed to reference section 3.1. 13. Section 3.3.1.1 - Change ``The Internet Community in the U.S.'' to ``The U.S. Internet Community''. Also, recommend that PRMD=Internet be used -only- in the context of addressing the generic (i.e. nearest) RFC1148bis gateway. 14. Section 3.3 - Refer to RFC1148bis and indicate that conformance to it is mandatory. 15. Section 3.3.2 - Remove reference to annex ``NA-Guidelines''. 16. Section 3.4 - Add an indication that the static approach to routing and address mapping is a short term solution. 5.2 The References Urs will distribute a new revision of his Routing Coordination paper. 4 The new revision will reflect comments made at the recent RARE WG1 meeting. Harald Alvestrand will polish his ``Routing Policy'' draft and distribute it to the Working Group. It was agreed that this paper should become one of the RFC's in the X.400 set. It will be referenced by the base RFC. 6. Use of an X.500 Infrastructure For Routing Purposes Jordan's X.500 white paper was generally well accepted. However, the following recommendations were made against it: 1. As an optimization to the route determination algorithm, take advantage of the fact that a failed directory read operation will return a distinguished name prefix in the case that part of a distinguished name is matched. This can be used to locate the longest match of an O/R name in one read, and a second read can then be used to obtain desired attributes. 2. Update the document to allow for PRMD's explicitly under ADMD's and propose that the X.400 tree be rooted under a new object occurring under country (rather than rooting the X.400 tree directly under country). 7. Status and necessary actions for implementation of experiments with the draft RFC for use of the DNS system for address mapping purposes Claudio has implemented a scheme for using existing PTR resource records to store address mapping information. He has also implemented a scheme for using MX resource records to store X.400 routing information. Tools have been implemented for extracting PTR and MX records and producing RARE tables from them. The Italian PARADISE Project is also implementing Kevin Jordan's recommendations for using X.500 to support X.400 routing and address mapping. 8. Summary of Conclusions and Actions P. Yee Peter will distribute his recommendations for 5 liaisons with other groups. R. Hagens, A. Hansen The editors will review section 3.1, rewrite it, and distribute it to the Working Group for review and comment. The RFC authors will revise the document in accordance with the comments and conclusions generated at this meeting. A new draft will be distributed prior to the next IETF meeting, no later than January 15. J. Geiter Jishoo will write a recommendation for the construction of X.400 names based upon relevant RFC's and Implementor's Agreements. A. Hansen Alf will formally propose to RARE WG1 that mapping coordination procedures be published as RFC's. All The issue of ADMD=`` '' versus ADMD=0 will be discussed via email after the text about this issue from the recent RARE WG1 meeting is distributed. K. Jordan Kevin will rewrite his paper on use of X.500 for support of X.400 as a pair of draft RFC's: one related to use of X.500 for X.400 routing purposes, and one related to use of X.500 for address mapping purposes. NOTE: This action should be reconsidered in light of Steve H-K's comprehensive paper on the same subject. I propose that we adopt Steve's paper as the basis for further work in this area. U. Eppenberger Urs will update his paper on static routing and mapping procedures and present it as a draft RFC. Other Business Borka and Harald each made presentations on national character set issues and suggested alternatives for solving this problem with respect to X.400. The Working Group made no conclusions but agreed that this issue needs further discussion at future meetings. Future Meetings 6 The next general IETF meeting is scheduled for the week of March 16 in San Diego, California. The X.400 Operations Working Group will meet on March 17 and March 18. Attendees Claudio Allocchio claudio.allocchio@elettra-ts.infn.it Harald Alvestrand herald.alvestrand@delab.sintef.no William Biagi bbiagi@cos.com Ken Carlberg carlberg@cseic.saic.com Cyrus Chow cchow@ames.arc.nasa.gov Richard Colella colella@osi.ncsl.nist.gov Curtis Cox ccox@wnyose.nctsw.navy.mil John Demco demco@cs.ubc.ca Tim Dixon dixon@nikhef.nl Jisoo Geiter geiter@gateway.mitre.org Tony Genovese genovese@es.net Robert Hagens hagens@cs.wisc.edu Alf Hansen Alf.Hansen@delab.sintef.no Susan Hares skh@merit.edu Christian Huitema christian.huitema@sophia.inria.fr Borka Jerman-Blazic jerman-blazic@ijs.ac.mail.yu Kevin Jordan kej@udev.cdc.com Scott Kaplan scott@ftp.com Jim Knowles jknowles@trident.arc.nasa.gov Walter Lazear lazear@gateway.mitre.org Jack Liu liu@koala.enet.dec.com Linda Winkler lwinkler@anl.gov Robert Woodburn woody@cseic.saic.com Russ Wright wright@lbl.gov 7