Rodney, Nice diagram! It says part of something I wanted to say, but misses a particular detail, and so masks a significant saving in the effort involved in deploying additional contact data in the current database. I'm not sure whether you were thinking of deployment, or rather of development work on tools and server. I'm thinking of deployment as the major task. Besides filling in this detail, I'm suggesting how we might quantify this effort. MarcoH, You may already have real numbers to use in place of my assumptions. On 8 Apr 2004, at 15:27, Rodney Tillotson wrote:
The IRT route has an extra step. Instead of
any one of the following:
inet[6]num -> e-mail address[es] inet[6]num -> person/role (which must already be present as admin-c or tech-c) -> e-mail inet[6]num -> mntner (which may already be present as mnt-by) -> e-mail
they have to do inet[6]num -> IRT(if present) -> e-mail address[es]
and must create the IRT if it's not already present (which involves updating the inet[6]num to link it to the relevant IRT),
and tool-writers have to add extra code. They will understand that.
It would be interesting to quantify the deployment effort necesssary to reach the point where every inet[6]num is associated, either directly or via linked objects, with a distinguished attribute (eg: abuse-mailbox). As a starting point, let's take (approximations to) MarcoH's RIPE-47 statistics. Number of inet[6]num objects: 10**6 Number of inet[6]num objects with IRT: 10**3 (not significant) I'll assume that the minimal set of person/role/mntner objects required to cover all 10**6 inet[6]num objects is of the order of 10**5, to allow for multiple inet[6]num objects under common management. This assumption can be validated (and corrected if unjustified: I haven't done the analysis) from the existing contents of the database. I'll further assume that 10**5 IRT objects will likewise be sufficient to cover all 10**6 inet[6]num objects. This assumption cannot be validated on the basis of current information, it seems reasonable to treat the eventual IRT population on the same basis as the actual P/R/M population. I'll also assume that any required tool and server development and/or modification effort is negligible compared to that required to deploy whatever new data is needed. Now I look at some possible methods for deploying the desired information in the database. Method A: Provide every inet[6]num _directly_ with a distinguished attribute indicating the appropriate abuse contact: 10**6 update transactions on the inet[6]num objects Method B: Provide every inet[6]num with an appropriately configured IRT object: 10**6 - 10**3 ( ~ 10**6 ) update transactions on inet[6]num objects 10**5 - 10**3 ( ~ 10**5 ) _new_ IRT's to be created Method C: Provide an _existing_ contact object (person/role/mntner/IRT (even!)) of every inet[6]num object with a distinguished attribute indicating the appropriate abuse contact: 10**5 update transactions on _existing_ contact objects I understand why nobody likes method A. I think I hear people declaring a preference for method B over method C. I'm missing something here; who can help? MarcoH has explained the advantage of a distinguished attribute (abuse-mailbox or, as he originally suggested, just plain abuse) over a common attribute (specifically: e-mail) which takes on extra semantics in the particular context of belonging to an IRT object. I don't think I need to his excellent explanation. Best regards, Niall O'Reilly