[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