rfc1330.txt

RFC 的详细文档！

2.4.3.  Naming Structure Below the o=<site> Level

   The structure of the subtree below the organization's node in the DIT
   is a matter for the local organization to decide.  A site's DSA



ESCC X.500/X.400 Task Force                                    [Page 10]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   manager will probably want to enlist input from others within the
   organization before deciding how to structure the local DIT.

   Some organizations currently participating in the Pilot have
   established a simple structure, choosing to limit the number of
   organizational units and levels of hierarchy.  Often this is done in
   order to optimize search performance.  This approach has the added
   benefit of insulating the local DIT from administrative restructuring
   within the organization.  Others have chosen to closely model their
   organization's departmental structure.  Often this approach seems
   more natural and can enhance the information obtained from browsing
   the Directory.

   Below are experiences from current DSA managers, describing the way
   they structured their local DIT and the reasons for doing so.  A site
   may find this information helpful in determining how to structure
   their local DIT.  Ultimately this decision will depend upon the needs
   of the local organization and expectations of Directory usage.

   Valdis Kletnieks of the Virginia Polytechnic Institute:

      "For Virginia Tech, it turned out to be a reasonably
      straightforward process.  Basically, the University is
      organized on a College/Department basis.  We decided to model
      that "real" structure in the DIT for two major reasons:

      "(a) It duplicates the way we do business, so interfacing the
      X.500 directory with the "real world" is easier.

      "(b) With 600+ departmental units and 11,000+ people (to be
      30,000+ once we add students), a "zero" (everybody at top) or
      "one" deep (600 departments at top) arrangement just didn't
      hack it - it was deemed necessary that you be able to do a
      some 120 or 140 county office entries under the Extension
      service, it's a BIT unwieldy there).  However, with some 20
      college-level entries at the top, and the "average" college
      having 30 departments, and the "average" department being from
      10 to 40 people, it works out pretty well."

   Jeff Tannehill of Duke University:

      "Our DIT is flat.  We get the entire database of people at Duke
      from Tel-Com and just put everyone directly under "O=Duke
      University".

      "Actually, there is an exception, when the DSA was first set up
      and we had not received a database yet, I configured the DIT to
      include "OU=Computer Science", under which myself and one other



ESCC X.500/X.400 Task Force                                    [Page 11]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


      System Administrator have entries.  Upon getting the database
      for everyone else I decided not to attempt to separate the
      people in the database into multiple ou's."

   Joe Carlson of Lawrence Livermore National Laboratory:

      "We tried both flat (actually all under the same OU) and
      splitting based on internal department name and ended up with
      flat.  Our primary reason was load and search times, which were
      2-3 times faster for flat organization."

   Paul Mauvais of Portland State University:

      "We originally set up our DIT by simply loading our campus
      phone book into one level down from the top (e.g. OU=Faculty
      and Staff, OU=Students, OU=Computing Services).

      "I'd love to have an easy way to convert our flat faculty and
      staff area into departments and colleges, but the time to
      convert the data into the separate OU's is probably more than I
      have right now."

   Mohamed Ellozy of Dana-Farber Cancer Institute:

      "Here we have a phone database that includes department, so we
      got the ou's with no effort.  We thus never went the flat space
      way."

   Dan Moline of TRW:

      "Well - we're still in the process of defining our DIT.  TRW
      comes under the international companies DBA.  Our part under
      the PSI White Pages Pilot defines the DIT for our space and
      defense organization here in Redondo Beach (however, I
      organized the structure to adhere to TRW corporate).  We input
      from our manpower DB for our S&D personnel.  We're trying to
      get corporate's DB for possible input.

      "However, arranging your DIT by organizations (at least for
      corps) presents a problem; things are always being reorganized!
      We were DSO now we're SSO!!!  We still have some of our old
      domain name for DNS tied to organizations that have not existed
      for years!

      "So we are currently redesigning our DIT to try to fit NADF 175
      (something more geographically).  Our reasoning was that
      organizations may change but buildings and localities do not."




ESCC X.500/X.400 Task Force                                    [Page 12]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Ruth Lang of SRI:

      "There has been no SRI-wide policy or decision to participate
      in the PSI White Pages Pilot.  @c=US@O=SRI International
      supports the information for one OU only (i.e., a local policy
      and decision).  In order to not give the false impression that
      all SRI information was contained under this O=SRI
      International, I used OU=Network Information Systems Center.
      If I were to structure the DIT for all of SRI, I'm sure that my
      thinking would yield a much different structure."

   Russ Wright of Lawrence Berkeley Laboratory:

      "Since we don't have much organizational information in current
      staff database, I have to stick to a fairly flat structure.  I
      have two OUs.  One is for permanent staff, the other is for
      guests (there is a flag in our database that is set for
      guests).

      "I may add an additional level of OUs to our current structure.
      The top level would contain different 'types' of information.
      For example, one OU may be 'Personnel', another may be called
      publications).  Staff and Guests would reside under the
      Personnel OU."

   Peter Yee of NASA Ames:

      "I broke up my DIT at the NASA Center level.  NASA is made of
      nearly 20 Centers and Facilities.  The decision to break up at
      this level was driven by several factors:

      "1.  Control of the local portion of the DIT should reside with
      the Center in question, particularly since the Center probably
      supplies the data in question and controls the matching DSA.

      "2.  Each Center ranges in size from 1,000 to 16,000 persons.
      This seems to be the range that works well on moderate sized
      UNIX servers.  Smaller would be a waste, larger would require
      too much memory.

      "3.  Representatives from several Centers have contacted me
      asking if they could run their own DSAs so that they can
      experiment with X.500.  Thus the relevant DSA needs to be under
      their control."

2.5.  Information Stored in X.500

   The Phase I deployment of X.500 should be limited to "white pages"-



ESCC X.500/X.400 Task Force                                    [Page 13]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   type information about people.  Other types of objects can be added
   in later Phases, or added dynamically as the need arises.

   To make X.500 truly useful to the ESnet community as a White Pages
   service, it is recommended that the following minimum information
   should be stored in the X.500 database:

   Information   ASN.1 Attribute Type      Example
   -----------   --------------------      -------
   Locator Info  commonName                Allen Sturtevant
                 surname                   Sturtevant
                 postalAddress             LLNL
                                           P.O. Box 5509, L-561
                                           Livermore, CA 94551
                 telephoneNumber           [phone]
                 facsimileTelephoneNumber  [phone]

   E-Mail Info   rfc822Mailbox             [e-mail]
                 mhsORAddresses            /PN=Allen Sturtevant/O=NERSC/
                                             /PRMD=ESnet/ADMD= /C=US/
                 otherMailbox              DECnet:  ESNIC::APS

   The above list of attributes comprises a minimum set which is
   recommended for a person's entry.  However, you may chose to omit
   some attributes for reasons of privacy or legality.  Note that the
   X.500 standard requires that the surname and commonName attributes be
   present.  If an individual's phone number and/or address cannot be
   provided, they should be replaced by the site's "Information Phone
   Number" and postal address to allow some means of contacting the
   person.

2.5.1.  Information Security

   It is understood that placing this type of information in X.500 is
   equivalent to putting the "Company Phone Book" on-line in the
   Internet.  Different sites may treat this information differently.
   Some may view it as confidential, while others may view this data as
   open to the public.  In any case, it was recommended that ESnet sites
   discuss the implications with their respective legal departments
   before actually making their information openly available. There
   currently exists minimal access control in several X.500
   implementations.

2.6.  Accessing the X.500 Directory Service

   The PSI White Pages Pilot Project software provides numerous
   interfaces to the information in the X.500 Directory.  Non-
   interactive access mechanisms (e.g. WHOIS, FINGER and Electronic



ESCC X.500/X.400 Task Force                                    [Page 14]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Mail) make use of capabilities or services which already reside on
   many workstations and hosts.  Such hosts could immediately take
   advantage of the X.500 service with no additional software or
   reconfiguration needed.  However, since these methods are non-
   interactive, they only provide a way to search for and read
   information in the Directory but no way to modify information.

2.6.1.  Directory Service via WHOIS

   The Pilot Project software allows you to configure the X.500
   Directory service to be made available via a network port offering an
   emulation of the SRI-NIC WHOIS service.  UNIX-based hosts and VMS
   hosts running Multinet typically come configured with the WHOIS
   service.  Users at their workstations would then be able to issue a
   simple WHOIS command to a known host running a DSA to retrieve
   information about colleagues at their site or at other ESnet sites.
   For example, the command:

      whois -h wp.lbl.gov wright

   will return information about Russ Wright at Lawrence Berkeley Lab.
   It is recommended that all sites which bring up such a service,
   should provide an alias name for the host running their DSA of the
   form <wp.site.domain> for consistency within the ESnet community.

2.6.2.  Directory Service via Electronic Mail

   The Pilot Project software also allows the X.500 Directory service to
   be made available via electronic mail.  A user who sends an
   electronic mail message to a known host running a DSA containing a
   WHOIS-like command on the subject line, would then receive a return
   mail message containing the results of their query.

2.6.3.  Directory Service via FINGER

   The X.500 Directory service could also be made available via the
   FINGER service.  Although this access method does not come with the
   PSI Pilot Project software, several sites have already implemented a
   FINGER interface to the X.500 Directory.  For ease of use and
   consistency, a single FINGER interface should be selected, then
   individual implementations within the ESnet community should conform