Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
Hello, This policy proposal seems a bit incomplete to, as it fails to address the problem statement from the summary.
From the summary: "...it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object.". What is supposed to happen to IRT objects, or data from them?
For existing records: at the very least it should be explicit which tags should no longer be used or would be deprecated / removed in order to give clear guidance. Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots? Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473
Gilles, On Thu, Nov 24, 2011 at 09:55:02AM +0100, Gilles Massen wrote:
This policy proposal seems a bit incomplete to, as it fails to address the problem statement from the summary.
thanks for pointing this out. There is a bit of confusion w.r.t. the target audience and intended goals. Let me give you my view. Any change we make to the DB schema or the Port 43 interface is unlikely to please the random end user who is looking for a target to report spam or other issues. Those are much better served by a service like the NCC's "abuse contact finder" tool, which in turn may benefit from a crisper data structure. But there is also a lot of (semi-)automated reporting going on between ISPs, CSIRTs and other entities, where timely detection, reporting and mitigation is crucial. Some of these use standardized message formats. Those are not well served by a web-based service or heuristics that may or may not end up with a "human" mailbox. And there's a range of grey between these examples.
From the summary: "...it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object.". What is supposed to happen to IRT objects, or data from them?
For existing records: at the very least it should be explicit which tags should no longer be used or would be deprecated / removed in order to give clear guidance.
Both questions would be addressed in a migration plan, but my reading is that "abuse-mailbox" is going to disappear.
Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots?
+1; -Peter (again, not speaking for the TF)
Peter Koch wrote:
Gilles,
On Thu, Nov 24, 2011 at 09:55:02AM +0100, Gilles Massen wrote:
This policy proposal seems a bit incomplete to, as it fails to address the problem statement from the summary.
thanks for pointing this out. There is a bit of confusion w.r.t. the target audience and intended goals. Let me give you my view. Any change we make to the DB schema or the Port 43 interface is unlikely to please the random end user who is looking for a target to report spam or other issues. Those are much better served by a service like the NCC's "abuse contact finder" tool, which in turn may benefit from a crisper data structure. But there is also a lot of (semi-)automated reporting going on between ISPs, CSIRTs and other entities, where
The proposal helps these kinds of automatic reporting a lot, simply because the field will not be mandatory anymore and there will be only one place to look. Furthermore: the amount of whois queries to the abuse-c cannot be restricted anymore. So: a bit +1 here from us.
timely detection, reporting and mitigation is crucial. Some of these use standardized message formats. Those are not well served by a web-based service or heuristics that may or may not end up with a "human" mailbox. And there's a range of grey between these examples.
From the summary: "...it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object.". What is supposed to happen to IRT objects, or data from them?
For existing records: at the very least it should be explicit which tags should no longer be used or would be deprecated / removed in order to give clear guidance.
Both questions would be addressed in a migration plan, but my reading is that "abuse-mailbox" is going to disappear.
A "migration plan" cannot be located in a proposal, because it heavily depends on the work of the RIPE NCC and a plan include dates (to my understanding) wich shouldnt end up in a proposal. But a "migration outlook/idea" would be a really good idea to have in the proposal.
Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots?
+1;
Having two contacts might complicates things, it might be complicated for the end user to decide wich one to contact. Maybe it would be easier to make one contact wich has to be marked as "person", "role" or "robot". Both, end user or automatic reporting tools, could then decide themself, if the type of the contact fits their intention. It might also be nice to have a "preferred reporting method" field included, what could be "email, phone, url, ARF, X-ARF" or similar. Kind regards, Frank
-Peter (again, not speaking for the TF)
-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
On Tue, Nov 29, 2011 at 09:19:31AM +0100, Frank Gadegast wrote: Hi,
A "migration plan" cannot be located in a proposal, because it heavily depends on the work of the RIPE NCC and a plan include dates (to my understanding) wich shouldnt end up in a proposal.
Lets say order the relevant technical processes should be included in this proposal (Some might call this a plan).
Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots?
+1;
Having two contacts might complicates things, it might be complicated for the end user to decide wich one to contact.
Maybe it would be easier to make one contact wich has to be marked as "person", "role" or "robot". Both, end user or automatic reporting tools, could then decide themself, if the type of the contact fits their intention. It might also be nice to have a "preferred reporting method" field included, what could be "email, phone, url, ARF, X-ARF" or similar.
What if the people or robots reporting to such an address, don't care about robot vs. human mailboxes and/or relevant reporting formats (or are reporting bogus due to bugs)? I would suggest, that every team/member/robot behind such an address should figure that for themselves. Cheers, Adrian
Adrian wrote:
On Tue, Nov 29, 2011 at 09:19:31AM +0100, Frank Gadegast wrote:
Hi,
Hi,
A "migration plan" cannot be located in a proposal, because it heavily depends on the work of the RIPE NCC and a plan include dates (to my understanding) wich shouldnt end up in a proposal.
Lets say order the relevant technical processes should be included in this proposal (Some might call this a plan).
Agreed.
Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots?
+1;
Having two contacts might complicates things, it might be complicated for the end user to decide wich one to contact.
Maybe it would be easier to make one contact wich has to be marked as "person", "role" or "robot". Both, end user or automatic reporting tools, could then decide themself, if the type of the contact fits their intention. It might also be nice to have a "preferred reporting method" field included, what could be "email, phone, url, ARF, X-ARF" or similar.
What if the people or robots reporting to such an address, don't care about robot vs. human mailboxes and/or relevant reporting formats (or are reporting bogus due to bugs)? I would suggest, that every team/member/robot behind such an address should figure that for themselves.
Also agreed, I recommend a "preferred" reporting method field, what should improve the reporting accuracy (we often receive emails back, wich simply includes a link to an online form, this could be shorted, when the URL is already included in the field). Surely its not 100%. Kind regards, Frank
Cheers, Adrian
-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Hi,
Lets say order the relevant technical processes should be included in this proposal (Some might call this a plan).
I will ask RIPE NCC to join this discussion since I can not talk about implementation in behalf of RIPE NCC. In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database? Policy is policy and implemetation details are implementation details. I agree that RIPE NCC should publish their ideas, but not put it into the proposal text. And an example at the end. If we agree that we have to be in London on 10th of December. We agreed on that. If RIPE NCC tells us to walk and swim, we can say "No way!" and ask them if we could fly, but we do not disagree about being in London. I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things).
Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots?
+1;
Having two contacts might complicates things, it might be complicated for the end user to decide wich one to contact.
No. End users should not take the way of whois. They should use the abuse finder tool. This tool will give them exactly what they need.
Maybe it would be easier to make one contact wich has to be marked as "person", "role" or "robot". Both, end user or automatic reporting tools, could then decide themself, if the type of the contact fits their intention. It might also be nice to have a "preferred reporting method" field included, what could be "email, phone, url, ARF, X-ARF" or similar.
This will make things much more complicated. I agree and we had a discussion about this in the Task Force as well, that a url may be an option as well. On the other hand, parsing email in a standard format is not that difficult and in the abuse community offering a form to report abuse is most likely seen as a "Fuck off!" to the reporter. The idea behind abuse-mailbox and e-mail attribute is the following: The email attribute can be personal information, so you do not want to publish it unrestricted. The information in the abuse-mailbox attribute will be not personal information and can be queried unrestrictedly. If you have no need for a differentiation between those, take the same address for both. That would be absolutely fine.
What if the people or robots reporting to such an address, don't care about robot vs. human mailboxes and/or relevant reporting formats (or are reporting bogus due to bugs)? I would suggest, that every team/member/robot behind such an address should figure that for themselves.
There is a second reason for differentiation. Spam filters on abuse addresses do not make a lot of sense. But spam filters on a team addresses read by humans do make a lot of sense. What if a bot does not care. He will take care, because if he sends the reports to the personal address they will get lost, because the spam filter will take care of them. I'm against every team/member/robot should figure that out themselves. That is exactly the situation at the moment with loads of opportunities. Receiving all kinds of robot reports on one mailbox (abuse-mailbox) is already best practice today. So this is nothing new. A last reason why I would not split up things to far. I want to avoid adding to much opportunities at once. I think there is not reason not to add Jabber/IRC/XMP-PRC/whatever as a new attribute as soon as it shows up and is widely used. At the moment mail is the most common way of exchanging reports about abusive behavior. So that is why I would suggest to stay with email and see if something really new comes up. Thanks, Tobias -- abusix
On Tue, Nov 29, 2011 at 12:24:10PM +0100, Tobias Knecht wrote: Hi,
In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database?
I am aware of that. I think It would be fine for everyone, if the proposal contains a reference to a document which defines this.
I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things).
Yet, it should be defined to make sure everybody _is_ in London on Dec. 10.
I'm against every team/member/robot should figure that out themselves.
So you are proposing a kind of "one-size-fits-all" on how to process data internally. I am curious if this works. Cheers, Adrian
Hi,
In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database?
I am aware of that. I think It would be fine for everyone, if the proposal contains a reference to a document which defines this.
I already asked RIPE NCC folks to join the discussion and come up with the implementation details and the operational details on how things are handled if data is inaccurate.
I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things).
Yet, it should be defined to make sure everybody _is_ in London on Dec. 10.
I guess we agree on that. ;-) Additional paper would make sense.
I'm against every team/member/robot should figure that out themselves.
So you are proposing a kind of "one-size-fits-all" on how to process data internally. I am curious if this works.
We are talking about formats that are intended to be machine readable (arf, xarf, IODEF). Every single of the todays official formats can be parsed full automatic. Even not "official" formats like spamcop or others can be parsed automatically. Things that can not be parsed automatically can be forwarded to an internal mailbox and can be manually reviewed. My experience tells me that more than 98% of the incoming reports are within the top 10 fully automatic parsable formats and only 2% of the incoming traffic has to be reviews manually. This whole routing process takes less than an hour to be implemented in procmail. But that would go to far into another interesting discussion. If you are interested in that we can go on off list. Thanks, Tobias -- abusix
HI Tobias and others As requested we will prepare a document on a technical implementation, as discussed by the Task Force, for your proposed policy. We expect to be able to publish this tomorrow. Regards Denis Walker Business Analyst RIPE NCC Database Group On 29/11/11:49 12:54 PM, Tobias Knecht wrote:
Hi,
In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database?
I am aware of that. I think It would be fine for everyone, if the proposal contains a reference to a document which defines this.
I already asked RIPE NCC folks to join the discussion and come up with the implementation details and the operational details on how things are handled if data is inaccurate.
I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things).
Yet, it should be defined to make sure everybody _is_ in London on Dec. 10.
I guess we agree on that. ;-) Additional paper would make sense.
I'm against every team/member/robot should figure that out themselves.
So you are proposing a kind of "one-size-fits-all" on how to process data internally. I am curious if this works.
We are talking about formats that are intended to be machine readable (arf, xarf, IODEF). Every single of the todays official formats can be parsed full automatic. Even not "official" formats like spamcop or others can be parsed automatically. Things that can not be parsed automatically can be forwarded to an internal mailbox and can be manually reviewed. My experience tells me that more than 98% of the incoming reports are within the top 10 fully automatic parsable formats and only 2% of the incoming traffic has to be reviews manually.
This whole routing process takes less than an hour to be implemented in procmail.
But that would go to far into another interesting discussion. If you are interested in that we can go on off list.
Thanks,
Tobias
Hi Denis, thank you very much! Looking forward the document. Thanks, Tobias -- abusix Am 29.11.11 16:35, schrieb Denis Walker:
HI Tobias and others
As requested we will prepare a document on a technical implementation, as discussed by the Task Force, for your proposed policy. We expect to be able to publish this tomorrow.
Regards Denis Walker Business Analyst RIPE NCC Database Group
On 29/11/11:49 12:54 PM, Tobias Knecht wrote:
Hi,
In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database?
I am aware of that. I think It would be fine for everyone, if the proposal contains a reference to a document which defines this.
I already asked RIPE NCC folks to join the discussion and come up with the implementation details and the operational details on how things are handled if data is inaccurate.
I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things).
Yet, it should be defined to make sure everybody _is_ in London on Dec. 10.
I guess we agree on that. ;-) Additional paper would make sense.
I'm against every team/member/robot should figure that out themselves.
So you are proposing a kind of "one-size-fits-all" on how to process data internally. I am curious if this works.
We are talking about formats that are intended to be machine readable (arf, xarf, IODEF). Every single of the todays official formats can be parsed full automatic. Even not "official" formats like spamcop or others can be parsed automatically. Things that can not be parsed automatically can be forwarded to an internal mailbox and can be manually reviewed. My experience tells me that more than 98% of the incoming reports are within the top 10 fully automatic parsable formats and only 2% of the incoming traffic has to be reviews manually.
This whole routing process takes less than an hour to be implemented in procmail.
But that would go to far into another interesting discussion. If you are interested in that we can go on off list.
Thanks,
Tobias
Dear Tobias and others The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object. https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database Regards Denis Walker Business Analyst RIPE NCC Database Group On 29/11/11:49 4:49 PM, Tobias Knecht wrote:
Hi Denis,
thank you very much! Looking forward the document.
Thanks,
Tobias
Thanks to Denis and RIPE NCC to come up with this view of the planned implementation. Thanks, Tobias -- abusix Am 30.11.11 16:25, schrieb Denis Walker:
Dear Tobias and others
The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object.
https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
Regards Denis Walker Business Analyst RIPE NCC Database Group
On 29/11/11:49 4:49 PM, Tobias Knecht wrote:
Hi Denis,
thank you very much! Looking forward the document.
Thanks,
Tobias
Tobias Knecht <tk@abusix.com> writes:
From a first reading, it seems an elegant approach.
Regards, Kostas
Thanks to Denis and RIPE NCC to come up with this view of the planned implementation.
Thanks,
Tobias
-- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
Hi,
From a first reading, it seems an elegant approach.
The most elegant part is, that the next step will be easier. The data accuracy part needs to handle only one type of object and not different ones. That will make the data accuracy part imho easier. So this proposal is imho just a very first step down the road of more data accuracy and some other ideas. I hope with this explanation it gets clearer why we wanted to keep this proposal very lean. As Denis said, we had to step back. Thanks, Tobias -- abusix
Hi Tobias, On Dec 1, 2011, at 5:28 am, Tobias Knecht wrote: […]
The most elegant part is, that the next step will be easier.
I think this is a problematic statement. It implies that this is the first step on a road towards a destination we have not yet been informed about. At the very least, it would have been courteous to publish a roadmap document prior to publishing the policy proposal, so that participants in the WG can review it in the context you intend it to have. I have no problem with improving the abuse reporting system but from my perspective, adding way to embed e-mail addresses in the database is not going to help significantly. The people who want abuse reports to so they can correct issues with their networks already have ways to publish that information and the people who don't want to deal with reports will either not use the proposed abuse-c objects or will populate them with broken data. New ways of putting information into the database will not fix abuse report handling. Unless you share your broader vision for how abuse report handling will improve, all this proposal does is add cost to RIPE NCC members and confusion to naive database users. Regards, Leo
Hi Leo,
The most elegant part is, that the next step will be easier.
I think this is a problematic statement. It implies that this is the first step on a road towards a destination we have not yet been informed about. At the very least, it would have been courteous to publish a roadmap document prior to publishing the policy proposal, so that participants in the WG can review it in the context you intend it to have.
I do not have a roadmap, but community has. And community asks over and over again what could be done about data accuracy. If community wants the Task Force to take care of this as well, the Task Force will be happy to do so. But if the community does not want the Task Force to take care of it, we will not do it. Maybe somebody else will come up with an idea, as I already did a few month ago with a proposal which I have withdrawn to get things sorted out in the Task Force. Sorry if this sounded like we are already having a masterplan in the pockets and we are not willed to share with you, that is not the case. But it is the case that we are listening to the discussions on the mailinglist and the meetings and wanted to make things more clean and clear for whomever will come up with and idea about improving data accuracy.
I have no problem with improving the abuse reporting system but from my perspective, adding way to embed e-mail addresses in the database is not going to help significantly. The people who want abuse reports to so they can correct issues with their networks already have ways to publish that information and the people who don't want to deal with reports will either not use the proposed abuse-c objects or will populate them with broken data.
This proposal is not only about putting something into DB as it was done by APNIC and will hopefully be done by AfriNIC soon. In both these regions there was no possibility to add abuse contact information. In the RIPE region the point is that we have to many options and womtimes these options break things. And the main point of the Task Force was, to come up with a solution that fixes the variety we have at the moment and find "the place" to store abuse-contact information. And that is exactly what we did.
New ways of putting information into the database will not fix abuse report handling. Unless you share your broader vision for how abuse report handling will improve, all this proposal does is add cost to RIPE NCC members and confusion to naive database users.
And again this has never been the intention of this proposal. Such a proposal will never fix abuse report handling. Because handling incoming abuse reports is the business of every single ISP and not of RIPE NCC or RIPE as a community. The intention is to make it easier and clearer to publish and find the relevant things and maybe in a next step if community wants us to take care of focus on data accuracy. I do not see that this will make things more complicated to naive users. Imho the opposite is the case. The naive user should use the abuse finder tool which is already in place and would run much easier than today (150 db queries to get one single email address is just crazy). The naive user has to learn how to add abuse contact information in either way (old style or new style). And I as a naive user would rather know exactly what I have to do than thinking about what might be the right place to add information. I have no idea about the costs of this and I'm not sure if this is a relevant factor to decide if a proposal is good or not. Thanks for your feedback, Tobias -- abusix
Hi Tobias, You wrote:
The intention is to make it easier and clearer to publish and find the relevant things and maybe in a next step if community wants us to take care of focus on data accuracy.
Please don't add yet more data and then start thinking about the possibility of looking at data accuracy. Do it the other way around. There are already plenty of ways to publish abuse reporting data and adding another is not going to improve it. As sending reports to the wrong address is a wasted effort please don't make things worse by introducing requirements for new data to be published against the will of the people being forced to publish it. That will only make the overall dataset less useful.
I do not see that this will make things more complicated to naive users. Imho the opposite is the case.
Of course it will. The template will say that things are optional while the business rules say they are not.
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign... The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie. The scale of the problem requires large scale sampling and statistical analysis rather than individual reports. By all means work on the abuse issue but please approach it from the perspective of solving the abuse rather than adding a new, larger and more polluted set of addresses for reporting abuse. At a minimum, the proposal should include a policy for maintaining data quality and migrating from the existing dataset. Regards, Leo
On Thu, Dec 01, 2011 at 07:27:28AM -0800, Leo Vegoda wrote: hi,
Please don't add yet more data and then start thinking about the possibility of looking at data accuracy. Do it the other way around. There are already plenty of ways to publish abuse reporting data and adding another is not going to improve it.
By all means work on the abuse issue but please approach it from the perspective of solving the abuse rather than adding a new, larger and more polluted set of addresses for reporting abuse. At a minimum, the proposal should include a policy for maintaining data quality and migrating from the existing dataset.
100% agree on that. Cheers, Adrian
Leo Vegoda <leo.vegoda@icann.org> writes:
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie. The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
This is true, but imagine the reporting function be handled automatically by machines and the counter-measures enforced near real-time by interested and cooperatings ISPs (again using automation). This might make the situation a bit better than today. Also parties that don't care or cooperate can be more easily identified. I think we should not leave the situation as-is. Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
Hi Kostas, You wrote:
This is true, but imagine the reporting function be handled automatically by machines and the counter-measures enforced near real-time by interested and cooperatings ISPs (again using automation). This might make the situation a bit better than today. Also parties that don't care or cooperate can be more easily identified.
It would only be able to identify someone who did not care after sending them a report. Why not allow the publication of abuse contact details to remain optional and know that someone does not care about abuse reports before wasting cycles in contacting them? There is nothing wrong with standardising the publication mechanism to aid automation but enforcing it on people who would prefer to be uncooperative just means a lot of wasted effort.
I think we should not leave the situation as-is.
I don't believe anyone has suggested that things should not change and improve. I am suggesting that directionless, piecemeal changes are a bad idea and that any changes should be part of an overall plan that has received the consensus of the community before any single change is implemented. At a minimum, a plan needs to address the migration plan for automatically converting old abuse contact data to the new format and a systematic programme for maintaining data quality. If there are any implications for address allocation policy, such as reclaiming address space in certain circumstances, those should be spelled out explicitly and receive the consensus of the Address Policy WG. Regards, Leo
Hi,
Please don't add yet more data and then start thinking about the possibility of looking at data accuracy. Do it the other way around.
So what is accurate at the moment? Remarks? IRT? abuse-mailbox? It does not make any sense looking at a "broken" structure and try to figure out what we can get out of it. Cleaning up and look at the cleaned structure makes much more sense. We do not add more data. That is absolutely not true. We are reorganizing the data in a way that there is no need for abuse contacts in remark fields and the abuse-mailbox attribute is handled in a different way. The only thing we add is a completely and easy to understandable point of reference. But the data behind the abuse-c can be the same data that is already there. It is just structured differently.
There are already plenty of ways to publish abuse reporting data and adding another is not going to improve it.
And that is the point we want to change. We do not want to have plenty half baked ways. We want to have one good one.
As sending reports to the wrong address is a wasted effort please don't make things worse by introducing requirements for new data to be published against the will of the people being forced to publish it. That will only make the overall dataset less useful.
We are not doing what you are saying. Today it would be good enough to add an abuse-mailbox attribute. Right? That is exactly what you are saying. That is what is already existing and we should stay with it. Right? So what would be needed to do after this proposal would be in place. If there is somebody with a role that does not contain an abuse-mailbox attribute he would have to add an abuse-mailbox attribute and say lets take this role as abuse-c. The only difference would be that the output would tell everybody that it is an abuse-c and not any object somewhere in the middle of "I do not know" that contains an abuse-mailbox attribute. So where is the part with forcing people to add more data? In the very end we are not even forcing members to do so. The only members that have to add an abuse-c are the direct allocated ranges. Not even the sub delegations. That means we are not forcing more people to add data, we are at the end force less people to add data than we do today.
Of course it will. The template will say that things are optional while the business rules say they are not.
If you want to use the object as an abuse-c it has to have an abuse-mailbox attribute, otherwise not. Is that really making things more complicated than they are today?
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
Let me rephrase it: The naive user should use the abuse finder tool _if he wants_ and does not agree to RIPE NCC's answer in the abuse FAQ. Otherwise, if he agrees to RIPE NCC's answer in the abuse FAQ and does not want to do anything, which is absolutely fine, he can be ignored, because he will not be a user of this system and by that means this proposal does not touch him in any way.
By all means work on the abuse issue but please approach it from the perspective of solving the abuse rather than adding a new, larger and more polluted set of addresses for reporting abuse. At a minimum, the proposal should include a policy for maintaining data quality and migrating from the existing dataset.
As already mentioned, the community seems to want a solution to the data accuracy problem. But I do not want to mix things up. We are talking here about an abuse-c, which will be than 1 of 4 -c's in the whois database (without counting the IRT). Data accuracy is a problem of all 4 (and the IRT object) of them. I will not try to fix a small part of the problem now and start over again to fix the general problem. The migration is mentioned but is not explained in detail because of the lack of an impact analysis. On of the main parts of the this proposal is cleaning up the existing situation. So I'm sure RIPE NCC will do everything that can be done to clean up as much as possible. 2 last questions: Do you agree that the data accuracy is a problem in the WHOIS DB? Do you think the Task Force should take care of this issue as soon as possible? Thanks, Tobias -- abusix
All, some of the replies to spam FAQs are bad. FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently On 01/Dec/11 16:27, Leo Vegoda wrote:
Hi Tobias, You wrote:
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads: Should I just ignore spam? Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5. I propose the following replacement text: Should I just ignore spam? Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically. Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?" Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time. Does everyone agree with the replacement text for FAQ#2?
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie.
Agreed.
The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry.
It is a FAQ, not an advocacy portal. Simply link to the MAAWG best practices document - there's several available for providers, end users etc. Tryign to define spam and write faqs on spam ends up as a hair splitting discussion, so I'd rather not have it here or reinvent multiple of maawg's wheels. thank you srs On Mon, Dec 12, 2011 at 4:14 PM, Alessandro Vesely <vesely@tana.it> wrote:
All, some of the replies to spam FAQs are bad.
FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently
On 01/Dec/11 16:27, Leo Vegoda wrote:
Hi Tobias, You wrote:
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads:
Should I just ignore spam?
Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5.
I propose the following replacement text:
Should I just ignore spam?
Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically.
Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?"
Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time.
Does everyone agree with the replacement text for FAQ#2?
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie.
Agreed.
The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
+1 On 12 Dec 2011, at 09:47, Suresh Ramasubramanian wrote:
It is a FAQ, not an advocacy portal.
Simply link to the MAAWG best practices document - there's several available for providers, end users etc.
Tryign to define spam and write faqs on spam ends up as a hair splitting discussion, so I'd rather not have it here or reinvent multiple of maawg's wheels.
thank you srs
On Mon, Dec 12, 2011 at 4:14 PM, Alessandro Vesely <vesely@tana.it> wrote:
All, some of the replies to spam FAQs are bad.
FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently
On 01/Dec/11 16:27, Leo Vegoda wrote:
Hi Tobias, You wrote:
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads:
Should I just ignore spam?
Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5.
I propose the following replacement text:
Should I just ignore spam?
Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically.
Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?"
Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time.
Does everyone agree with the replacement text for FAQ#2?
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie.
Agreed.
The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
That would be fine too. It's far better not to have a "Hacking & Spamming" section [1] in the FAQ than having wrong entries. Is it possible to remove it? [1] http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming thanks On 12/Dec/11 16:14, Michele Neylon :: Blacknight wrote:
+1
On 12 Dec 2011, at 09:47, Suresh Ramasubramanian wrote:
It is a FAQ, not an advocacy portal.
Simply link to the MAAWG best practices document - there's several available for providers, end users etc.
Tryign to define spam and write faqs on spam ends up as a hair splitting discussion, so I'd rather not have it here or reinvent multiple of maawg's wheels.
thank you srs
On Mon, Dec 12, 2011 at 4:14 PM, Alessandro Vesely <vesely@tana.it> wrote:
All, some of the replies to spam FAQs are bad.
FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently
On 01/Dec/11 16:27, Leo Vegoda wrote:
Hi Tobias, You wrote:
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads:
Should I just ignore spam?
Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5.
I propose the following replacement text:
Should I just ignore spam?
Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically.
Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?"
Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time.
Does everyone agree with the replacement text for FAQ#2?
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie.
Agreed.
The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Instead of all that I'd focus on this little nugget from the faq. Which was, is and will remain central to why this wg was set up in the first place. ________ Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on? → The records in the Regional Internet Registries' (RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records. On Mon, Dec 12, 2011 at 10:09 PM, Alessandro Vesely <vesely@tana.it> wrote:
That would be fine too. It's far better not to have a "Hacking & Spamming" section [1] in the FAQ than having wrong entries. Is it possible to remove it?
[1] http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming
Yes, FAQ#6 is to be removed as well. On 12/Dec/11 17:49, Suresh Ramasubramanian wrote:
Instead of all that I'd focus on this little nugget from the faq. Which was, is and will remain central to why this wg was set up in the first place.
________
Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on? →
The records in the Regional Internet Registries' (RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records.
On Mon, Dec 12, 2011 at 10:09 PM, Alessandro Vesely <vesely@tana.it> wrote:
That would be fine too. It's far better not to have a "Hacking & Spamming" section [1] in the FAQ than having wrong entries. Is it possible to remove it?
[1] http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg- bounces@ripe.net] On Behalf Of Suresh Ramasubramanian Sent: Monday, December 12, 2011 4:47 PM To: Alessandro Vesely Cc: anti-abuse-wg@ripe.net
It is a FAQ, not an advocacy portal.
Simply link to the MAAWG best practices document - there's several available for providers, end users etc.
Linking to MAAWG could also be viewed as a form of advocacy, and the interests of RIPE may not be entirely aligned with those of MAAWG. As an example, Yahoo is a MAAWG member at the highest level of influence ('Sponsor', which includes a seat on the MAAWG Board of Directors), but decade after decade, Yahoo inflicts enormous amounts of spam on the RIPE community and other Internet users. Other MAAWG members with reputations for spam and/or spam support include Amazon and Constant Contact. I would prefer for RIPE to produce its own information on spam and other forms of abuse of the network, as needed. -- Thor Kottelin http://www.anta.net/
MAAWG is not an advocacy or lobbying organization. It is an organization that advocates best practices. "Reps for spam or spam support" and constant contact .. jesus, you don't know too much do you? As for yahoo - or gmail or any of the other large free services out there, they can deter spammers from signing up. And they can spam filter their outbound email. But I seriously doubt they, or anybody else, is going to catch 100% of the spam. They just happen to have like several million users more than you do, so the volume of spam (as opposed to the percentage of spam) is higher. As for the interests of RIPE not being "aligned" with MAAWG .. I'll see your spam from amazon and constant contact and raise you a big bunch of fake romanian and eastern european LIRs, assigned PA/PI netblocks given to botmasters, "we are not the * police" memes etc. --srs On Mon, Dec 12, 2011 at 8:59 PM, Thor Kottelin <thor.kottelin@turvasana.com> wrote:
Linking to MAAWG could also be viewed as a form of advocacy, and the interests of RIPE may not be entirely aligned with those of MAAWG.
As an example, Yahoo is a MAAWG member at the highest level of influence ('Sponsor', which includes a seat on the MAAWG Board of Directors), but decade after decade, Yahoo inflicts enormous amounts of spam on the RIPE community and other Internet users. Other MAAWG members with reputations for spam and/or spam support include Amazon and Constant Contact.
I would prefer for RIPE to produce its own information on spam and other forms of abuse of the network, as needed.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Monday 12 December 2011 17.14, Suresh Ramasubramanian wrote:
MAAWG is not an advocacy or lobbying organization. It is an organization that advocates best practices.
"Reps for spam or spam support" and constant contact .. jesus, you don't know too much do you?
Yahoo in one of the major sources of "ISP-based spam. The majority however comes from stolen windoze (home)computers. <snip> -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. )
And that'd be just how much as a percentage of the legitimate mail you get from their IP space? Note - please have data points that are based on a more substantial number of users than say "corporate exchange server" or "personal linux box" On Mon, Dec 12, 2011 at 10:30 PM, peter h <peter@hk.ipsec.se> wrote:
Yahoo in one of the major sources of "ISP-based spam. The majority however comes from stolen windoze (home)computers.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Monday 12 December 2011 18.26, Suresh Ramasubramanian wrote:
And that'd be just how much as a percentage of the legitimate mail you get from their IP space?
100% It's years ago since i had any mail conversation with a yahoo-customer. But i still get spam from various yahoo-ranges, none of them related to former contacts. It's simply a lazy policy that allows abuse of their resources. I can mention gmail as a site with excellent spam policy. Anyone trying to send spam through gmail will be "killed" fast. So it's not impossible to block spammers, but it takes some resources and comittment to do so.
Note - please have data points that are based on a more substantial number of users than say "corporate exchange server" or "personal linux box"
On Mon, Dec 12, 2011 at 10:30 PM, peter h <peter@hk.ipsec.se> wrote:
Yahoo in one of the major sources of "ISP-based spam. The majority however comes from stolen windoze (home)computers.
-- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. )
No no... let's not confine conversation to one mailbox, or one small personal domain. Please. If you run a large enough mail system, you'll see quite a lot of spam issues on gmail as well (google groups and other google properties too, just as you'd see distinct yahoo properties such as yahoogroups have their own abuse volumes, challenges etc) On Mon, Dec 12, 2011 at 11:24 PM, peter h <peter@hk.ipsec.se> wrote:
It's years ago since i had any mail conversation with a yahoo-customer. But i still get spam from various yahoo-ranges, none of them related to former contacts. It's simply a lazy policy that allows abuse of their resources.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
and s/gmail/any other provider/ and my statement below would still apply. I'm not picking on gmail or yahoo here. On Mon, Dec 12, 2011 at 11:41 PM, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
No no... let's not confine conversation to one mailbox, or one small personal domain. Please.
If you run a large enough mail system, you'll see quite a lot of spam issues on gmail as well (google groups and other google properties too, just as you'd see distinct yahoo properties such as yahoogroups have their own abuse volumes, challenges etc)
On Mon, Dec 12, 2011 at 11:24 PM, peter h <peter@hk.ipsec.se> wrote:
It's years ago since i had any mail conversation with a yahoo-customer. But i still get spam from various yahoo-ranges, none of them related to former contacts. It's simply a lazy policy that allows abuse of their resources.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
-- Suresh Ramasubramanian (ops.lists@gmail.com)
-----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: Monday, December 12, 2011 6:14 PM To: Thor Kottelin Cc: anti-abuse-wg@ripe.net
"Reps for spam or spam support" and constant contact .. jesus, you don't know too much do you?
No, definitely not too much, but considering your vast experience in combating spam, I would be surprised were you to deny the reputation I mentioned. That is really a side issue though. My point was that MAAWG and RIPE are dissimilar communities with dissimilar memberships. Whether those dissimilarities are minor enough for RIPE to refer to MAAWG documents instead of continue creating its own is a matter for consensus.
As for yahoo - or gmail or any of the other large free services out there, they can deter spammers from signing up. And they can spam filter their outbound email. But I seriously doubt they, or anybody else, is going to catch 100% of the spam. They just happen to have like several million users more than you do, so the volume of spam (as opposed to the percentage of spam) is higher.
It is the volume that hurts, not the percentage. -- Thor Kottelin http://www.anta.net/
On Mon, Dec 12, 2011 at 11:09 PM, Thor Kottelin <thor.kottelin@turvasana.com> wrote:
That is really a side issue though. My point was that MAAWG and RIPE are dissimilar communities with dissimilar memberships. Whether those dissimilarities are minor enough for RIPE to refer to MAAWG documents instead of continue creating its own is a matter for consensus.
Er, the very same memberships if you look at organizations. If the IP and routing people come to RIPE and make one set of policies, without knowing anything at all about what their colleagues from the very same SP's abuse and security teams are doing at other events .. what does that say?
It is the volume that hurts, not the percentage.
Yes that's why I was more like "put yourself in the shoes of a large provider first". -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Mon, Dec 12, 2011 at 08:17:18PM +0530, Suresh Ramasubramanian wrote:
It is a FAQ, not an advocacy portal.
i'd like to suggest the FAQ is maintained as part of the NCC's operational duties. My experience is that NCC staff quite well listens to community input, but this should not encourage micro management.
Simply link to the MAAWG best practices document - there's several available for providers, end users etc.
MAAWG is but one organization. I am not convinced that, undue endorsement or not, the user community is best served by a 'simple link' to MAAWG documents. -Peter
Dear all, We are working on improving the procedures and documentation in the area of reporting abuse. As part of this work, we have already rewritten the FAQs currently being discussed on this list. We will inform you as soon as the revised FAQs are published. Best regards, Laura Cobley RIPE NCC Customer Services Manager On 12/12/11 11:44 AM, Alessandro Vesely wrote:
All, some of the replies to spam FAQs are bad.
FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently
On 01/Dec/11 16:27, Leo Vegoda wrote:
Hi Tobias, You wrote:
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads:
Should I just ignore spam?
Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5.
I propose the following replacement text:
Should I just ignore spam?
Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically.
Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?"
Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time.
Does everyone agree with the replacement text for FAQ#2?
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie.
Agreed.
The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry.
On 13/Dec/11 12:39, Laura Cobley wrote:
We are working on improving the procedures and documentation in the area of reporting abuse. As part of this work, we have already rewritten the FAQs currently being discussed on this list.
We will inform you as soon as the revised FAQs are published.
Thank you so much! It is quite curious that this WG shouldn't able to suggest an adequate wording...
Dear colleagues, Thank you for your comments. We have published new FAQs on spam/hacking. You can find them online at: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming We will add further information in the coming months to support the implementation of new procedures. Best regards, Laura Cobley RIPE NCC Customer Services Manager On 12/13/11 12:39 PM, Laura Cobley wrote:
Dear all,
We are working on improving the procedures and documentation in the area of reporting abuse. As part of this work, we have already rewritten the FAQs currently being discussed on this list.
We will inform you as soon as the revised FAQs are published.
Best regards,
Laura Cobley RIPE NCC Customer Services Manager
On 12/12/11 11:44 AM, Alessandro Vesely wrote:
All, some of the replies to spam FAQs are bad.
FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently
On 01/Dec/11 16:27, Leo Vegoda wrote:
Hi Tobias, You wrote:
The naive user should use the abuse finder tool which is already in place and would run much easier than today
I disagree and I support the RIPE NCC's answer in its abuse FAQ:
http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ign...
I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads:
Should I just ignore spam?
Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5.
I propose the following replacement text:
Should I just ignore spam?
Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically.
Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?"
Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time.
Does everyone agree with the replacement text for FAQ#2?
The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie.
Agreed.
The scale of the problem requires large scale sampling and statistical analysis rather than individual reports.
In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry.
On 16/Dec/11 14:04, Laura Cobley wrote:
We have published new FAQs on spam/hacking. You can find them online at: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming
Great improvement! One quick comment. In the page referenced from the last entry, http://www.ripe.net/ripe/docs/ripe-409 the term *ISP* is often used instead of *Mailbox Provider* (MP). The latter is newer, but more specific, since some ISPs don't run mail servers nowadays.
Hello Laura, While processing and reporting Spam e-mails that I receive occasionally, I come across networks like National PSDN "UZPAK" that do not have any contact e-mail for reporting. The only address listed, ripeadmin@uzpak.uz, appears to have been Changed. What is the RIPE policy regarding listing contact e-mails, especially about reporting abuse? If RIPE has such a policy, then why networks like this fail to list such contacts? Moreover, how come no one at RIPE reviews such incomplete listing and advise the network administrators? I hope to hear from you and others about this important matter. Thank you, Reza Farzan rezaf@mindspring.com --------- inetnum: 213.230.122.0 - 213.230.122.255 netname: UzPAK descr: National PSDN "UZPAK" descr: DSL Customers by New Plan country: UZ admin-c: HUS14-RIPE tech-c: HUS14-RIPE status: ASSIGNED PA mnt-by: AS8193-MNT changed: mazgarov@uznet.net 20090216 source: RIPE person: Husniddin D. Tuychiev address: National Data Network Company "UzPAK" address: 8,8-fl., Druzhba Narodov Street address: Tashkent, Republic of Uzbekistan, 700043 mnt-by: AS8193-MNT phone: +99871 114-6161 nic-hdl: HUS14-RIPE org: ORG-UNCN1-RIPE changed: ripeadmin@uzpak.uz 20030707 changed: ripeadmin@uzpak.uz 20040419 source: RIPE route: 213.230.64.0/18 descr: National Data Network Company "UzPAK" descr: 8, 8-fl., Druzhba Narodov Prospekt, descr: Tashkent, Republic of Uzbekistan, 700043 origin: AS8193 mnt-by: AS8193-MNT changed: ripeadmin@uzpak.uz 20090216 source: RIPE route: 213.230.122.0/24 descr: National Data Network Company "UzNet" descr: IP Pool for Satellite Channel origin: AS8193 mnt-by: AS8193-MNT changed: mazgarov@uznet.net 20100114 source: RIPE
* Reza Farzan:
What is the RIPE policy regarding listing contact e-mails, especially about reporting abuse?
Email contact information is optional.
Florian, If your statement--Email contact information is optional, is correct, how do people contact a network regarding the abuse violations that were originated from their IP address? By calling them? Or, writing a letter using the postal service? This is simply ridiculous. Again, if your statement--Email contact information is optional, is true, RIPE must be stuck in the past, without realizing the necessity of e-mail contacts. RIPE must create a revised policy regarding e-mail contact for networks listing within RIPE database to ensure accountability. Thank you. Reza Farzan rezaf@mindspring.com
-----Original Message----- From: Florian Weimer [mailto:fw@deneb.enyo.de] Sent: Sunday, March 25, 2012 12:50 PM To: rezaf@mindspring.com Cc: 'Laura Cobley'; anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] National PSDN "UZPAK"
* Reza Farzan:
What is the RIPE policy regarding listing contact e-mails, especially about reporting abuse?
Email contact information is optional.
On 26 Mar 2012, at 12:43, Reza Farzan wrote:
Florian,
If your statement--Email contact information is optional, is correct, how do people contact a network regarding the abuse violations that were originated from their IP address?
This has been discussed at length - check the list archives
By calling them? Or, writing a letter using the postal service? This is simply ridiculous.
Again, if your statement--Email contact information is optional, is true, RIPE must be stuck in the past, without realizing the necessity of e-mail contacts.
RIPE knows who its members are and there's plenty of data in the database that is public. I think Florian answered the question that was asked and didn't elaborate any further ..
RIPE must create a revised policy regarding e-mail contact for networks listing within RIPE database to ensure accountability.
RIPE "must" not do anything. RIPE might consider doing a lot of things, but they're not obliged to do anything Mr Michele Neylon Blacknight Solutions ♞ Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Ah yes. A lot of shell companies, and "we are not the document police" as somebody said on one occasion. If a bank manager disbursed loans based on the sort of paperwork that's enough for getting a /15 .. On Mon, Mar 26, 2012 at 5:25 PM, Michele Neylon :: Blacknight < michele@blacknight.ie> wrote:
RIPE knows who its members are and there's plenty of data in the database that is public. I think Florian answered the question that was asked and didn't elaborate any further ..
-- Suresh Ramasubramanian (ops.lists@gmail.com)
* Suresh Ramasubramanian:
If a bank manager disbursed loans based on the sort of paperwork that's enough for getting a /15 ..
I'm afraid banking analogies do not score any points in a discussion about accountability.
There is clearly a fiduciary duty as the custodians of a scarce, depleting, common good. So, why would an analogy about due diligence not score points? On Tuesday, March 27, 2012, Florian Weimer <fw@deneb.enyo.de> wrote:
* Suresh Ramasubramanian:
If a bank manager disbursed loans based on the sort of paperwork that's enough for getting a /15 ..
I'm afraid banking analogies do not score any points in a discussion about accountability.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
speaking of that, it would be interesting to see the response to soca's proposed whois validation http://news.dot-nxt.com/2012/03/12/five-cs-whois-validation-model On Wednesday, March 28, 2012, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
There is clearly a fiduciary duty as the custodians of a scarce, depleting, common good.
So, why would an analogy about due diligence not score points?
On Tuesday, March 27, 2012, Florian Weimer <fw@deneb.enyo.de> wrote:
* Suresh Ramasubramanian:
If a bank manager disbursed loans based on the sort of paperwork that's enough for getting a /15 ..
I'm afraid banking analogies do not score any points in a discussion about accountability.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
-- Suresh Ramasubramanian (ops.lists@gmail.com)
* Suresh Ramasubramanian:
speaking of that, it would be interesting to see the response to soca's proposed whois validation
http://news.dot-nxt.com/2012/03/12/five-cs-whois-validation-model
In essence, it boils down to this question: Can RIPE NCC rely on the UK Register of Companies to validate requests which aim to establish a UK business as a LIR? SOCA seems to suggest that the answer is "no". This is disturbing.
On 28 Mar 2012, at 18:57, Florian Weimer wrote:
Can RIPE NCC rely on the UK Register of Companies to validate requests which aim to establish a UK business as a LIR?
SOCA seems to suggest that the answer is "no". This is disturbing.
Well since you don't need to be a registered company to hold LIR assets then that is hardly surprising that Companies House is not the ultimate source of all knowledge in this case. cc line trimmed back to the OP and the WG. f
* Fearghas McKay:
On 28 Mar 2012, at 18:57, Florian Weimer wrote:
Can RIPE NCC rely on the UK Register of Companies to validate requests which aim to establish a UK business as a LIR?
SOCA seems to suggest that the answer is "no". This is disturbing.
Well since you don't need to be a registered company to hold LIR assets then that is hardly surprising that Companies House is not the ultimate source of all knowledge in this case.
True, but a signature from an officer of a registered company should be sufficient (together with the signup fee). If it's not, there's something seriously wrong with the registration procedure.
On 28 Mar 2012, at 20:53, Florian Weimer wrote:
* Fearghas McKay:
On 28 Mar 2012, at 18:57, Florian Weimer wrote:
Can RIPE NCC rely on the UK Register of Companies to validate requests which aim to establish a UK business as a LIR?
SOCA seems to suggest that the answer is "no". This is disturbing.
Well since you don't need to be a registered company to hold LIR assets then that is hardly surprising that Companies House is not the ultimate source of all knowledge in this case.
True, but a signature from an officer of a registered company should be sufficient (together with the signup fee). If it's not, there's something seriously wrong with the registration procedure.
You miss the point - there are many different kinds of commercial organisation structures that are not Limited/PLC/Limited by Guarantee companies that can hold LIR assets and be members. Why should I be a Limited/PLC/Limited by Guarantee company just to hold LIR membership or an ASN/PA/PI/etc space ? Just because SOCA finds it makes their life harder doesn't mean the whole commercial world has to change to make their lives a bit easier. Why do you find it disturbing that we can have different corporate structures ? All registered of course otherwise they would struggle to do business :-) f
SOCA's point is a lot simpler than this nit that's getting picked here. "Company exists" (as a legal entity of some sort, registered somewhere) isn't quite seen as a sufficient criterion and shouldn't be seen as the sole criterion either. IP address justification paperwork is easy enough to fudge - say all the right things, copy and paste from boilerplate or whatever. The RIR certainly isn;t going to give you a /22 if you say you want to deploy botnet C&Cs on it, so of course you aren't going to say that. On Thu, Mar 29, 2012 at 1:29 AM, Fearghas McKay <fearghas@gmail.com> wrote:
Just because SOCA finds it makes their life harder doesn't mean the whole commercial world has to change to make their lives a bit easier.
Why do you find it disturbing that we can have different corporate structures ? All registered of course otherwise they would struggle to do business :-)
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Wed, Mar 28, 2012 at 11:27 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
Can RIPE NCC rely on the UK Register of Companies to validate requests which aim to establish a UK business as a LIR?
SOCA seems to suggest that the answer is "no". This is disturbing.
Incorporating an LLC with the address of record being a maildrop location, or even an empty lot, has traditionally taken you a few pounds and less than a day .. How or why should the registrar of companies be an authoritative source to declare anything except that "a registered company by that name exists"? In other words, there's absolutely no useful input into your IP justification process that validates that X is a genuine entity who actually needs a /20 for his new datacenter location, rather than to stuff it with botnet C&Cs or whatever. Now, if RIPE NCC were to get the RBN or whoever as a customer, they wouldn't know because they simply don't validate anything much of this sort at all, and even if they do set up some perfunctory validation like checking that the company presenting IP allocation paperwork is registered, that doesn't mean anything relevant. Andy Auld was probably not particularly diplomatic when he said this - but he was 100% correct. http://www.zdnet.co.uk/news/security-threats/2009/10/22/soca-russian-cyber-g... "RBN paid Ripe for services," said Auld. "If we were being harsh, we could say that Ripe has received criminal funds and was involved in money-laundering offences. We are not treating it that way, but you could see it like that." "....to which RIPE NCC pointed out that RBN passed a set of checklists."Our checklists include the provision of proof that a prospective LIR has the necessary legal documentation, which proves that a business is bona fide." Now, it is great that you don't like analogies about the banking industry, and don't work in the banking industry (I don't either, but what I did was to phone my bank manager and ask him what'd happen if such a situation arose). Because you see, if this had happened with our putative bank manager, he'd have been arrested for money laundering and the bank would be facing some fairly extensive audits from the banking regulator, getting its records subpoena'd by the police etc -- Suresh Ramasubramanian (ops.lists@gmail.com)
* Suresh Ramasubramanian:
There is clearly a fiduciary duty as the custodians of a scarce, depleting, common good.
So, why would an analogy about due diligence not score points?
Because we do not value accountability in our financial institutions. Back to the original topic. I agree that we face various issues with service provider accountability, but one of the major problems with this and similar discussions is that those who demand some form of action make claims which are quite obviously not factually correct. The allocated resource covering 213.230.122.0 is the inetnum object 213.230.64.0 - 213.230.127.255, allocated to this LIR: organisation: ORG-UNCN1-RIPE org-name: Uzpak Net (Country Net of Independence Republic of Uzbekistan) org-type: LIR address: National Data Network Company 8th floor, 8, Druzhba Narodov str., 700043, Tashkent, Uzbekistan phone: +998 71 114 6314 phone: +998 71 144 4804 fax-no: +998 71 114 6322 e-mail: admin@uzpak.uz admin-c: BM2509-RIPE admin-c: MBA-RIPE mnt-ref: AS8193-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT changed: [...] 20120308 source: RIPE There you have a street address, a phone number, and even an email address. Does this change anything about accountability? Not sure. For PA resources, such information is relatively easy to find. However, RIPE NCC is not able to provide this as a service, and restricts access to the database in a way that makes it impossible to offer such a service to the general public. But these obstacles are created by RIPE NCC and the RIPE community, and not the resource holders. Again, let me stress that this case is far from unique. We often see claims that some network is "bad". I'm slightly out of touch with regards to current network-wide events, but I still feel that I should be able to recognize proof of badness as such. But what happens far too often is that folks who I know are knowledgeable about these things cannot express their rationale in terms I can understand or accept as proof. This is a problem.
Florian, As I had stated in my earlier message, I had forwarded my Spam report to the following address [admin@uzpak.uz], but it came back with this error message: ------- A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: ripeadmin@uzpak.uz SMTP error from remote mail server after RCPT TO:<ripeadmin@uzpak.uz>: host mail.uzpak.uz [84.54.64.37]: 553 sorry, this recipient is not in my validrcptto list (#5.7.1) ------- As you may know, many networks show and use invalid, or even fake contact e-mail addresses in order to frustrate everyone, and the National PSDN "UZPAK" is no exception. On a daily basis, I report such abuse violations to Spamcop.net, http://www.spamcop.net/, and in many instances, the IP address either does not have an Abuse Reporting e-mail, or the e-mail addresses listed in the Whois directory is bogus. So, having a street address, a phone number, and even an invalid email address, does not change anything; it creates frustration and despair. One way to hold all networks accountable perhaps would be for the RIPE NCC to send an e-mail [once a year] to addresses in their Whois listing, thereby confirming and verifying their correctness and validity. Thank you, Reza Farzan rezaf@mindspring.com ===========
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of Florian Weimer Sent: Wednesday, March 28, 2012 2:35 PM To: Suresh Ramasubramanian Cc: Laura Cobley; Michele Neylon :: Blacknight; <rezaf@mindspring.com>; <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] National PSDN "UZPAK"
* Suresh Ramasubramanian:
There is clearly a fiduciary duty as the custodians of a scarce, depleting, common good.
So, why would an analogy about due diligence not score points?
Because we do not value accountability in our financial institutions.
Back to the original topic. I agree that we face various issues with service provider accountability, but one of the major problems with this and similar discussions is that those who demand some form of action make claims which are quite obviously not factually correct.
The allocated resource covering 213.230.122.0 is the inetnum object 213.230.64.0 - 213.230.127.255, allocated to this LIR:
organisation: ORG-UNCN1-RIPE org-name: Uzpak Net (Country Net of Independence Republic of Uzbekistan) org-type: LIR address: National Data Network Company 8th floor, 8, Druzhba Narodov str., 700043, Tashkent, Uzbekistan phone: +998 71 114 6314 phone: +998 71 144 4804 fax-no: +998 71 114 6322 e-mail: admin@uzpak.uz admin-c: BM2509-RIPE admin-c: MBA-RIPE mnt-ref: AS8193-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT changed: [...] 20120308 source: RIPE
There you have a street address, a phone number, and even an email address. Does this change anything about accountability? Not sure.
For PA resources, such information is relatively easy to find. However, RIPE NCC is not able to provide this as a service, and restricts access to the database in a way that makes it impossible to offer such a service to the general public. But these obstacles are created by RIPE NCC and the RIPE community, and not the resource holders.
Again, let me stress that this case is far from unique. We often see claims that some network is "bad". I'm slightly out of touch with regards to current network-wide events, but I still feel that I should be able to recognize proof of badness as such. But what happens far too often is that folks who I know are knowledgeable about these things cannot express their rationale in terms I can understand or accept as proof. This is a problem.
* Reza Farzan:
As I had stated in my earlier message, I had forwarded my Spam report to the following address [admin@uzpak.uz], but it came back with this error message:
In your earlier message, you mentioned <mazgarov@uznet.net> and <ripeadmin@uzpak.uz> only, and not <admin@uzpak.uz>. But it turns out this address is not valid, either: | 220 Welcome to UzNET Cyber Mail ESMTP | EHLO ka.mail.enyo.de | 250-Welcome to UzNET Cyber Mail | 250-SIZE 0 | 250-PIPELINING | 250 8BITMIME | MAIL FROM:<fw@deneb.enyo.de> | 250 ok | RCPT TO:<admin@uzpak.uz> | 553 sorry, this recipient is not in my validrcptto list (#5.7.1) | QUIT | 221 Welcome to UzNET Cyber Mail So we've finally something which is demonstrably not in order: the email attribute of ORG-UNCN1-RIPE does not refer to a valid mailbox (to the degree something like that can be tested).
So, having a street address, a phone number, and even an invalid email address, does not change anything; it creates frustration and despair.
The sad thing is that even if there was a working email address (<admin@intel.uz>, probably), it wouldn't change anything. I've been through this---in the end, WHOIS accuracy has very little impact on things. The data is bad because no one has a serios need for it. Neither the anti-abuse folks, nor the copyright holders, and certainly not law enforcement. If the data was actually used for any significant purpose, those who submit and publish incorrect WHOIS information would face some accountability. Right now, they get away with publishing anything from outright lies to data which may have been current ten years ago. There is no use case, so quality does not matter. This is like any documentation: if it is not continuously used, it decays fast, and it is extremely difficult to motivate people to maintain it because they abhor the sheer pointlessness of it.
On Fri, Mar 30, 2012 at 1:22 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
I've been through this---in the end, WHOIS accuracy has very little impact on things. The data is bad because no one has a serios need for it. Neither the anti-abuse folks, nor the copyright holders, and certainly not law enforcement.
Are you sure? http://www.icann.org/en/news/presentations/opta-mar-26jun06-en.pdf -- Suresh Ramasubramanian (ops.lists@gmail.com)
Hi Reza, this issue is well known (see the list archive) and at the moment it is my fault to not come up with a new policy proposal. Sorry 24 hours a day is just to less ;-) I hope I'll get it done pretty soon, to have another starting point for a discussion. Stay tuned, Tobias Am 26.03.12 13:43, schrieb Reza Farzan:
Florian,
If your statement--Email contact information is optional, is correct, how do people contact a network regarding the abuse violations that were originated from their IP address? By calling them? Or, writing a letter using the postal service? This is simply ridiculous.
Again, if your statement--Email contact information is optional, is true, RIPE must be stuck in the past, without realizing the necessity of e-mail contacts.
RIPE must create a revised policy regarding e-mail contact for networks listing within RIPE database to ensure accountability.
Thank you.
Reza Farzan rezaf@mindspring.com
-----Original Message----- From: Florian Weimer [mailto:fw@deneb.enyo.de] Sent: Sunday, March 25, 2012 12:50 PM To: rezaf@mindspring.com Cc: 'Laura Cobley'; anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] National PSDN "UZPAK"
* Reza Farzan:
What is the RIPE policy regarding listing contact e-mails, especially about reporting abuse?
Email contact information is optional.
Hi, On 03/26/2012 01:43 PM, Reza Farzan wrote:
RIPE must create a revised policy regarding e-mail contact for networks listing within RIPE database to ensure accountability.
Oh wow, now that you said so, RIPE (that would be the european+ internet - how much is that, a billion pepole?) has to subject themselves to your wisdom... ;) You can, ofc, try the obvious: mazgarov@uznet.net ripeadmin@uzpak.uz Then again, seeing your mailinglist-contributions I guess it's highly likely that your mails might be considered the same as the probable reason there's no email attributes: spam. In case of a serious issue you probably wouldn't have a problem with postal mail. And while we're at it, regarding your 'accountability'-thing: you should really talk to some governments, being from the past (well...) they all seem to tend to regard postal mail as more 'accountable' than email... Surprisingly... Regards, Chris
* Reza Farzan:
If your statement--Email contact information is optional, is correct, how do people contact a network regarding the abuse violations that were originated from their IP address? By calling them? Or, writing a letter using the postal service? This is simply ridiculous.
Usually, you don't care about contact, you want them to take some sort of action as well.
RIPE must create a revised policy regarding e-mail contact for networks listing within RIPE database to ensure accountability.
There is no relationship between the two, one way or the other. All PA resources can be traced back to a legal entity which has submitted proof of its existence to RIPE NCC. For PI resources, the status is less clear, but I can't tell if this is an issue in practice. And there are countries (curiously, not the ones you would expect) where forming a limited liability company is so easy and cheap that accountability is seriously impacted.
2012/3/25 Florian Weimer <fw@deneb.enyo.de>:
* Reza Farzan:
What is the RIPE policy regarding listing contact e-mails, especially about reporting abuse?
Email contact information is optional.
fake fax number with a 3200baud lane is however cool, or optionnaly overtaxed telephone number with unnice and incompetent sweat phone center is quite a must. A regexp describing a phone number in an ABNF in a RFC matters more to RIPE than if there are actually people answering the given phone number are respecting the basics of troubleshooting (ticketing, tracability, competence, accountability...). Well, to be honest would they have contracts with the LIR/RIR they could enforce the contact. Ho ! My bad. They have the awful power to restrict the delivery of public IP & AS, therefore they have power over the contractant. I even guess they could ask the blackholing of some resources (BGP) in extreme case. I am pretty much seeing RIPE as a bureaucracy even though it is working by the good will of really nice and expert persons. But -in my opinion- it has forgotten its goal : making sure change management, QA, accountability of internet resources stakeholders is made correctly. And they have the power to do it. Contracts are there since the roman empire and they still works the same : a contract is broken if one of the party does not respects its word on an essential contractual binding as long as it is legal. I have read 10 years ago the RIPE contract for RIR, they do have the power to do it for sure. It is not a technical issue, it is more a political issue amongst RIPE : they don't want to be the bad guys sanctioning bad behaviours, they are the good guys helping as much good willed people as they can to do their job properly and cooperate (that's the reason to be of the RIPE formation I guess on topics such as DNSSec, IPv6, and meetings, RIPE ML). Revoking a contract is way more costly (since you have to put a lawyer on the issue in an international context ruled by more than one country/law/convention). How many formations do you have to sacrifice for a contract to be revoked ? Politic is about deciding how much resources you spend on a given task. It is clearly not in the hand of any technical mailing lists. And legal enforcement costs prejudices the formation price. (Education is productive, litigations alone has no long term positive impact on the whole ecosystem). RIPE essence is clearly to improve the pool of good willed people and make them cooperate. However, I would -if I were the RIPE- at least publicly announce once in a while that a rogue RIR/LIR has its contract suspended. I would do it just because it is demotivating to do your job correctly when you have evidence of people doing it wrong without any consequence for them. Cheers PS : I really do have appreciated RIPE good willed, nice, and competent help when I had to fill the IPv4 forms. I really loved working with RIPE NCC it was a pleasing experience. I just would like it to be even better and I guess I lack so much elements that I might have expressed an obviously stupid opinion, but I was told you should always trust your intuition :) -- Julien Tayon Silent lurker for years and with no actual shiny title or experience to backup its opinion :)
* julien tayon:
Well, to be honest would they have contracts with the LIR/RIR they could enforce the contact. Ho ! My bad. They have the awful power to restrict the delivery of public IP & AS, therefore they have power over the contractant. I even guess they could ask the blackholing of some resources (BGP) in extreme case.
At a technical level, RPKI might eventually allow this, but this project was not exactly welcomed by the RIPE community, for precisely this reason.
Can I get off this list? On 25 Mar 2012, at 14:19, "Reza Farzan" <rezaf@mindspring.com> wrote:
Hello Laura,
While processing and reporting Spam e-mails that I receive occasionally, I come across networks like National PSDN "UZPAK" that do not have any contact e-mail for reporting. The only address listed, ripeadmin@uzpak.uz, appears to have been Changed.
What is the RIPE policy regarding listing contact e-mails, especially about reporting abuse?
If RIPE has such a policy, then why networks like this fail to list such contacts? Moreover, how come no one at RIPE reviews such incomplete listing and advise the network administrators?
I hope to hear from you and others about this important matter.
Thank you,
Reza Farzan rezaf@mindspring.com
---------
inetnum: 213.230.122.0 - 213.230.122.255 netname: UzPAK descr: National PSDN "UZPAK" descr: DSL Customers by New Plan country: UZ admin-c: HUS14-RIPE tech-c: HUS14-RIPE status: ASSIGNED PA mnt-by: AS8193-MNT changed: mazgarov@uznet.net 20090216 source: RIPE
person: Husniddin D. Tuychiev address: National Data Network Company "UzPAK" address: 8,8-fl., Druzhba Narodov Street address: Tashkent, Republic of Uzbekistan, 700043 mnt-by: AS8193-MNT phone: +99871 114-6161 nic-hdl: HUS14-RIPE org: ORG-UNCN1-RIPE changed: ripeadmin@uzpak.uz 20030707 changed: ripeadmin@uzpak.uz 20040419 source: RIPE
route: 213.230.64.0/18 descr: National Data Network Company "UzPAK" descr: 8, 8-fl., Druzhba Narodov Prospekt, descr: Tashkent, Republic of Uzbekistan, 700043 origin: AS8193 mnt-by: AS8193-MNT changed: ripeadmin@uzpak.uz 20090216 source: RIPE
route: 213.230.122.0/24 descr: National Data Network Company "UzNet" descr: IP Pool for Satellite Channel origin: AS8193 mnt-by: AS8193-MNT changed: mazgarov@uznet.net 20100114 source: RIPE
Hi, On Sun, Mar 25, 2012 at 07:24:43PM +0100, Ian.Cleary wrote:
Can I get off this list?
Doesn't look like it. But with a little help... http://lmgtfy.com/?q=unsubscribe+anti-abuse-wg%40ripe.net Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg- bounces@ripe.net] On Behalf Of Ian.Cleary Sent: Sunday, March 25, 2012 9:25 PM To: rezaf@mindspring.com Cc: Laura Cobley; <anti-abuse-wg@ripe.net>
Can I get off this list?
As the header says: 'List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/anti-abuse-wg>'. -- Thor Kottelin http://www.anta.net/
Hi, I support this proposal, hoping that it would eventually become mandatory and we have an auditing mechanism in place. Regards, -- Babak Farrokhi Network Expert / Unix SA / Security Analyst
Denis, On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object.
https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
Thanks for putting this together. Basically, I think that the basic split between ABUSE and STANDARD ROLE objects does not make a lot of sense, and will likely lead to user confusion and frustration. Some of the ideas you've presented do make sense, but make sense for any contact data rather than restricting them via arbitrary business rules. One thing that I think would be a positive step forward for the RIPE Database is *not* to restrict references to ABUSE ROLE, but rather to restrict *all* references to person or role objects. I believe the database currently still allows me to reference any person/role object if I want to. This is a bug, not a feature, and I think adding "mnt-ref:" to person/role objects would be a better way forward than adding yet another special case. (This was introduced as a special case to the irt type, but then generalised in the organisation object.) I also suggest that normal access controls should apply to roles when used for abuse. Abuse desks don't like spam either. -- Shane
Shane Kerr wrote:
Denis,
Dear Denis, a restriction or ACL for the abuse address is simple not what a lot of people intended. You forgot about bigger ISPs that likes to report abuse automatically in standarized formats (and what most abuse departments really LIKE to receive). An unrestricted abuse contact really helps here a lot. Sure, personal data should be protected, and thats why we really like the idea of seperating them from personal objects. But to be honest: no restriction helps that your email address ends up in a spammers list, they have more power you can dream of (I even heared that they pay people to enter captcha codes). Kind regards, Frank
On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object.
https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
Thanks for putting this together.
Basically, I think that the basic split between ABUSE and STANDARD ROLE objects does not make a lot of sense, and will likely lead to user confusion and frustration. Some of the ideas you've presented do make sense, but make sense for any contact data rather than restricting them via arbitrary business rules.
One thing that I think would be a positive step forward for the RIPE Database is *not* to restrict references to ABUSE ROLE, but rather to restrict *all* references to person or role objects. I believe the database currently still allows me to reference any person/role object if I want to. This is a bug, not a feature, and I think adding "mnt-ref:" to person/role objects would be a better way forward than adding yet another special case. (This was introduced as a special case to the irt type, but then generalised in the organisation object.)
I also suggest that normal access controls should apply to roles when used for abuse. Abuse desks don't like spam either.
-- Shane
-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Hi,
a restriction or ACL for the abuse address is simple not what a lot of people intended.
We do not want to have a restriction on the abuse address it self. But we are able to control and split personal data from public data with these ACLs. And that is exactly what should happen.
You forgot about bigger ISPs that likes to report abuse automatically in standarized formats (and what most abuse departments really LIKE to receive). An unrestricted abuse contact really helps here a lot.
That is exactly what we want. That the abuse-mailbox attribute is unrestricted, but not the email address attribute. And that can be managed by ACLs.
Sure, personal data should be protected, and thats why we really like the idea of seperating them from personal objects.
And that again is exactly what ACLs are for, to separate personal data from public data. I do not see any sense in splitting this up in different objects, since this makes things much more complicated for maintainers and especially for smaller maintainers.
But to be honest: no restriction helps that your email address ends up in a spammers list, they have more power you can dream of (I even heared that they pay people to enter captcha codes).
Paying people to entering captcha codes is not that new at all. ;-) The point is that we would not change anything. The abuse-mailbox attribute can be queried without restrictions already. So the whole proposal is about adding an abuse-c which makes imho sense and the implementation will take care of clearing thing up a little bit. Thanks, Tobias -- abusix
Kind regards, Frank
On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object.
https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
Thanks for putting this together.
Basically, I think that the basic split between ABUSE and STANDARD ROLE objects does not make a lot of sense, and will likely lead to user confusion and frustration. Some of the ideas you've presented do make sense, but make sense for any contact data rather than restricting them via arbitrary business rules.
One thing that I think would be a positive step forward for the RIPE Database is *not* to restrict references to ABUSE ROLE, but rather to restrict *all* references to person or role objects. I believe the database currently still allows me to reference any person/role object if I want to. This is a bug, not a feature, and I think adding "mnt-ref:" to person/role objects would be a better way forward than adding yet another special case. (This was introduced as a special case to the irt type, but then generalised in the organisation object.)
I also suggest that normal access controls should apply to roles when used for abuse. Abuse desks don't like spam either.
-- Shane
On Thu, Dec 01, 2011 at 03:24:05PM +0100, Frank Gadegast wrote: hi,
You forgot about bigger ISPs that likes to report abuse automatically in standarized formats (and what most abuse departments really LIKE to receive).
True, but this is an orthogonal problem.
An unrestricted abuse contact really helps here a lot.
Like, the abuse mailbox defined in RFC 2142?
But to be honest: no restriction helps that your email address ends up in a spammers list, they have more
Adding arbitrary restrictions doesn't prevent that either.
power you can dream of (I even heared that they pay people to enter captcha codes).
Yes. Cheers, Adrian
Adrian wrote:
On Thu, Dec 01, 2011 at 03:24:05PM +0100, Frank Gadegast wrote:
hi,
Hi,
You forgot about bigger ISPs that likes to report abuse automatically in standarized formats (and what most abuse departments really LIKE to receive).
True, but this is an orthogonal problem.
An unrestricted abuse contact really helps here a lot.
Like, the abuse mailbox defined in RFC 2142?
Dont forget that the abuse-mailbox is mandatory, the new abuce-c isnt (and its also hierachically). When automatic parsing is needed, your need to query several objects including IRT, remarks, abuse-mailbox (what is usally not present for networks that ARE spamming a lot) and finally personal objects to find at least one email address you could send an abuse report too. And personal objects ARE restricted, what compicates things a lot.
But to be honest: no restriction helps that your email address ends up in a spammers list, they have more
Adding arbitrary restrictions doesn't prevent that either.
power you can dream of (I even heared that they pay people to enter captcha codes).
Yes.
Ok, so lets restrict access to personal objects even more and lets have a non mandatory and public abuse-c without any restriction. And I still like the idea of an "preferred contact method" field, so we can decide what format to use automatically.
Cheers, Adrian
Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Hi,
Dont forget that the abuse-mailbox is mandatory, the new abuce-c isnt (and its also hierachically).
Don't forget hierarchy. If X.0.0.0/8 has an abuse-c all ips in this range are covered. If somebody wants to handle his own abuse he can add an abuse-c as well. If the maintainer of X.0.0.0/8 does not want to be responsible he has to ask his customers to publish an abuse-c. This should cover your thoughts.
When automatic parsing is needed, your need to query several objects including IRT, remarks, abuse-mailbox (what is usally not present for networks that ARE spamming a lot) and finally personal objects to find at least one email address you could send an abuse report too.
This is exactly what should not happen in future, because the Abuse Finder API will give you the exact information you requested. If you use whois, you should use the -b option which returns only the abuse-mailbox attribute of the abuse-c. In the transitionphase this result will come up first and the other "old" results will come up if the first result is not possible to find. Later on there is only the mailbox attribute coming from an abuse-c.
And personal objects ARE restricted, what compicates things a lot.
As well this should not happen any more. Before sending the report to a personal address you should use hierarchy and go up one level and report things to this level. They can take care in whatever way they find it would be appropriate.
Ok, so lets restrict access to personal objects even more and lets have a non mandatory and public abuse-c without any restriction.
I do not get the point why data other than abuse-mailbox would be needed in an unrestricted way. The abuse-c will be mandatory for at least the highest allocation, which gives you an abuse-mailbox attribute for every single ip address. So why would we need an unrestricted email-attribute, phone number, street and name of the object?
And I still like the idea of an "preferred contact method" field, so we can decide what format to use automatically.
There is a project working on this as a DNS based service in the IETF ARF Working Group. I'm absolutely against defining formats in the whois database. I could accept channels as soon as there are other channels finding their way in the everydays life of an abuse department. Putting formats into the whois things get polluted with stuff that has nothing to do in the whois. And second keeping this up2date is a pain. An abuse department does probably not want to get on NOCs people nerves and requests updates every once in a while. Thanks, Tobias -- abusix
Tobias Knecht wrote:
Hi,
Hi Tobias,
Dont forget that the abuse-mailbox is mandatory, the new abuce-c isnt (and its also hierachically).
Don't forget hierarchy. If X.0.0.0/8 has an abuse-c all ips in this range are covered. If somebody wants to handle his own abuse he can add an abuse-c as well. If the maintainer of X.0.0.0/8 does not want to be responsible he has to ask his customers to publish an abuse-c.
Thats a big point FOR the proposal. It will force the maintainer of the /8 to force his customers to migrate to the new abuce-c pretty quick.
attribute of the abuse-c. In the transitionphase this result will come up first and the other "old" results will come up if the first result is not possible to find. Later on there is only the mailbox attribute coming from an abuse-c.
Just what I meant, it will be perfect. One API or whois call or visit to the abuse finder tool to find the reponsible abuse email address, automatic or not, it simply will work for every complaint.
And personal objects ARE restricted, what compicates things a lot.
As well this should not happen any more. Before sending the report to a personal address you should use hierarchy and go up one level and report things to this level. They can take care in whatever way they find it would be appropriate.
We regulary climb that latter and often end up at hostmaster@ripe.net or bitbucket@ripe.net (or similar at the other RIRs) after making lots of unneeded queries :o( abuce-c will be much better than the confusion that we have right now (I even saw whois output with a different abuse-mailbox email that was mentioned in the remarks ;o)
Ok, so lets restrict access to personal objects even more and lets have a non mandatory and public abuse-c without any restriction.
I do not get the point why data other than abuse-mailbox would be needed in an unrestricted way.
That not what I meant, we will be happy, if the abuce-c is in place and its abuse-mailbox field queries will be unrestricted.
The abuse-c will be mandatory for at least the highest allocation, which gives you an abuse-mailbox attribute for every single ip address. So why
I know, thats why I support this proposal 100% +1
would we need an unrestricted email-attribute, phone number, street and name of the object?
And I still like the idea of an "preferred contact method" field, so we can decide what format to use automatically.
There is a project working on this as a DNS based service in the IETF ARF Working Group.
I'm absolutely against defining formats in the whois database. I could accept channels as soon as there are other channels finding their way in the everydays life of an abuse department. Putting formats into the whois things get polluted with stuff that has nothing to do in the whois. And second keeping this up2date is a pain. An abuse department does probably not want to get on NOCs people nerves and requests updates every once in a while.
Ok, can see that one too ... was just an idea that will help our daily work ... Kind regards, Frank
Thanks,
Tobias
-- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Hi Shane You raised several points here, but I think they fall into two different issues. I will address one of them in this email. Then address the other ones in another email. First, the long standing question about referencing anyone's PERSON or ROLE object. I raised this question with the RIPE Data Protection Task Force and they considered the issue at great length some time ago. The Task Force concluded that it is actually better to NOT require authentication. As things stand now anyone can reference *your* PERSON object in their data. But you can do an inverse query (-i pn NIC-Hdl) and find any object in the RIPE Database where your PERSON object has been referenced. If you see a reference that you did not make, in data that you do not maintain, then you can question it with the maintainer of that data. If you get no success or response from them you can use the legal process (also set up by that Task Force) to deal with requests to remove (references to) personal data in the RIPE Database by a data subject. If the community asks for references to PERSON/ROLE objects to require mandatory authorisation, then no one can add a reference to YOUR object in their data. At first this looks like the ideal situation. However, the RIPE Data Protection Task Force looked at this from a different angle. There is no restriction on anyone creating a PERSON object containing any data. So anyone can create a new PERSON object with a copy of the data contained in your PERSON object. The guy who creates this copy also maintains it. So he can provide any mandatory authorisation for referencing this data copy. In the first case you can find any unauthorised references. In the second case you may never know someone has copied your personal data. So the Task Force considered it is safer to leave it as it is. Maybe a more important question to address is WHO made the changes? From the logs we can see which MNTNER and which password/PGP authorised a reference to your PERSON object or that created a copy of it. But a MNTNER is a box holding anonymous credentials of unknown people. What is missing is accountability. regards Denis On 1/12/11:49 3:06 PM, Shane Kerr wrote:
Denis,
On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object.
https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
Thanks for putting this together.
Basically, I think that the basic split between ABUSE and STANDARD ROLE objects does not make a lot of sense, and will likely lead to user confusion and frustration. Some of the ideas you've presented do make sense, but make sense for any contact data rather than restricting them via arbitrary business rules.
One thing that I think would be a positive step forward for the RIPE Database is *not* to restrict references to ABUSE ROLE, but rather to restrict *all* references to person or role objects. I believe the database currently still allows me to reference any person/role object if I want to. This is a bug, not a feature, and I think adding "mnt-ref:" to person/role objects would be a better way forward than adding yet another special case. (This was introduced as a special case to the irt type, but then generalised in the organisation object.)
I also suggest that normal access controls should apply to roles when used for abuse. Abuse desks don't like spam either.
-- Shane
Hi Shane I answered your point about authorised references to PERSON objects separately as I don't think it is directly related to the technical proposal for this community policy proposal. The community may wish to discuss it further, but it may be better in another thread. Let me now answer the other half of this mail. If there were only to be two types of ROLE objects then it may not make sense to develop a generalised ROLE object. But as I illustrated in the article on RIPE Labs, the IRT object would fit very easily into this model as a third type of role. We have listened to comments about the IRT object over the years from people at RIPE Meetings and feedback from the trainers, who talk to many members every week. There is only a small group of people who really understand the complexity of the design of the IRT object. That is why for many years there were probably more POEM than IRT objects in the RIPE Database. It is a good example of using over complicated exceptions to solve a problem instead of generalising on an existing feature. However you look at it, the IRT object simply provides contact details for a specific role within an organisation. But it is not identical to the "admin-c:" role which is not identical to the "abuse-c:" role. When you look at the wider picture, an organisation has many role type functions. They may have slightly different characteristics in terms of where they are referenced from, the scope of the data they apply to (hierarchies for example), what type of contact details they present, authorisation issues and how much of the object should be displayed in different scenarios. But they are all roles. These differences can be handled by clearly defined business rules. They are by no means 'arbitrary'. This is why we made the technical proposal to make that generalisation now instead of building more one off exceptions. The article I wrote on RIPE Labs may look a little complicated because I included some of the design issues and background to explain how the RIPE Database developed into the animal it is today. If the community accepts this technical proposal as part of the policy under discussion, we will provide much simpler documentation explaining how to manage all contact data in the RIPE Database. This will include illustrated examples of the different role types, when and how to use them, what needs to be in them and the relationship between ROLE and PERSON objects. As a further step we can then improve Webupdates to recognise the different role types and present templates according to the type. This would clearly show what attributes are mandatory, optional, (not)allowed and required for a specific role type. Another step would then be for the Web Query form and the Query API to also present templates based on role type. In the long term we want to provide more modern tools for managing your data in the RIPE Database. As we further develop the Query and Update APIs we want to take away the need to remember what an RPSL object should look like in any given situation. It is a question of taking a series of small steps, each one to improve some aspect of using the RIPE Database. So rather than leading to 'confusion and frustration' we expect to provide clarity and calmness. It may look like a big change, but in reality it is a straight forward cleanup of the software to handle generalised roles and the final documentation will be much clearer than the article on RIPE Labs. When the community makes a decision on the policy, if we have the go ahead to implement this we will develop and deploy it quite quickly. As we now work with agile software development nothing is ever final. When a solution is deployed, if the community has any concerns or issues we can adapt it quite quickly. The aim is to work towards the perfect solution in a series of small, deployed steps. Then the community can review progress more often and see if it is the direction you want to be moving in. Change is much easier with small steps than a giant leap. I hope this answers some of the concerns over the technical details behind the communities policy proposal. Regards Denis Walker Business Analyst RIPE NCC Database Group
Denis,
On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object.
https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
Thanks for putting this together.
Basically, I think that the basic split between ABUSE and STANDARD ROLE objects does not make a lot of sense, and will likely lead to user confusion and frustration. Some of the ideas you've presented do make sense, but make sense for any contact data rather than restricting them via arbitrary business rules.
One thing that I think would be a positive step forward for the RIPE Database is *not* to restrict references to ABUSE ROLE, but rather to restrict *all* references to person or role objects. I believe the database currently still allows me to reference any person/role object if I want to. This is a bug, not a feature, and I think adding "mnt-ref:" to person/role objects would be a better way forward than adding yet another special case. (This was introduced as a special case to the irt type, but then generalised in the organisation object.)
I also suggest that normal access controls should apply to roles when used for abuse. Abuse desks don't like spam either.
-- Shane
participants (25)
-
Adrian -
Alessandro Vesely -
Babak Farrokhi -
Chris -
Denis Walker -
denis＠ripe.net
-
Fearghas McKay -
Florian Weimer -
Frank Gadegast -
Frank Gadegast -
Gert Doering -
Gilles Massen -
Ian.Cleary -
julien tayon -
Kostas Zorbadelos -
Laura Cobley -
Leo Vegoda -
Michele Neylon :: Blacknight -
peter h -
Peter Koch -
Reza Farzan -
Shane Kerr -
Suresh Ramasubramanian -
Thor Kottelin -
Tobias Knecht