[Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8]

[Peter Gietz]

Oops, I forgot to include the list in my reply. Thanks Andrew to make me 
aware of this.

Cheers,

Peter

-------- Original Message --------
Subject: Re: [Ietf-not43] Re: Requirement 3.1.8
Date: Mon, 25 Aug 2003 14:58:05 +0200
From: Peter Gietz <Peter.Gietz at daasi.de>
Organization: DAASI International GmbH
To: Andrew Newton <anewton at ecotroph.net>
References: <3F3E5918.3000306 at ecotroph.net> 
<3F3FD067.5070902 at ehsco.com>	<3F40FB5D.7060806 at ecotroph.net> 
<3F413C1A.8060609 at ehsco.com>	<3F4145C3.4040706 at ecotroph.net> 
<3F417E94.5000603 at ehsco.com>	<p06001a01bb680d15d9b0@[129.46.227.161]> 
<3F429CAC.4080206 at ehsco.com> <3F435E55.7040705 at daasi.de> 
<3F436250.9000100 at ecotroph.net> <3F4373F7.3040608 at daasi.de> 
<3F437ECE.6020501 at ecotroph.net>



Andrew Newton wrote:

> Peter Gietz wrote:
> 
>>
>>> This is an interesting approach.  It would probably need to be worked 
>>> out more thoroughly on paper first.  However, you would also need to 
>>> include the qualifying matching rules and search scope.
>>
>>
>>
>> Why matching rules? Do you want to distinguish between string and 
>> substring search here?
>>
>> With scope I am not so sure either, since the policy should rule for 
>> whole subtrees. It shouldn't matter if the client makes basedn, 
>> onelevel or subtree searches, the access policy should be the same.
>>
>> I don't want to get this too complex. What might be added is the 
>> server side sizelimit (the maximum of entries a server will be willing 
>> to give back to the client), which should be one number for all naming 
>> contexts of the server.
> 
> 
> People will be attempting to mine data from these servers.  That is a 
> fact of life.  I know our service will not allow somebody to do a 
> subtree search in the contacts DIT.  For RLDAP, we excluded any partial 
> string matching if they didn't give use the first three letters of the 
> name (e.g. cn=*, cn=b*, and cn=bob*).  Therefore matching rules, search 
> filters, and scope will be allowed and disallowed depending on what the 
> person is attempting to do.

I still think that it is easier to prevent mining by a serverside size
limit than by specifying policy rules with parameters like scope and
matching rule. As I said, including such paramenters will make the
policy definition and interpretation quite complex. To get the
functionality of your example, we would notonly have to specify if
substringmatch is allowed and additionally the minimum length of the
substirng. The latter would have to be implemented as dedicated FIRS
feature since there i s no standard way of specifying substring length.

Is there another opinion on this in the group besides Andrew's and mine?


Cheers,

Peter

> 
> -andy
> 

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: peter.gietz at daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________