- anti-abuse-wg - mailman.ripe.net

Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552
by Suresh Ramasubramanian 02 Dec '20

02 Dec '20

I know him and trust him enough to have workable proposals. So, thank you very much for your opinion but I’m afraid I fail to share it. From: Elad Cohen <elad(a)netstyle.io> Date: Wednesday, 2 December 2020 at 8:38 PM To: Suresh Ramasubramanian <ops.lists(a)gmail.com>, Michele Neylon - Blacknight <michele(a)blacknight.com>, IP Abuse Research <ipabuseresearch(a)gmail.com>, Serge Droz <serge.droz(a)first.org> Cc: "anti-abuse-wg(a)ripe.net" <anti-abuse-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552 Mr. Michele have no proposals, all he can do is to complain. ________________________________ From: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> on behalf of Suresh Ramasubramanian <ops.lists(a)gmail.com> Sent: Wednesday, December 2, 2020 4:56 PM To: Michele Neylon - Blacknight <michele(a)blacknight.com>; IP Abuse Research <ipabuseresearch(a)gmail.com>; Serge Droz <serge.droz(a)first.org> Cc: anti-abuse-wg(a)ripe.net <anti-abuse-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552 Please feel free to come up with workable proposals then 😊 At leat that way the conversation stays operational From: Michele Neylon - Blacknight <michele(a)blacknight.com> Date: Wednesday, 2 December 2020 at 8:14 PM To: Suresh Ramasubramanian <ops.lists(a)gmail.com>, IP Abuse Research <ipabuseresearch(a)gmail.com>, Serge Droz <serge.droz(a)first.org> Cc: "anti-abuse-wg(a)ripe.net" <anti-abuse-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552 I don’t think it’s simply a matter of two sides, which your language attempts to categorise it as. Some of us refuse to have our processes and businesses dictated to by people who won’t listen to reasonable arguments against their unworkable proposals -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> on behalf of Suresh Ramasubramanian <ops.lists(a)gmail.com> Date: Wednesday 2 December 2020 at 14:06 To: IP Abuse Research <ipabuseresearch(a)gmail.com>, Serge Droz <serge.droz(a)first.org> Cc: "anti-abuse-wg(a)ripe.net" <anti-abuse-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552 +1 – most of the activity on this list has been people from the anti abuse community come up with suggestions that the RIPE regulars find unworkable, and then many people spend lots of time pointing out why the proposal is unworkable. So far I have not seen one case of a proposal coming in from the other side on what can be done instead to achieve the goals of the unworkable proposal, but have a chance of working under RIPE policies and procedures. From: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> on behalf of IP Abuse Research <ipabuseresearch(a)gmail.com> Date: Wednesday, 2 December 2020 at 7:25 PM To: Serge Droz <serge.droz(a)first.org> Cc: "anti-abuse-wg(a)ripe.net" <anti-abuse-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552 I'd like to second Serge's sentiment, RFG catches a good deal of abuse for his contributions, which we have all seen on this and other lists. What the continued findings indicate is a need for IANA and the RIRs to adapt to a new stage in the resource issuance and governance lifecycle. Since this is by definition a working group, would it make sense to establish some metrics to quantify the perceived impact of this phenomenon on abuse? If we establish a process to collect these observations of either "abandoned" resources, prefixes or ASNs, which then re-appear mysteriously or in the case of an ASN start routing space that is unexpectedly, "hijack", we can take a step as a community to quantify the phenomenon? Note: This is specifically not an internet policing function as much as a neighborhood watch effort to help inform the governing bodies / policy ... etc. Right now from responses it seems like defacto this weight has been put onto the shoulder of Spamhaus vs. having a working group work on a solution. If this is of interest I'm happy to write up a proposal and or work with the chairs to see if this is something that is seen as constructive. Also if this doesn't fit into the anti-abuse working group ... where does it fit? On Wed, Dec 2, 2020 at 3:12 AM Serge Droz via anti-abuse-wg <anti-abuse-wg(a)ripe.net<mailto:anti-abuse-wg@ripe.net>> wrote: First of: Congrats and thank you Ronald for this work. What makes me a bit sad is, that posting this here immediately starts a discussion about what is expected behavior on these lists, rather than how we could combat abuse more efficiently. It seems a seeminglu, to me at least, humorous remark, sparks more discussion than the troubling fact that criminals have the time of their lives during this period of time. I'm all in favor of staying civil on public fora. But noting in the original post was not civil. I am wondering what the we want to achieve here on the anti-abuse list? Call me stupid, but I just don't get it. Best Serge On 01.12.20 22:48, Ronald F. Guilmette wrote: > In message <DB7PR06MB501791137C12E71EA525C7DD94F40(a)DB7PR06MB5017.eurprd06.prod. > outlook.com<http://outlook.com>>, Brian Nisbet <brian.nisbet(a)heanet.ie<mailto:brian.nisbet@heanet.ie>> wrote: > >> However I suspect that X-posting to a list like apnic-talk may not be the >> wisest idea, given the different populations etc... > > It is among my fondest hopes that cybercriminals of all stripes, and > particularly the ones who squat on IPv4 space that doesn't belong to > them, will, in future, show more respect for regional boundaries, such > that their devious activities will only oblige me to notify the > members of a single one of the five RIR regions regarding any single > one of these elaborate criminal schemes. Alas, in this instance > however, the perpetrators, in a very unsportsmanlike manner, elected > to make messes whose roots were found in both the RIPE region and also > in the APNIC region. (And that's not even to mention that most of the > squatted IPv4 real estate was and is under the administration of the > ARIN region.) > > Clearly, authorities in all five regions should be devoting somewhat > more effort towards the cultivation of a better and more respectful > class of cybercriminals who will confine their convoluted schemes to > their own home regions. > > > Regards, > rfg > -- Dr. Serge Droz Chair of the FIRST Board of Directors https://www.first.org

1 0

AS55330 -- Routing oddities
by Ronald F. Guilmette 01 Dec '20

01 Dec '20

Some people seem to think that I'm sort of a master Internet sleuth. The truth is that I'm just as dumb as anybody else, and maybe even moreso. But if one spends enough time looking at stuff on the Internet, it really takes both very little time and also very little in the way of brains to notice many many inexplicable oddities. AS55330 is a case in point. This ASN was allocated/assigned to the Afghan government by APNIC, circa 2009-12-08. Given the nature of the registrant in this case, One might thus reasonably assume that this ASN, belonging as it does to a national government, would be one of the last ones that one would ever see as being involved in any kind of untoward hanky panky or funny business on the Internet. But despite that, I feel compelled to ask if anyone would like to take a stab at explaining to me why the Afghan national government's ASN would be announcing routes to IP blocks belonging to (a) a Chinese commercial enterprise (180.94.99.0/24) and also (b) several RIPE-issued IPv4 blocks that appear to be the property of some Airbus facility located in Norway (182.50.176.0/24, 182.50.177.0/24, 182.50.178.0/23, 182.50.180.0/22): https://bgp.he.net/AS55330#_prefixes I am not persuaded that Airbus/Norway's apparent reliance on the Afghan government to route their IPv4 space for them is an entirely sustainable business model, over the longer term. If I have misunderstood any of the data I'm looking at, then I do apologize to all parties concerned. Regards, rfg

1 0

Draft Anti-Abuse WG Minutes from RIPE 81
by Tobias Knecht 12 Nov '20

12 Nov '20

Hi there, Please see the draft minutes from our Anti-Abuse Working Group Session in 127.0.0.1. Please let us know about any objections or necessary corrections asap. Thanks and stay safe, Tobias Co-Chair, RIPE AA-WG -- | Tobias Knecht | CEO | Abusix, Inc. | tk(a)abusix.com | http://abusix.com | mobile_eu: +49 170 455 98 45 ----------------------------------------------------------------------- CONFIDENTIALITY This e-mail and any attachments are confidential and may also be privileged or otherwise protected from disclosure. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose, or store or copy the information in any medium. ----------------------------------------------------------------------

2 1

Re: [anti-abuse-wg] Appeal against the Anti-Abuse WG Co-chairs decisions on proposal 2019-04 (Validation of “abuse-mailbox”)
by JORDI PALET MARTINEZ 12 Nov '20

12 Nov '20

Hi Mirjam, See my responses below, in-line as many clarifications are clearly required, not just because this appeal, but because there is a misjudgment of the PDP itself. Regards, Jordi @jordipalet El 26/10/20 9:07, "Mirjam Kuehne" <mir(a)zu-hause.nl> escribió: Dear Jordi, Regarding the appeal you submitted on 5 October to the RIPE Anti-Abuse Working Group mailing list, I would like to inform you about the decision of the RIPE Working Group Chairs Collective (according to the procedure as defined in ripe-710). [Jordi] I don't think the PDP has been followed in full for this appeal. For example, there was not announcement of the publication of the appeal in the web site. The WG Chairs Collective (WGCC) decided to uphold the decision of the Co-Chairs of the Anti-Abuse Working Group. Please find below their detailed response. Kind regards, Mirjam Kühne RIPE Chair ======== Summary ======= The WGCC does not find sufficient reason to overturn the ruling of the Anti-Abuse WG chairs on proposal 2019-04 (Validation of "abuse-mailbox"). If Jordi wishes to bring a new proposal that he thinks may achieve consensus, we note that 2019-04 was being considered during an unusual time, when we have not had face-to-face meetings due to the COVID-19 pandemic. So it faced difficulties not normally facing a policy proposal. As always, the Anti-Abuse WG chairs may decide not to adopt any new proposal. [Jordi] Could you clarify this paragraph; I can't parse it. Scope ===== The WGCC considers the appeal process to be solely to determine if the working group chairs made a reasonable declaration of consensus or lack of consensus. The appeal process is able review whether the process was followed, or whether there was bias shown in the declaration. The appeal process will not re-visit any of the points for or against the proposal. [Jordi] Following the PDP, I can't agree with this. Can you clarify? Discussion ========== The appeal submitted includes several points that the WGCC found important to consider. These are discussed here. Points outside of the scope of the appeal process are omitted. RIPE NCC Impact Analysis ------------------------ The appeal will not review the accuracy of the RIPE NCC impact analysis. The WGCC defers to the expertise of the RIPE NCC staff who performed the analysis and the members of the Anti-Abuse WG who received the analysis. Further, an impact analysis is information intended to be helpful to decide whether to adopt a policy. The RIPE community is free to assign whatever weight it wishes. [Jordi] However, according to this, the co-chairs should also consider that the justification provided by the author against the objections is clearly demonstrating that the analysis impact is wrong in certain aspects, so those objections can't be accepted as valid. Discussion During the Review Phase ---------------------------------- The need to re-state opinions was explicitly mentioned in the e-mail moving the policy proposal to the review phase. It is unfortunate that the importance of this was not clear to Jordi. Possibly in the future this can be highlighted in some way. [Jordi] This is against the PDP. The chairs can even say I must sing a song, but the only valid process is the one CLEARLY STATED in the PDP. Nothing else. Otherwise there is a clear subjectivity in the process which invalidates it. Timing of Consensus Declaration ------------------------------- Jordi mentions several possible changes to the policy proposal which may have led to consensus. He suggests that the declaration of consensus was made too soon. We recognize that this is a bit of an odd time, due to COVID-19. This has removed one of our valuable tools, the face-to-face meetings. The already-tricky job of the working group chairs in the PDP has been made harder. We rely on the chairs of the WG involved to decide whether or not a proposal is likely to ever reach consensus. There are no guidelines given for this decision. We find that the Anti-Abuse WG chairs were reasonable in the timing of declaring that there is no consensus. Specific Points in Conclusion ----------------------------- The conclusion states: 1. It is not acceptable to declare lack of consensus and at the same time recognize that there was “some clear support for the policy during the Discussion Phase”. This is not true. Having support for a policy does not _necessarily_ mean there is consensus. [Jordi] Exactly the same that declaring no-consensus based on justifications that have been refuted by the author, is not acceptable. 2. It is not acceptable to, due to the lack of messages in the Review Phase, instead of extending it, considering the summer vacations period, declare lack of consensus. We find the judgment of the Anti-Abuse WG chairs to be reasonable in not extending the Review Phase. [Jordi] Based on what? Because this is even clearly against the text of the co-chairs decision. You also are recognizing across the text that the circumstances during the Covid are special, so how come then it should be acceptable not to extend the review phase considering the lack of responses, and the summer period in addition to the Covid itself? 3. It is not acceptable to accept repeated objections as valid when have been already refuted in a previous phase. The consensus declaration should defer to the community and what they consider valid. It appears to have done so in this case. [Jordi] Once more, lack of consensus can't be determined based on objections which are invalid as they have been reasonably refuted by the author and even other community members. 4. It is not acceptable to, considering the PDP (“The PDP is designed so that compromises can be made and genuine consensus achieved”), subjectively decide that “regardless of possible edits, reaching consensus in the short or medium term”, when there are possible ways to address the objections, which have anyway already being addressed. We find the judgment of the Anti-Abuse WG chairs to be reasonable in declaring a lack of consensus. [Jordi] This is unacceptable. If the discussion shows that changes to the proposal can bring a new version which may achieve consensus, then it should be allowed. We know that different proposals have taken different time and different number of versions to achieve consensus, so such decision about if a proposal can reach or not consensus, can't be based on a subjective decision. New Policy Proposal ------------------- In principle there is nothing to prevent Jordi or anyone else from submitting an updated version of 2019-04. However, in the Address Policy working group having submitted an unsuccessful policy proposal did prejudice the working group against accepting other submissions. So there is some possible concern that an updated version would have a more difficult time. There are many factors to balance when deciding what proposals to accept, and the work of balancing them is up to the working group chairs. So we do _not_ explicitly request that the Anti-Abuse working group chairs adopt any subsequent policy proposals. We _do_ ask that they give extra consideration to the unusual circumstances that we are attempting to make policies in. We do not have any recommendation to Jordi whether he or anyone else should submit an updated version of 2019-04. [Jordi] I can't parse this. It looks contradictory. Previous text seems that is ok to the co-chairs to reject a new version, but here it is clearly stated that anyone can do it? Are we talking about a new version of the same proposal or a new proposal? Working Group Chairs Excluded ============================== The working group chairs of the Anti-Abuse working group were not part of the discussions regarding the appeal. A number of other working group chairs recused themselves from the appeal. These were: * Erik Bais * Gert Doering * Denis Walker In addition, Mirjam Kühne and Niall O'Reilly recused themselves from discussion and writing of the appeal. Recommendation to All RIPE WG Chairs ==================================== We recommend that all RIPE WG Chairs provide extra help for all policy proposals while we are struggling to deal with lack of face-to-face contact. The form of this help will vary depending on the proposal. The rest of the WGCC is available to discuss any topics related to this if any WG chairs want additional feedback or ideas. This advice does not strictly fall within the scope of the appeal, but the appeal brought the issue to the attention of the WGCC. We consider it important to mention here. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

6 9

Post in RIPELABS blog on Internet standards deployment
by Wout de Natris 27 Oct '20

27 Oct '20

Dear colleagues, Following my request to you last summer, to participate in a questionnaire on the deployment of Internet standards and ICT best practices, I have written a post on the outcomes and the next steps to be taken in the DC-ISSS. You find the link to the post attached. The DC-ISSS is looking for experts interested to work with us on either of the three topics that have been given priority unanimously by those currently participating already: Procurement and business case; Education curricula; Security by design IoT. Please let me know should you have any questions or would like to know more. Those interested can join the DC-ISSS through the website of the Internet Governance Forum (IGF). Kind regards, Wout de Natris https://labs.ripe.net/Members/wout_de_natris/invitation-to-igf-dynamic-coal…

2 2

Appeal against the Anti-Abuse WG Co-chairs decisions on proposal 2019-04 (Validation of “abuse-mailbox”)
by JORDI PALET MARTINEZ 26 Oct '20

26 Oct '20

Hi all, This appeal (attached in PDF) follows the process outlined by ripe-710 (RIPE PDP). Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

7 8

Draft Agenda - Anti-Abuse WG @ RIPE 81
by Brian Nisbet 19 Oct '20

19 Oct '20

Colleagues, Here is the draft agenda for our session next week. It will take place via the RIPE 81 meeting platform at 10:00 CET/UTC +1 on Thursday 29th October. As mentioned, there is likely some time still available if anyone has anything they'd like to bring to the WG. Please note C.2. where the Co-Chairs would like to facilitate some open discussion on where the WG feels we might go in regards to abuse validation and other similar topics. A. Administrative Matters * Welcome * Scribe, Chat, Stenography * Chat Etiquette * Ratings Where Appropriate * Approve Minutes from RIPE 80 * Finalise agenda B. Update * B1. Recent List Discussion C. Policies - *C.1. Status of Policy Proposal 2019-04 - Validation of "abuse-mailbox" *C.2. Open discussion on abuse validation & next steps D. Interactions - E. Presentation - X. A.O.B. Z. Agenda for RIPE 82 Brian Co-Chair, RIPE AA-WG Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

Final-ish Call for Agenda Items: AA-WG @ RIPE81
by Brian Nisbet 14 Oct '20

14 Oct '20

Colleagues, The AA-WG will be meeting at RIPE81 on Thursday 29th October at 10:00 CET. We will be posting a draft agenda later this week, but we still have some time free, so if you would like to raise any items with the WG, please contact the Co-Chairs at aa-wg-chair(a)ripe.net Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

[db-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Hi Lutz Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses. I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects. When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer. I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time. Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon. cheersdenis co-chair DB-WG On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg <db-wg(a)ripe.net> wrote: > > 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. I support any proposal, that comes to the same result as the ripe whois database tool. It's not really hard to do correctly. #! /bin/sh getripe="whois -h whois.ripe.net --" $getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do $getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do $getripe -r $av | fgrep abuse-mailbox done done | tail -1 In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c". See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C

2 1

NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

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

4 6