On 13 Apr 2004, at 18:00, Marco d'Itri wrote:
On Apr 13, Niall O'Reilly <niall.oreilly@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