CURRENT_MEETING_REPORT_ Reported by Allan Cargille/University of Wisconsin Minutes of MHS-DS Working Group (MHSDS) Document Changes Kevin Jordan summarized three major changes that have been made in the documents: 1. Use of directory to support mapping---especially missing address components. For example, in Germany often the Organization attribute is not used but OUs are used. There is a major change in where the mapping rules will be stored. Now all rules will be stored under O=Internet, OU=X.400/RFC822 Mapping. CN=X.400 to RFC822 or CN=RFC822 to X.400. The X.400 tree has C, ADMD, etc. The RFC822 tree has top-level domain, 2nd domain, etc. This keeps all the information under one subtree and makes it possible to easily replicate the whole subtree. Experts do not expect the mapping rules to grow much larger than the present size. This also makes it much easier to copy entire mapping rules into a directory from tables. Replication is standard in the X.500 1992/93 specification, and can support replicating entire subtrees. 2. Bilateral versus multi-lateral agreements. BilateralTable attribute is a sequence now. Small editorial note: Need to change the OID value in the document to a new one; the old OID was used even though the definition was changed. This feature can now support multi-party agreements or truly private agreements. 3. Change to default routing failure action at country level (now it is the same as for any other level). Minimum profile was discussed. Is this valuable? It contains errors. Is this document necessary? The minimum is so small that it will hurt things because not enough functionality is demanded of implementations. Another example of where a weak profile was the minimum profile was for RFC 987 in the COSINE MHS Community---it discouraged deployment of fully functional gateways. It was discussed whether or not to progress the current document. However, a minimum profile should be a useful document, it should just contain enough functionality as to be truly useful. It was decided that implementors will discuss and agree on a minimum profile (Kevin Jordan and other implementors). Terminology in minimum profile was also discussed. The issue of the terminology used in the document was raised: ``may,'' ``should,'' and ``shall'' in regard to exactly what is mandatory, suggested, and optional. This could be specified in the routing document, but it is simpler to keep it in a separate document because the routing document is so complex. Someone commented that if we do not clean up the current language, the RFC Editor will insist on it when the document is progressed anyway. Review of Long Bud Status The authors have made some changes. Sylvain will produce a new draft by the end of April. The document will be progressed if agreement is reached on the mailing list. Some tools are available via anonymous FTP from ftp.css.cdc.com in pub/mhs-ds/long-bud/software: o listOT - list Open Tree. Written in DuaPerl o pingMTAs - finds MTAs and tests connections to them. The current version uses CDC products in the tool. Kevin will try to make the necessary components publicly available. Perhaps PP has the necessary functionality already available. Same kinds of tools available. Written in DuaPerl. o upload-2.0 - accepts routing/mapping tables in RFC 1465 format, creates corresponding information in the Open Tree. Needs to be updated for new version of the specifications. Written in C and awk. o getRouting - opposite of upload above, downloads tables from directory. Written in C. It was suggested that it would be nice if someone could rewrite these tools in DuaPerl. Volunteers were requested. Is it a problem that domains with no MTA are listed? Should they be deleted? The conclusion was that this seems okay. Another problem is that some MTAs are listed but they do not accept connections from any other MTA. In the US, MTAs are listed that do not exist. This needs to be cleaned up. Someone should talk to them and get them to upgrade the service. Perhaps some sites like Merit and MITRE will participate again? This is an action item for the Wisconsin project. MTAs which do not exist any more should be deleted from the open tree. o US/ATTMAIL/CDC, ESNET - are mastered at CDC o US/TELEMAIL/arc (NASA) - is mastered at NASA Can all sites see the same thing? Yes, this is just a list of information from the directory. The pingMTAs tool may see different results based on connection permissions, or they can also be affected by timeouts, chains, referrals, etc. PingMTAs try to connect to all listed MTAs. Some problems in using this were found: o Registered, but non-existent MTAs (remove) o Registered, but unmanaged MTAs - mostly US (remove) o Registered, but mostly unreachable domains (add routing information) o Missing authentication requirements (add them where truly needed) Default routes need to be registered to make all existing domains in the GO-MHS community routable via the X.500 Directory. Base initial routes upon RARE tables where necessary; use authentication requirements where needed. An open tree has been assumed where MTAs will accept connections from any calling MTA. Is this a valid model? Each MD must list an MTA which will be openly accessible from any calling MTA. This approach is simpler. An alternate approach would be to reflect the current GO-MHS community in the directory with multilateral agreements. Each ADMD, PRMD, O, OU lists an MTA. Why would people operate ``closed'' MTAs? Urs reported that SWITCH blocks out unknown MTAs because incoming connections can ship you anything they want, and routing this mail can cost them money (over expensive links, or to costly commercial destinations). The group strongly reaffirmed that open tree MTAs should be willing to accept connections from anyone. It is also noted that it is technically possible to establish a closed community with MTA information at one location in the tree in the current draft of the routing specification, but this approach will not be taken in the Long Bud pilot. What mandatory stacks that should be supported for each domain? This was not specified in the current draft. Possible stacks are RFC 1006, CLNS, X.25. The decision was that initially RFC 1006 is the mandatory stack, and other stacks may optionally be used. This should be added to the Long Bud draft. Discussion - DSA Problems o Existing infrastructure is too unreliable for routing. o Need to establish more replication. o Need to establish more explicit backup DSAs. There is a problem with top-level servers, especially the US server. It is unavailable often, perhaps due to crashing. There is a need for a more reliable US top-level X.500 server. In light of this problem, Kevin proposed the following replication strategy: o To start: Pick two DSAs in the US and two in Europe: CDC? InterNIC? NASA? France (Sylvain), SWITCH, or ULCC (Linda). (ULCC runs a worldwide root server.) - Each DSA has complete replica of top levels. - Each MHS-DS entry must have at least one backup DSA attribute. - backupDSA attribute should reference DSA on other side of ocean. - Each core DSA will accept request for bilateral replication agreements from any DSA manager that asks. o To expand: Establish a more methodical, more scalable approach. This is an unsolved problem. Peter Kirstein asked if anyone has investigated what the problems are with the DSA reliability? Is this published? The answer is yes, once per week to the DSA national managers and the OSIDS mailing list. Probes are only from NeXor, which may make the data suspect because there may be problems with transatlantic lines or timeouts. It would also be good for someone to do probes in the US---can CDC do these? Or another site? Peter stated that a test can be done from anywhere in the US, but it needs to be a national master. There are three root-level DSAs in the US, but availability is not good. Linda stated that ULCC does measurements of DSA reliability and that there is a problem with the US master DSA. European DSAs are more reliable. Attendees Claudio Allocchio Claudio.Allocchio@elettra.trieste.it C. Allan Cargille allan.cargille@cs.wisc.edu Rong Chang rong@watson.ibm.com Charles Combs 0003647213@mcimail.com Urs Eppenberger eppenberger@switch.ch Tony Genovese genovese@es.net Kevin Jordan Kevin.E.Jordan@cdc.com Marko Kaittola Marko.Kaittola@dante.org.uk Peter Kirstein P.Kirstein@cs.ucl.ac.uk Sylvain Langlois Sylvain.Langlois@der.edf.fr Linda Millington l.millington@noc.ulcc.ac.uk Francois Robitaille francois.robitaille@crim.ca Jim Romaguera romaguera@netconsult.ch Einar Stefferud stef@nma.com Peter Sylvester peter.sylvester@inria.fr