File: rfc1803.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (451 lines) | stat: -rw-r--r-- 14,741 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451






Network Working Group                                          R. Wright
Request for Comments: 1803                  Lawrence Berkeley Laboratory
Category: Informational                                      A. Getchell
                                  Lawrence Livermore National Laboratory
                                                                T. Howes
                                                  University of Michigan
                                                             S. Sataluri
                                                  AT&T Bell Laboratories
                                                                  P. Yee
                                               NASA Ames Research Center
                                                                W. Yeong
                                 Performance Systems International, Inc.
                                                               June 1995


       Recommendations for an X.500 Production Directory Service

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This document contains a set of basic recommendations for a country-
   level X.500 DSA.  These recommendations can only be considered a
   starting point in the quest to create a global production quality
   X.500 infrastructure.  For there to be a true "production quality"
   X.500 infrastructure more work must be done, including a transition
   from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500
   standard (including the '93 replication and knowledge model).  This
   document does not discuss this transition.

1.  Introduction

   The ISO/CCITT X.500 Directory standard enables the creation of a
   single world-wide Directory that contains information about various
   types of information, including people. In the United States, in mid
   1989 NYSERNet (the project was later taken over by Performance
   Systems International - PSI) started a White-pages Pilot Project
   (WPP).  Several organizations in the US joined this project.  The PSI
   WPP provided the c=US root level master Directory System Agent (DSA)
   where organizations that joined the pilot were connected.  In
   November 1990, the PARADISE project was started in Europe to provide
   an international directory service across Europe with international
   connectivity to the rest of the world.  The PARADISE project also
   operated the "root of the world" DSA that connected each of the



Wright, et al                Informational                      [Page 1]

RFC 1803           X.500 Production Directory Service          June 1995


   national pilots into a single world-wide Directory Information Tree
   (DIT), enabling information about people all over the world to be
   obtainable using an Internet DUA (Directory User Agent).

   Much of the criticism of X.500 stems from the lack of a production
   quality infrastructure.  Although there are already well over 500
   organizations and 1,000,000 entries in the the X.500 directory, some
   portions of the directory are still considered a "pilot project".
   Poor availability of portions of the directory and inconsistent
   quality of information are two problems that have not been adequately
   addressed in a number of the X.500 "pilot projects".  One of the
   reasons for this has been a lack of formal service objectives for
   running an X.500 service, and recommendations for achieving them.

   In X.500, the country-level DSAs form the access path for the rest of
   the world to access directory entries associated with that country's
   organizations.  Thus, the availability and performance of the
   country-level DSAs give an upper bound to the quality of service of
   the whole country's part of the Directory.

2. Recommendations for the country-level Master DSA

   We will split the recommendations into three categories:  Operational
   recommendations for the organization running the master DSA (service
   provider), DSA recommendations and personnel recommendations.

2a. Operational recommendations for the country-level master and shadow
    DSAs

   In general, the country-level data should be available for querying
   100% of the time.  Availability for updating is also important, but
   may be slightly reduced in practice, given X.500's single master
   scheme.

   *  The master DSA should be available at least 95% of the time.  This
   means that the DSA must be monitored and supported over the weekend.

   * The Master DSA and its shadows should be positioned to minimize the
   possibility of single points of failure.

   * The master and its shadow DSAs should be disbursed across the
   national network infrastructure in order to distribute the load
   across the network, and to get the information closer to the
   requesters.  This distribution should also minimize the possibility
   of a single point of failure, increasing availability.






Wright, et al                Informational                      [Page 2]

RFC 1803           X.500 Production Directory Service          June 1995


   * Country DIT information, including naming infrastructure
   information such as localities and states, should be replicated
   across the oceans - not only to serve when the trans-oceanic links go
   down, but also to handle name resolution operations for clients in
   other countries.  There should be a complete copy of the US root in
   Europe and a copy of the Japanese root in Africa and North America,
   for instance.  Generally, data should be replicated where ever it is
   heavily used, and where it will be needed in the event of a network
   partition.

   *  The master and shadow DSAs must run software that conforms to all
   the recommendations listed in section 4.

2b. Operational recommendations for the service provider

   * Provide a generic e-mail address for the DSA manager (e.g., x500-
   manager@foo.com).  More than one manager should be available to
   handle problems as they come up (i.e., the manager should be able to
   go on vacation!).

   *  E-mail to the manager of the master DSA must be answered in a
   timely fashion:

      * All mail to the manager should be acknowledged as received
      within one working day.

      * Trouble reports concerning the master and shadow DSAs must be
      answered within 24 hours;  this response should include a
      resolution to the problem (when possible).  There are situations
      where problem resolution may take longer than 24 hours, but this
      should be unusual.

      * General informational requests (e.g., how to join the service,
      where to get the software, etc.) should be acknowledged within 2
      working days and should normally be resolved within 2 working
      days.

   *  Maintain a current e-mail distribution list of all DSA managers
   within the country.  Changes to this list must be made in a timely
   manner (within 2 working days).  It may be useful to include X.500
   software vendors and funders on this distribution list.

   *  Provide quick turn around (2 working days) for changes/additions
   to the national master DSA (i.e., requests to add a new organization,
   to change a DSA's information, or to remove a DSA).  Acknowledgments
   to these requests must be made within 1 working day.





Wright, et al                Informational                      [Page 3]

RFC 1803           X.500 Production Directory Service          June 1995


   *  At a minimum, the manager will make available documentation about
   the X.500 Production Service that includes information about how to
   join, which software to run and where to obtain it, naming
   guidelines, schema requirements, operational requirements, etc.
   Ideally, the manager  should take a proactive role in advertising the
   X.500 Production Service and soliciting new members.

   *  If the service is currently operating at a "pilot" level, remove
   references to "pilot" from the service and establish a process with
   the national-level DSA managers to transition from a pilot to a
   production service.  This transition plan must include the production
   of a new set of requirements for their DSAs in the new production
   service (see section 3).

   *  Remove organizations and their DSAs that do not meet the service's
   published operational guidelines (see section 3).  DSA managers
   should be notified at least 4 weeks in advance of removal to give
   them time to correct their operational deficiencies. This procedure
   should be performed at least once every 3 months.  A grace period of
   3 months should be given to new organizations to come up to speed.

   * The service provider should work with other national X.500 service
   providers in the same country to ensure a single consistent DIT
   within the country.  In North America, for example, the Production
   X.500 service should act as an ADDMD in the North American Directory
   Forum (NADF) X.500 service, producing timely Knowledge and Naming
   (KAN) updates for the Central Administration for the NADF (CAN) when
   entries under c=US or c=CA are added, changed or removed, and
   applying KAN updates produced by the CAN in response to updates from
   other ADDMDs.

   This will ensure a single consistent DIT common to both NADF and
   Internet X.500.

2c. Personnel recommendations for the country-level Master DSA

   * Participate in various technical forums, where appropriate.  This
   requirement will become more important as more technical work
   transpires (e.g., for the 93 transition).

   * Provide a help desk that DSA managers can go to for help resolving
   operational problems.  Support should be provided via e-mail and
   optionally via telephone.  This help desk facility is intended to
   provide support above and beyond that provided on the mailing list
   mentioned previously.






Wright, et al                Informational                      [Page 4]

RFC 1803           X.500 Production Directory Service          June 1995


   * Publish quarterly status reports giving details on the state of the
   service: new organizations, deleted organizations, statistics on the
   availability of the master and shadow DSAs, number of operations
   performed by the master and shadow DSAs, etc.

   * Provide electronic access to service information.  Some useful ways
   of doing this are:

      Provide a World Wide Web (WWW) page that includes information
      describing the service, together with contact information,
      pointers to useful software, a form that can be used to submit
      comments/bug reports, and any other useful information that can be
      provided.

      Provide FTP access to above information.

3. Recommendations for operating a DSA within the National Directory
   Management Domain (DMD)

   The following are recommendations for all DSAs that are operating
   within the country-level DMD.

      * The availability of the organization's subtree should be as
      close to 100% as possible.  This coverage shall be provided by a
      master DSA and zero or more shadow DSAs.

      * Organizations should maintain information in their DSAs that is
      complete, accurate, and up-to-date.  This information shall be
      accessible through Directory protocols to the extent allowable by
      the security and privacy policies of the respective organizations.

      * Organizations experimenting with the Directory should either be
      marked clearly as "experimental" (e.g., with an appropriate
      Quality of Service attribute, or perhaps by including the word
      "experimental" as part of the organization's RDN), or they should
      be listed in a separate portion of the namespace, also clearly
      marked.  Once the organization is done experimenting, it can be
      move to the "production" part of the DIT.

      * Two contact persons must be named as DSA managers for each DSA

      * DSA software should conform to the recommendations found in
      section 4.








Wright, et al                Informational                      [Page 5]

RFC 1803           X.500 Production Directory Service          June 1995


4. Recommendations for DSA software

   The software should support the attributes and object classes found
   in the Internet schema [RFC 1274].

   Software should be reliable, supportable and should provide
   sufficient performance to handle the DSA traffic.

   Additional requirements may be imposed by the service provider (e.g.,
   '93 replication).

5. References

   [CCITT-88]  CCITT, "Data Communications Networks Directory",
               Recommendations X.500-X.521, Volume VIII - Fascicle
               VIII.8, IXth Plenary Assembly, Melbourne, November
               1988.

   [RFC 1274]  Barker, P., and S. Kille, "The COSINE and Internet
               X.500 Schema", RFC 1274, University College, London,
               England, November 1991.

6. Security Considerations

   Security issues are not discussed in this memo.


























Wright, et al                Informational                      [Page 6]

RFC 1803           X.500 Production Directory Service          June 1995


7.  Editors' Addresses

   Russ Wright
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   Mail-Stop 50B-2258
   Berkeley, CA 94720

   Phone: (510) 486-6965
   EMail: wright@LBL.Gov
   X.400: s=wright;p=esnet;o=LBL; a= ;c=us;


   Arlene F. Getchell
   Lawrence Livermore National Laboratory
   National Energy Research Supercomputer Center
   P.O. Box 5509, L-561
   Livermore, CA 94551

   Phone: (510) 423-6349
   EMail: getchell@es.net
   X.400: s=getchell;p=esnet;a= ;c=us;


   Tim Howes
   University of Michigan
   ITD Research Systems
   535 W William St.
   Ann Arbor, MI 48103-4943, USA

   Phone: (313) 747-4454
   EMail: tim@umich.edu


   Srinivas R. Sataluri
   AT&T Bell Laboratories
   Room 1C-429, 101 Crawfords Corner Road
   P.O. Box 3030
   Holmdel, NJ 07733-3030

   Phone: (908) 949-7782
   EMail: sri@qsun.att.com









Wright, et al                Informational                      [Page 7]

RFC 1803           X.500 Production Directory Service          June 1995


   Peter Yee
   Ames Research Center
   MS 233-18
   Moffett Field CA 94035-1000

   EMail: yee@atlas.arc.nasa.gov


   Wengyik Yeong
   Performance Systems International, Inc.
   510, Huntmar Park Drive,
   Herndon, VA 22070

   EMail: yeongw@psi.com





































Wright, et al                Informational                      [Page 8]