NWI reviews: NWI-1 staying on top of abuse contact changes
Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG
Hi Denis, On Tue, Sep 22, 2020 at 1:51 PM ripedenis--- via anti-abuse-wg <anti-abuse-wg@ripe.net> wrote: [...]
Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact.
There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks.
Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise.
My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource.
Would this be useful, is it necessary or a waste of time? Please discuss....
Should I understand this as a proposal for a tool that is used to keep the registrant informed about changes related to resources for which they are responsible, or a tool to help other network operators and users find the right place to send an abuse report? Many thanks, Leo
Hi Leo I was proposing a tool to help the registrant manage their data. If you want to find the abuse contact you just query the resource and the abuse contact is returned. cheersdenis co-chair DB-WG On Tuesday, 22 September 2020, 23:13:02 CEST, Leo Vegoda <leo@vegoda.org> wrote: Hi Denis, On Tue, Sep 22, 2020 at 1:51 PM ripedenis--- via anti-abuse-wg <anti-abuse-wg@ripe.net> wrote: [...]
Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact.
There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks.
Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise.
My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource.
Would this be useful, is it necessary or a waste of time? Please discuss....
Should I understand this as a proposal for a tool that is used to keep the registrant informed about changes related to resources for which they are responsible, or a tool to help other network operators and users find the right place to send an abuse report? Many thanks, Leo
Hi Denis, On Tue, Sep 22, 2020 at 4:45 PM ripedenis@yahoo.co.uk <ripedenis@yahoo.co.uk> wrote:
Hi Leo
I was proposing a tool to help the registrant manage their data. If you want to find the abuse contact you just query the resource and the abuse contact is returned.
I have no objection to creating useful tools for people to use when managing their resources. That said, whenever the data structure is so complex that a special tool is needed to help people understand it, I wonder if the real problem is the data structure. Kind regards, Leo Vegoda
On Wed 23/Sep/2020 01:45:26 +0200 ripedenis--- via anti-abuse-wg wrote:
Hi Leo
I was proposing a tool to help the registrant manage their data. If you want to find the abuse contact you just query the resource and the abuse contact is returned.
I thought only ISPs had the right to manage their own abuse-c's. From the text below, I infer there are more ways to get the right data to the DB. For example, my ISP (Eutelia) went belly up between the change from abuse-mailbox to abuse-c. The one who took over (Clouditalia) never took care to point abuse-c to my abuse mailbox. Actually, they don't even reply to the email address currently pointed to (in CC). What are the extra methods which allow to carry out arrangements that the resource holder can overlook? Best Ale
cheers denis
co-chair DB-WG
On Tuesday, 22 September 2020, 23:13:02 CEST, Leo Vegoda <leo@vegoda.org> wrote:
Hi Denis,
On Tue, Sep 22, 2020 at 1:51 PM ripedenis--- via anti-abuse-wg <anti-abuse-wg@ripe.net <mailto:anti-abuse-wg@ripe.net>> wrote:
[...]
Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact.
There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks.
Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise.
My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource.
Would this be useful, is it necessary or a waste of time? Please discuss....
Should I understand this as a proposal for a tool that is used to keep the registrant informed about changes related to resources for which they are responsible, or a tool to help other network operators and users find the right place to send an abuse report?
Many thanks,
Leo
Colleagues We need to take some action on these old NWIs. Either we move forward with them or we cancel them. It is difficult to draw a consensus on 2 comments. Can you please give us a couple of minutes of your time and let us know if this NWI-1 is needed, useful or a waste of time. cheersdenis co-chair DB-WG ----- Forwarded message ----- From: ripedenis--- via anti-abuse-wg <anti-abuse-wg@ripe.net>To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net>Sent: Tuesday, 22 September 2020, 22:50:52 CESTSubject: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG
On Thu, Sep 24, 2020 at 12:30:06PM +0000, ripedenis--- via db-wg wrote: Denis, All,
We need to take some action on these old NWIs. Either we move forward with them or we cancel them. It is difficult to draw a consensus on 2 comments. Can you please give us a couple of minutes of your time and let us know if this NWI-1 is needed, useful or a waste of time.
I share the view already expressed. If we need a tool, maybe the problem is somewhere else. Best, Piotr -- Piotr Strzyżewski
participants (4)
-
Alessandro Vesely -
Leo Vegoda -
Piotr Strzyzewski -
ripedenis＠yahoo.co.uk