CURRENT_MEETING_REPORT_ Reported by C. Allan Cargille/University of Wisconsin Minutes of MHS-DS Working Group (MHSDS) Document Review After editorial corrections, the following three documents will be ready to move forward: o ``Representing Tables and Subtrees in the Directory'' (draft-ietf-mhsds-subtrees-05) o ``Use of the Directory to support mapping between X.400 and RFC 822 Addresses'' (draft-ietf-mhsds-supmapping-05) o ``Representing the O/R Address hierarchy in the Directory'' (draft-ietf-mhsds-infotree-05) Steve will make the minor changes and submit them for recommendation as Proposed Standards by 2 September. ``MHS use of Directory to support MHS Routing'' Steve reviewed the major changes to the routing document (draft-ietf-mhsds-routdirectory-05): o Editorial changes were made. o The document was upgraded to use 1993 ASN.1. o The language of the specification was changed to ``may'' for things that are optional, and ``shall'' for things that are mandatory. o It was clarified that searching is allowed at local levels. Steve had intended to add pseudocode to the document, but it has not been done yet. There was a discussion about whether it should be included or dropped, so that the document could be forwarded. It was noted that the pseudocode could be split out into a separate document or added when the document is progressed. It was noted that it must be clear whether the textual specification or the pseudocode is authoritative in the event that they are not consistent. Not having pseudocode will not hold up the document at this level, but this might be an issue when the specification goes to full Standard. John Klensin encouraged the group not to let this issue hold up the document. It was decided to delete the pseudocode appendix and consider this for future work. John Klensin encouraged the group to get the documents out quickly, and noted that they can be revised in the future as they progress on the standards track. Allan will get final comments on the document to Steve as soon as possible. If time allows, Steve will send a revised copy to the design team (working group chairs, John Klensin and Allan Cargille) before 2 September. Either way, the document will be forwarded as a Proposed Standard by that time. ``Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing'' Allan Cargille had significant editorial comments on the document (draft-ietf-mhsds-long-bud-intro-02) and felt that it was not ready to go forward in the present form. It was decided that Sylvain will work with Allan to incorporate relevant comments, and then he will submit it as an Informational RFC by 2 September (recommending no Last Call from the IESG). Additional Documents There are two other documents which may need to be discussed: a ``minimum profile'' document (identifying which parts of the routing document must be implemented for a ``conformant'' implementation), and an ``overview'' document (explaining the general intent and architecture of the routing document). The status of the minimum profile document is not clear. It has either been dropped, or it is on hold pending work by Kevin Jordan and Julian Onions, who have implemented it. Allan Cargille still plans to write an overview document, given time and energy. If anyone else wants to work on this, they should let Allan know. Allan hopes to write something by September. Update on Current Pilot Kevin Jordan presented the following information: o DSA CN=Long Bud, C=us contains information on - C=us, ADMD=attmail - C=us, ADMD=telemail - C=us, ADMD= o DSA CN=Ornate Hawk Eagle, C=gb contains information on - c=gb, ADMD= These ``core'' DSAs have full replication of US, GB, and BE information at the ADMD and PRMD levels, to increase reliability. They are using slaveDSA attributes for backup. Germany has also expressed interest in participating in replication. Core DSAs will also be brought up by the InterNIC (US) and Sylvain (France). Reliability issues in the project are improving, due to the use of the core DSAs. People need to start verifying/policing MTA information in the tree---we need correct, complete information for proper routing. All information also needs to be robust. Kevin has a tool which he will run regularly and publish the results on the MHSDS list. An important issue is that some MTAs are not accepting connections from other open tree MTAs. It is unknown if anyone is taking responsibility for uploading GOMHS information into the tree. There was a call for tender for this tool in the UK, but it is unclear if it will be funded. The group discussed which GOMHS MTAs will relay between the GOMHS community and open tree MTAs. John Klensin invited the group to consider whether there is a business case for commercial ADMDs to participate in this experiment. ADMDs are financially driven---what would they gain? Is there a long-term benefit for ADMDs to participate? They can register in the open tree, and list information needed for customers or other ADMDs to connect or purchase services. Services can be restricted based on routing policies. The argument for ADMDs to participate in the open tree is that customers receive more mail, and therefore send more mail (generating more chargeable traffic). It was also noted that they are already receiving this traffic from the Internet community, it is just traveling via SMTP rather than X.400, so this is not a policy change, just a protocol change. The group discussed how this project should be publicized to PRMD operators and get them to participate. It was suggested to start with the GOMHS community for PRMD participants. Kevin will annotate a report and identify incomplete or incorrect data in various countries. He said he can modify a tool to identify the responsible managers. Future Work Three documents have been shelved: o ``MHS use of the Directory to support distribution lists'' (draft-ietf-mhsds-mhsuse) o ``MHS use of Directory to support MHS Content Conversion'' (draft-ietf-mhsds-convert) o ``Use of the Directory to support routing for RFC 822 and related protocols'' (draft-ietf-mhsds-822dir) There are three possible new documents: minimum profile, overview, and pseudocode specification The distribution list document is important from a commercial perspective---some RFPs want this. It could improve X.400 support for lists. The document adds to X.402. Perhaps that means it should be handled in an ISO process, not the IETF. The IETF tends to work on things related to internet operations, not part of core X.400/X.500 functionality. John indicated that the group would need to give extremely powerful arguments to get approval for such work in the IETF community. Is there an alternate home for this work? Steve felt distribution lists and content conversion are critical to work on and he has to work on them. He would prefer to do the work in the IETF, but otherwise will do it elsewhere. He felt the 822 is elegant and would round out the other standards, but is not critical. It was noted that the 822 document would take a lot of work to update and is not popular in the IETF. However, it would also add functionality. The document would need to be updated to incorporate MIME. John indicated that there is pressure to shut this working group down. He prefers tightly focused proposals directly related to X.400/X.500 on the Internet. Perhaps another group should be created to work on this? John and Steve will take this off-line. Summary and Close All documents to be forwarded should be published by 2 September. The chairs will send them to the area director to forward.