If the policy does not include an obligation to maintain the abuse-c and keep it current then I can't see what purpose this serves and the problem that needs to be addressed will remain a problem. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

Hi Denis, I don't think I've seen anyone suggest that improving the structure is a bad thing to do. However, adding new structure before anyone has even had an opportunity to look at the proposals for maintaining the mandatory new data seems at least less than ideal. If this is part of a grand plan, it would be nice if the grand plan could be shared. Is there a reason for not sharing the big picture? Regards, Leo -----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of Denis Walker Sent: Monday 16 Apr 12 2:13 pm To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database) Hi Leo If you remember back to an earlier RIPE Meeting (some time ago) three policies were proposed including where to put the abuse data and how to validate it. These were withdrawn to allow a Task Force to look at the issues. The first policy from the Task Force is to have a single location in the RIPE Database to store abuse contact details. You can debate which should come first, a place to store the details or a means of validating/enforcing accuracy of the data. But what you have right now in the RIPE Database for abuse contacts is a mess. Many details are still stored in remarks. When we wrote the Abuse Finder tool we could not even find these contacts by scripting. The best we could offer is a pointer to where you might find something useful. If you can't reliably find the data you have little chance of validating it. The whole point of this proposal is to fix the abuse contact details in one easy to find place in the database, by humans and scripting. Far from putting off the day when the mess has to be cleared up, this is the first step in cleaning up the already existing mess. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 16/04/12:17 9:13 PM, Leo Vegoda wrote:

Hi Frank,

Frank wrote:

...

Leo Vegoda wrote:

...

Marco Schmidt wrote:

[...]

...

...

It is disappointing that this new proposal is still focused on a one-time process of adding additional contact information and does not address ongoing management of the published information. Until there is a policy requiring contact information to be regularly maintained, proposal 2011-06 is of limited value.

Not at all, its good to seperate definitions and other procedures like management or validation of abuse contacts, if you remember how hard it is to achive consensus.

Lets starts simple and lets add other parts later.

I will be happy to prepare a validation draft, if the community wants it.

My issue is mainly with the way the proposals are ordered. Creating new requirements for types of contact data to be published before agreeing on a contact data management policy risks creating a situation where a new layer of contact information of questionable quality is added as a one-time only event. Unless you have a pre-existing contact data management policy you are just making the problem bigger and putting off the day when the mess has to be cleared up.

Agreeing a way to manage contact data should be a prerequisite to the creation of new contact types.

Regards,

Leo Vegoda

Hi Denis, On Apr 16, 2012, at 2:32 pm, Denis Walker wrote:

I am not aware of any formal big picture, but I follow the mailing list as closely as I am sure you and many others do. As you will know many of these issues invoke much discussion on the list.

I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary. Regards, Leo

Leo, Leo Vegoda wrote, On 17/04/2012 00:22:

Hi Denis,

On Apr 16, 2012, at 2:32 pm, Denis Walker wrote:

...

I am not aware of any formal big picture, but I follow the mailing list as closely as I am sure you and many others do. As you will know many of these issues invoke much discussion on the list.

I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary.

While I think that Frank has given a good outline, what is "this" to your mind? Is it abuse contact management, is it data verification? Part of the problem that we hit with the ACM-TF is that data verification is a very big thing and people have a lot of reactions to it. This lead to a decision to try to get the abuse-c nailed down and integrated, before, should the community or TF decide, looking at data verification, and indeed the scope of that. I'll be honest, I don't see the 2011-06 and any data verification proposal as being that tightly integrated, but I'll accept not everyone shares my view of the world, so if you could expand on your fears, or why you feel it is so vital, that would be great. Thanks, Brian.

On 17/04/12:17 10:48 AM, Frank Gadegast wrote:

Do you think that the LIRs would complain, if the NCC asks the maintainer with an automatic email to updated his or her objects ? Cannot imagine it, because they DID supply an email address, its simply wrong (old, forgotten or typing mistake or deliberatly wrong).

Here in lays another problem....you are assuming now that all maintainers email addresses are valid. We will present some stats on these in the DB WG presentation later this week. Here we are talking much more than 1.5% problems. I think this is one of the points Brian means. The issue of user data accuracy is wider than just for abuse reporting. regards Denis Walker Business Analyst RIPE NCC Database Group

On Tue, Apr 17, 2012 at 2:34 PM, Michele Neylon :: Blacknight <michele@blacknight.ie> wrote:

I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received?

Or does it work the way it does in webhosting abuse? Use a prepaid card and register an AS and its /15 as "mickey mouse, care of euro disney"? [or better still, as j random llc, care of a maildrop at a tobacconist in paddington] -- Suresh Ramasubramanian (ops.lists@gmail.com)

Not at all. Trying to find a vector through which this can be abused. If you thought that was an insult or a potshot, please be assured that's not my intent. On Tue, Apr 17, 2012 at 2:51 PM, Michele Neylon :: Blacknight <michele@blacknight.ie> wrote:

Suresh

I'm not sure what your last email is about.

Are you trying to be amusing? Or are you trying to take potshots at me or at RIPE?

In either case I don't see it as being particularly helpful for anyone

Regards

Michele

On 17 Apr 2012, at 10:07, Suresh Ramasubramanian wrote:

...

On Tue, Apr 17, 2012 at 2:34 PM, Michele Neylon :: Blacknight <michele@blacknight.ie> wrote:

...

I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received?

Or does it work the way it does in webhosting abuse?  Use a prepaid card and register an AS and its /15 as "mickey mouse, care of euro disney"?

[or better still, as j random llc, care of a maildrop at a tobacconist in paddington]

-- 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.biz http://mneylon.tel Intl. +353 (0) 59  9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 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

-- Suresh Ramasubramanian (ops.lists@gmail.com)

On 17/04/12:17 11:04 AM, Michele Neylon :: Blacknight wrote:

Denis

I assume RIPE is able to get paid by all members, so it must have some valid contact details or no bills would be sent or money received?

You are assuming that all data in the RIPE Database is either maintained by the RIPE NCC (registry data) or by members. This is not the case. A member can, for example, make a sub-allocation to another organisation that the RIPE NCC has no contract with and probably no direct email contact with. That sub-allocation can be further sub-allocated and then there may be assignments made where the assignment holder has the mnt-by authority over the assignment. However many layers, there is of course a chain of authority leading back to the LIR who has responsibility for their allocated address space. But it is not always as simple as the RIPE NCC emails a member and asks them to 'fix it'. Regards Denis Walker Business Analyst RIPE NCC Database Group

Regards

Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

Tobias Knecht wrote:

I think we should look for a solution that covers the chain of authority. Maybe a first step can be to cover the maintainers email addresses and go from there. As soon as we have the maintainers we could cover everything beyond and notify maintainers if something is going wrong within their reliability.

RIPE NCC has even other addresses they could use, not only the maintainer.

This should also cover the mechanisms that will be used for checking. For example I think it is absolutely okay to send verification mails to the maintainers,

Right. The LIR will have a problem, if they do not work, and even if they do not work, the NCC could mail the (internally known) customer email address and tell them, that the maintainer does not work.

but I'm not sure we should use a verification process on all the email addresses. This could first of all lead into legal issues and end up in accusing RIPE NCC as spammers when people with no

You cannot spam an email address, that is not working ;o) Remember: Im currently not talking about regular email checks, first there should be syntax, TLD, domain, MX or A record and availability of the mailserver checked, these could by easily reported to the maintainer or if that fails to the LIR. But thats interesting. Does anybody think, that an object maintainer will interpret an email coming from the NCC as spam, when it tells him, that his object is wrong ? If thats true, RIPE should really only mail the LIR directly. On the other hand: Could somebody please point out, if there is any contractual rule between RIPE and the LIR pushing the LIR to insert only correct data in the database ? If there is such a paragraph somewhere, it must be true, that the LIR has the same rule with his own customers and the chain should go down to every maintainer and even the last email address, "spam" should be no problem then.

direct legal connection to RIPE NCC receiving "spam" and need to verify their email address.

Verification should be discussed later, after its clear what the community thinks about validation. Kind regards, Frank

Thanks,

Tobias

-- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ======================================================================

Brian One of my fears is that if you introduce an abuse-c without any obligation to maintain then RIPE will be the target for a lot of criticism Regards Michele On 17 Apr 2012, at 09:09, Brian Nisbet wrote:

Leo,

Leo Vegoda wrote, On 17/04/2012 00:22:

...

Hi Denis,

On Apr 16, 2012, at 2:32 pm, Denis Walker wrote:

...

I am not aware of any formal big picture, but I follow the mailing list as closely as I am sure you and many others do. As you will know many of these issues invoke much discussion on the list.

I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary.

While I think that Frank has given a good outline, what is "this" to your mind?

Is it abuse contact management, is it data verification? Part of the problem that we hit with the ACM-TF is that data verification is a very big thing and people have a lot of reactions to it. This lead to a decision to try to get the abuse-c nailed down and integrated, before, should the community or TF decide, looking at data verification, and indeed the scope of that.

I'll be honest, I don't see the 2011-06 and any data verification proposal as being that tightly integrated, but I'll accept not everyone shares my view of the world, so if you could expand on your fears, or why you feel it is so vital, that would be great.

Thanks,

Brian.

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 Direct Dial: +353 (0)59 9183090 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

Hi Brian, all, Brian Nisbet wrote:

Leo Vegoda wrote, On 17/04/2012 00:22:

...

Hi Denis,

On Apr 16, 2012, at 2:32 pm, Denis Walker wrote:

...

I am not aware of any formal big picture, but I follow the mailing list as closely as I am sure you and many others do. As you will know many of these issues invoke much discussion on the list.

I think we only get one opportunity to do this right. Doing it without a strategy that's been agreed by the whole community seems quite scary.

While I think that Frank has given a good outline, what is "this" to your mind?

Is it abuse contact management, is it data verification? Part of the problem that we hit with the ACM-TF is that data verification is a very big thing and people have a lot of reactions to it. This lead to a decision to try to get the abuse-c nailed down and integrated, before, should the community or TF decide, looking at data verification, and indeed the scope of that.

I think my concerns are that if we have a large problem and solve it in pieces, because the work is done in pieces they might not tessellate well and leave us with something that is a bit broken. In particular, I am concerned that if a proposal for a new abuse-c object is approved but no contact data management policy is approved we just have a new layer of stale data. In general, I think more stale data is worse than less stale data. On the other hand, I can see that discussing multiple policy proposals simultaneously is difficult. I think my concerns would be allayed if the resulting policies (once approved) were implemented as part of a single, coherent programme of work and not as individual projects. That way, I think we could be fairly sure all the pieces fit well together. Regards, Leo

Hi everybody,

Accepting the assumption it was hard for resource holders/maintainers to find the right attribute/object type to publish abuse contact information, this can be well achieved with abuse-c. But the various examples provided in this and other threads suggest that more differentiation is needed for the communication channels. An abuse-c target object should inherit most of its attributes from the role: object and should offer different ways of reporting: manual (email), automated (email) and, maybe, web forms and the likes. Note, the idea was to help resource holders communicate their preferred way of contact establishment, _not_ to dictate or discriminate against their abuse handling procedures.

Sounds like a good suggestion. Imho the Best Practice for reporting abuse issues is e-mail for several good reasons. That's why I decided to stay with e-mail in this proposal. If there is any other Best Practice out there that tells us to add an attribute for webforms please let me know and I will add it to the proposal as an optional field in addition to e-mail and abuse-mailbox attributes.

And again, still assuming the idea is to help resource holders publish their data, there is no need to make "abuse-c" mandatory -- simply because the idea is so crisp and brilliant that they will adopt quickly.

Even if I fully agree with your statement about the crisp and brilliant proposal ;-) I do not agree with your other statement. I think the abuse-c should be mandatory for several good reasons I already brought up on this list. I also agree that there are several reasons for not making it mandatory, but the brilliance of this proposal is probably not one of them.

On item (1b) above, the proposal is unclear about the target audience for the "abuse-c" object on the receiving side.

It is all of the following.

Is it the end user who - regularly or occasional - sends some report? These folk can use the abuse finder tool today and they should really not be exposed to the raw database output anyway. Whatever change is applied, it will need a tool with additional explanation and guidance.

Absolutely agree with the additional explanation and guidance. The Abuse Finder Tool is the Tool to use for this audience. Never the less to come back to the "mess" the Abuse Finder can not find all entries in the Database just because there is no way to parse free text in an 100% correct way. And to be honest needing up to 150 queries to get one email address is far away from not being a "mess". Please recognize, that I have not put this specific issue in the proposal, because it has nothing to do with the idea of the proposal itself. Never the less it shows that this proposal would also be a huge improvement when it comes to maintenance and development for RIPE NCC and the functionality and reliability of the Database which should be and hopefully is the most important issue.

Is it for inter-operator incident handling? In this case, the relation to the IRT object needs to be clarified. That aside, people would probably expect manual or semi-automated (as in: ticketing system) handling of the incident report. Still, the current abuse-finder tool can already be of significant help.

As already stated in another mail on this mailinglist the IRT Object is another Object that has not direct connection to the abuse-c. Of course there will be maintainers that feel, that the abuse-c is a copy of the IRT and makes data redundant. Since we have seen numbers of IRT Object published there is absolutely no doubt about, that the future of the IRT Object has to be discussed. Whether if it will be removed, stays like it is or will be pushed more with documentation and "IRT Object Marketing". But this is and will not be part of this discussion.

Is it for high volume automated report dissemination (trap or sensor initiated identification of "activity")? For this to work it needs automated handling on the receiving side and it should be clearly opt-in, so that the receiving entity can prepare for proper processing.

Disagree from my experience in the anti-abuse industry. First of all reporting must be easy and receiving reports must be easy as well. That's why opt-in is a bad idea, which can bee seen at feedbackloops. Second, if you do not want to receive reports from one party, block them or directly delete them. That is best practice and widely adopted and really not complicated to do. Not even talking about the huge amount of work and maintenance that is needed to keep up a opt-in infrastructure and to find the right data sources.

To summarize: who is the target audience and what mode of operation are resource holders going to subscribe to by publishing an "abuse-c" reference?

The target audience is the reporter and the receiver. The reporter will find the responsible address more easy and the receiver can publish his information more easy. By publishing the abuse-c the receiver subscribes to his already existing duty to keep his network clean and avoid abusive behavior. I hope all people here agree to this.

Item (2) above, no rate limiting on the responses, is also tricky. This is much more about the actual access mechanism than the object type and its attributes and the policy text (cf 'arguments opposing this proposal') already states that a proposal with the devil in the details and the details not laid out doesn't really make sense.

It is about the possibility to access the abuse-c without query restrictions. As a policy proposer I do not care about the implementation, I care about functionality. And if this functionality is not possible in the RIPE DB, RIPE NCC will mention this in the impact analysis. If it is possible they will probably implement it as soon as this proposal reached consensus.

And quite frankly, postponing this to the result of the NCC impact analysis is putting the cart before the horse. Details,please - and that also covers the proposed inheritance function.

Same here. We are talking about the goal and not the way at the moment. If we decide that we have the same goal we can talk with RIPE NCC about the way to get there and find a way that suits (mostly) all parties.

Then, finally, why should the "abuse-c" object, or the references to it, respectively, be mandatory (noting that version 2 claims it's mandatory for aut-nums only, again without giving deeper insight)?

It will be mandatory for aut-nums, inetnums and inet6nums. I have seen that there is something missing in the proposal text and I'm sorry for that. It will be mandatory for aut-nums, inetnums and inet6nums. I will try to get it fixed in this version or at least in the next version. Thanks for pointing this out.

However, I have read between the lines (or maybe even explicit) that some are dreaming of creating compliance cases at high volume, probably to get address space eventually revoked. I am unconvinced that this reflects the community cooperation that we celebrated happening the last 2+ decades. In any event, if that's the end goal, the proposal should be honest about this, but I think it's the wrong way to go.

I was reading the hole proposal, which was written by me, again a few seconds ago just to make sure I fully understood it. I have not seen anything about revoking address space and a possibility that high volumes lead to any kind of punishment. Not explicitly and not between the lines. Honestly (as honest as the proposal itself) reading between the lines and to fan fear are imho not good arguments against this proposal. Sorry. However the idea of revoking ip space based on high level complaint rates may be dreamed by some people, but there would be still a policy proposal necessary to go down this road and I think if this proposal shows up we can disagree there. I hope I was able to clear some stuff up and make it more clear what this proposal is about and about which parts we should discuss now. Thanks, Tobias