git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-relax.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                   Kurt D. Zeilenga
   8 Intended Category: Experimental                  Isode Limited
   9 Expires in six months                            14 February 2007
  10
  11
  12
  13                        The LDAP Relax Rules Control
  14                     <draft-zeilenga-ldap-relax-01.txt>
  15
  16
  17 Status of this Memo
  18
  19   This document is intended to be, after appropriate review and
  20   revision, submitted to the RFC Editor for publication as an
  21   Experimental document.   Distribution of this memo is unlimited.
  22   Technical discussion of this document will take place on the IETF LDAP
  23   Extensions mailing list <ldapext@ietf.org>.  Please send editorial
  24   comments directly to the author <Kurt.Zeilenga@Isode.COM>.
  25
  26   This document replaces draft-zeilenga-ldap-managedit-xx.txt.
  27
  28   By submitting this Internet-Draft, each author represents that any
  29   applicable patent or other IPR claims of which he or she is aware have
  30   been or will be disclosed, and any of which he or she becomes aware
  31   will be disclosed, in accordance with Section 6 of BCP 79.
  32
  33   Internet-Drafts are working documents of the Internet Engineering Task
  34   Force (IETF), its areas, and its working groups. Note that other
  35   groups may also distribute working documents as Internet-Drafts.
  36
  37   Internet-Drafts are draft documents valid for a maximum of six months
  38   and may be updated, replaced, or obsoleted by other documents at any
  39   time. It is inappropriate to use Internet-Drafts as reference material
  40   or to cite them other than as "work in progress."
  41
  42   The list of current Internet-Drafts can be accessed at
  43   http://www.ietf.org/1id-abstracts.html.
  44
  45   The list of Internet-Draft Shadow Directories can be accessed at
  46   http://www.ietf.org/shadow.html.
  47
  48
  49   Copyright (C) The IETF Trust (2007).  All Rights Reserved.
  50
  51   Please see the Full Copyright section near the end of this document
  52   for more information.
  53
  54
  55
  56
  57
  58 Zeilenga                LDAP Relax Rules Control                [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
  61
  62
  63 Abstract
  64
  65   This document defines the Lightweight Directory Access Protocol (LDAP)
  66   Relax Rules Control which allows a directory user agent (a client) to
  67   request the directory service temporarily relax enforcement of various
  68   data and service model rules.
  69
  70
  71 1.  Background and Intended Use
  72
  73   Directory servers accessible via Lightweight Directory Access Protocol
  74   (LDAP) [RFC4510] are expected to act in accordance with the X.500
  75   [X.500] series of ITU-T Recommendations.  In particular, servers are
  76   expected to ensure the X.500 data and service models are not violated.
  77
  78   An LDAP server is expected to prevent modification of the structural
  79   object class of an object [RFC4512].  That is, the X.500 models do not
  80   allow a 'person' object to be transformed into an
  81   'organizationalPerson' object through modification of the object.
  82   Instead, the 'person' object must be deleted and then a new
  83   'organizationalPerson' object created in its place.  This approach,
  84   aside from being inconvient, is problematic for a number reasons.
  85   First, as LDAP does not have a standardized method for performing the
  86   two operations in a single transaction, the intermediate directory
  87   state (after the delete, before the add) is visible to other clients,
  88   which may lead to undesirable client behavior.  Second, attributes
  89   such as 'entryUUID' [RFC4530] will reflect the object was replaced,
  90   not transformed.
  91
  92   An LDAP server is expected to prevent clients from modifying values of
  93   NO-USER-MODIFICATION attributes [RFC4512].  For instance, an entry is
  94   not allowed to assign or modify the value of the 'entryUUID'
  95   attribute.  However, where an administrator is restoring a previously
  96   existing object, for instance when repartitioning data between
  97   directory servers or when migrating from one vendor server product to
  98   another, it may be desirable to allow the client to assign or modify
  99   the value of the 'entryUUID' attribute.
 100
 101   This document defines the LDAP Relax Rules control.  This control may
 102   be attached to LDAP requests to update the Directory Information Tree
 103   (DIT) to request various data and service rules be temporarily relaxed
 104   during the performance of the requested DIT update.  The server is
 105   however to ensure the resulting directory state is valid.
 106
 107   Use of this control is expected that use of this extension will be
 108   restricted by administrative and/or access controls.  It is intended
 109   to be used primarily by directory administrators.
 110
 111
 112
 113
 114 Zeilenga                LDAP Relax Rules Control                [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 117
 118
 119   This extension is considered experimental as it is not yet clear
 120   whether it adequately addresses directory administrators' needs for
 121   flexible mechanisms for managing directory objects.  It is hoped that
 122   after suitable amount of time, either this extension or a suitable
 123   replacement will be standardization.
 124
 125
 126 1.1. Terminology
 127
 128   Protocol elements are described using ASN.1 [X.680] with implicit
 129   tags.  The term "BER-encoded" means the element is to be encoded using
 130   the Basic Encoding Rules [X.690] under the restrictions detailed in
 131   Section 5.1 of [RFC4511].
 132
 133   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 134   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 135   document are to be interpreted as described in BCP 14 [RFC2119].
 136
 137   DSA stands for Directory System Agent, a server.  DSE stands for
 138   DSA-specific Entry.
 139
 140
 141 2.  The Relax Rules Control
 142
 143   The Relax Rules control is an LDAP Control [RFC4511] whose controlType
 144   is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of
 145   TRUE.
 146
 147   There is no corresponding response control.
 148
 149   The control is appropriate for all LDAP update requests, including
 150   add, delete, modify, and modifyDN (rename) [RFC4511].
 151
 152   The presence of the Rules Rules control in an LDAP update request
 153   indicates the server temporarily relax X.500 model contraints during
 154   performance of the directory update.
 155
 156   The server may restrict use of this control and/or limit the extent of
 157   the relaxation provided based upon local policy or factors.
 158
 159   The server is obligated to ensure the resulting directory state is
 160   consistent with the X.500 models.  For instance, the server ensure
 161   that values of attributes conform to the value syntax.
 162
 163   It is noted that while this extension may be used to add or modify
 164   objects in a manner which violate the controlling subschema, the
 165   presence of objects in the DIT is not inconsistent with the X.500
 166   models.  For instance, an object created prior to establshment of a
 167
 168
 169
 170 Zeilenga                LDAP Relax Rules Control                [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 173
 174
 175   DIT content rule may contain an attribute now precluded by the current
 176   controlling DIT Content Rule.
 177
 178   Servers implementing this technical specification SHOULD publish the
 179   object identifier IANA-ASSIGNED-OID as a value of the
 180   'supportedControl' attribute [RFC4512] in their root DSE.  A server
 181   MAY choose to advertise this extension only when the client is
 182   authorized to use it.
 183
 184
 185 3.  Use Cases
 186
 187 3.1. Object metamorphism
 188
 189   In absence of this control, an attempt to modify an object's
 190   'objectClass' in a manner which cause a change in the structural
 191   object class of the object would normally lead to an
 192   objectClassModsProhibited error [RFC4511].  The presence of the Relax
 193   Rules control in the modify request requests the change be allowed.
 194   If the server is willing and able to allow the change in the
 195   structural object class of the object.
 196
 197   For instance, to change an 'organization' object into an
 198   'organizationalUnit' object, a client could issue the following LDAP
 199   request:
 200
 201       dn: o=Unit,dc=example,dc=net
 202       control: IANA-ASSIGNED-OID
 203       changetype: modify
 204       delete: objectClass
 205       objectClass: organization
 206       -
 207       add: objectClass
 208       objectClass: organizationalUnit
 209       -
 210
 211   In this case, the server is expected to either effect the requested
 212   change in the structural object class, including updating of the value
 213   of the structural object class, or fail the operation.
 214
 215
 216 3.2. Inactive Attribute Types
 217
 218   In absence of the Relax Rules control, an attempt to add or modify
 219   values to an attribute whose type has been marked inactive in the
 220   controlling subschema (its attribute type description contains the
 221   OBSOLETE field) [RFC4512] normally results in a failure.
 222
 223
 224
 225
 226 Zeilenga                LDAP Relax Rules Control                [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 229
 230
 231   In the presence of the Relax Rules control, the server performs the
 232   update operation as if the attribute's type is marked active in the
 233   controlling subschema (its attribute type description does not contain
 234   the OBSOLETE field).
 235
 236
 237 3.3. DIT Content Rules
 238
 239   In absence of the Relax Rules control, an attempt to include the name
 240   (or OID) of an auxiliary class to an object's 'objectClass' which is
 241   not allowed by the controlling DIT Content Rule would be disallowed
 242   [RFC4512].   Additionally, an attempt to add values of an attribute
 243   not allowed (or explicitly precluded) by the DIT Content Rule would
 244   fail.
 245
 246   In presence of the Relax Rules control, the server performs the update
 247   operation as if the controlling DIT Content Rule allowed any and all
 248   known auxiliary classses to be present and allowed any and all known
 249   attributes to be present (and precluded no attributes).
 250
 251
 252 3.4. DIT Structure Rules and Name Forms
 253
 254   In absence of the Relax Rules control, the service enforces DIT
 255   structure rules and name form requirements of the controlling
 256   subschema [RFC4512].
 257
 258   In the presence of the Relax Rules control, the server performs the
 259   update operation ignoring all DIT structure rules and name forms in
 260   the controlling subschema.
 261
 262
 263 3.5. Modification of Nonconformant Objects
 264
 265   It is also noted that in absense of this control, modification of an
 266   object which presently violates the controlling subschema will fail
 267   unless the modification would result in the object conforming to the
 268   controlling subschema.  That is, modifications of an non-conformant
 269   object should result in a conformant object.
 270
 271   In the presence of this control, modifications of a non-conformant
 272   object need not result in a conformant object.
 273
 274
 275 3.6. NO-USER-MODIFICATION attribute modification
 276
 277   In absence of this control, an attempt to modify values of a
 278   NO-USER-MODIFICATION attribute [RFC4512] would normally lead to a
 279
 280
 281
 282 Zeilenga                LDAP Relax Rules Control                [Page 5]
 283 \f
 284 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 285
 286
 287   constraintViolation or other appropriate error [RFC4511].  In the
 288   presence of the Relax Rules control in the update request requests the
 289   modification be allowed.
 290
 291   Relaxation of the NO-USER-MODIFICATION constraint is not appropriate
 292   for some operational attribute types. For instance, as the value of
 293   the 'structuralObjectClass' is derived by the values of the
 294   'objectClass' attribute, the 'structuralObjectClass' attribute type's
 295   NO-USER-MODIFICATION contraint MUST NOT be relaxed.  To effect a
 296   change in the structuralObjectClass class, values of objectClass
 297   should be changed as discussed in Section 3.1.  Other attributes for
 298   which the NO-USER-MODIFICATION constraint should not be relaxed
 299   include 'subschemaSubentry' [RFC4512] and
 300   'collectiveAttributeSubentries' [RFC3671].
 301
 302   The subsections of this section discuss modification of various
 303   operational attributes where their NO-USER-MODIFICATION constraint may
 304   be relaxed.  Future documents may specify where NO-USER-MODIFICATION
 305   constraints on other operational attribute may be relaxed.  In absence
 306   of a document detailing that the NO-USER-MODIFICATION constraint on a
 307   particular operational attribute may be relaxed, implementors SHOULD
 308   assume relaxation of the constraint is not appropriate for that
 309   attribute.
 310
 311
 312 3.1.1. 'entryUUID' attribute
 313
 314   To provide a value for the 'entryUUID' [RFC4530] attribute on entry
 315   creation, the client should issue an LDAP Add request with a Relax
 316   Rules control providing the desired value.  For instance:
 317
 318       dn: ou=Unit,dc=example,dc=net
 319       control: IANA-ASSIGNED-OID
 320       changetype: add
 321       objectClass: organizationalUnit
 322       ou: Unit
 323       entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
 324
 325   In this case, the server is either to add the entry using the
 326   provided 'entryUUID' value or fail the request.
 327
 328   To provide a replacement value for the 'entryUUID' after entry
 329   creation, the client should issue an LDAP Modify request with a
 330   Relax Rules control including an approrpiate change.  For instance:
 331
 332       dn: ou=Unit,dc=example,dc=net
 333       control: IANA-ASSIGNED-OID
 334       changetype: modify
 335
 336
 337
 338 Zeilenga                LDAP Relax Rules Control                [Page 6]
 339 \f
 340 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 341
 342
 343       replace: entryUUID
 344       entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
 345       -
 346
 347   In this case, the server is either to replace the 'entryUUID' value
 348   as requested or fail the request.
 349
 350
 351 3.2.2. createTimestamp
 352
 353   To provide a value for the 'createTimestamp' [RFC4512] attribute
 354   on entry creation, the client should issue an LDAP Add request with
 355   a Relax Rules control providing the desired 'createTimestamp'
 356   value.  For instance:
 357
 358       dn: ou=Unit,dc=example,dc=net
 359       control: IANA-ASSIGNED-OID
 360       changetype: add
 361       objectClass: organizationalUnit
 362       ou: Unit
 363       createTimestamp: 20060101000000Z
 364
 365   In this case, the server is either to add the entry using the
 366   provided 'createTimestamp' value or fail the request.
 367
 368   To provide a replacement value for the 'createTimestamp' after
 369   entry creation, the client should issue an LDAP Modify request with
 370   a Relax Rules control including an approrpiate change.  For instance:
 371
 372       dn: ou=Unit,dc=example,dc=net
 373       control: IANA-ASSIGNED-OID
 374       changetype: modify
 375       replace: createTimestamp
 376       createTimestamp: 20060101000000Z
 377       -
 378
 379   In this case, the server is either to replace the 'createTimestamp'
 380   value as requested or fail the request.
 381
 382   The server should ensure the requested 'createTimestamp' value is
 383   appropriate.  In particular, it should fail the request if the
 384   requested 'createTimestamp' value is in the future or is greater
 385   than the value of the 'modifyTimestamp' attribute.
 386
 387
 388 3.2.3. modifyTimestamp
 389
 390   To provide a value for the 'modifyTimestamp' [RFC4512] attribute
 391
 392
 393
 394 Zeilenga                LDAP Relax Rules Control                [Page 7]
 395 \f
 396 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 397
 398
 399   on entry creation, the client should issue an LDAP Add request with
 400   a Relax Rules control providing the desired 'modifyTimestamp'
 401   value.  For instance:
 402
 403       dn: ou=Unit,dc=example,dc=net
 404       control: IANA-ASSIGNED-OID
 405       changetype: add
 406       objectClass: organizationalUnit
 407       ou: Unit
 408       modifyTimestamp: 20060101000000Z
 409
 410   In this case, the server is either to add the entry using
 411   the provided 'modifyTimestamp' value or fail the request.
 412
 413   To provide a replacement value for the 'modifyTimestamp' after
 414   entry creation, the client should issue an LDAP Modify
 415   request with a Relax Rules control including an approrpiate
 416   change.  For instance:
 417
 418       dn: ou=Unit,dc=example,dc=net
 419       control: IANA-ASSIGNED-OID
 420       changetype: modify
 421       replace: modifyTimestamp
 422       modifyTimestamp: 20060101000000Z
 423       -
 424
 425   In this case, the server is either to replace the 'modifyTimestamp'
 426   value as requested or fail the request.
 427
 428   The server should ensure the requested 'modifyTimestamp' value is
 429   appropriate.  In particular, it should fail the request if the
 430   requested 'modifyTimestamp' value is in the future or is less than
 431   the value of the 'createTimestamp' attribute.
 432
 433
 434   3.2.3. creatorsName and modifiersName
 435
 436   To provide a value for the 'creatorsName' and/or 'modifiersName'
 437   [RFC4512] attribute on entry creation, the client should issue an
 438   LDAP Add request with a Relax Rules control providing the desired
 439   values.  For instance:
 440
 441       dn: ou=Unit,dc=example,dc=net
 442       control: IANA-ASSIGNED-OID
 443       changetype: add
 444       objectClass: organizationalUnit
 445       ou: Unit
 446       creatorsName: cn=Jane Doe,dc=example,net
 447
 448
 449
 450 Zeilenga                LDAP Relax Rules Control                [Page 8]
 451 \f
 452 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 453
 454
 455       modifiersName: cn=Jane Doe,dc=example,net
 456
 457   In this case, the server is either to add the entry using
 458   the provided values or fail the request.
 459
 460   To provide a replacement values after entry creation for either of
 461   the 'creatorsName' or 'modifiersName' attributes or both, the
 462   client should issue an LDAP Modify request with a Relax Rules control
 463   including the approrpiate changes.  For instance:
 464
 465       dn: ou=Unit,dc=example,dc=net
 466       control: IANA-ASSIGNED-OID
 467       changetype: modify
 468       replace: creatorsName
 469       creatorsName: cn=Jane Doe,dc=example,net
 470       -
 471       replace: modifiersName
 472       modifiersName: cn=Jane Doe,dc=example,net
 473       -
 474
 475   In this case, the server is either to replace the provided
 476   values as requested or fail the request.
 477
 478
 479 4.  Security Considerations
 480
 481   Use of this extension should be subject to appropriate administrative
 482   and access controls.  Use of this mechanism is intended to be
 483   restricted to directory administrators.
 484
 485   Security considerations for the base operations [RFC4511] extended
 486   by this control, as well as general LDAP security considerations
 487   [RFC4510], generally apply to implementation and use of this
 488   extension.
 489
 490
 491 5.  IANA Considerations
 492
 493 5.1.  Object Identifier
 494
 495   It is requested that the IANA assign a LDAP Object Identifier
 496   [RFC4520] to identify the LDAP Relax Rules Control defined in this
 497   document.
 498
 499       Subject: Request for LDAP Object Identifier Registration
 500       Person & email address to contact for further information:
 501           Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
 502       Specification: RFC XXXX
 503
 504
 505
 506 Zeilenga                LDAP Relax Rules Control                [Page 9]
 507 \f
 508 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 509
 510
 511       Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
 512       Comments: Identifies the LDAP Relax Rules Control
 513
 514 5.2  LDAP Protocol Mechanism
 515
 516   Registration of this protocol mechanism [RFC4520] is requested.
 517
 518       Subject: Request for LDAP Protocol Mechanism Registration
 519       Object Identifier: IANA-ASSIGNED-OID
 520       Description: Relax Rules Control
 521       Person & email address to contact for further information:
 522           Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
 523       Usage: Control
 524       Specification: RFC XXXX
 525       Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
 526       Comments: none
 527
 528
 529 6.  Author's Address
 530
 531   Kurt D. Zeilenga
 532   Isode Limited
 533
 534   Email: Kurt.Zeilenga@Isode.COM
 535
 536
 537 7. References
 538
 539   [[Note to the RFC Editor: please replace the citation tags used in
 540   referencing Internet-Drafts with tags of the form RFCnnnn where
 541   possible.]]
 542
 543
 544 7.1. Normative References
 545
 546   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 547                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 548
 549   [RFC3671]     Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
 550                 December 2003.
 551
 552   [RFC4510]     Zeilenga, K. (editor), "LDAP: Technical Specification
 553                 Road Map", RFC 4510, June 2006.
 554
 555   [RFC4511]     Sermersheim, J. (editor), "LDAP: The Protocol", RFC
 556                 4511, June 2006.
 557
 558   [RFC4512]     Zeilenga, K. (editor), "LDAP: Directory Information
 559
 560
 561
 562 Zeilenga                LDAP Relax Rules Control               [Page 10]
 563 \f
 564 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 565
 566
 567                 Models", RFC 4512, June 2006.
 568
 569   [RFC4530]     Zeilenga, K., "Lightweight Directory Access Protocol
 570                 (LDAP) entryUUID Operational Attribute", RFC 4530, June
 571                 2006.
 572
 573   [X.500]       International Telecommunication Union -
 574                 Telecommunication Standardization Sector, "The Directory
 575                 -- Overview of concepts, models and services,"
 576                 X.500(1993) (also ISO/IEC 9594-1:1994).
 577
 578
 579 7.2. Informative References
 580
 581   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
 582                 (IANA) Considerations for the Lightweight Directory
 583                 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
 584
 585
 586
 587 Intellectual Property
 588
 589   The IETF takes no position regarding the validity or scope of any
 590   Intellectual Property Rights or other rights that might be claimed to
 591   pertain to the implementation or use of the technology described in
 592   this document or the extent to which any license under such rights
 593   might or might not be available; nor does it represent that it has
 594   made any independent effort to identify any such rights.  Information
 595   on the procedures with respect to rights in RFC documents can be found
 596   in BCP 78 and BCP 79.
 597
 598   Copies of IPR disclosures made to the IETF Secretariat and any
 599   assurances of licenses to be made available, or the result of an
 600   attempt made to obtain a general license or permission for the use of
 601   such proprietary rights by implementers or users of this specification
 602   can be obtained from the IETF on-line IPR repository at
 603   http://www.ietf.org/ipr.
 604
 605   The IETF invites any interested party to bring to its attention any
 606   copyrights, patents or patent applications, or other proprietary
 607   rights that may cover technology that may be required to implement
 608   this standard.  Please address the information to the IETF at
 609   ietf-ipr@ietf.org.
 610
 611
 612
 613 Full Copyright
 614
 615
 616
 617
 618 Zeilenga                LDAP Relax Rules Control               [Page 11]
 619 \f
 620 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
 621
 622
 623   Copyright (C) The IETF Trust (2007).
 624
 625   This document is subject to the rights, licenses and restrictions
 626   contained in BCP 78, and except as set forth therein, the authors
 627   retain all their rights.
 628
 629   This document and the information contained herein are provided on an
 630   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 631   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 632   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 633   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 634   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 635   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Zeilenga                LDAP Relax Rules Control               [Page 12]
 675 \f