[Ldap-dir] Review of draft-wahl-ldap-subtree-source

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

Return-path: <ldap-dir-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiV-0000Uq-Ux; Fri, 25 May 2007 10:24:31 -0400
Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1HraiV-0000RQ-59 for ldap-dir-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiT-0000Pt-2E; Fri, 25 May 2007 10:24:29 -0400
Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiR-0000vw-Nf; Fri, 25 May 2007 10:24:29 -0400
Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <RlbxmABlQCF0@rufus.isode.com>; Fri, 25 May 2007 15:24:25 +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: <D893844B-47EC-4973-A23A-64FB851DA5F1@Isode.com>
Content-Transfer-Encoding: 7bit
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
Date: Fri, 25 May 2007 07:24:19 -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: 0a7aa2e6e558383d84476dc338324fab
Cc: Ldapext <ldapext@ietf.org>, ldap-dir@ietf.org, apps-review@ietf.org
Subject: [Ldap-dir] Review of draft-wahl-ldap-subtree-source
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
Errors-To: ldap-dir-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.  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".


_______________________________________________
Ldap-dir mailing list
Ldap-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/ldap-dir