[ldapext] Review of draft-wahl-ldap-adminaddr

Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Fri, 25 May 2007 14:24 UTC

Return-path: <ldapext-bounces@ietf.org>
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 <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: [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 <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=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