Re: [db-wg] Action item 47.2: Proposal for Adding Abuse Contact
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)
This simple counting approach is potentially VERY misleading, as it is not the sheer _number_ of individual entries which should be counted, but the _size_ of the address blocks covered in this hierarchy. On top of that, there's the possibiltiy to use the hierarchy to e.g. provide a "1st-line" contact for an individual address block AND a fallback or upstream for the encompassing block. Marco, would it be reasonably easy for you to extract this additional piece of statistics data? Wilfried.
On 13 Apr 2004, at 17:23, Wilfried Woeber, UniVie/ACOnet wrote:
This simple counting approach is potentially VERY misleading,
Sure. That's why I took care to call it a starting point! 8-)
as it is not the sheer _number_ of individual entries which should be counted, but the _size_ of the address blocks covered in this hierarchy.
Fine. So ALL the numbers can be scaled down. Does the scaling affect the different methods I suggested (or others: I'm sure someone must have better concrete ideas?) differently, or similarly ?
On top of that, there's the possibiltiy to use the hierarchy to e.g. provide a "1st-line" contact for an individual address block AND a fallback or upstream for the encompassing block.
Again, does this skew the argument, or just scale everything down in proportion ? Best regards, Niall
On Tue, Apr 13, 2004 at 06:23:24PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
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)
This simple counting approach is potentially VERY misleading, as it is not the sheer _number_ of individual entries which should be counted, but the _size_ of the address blocks covered in this hierarchy.
On top of that, there's the possibiltiy to use the hierarchy to e.g. provide a "1st-line" contact for an individual address block AND a fallback or upstream for the encompassing block.
Marco, would it be reasonably easy for you to extract this additional piece of statistics data?
Sure, although it will probably take some time as I'm kinda busy these days. To be sure, last meeting I had the count on the number of inet(6)num objects having a mnt-irt and the number having a remarks: *abuse* attribute. The request is to extend this on the actual number of IP-addresses covered by both methods ? I will try to extend my script (grep | wc -l) a bit to get this info, hopefully during next weekend but at least in time for the next meeting. Grtx, MarcoH
LS, On 13 Apr 2004, at 17:23, Wilfried Woeber, UniVie/ACOnet wrote:
This simple counting approach is potentially VERY misleading, as it is not the sheer _number_ of individual entries which should be counted, but the _size_ of the address blocks covered in this hierarchy.
I'ld like to see or hear the argument behind this assertion. I can see that it is useful to be aware of what proportion of the address space is within the scope of some abuse contact or other. This gives us a sense of the scale of the problem, and the extent to which it is already solved. IMHO, we should count whatever will give us a measure of the amount of effort (work, energy) we need to exert to deal with the problem at hand. If we propose to intervene at the level of individual addresses, counting them will be useful. I suggest that a more realistic estimate of the effort involved will be based on intervention at a more aggregated level, and that we should count whatever the operations are which we need to make at that aggregated level. That's what I've tried to present, with a proposed method for estimating the effort involved. I haven't seen any serious counter-argument. By the way, I see an entry for "inetnum: 0.0.0.0 - 255.255.255.255". One "straw man" starting point, which gives a very attractive (but of course totally misleading) lower bound on the effort involved, is to choose to address the problem at this level of aggregation. By implementing the "abuse-mailbox" distinguished attribute, and updating just one database object, the problem would be solved! N'est-ce pas? 8-) Valete! Niall
participants (3)
-
MarcoH -
Niall O'Reilly -
Wilfried Woeber, UniVie/ACOnet