[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



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