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

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