Dear Sergey, Thank you for your question. These are the kinds of things that our formal impact analysis will cover in the Review Phase. This is the best time to explore these topics in more depth. However, our initial understanding is that the proposal aims to identify and fix invalid abuse-mailbox contact information. The RIPE NCC would contact resource holders and help them to update their information if necessary. Only if an organisation was unresponsive or uncooperative over a long period would we consider invoking the current closure procedure detailed in ripe-676, "Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources". You can find this document here: https://www.ripe.net/publications/docs/ripe-676 It is important to note that the RIPE NCC has always been careful when invoking this procedure, and does so only as a last resort. We would continue to apply the same level of caution if this policy proposal is accepted. In its current version, the policy change would only apply to RIPE NCC members and holders of Independent Resources. "Abuse Contact Management in the RIPE Database" does not apply to legacy holders, so they would be unaffected. A recent policy proposal (2016-01) tried to add a requirement for legacy holders to have an abuse contact, but it did not reach consensus: https://www.ripe.net/participate/policies/proposals/2016-01 Kind regards, Marco Schmidt Policy Development Officer RIPE NCC On 2017-09-07 14:13:04 CET, Sergey Myasoedov wrote:

Hi Marco,

Thank you for the very good proposal.

The one of opposing arguments is:

...

If organisations are not cooperative, the RIPE NCC ultimately has the possibility to close their RIPE NCC membership and deregister their Internet number resources.

How RIPE NCC is going to deal with not cooperative members/PI holders/Legacy holders? I don't see anything in the proposal text. Is there any grounds for terminating membership and/or deregistering resources?

-- Kind regards, Sergey Myasoedov

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Suresh, This information will be part of the NCC's Impact Assessment, which is supplied at the end of the initial discussion phase. The first phase is around the proposal itself and whether the community feels it has merit in and of itself. All of the pieces are required for the whole that is the PDP, but impact on the NCC isn't he focus right now. Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 On 13/09/2017 12:29, Suresh Ramasubramanian wrote:

As a rough indication of the impact, how many ASNs are going to be affected by this move?  Has any study been made on the number of ASNs with such invalid contact information in abuse-c, and are they concentrated anywhere in particular such as on specific ISPs?

 

If the objections to this proposal were not made on philosophical grounds, and made with loud protestations that the impact on RIPE NCC staffing resources would be too great, without actually making such assessments and seeing the data on who would actually be negatively impacted by this proposal ..

 

TL;DR – what data do we have available?

 

--srs

 

*From: *anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Andreas Worbs <anw@artfiles.de> *Organization: *Artfiles New Media GmbH *Date: *Wednesday, 13 September 2017 at 3:52 PM *To: *<anti-abuse-wg@ripe.net> *Subject: *Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)

 

I support this proposal, it's a good step in the right direction. Valid contact (incl abuse-c) information is necessary for such a database.

Also a validation of the abuse-c should be made with the resource registration for new resources.

Furthermore i don't know why some guys think a resource will be deregistered right after the resource is tagged as invalid. The proposal is obviuos

/In cases where the “abuse-mailbox:” contact attribute is invalid, the RIPE NCC will follow up with the resource holder and attempt to correct the issue./

So there are some more steps before it will be deregistered, so cool down.

 

Am 07.09.17 um 13:59 schrieb Marco Schmidt:

Dear colleagues,

 

A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion.

 

The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information

and to follow up in cases where contact information is found to be invalid.

 

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2017-02

 

As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase

is to discuss the proposal and provide feedback to the proposer.

 

At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs,

decides how to proceed with the proposal.

 

We encourage you to review this proposal and send your comments to

<anti-abuse-wg@ripe.net> <mailto:anti-abuse-wg@ripe.net> before 6 October 2017.

 

Kind regards,

 

Marco Schmidt

Policy Development Officer

RIPE NCC

 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

 

--

Kind regards

 

Artfiles New Media GmbH

 

Andreas Worbs

 

 

Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg

Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95

E-Mail: support@artfiles.de <mailto:support@artfiles.de> | Web: http://www.artfiles.de

Geschäftsführer: Harald Oltmanns | Tim Evers

Eingetragen im Handelsregister Hamburg - HRB 81478

Suresh, Indeed, and it's a point that I should have reiterated earlier in regards to when in the process the NCC will provide their impact assessment. Thanks, Brian Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 On 14/09/2017 11:29, Suresh Ramasubramanian wrote:

Sorry – two sets of impacts

1. Impact on NCC staff’s time – ok, impact assessment 2. How many ASNs are we talking about here and can they be aggregated under some specific upstream providers?

I am sure an impact assessment would work – my point was that a lot of the criticism so far has been jumping to conclusions over the impact.

On 14/09/17, 3:03 PM, "Brian Nisbet" <brian.nisbet@heanet.ie> wrote:

Suresh,

This information will be part of the NCC's Impact Assessment, which is supplied at the end of the initial discussion phase. The first phase is around the proposal itself and whether the community feels it has merit in and of itself.

All of the pieces are required for the whole that is the PDP, but impact on the NCC isn't he focus right now.

Thanks,

Brian Co-Chair, RIPE AA-WG

Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

On 13/09/2017 12:29, Suresh Ramasubramanian wrote: > As a rough indication of the impact, how many ASNs are going to be > affected by this move? Has any study been made on the number of ASNs > with such invalid contact information in abuse-c, and are they > concentrated anywhere in particular such as on specific ISPs? > > > > If the objections to this proposal were not made on philosophical > grounds, and made with loud protestations that the impact on RIPE NCC > staffing resources would be too great, without actually making such > assessments and seeing the data on who would actually be negatively > impacted by this proposal .. > > > > TL;DR – what data do we have available? > > > > --srs > > > > *From: *anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of > Andreas Worbs <anw@artfiles.de> > *Organization: *Artfiles New Media GmbH > *Date: *Wednesday, 13 September 2017 at 3:52 PM > *To: *<anti-abuse-wg@ripe.net> > *Subject: *Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular > abuse-c Validation) > > > > I support this proposal, it's a good step in the right direction. Valid > contact (incl abuse-c) information is necessary for such a database. > > Also a validation of the abuse-c should be made with the resource > registration for new resources. > > Furthermore i don't know why some guys think a resource will be > deregistered right after the resource is tagged as invalid. The proposal > is obviuos > > /In cases where the “abuse-mailbox:” contact attribute is invalid, > the RIPE NCC will follow up with the resource holder and attempt to > correct the issue./ > > So there are some more steps before it will be deregistered, so cool down. > > > > Am 07.09.17 um 13:59 schrieb Marco Schmidt: > > Dear colleagues, > > > > A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion. > > > > The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information > > and to follow up in cases where contact information is found to be invalid. > > > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2017-02 > > > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase > > is to discuss the proposal and provide feedback to the proposer. > > > > At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, > > decides how to proceed with the proposal. > > > > We encourage you to review this proposal and send your comments to > > <anti-abuse-wg@ripe.net> <mailto:anti-abuse-wg@ripe.net> before 6 October 2017. > > > > Kind regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > -- > > Kind regards > > > > Artfiles New Media GmbH > > > > Andreas Worbs > > > > > > Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg > > Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 > > E-Mail: support@artfiles.de <mailto:support@artfiles.de> | Web: http://www.artfiles.de > > Geschäftsführer: Harald Oltmanns | Tim Evers > > Eingetragen im Handelsregister Hamburg - HRB 81478 >

In either case the numbers will speak for themselves and any comments without seeing them are going to be premature. Never mind the RIPE NCC staff effort costing – does someone have numbers on the # of ASNs with invalid abuse-c information, and whether there are significant clusters of such ASNs downstream of individual ISPs / LIRs? --srs On 14/09/17, 5:56 PM, "Nick Hilliard" <nick@foobar.org> wrote: Suresh Ramasubramanian wrote: > I am sure an impact assessment would work – my point was that a lot > of the criticism so far has been jumping to conclusions over the > impact. That's not an unreasonable comment, but the flip side is also true: the policy makes an a-priori assumption that this is the best approach for dealing with abuse contact management in the circumstances, without providing or considering any evidence for or against. Nick

On Wed, 4 Oct 2017 23:54:44 +0000 (UTC) denis walker <ripedenis@yahoo.co.uk> wrote:

I have read the proposal and all the comments. Many things have already been said. I will try to say something new, mostly on the technical issues. My first comment is as the co author of the original "abuse-c:" policy. It was clearly said during the discussion about that policy that it was ONLY intended to define a place to store abuse contact information in the RIPE Database. It was also

if one is to store information in a database, surely it has to be actual data and not just random characters? so, if you store an abuse-c email record, in your statement, it is okay to store: mickey.mouse@example.com and RIPE has to store a lot of junk? what would the purpose of that be?

said that further policies may be brought forward at a later time about validating the email addresses and/or enforcing action on abuse reports. So the lack of any validation does not undermine the existing policy. This was by design.

poor design or what else? one sometimes has to wonder at the motives and sometimes these motives seem immoral, not ethical and very vague and suspicious. all hidden under the guise of "freedom" - but freedom with zero responsibility is evil.

This policy extension is about validating the email address in the "abuse-mailbox:" attribute. These will only exist in ROLE objects after the planned cleanup to be done soon. These ROLE objects are referenced by "abuse-c:" attributes in ORGANISATION objects and soon INET(6)NUM and AUT-NUM objects. They may also be unreferenced. There will be a default "abuse-c:" for all resources administered by the RIPE NCC. There will also be delegated "abuse-c:" attributes in a variety of places managed by or on behalf of customers of LIRs. It is not clear at all in this proposal which ones are going to be validated. Just the mandatory ones for resource holders or all of them? Validating all of them will be more challenging both technically and procedurally. But not validating them all may leave invalid data in the RPE Database.

the point of storing data is to store actual data and not actual rubbish. otherwise you may as well propose the allocation of resources to Minnie and Mickey Mouse.

How will they be marked as invalid? Will this show up on a database query or in the information returned from the Abuse Finder or RIPEstat? Or is it for RIPE NCC internal use only? Will they only be marked as invalid because of a lack of response from the test email? What if someone informs the RIPE NCC of an invalid address?

this will need to be discussed as having junk data is not only pointless but also meaningless. Why does RIPE exist if there is fake/junk/rubbish data?

The new policy text says "attempt to correct the issue". Saying 'attempt' is a very weak statement. If the end result 'could be' deregistration then I think the policy should say something stronger like "the issue will be fixed". If that is the end goal then make it clear.

+1

There is some mention of 'complying with national laws'. Did you have a particular nation in mind or do you mean all nation's laws or just all those in the RIPE region?

all EU nation laws, maybe the word EU could just be added? or is the intent "international" as in planet wide? (-1 for that)

One of the supporting arguments is given as "Validating “abuse-c:” information is essential to ensure the efficiency of the abuse reporting system." It may be "helpful to the effectiveness" but it has nothing to do with efficiency.

it does. as junk in means junk out. the whole point of validating abuse-c is to firstly ensure the accuracy of data, which will serve to ensure efficiency of abuse reporting.

During the discussion it was said that using an auto responder would validate the email address in compliance with this policy. So anyone who doesn't intend to handle any abuse reports just needs to set up an auto responder, or even filter emails on "@ripe.net" or on some keyword/phrase in what will probably be a standard text and respond to that email. The data is valid and the RIPE NCC at least will get a response. But it is meaningless. Of course it will highlight those resource holders who are already serious about handling abuse but mistyped an address or forgot to update it. But resource holders who have no intention of responding to any abuse complaint can easily avoid any hassle from the RIPE NCC with this validation process.

ianal, but: an auto response is an acknowledgement of receipt. so, if you receive notice of a 100TB DDOS and you do nothing, you may be legally "more" liable. etc etc.

Also during this discussion it was said "The point is: if there is an auto-responder, there won't be an absolute and definitive invalidity of the answer. But additional investigations would be conducted, of course." Now I am not an expert on the inner workings of email clients. So do all auto responders add something to the email header to make it clear it is an auto response? Or can one be configured to send back an email looking as if I wrote it? If so what is going to trigger the 'additional investigations' for auto responses?

any response is a response. so, it is semantics...

I don't understand why possible deregistration is listed as an argument 'against' the proposal.

fake data?

The arguments listed as supporting the proposal, in my mind, read like a marketing brochure. I don't think that style of writing in this type of proposal is helpful...but that is just my opinion...

Overall I neither support nor oppose the policy. I just wanted to highlight some issues.

cheers denis

From: Marco Schmidt <mschmidt@ripe.net> To: anti-abuse-wg@ripe.net Sent: Thursday, 7 September 2017, 13:59 Subject: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation) Dear colleagues,

A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion.

The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information and to follow up in cases where contact information is found to be invalid.

You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-02

As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal.

We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 6 October 2017.

Kind regards,

Marco Schmidt Policy Development Officer RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

On Thu, 5 Oct 2017 11:29:38 +0000 (UTC) denis walker <ripedenis@yahoo.co.uk> wrote:

Just because that policy didn't force people to enter valid information with a threat of deregistration is no reason for anyone to enter junk into the database. There has always been a condition of membership that people enter and maintain correct information in the RIPE Database. A policy for verifying email addresses was left for another day...that day seems to be now... cheersdenis

then you should be offering improvements to this proposal and support it. as per your own words and implication: this policy is needed. it is not only a moral and ethical imperative to ensure the highest standards and leadership role that RIPE has become known and respected for, but as you said: the time has come. so, all moral, good and ethical people should stand up and add, improve, support. and not simply say: well i am neither for not against... clearly you are supportive of this as non support of this makes no sense other than to derail ethical and moral behavior towards public owned allocated resources. Andre