From ldap-dir-bounces@ietf.org Thu May 17 19:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hop7w-0005aR-Bd; Thu, 17 May 2007 19:11:20 -0400 Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1HixnG-0004ZE-74 for ldap-dir-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 15:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HixnF-0004Z6-Tu for ldap-dir@ietf.org; Tue, 01 May 2007 15:13:45 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HixnA-0002Kw-IO for ldap-dir@ietf.org; Tue, 01 May 2007 15:13:45 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l41JDejh013363 for ; Tue, 1 May 2007 19:13:40 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHD00C01MAHJ600@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ldap-dir@ietf.org; Tue, 01 May 2007 13:13:40 -0600 (MDT) Received: from [192.168.0.103] ([209.78.251.2]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHD007ZUMQPW220@mail-amer.sun.com> for ldap-dir@ietf.org; Tue, 01 May 2007 13:13:39 -0600 (MDT) Date: Tue, 01 May 2007 12:13:20 -0700 From: Chris Newman To: ldap-dir@ietf.org Message-id: <62B5CF0CB44DE0B82AF40991@[192.168.0.103]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Thu, 17 May 2007 19:11:19 -0400 Subject: [Ldap-dir] Mark Wahl's individual submissions X-BeenThere: ldap-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ldap-dir-bounces@ietf.org Mark Wahl has ask the following documents move to proposed standard: I would like at least one person on the directorate other than Mark to express support for moving these forward. I would appreciate it if anyone on the directorate has time to fill out a proto write up for these documents. For details on what that entails, see Thanks, - Chris Newman Applications Area Director _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir From ldap-dir-bounces@ietf.org Mon May 21 03:14:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq25g-0001UC-MJ; Mon, 21 May 2007 03:14:00 -0400 Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1Hq25f-0001LL-04 for ldap-dir-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 03:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq25e-0001GR-7d for ldap-dir@ietf.org; Mon, 21 May 2007 03:13:58 -0400 Received: from eb2bcom.com ([72.232.34.13] helo=host.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq25c-0000Fv-In for ldap-dir@ietf.org; Mon, 21 May 2007 03:13:58 -0400 Received: from [203.206.165.210] (helo=[192.168.1.156]) by host.eb2bcom.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hq25c-0006A3-TB; Mon, 21 May 2007 17:13:57 +1000 Message-ID: <465146AF.6020009@eb2bcom.com> Date: Mon, 21 May 2007 17:13:51 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Newman Subject: Re: [Ldap-dir] Mark Wahl's individual submissions References: <62B5CF0CB44DE0B82AF40991@[192.168.0.103]> In-Reply-To: <62B5CF0CB44DE0B82AF40991@[192.168.0.103]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ldap-dir@ietf.org X-BeenThere: ldap-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ldap-dir-bounces@ietf.org Chris, This message only showed up in my mail box a few days ago. I don't have a current need for these proposals, so I can't attest to their usefulness, but I can comment on the technical content. Chris Newman wrote: > Mark Wahl has ask the following documents move to proposed standard: > > I have no concern over this document progressing as a proposed standard. > > The only concern I have over this document being progressed as a proposed standard is that the method a client needs to follow to obtain the appropriate subtreeP3PrivacyPolicy attribute isn't well defined. Two independent client implementations could end up applying different policy because they don't look in the same likely places or don't look in those likely places in the same order. > > I have no concern over this document progressing as a proposed standard. I find the last sentence in section 2, i.e., "The semantics of comparison of values of this attribute for equality is outside of the scope of this document." a little odd given that the attribute definition explicitly references caseExactMatch as the equality matching rule. I would guess that Mark is referring to the problem that two URI strings that are not equal according to the caseExactMatch matching rule can nonetheless be equivalent as URIs. > > I would like at least one person on the directorate other than Mark to > express support for moving these forward. If the method for obtaining the subtreeP3PrivacyPolicy attribute is better defined then I see no harm in progressing the documents. Does that count as support ? > > I would appreciate it if anyone on the directorate has time to fill out > a proto write up for these documents. For details on what that entails, see > Not me I'm afraid. Regards, Steven > > Thanks, > - Chris Newman > Applications Area Director > > > > _______________________________________________ > Ldap-dir mailing list > Ldap-dir@ietf.org > https://www1.ietf.org/mailman/listinfo/ldap-dir > _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir From ldap-dir-bounces@ietf.org Fri May 25 10:24:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiO-0000OW-H8; Fri, 25 May 2007 10:24:24 -0400 Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1HraiN-0000Nk-7B for ldap-dir-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiJ-0000NO-M4; Fri, 25 May 2007 10:24:19 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiI-0000uT-6r; Fri, 25 May 2007 10:24:19 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 May 2007 15:24:14 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Fri, 25 May 2007 07:24:06 -0700 To: Mark Wahl , Chris Newman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [Ldap-dir] Review of draft-wahl-ldap-adminaddr X-BeenThere: ldap-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ldap-dir-bounces@ietf.org I reviewed this draft on behalf of the Apps Area Review team and the LDAP Directorate. Such reviews have no special weight in the IETF. Summary: This I-D specifies the administratorsAddress attribute type for use in LDAP directory services to hold contact information about an "administrator". This document has a few minor issues. Once addressed, I see no problem with publication of this document. The attribute type was described in an ASID WG draft as having dSAOperation usage, which is generally appropriate for attributes providing information specific to the DSA (server). In this I-D it has directoryOperation usage. I assume the change was due to allowing the attribute not only to appear in the Root DSE, but in entries at the context prefix. I don't have any problem with this change, but it likely should be noted. Might be good to expand its applicability to other subentries. For instance, when placed in a collective attribute subentry, the attribute would contain the address of the party responsible for the content of that subentry. Expansion beyond this would likely be problematic. Should likely have an equality matching rule as well, but no ordering or substrings rule. As the syntax, IA5String, is not constrained to URIs, the I-D should say something about what clients should do when the value isn't a valid URI. (Treat it like an non-resolvable URI.) I do find the uses of SHOULD in the Security Consideration section kind of odd. Use of RFC 2119 keywords should be limited to specification of implementation requirements. It would be appropriate to say that access to this attribute SHOULD be controlled by the server's authorization mechanisms, any guidance to the server administrator as to what access policy for this attribute should be stated as guidance. Since one use of this attribute is to find who is responsible if the server is not making authentication decisions properly, a directory server configuration SHOULD cause the attribute in the root DSE, if present, to be able to be returned in a search response to all users who are permitted to access the directory server. If the user cannot authenticate, he's anonymous to the server, so by the above, I assume you mean: Since one use of this attribute is to find who is responsible if the server is not making authentication decisions properly, it may be appropriate to allow anonymous access this information (with or without other administrative restrictions). (your wording could be taken a number of odd ways) I suggest stating that servers SHOULD allow the administrator to control access to this attribute (via whatever access control mechanisms it offers). And where they don't allow the administrator to control access, they MUST allow the administrator to elect not to publish contact information. _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir From ldap-dir-bounces@ietf.org Fri May 25 10:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiV-0000Uq-Ux; Fri, 25 May 2007 10:24:31 -0400 Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1HraiV-0000RQ-59 for ldap-dir-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiT-0000Pt-2E; Fri, 25 May 2007 10:24:29 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiR-0000vw-Nf; Fri, 25 May 2007 10:24:29 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 May 2007 15:24:25 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Fri, 25 May 2007 07:24:19 -0700 To: Mark Wahl , Chris Newman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [Ldap-dir] Review of draft-wahl-ldap-subtree-source X-BeenThere: ldap-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ldap-dir-bounces@ietf.org I reviewed this draft on behalf of the Apps Area Review team and the LDAP Directorate. Such reviews have no special weight in the IETF. That is, this message should be treated simply as comments from an IETF participant. Summary: This document specifies an directory attribute to publish the "source" of directory entries. Directory entries often do derive from other sources. An entry could easily derive from multiple sources. Having a standard attribute that holds reliable source information seems to useful. However, I wonder if it appropriate to have an attribute which has "subtree" scope. I would think an attribute with "entry" scope would be better. The main problem with use of a "subtree" scope attribute here is that it can be quite difficult, if not impossible, for the client to determine how entries in the subtree relate to objects at the source URI. For instance, say I have a subtree of each entries, each representing a page from a website. How can the client relate an entry of the subtree to a page from a website? It should be assumed that the relationship between the derived entry and its specific source element at the source (provided by the source URI) is non-obvious. Under this assumption, the source URI only provides information about the source of the subtree as a collection of entries, not information about the particular source object of any particular entry in the collection. I don't see how automated tools could make use of non-specific subtree source information. Say I have a subtree of entries derived from a website. How is Beyond this, I think RFC 2119 keywords are misused in the document, especially within the Security Considerations section. RFC 2119 keywords should only be used to detail requirements up implementations. While certainly server implementations SHOULD be capable of restricting access to this attribute (by whatever means they provide) (SHOULD be protectABLE), access policy is a local matter (should/should not be protectED). I see no reason why the document should recommend access be restricted to "administrative tools". _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir From ldap-dir-bounces@ietf.org Fri May 25 10:24:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hraid-0000aP-IP; Fri, 25 May 2007 10:24:39 -0400 Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1Hraib-0000Yw-Fe for ldap-dir-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hraia-0000YY-R6; Fri, 25 May 2007 10:24:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiY-0000wB-BR; Fri, 25 May 2007 10:24:36 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 May 2007 15:24:33 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7039DF2B-2C9A-46DC-8D0E-16971083F942@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Fri, 25 May 2007 07:24:27 -0700 To: Mark Wahl , Chris Newman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [Ldap-dir] Review of draft-wahl-ldap-p3p X-BeenThere: ldap-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ldap-dir-bounces@ietf.org I reviewed this draft on behalf of the Apps Area Review team and the LDAP Directorate. Such reviews have no special weight in the IETF. Summary: This I-D specifies LDAP schema for holding URIs for privacy policy documents. Though it seems a good idea for a directory service to publish its privacy policy information, I rather see the information stored in the directory so that directory clients need not use another access protocol. Aside from avoiding complexity in client implementations, there may be some security considerations specific to the use of a second protocol, and second connection to retrieve the policy information. The key issues here center around trust. Another issue with the expectation that an LDAP client can talk HTTP, is that LDAP clients often use authentication and data services which are not supported in HTTP. For instance, LDAP supports SASL, and HTTP doesn't. I dislike "subtree scoped" attributes as they make it more difficult than necessary for clients to obtain the information. The last paragraph of page 7 says "Clients MUST NOT assume the absence of this class in an entry's objectClass implies that the subtreeP3PrivacyPolicy attribute is not present in the entry...." This implies, however, that a client can assume the absence of the subtreeP3PrivacyPolicy in results requesting its return implies absence in the entry. A client, of course, cannot assume this. Unfortunately, because of the apparent absence, the client will likely go looking for this attribute in superior entries. If it finds one, or one in the Root DSE, the client will get the wrong privacy policy. I think it would be far better to define privacy policy in terms of the LDAP/X.500 administrative model. I note the community discussed use of subtree policy attributes v. use of subentries on multiple occasions, and seems to favor use of subentries (as evident by both ACI and password policy proposals, initially submitted using subtree scoped attributes, to being re-engineered to use subentries). That said, these discussions may not completely apply here. More discussion is needed. Lastly, a few minor things: The serverP3PrivacyPolicy attribute likely should have usage dSAOperation as it's DSA-specific (as are all root DSE attributes). The last paragraph on page 7 says "... this attribute might ... be provided through collective attributes". However, as the attribute is not defined as being COLLECTIVE, it simply cannot be provided as a collective attribute (as defined in [RFC 3671]). You likely meant something else. I suggest you say "provided by other means". For instance, the attribute could be specifically allowed by the controlling DIT content rule. Should note that caseExactMatch is not designed for matching of URIs and will return False for URIs which are equivalent, like http:// www.example.com v. HTTP://WWW.EXAMPLE.COM. Given serverP3PrivacyPolicy attribute is single valued, use of caseIgnoreMatch might be more appropriate (as it will return TRUE in cases such as the above). Of course, caseIgnoreMatch will ignore differences in URIs that are similar, like http://www.example.com/x and http://www.example.com/X. In either case, the inadequency of the matching rule chosen should be discussed in the I-D (and possibly the security considerations section. Also note that the LDAP data preservation requirements is also problematic, especially for the subtreeP3PrivacyPolicy (as its a user applications attribute). LDAP only requirements only require the server to return a value which is equivalent per the matching rule. To ensure the value is actually preserved, it might be best to use octetString and octetStringMatch to hold the URI. The document likely should include a statement of how a client is to treat a value which is not a valid URI. The attribute type and object class definitions were line-wrapped for readability. A note stating this is required (per Section 5 of BCP 118). Should include a references for UTF-8, XML, and LDAP URL. HTTP cite should be on first mention. Acronyms should be spelled out on first use in title, in Abstract, and in body. _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir From ldap-dir-bounces@ietf.org Wed May 30 15:39:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU1L-0004d5-Ct; Wed, 30 May 2007 15:39:47 -0400 Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1HtU1K-0004ct-Jw for ldap-dir-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 15:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU1K-0004ca-0F; Wed, 30 May 2007 15:39:46 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtU1I-0003z4-Iy; Wed, 30 May 2007 15:39:45 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 30 May 2007 20:39:43 +0100 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: <465DA809.9020306@informed-control.com> References: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> <465DA809.9020306@informed-control.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E9A40B4-C10B-44C7-B64E-5710CB71F4B0@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Wed, 30 May 2007 12:39:37 -0700 To: Mark Wahl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Chris Newman , Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [Ldap-dir] Re: [ldapext] Re: Review of draft-wahl-ldap-adminaddr X-BeenThere: ldap-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ldap-dir-bounces@ietf.org On May 30, 2007, at 9:36 AM, Mark Wahl wrote: > Kurt Zeilenga wrote: >> I reviewed this draft on behalf of the Apps Area Review team and >> the LDAP Directorate. > > Thanks for your comments on these drafts! I'll be reviewing your > emails and will respond shortly with more details. > >> I do find the uses of SHOULD in the Security Consideration section >> kind of odd. Use >> of RFC 2119 keywords should be limited to specification of >> implementation requirements. > > If so, then RFC 2119 should be revised to incorporate that limitation, > as I don't see that stated in 2119, and I observe in recently > published > proposed standard RFCs the use of RFC 2119 terminology in the security > considerations sections to make statements beyond implementation > requirements, e.g., RFC 4875 "Specifications of applications within > the > IETF MUST specify this mechanism" or RFC 4872 "RSVP signaling MUST be > able to provide authentication and integrity". There are plenty of examples of RFC 2119 keywords being oddly used... (including RFC 2119 itself). As I wasn't intending to start a debate on use of RFC 2119 keywords, I suggest you can take my RFC 2119 comments as indicating a concern that the document may not be clear as whom its requirements are placed upon. For instance, "The server's access control policy SHOULD allow this information to be visible to a suitable administrator in the same organization. can be taken to mean: The server SHOULD restricted allowable access control policies to those which cause this information to be visible to suitable administrators in the same organization. Which, if implemented in a server, would be quite bad. To avoid such confusion, I recommend you only use RFC 2119 keywords to impart requirements upon implementations of the specification and to word recommendations to server administrators as guidance. -- Kurt _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir