From ldapext-bounces@ietf.org Sat May 05 17:06:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkRSV-0002xT-Ds; Sat, 05 May 2007 17:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkRST-0002xO-QM for ldapext@ietf.org; Sat, 05 May 2007 17:06:25 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkRSS-00014C-E3 for ldapext@ietf.org; Sat, 05 May 2007 17:06:25 -0400 Received: from [10.224.14.153] (m010f36d0.tmodns.net [208.54.15.1]) by rufus.isode.com (submission channel) via TCP with ESMTPA id for ; Sat, 5 May 2007 22:06:22 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7BD54F47-0C51-43D5-B9D8-39013E5AFE57@Isode.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Ldapext From: Kurt Zeilenga Date: Sat, 5 May 2007 13:25:23 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [ldapext] LDAP BoF at IETF#69? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org It seems to me that it might be appropriate to organize a BoF (bar or actual) at IETF#69 to discuss specification and standardization of various LDAP extensions, determine whether a WG is needed/desired to further this engineering, and, if so, rough out a charter proposal. Some work candidates (in no particular order): Internet Naming Plan (update) Distributed Operations (chaining) Distributed Authentication Use of DNS in Internet directories (DNS SRV) Password Policy administrative model and notifications Transactions DAP/LDAP alignment Regular Expression Matching Rule If there is sufficient interested shown on this list (and elsewhere), I would be willing to put together a BoF proposal for AD/IESG consideration. So, please let your views on whether such a BoF should be held known. You're also more than welcomed to name other work candidates, and comment on those that I enumerated. Also, those willing to serve as a BOF chair should drop me a note. Regards, Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 16 17:19:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQu5-00076x-7G; Wed, 16 May 2007 17:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQu4-00074o-6Z for ldapext@ietf.org; Wed, 16 May 2007 17:19:24 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoQu3-0000Uc-Ox for ldapext@ietf.org; Wed, 16 May 2007 17:19:24 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 16 May 2007 22:19:22 +0100 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: <7BD54F47-0C51-43D5-B9D8-39013E5AFE57@Isode.com> References: <7BD54F47-0C51-43D5-B9D8-39013E5AFE57@Isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76D5008F-5269-4900-A6C2-1ECAAAADB634@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Subject: Re: [ldapext] LDAP BoF at IETF#69? Date: Wed, 16 May 2007 14:19:15 -0700 To: Kurt Zeilenga X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org There has been insufficient interest shown in holding an LDAP BoF at IETF#69 and, hence, I won't be putting together a formal BoF proposal for AD/IESG consideration. I will be attending IETF#69 anyways and would be happy to met with LDAP'ers informally (e.g., at the bar) to discussion any on-going / future LDAP work. -- Kurt On May 5, 2007, at 5:25 AM, Kurt Zeilenga wrote: > It seems to me that it might be appropriate to organize a BoF (bar > or actual) > at IETF#69 to discuss specification and standardization of various > LDAP > extensions, determine whether a WG is needed/desired to further this > engineering, and, if so, rough out a charter proposal. > > Some work candidates (in no particular order): > > Internet Naming Plan (update) > Distributed Operations (chaining) > Distributed Authentication > Use of DNS in Internet directories (DNS SRV) > Password Policy administrative model and notifications > Transactions > DAP/LDAP alignment > Regular Expression Matching Rule > > If there is sufficient interested shown on this list (and > elsewhere), I > would be willing to put together a BoF proposal for AD/IESG > consideration. > So, please let your views on whether such a BoF should be held known. > > You're also more than welcomed to name other work candidates, and > comment > on those that I enumerated. > > Also, those willing to serve as a BOF chair should drop me a note. > > Regards, Kurt > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri May 25 10:24:26 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-0000Ov-KJ; Fri, 25 May 2007 10:24:24 -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: [ldapext] Review of draft-wahl-ldap-adminaddr X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-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. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-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 1HraiW-0000Vs-5G; Fri, 25 May 2007 10:24:32 -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: [ldapext] Review of draft-wahl-ldap-subtree-source X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-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". _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-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-0000a7-E7; Fri, 25 May 2007 10:24:39 -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: [ldapext] Review of draft-wahl-ldap-p3p X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-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. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri May 25 11:01:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrbHs-0005t6-Mv; Fri, 25 May 2007 11:01:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrbHq-0005sc-Es; Fri, 25 May 2007 11:01:02 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrbHp-0001Bt-5c; Fri, 25 May 2007 11:01:02 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id D1A4674353; Fri, 25 May 2007 17:00:59 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27745-01-24; Fri, 25 May 2007 17:00:59 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 6333974279; Fri, 25 May 2007 17:00:56 +0200 (CEST) Message-ID: <4656FA33.6000608@it.su.se> Date: Fri, 25 May 2007 17:01:07 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Kurt Zeilenga Subject: Re: [ldapext] Review of draft-wahl-ldap-subtree-source References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.312 tagged_above=-99 required=7 tests=[BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ldapext , Mark Wahl , Chris Newman , ldap-dir@ietf.org, apps-review@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Kurt Zeilenga wrote: > 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. > In practice I'd say entries are typically derived from multiple sources. Attribute or even value scope would be ideal imo but that may be impractical. I definitely agree that subree scope is too blunt a tool. Cheers Leif _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 30 12:36:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRAJ-00013d-1r; Wed, 30 May 2007 12:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRAE-00012y-5P; Wed, 30 May 2007 12:36:46 -0400 Received: from mail.cs.utexas.edu ([128.83.139.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRAC-0007YU-SW; Wed, 30 May 2007 12:36:46 -0400 Received: from [192.168.0.14] (rrcs-71-42-113-213.sw.biz.rr.com [71.42.113.213]) (authenticated bits=0) by mail.cs.utexas.edu (8.14.1/8.14.1) with ESMTP id l4UGaUtm023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 11:36:43 -0500 (CDT) Message-ID: <465DA809.9020306@informed-control.com> Date: Wed, 30 May 2007 11:36:25 -0500 From: Mark Wahl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> In-Reply-To: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Ldapext , Mark Wahl , Chris Newman , ldap-dir@ietf.org, apps-review@ietf.org Subject: [ldapext] Re: Review of draft-wahl-ldap-adminaddr X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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". Mark Wahl Informed Control Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 30 15:39:50 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-0004dT-GK; Wed, 30 May 2007 15:39:47 -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 Subject: Re: [ldapext] Re: Review of draft-wahl-ldap-adminaddr 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 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext