[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
- [Ldap-dir] Review of draft-wahl-ldap-subtree-sour… Kurt Zeilenga
- [Ldap-dir] Re: [ldapext] Review of draft-wahl-lda… Leif Johansson