rfc1802.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   availability and global Directory data accuracy are not in the scope
   of Long Bud, care must be taken that Directory resources used by Long
   Bud participants are administrated well.

   If they have the technical ability to do so, Long Bud participants
   are encouraged to replicate routing information in their Directory to
   improve data availability.

   Directory data used by the pilot must be accurate:  solutions to this
   problem will be recommanded as the project matures.

5. Participation Guide

   The existing operational X.400 service, the GO-MHS service, uses the
   following method to distribute and manage X.400 routing information:
   A group of MTAs is organized into a routing community.  The community
   keeps its routing information up to date by assigning to each MTA
   manager the responsibility of determining the routing information for
   his/her MTA, formalizing this routing information in the syntax
   defined by the community and sending the result to the GO-MHS
   coordination service.  Once the information has been validated
   against the other data provided by all managers in the community, the
   coordination service will advertise it to the whole community.  Each
   manager will then have to update his/her MTA configuration with the



Alvestrand, et al            Informational                      [Page 6]

RFC 1802              Introducing Project Long Bud             June 1995


   verified information.

   The purpose of Project Long Bud is to allow a manager to operate an
   MTA without having to perform ANY manual steps when another MTA
   manager adds new or changes existing routing information.  This will
   facilitate efficient, dynamic, and manageable interconnection of very
   large communities of MTAs.  It will allow the Internet X.400
   community to overcome the limitations in scalability which it is
   currently encountering.

5.1 Prerequisites for participation

   The prerequisites for joining Project Long Bud are:

   Step 1:  Participants in the pilot must have a good knowledge of
            the IETF MHS-DS Working Group activities and documents:

          1. Participants must join the MHS-DS distribution list:

                   RFC-822:  [e-mail]

                     X.400:  PN=mhs-ds; OU=mercury; OU=OSS;
                             OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US

             Requests to join the MHS-DS distribution list may be sent
             to the following email address:

                  RFC-822:  [e-mail]

                    X.400:  PN=mhs-ds-request; OU=mercury; OU=OSS;
                            OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US


          2. Participants must retrieve and become familiar with all
             relevant tools and documents stored on the Project Long
             Bud anonymous FTP server

                           Host name:  ftp.css.cdc.com

                           Directory:  pub/mhs-ds/long-bud

             In particular, openly available software related to Long
             Bud activities will be kept up-to-date at this location.








Alvestrand, et al            Informational                      [Page 7]

RFC 1802              Introducing Project Long Bud             June 1995


          3. If not already done, participants must do one of the
             following:

               * Upgrade their X.400 and X.500 software such that it
                 supports the MHS-DS specifications as in [Kille 94].

               * Use the tools which extract MHS-DS information from
                 the directory and generate whatever local
                 configuration files are necessary to allow local MTA's
                 to use the information.  This should be done
                 frequently (at least once per day).

   Step 2:  Participants must register required entries in the
            Directory so that their MTA(s) is (are) known to the
            Directory.

          1. Arrange with the appropriate DSA Manager (who can be a
             local manager if the DSA is run by the participating
             organization, or a manager who is in charge of running the
             organization's DSA) to create an entry for the local
             MTA(s) involved in the pilot.  At this stage, only
             connection information is required.

          2. Check, test and verify the connection information with at
             least one other participant.  The mhs-ds distribution list
             should be used for announcing the new registration and
             asking volunteers for testing.

          3. Participants must establish sensible default X.400 routes
             to existing GO-MHS destinations for which X.500-based
             routing information will not exist initially.

   Step 3:  Participants can then enter their routing information in
            the Directory.

          1. Before any routing is entered in the DIT, participants
             must check with the GO-MHS Coordination Service that the
             routes they want to register can be properly handled by
             the GO-MHS community (contact information is
             [e-mail]).  It is crucial for the Pilot
             that any routing information entered in the Directory is
             kept carefully accurate if the experiment is to be
             meaningful.  Participants may also consider the need for
             mapping rules (see [RFC 1465] for details).

          2. Once the above step is validated by the GO-MHS
             Coordination Service, participants must record routing
             information for their MTA(s) in the Internet X.500



Alvestrand, et al            Informational                      [Page 8]

RFC 1802              Introducing Project Long Bud             June 1995


             directory service.  This requires that a participant does
             the following:

               * Arrange with the appropriate DSA Manager (who can be
                 either a local manager if the DSA is run by the
                 participating organization or a manager which is in
                 charge of running the organization's DSA) to enter
                 X.400 routing information in a routing tree held by
                 the participating organization.  This routing tree
                 should contain all necessary information for the local
                 mail domain.

               * Check, test and verify the registered routing
                 information with at least one other participant.  The
                 mhs-ds distribution list should be used for announcing
                 the new registration and asking volunteers for
                 testing.

          3. If a participant adds new nonleaf entries to the Open
             Community Routing Tree, then s/he must find at least one
             other participant who will maintain a slave copy of the
             children of the nonleaf entry.  Send email to the mhs-ds
             distribution list in order to find a partner who is
             willing to do this.

          4. If a participant adds new nonleaf ADMD or PRMD entries to
             the directory, then s/he must contact the managers of the
             Long Bud core DSA's and arrange to provide slave copies of
             the children of the ADMD and/or PRMD entries to all of the
             core DSA's.  Send email to the mhs-ds distribution list in
             order to contact the core DSA managers.

          5. Once the above testing is completed, send email to the
             mhs-ds distribution list announcing the establishment of
             new X.500-based routes.

6. Notes on side effects

   The Long Bud Pilot Project, with its specific scope, is investigating
   a new direction in X.500 service usage.  This should facilitate and
   expedite the global deployment of X.500 on the Internet.

   Once the routing infrastructure illustrated by the Long Bud
   experiment is in place, the routing process will be able to take into
   account additional information to improve quality of service
   (minimizing messages conversions, enforcing various security policies
   established by MHS domains, taking advantage of recipients's
   capabilities stored in the Directory, ...).  While the Open Tree



Alvestrand, et al            Informational                      [Page 9]

RFC 1802              Introducing Project Long Bud             June 1995


   provides global connectivity, multiple private routing trees allow
   the use of various routing trees.

7. Acknowledgements

   The authors would like to thank Urs Eppenberger (SWITCH) and Allan
   Cargille (University of Wisconsin) for their constructive comments on
   earlier drafts of this document.

References

   [CCITT 88]          International Telegraph and Telephone
                       Consultative Committee. X.500 Recommendations
                       series. December 1988.

   [RFC 1649]          Hagens, R., and A. Hansen, "Operational
                       Requirements for X.400 Management Domains in the
                       GO-MHS Community", RFC 1649, ANS, UNINETT,
                       July 1994.

   [Kille 94]          Kille, S., "MHS Use of the X.500 Directory to
                       Support MHS Routing", RFC 1801, ISODE Consortium,
                       June 1995.

   [RFC 1006]          Rose, M., and D. Cass, "ISO Transport Service on
                       top of the TCP Version: 3", STD 35, RFC 1006,
                       Northrop Research and Technology Center,
                       May 1987.

   [RFC 1275]          Hardcastle-Kille, S., "Replication Requirements
                       to provide an Internet Directory using X.500",
                       RFC 1275, University College London,
                       November 1991.

   [RFC 1465]          Eppenberger, U., "Routing Coordination for X.400
                       MHS Services Within a Multi Protocol / Multi
                       Network Environment Table Format V3 for Static
                       Routing", RFC 1465, SWITCH, May 1993.

   [RFC 1487]          Yeong, W., Howes, T., and S. Kille, "X.500
                       Lightweight Directory Access Protocol",
                       RFC 1487, Performance Systems International,
                       University of Michigan, ISODE Consortium,
                       July 1993.







Alvestrand, et al            Informational                     [Page 10]

RFC 1802              Introducing Project Long Bud             June 1995


8. Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Harald T. Alvestrand
   UNINETT
   P.O. box 6883 Elgeseter
   N-7002 Trondheim, Norway

   Phone:  [phone]
   EMail:  [e-mail]


   Kevin E. Jordan
   Control Data Systems, Inc.
   4201 Lexington Avenue North
   Arden Hills, MN 55126, USA

   Phone:  [phone]
   EMail:  [e-mail]


   Sylvain Langlois
   Electricite de France
   Direction des Etudes et Recherches
   1, avenue du General de Gaulle
   92141 Clamart Cedex, France

   Phone:  [phone]
   EMail:  [e-mail]


   James A. Romaguera
   NetConsult AG
   Morgenstrasse 129 3018 Bern, Switzerland

   Phone:  [phone]
   EMail:  [e-mail]
   X.400:  S=Romaguera;O=NetConsult;P=switch;A=arcom;C=ch










Alvestrand, et al            Informational                     [Page 11]