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

[Shane Kerr]

David Blacka wrote:
> On Monday 25 August 2003 12:00 pm, Eric A. Hall wrote:
> 
>>on 8/25/2003 10:10 AM Eric A. Hall wrote:
>>
>>
>>>Mining-prevention is provided through a variety of mechanisms.
>>
>>BTW, the reason I've got an ARCH document separate from a CORE document 
> 
> is
> 
>>so that concepts can be described separately from the frobs. This is a
>>good example area, where the numerous frobs scattered throughout CORE can
>>lose their unity, and so should be discussed holistically in ARCH.
>>
>>As such, I've added the following text to ARCH to clarify the frobs that
>>are available in CORE.
>>
>>Are there any other frobs that any of the operators feels they need to
>>have, and which are missing from this list?
> 
> 
> Arbitrary maximum limits on the number of result objects for any given time 
> period for a particular client.
> 
> IMHO, this is the core of mining prevention, as it is actually directly 
> measuring the correct thing (response objects per unit time).
> 
> I think that it should be possible to count some result objects and not 
> others towards the limit.

We use this today, and would be sad to see this go.  For instance, users 
can query the database to determine if space has been allocated, but may 
not care to see contact information.  We only count contact information 
against our rate limits - you can get all the AS information you want from 
the database.  :)

-- 
Shane Kerr
RIPE NCC