[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Review of draft-wahl-ldap-subtree-source
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