[APPS-REVIEW] Review of draft-wahl-ldap-adminaddr
Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Fri, 25 May 2007 14:24 UTC
Return-path: <apps-review-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiN-0000Ns-FE; Fri, 25 May 2007 10:24:23 -0400
Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HraiM-0000Na-M9 for apps-review-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:22 -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 <RlbxjQBlQINy@rufus.isode.com>; 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 <Kurt.Zeilenga@Isode.com>
Date: Fri, 25 May 2007 07:24:06 -0700
To: Mark Wahl <Mark.Wahl@informed-control.com>, Chris Newman <Chris.Newman@Sun.COM>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: Ldapext <ldapext@ietf.org>, ldap-dir@ietf.org, apps-review@ietf.org
Subject: [APPS-REVIEW] Review of draft-wahl-ldap-adminaddr
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
Errors-To: apps-review-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. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review
- [APPS-REVIEW] Review of draft-wahl-ldap-adminaddr Kurt Zeilenga
- [APPS-REVIEW] Re: [ldapext] Re: Review of draft-w… Kurt Zeilenga
- [APPS-REVIEW] Re: Review of draft-wahl-ldap-admin… Mark Wahl