[db-wg] Action item 47.2: Proposal for Adding Abuse Contact

On 13 Apr 2004, at 18:00, Marco d'Itri wrote:

> On Apr 13, Niall O'Reilly <niall.oreilly at ucd.ie> wrote:
>
>> Can you quantify what will still be required after taking advantage
>> of the kind of aggregation you suggest ?
> I think that a much better estimate is the number of ALLOCATED-BY-RIR
> (for inet6num), ALLOCATED PA and ASSIGNED PI (for inetnum) objects.
>
> After the top level objects will have a contact, detailed data can be
> added by customers and the need for this will be regulated by the usual
> ISP-customer relationships.
>

Fine.  You suggest a method for arriving at a better estimate of the
scope of the discussion.  I don't see that this changes the nature of
the argument.

Do you have a rough idea of what the new estimate is, numerically?

More specifically, the following questions arise.

Is the population of inet[6]num objects which are included in your 
improved
estimate closer to 10**6, 10**5, 10**4, or even 10**3?  Let's call the 
number,
(for the sake of originality) "N".

Of this population, how many already are associated with a person/role/
mntner/IRT object (PRMIO), and what is the minimal set of PRMIO's which 
will
cover the population? This will give a good estimate of how many 
existing
objects need to be updated with a DAIAC in order to cover the whole 
population
of interest.  Let's call this number "M".  I expect that M is 
significantly
less than N; it clearly can't be greater.

Now, we can cover all N inet[6]num objects within our scope by applying 
just
M updates to the related PRMIO's.  I believe that this is the lower 
bound on
the effort involved.  The data needed to drive the planning for this 
effort
is already in the database.

Another approach would be, to choose an IRT-only solution.  In this 
case,
we let "P" be the number of inet[6]num objects within our scope which 
require
a new IRT object, and "Q" the least number of such IRT objects needed 
to meet
these requirements.  It's useful to consider a factor "R" which 
represents the
inertial tendency against the creation of the new IRT objects.  This 
doesn't
directly represent extra effort, but rather delay in achieving results,
expressed in terms of effort-equivalent.  Ideally, R = 1;  in practice, 
R > 1.

To estimate the effort involved, we count:

	Q new IRT objects, and
	P updates to existing inet[6]num objects, in order to link the new 
IRT's,

and then reckon the total effort-equivalent as P + (R * Q).

The quantity, P is available from the existing database.  The set of 
new IRT
objects has to be chosen before the number Q is available.  However, Q 
cannot
be greater than P.

I suggest that the comparison of M with P+(R*Q) is a reasonable basis 
for
deciding which way to proceed, and that the following table shows how 
this
comparison should determine the actual decision.  Since neither Q or R 
is yet
available, I tentatively estimate Q * R = 1.5 * P.  I know this isn't 
"accurate";
I'm pretty sure it's not "outrageous" either.

	M < P:  			 PRMIO solution

	M > 2.5 * P: 		 IRT-only solution

	P < M < 2.5 * P:	 Further study

Best regards,

Niall O'Reilly