CURRENT_MEETING_REPORT_ Reported by Alan Cargille/University of Wisconsin Minutes of the X.400 Operations Working Group (X400OPS) Executive Summary o The Amsterdam minutes were not approved. They will be revised. o The postmaster document will receive final editorial comments and be submitted for consideration as a standards-track RFC. o The management domains requirements document will receive final editorial comments and be submitted for consideration as an Informational RFC. o A revised document on storing RFC 1327 mapping rules in the DNS will be released within a few weeks. A new companion document about how this should be administratively implemented and deployed will be written by the next IETF or the meeting of the RARE Working Group on messaging. o The proposed CXII group will continue to be discussed on the cxii list. If it cannot be finalized by the Seattle IETF, the group will probably not be created. o The work on ADMD IMX is viewed as a United States national issue and should be developed in some US forum, not the IETF. The work should be fed back into the IETF for comments and publication. o A sister group to the IETF on operations may be created (the IOTF). o The X400OPS Working Group will be terminated following this IETF. Outstanding work items can be brought up on the X400OPS mailing list. If worthwhile, a small focused working group will be created to work on the new topic. Thanks to Tony Genovese and Alf Hansen for chairing this group. Goodbye, and thanks for all the fish! Review of Action Items This was difficult to do because action items were not summarized in previous minutes. This section will be updated as the Amsterdam minutes are revised. Jim Romaguera conducted the review of the minutes from the last meeting. They are were not approved. They had been submitted in a rush. Alf and Tony apologized for incomplete minutes being published. Marko and Urs had sent messages requesting changes to the minutes which were not made. Marko's name was misspelled in Section 6. He was unhappy with the proposed chairs in Section 10. The Amsterdam minutes will be reviewed again on the list and revised. Allan Cargille foolishly volunteered to edit the revised minutes. Action items need to be identified, both those from the previous meeting (Columbus) at the beginning of the document and those from Amsterdam in the body. We can also check the X400OPS list archive for comments on the minutes. Postmaster Convention for X.400 Operations Allan Cargille reviewed the key idea of the document. He removed the section about supporting an easy way to reach the managers of an X.400 management domain (ADMD or PRMD) out of the document and plans to write that up in a separate document (edit out the part about 84 and 88, just say both are running and reference both standards). There was consensus that the group will forward the document for consideration as a standards-track RFC. Allan will revise the document and clean up the references. He will then publish it as an Internet-Draft and ask for comments for one week on the ops list. This final review is for editorial comments only. Allan will make any necessary corrections and forward the document to be published. Allan will have the revised Internet-Draft out by November 8. Operational Requirements for X.400 Management Domains Alf made editorial changes to the document and cleaned up the references. Few people have read the final version. The document is available and key people are asked to review the document for editorial changes: Tony, Urs, Jeroen, Harald, and Allan. We will close discussion by November 15. People who read the document should let Alf and Tony know that they have read it. Tony will buy a beverage for the person who finds the most typos! DNS support for RFC 1327 Mapping Claudio has been working on a mechanism to store and look up RFC 1327 mappings using the DNS. The first proposal received some strong requests for changes from the namedroppers mailing list (DNS experts) at the March 1993 IETF. Claudio had also done work on storing X.400 routing and MTA connection information in the DNS. This work has been suspended in favor of using X.500 (the IETF MHSDS Working Group work). Claudio has developed a second version of his proposal. The document will be published as an Internet-Draft this coming week. He presented the major changes of the new approach. The new approach defines a new DNS resource record which allows a single DNS query for a lookup. Some extensions are also included for eventual future use. The new approach stores Table 2 (822 to X.400) and ``Gateway Table'' mappings in the normal DNS domain tree. Table 1 (X.400 to 822) mappings will be stored in a separate tree, rooted at the national level. This approach forces coordination between the X.400 and DNS naming authorities. This will require considerable work in explaining concepts and coordinating things. Claudio said there is a need for an API specification. Mapping coordination at the national level will be achieved in different steps, according to the draft document on mapping authorities. It fits into the regionalization process currently ongoing in the internet. It allows a full authority delegation as a final result of the process. An orderly transition is supported from centralized storage of the mapping rules in Italy to using the new national mapping tree, because software will support checking the national tree first and looking in the Italian tree if nothing was found. Mapping rule storage and control will proceed in three different steps: 1. The information is maintained centrally in Italy and servers fallback to that location for lookups. 2. The national trees are implemented but things are centralized at the national level. 3. The information is truly distributed in the national trees. The document also makes it possible to define a DNS/x.500 interface to make LONGBUD and DNS a unique schema for mapping distribution, with no duplication and global accessibility. There was general concern about an update problem with two distributed mapping storage technologies (DNS and X.500). Urs said that the technical work is done and is solid, and that we need to think about the administrative work that is necessary to use this technology. The group notes that this work has implications on the MHSDS Working Group. Claudio will write a separate document about information and deployment of this technology by the next RARE MSG or IETF meeting. Further discussion of both documents will proceed in the RARE Working Group on messaging. Commercial X.400 Interconnection with Internet (CXII) Working Group A proposed charter was included as input to this meeting. Tony Genovese led this discussion. Tony's slides are on the ESnet file server (FTP to ftp.es.net, the directory is pub/mhs/x400ops/houston). o Since Amsterdam: - There are two points of contention: chairs and technical contributors. - The chairs will be determined solely by the Area Directors. - Technical leads are needed for document sets. - There is already one volunteer co-chair, but another is still needed. - Technical leads for documents are needed. - The working group will be in the Operations Area but Erik Huizer (without his co-director) will serve as Area Director for the group. o Questions: - Should the area be worked on? (SK - in general? Or in IETF?) - Are there problems in this area? (agreement: YES) - Which problems? - Who wants to work on them? - Will any commercial providers come in and participate? Erik working to get EMA and EEMA participants, and may be able to find a co-chair for the group from a commercial service. o Attendee Input: - Steve: There is a report on EEMA work in this area. The issue was raised in the EEMA PRMD operators group---requirement for X.400 to Internet working. X.400 mail users wish to communicate with the Internet and vice-versa. It is not service provider initiated, but user initiated by big customers. X.400 is real and a large group is using it and is serious about using it. There were two meetings with large attendance on interconnecting. Jim Romaguera contracted to write a series of reports for that group---were they circulated to the x400ops list? There are two issues: technical and commercial. The technical work is essentially completed. Real issues are commercial ones. To make this fly a commercial model must be built which will allow interoperation between these communities. It is quite clear that if you do not find a commercial model that will accommodate both worlds then we have a serious problem. Commercial---pay for e-mail service. Internet - pay for pipe, e-mail ``free.'' GOMHS using internet model. Need to develop a viable commercial model. Users are prepared to pay for services as long as charges are reasonable (appropriate). IP providers and X.400 providers are competing with each other. Have to formulate a connection in a way which protects the operational interests of both parties. Have a problem if you just expect the ADMDs to connect up for free. Steve chairing small group of five people in EEMA---two Internet providers and two commercial providers (DBP and Mercury, UK) trying to put together a commercial proposal---a small forum to try to make progress on this. - Tony: Concerned about EEMA putting out documents with no review process, Internet input. - Steve: Feels a forum is needed which balances Internet and ADMDs, or is heavy on ADMDs. In a group which is mostly research and development the ADMDs will not be comfortable and progress will not be made. Model problem---ADMDs cannot talk to anyone who is ``responsible'' for the Internet mail service. - Tony: The real problem is that national mail services make agreements but the agreements do not cover the whole Internet community, just that specific community. - Marko: EEMA small forum is strictly commercial (IP and ADMD) and the research and development community is not represented. - Harald: In the IETF, work is done by informal design teams, and working groups are for review and discussion. Is it a good idea to have the review process in this group (x400ops) or elsewhere in the IETF for EEMA outputs? - Erik: Sees the need for work in the IETF forum. Sees need for EEMA work. Not too happy with small EEMA team because both are commercial providers (IP and ADMD). There is tradition and experience in the IETF community. We have a community to serve which needs to be connected to ADMD world. Need to get our own perspectives right on how we think these services should be operated. Need to start thinking about service levels, with commercial perspective. Need to understand what the commercial world wants, and whether our customers want that too, if we can live up to it too, etc., if so, what are the requirements and what do we have to do to get to that point? He does not see necessary progress happening if EEMA output is not subject to review and is imposed on the Internet community. - Steve: EEMA assumes CXII work will happen, and will liaison with the group if it occurs. - Erik: No use to do CXII work unless we can get commercial participation. Only has use if we do this in a real collaborative effort with the ADMD community. Sees a real use for that. - Urs: It seems like CXII is trying to find business arrangement between service providers. This is not the IETF's business. - Steve: * Short discussion of problems * Agreements that could be put in place * How do you coordinate the whole thing * Will never find one model that does everything---connects whole Internet to entire X.400 service. Need to show how to tie the pieces together. Connecting X.400 commercial services to the Internet e-mail community (822 and X.400) will include many pieces. - Erik: Let's focus. Identify the errors which are not covered by the documents we have done yet, which are worthwhile covering: mapping coordination, accounting, service levels, helpdesks, levels of logging and trouble shooting, etc. There will not be a BOF in Seattle if the list does not reach consensus by then. Purpose of the first document is vague. The second and third identify exact points that need to be covered. If there is agreement, a meeting can be held in Seattle. Need to specify, ``This document is trying to address the following problems: ...'' - Allan C.: Documenting various business models is highly appropriate. Imposing one business model is not. Documenting them would be very helpful. Others agreed with this. A small group met for a follow-on CXII discussion. The results of this meeting will be mailed to the cxii list. US-ops Allan Cargille led this discussion. He outlined two different issues which fall under this agenda item: o The work on ADMD IMX under C=US. o The need for a forum for Internet-related issues which are specific to the United States or North America. There are questions about whether ADMD IMX should be viewed as a United States issue or an Internet-wide issue. It can be viewed as an Internet-wide solution which happens to be stuck under C=US due to the X.400 country-centric addressing structure. For example, if C=WW (worldwide) existed, we would prefer to register ADMD IMX under C=WW and it would not be bound to the Unites States. Alternatively, it can be viewed as the Unites States national solution to X.400 naming in the US Internet, which is US-centric and should be developed in a United States forum. The second issue is that the IETF developed in the context of the US. Therefore work on an issue which was Internet-related could be conducted in the IETF, even if the work was US-centric. Now that the IETF has developed its identity as an international organization, Internet-related topics which are United States or North American in scope do not have a valid forum. The problem was recognized by the group, but addressing this problem is outside the scope of the X400OPS Working Group. o Attendee Input: - Erik: IMX work should not be in the IETF; the IESG agrees. They do not want to solve US national issues. There is support in the IAB for the development of a new international group, the IOTF (Internet Operations Task Force). Someone is needed to drive and chair it, and put structure in place. The structure is still open---might have areas and regionals within areas. For example, the X.400 area could have North American and European groups. Area directors would ensure coordination between groups. Someone is needed to work on this and pull it off. Erik plans to talk to Vint on Thursday. Someone is needed with impact in various organizations, who can get commitments from organizations to send people. This person should have visibility and support from funding agencies. Organizations must also participate. The IESG and IAB are behind this idea. Allan and Erik talk to Vint on Thursday? People recognize the need for it. Erik would go for someone high up in operators groups; a US person should lead this. Most likely the IOTF will be established within six months or it will not proceed any time soon. Initially it will probably meet in parallel with IETFs; maybe not later. Erik stated that IMX is not a good solution for the world, even though it might be for the US. - Alf: Should each country write a similar document? - Allan C.: Would C=us; ADMD=IMX be used in other countries? Other people all said no. This implies it is more of a national issue. The forum is unclear; perhaps the budding IOTF would be a forum for this work. - Jeroen: Engineering efforts should not be fragmented. IMX is not operational so IOTF is not the right forum for that work. - Erik: The IMX document should be published as an Informational RFC. It will not get IESG review. The Document should be reviewed by X400OPS participants but will not be progressed as a working group document. Erik predicts future regionalization of the IETF. RARE will become the European committee of ISOC. Some North American group will also be created. There will still be overall ISOC coordination. - John K.: Even if the IETF does not regionalize, the future will be much more coordinated with different groups such as RARE, ISO groups, etc. What Next Erik commented that the ops list should be kept open because of the documents being progressed. He also noted that the RARE Working Group on messaging could be used for some topics. If discussions raise technical issues that merit IETF work, he would welcome a proposal for that group (not just an extension of X400OPS but a focused group for 1/2 year or so to work on a specific issue.) Urs pointed out that there is a specific list for RFC 1465 issues: rfc1465@chx400.switch.ch. Jeroen has copies of tutorial papers, and RARE can send more copies if needed. Allan sees the following as outstanding work items: o A document on the long-range plan for X.400 in the Internet. o Possible work on dynamic X.400 routing using the DNS. X.500 work (mhsds/LONGBUD) is not materializing fast enough. o X.400(88) in the GO-MHS community. o A standard way to address the managers of an X.400 management domain (PRMD or MD). o A document on internal operations of ADMD IMX. o A document on connections between ADMD IMX and ADMDs. It appears that the IMX work will not be approved to be done in the context of the IETF. Steve was also concerned about mhsds delays. It is a very high priority for specifications and for implementation. A global solution is needed for scalable routing, he sees X.500 as the only viable solution. Erik wants focused groups in future. The problem is that groups can have beautiful ideas about what needs to be done, but there must be volunteers to do the work. People are needed to chair the groups, write the documents, and lead discussions. Erik thanked Alf and Tony for chairing the group. The working group will be terminated after this IETF. Attendees Claudio Allocchio Claudio.Allocchio@elettra.trieste.it Harald Alvestrand Harald.T.Alvestrand@uninett.no Vadim Antonov avg@icm1.icp.net C. Allan Cargille allan.cargille@cs.wisc.edu Urs Eppenberger eppenberger@switch.ch Qin Fang qin_fang@unc.edu Tony Genovese genovese@es.net Alf Hansen Alf.Hansen@uninett.no Jeroen Houttuin houttuin@rare.nl Erik Huizer Erik.Huizer@SURFnet.nl Barbara Jennings bjjenni@sandia.gov Marko Kaittola Marko.Kaittola@funet.fi Steve Kille S.Kille@isode.com Jim Knowles jknowles@binky.arc.nasa.gov Jian Li jian@rice.edu Lars-Johan Liman liman@ebone.net Karen Petraska-Veum karen.veum@gsfc.nasa.gov Kenneth Rossen kenr@shl.com Srinivas Sataluri sri@internic.net Richard Schmalgemeier rgs@merit.edu David Staudt dstaudt@nsf.gov Panos Tsigaridas Tsigaridas@fokus.gmd.de Brien Wheeler blw@mitre.org Jackie Wilson Jackie.Wilson@msfc.nasa.gov Russ Wright wright@lbl.gov