idnits 2.17.1 draft-wahl-ldap-adminaddr-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 74: '... The word SHOULD in this section is defined in [1]....' RFC 2119 keyword, line 76: '...s control policy SHOULD allow this inf...' RFC 2119 keyword, line 79: '...entication decisions propoerly, it MAY...' RFC 2119 keyword, line 80: '...he administrator SHOULD then choose ad...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2000) is 8624 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 94 looks like a reference -- Missing reference section? '3' on line 97 looks like a reference -- Missing reference section? '1' on line 91 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Sun Microsystems, Inc. 3 Expires in September 2000 5 Administrator Address Attribute 6 draft-wahl-ldap-adminaddr-00.txt 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or made obsolete by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This draft, file name draft-wahl-ldap-adminaddr-xx.txt, is intended 29 to be become an Informational RFC. Distribution of this document 30 is unlimited. 32 2. Abstract 34 Organizations running multiple directory servers need an ability for 35 administrators to determine who is responsible for a particular server. 36 This is conceptually similar to the 'sysContact' object of SNMP. 38 3. The administratorsAddress attribute 40 This attribute allows a server administrator to provide the contact 41 information of the responsible party for an LDAP server. This can 42 be used by management clients which are, for example, checking the 43 state of a replication or referral topology, to provide a way for the 44 user of the management client to send email to manager of a particular 45 server. 47 The attribute is defined as follows: 49 ( 1.3.6.1.4.1.1466.101.120.1 NAME 'administratorsAddress' 50 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 51 USAGE directoryOperation ) 53 This attribute is located in the root DSE. It can contain one or 54 more values, each containing a URI [2]. Unlike the labeledURI [3] 55 attribute, these values do not have a label. 57 This document only specifies how a client can read this attribute. 58 Updating this attribute over protocol is out of scope of this 59 document. Typically this attribute would be configured through the 60 server's management interface. 62 In existing practice, this URI is commonly of the 'mailto:' form 63 identifying a role mail address, such as 64 "mailto:helpdesk@example.com". 66 (Note that this address need not be the same as that of the directory 67 data administrator. The address might not be suitable for comments or 68 problems affecting the data held in the directory server. An 69 attribute for providing the contact details for a data administrator 70 belongs in the naming contexts.) 72 4. Security Considerations 74 The word SHOULD in this section is defined in [1]. 76 The server's access control policy SHOULD allow this information to 77 be visible to any suitable administrator in the same organization. 78 Since one use of this attribute is to find who is responsible if 79 the server is not making authentication decisions propoerly, it MAY 80 be publically visible. The administrator SHOULD then choose addresses 81 that are already publically known. 83 5. Acknowlegements 85 The contents of this document is based on earlier work of the ASID 86 Working Group of the IETF. The contributions of its members is 87 greatly appreciated. 89 6. Bibliography 91 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 92 Levels", RFC 2119. 94 [2] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform 95 Resource Locators (URL)", RFC 1738. 97 [3] M. Smith, "Definition of an X.500 Attribute Type and Object Class 98 to Hold Uniform Resource Identifiers (URIs)", RFC 2079. 100 7. Authors Address 102 Mark Wahl 103 Sun Microsystems, Inc. 104 8911 Capital of Texas Hwy, Suite 4140 105 Austin, TX 78759 106 USA 108 Phone: +1 512 231 1600 109 EMail: Mark.Wahl@innosoft.com 111 Intellectual Property Notice 113 The IETF takes no position regarding the validity or scope of any 114 intellectual property or other rights that might be claimed to 115 pertain to the implementation or use of the technology described in 116 this document or the extent to which any license under such rights 117 might or might not be available; neither does it represent that it has 118 made any effort to identify any such rights. Information on the 119 IETF's procedures with respect to rights in standards-track and 120 standards-related documentation can be found in BCP-11. 121 Copies of claims of rights made available for publication and any 122 assurances of licenses to be made available, or the result of an 123 attempt made to obtain a general license or permission for the use of 124 such proprietary rights by implementors or users of this specification 125 can be obtained from the IETF Secretariat. 127 The IETF invites any interested party to bring to its attention any 128 copyrights, patents or patent applications, or other proprietary 129 rights which may cover technology that may be required to practice 130 this standard. Please address the information to the IETF Executive 131 Director. 133 Full Copyright Statement 135 Copyright (C) The Internet Society (1999-2000). All Rights Reserved. 137 This document and translations of it may be copied and furnished to 138 others, and derivative works that comment on or otherwise explain it 139 or assist in its implementation may be prepared, copied, published 140 and distributed, in whole or in part, without restriction of any 141 kind, provided that the above copyright notice and this paragraph are 142 included on all such copies and derivative works. However, this 143 document itself may not be modified in any way, such as by removing 144 the copyright notice or references to the Internet Society or other 145 Internet organizations, except as needed for the purpose of 146 developing Internet standards in which case the procedures for 147 copyrights defined in the Internet Standards process must be 148 followed, or as required to translate it into languages other than 149 English. 151 The limited permissions granted above are perpetual and will not be 152 revoked by the Internet Society or its successors or assigns. 154 This document and the information contained herein is provided on an 155 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 156 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 157 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 158 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 159 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.